[flashrom] [RFC] Layout handling...

Stefan Tauner stefan.tauner at student.tuwien.ac.at
Tue Aug 23 11:52:23 CEST 2011


On Wed, 17 Aug 2011 02:00:28 +0200
Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> 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.

missing term: range (and derived terms, especially "write-protected
range" because it relies on write protection borders to coincide with
erase block borders(?))

> 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.
                             ^--------------------^
are they specified somewhere explicitly? i guess everyone reading this
is aware of the general read-erase-write-read pattern, but arguing
about any feature with the aid of those without specifying exactly what
it means is pointless.

> 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?

it would be enough if specific programmers with attached chips
behave like that. there might be some FPGA boards that use an external
SPI flash, but restrict access to it in that way. the nickname is a bit
misleading imho (sounds like reading is only possible after write.
fullwrite-nopostread might be an alternative).

> fullwrite-partialread: Write a chip-sized image, reading is only
> possible in some chip regions. Only partial verification, violates our
> reliability guarantees.

does this exist in the wild?
ICH could be configured this way theoretically.
 
> 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?

what david said (i.e. refuse unless pointed by layout+image options to
writable ranges only, so always refuse (in) this scenario).

> 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?

what david said.

> 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.

what david said.

> 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.

yes. bail out and warn, even if parts of the regions requested might be
readable (to be consistent with *-partialwrite).

> 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?

publicly undefined (and use either in implementation). what are the use
cases for those regions?

> 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?

what david said already...
with my (*ahem* chromium's) patches both is possible (even in the same
execution): having one big image with the parts at their offsets, or a
file for (some or or every) region with offset 0. and that's how it
should be imho :)

> 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?

see above and patches ;)

> 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?

yes, yes, see patches.

> 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.

do we need to express it somehwere? we should just unlock as much as
possible at startup, return layout data describing what ranges are
readable and writable according to the module (chipset
enable/programmer init and flash chip probe/query lock). if the union
of all those layouts indicate we can do what we want fine, if not bail
out.

> 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.

so far we have only discussed don't read and don't write ranges. the
crash regions should simply be described as both (WP and RP) and handled
implicitly. is there a problem with that?

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner




More information about the flashrom mailing list