Helge,

 

Unable to recover the server that was corrupted yesterday. I’ve followed the procedures provided by Supermicro and I’m going to have to send back the server to be re-flashed. During my initial testing I back leveled the BIOS to 1.0B and with “flashrom” I was able to move the BIOS to version 1.1 and it boot just fine. My second test which caused the corrupted state was a change in a setting of the 1.1 BIOS (to ensure if an maintainer makes a BIOS change I can recover by loading up the original settings) and a reboot which work. When I reload 1.1 with the original settings it finished correctly but now I’m failing to boot?

 

Thanks again,

John

 

From: Johnson, Je
Sent: Tuesday, August 10, 2010 8:40 AM
To: 'Wagner, Helge (GE Intelligent Platforms)'
Cc: flashrom@flashrom.org
Subject: RE: [flashrom] Flashrom Issues

 

Helge,

 

Thanks for the information concerning the SPI ROMs errors. I’ll test the patch this morning and let you know the results. I’m still a little concerned that reloading the same BIOS and rebooting caused my server to stop booting and I’m not seeing any displays? I did run a verify after flashing the BIOS and everything seemed fine. I’m the OS technical lead here in Manassas and I support over 12 different programs. I’m pushing to start using the “flashrom” program for all of our BIOS updates (as long as the motherboards are supported).

 

It’s time we get away from the floppy/CD solution of installing and updating the BIOS.

 

Thanks again,

John

 

From: Wagner, Helge (GE Intelligent Platforms) [mailto:Helge.Wagner@ge.com]
Sent: Tuesday, August 10, 2010 2:53 AM
To: Johnson, Je
Cc: flashrom@flashrom.org
Subject: EXTERNAL: RE: [flashrom] Flashrom Issues

 

You can ignore these "spi_block_erase_xx failed" errors as for the SPI ROMs there are some erase functions defined (with different block sizes), and when at least one of them is successful, the erase will finally work.

And as you told it stated that it was successfully, so what you have in the flash should be the same as in the file.

 

Can you try to clear the RTC/CMOS RAM? (remove battery for 10 minutes, use a jumper if available, see manual)?

If that doesn't help: follow the procedure outlined in the "AMI BIOS Recovery" manual at http://www.supermicro.com/support/manuals/

 

 

Some additional notes about the erase error messages:

The errors occur because on the ICH SPI engines you have to program a list of supported commands. This list is filled at program start with the most common SPI commands, and if one of the commands used by the erase functions is not in this list, this specific erase will fail (but as told before: one of the erase functions defined for your SPI flash chips should work).

I have created a patch to dynamically re-program the list of supported commands on-the-fly, so that no command should fail after the patch is applied. You can find the patch here: http://www.flashrom.org/pipermail/flashrom/2010-August/004331.html ("[flashrom] Speedup SST 25VF032B and 25VF064C programming").

 

Regards,

Helge

 


From: flashrom-bounces@flashrom.org [mailto:flashrom-bounces@flashrom.org] On Behalf Of Johnson, Je
Sent: Montag, 9. August 2010 21:38
To: flashrom@flashrom.org
Subject: [flashrom] Flashrom Issues

I’ve been working with a Supermicro X8DA3/DAI mother board running with RHEL ES 5.4 (2.6.30.9). I compiled the latest version of “flashrom 0.9.2) and was able to capture my current BIOS by running “flashrom –r X8DA3.BIOS”. After capturing the BIOS I reloaded it by issuing the following command “flashrom –w X8DA3.BIOS”. I was told that the write was successful, but saw the following errors:

 

Writing flash chip… Erasing flash before programming Erasing Flash Chip… spi_block_erase_20 failed during command execution at address 0x0

Spi_block_erase_52 failed during command execution at address 0x0

 

Since it stated that it was successfully, I simply reset the server and now it’s failing to boot?

 

Any help in understanding in what went wrong or if my motherboard is not fully support ( I did run the check initially to ensure the chipset was support).

 

Thanks,

John Johnson

Lockheed Martin

Manassas, VA