[flashrom] [RFC] Layout handling...

[David Hendricks]

On Tue, Aug 16, 2011 at 5:00 PM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> fullwrite-noread: Write a chip-sized image, reading anything from the
> chip is not possible. Many DVD writers fall in that category. No
> verification, violates our reliability guarantees.
>

While this is an understandable constraint, it means we'll need to be more
careful with how we handle partial write logic (no more reading old content,
merging new content, and writing back).

On Tue, Aug 16, 2011 at 5:00 PM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> fullwrite-partialwrite: Write a chip-sized image, but writing is only
> possible in some regions. This is obviously a conflict unless the image
> has the same contents as the chip in the write-protected regions and
> there is a possible write strategy for the whole image which does not
> touch the write-protected regions. Should flashrom always refuse this
> scenario, or only refuse it in case of conflicts?
>

Process include arguments first. User must specify regions which are fully
writeable. Flashrom should check that they are beforehand and abort if any
foreseeable problems arise so that the image on the chip is not left in an
inconsistent state.

On Tue, Aug 16, 2011 at 5:00 PM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> partialwrite-partialread: Write only parts of an image, the rest of the
> chip contents is kept, reading is only possible in some chip regions. If
> no read-protected regions are written and a suitable write strategy
> exists, should flashrom warn? If a read-protected region is written,
> should flashrom warn/refuse due to reliability requirements?
>

In the former case (no read-protected regions are written and suitable write
strategy exists), do not warn. In the latter case (read-protected region is
written, like with the DVD write example above), refuse and print a warning
to use --force.

On Tue, Aug 16, 2011 at 5:00 PM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> partialwrite-partialwrite: Write only parts of an image, the rest of the
> chip contents is kept, writing is only possible in some chip regions. If
> no write-protected regions are written and a suitable write strategy
> exists, should flashrom warn? flashrom will refuse to write a
> write-protected region.
>

No warning if no write-protected regions are used.

On Tue, Aug 16, 2011 at 5:00 PM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> partialread-partialread: Read only parts of a chip, some regions are
> read-protected. flashrom should refuse to read any read-protected regions.
>

Flashrom should probably also print a warning so the user knows the output
might not meet expectations.

On Tue, Aug 16, 2011 at 5:00 PM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> partialread-imagefiller: If only parts of a chip are read and the read
> image has full chip size, what should be used as filler for unread
> regions? 0x00 or 0xff?
>

Whatever the ROM's default is. I presume 0xff is a safe bet for modern flash
memory. I also suggest this to avoid unnecessary erase/write operations.

On Tue, Aug 16, 2011 at 5:00 PM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> partialread-layout-imagesize: If only parts of a chip are read, should
> the read image still have full chip size with all read regions filled in
> at the respective locations?
>
> partialread-layout-split: If only parts of a chip are read, should it be
> possible to write each region (or a combination thereof) to a separate
> image file, and would that mapping be specified in the layout file?
>
> partialwrite-layout-split: If only parts of a chip are written, should
> it be possible to collect each part of the new image from a separate
> image file, and would that mapping be specified in the layout file?
>

Good question. We actually found a use for this scenario in Chromium OS, and
the answer is that we do both now. The syntax we arrived at (Louis Lo added
this) goes like this:

./flashrom -p internal:bus=spi -l layout.txt -i region_0:region_0.bin -i
region_1:region_1.bin -r foo.bin

The result is three files: region_0.bin containing only region_0's content,
region_1.bin containing only region_1's content, and foo.bin. foo.bin is the
size of the chip, contains region_1 and region_2 content at their respective
locations, and is filled with 0xff elsewhere.

This is useful in a few ways:
- Speed (obviously) for selectively reading content.
- The chip-sized image can be modified and written back to the chip easily
using familiar partial write methods.
- The chip-sized image is also good for debugging since no arithmetic is
required to know what offset is being examined :-)

On Tue, Aug 16, 2011 at 5:00 PM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> readwrite-protection-time: Which read protection and write protection
> times exist? Temporary lock until unlock, temporary lock until chip soft
> reset, temporary lock until chip/programmer hard reset (powerdown or
> reset line), permanent eternal lock.
>
> readwrite-protection-type: Which read protection and write protection
> types exist? Programmer lock (e.g. Intel SPI), hardware chip lock (WP
> pin), software chip lock (chip command).
>
> readwrite-protection-interaction: How should we express this situation:
> A region is write-locked with a software chip lock, but to remove that
> software chip lock, a hardware chip lock has to be disabled first, then
> the software chip lock can be disabled.
>

Just fail if it's not easy to defeat the write protection (and hopefully
restore it). There are so many hardware write protection mechanisms out
there that I don't think it's within Flashrom's scope to try and defeat them
all.

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.flashrom.org/pipermail/flashrom/attachments/20110819/a6d49c14/attachment.html>