[flashrom] IBM Aptiva, SiS 5595 - success (read)

[Stefan Tauner]

On Tue, 25 Dec 2012 13:48:23 +0000 (GMT)
Bertho Grandpied <y31415926536 at 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.
-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner