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