[flashrom] RFC: precious regions

Stefan Tauner stefan.tauner at student.tuwien.ac.at
Wed May 4 13:59:15 CEST 2011


On Wed, 04 May 2011 12:35:54 +0200
Michael Karcher <flashrom at mkarcher.dialup.fu-berlin.de> wrote:

> IDEA:
> -----
> Introduce the concept of "precious regions", i.e. parts of the flash
> chip that may never be erased. Flashrom would deny to send erase
> commands to blocks that overlap with precious regions. This might
> cause flashrom to fail in certain cases where a block that crosses a
> border between precious and non-precios needs to be erased to modify
> the contents of the non-precious region, so "precious regions" should
> not be overused (i.e. declare all not-to-be-modified regions from the
> layout file as "precious" unconditionally). I see the main use case
> for precious regions in these two items:
>  - Regions we know we can't write, because of the flash firewall in
> the chipset. Most flash chips implement their locks in a way that a
> non-programmable area is non-eraseable, so flash chip locks don't need
> the "erase forbidden" handling.
>  - Embedded controller code and boot block code
> 
> precious regions for unwritable areas are mandatory, as flashrom will
> leave a messed up system behind otherwise, while precious regions for
> boot block and EC code of course should be optional, but are very nice
> to have as safety net on computers with soldered flash.
> 
> I explicitly don't suggest trying to implement a general algorithm to
> find boot block and EC code in vendor images in flashrom, but a
> 3rd-party tool to generate layout files might be nice. I do think of
> extending layout file syntax to be able to flag layout parts (e.g. as
> precious, but other flags like "prefer big erase/prefer small erase"
> might make sense too), though.
> 
> What are your thoughts about this?

i dont like the term "precious regions", but apart from that i think
for the described problem a layout file-based solution alone is not
ambitious enough.. it even complicates things, because we need an
extra step to generate the layout file. i have not looked at the code
yet, but generally the desired information needs to be gathered from
several sources.
in the case of ICHs some pci registers of the (internal) programmer
have to be read; for some hardware protected flash chips it is possible
to read the wp status in their status register(s); there may also be
other limitations like maximum address lines for parallel flashers
(what else?).
these can and should be read dynamically and evaluated before starting
to erase/write in combination with the information from the layout file
(precedence on the dynamic data with an enforcing option in the layout
file?).
so we would need a data structure (probably similar to what now holds
the layout from the layout file), querying methods in all kinds of
objects in flashrom and something that evaluates the data structure
before committing modifying commands.
all in all this stuff is quite convoluted. i think we should
not start before we have reduced the patch backlog significantly. a
part of what i think can certainly be hacked into ichspi.c quite
quickly but i think to mitigate the outstanding ICH problems for the
near future the backup idea is better.

i see the java programmer shines a little bit through... but i
really like generic solutions :)

> 
> BACKUP IDEA:
> ------------
> If the precious region stuff seems as overdesigned, we should abort as
> soon as we find any non-rw region on the ichspi driver.

this is the way to go for -w/-e for now imho. we should also print a big
fat warning when we do probe (or -r) and notice some possible problems
for other operations (i.e. r/o or locked regions).

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




More information about the flashrom mailing list