After many months of testing, and 5 months after tagging the release, we are happy to announce that flashrom 0.9.1 is ready for your machines.
flashrom is a utility for reading, writing, erasing and verifying flash ROM chips on mainboards, SATA/network controller cards and external programmers.
flashrom is often used to flash BIOS/EFI/coreboot/firmware images because it allows you to update your BIOS/EFI/coreboot/firmware without opening the computer and without any special boot procedures.
After nine years of development and constant improvement, we have added support for every BIOS flash ROM technology present on x86 mainboards and every flash ROM chip we ever saw in the wild.
Highlights of flashrom include:
* Parallel, LPC, FWH and SPI flash interfaces. * Support for on-mainboard programming and external programmers. * 192 flash chip families and half a dozen variants of each family. * Flash chip package agnostic. DIP32, PLCC32, DIP8, SO8/SOIC8, TSOP32, TSOP40 and more have all been verified to work. * 78 different chipsets, some with multiple flash controllers. * Special mainboard enabling code for dozens of nonstandard mainboards. * No physical access needed. root access is sufficient. * No bootable floppy disk, bootable CD-ROM or other media needed. * No keyboard or monitor needed. Simply reflash remotely via SSH. * No instant reboot needed. Reflash your ROM in a running system, verify it, be happy. The new firmware will be present next time you boot. * Crossflashing and hotflashing is possible as long as the flash chips are electrically and logically compatible (same protocol). Great for recovery. * Scriptability. Reflash a whole pool of identical machines at the same time from the command line. It is recommended to check flashrom output and error codes. * Speed. flashrom is much faster than vendor flash tools. * Supports Linux, FreeBSD, DragonFly BSD, Nexenta, Solaris, Mac OS X. Please refer to the README for build instructions.
Thanks go to everyone who contributed to flashrom over the years.
Please note that rewriting your flash chip can be dangerous and flashrom developers make no guarantees whatsoever. That said, many users have successfully replaced proprietary tools such as awdflash, amiflash and afudos with flashrom.
If you have a laptop, we advise against using flashrom for now. Many laptops share their flash chip between the main CPU and an undocumented embedded controller which may crash the machine during flashing. This will be addressed once we manage to get docs for those embedded controllers.
flashrom has its own home page at http://www.flashrom.org/
You can see a list of downloads at http://www.flashrom.org/Downloads
New major user-visible features include:
* 3Com NICs flashing * Silicon Image SATA controller flashing * ITE IT87* SuperI/O SPI flashing * FT2232H/FT4232H based SPI external programmer support * Universal external programmer protocol * AVR based external programmer support attached via serial line * Dummy flasher driver to trace execution * Automatic write/erase verification * Dozens of added flash chips * Support for new chipsets * Support for new boards * Fast bus type dependent probing * No root privileges needed for most external flashers
Infrastructural improvements and fixes:
* External flasher infrastructure * Improved SPI abstraction * SPI multicommand infrastructure * Partial read support infrastructure * Accurate timing information for probing * Tarball export target * User interface cleanup * Block protection printing for more chips * Probing accuracy improvements for old SPI chips on ICH * MMIO abstraction layer * Chip access abstraction layer * More intelligent error handling for ICH/VIA SPI * Fix corner case SB600 SPI hangs on non-SPI boards * Downgrade to byte program for certain chip families because they don't support page program * Detection of no-ID responses from chips * Elan SC520 runtime detection * 100x speedup for writes to some SPI chips * Improved error messages * Correctness fixes * Various workarounds for broken hardware * Code cleanups
Hi,
not much more information yet, but I suggest everyone be careful with this release due to work on generalization and restructure that has been done. The Winbond W39V080FA is the first chip tried here and writing fails with flashrom 0.9.1. It worked with 0.9.0. So everyone should take the missing test flags very seriously.
Best regards,
Stefan Reinauer
On 03.02.2010 17:17, Stefan Reinauer wrote:
not much more information yet, but I suggest everyone be careful with this release due to work on generalization and restructure that has been done. The Winbond W39V080FA is the first chip tried here and writing fails with flashrom 0.9.1. It worked with 0.9.0. So everyone should take the missing test flags very seriously.
Did you test with svn or the (5 months old) 0.9.1 release? I just checked the difference between 0.9.0 and 0.9.1 for the W39V080FA and there isn't any.
If you tested with svn, can you please provide a verbose log? I'm aware that locking/unlocking is basically non-working with current svn and that might be the reason you see the failure. Patch pending.
Regards, Carl-Daniel
On 2/3/10 5:34 PM, Carl-Daniel Hailfinger wrote:
On 03.02.2010 17:17, Stefan Reinauer wrote:
not much more information yet, but I suggest everyone be careful with this release due to work on generalization and restructure that has been done. The Winbond W39V080FA is the first chip tried here and writing fails with flashrom 0.9.1. It worked with 0.9.0. So everyone should take the missing test flags very seriously.
Did you test with svn or the (5 months old) 0.9.1 release? I just checked the difference between 0.9.0 and 0.9.1 for the W39V080FA and there isn't any.
Oh, I assumed that r889 is 0.9.1 ... ? Now I am confused.
If you tested with svn, can you please provide a verbose log? I'm aware that locking/unlocking is basically non-working with current svn and that might be the reason you see the failure. Patch pending.
Will try. It's most likely a timing issue, as the driver was switched from the winbond specific flash code to the generic jedec flash code with timings that don't seem to match what the data sheets or the hardware assume.
Stefan
On 03.02.2010 17:38, Stefan Reinauer wrote:
On 2/3/10 5:34 PM, Carl-Daniel Hailfinger wrote:
On 03.02.2010 17:17, Stefan Reinauer wrote:
not much more information yet, but I suggest everyone be careful with this release due to work on generalization and restructure that has been done. The Winbond W39V080FA is the first chip tried here and writing fails with flashrom 0.9.1. It worked with 0.9.0. So everyone should take the missing test flags very seriously.
Did you test with svn or the (5 months old) 0.9.1 release? I just checked the difference between 0.9.0 and 0.9.1 for the W39V080FA and there isn't any.
Oh, I assumed that r889 is 0.9.1 ... ? Now I am confused.
flashrom 0.9.1 was tagged 5 months ago, but we never got around to sending out a release announcement. Now I finally found some spare time to send out that announcement, and it already generated some publicity. Plus, 0.9.2-rc1 is just around the corner and some raised awareness about flashrom is very useful.
If you tested with svn, can you please provide a verbose log? I'm aware that locking/unlocking is basically non-working with current svn and that might be the reason you see the failure. Patch pending.
Will try. It's most likely a timing issue, as the driver was switched from the winbond specific flash code to the generic jedec flash code with timings that don't seem to match what the data sheets or the hardware assume.
Thanks. Not so long ago, I fixed a timing issue on Winbond after we were puzzled for a long time why erase had not completed although JEDEC toggle stopped. This may or may not be related.
Ummm... is there any guarantee that ACPI and SMM won't access the ROM chip? If not, we need a more resilient (slower) JEDEC toggle routine.
Regards, Carl-Daniel
On 2/3/10 11:13 PM, Carl-Daniel Hailfinger wrote:
If you tested with svn, can you please provide a verbose log? I'm aware that locking/unlocking is basically non-working with current svn and that might be the reason you see the failure. Patch pending.
Will try. It's most likely a timing issue, as the driver was switched from the winbond specific flash code to the generic jedec flash code with timings that don't seem to match what the data sheets or the hardware assume.
Thanks. Not so long ago, I fixed a timing issue on Winbond after we were puzzled for a long time why erase had not completed although JEDEC toggle stopped. This may or may not be related.
Ummm... is there any guarantee that ACPI and SMM won't access the ROM chip? If not, we need a more resilient (slower) JEDEC toggle routine.
Yes; It's definitely a flashrom issue. Old revisions work, and the SMM handler nor ACPI is not active.
Here's a failure log for a starter
Am Donnerstag, den 04.02.2010, 00:12 +0100 schrieb Stefan Reinauer:
Here's a failure log for a starter
Problem is obvious. In svn r868, where the Winbond chips were changed to standard JEDEC procedures the unlocking code (call to unlock_winbond_fwhub in erase_winbond_fwhub) got lost. This applies to w39v080fa in standard mode and in dual partition mode. As the chip is no longer unlocked, erase doesn't work. Write would fail, too.
Regards, Michael Karcher
On 2/4/10 12:27 AM, Michael Karcher wrote:
Am Donnerstag, den 04.02.2010, 00:12 +0100 schrieb Stefan Reinauer:
Here's a failure log for a starter
Problem is obvious. In svn r868, where the Winbond chips were changed to standard JEDEC procedures the unlocking code (call to unlock_winbond_fwhub in erase_winbond_fwhub) got lost. This applies to w39v080fa in standard mode and in dual partition mode. As the chip is no longer unlocked, erase doesn't work. Write would fail, too.
Regards, Michael Karcher
I can verify that this is the case.
The attached hack fixes erase for me.
-
Carl-Daniel Hailfinger -
Michael Karcher -
Stefan Reinauer