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.

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.