On Wed, 04 May 2011 14:51:41 +0200 Michael Karcher <[email protected]> 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 _______________________________________________ flashrom mailing list [email protected] http://www.flashrom.org/mailman/listinfo/flashrom
