Hi all,
Richard and I spent most of this evening chasing a suspected hardware problem that turned out to be not a hardware problem, but a flashrom problem.
Basically, I had made a copy of the rom with flashrom earlier today, and Richard soldered a PLCC socket onto our board this evening. After that, the board booted fine, but when reading out the rom image with flashrom again, it came up as slightly different - 115 bytes of difference out of 512K.
Eventually, we realized that the image we read out *changed after every boot*. We also diffed the image that is downloadable from Gigabyte of this particular BIOS revision, and it's nothing like what flashrom returns. While they are the same size, the flashrom copy looks like it is uncompressed (and only part of the real BIOS), while the downloadable image has hardly any recognizable strings in it - it's probably compressed somehow.
It looks like flashrom is not disabling shadow properly. This is probably related to my patch of earlier today that added a new pci id for this particular board's MCP55 (0x0360). Flashrom only knew about 0x0364 and 0x0367 for the MCP55.
I also saw a patch from Ed Swierk a couple of weeks ago, which added a whole bunch of PCI ids for the MCP55 (among which the 0x0360), but was never applied to the tree.
Can someone who knows the MCP55 have a look at the enable_flash_mcp55 function in flash_enable.c and figure out what's wrong?
Yinghai, can you tell us which board(s) you've tested the enable_flash_mcp55 function on?
Thanks, Richard and Ward.
On 2/28/07, Ward Vandewege ward@gnu.org wrote:
It looks like flashrom is not disabling shadow properly. This is probably related to my patch of earlier today that added a new pci id for this particular board's MCP55 (0x0360). Flashrom only knew about 0x0364 and 0x0367 for the MCP55.
I also saw a patch from Ed Swierk a couple of weeks ago, which added a whole bunch of PCI ids for the MCP55 (among which the 0x0360), but was never applied to the tree.
Can someone who knows the MCP55 have a look at the enable_flash_mcp55 function in flash_enable.c and figure out what's wrong?
Yinghai, can you tell us which board(s) you've tested the enable_flash_mcp55 function on?
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.
--Ed
On Wed, Feb 28, 2007 at 09:11:21PM -0800, Ed Swierk wrote:
On 2/28/07, Ward Vandewege ward@gnu.org wrote:
It looks like flashrom is not disabling shadow properly. This is probably related to my patch of earlier today that added a new pci id for this particular board's MCP55 (0x0360). Flashrom only knew about 0x0364 and 0x0367 for the MCP55.
I also saw a patch from Ed Swierk a couple of weeks ago, which added a whole bunch of PCI ids for the MCP55 (among which the 0x0360), but was never applied to the tree.
Can someone who knows the MCP55 have a look at the enable_flash_mcp55 function in flash_enable.c and figure out what's wrong?
Yinghai, can you tell us which board(s) you've tested the enable_flash_mcp55 function on?
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)?
Flashrom doesn't crash or anything here, and it might just *write* fine (not tested yet), but reading gives the wrong data. We know, because we got the ID for the chip back, that at least a couple of writes to the chip succeeded.
Thanks, Ward.
On 2/28/07, Ward Vandewege ward@gnu.org wrote:
So, you've verified that the image that flashrom reads matches what you can download from the manufacturers website (extracted)?
Flashrom doesn't crash or anything here, and it might just *write* fine (not tested yet), but reading gives the wrong data. We know, because we got the ID for the chip back, that at least a couple of writes to the chip succeeded.
I used flashrom several months ago to read the vendor's BIOS. I did not actually compare it against the one posted on their web site, but I thought the contents looked plausible when I went grepping through it for strings.
I can give it another try when I get my hands on the DFI board again next week.
--Ed
Ed Swierk wrote:
I used flashrom several months ago to read the vendor's BIOS. I did not actually compare it against the one posted on their web site, but I thought the contents looked plausible when I went grepping through it for strings.
I can give it another try when I get my hands on the DFI board again next week.
That's exactly what we thought as well. The de-compressed code in RAM has loads of bios type strings in it.
But all most all the bios these days are compressed. So a copy of whats _actually_ in the ROM should have very little in the way of strings.
Ward Vandewege wrote:
So, you've verified that the image that flashrom reads matches what you can download from the manufacturers website (extracted)?
There will often be small differences between those, too. ie. in the "DMI area".
Flashrom doesn't crash or anything here, and it might just *write* fine (not tested yet), but reading gives the wrong data.
Don't try it unless reading works reliably. Writing "requires reading" for the write to work. (It polls for the data to "arrive" in the chip")
We know, because we got the ID for the chip back, that at least a couple of writes to the chip succeeded.
Weird. This is a pretty good sign that shadowing is disabled, normally.
Maybe not all of shadowing is disabled? only half the chip?
On Thu, Mar 01, 2007 at 11:40:28AM +0100, Stefan Reinauer wrote:
Ward Vandewege wrote:
So, you've verified that the image that flashrom reads matches what you can download from the manufacturers website (extracted)?
There will often be small differences between those, too. ie. in the "DMI area".
Sure. This one was entirely different.
Flashrom doesn't crash or anything here, and it might just *write* fine (not tested yet), but reading gives the wrong data.
Don't try it unless reading works reliably. Writing "requires reading" for the write to work. (It polls for the data to "arrive" in the chip")
Yeah, sure.
We know, because we got the ID for the chip back, that at least a couple of writes to the chip succeeded.
Weird. This is a pretty good sign that shadowing is disabled, normally.
Maybe not all of shadowing is disabled? only half the chip?
I really don't know. I'm glad we caught this bug though - given that this board doesn't have a socket (at least in the rev that we have), it might have led to a nasty surprise for someone.
Thanks, Ward.
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.
Do they differ, too?
Uwe.
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 |..$.........@...| +0000fd90 20 00 2d 00 12 00 00 02 03 07 00 00 40 00 00 00 | .-.........@...| 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 |..$.........@...| +0000fd90 0d 00 38 00 12 00 00 02 03 07 00 00 40 00 00 00 |..8.........@...| 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.
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 |..$.........@...| +0000fd90 20 00 2d 00 12 00 00 02 03 07 00 00 40 00 00 00 | .-.........@...| 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 |..$.........@...| +0000fd90 0d 00 38 00 12 00 00 02 03 07 00 00 40 00 00 00 |..8.........@...| 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
On Fri, Mar 02, 2007 at 08:57:12PM +0100, Carl-Daniel Hailfinger wrote:
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.
So, let's assume that's the case.
The Q-flash tool - built into the proprietary bios - also has 'restore' functionality.
So; if I would attempt to 'restore' the copy of the BIOS I made with Q-flash, I would have a brick? Or perhaps those 2 bytes don't matter for proper operation of the machine?
No, of course not. That would be too dangerous, so you can bet that shadowing is on.
I guess that means that flashrom needs fixing. Can someone who knows MCP55 chime in?
Thanks, Ward.
can you yank the FLASH part and try the same game in another machine.
ron
On Fri, Mar 02, 2007 at 01:58:39PM -0700, ron minnich wrote:
can you yank the FLASH part and try the same game in another machine.
OK, I've used flashrom/biossavior on a Tyan box to get the *actual* contents of the chip (I hope!).
This one is 3 bytes different from the q-flash image (or any of the flashrom images made on the gigabyte board itself):
--- qfl.rom.hd 2007-03-02 13:49:33.000000000 -0500 +++ tyan_created.rom.hd 2007-03-02 16:39:21.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 |..$.........@...| +0000fd90 23 00 22 00 14 00 00 02 03 07 00 00 40 00 00 00 |#.".........@...| 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 |................|
I didn't notice that change in 0000fd94 in the previous diffs, so it's basically the same phenomenon as with flashrom on the gigabyte machine itself - 3 bytes change between boots.
So.... are flashrom and Q-flash doing the right thing (disabling shadowing), and if so, what's causing those 3 bytes to be different each time?
Thanks, Ward.
What i am not sure of: I had heard that bios vendors were going to start writing data to flash on each boot, since CMOS is so constrained. I wonder if this is part of it.
ron
* Ward Vandewege ward@gnu.org [070302 22:47]:
OK, I've used flashrom/biossavior on a Tyan box to get the *actual* contents of the chip (I hope!).
I didn't notice that change in 0000fd94 in the previous diffs, so it's basically the same phenomenon as with flashrom on the gigabyte machine itself
- 3 bytes change between boots.
Between _every_ boot? How do the bytes change every time in 5 boots? Are bytes just increasing?
So.... are flashrom and Q-flash doing the right thing (disabling shadowing), and if so, what's causing those 3 bytes to be different each time?
Yes, shadow handling seems to work fine. The BIOS has _some_ reason to change it's config (which is far bigger than the 256 bytes of nvram nowadays, --> ESCD/DMI)
Have you changed the configuration of the machine? (Enable/Disable Floppy, ...?)
Can you please observe the changes over several consequtive reboots (5 or so)
On Sat, Mar 03, 2007 at 07:09:15PM +0100, Stefan Reinauer wrote:
- Ward Vandewege ward@gnu.org [070302 22:47]:
OK, I've used flashrom/biossavior on a Tyan box to get the *actual* contents of the chip (I hope!).
I didn't notice that change in 0000fd94 in the previous diffs, so it's basically the same phenomenon as with flashrom on the gigabyte machine itself
- 3 bytes change between boots.
Between _every_ boot?
From limited observation so far (3 or 4 boots), yes.
How do the bytes change every time in 5 boots? Are bytes just increasing?
So.... are flashrom and Q-flash doing the right thing (disabling shadowing), and if so, what's causing those 3 bytes to be different each time?
Yes, shadow handling seems to work fine. The BIOS has _some_ reason to change it's config (which is far bigger than the 256 bytes of nvram nowadays, --> ESCD/DMI)
Have you changed the configuration of the machine? (Enable/Disable Floppy, ...?)
I have not changed anything after enabling the floppy - and 3 bytes change every boot, indeed.
Can you please observe the changes over several consequtive reboots (5 or so)
I will do that Monday or Tuesday, and report back.
Thanks, Ward.
On Sat, Mar 03, 2007 at 07:09:15PM +0100, Stefan Reinauer wrote:
- Ward Vandewege ward@gnu.org [070302 22:47]:
OK, I've used flashrom/biossavior on a Tyan box to get the *actual* contents of the chip (I hope!).
Yes, shadow handling seems to work fine. The BIOS has _some_ reason to change it's config (which is far bigger than the 256 bytes of nvram nowadays, --> ESCD/DMI)
Can you please observe the changes over several consequtive reboots (5 or so)
This is it. The first line is the 'baseline' - the image I retrieved with the proprietary in-bios qflash tool, last Friday. All the other lines are consecutive reboots today; I wrote a script to dump the flash with flashrom, diff it, and reboot - each of these lines is roughly a couple of minutes apart.
-0000fd90 0f 00 24 00 12 00 00 02 03 07 00 00 40 00 00 00 +0000fd90 0a 00 00 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 16 00 1c 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 14 00 25 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 14 00 27 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 08 00 29 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 39 00 2a 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 2e 00 2c 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 16 00 31 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 0b 00 33 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 00 00 35 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 32 00 36 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 28 00 38 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 0e 00 3b 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 36 00 02 00 10 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 2c 00 04 00 10 00 00 05 03 07 00 00 40 00 00 00
What do you make of this?
Thanks, Ward.
On 05.03.2007 17:37, Ward Vandewege wrote:
On Sat, Mar 03, 2007 at 07:09:15PM +0100, Stefan Reinauer wrote:
Can you please observe the changes over several consequtive reboots (5 or so)
This is it. The first line is the 'baseline' - the image I retrieved with the proprietary in-bios qflash tool, last Friday. All the other lines are consecutive reboots today; I wrote a script to dump the flash with flashrom, diff it, and reboot - each of these lines is roughly a couple of minutes apart.
-0000fd90 0f 00 24 00 12 00 00 02 03 07 00 00 40 00 00 00
^^ ^^ ^^ ^^ || || || unknown || || ++-most significant byte of counter || ++-medium significant byte of counter ++-least significant byte of counter
+0000fd90 0a 00 00 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 16 00 1c 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 14 00 25 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 14 00 27 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 08 00 29 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 39 00 2a 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 2e 00 2c 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 16 00 31 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 0b 00 33 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 00 00 35 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 32 00 36 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 28 00 38 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 0e 00 3b 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 36 00 02 00 10 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 2c 00 04 00 10 00 00 05 03 07 00 00 40 00 00 00
What do you make of this?
A counter with 6 bits per byte and one unknown byte. Note how no value is >=0x40 and a wraparound of the second value increases the third value by 1? Could be a timer, e.g. boot time or something like that. Try to correlate boot time intervals with the differences in the counter.
Regards, Carl-Daniel
A agree with Carl-Danial. A counter.
So we may have confirmed that BIOSes are moving to flash, as I have heard, due to CMOS limitations.
ron
On Mon, Mar 05, 2007 at 05:53:52PM +0100, Carl-Daniel Hailfinger wrote:
-0000fd90 0f 00 24 00 12 00 00 02 03 07 00 00 40 00 00 00
^^ ^^ ^^ ^^ || || || unknown
[...]
+0000fd90 0a 00 00 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 16 00 1c 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 14 00 25 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 14 00 27 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 08 00 29 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 39 00 2a 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 2e 00 2c 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 16 00 31 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 0b 00 33 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 00 00 35 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 32 00 36 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 28 00 38 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 0e 00 3b 00 0f 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 36 00 02 00 10 00 00 05 03 07 00 00 40 00 00 00 +0000fd90 2c 00 04 00 10 00 00 05 03 07 00 00 40 00 00 00
^^ boot status?
I'm just guessing, but 02 could mean "cold boot", 05 "warm boot"?
Uwe.
On Mon, Mar 05, 2007 at 05:53:52PM +0100, Carl-Daniel Hailfinger wrote:
A counter with 6 bits per byte and one unknown byte. Note how no value is >=0x40 and a wraparound of the second value increases the third value by 1? Could be a timer, e.g. boot time or something like that. Try to correlate boot time intervals with the differences in the counter.
-0000fd90 0f 00 24 00 12 00 00 02 03 07 00 00 40 00 00 00 2007-03-05 10:17 +0000fd90 0a 00 00 00 0f 00 00 05 03 07 00 00 40 00 00 00 2007-03-05 10:29 +0000fd90 16 00 1c 00 0f 00 00 05 03 07 00 00 40 00 00 00 2007-03-05 10:38 +0000fd90 14 00 25 00 0f 00 00 05 03 07 00 00 40 00 00 00 2007-03-05 10:40 +0000fd90 14 00 27 00 0f 00 00 05 03 07 00 00 40 00 00 00 2007-03-05 10:42 +0000fd90 08 00 29 00 0f 00 00 05 03 07 00 00 40 00 00 00 2007-03-05 10:43 +0000fd90 39 00 2a 00 0f 00 00 05 03 07 00 00 40 00 00 00 2007-03-05 10:48 +0000fd90 2e 00 2c 00 0f 00 00 05 03 07 00 00 40 00 00 00 2007-03-05 10:50 +0000fd90 16 00 31 00 0f 00 00 05 03 07 00 00 40 00 00 00 2007-03-05 10:52 +0000fd90 0b 00 33 00 0f 00 00 05 03 07 00 00 40 00 00 00 2007-03-05 10:53 +0000fd90 00 00 35 00 0f 00 00 05 03 07 00 00 40 00 00 00 2007-03-05 10:55 +0000fd90 32 00 36 00 0f 00 00 05 03 07 00 00 40 00 00 00 2007-03-05 10:57 +0000fd90 28 00 38 00 0f 00 00 05 03 07 00 00 40 00 00 00 2007-03-05 11:00 +0000fd90 0e 00 3b 00 0f 00 00 05 03 07 00 00 40 00 00 00 2007-03-05 11:02 +0000fd90 05 00 01 00 10 00 00 05 03 07 00 00 40 00 00 00 2007-03-05 11:03 +0000fd90 36 00 02 00 10 00 00 05 03 07 00 00 40 00 00 00 2007-03-05 11:05 +0000fd90 2c 00 04 00 10 00 00 05 03 07 00 00 40 00 00 00 2007-03-05 13:01 +0000fd90 22 00 3b 00 11 00 00 05 03 07 00 00 40 00 00 00
These timestamps are the ones of the rom files; the actual boot time would be 30-60 seconds earlier.
The boot at 2007-03-05 10:17 was a cold boot.
The boot at 2007-03-05 11:00 was a cold boot.
The boot at 2007-03-05 13:01 was a *really* cold boot: I unplugged power, waited 10 seconds, and then replugged and started the machine.
All other boots were warm boots.
Thanks, Ward.
On Mon, 5 Mar 2007, Ward Vandewege wrote:
On Mon, Mar 05, 2007 at 05:53:52PM +0100, Carl-Daniel Hailfinger wrote:
A counter with 6 bits per byte and one unknown byte. Note how no value is >=0x40 and a wraparound of the second value increases the third value by 1? Could be a timer, e.g. boot time or something like that. Try to correlate boot time intervals with the differences in the counter.
Hypothesis: boot or shutdown time in UTC and date (Ward's local time seems to be -0500 from UTC, translation to decimal below):
-0000fd90 0f 00 24 00 12 00 00 02 03 07 00 00 40 00 00 00
The baseline was last Friday, i.e 2007-03-02: 02 03 07
2007-03-05 10:17 +0000fd90 0a 00 00 00 0f 00 00 05 03 07 00 00 40 00 00 00
ss mm hh DD MM YY 10 00 15 05 05 07
2007-03-05 10:29 +0000fd90 16 00 1c 00 0f 00 00 05 03 07 00 00 40 00 00 00
22 28 15
2007-03-05 10:38 +0000fd90 14 00 25 00 0f 00 00 05 03 07 00 00 40 00 00 00
20 37 15
2007-03-05 10:40 +0000fd90 14 00 27 00 0f 00 00 05 03 07 00 00 40 00 00 00
20 39 15
2007-03-05 10:42 +0000fd90 08 00 29 00 0f 00 00 05 03 07 00 00 40 00 00 00
08 41 15
2007-03-05 10:43 +0000fd90 39 00 2a 00 0f 00 00 05 03 07 00 00 40 00 00 00
57 42 15
2007-03-05 10:48 +0000fd90 2e 00 2c 00 0f 00 00 05 03 07 00 00 40 00 00 00
46 44 15
2007-03-05 10:50 +0000fd90 16 00 31 00 0f 00 00 05 03 07 00 00 40 00 00 00
22 49 15
2007-03-05 10:52 +0000fd90 0b 00 33 00 0f 00 00 05 03 07 00 00 40 00 00 00
11 51 15
2007-03-05 10:53 +0000fd90 00 00 35 00 0f 00 00 05 03 07 00 00 40 00 00 00
00 53 15
2007-03-05 10:55 +0000fd90 32 00 36 00 0f 00 00 05 03 07 00 00 40 00 00 00
50 54 15
2007-03-05 10:57 +0000fd90 28 00 38 00 0f 00 00 05 03 07 00 00 40 00 00 00
40 56 15
2007-03-05 11:00 +0000fd90 0e 00 3b 00 0f 00 00 05 03 07 00 00 40 00 00 00
14 59 15
2007-03-05 11:02 +0000fd90 05 00 01 00 10 00 00 05 03 07 00 00 40 00 00 00
05 01 16
2007-03-05 11:03 +0000fd90 36 00 02 00 10 00 00 05 03 07 00 00 40 00 00 00
54 02 16
2007-03-05 11:05 +0000fd90 2c 00 04 00 10 00 00 05 03 07 00 00 40 00 00 00
44 04 16
2007-03-05 13:01 +0000fd90 22 00 3b 00 11 00 00 05 03 07 00 00 40 00 00 00
34 59 17
These timestamps are the ones of the rom files; the actual boot time would be 30-60 seconds earlier.
The boot at 2007-03-05 10:17 was a cold boot.
The boot at 2007-03-05 11:00 was a cold boot.
The boot at 2007-03-05 13:01 was a *really* cold boot: I unplugged power, waited 10 seconds, and then replugged and started the machine.
Was the down time (from shutdown to power on) like a few seconds/minutes or longer? I try to distinguish between last *shutdown* time and last *boot* time.
For the boot 2007-03-05 10:17, there is a 16 minute difference, if we interpret the numbers in the image as time in UTC, for 2007-03-05 10:48 a 4 minute difference, while for the others more like within one minute. This suggest that it could be correlated with last shutdown time.
A possible experiment to distinguish between shutdown and boot time could be to do dumps after a 10 minute shutdown and a 1 minute shutdown. If the interpreted time in the image differs by approximately 10 minutes in the first case, I believe we have shown it to be the shutdown time.
/ulf
2007-03-05 10:17 +0000fd90 0a 00 00 00 0f 00 00 05 03 07 00 00 40 00 00 00
ss mm hh DD MM YY 10 00 15 05 05 07 Typo. Should be: 10 00 15 05 03 07 /ulf
* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [070302 20:57]:
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.
I disagree. The shadowed copy is uncompressed, the shadow-off copy is compressed. Those two copies definitely have more than 100 bytes difference.
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.
Looks like Gigabyte encrypts their BIOS images?
All BIOS images are compressed in flash nowadays. LinuxBIOS is not particularly innovative here.
+++ test7.rom.hd 2007-03-02 13:49:23.000000000 -0500 @@ -360,7 +360,7 @@ -0000fd90 0f 00 24 00 12 00 00 02 03 07 00 00 40 00 00 00 |..$.........@...| +0000fd90 20 00 2d 00 12 00 00 02 03 07 00 00 40 00 00 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.
Rebooting (warm, cold, or even with unplugging of power for 10 seconds) only leads to 2 bytes of difference now between boots. For instance:
Did it say something like "Updating ESCD..." during boot?
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),
You would read a whole block (ie 256 bytes) and write it again, with 2 bytes changed. Nothing too complex.
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?
I would assume so. Current chips have an average of far more than 10000 cycles before failure. With 365 days a year, your machine will fail after 27 years if you reboot it every day. (Potentially not every reboot will change the flashrom) Or, if you would assume an average use time of 3 years for the system, 10 reboots every day. This is plenty.
Good question is what changed between the boots that made the bios rewrite parts of the flash.
Stefan
* Ward Vandewege ward@gnu.org [070302 20:42]:
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.
This is normal and no indication of shadowing problems. ESCD/DMI is changing very often.
Stefan
what is your Mem conf? 4G or 2G?
Kernel version?
YH
On Wed, Feb 28, 2007 at 10:02:55PM -0800, yhlu wrote:
what is your Mem conf? 4G or 2G?
2 gigabytes of RAM in this machine.
Kernel version?
It's the default Gnewsense kernel, which is a slightly modified Ubuntu Dapper 2.6.15 kernel.
Thanks, Ward.
-
Carl-Daniel Hailfinger -
Ed Swierk -
Richard Smith -
ron minnich -
Stefan Reinauer -
Stefan Reinauer -
Ulf Jordan -
Uwe Hermann -
Ward Vandewege -
yhlu