On Tue, Aug 16, 2011 at 5:00 PM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006@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@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@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@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@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@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@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@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.