[LinuxBIOS] mcp55 flashrom problem

Ward Vandewege ward at gnu.org
Fri Mar 2 20:42:38 CET 2007


On Thu, Mar 01, 2007 at 02:17:22PM +0100, Uwe Hermann wrote:
> On Thu, Mar 01, 2007 at 12:15:33AM -0500, Ward Vandewege wrote:
> > > That's odd. flashrom works fine on my DFI LANParty board, with the
> > > patch I submitted that adds PCI ID 0x360. Maybe shadowing is enabled
> > > only on certain vendors' BIOSes.
> > 
> > So, you've verified that the image that flashrom reads matches what you can
> > download from the manufacturers website (extracted)?
> 
> Can you please try to read the BIOS using a tool from the vendor, then
> reboot, then read the BIOS again and compare both images.

OK, I don't understand what's happening here.

Datapoint 1:

Last Wednesday, we got fairly large differences in the flashrom readouts
between boots, on the order of about 100 bytes, spread throughout the image.

Datapoint 2:

The downloadable bios from Gigabyte must be somehow compressed (even though
it's the exact right size), and be decompressed by their proprietary flash
tool on the fly; it's *totally* different from what flashrom reads.

Datapoint 3:

The proprietary bios includes a feature called 'Q-flash' which is basically a
BIOS flash tool built into the BIOS. It can save the current BIOS, but only
to a floppy (sigh). Also, don't disable floppy support in the BIOS, Q-flash
will just hang (sigh again).

The output from Q-flash is *almost* identical to the output that flashrom
generates right after running Q-flash (sorry, long lines):

--- qfl.rom.hd    2007-03-02 13:49:33.000000000 -0500
+++ test7.rom.hd  2007-03-02 13:49:23.000000000 -0500
@@ -360,7 +360,7 @@
 0000fd60  fe 7f eb 85 ff fc 5f 53  92 07 ef 95 f9 01 00 00 |......_S........|
 0000fd70  36 41 36 31 4a 47 30 34  aa 06 aa ff ff ff ff ff |6A61JG04........|
 0000fd80  44 65 66 61 75 6c 74 20  20 20 20 20 20 20 20 00 |Default        .|
-0000fd90  0f 00 24 00 12 00 00 02  03 07 00 00 40 00 00 00 |..$......... at ...|
+0000fd90  20 00 2d 00 12 00 00 02  03 07 00 00 40 00 00 00 | .-......... at ...|
 0000fda0  40 80 00 00 00 00 00 00  00 2f 2f 00 00 00 00 00 |@........//.....|
 0000fdb0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 |................|
 0000fdc0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 02 00 |................|

As you can see, a 2 bytes difference.

That's good news I think, it means that flashrom is probably doing the same
thing as Q-flash.

Datapoint 4:

Rebooting (warm, cold, or even with unplugging of power for 10 seconds) only
leads to 2 bytes of difference now between boots. For instance:

--- qfl.rom.hd  2007-03-02 13:49:33.000000000 -0500
+++ test8.rom.hd        2007-03-02 13:58:24.000000000 -0500
@@ -360,7 +360,7 @@
 0000fd60  fe 7f eb 85 ff fc 5f 53  92 07 ef 95 f9 01 00 00 |......_S........|
 0000fd70  36 41 36 31 4a 47 30 34  aa 06 aa ff ff ff ff ff |6A61JG04........|
 0000fd80  44 65 66 61 75 6c 74 20  20 20 20 20 20 20 20 00 |Default        .|
-0000fd90  0f 00 24 00 12 00 00 02  03 07 00 00 40 00 00 00 |..$......... at ...|
+0000fd90  0d 00 38 00 12 00 00 02  03 07 00 00 40 00 00 00 |..8......... at ...|
 0000fda0  40 80 00 00 00 00 00 00  00 2f 2f 00 00 00 00 00 |@........//.....|
 0000fdb0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 |................|
 0000fdc0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 02 00 |................|

Datapoint 5:

These 2 bytes keep changing across boots. Every time. But that's all that
changes now. Other than enabling the floppy drive in the BIOS, and using
Q-flash, I really don't understand what's different now, and why there are
far fewer changes than 2 days ago.

What really confuses me though is that there are changes *at all*. I thought
that it was non-trivial to write (small) changes to ROM chips (the thing
about block writes), and that the number of writes before the chip fails is
fairly limited. Is this ROM chip really being reprogrammed every single time
the machine boots?

Finally, of course, the following questions remain: why are there changes,
why is the changing data not stored in CMOS, and what exactly is being
recorded?

I have not yet tried to burn the flashrom/q-flash image back into the chip;
need to debug a bios-savior problem first.

Any insights would be greatly appreciated.

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator




More information about the coreboot mailing list