[flashrom] [RFC] Layout handling...

[Tadas Slotkus]

On Tr, 2011-08-17 at 02:00 +0200, Carl-Daniel Hailfinger wrote:
> Hi,
> 
> before we change flashrom to work with current layout requirements, we
> should summarize the features we need/want, and then decide how to
> handle the individual layout regions internally.
> 
> Terms:
> "write strategy" describes a combination of erase+write commands with a
> given block size, touching some blocks.
> "read protected" describes a region which can not be read.
> "write protected" describes a region which can not be written.
> "write once" describes a region which can be written exactly once in the
> chip lifetime.
> 
> If you add a feature to the list, please give it a nickname so we know
> which feature people are referring to. Some of the features below might
> not be desirable, but I want to list them anyway so we can explicitly
> declare them as unsupported if needed.
> 
> fullwrite-unrestricted: Write a chip-sized image, no special read/write
> restrictions of the chip, no layout file needs to be specified. Default
> write case right now.
> 
> 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.
> 
> fullwrite-postread: Write a chip-sized image, reading anything from the
> chip is only possible after write. Chips which are read-locked until a
> full erase/write fall in that category. Do those exist as standalone
> flash chips or only integrated into processors?
> 
> fullwrite-partialread: Write a chip-sized image, reading is only
> possible in some chip regions. Only partial verification, violates our
> reliability guarantees.
> 
> 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?
> 
> partialwrite-unrestricted: Write only parts of an image, the rest of the
> chip contents is kept, no special read/write restrictions.
> 
> 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?
> 
> 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.
> 
> fullread-unrestricted: Read the full chip, no special read restrictions
> of the chip.
> 
> partialread-unrestricted: Read only parts of a chip, no special read
> restrictions of the chip.
> 
> partialread-partialread: Read only parts of a chip, some regions are
> read-protected. flashrom should refuse to read any read-protected regions.
> 
> 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?
> 
> 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?
> 
> 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.
> 
> partialaccess-crash: Some regions in the chip are really off-limits and
> will cause an unrecoverable error (system crash) when accessed (read or
> write). That seems to be the case for some EC/flash interactions.
> 
> 
> 
> Comments? Any forks of flashrom (e.g. chromium) which need
> infrastructure features not mentioned above?
> 
> 
> Regards,
> Carl-Daniel

Hi, wow, that's a big list you generated :)

Now, I think that any partial read/write must supply the image with only
it's contents (no 0xff or similar fills) and a layoaut file similar to
that we have now, except names point to binary files, and addresses are
offsets, where to write that binary to chip. Or it could be one
concatenated binary file.

Overlapping regions - never support it. It's not a flashrom's job to
make a good image for a chip. So do one region at a time in one place.

Partial write: don't read full chip. If needs erase: user supplied image
must contain all the eraseregion. Or the user must explicitly mark that
it needs erase somehow. I believe you won't go with me here, but I'm
open for discussion :)

Anyway, thanks for starting this thread - it's time to make it clear :)

Use UNIX philosophy: do one thing and do it well.

Thanks,
Tadas