[flashrom] RFC: precious regions

[Michael Karcher]

Am Mittwoch, den 04.05.2011, 13:59 +0200 schrieb Stefan Tauner:
> > 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 didn't think of implementing precious regions *via* a layout file, I
just mentioned that for EC/boot block, some subimages in the layout
files should be markable as "precious". I am open for other terms, too.

>  i have not looked at the code
> yet, but generally the desired information needs to be gathered from
> several sources.
That's correct.

> 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);
While we also might want a kind of locking infrastructure, which might
share code with what I thought of for the precious regions, this still
is something different. A flash chip that has some write protection does
not get into unfixable state by issuing an erase command, but it will
reject the erase command.

> there may also be
> other limitations like maximum address lines for parallel flashers
> (what else?).
IIRC we reject working with non-addressable chips (parallel with too few
address lines, or non-mapped FWH).

> these can and should be read dynamically and evaluated before starting
> to erase/write in combination with the information from the layout file
The data we get dynamically is qualitatively different from the data in
the layout file. The layout file tells us about the logical structure of
the flash, while the dynamic data tells us about the physical limits. In
case of the ICH stuff, on some layer these two views happen to coincide,
as the physical locking is indeed enforced on the base of the specified
logical structure. But for example on some parallel flash chips, the
chip might have a read-only top boot block of 16K, while the boot block
code of the BIOS is in fact 32K or 64K. For deciding what we should
rewrite, we need the true logical boot block size, while for knowing
what can be erased, we need the physical boot block size.

> all in all this stuff is quite convoluted. i think we should
> not start before we have reduced the patch backlog significantly.
Agree. I just wanted to archieve the idea.

> 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 never thought of an ichspi specific solution, that's why I didn't call
it something like "firewalled regions", but looked for a more general
concept of "for some reasons, do *never* *ever* erase this range".

> i see the java programmer shines a little bit through... but i
> really like generic solutions :)
If you are a java programmer, you are most likely gonna hate the limited
ad-hoc OO-like structures in flashrom.

[Abort on possible problems of ICH]
> 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).
Who will make a patch for that, me or you?

Regards,
  Michael Karcher