[LinuxBIOS] mcp55 flashrom problem

[Carl-Daniel Hailfinger]

On 02.03.2007 20:42, Ward Vandewege wrote:
> 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.

Looks like shadowing is on.

> 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.

Looks like you read an uncompressed version of the BIOS with flashrom.
-> Shadowing is on.

> 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.

Yes, both programs don't disable shadowing.

> 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?

No, of course not. That would be too dangerous, so you can bet that shadowing
is on.

> 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?

Assume that you don't access the ROM, but a decompressed image in RAM.
Variables might be stored there, it makes perfect sense.

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

Don't. I am fairly sure it will lead to disaster.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/