[flashrom] RFC: precious regions

[Stefan Tauner]

On Wed, 04 May 2011 14:51:41 +0200
Michael Karcher <flashrom at mkarcher.dialup.fu-berlin.de> wrote:

> Am Mittwoch, den 04.05.2011, 13:59 +0200 schrieb Stefan Tauner:
> 
> > 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.
sure the ICH case is more severe, but a system where flashrom tries to
erase+write a partially write-protected chip would also lead to
problems and unbootable systems (although they are more easily fixable
ofc).

> > 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).
yes, in a non-generic way ;)

> 
> > 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.
there may be two mappings necessary: one for write, one for erase; but
i dont see the point in differentiating between "logical" and
"physical". its unimportant for flashrom why exactly it is not possible
to write/erase an address region as long as it checks it before it
"commits the whole transaction" (i.e. starts to erase and write).

> > 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.
i don't hate the structures that try but fail to do the right thing, but
the language that hinders us from doing so :P

> [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?
i'd like to concentrate on my usb flasher and getting all the/my
previous patches in, but i can try too if you dont want to.
let's discuss/fix the specification first, which centers on the
question: when do we want to abort/warn?

warning could be done by letting "do_ich9_spi_frap" return something
instead of void and printing similar to the FLOCKDN warning at the end
of ich_init_spi.
(btw the FLOCKDN warning should be enhanced: as i said before i think
ichspi has very verbose output. those warnings need to stand out
more...)
we could abort immediately in ich_init_spi by returning something !=
0(?). what other options do we have? a file-wide variable that is set
by init and is checked by run_opcode?

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