[flashrom] FAILED: FR597AA-AKD m9360.pl (FR597AA#AKD)
stefan.tauner at student.tuwien.ac.at
Tue Feb 14 11:35:11 CET 2012
On Tue, 14 Feb 2012 09:58:08 +0100
Mariusz Cygan <itcygan at gmail.com> wrote:
> flashrom -c W25X80 -w NT35.bin
> flashrom v0.9.4-r1394 on Linux 3.0.0-16-generic (x86_64), built with libpci
> 3.1.7, GCC 4.6.1, little endian
> flashrom is free software, get the source code at http://www.flashrom.org
> Calibrating delay loop... OK.
> Found chipset "NVIDIA MCP61".
> This chipset is marked as untested. If you are using an up-to-date version
> of flashrom please email a report to flashrom at flashrom.org including a
> verbose (-V) log. Thank you!
> Enabling flash write... This chipset is not really supported yet.
> SPI on this chipset is WIP. Please report any success or failure by mailing
> us the verbose output to flashrom at flashrom.org, thanks!
> Mapping NVIDIA MCP6x SPI at 0xfec80000, unaligned size 0x544.
> Please send the output of "flashrom -V" to flashrom at flashrom.org with
> your board name: flashrom -V as the subject to help us finish support for
> chipset. Thanks.
> This chipset supports the following protocols: SPI.
> Found Winbond flash chip "W25X80" (1024 kB, SPI) at physical address
> Flash image seems to be a legacy BIOS. Disabling coreboot-related checks.
> Reading old flash chip contents... done.
> Erasing and writing flash chip... Erase/write done.
> Verifying flash... VERIFY FAILED at 0x00011a00! Expected=0x05, Read=0xff,
> failed byte count from 0x00000000-0x000fffff: 0x1f8
> Your flash chip is in an unknown state.
> Get help on IRC at irc.freenode.net (channel #flashrom) or
> mail flashrom at flashrom.org with FAILED: your board name in the subject line!
> DO NOT REBOOT OR POWEROFF!
i am not very familiar with the chipset, so i cant really help by
fixing the problem. It seems that the addressing is somehow broken: I
know that because erase and write succeeds. It does only succeed, if it
can verify the contents of every block it wrote to be correct. After
the whole process it does read the whole chip again and checks if it
equals the image. Now if the addressing of the blocks wraps somewhere
then the erase/write code will overwrite some blocks without noticing
it (the block itself looks correct to it), but verification will fail
at the end. Someone will have to look at it later. They will probably
want to look at least at a verbose log, so please post the output of
flashrom -V (and additionally maybe even with -VVV). The output of lspci
-nnvvxxx (run as root) may also be useful.
To get your board back to a consistent state, you could try flashing
the backup you made with the -r/--read option (you DID make a backup,
right?). But i fear it may also fail... in that case or if you do not
have a backup please join IRC and most importantly: DO NOT REBOOT OR
POWER OFF! We really mean it.
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
More information about the flashrom