On Tue, 25 Dec 2012 13:48:23 +0000 (GMT) Bertho Grandpied y31415926536@yahoo.fr wrote:
I,(Czerno), wrote :
reporting success reading (dumping) the ROM BIOS on my IBM Aptiva 2170-G (actually an ACER V75-M motherboard) ....
(S.T.) said :
Read tests are mostly pointless in general, even more without a log. If it is not too much of a hassle please send us the output of flashrom -p internal -V
Sorry I did intend to include a log. Appending it now (inlined rather than attached, for the benefit of ppl like me who read from the list archive).
Hi Czerno, thanks, looks good.
I have /not/ tried to write or erase, sorry; though
have little doubts those operations would succeed similarly.
I do fully understand your refusal to test writing (but I am not so sure about its probability of success. Many boards needs a bit of extra effort to disable write protections).
The reason I dared mention having little doubts (thus doubts still) is because that IBM machine is a desktop, not a portable. Not refusing to try the writing procedure, it's just... I had no particular reason to alter the EEPROM here, and wasn't even sure you'd have results already for this mobo and chipset.
My words were not meant to blame you or something like that, we don't ask users to test modifying operations without need, because the risk is usually not worth it. The M29F002T/NT is still untested, so from our point of view it would be interesting to know if it works. The chipset code was tested some time ago, but SiS chipsets are quite uncommon hence seldom tested (but of course we try to not break already working code :)
I /will/, since it's XMas time, test writing for the sake of you so, please, would you answer a couple questions :
That would be very nice, thank you.
- how many rewrites will a typical BIOS chip take (order of magnitude) ?
Quoting the datasheet for your chip (which is typical): "100,000 PROGRAM/ERASE CYCLES per BLOCK" NB: not all chips meet their specs.
- when instructed to write, will Flashrom try its best to spare the chip, e.g. in the sense that (IIUC) it should write without preerasing regions that were not previously written to (i.e., are read as hex FFFF...) ?
flashrom only erases and writes blocks with changed data only, this includes the special case you mentioned. This allows to do partial writes as mentioned below very easily by reading the old contents, flipping a bit and rewriting that image. This lowers the test coverage significantly though.
- if I intended to test by flashing over a small, currently unused, part of the ROM, defining it in a /layout file/, do I have to /know/ precisely how my particular flash chip is organised /physically/, or does Flashrom use /logical/ regions, as I hope it does ?
The physical layout is not known to flashrom with the exception of erase block boundaries (probably what you meant with physical layout). In general we are just operating on a linear address space.
Because of answers 1 and 2, I would prefer if you could test the complete chip as follows.
- verify that the image read by flashrom looks legit (e.g. not all 0xFF) - copy the image read somewhere safe. - edit the other copy of it and change a single byte in the middle of any larger 0xFF block. - write the modified image (this should be somewhat safer than what follows, but you can also skip it). - erase the whole chip with flashrom -o erase.log -E ... - write back the backup copied in step 1 with flashrom -o write.log -w ...
If anything unexpected happens and/or flashrom shouts at you, first try to write the backup. This usually leads to a safe state again and should never make things worse.