February 2012 - flashrom - mail.coreboot.org

FAILED: AXIOMTEK PICO821 REV:A2-RC
by Recovery.se Feb. 9, 2012

Feb. 9, 2012

Hello I'm very pleased with flashrom! Hovever we have a problem erasing. I can work around it by running erase (flashrom -E) sevral times and then flash with (flashrom -w <rom>). When I run errase the falure posision moves forward .. "ERASE FAILED at 0x00030000!" "ERASE FAILED at 0x00040000!" "ERASE FAILED at 0x000ef000!" ... Regards Eric Eriksson Recovery.se

1 0

Re: [flashrom] r1394: Acer Aspire E380: FAILED : mcp61sm -am
by Paul Menzel Feb. 9, 2012

Feb. 9, 2012

Dear Vince, Am Donnerstag, den 09.02.2012, 14:03 +0100 schrieb Vince S: > This is curious because it is always possible to clear the bios : > > vince@Bob:~$ sudo flashrom -VE > flashrom v0.9.4-r1394 on Linux 3.0.0-15-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 I did not follow the thread closely, but is that version not too old? Maybe try the latest revision from the Subversion repository? […] Thanks, Paul

1 0

Re: [flashrom] FAILED : mcp61sm -am
by Stefan Tauner Feb. 9, 2012

Feb. 9, 2012

On Thu, 9 Feb 2012 08:25:51 +0100 Vince S <vince06fr(a)gmail.com> wrote: > Hi so the output of my attempt to flash is > > sudo flashrom -V -w '/home/vince/Téléchargements/BIOS_R01-C0/61AO615.BIN' > > flashrom v0.9.4-r1394 on Linux 3.0.0-15-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... OS timer resolution is 1 usecs, 736M loops per > second, 10 myus = 11 us, 100 myus = 101 us, 1000 myus = 1007 us, 10000 myus > = 10003 us, 4 myus = 5 us, OK. > Initializing internal programmer > No coreboot table found. > DMI string system-manufacturer: "Acer" > DMI string system-product-name: "Aspire E380" > DMI string system-version: "R01-A2" > DMI string baseboard-manufacturer: "Acer" > DMI string baseboard-product-name: "EM61SM/EM61PM " > DMI string baseboard-version: " " > DMI string chassis-type: "Desktop" > Found ITE Super I/O, ID 0x8726 on port 0x2e > Found chipset "NVIDIA MCP61" with PCI ID 10de:03e0. > This chipset is marked as untested. If you are using an up-to-date version > of flashrom please email a report to flashrom(a)flashrom.org including a > verbose (-V) log. Thank you! > Enabling flash write... This chipset is not really supported yet. > Guesswork... > ISA/LPC bridge reg 0x8a contents: 0x00, bit 6 is 0, bit 5 is 0 > Flash bus type is LPC > Found SMBus device 10de:03eb at 00:01:1 > MCP SPI BAR is at 0xfec80000 > Strange. MCP SPI BAR is valid, but chipset apparently doesn't have SPI > enabled. > Please send the output of "flashrom -V" to flashrom(a)flashrom.org with > your board name: flashrom -V as the subject to help us finish support for > your > chipset. Thanks. > OK. > This chipset supports the following protocols: LPC. > Super I/O ID 0x8726 is not on the list of flash capable controllers. > Probing for AMIC A49LF040A, 512 kB: probe_jedec_common: id1 0xbf, id2 0x50 > Probing for PMC Pm49FL002, 256 kB: probe_jedec_common: id1 0xbf, id2 0x50 > Probing for PMC Pm49FL004, 512 kB: probe_jedec_common: id1 0xbf, id2 0x50 > Probing for SST SST49LF020, 256 kB: probe_jedec_common: id1 0xbf, id2 0x50 > Probing for SST SST49LF020A, 256 kB: probe_jedec_common: id1 0xbf, id2 0x50 > Probing for SST SST49LF040, 512 kB: probe_jedec_common: id1 0xbf, id2 0x50 > Probing for SST SST49LF040B, 512 kB: probe_jedec_common: id1 0xbf, id2 0x50 > Found SST flash chip "SST49LF040B" (512 kB, LPC) at physical address > 0xfff80000. > […] > === > This flash part has status UNTESTED for operations: WRITE > The test status of this chip may have been updated in the latest development > version of flashrom. If you are running the latest development version, > please email a report to flashrom(a)flashrom.org if any of the above > operations > work correctly for you with this flash part. Please include the flashrom > output with the additional -V option for all operations you tested (-V, -Vr, > -Vw, -VE), and mention which mainboard or programmer you tested. > Please mention your board in the subject line. Thanks for your help! > Flash image seems to be a legacy BIOS. Disabling coreboot-related checks. > Reading old flash chip contents... done. > Erasing and writing flash chip... Trying erase function 0... > 0x000000-0x000fff:W, 0x001000-0x001fff:S, 0x002000-0x002fff:S, > 0x003000-0x003fff:S, 0x004000-0x004fff:S, 0x005000-0x005fff:S, > 0x006000-0x006fff:S, 0x007000-0x007fff:S, 0x008000-0x008fff:S, > 0x009000-0x009fff:S, 0x00a000-0x00afff:S, 0x00b000-0x00bfff:S, > 0x00c000-0x00cfff:S, 0x00d000-0x00dfff:S, 0x00e000-0x00efff:S, > 0x00f000-0x00ffff:S, 0x010000-0x010fff:W, 0x011000-0x011fff:W, > 0x012000-0x012fff:W, 0x013000-0x013fff:W, 0x014000-0x014fff:W, > 0x015000-0x015fff:W, 0x016000-0x016fff:W, 0x017000-0x017fff:W, > 0x018000-0x018fff:W, 0x019000-0x019fff:W, 0x01a000-0x01afff:W, > 0x01b000-0x01bfff:W, 0x01c000-0x01cfff:W, 0x01d000-0x01dfff:W, > 0x01e000-0x01efff:W, 0x01f000-0x01ffff:W, 0x020000-0x020fff:W, > 0x021000-0x021fff:W, 0x022000-0x022fff:W, 0x023000-0x023fff:W, > 0x024000-0x024fff:W, 0x025000-0x025fff:W, 0x026000-0x026fff:W, > 0x027000-0x027fff:W, 0x028000-0x028fff:W, 0x029000-0x029fff:W, > 0x02a000-0x02afff:W, 0x02b000-0x02bfff:W, 0x02c000-0x02cfff:W, > 0x02d000-0x02dfff:W, 0x02e000-0x02efff:W, 0x02f000-0x02ffff:W, > 0x030000-0x030fff:W, 0x031000-0x031fff:W, 0x032000-0x032fff:W, > 0x033000-0x033fff:W, 0x034000-0x034fff:W, 0x035000-0x035fff:W, > 0x036000-0x036fff:W, 0x037000-0x037fff:W, 0x038000-0x038fff:W, > 0x039000-0x039fff:W, 0x03a000-0x03afff:W, 0x03b000-0x03bfff:W, > 0x03c000-0x03cfff:W, 0x03d000-0x03dfff:W, 0x03e000-0x03efff:W, > 0x03f000-0x03ffff:W, 0x040000-0x040fff:W, 0x041000-0x041fff:W, > 0x042000-0x042fff:W, 0x043000-0x043fff:W, 0x044000-0x044fff:W, > 0x045000-0x045fff:W, 0x046000-0x046fff:W, 0x047000-0x047fff:W, > 0x048000-0x048fff:W, 0x049000-0x049fff:W, 0x04a000-0x04afff:W, > 0x04b000-0x04bfff:W, 0x04c000-0x04cfff:W, 0x04d000-0x04dfff:W, > 0x04e000-0x04efff:W, 0x04f000-0x04ffff:W, 0x050000-0x050fff:W, > 0x051000-0x051fff:W, 0x052000-0x052fff:W, 0x053000-0x053fff:W, > 0x054000-0x054fff:W, 0x055000-0x055fff:W, 0x056000-0x056fff:S, > 0x057000-0x057fff:S, 0x058000-0x058fff:S, 0x059000-0x059fff:S, > 0x05a000-0x05afff:S, 0x05b000-0x05bfff:S, 0x05c000-0x05cfff:S, > 0x05d000-0x05dfff:S, 0x05e000-0x05efff:S, 0x05f000-0x05ffff:S, > 0x060000-0x060fff:S, 0x061000-0x061fff:S, 0x062000-0x062fff:S, > 0x063000-0x063fff:S, 0x064000-0x064fff:S, 0x065000-0x065fff:S, > 0x066000-0x066fff:S, 0x067000-0x067fff:S, 0x068000-0x068fff:S, > 0x069000-0x069fff:S, 0x06a000-0x06afff:W, 0x06b000-0x06bfff:W, > 0x06c000-0x06cfff:W, 0x06d000-0x06dfff:W, 0x06e000-0x06efff:W, > 0x06f000-0x06ffff:W, 0x070000-0x070fff:W writing sector at 0x7f28ed976000 > failed! > Reading current flash chip contents... done. Looking for another erase > function. > Trying erase function 1... 0x000000-0x00ffff:S, 0x010000-0x01ffff:S, > 0x020000-0x02ffff:S, 0x030000-0x03ffff:S, 0x040000-0x04ffff:S, > 0x050000-0x05ffff:S, 0x060000-0x06ffff:S, 0x070000-0x07ffff:W writing > sector at 0x7f28ed976000 failed! > Looking for another erase function. > No usable erase functions left. > FAILED! > Uh oh. Erase/write failed. Checking if anything changed. > Your flash chip is in an unknown state. > Get help on IRC at irc.freenode.net (channel #flashrom) or > mail flashrom(a)flashrom.org with FAILED: your board name in the subject line! > ------------------------------------------------------------------------------- > DO NOT REBOOT OR POWEROFF! > Restoring PCI config space for 00:01:0 reg 0x6d > Restoring PCI config space for 00:01:0 reg 0x90 > Restoring PCI config space for 00:01:0 reg 0x8c > Restoring PCI config space for 00:01:0 reg 0x88 that's interesting. it always fails at the same address (0x070000). this is where the boot block protection of that chip begins. the boot block protection is enabled by setting a pin to low and can not be disabled directly by software. usually the pin is connected to a general output pin of the southbridge (or another chip) on the mainboard and can be controlled by that. adding support for this requires some reverse engineering of various difficulty. the interesting question is something different: why were we able to erase that block a month ago... can you confirm that the two chips you are using are the same model? > > what can i do?? since you have a replacement chip, you could just throw the old one away... i would really like to know what happened though. maybe my colleagues can shed some light onto this... -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

flashrom@ mailing list at Gmane (news:gmane.linux.bios.flashrom)
by Ivan Shmakov Feb. 8, 2012

Feb. 8, 2012

Apparently, the flashrom@ mailing list traffic isn't properly forwarded to Gmane [1]. Indeed, it seems that all the messages archived there were propagated through one or more of the other Gmane-ized lists instead. Could the forwarding please be fixed? Also, it'd make sense to import the whole mailing list archive to Gmane (check, e. g., [2].) For this, however, one needs access to the Mailman's internal archives, as the downloadable mbox'es at [3] are stripped of much of the relevant information, including, in particular, MIME headers (effectively rendering anything non-ASCII there unreadable) and MIME parts. TIA. [1] http://dir.gmane.org/gmane.linux.bios.flashrom [2] http://gmane.org/import.php [3] http://www.flashrom.org/pipermail/flashrom/ -- FSF associate member #7257

1 0

Re: [flashrom] FAILED : mcp61sm -am
by Vince S Feb. 8, 2012

Feb. 8, 2012

Hi so the output of my attempt to flash is sudo flashrom -V -w '/home/vince/Téléchargements/BIOS_R01-C0/61AO615.BIN' flashrom v0.9.4-r1394 on Linux 3.0.0-15-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... OS timer resolution is 1 usecs, 736M loops per second, 10 myus = 11 us, 100 myus = 101 us, 1000 myus = 1007 us, 10000 myus = 10003 us, 4 myus = 5 us, OK. Initializing internal programmer No coreboot table found. DMI string system-manufacturer: "Acer" DMI string system-product-name: "Aspire E380" DMI string system-version: "R01-A2" DMI string baseboard-manufacturer: "Acer" DMI string baseboard-product-name: "EM61SM/EM61PM " DMI string baseboard-version: " " DMI string chassis-type: "Desktop" Found ITE Super I/O, ID 0x8726 on port 0x2e Found chipset "NVIDIA MCP61" with PCI ID 10de:03e0. This chipset is marked as untested. If you are using an up-to-date version of flashrom please email a report to flashrom(a)flashrom.org including a verbose (-V) log. Thank you! Enabling flash write... This chipset is not really supported yet. Guesswork... ISA/LPC bridge reg 0x8a contents: 0x00, bit 6 is 0, bit 5 is 0 Flash bus type is LPC Found SMBus device 10de:03eb at 00:01:1 MCP SPI BAR is at 0xfec80000 Strange. MCP SPI BAR is valid, but chipset apparently doesn't have SPI enabled. Please send the output of "flashrom -V" to flashrom(a)flashrom.org with your board name: flashrom -V as the subject to help us finish support for your chipset. Thanks. OK. This chipset supports the following protocols: LPC. Super I/O ID 0x8726 is not on the list of flash capable controllers. Probing for AMIC A49LF040A, 512 kB: probe_jedec_common: id1 0xbf, id2 0x50 Probing for PMC Pm49FL002, 256 kB: probe_jedec_common: id1 0xbf, id2 0x50 Probing for PMC Pm49FL004, 512 kB: probe_jedec_common: id1 0xbf, id2 0x50 Probing for SST SST49LF020, 256 kB: probe_jedec_common: id1 0xbf, id2 0x50 Probing for SST SST49LF020A, 256 kB: probe_jedec_common: id1 0xbf, id2 0x50 Probing for SST SST49LF040, 512 kB: probe_jedec_common: id1 0xbf, id2 0x50 Probing for SST SST49LF040B, 512 kB: probe_jedec_common: id1 0xbf, id2 0x50 Found SST flash chip "SST49LF040B" (512 kB, LPC) at physical address 0xfff80000. Probing for SST SST49LF080A, 1024 kB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF160C, 2048 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040A, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040B, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW080A, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW080B, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50LPW116, 2048 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040A, 512 kB: probe_jedec_common: id1 0xbf, id2 0x50 Probing for Winbond W39V040B, 512 kB: probe_jedec_common: id1 0xbf, id2 0x50 Probing for Winbond W39V040C, 512 kB: probe_jedec_common: id1 0xbf, id2 0x50 Probing for Winbond W39V080A, 1024 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W49V002A, 256 kB: probe_jedec_common: id1 0xbf, id2 0x50 === This flash part has status UNTESTED for operations: WRITE The test status of this chip may have been updated in the latest development version of flashrom. If you are running the latest development version, please email a report to flashrom(a)flashrom.org if any of the above operations work correctly for you with this flash part. Please include the flashrom output with the additional -V option for all operations you tested (-V, -Vr, -Vw, -VE), and mention which mainboard or programmer you tested. Please mention your board in the subject line. Thanks for your help! Flash image seems to be a legacy BIOS. Disabling coreboot-related checks. Reading old flash chip contents... done. Erasing and writing flash chip... Trying erase function 0... 0x000000-0x000fff:W, 0x001000-0x001fff:S, 0x002000-0x002fff:S, 0x003000-0x003fff:S, 0x004000-0x004fff:S, 0x005000-0x005fff:S, 0x006000-0x006fff:S, 0x007000-0x007fff:S, 0x008000-0x008fff:S, 0x009000-0x009fff:S, 0x00a000-0x00afff:S, 0x00b000-0x00bfff:S, 0x00c000-0x00cfff:S, 0x00d000-0x00dfff:S, 0x00e000-0x00efff:S, 0x00f000-0x00ffff:S, 0x010000-0x010fff:W, 0x011000-0x011fff:W, 0x012000-0x012fff:W, 0x013000-0x013fff:W, 0x014000-0x014fff:W, 0x015000-0x015fff:W, 0x016000-0x016fff:W, 0x017000-0x017fff:W, 0x018000-0x018fff:W, 0x019000-0x019fff:W, 0x01a000-0x01afff:W, 0x01b000-0x01bfff:W, 0x01c000-0x01cfff:W, 0x01d000-0x01dfff:W, 0x01e000-0x01efff:W, 0x01f000-0x01ffff:W, 0x020000-0x020fff:W, 0x021000-0x021fff:W, 0x022000-0x022fff:W, 0x023000-0x023fff:W, 0x024000-0x024fff:W, 0x025000-0x025fff:W, 0x026000-0x026fff:W, 0x027000-0x027fff:W, 0x028000-0x028fff:W, 0x029000-0x029fff:W, 0x02a000-0x02afff:W, 0x02b000-0x02bfff:W, 0x02c000-0x02cfff:W, 0x02d000-0x02dfff:W, 0x02e000-0x02efff:W, 0x02f000-0x02ffff:W, 0x030000-0x030fff:W, 0x031000-0x031fff:W, 0x032000-0x032fff:W, 0x033000-0x033fff:W, 0x034000-0x034fff:W, 0x035000-0x035fff:W, 0x036000-0x036fff:W, 0x037000-0x037fff:W, 0x038000-0x038fff:W, 0x039000-0x039fff:W, 0x03a000-0x03afff:W, 0x03b000-0x03bfff:W, 0x03c000-0x03cfff:W, 0x03d000-0x03dfff:W, 0x03e000-0x03efff:W, 0x03f000-0x03ffff:W, 0x040000-0x040fff:W, 0x041000-0x041fff:W, 0x042000-0x042fff:W, 0x043000-0x043fff:W, 0x044000-0x044fff:W, 0x045000-0x045fff:W, 0x046000-0x046fff:W, 0x047000-0x047fff:W, 0x048000-0x048fff:W, 0x049000-0x049fff:W, 0x04a000-0x04afff:W, 0x04b000-0x04bfff:W, 0x04c000-0x04cfff:W, 0x04d000-0x04dfff:W, 0x04e000-0x04efff:W, 0x04f000-0x04ffff:W, 0x050000-0x050fff:W, 0x051000-0x051fff:W, 0x052000-0x052fff:W, 0x053000-0x053fff:W, 0x054000-0x054fff:W, 0x055000-0x055fff:W, 0x056000-0x056fff:S, 0x057000-0x057fff:S, 0x058000-0x058fff:S, 0x059000-0x059fff:S, 0x05a000-0x05afff:S, 0x05b000-0x05bfff:S, 0x05c000-0x05cfff:S, 0x05d000-0x05dfff:S, 0x05e000-0x05efff:S, 0x05f000-0x05ffff:S, 0x060000-0x060fff:S, 0x061000-0x061fff:S, 0x062000-0x062fff:S, 0x063000-0x063fff:S, 0x064000-0x064fff:S, 0x065000-0x065fff:S, 0x066000-0x066fff:S, 0x067000-0x067fff:S, 0x068000-0x068fff:S, 0x069000-0x069fff:S, 0x06a000-0x06afff:W, 0x06b000-0x06bfff:W, 0x06c000-0x06cfff:W, 0x06d000-0x06dfff:W, 0x06e000-0x06efff:W, 0x06f000-0x06ffff:W, 0x070000-0x070fff:W writing sector at 0x7f28ed976000 failed! Reading current flash chip contents... done. Looking for another erase function. Trying erase function 1... 0x000000-0x00ffff:S, 0x010000-0x01ffff:S, 0x020000-0x02ffff:S, 0x030000-0x03ffff:S, 0x040000-0x04ffff:S, 0x050000-0x05ffff:S, 0x060000-0x06ffff:S, 0x070000-0x07ffff:W writing sector at 0x7f28ed976000 failed! Looking for another erase function. No usable erase functions left. FAILED! Uh oh. Erase/write failed. Checking if anything changed. Your flash chip is in an unknown state. Get help on IRC at irc.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org with FAILED: your board name in the subject line! ------------------------------------------------------------------------------- DO NOT REBOOT OR POWEROFF! Restoring PCI config space for 00:01:0 reg 0x6d Restoring PCI config space for 00:01:0 reg 0x90 Restoring PCI config space for 00:01:0 reg 0x8c Restoring PCI config space for 00:01:0 reg 0x88 what can i do??

1 0

Re: [flashrom] [PATCH] dummy programmer: blacklist SPI commands
by Carl-Daniel Hailfinger Feb. 8, 2012

Feb. 8, 2012

Am 08.02.2012 01:49 schrieb David Hendricks: > Acked-by: David Hendricks <dhendrix(a)google.com> Thanks, committed in r1490. Do we want to add a selftest script or "make selftest" target in the Makefile which compares known good output of a complicated write (maybe even including layout) to a reference output shipped with flashrom? That might be useful for distributors and/or as pre-checkin test of invasive changes. Regards, Carl-Daniel -- http://www.hailfinger.org/

1 0

[commit] r1490 - trunk
by repository service Feb. 8, 2012

Feb. 8, 2012

Author: hailfinger Date: Thu Feb 9 00:28:54 2012 New Revision: 1490 URL: http://flashrom.org/trac/flashrom/changeset/1490 Log: SPI command black-/ignorelisting for the flash chip emulator in the dummy programmer Usage: flashrom -p dummy:spi_blacklist=commandlist flashrom -p dummy:spi_ignorelist=commandlist If commandlist is 0302, flashrom will refuse (blacklist) or ignore (ignorelist) command 0x03 (READ) and command 0x02 (WRITE). The commandlist can be up to 512 bytes (256 commands) long. Specifying flash chip emulation is a good idea to get useful results. Very useful for testing corner cases if you don't own a locked down Intel chipset and want to simulate such a thing. Example usage: dd if=/dev/zeros bs=1024k count=4 of=dummy_simulator.rom dd if=/dev/urandom bs=1024k count=4 of=randomimage.rom flashrom -p dummy:emulate=SST25VF032B,image=dummy_simulator.rom,\ spi_blacklist=20,spi_ignorelist=52 -w randomimage.rom -V Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: David Hendricks <dhendrix(a)google.com> Modified: trunk/dummyflasher.c trunk/flashrom.8 Modified: trunk/dummyflasher.c ============================================================================== --- trunk/dummyflasher.c Tue Feb 7 22:29:48 2012 (r1489) +++ trunk/dummyflasher.c Thu Feb 9 00:28:54 2012 (r1490) @@ -19,6 +19,8 @@ #include <string.h> #include <stdlib.h> +#include <stdio.h> +#include <ctype.h> #include "flash.h" #include "chipdrivers.h" #include "programmer.h" @@ -55,6 +57,10 @@ static unsigned int emu_jedec_be_d8_size = 0; static unsigned int emu_jedec_ce_60_size = 0; static unsigned int emu_jedec_ce_c7_size = 0; +unsigned char spi_blacklist[256]; +unsigned char spi_ignorelist[256]; +int spi_blacklist_size = 0; +int spi_ignorelist_size = 0; #endif #endif @@ -126,6 +132,7 @@ { char *bustext = NULL; char *tmp = NULL; + int i; #if EMULATE_CHIP struct stat image_stat; #endif @@ -170,6 +177,68 @@ } } + tmp = extract_programmer_param("spi_blacklist"); + if (tmp) { + i = strlen(tmp); + if (!strncmp(tmp, "0x", 2)) { + i -= 2; + memmove(tmp, tmp + 2, i + 1); + } + if ((i > 512) || (i % 2)) { + msg_perr("Invalid SPI command blacklist length\n"); + free(tmp); + return 1; + } + spi_blacklist_size = i / 2; + for (i = 0; i < spi_blacklist_size * 2; i++) { + if (!isxdigit((unsigned char)tmp[i])) { + msg_perr("Invalid char \"%c\" in SPI command " + "blacklist\n", tmp[i]); + free(tmp); + return 1; + } + } + for (i = 0; i < spi_blacklist_size; i++) { + sscanf(tmp + i * 2, "%2hhx", &spi_blacklist[i]); + } + msg_pdbg("SPI blacklist is "); + for (i = 0; i < spi_blacklist_size; i++) + msg_pdbg("%02x ", spi_blacklist[i]); + msg_pdbg(", size %i\n", spi_blacklist_size); + } + free(tmp); + + tmp = extract_programmer_param("spi_ignorelist"); + if (tmp) { + i = strlen(tmp); + if (!strncmp(tmp, "0x", 2)) { + i -= 2; + memmove(tmp, tmp + 2, i + 1); + } + if ((i > 512) || (i % 2)) { + msg_perr("Invalid SPI command ignorelist length\n"); + free(tmp); + return 1; + } + spi_ignorelist_size = i / 2; + for (i = 0; i < spi_ignorelist_size * 2; i++) { + if (!isxdigit((unsigned char)tmp[i])) { + msg_perr("Invalid char \"%c\" in SPI command " + "ignorelist\n", tmp[i]); + free(tmp); + return 1; + } + } + for (i = 0; i < spi_ignorelist_size; i++) { + sscanf(tmp + i * 2, "%2hhx", &spi_ignorelist[i]); + } + msg_pdbg("SPI ignorelist is "); + for (i = 0; i < spi_ignorelist_size; i++) + msg_pdbg("%02x ", spi_ignorelist[i]); + msg_pdbg(", size %i\n", spi_ignorelist_size); + } + free(tmp); + #if EMULATE_CHIP tmp = extract_programmer_param("emulate"); if (!tmp) { @@ -348,7 +417,7 @@ const unsigned char *writearr, unsigned char *readarr) { - unsigned int offs; + unsigned int offs, i; static int unsigned aai_offs; static int aai_active = 0; @@ -356,7 +425,24 @@ msg_perr("No command sent to the chip!\n"); return 1; } - /* TODO: Implement command blacklists here. */ + /* spi_blacklist has precedence before spi_ignorelist. */ + for (i = 0; i < spi_blacklist_size; i++) { + if (writearr[0] == spi_blacklist[i]) { + msg_pdbg("Refusing blacklisted SPI command 0x%02x\n", + spi_blacklist[i]); + return SPI_INVALID_OPCODE; + } + } + for (i = 0; i < spi_ignorelist_size; i++) { + if (writearr[0] == spi_ignorelist[i]) { + msg_cdbg("Ignoring ignorelisted SPI command 0x%02x\n", + spi_ignorelist[i]); + /* Return success because the command does not fail, + * it is simply ignored. + */ + return 0; + } + } switch (writearr[0]) { case JEDEC_RES: if (emu_chip != EMULATE_ST_M25P10_RES) @@ -563,7 +649,7 @@ case EMULATE_SST_SST25VF032B: if (emulate_spi_chip_response(writecnt, readcnt, writearr, readarr)) { - msg_perr("Invalid command sent to flash chip!\n"); + msg_pdbg("Invalid command sent to flash chip!\n"); return 1; } break; Modified: trunk/flashrom.8 ============================================================================== --- trunk/flashrom.8 Tue Feb 7 22:29:48 2012 (r1489) +++ trunk/flashrom.8 Thu Feb 9 00:28:54 2012 (r1490) @@ -421,6 +421,28 @@ Example: .sp .B " flashrom -p dummy:emulate=M25P10.RES,spi_write_256_chunksize=5" +.sp +To simulate a programmer which refuses to send certain SPI commands to the +flash chip, you can specify a blacklist of SPI commands with the +.sp +.B " flashrom -p dummy:spi_blacklist=commandlist" +.sp +syntax where commandlist is a list of two-digit hexadecimal representations of +SPI commands. If commandlist is e.g. 0302, flashrom will behave as if the SPI +controller refuses to run command 0x03 (READ) and command 0x02 (WRITE). +commandlist may be up to 512 characters (256 commands) long. +Implementation note: flashrom will detect an error during command execution. +.sp +To simulate a flash chip which ignores (doesn't support) certain SPI commands, +you can specify an ignorelist of SPI commands with the +.sp +.B " flashrom -p dummy:spi_ignorelist=commandlist" +.sp +syntax where commandlist is a list of two-digit hexadecimal representations of +SPI commands. If commandlist is e.g. 0302, the emulated flash chip will ignore +command 0x03 (READ) and command 0x02 (WRITE). commandlist may be up to 512 +characters (256 commands) long. +Implementation note: flashrom won't detect an error during command execution. .TP .BR "nic3com" , " nicrealtek" , " nicsmc1211" , " nicnatsemi" , " nicintel\ " , " nicintel_spi" , " gfxnvidia" , " ogp_spi" , " drkaiser" , " satasii\

1 0

Re: [flashrom] FAILED : mcp61sm -am
by Stefan Tauner Feb. 8, 2012

Feb. 8, 2012

On Wed, 8 Feb 2012 20:47:13 +0100 Vince S <vince06fr(a)gmail.com> wrote: > can i restore my bios from my linux session or do i have to reboot (i have > another bios with i can reboot) to flash it from a freedos live usb? *if* you are talking about the acer you reported last month and *if* i understood your question correctly, *then* you should be able to write the flash chip with flashrom in your linux session. your previous log confirmed at least that erasing works. writing will almost always work if erase works. if you read out the good contents with -r, install the bad chip, write the previously read good content with -w, the two chips should be identical. please ask further questions if something is not clear. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Re: [flashrom] [PATCH] Add support for SFDP (JESD216).
by Carl-Daniel Hailfinger Feb. 8, 2012

Feb. 8, 2012

Am 31.01.2012 06:59 schrieb Stefan Tauner: > Similar to modules using the opaque programmer framework (e.g. ICH Hardware > Sequencing) this uses a template struct flashchip element in flashchips.c with > a special probe function that fills the obtained values into that struct. > > This allows yet unknown SPI chips to be supported (read, erase, write) almost > as if it was already added to flashchips.c. > > Documentation used: > http://www.jedec.org/standards-documents/docs/jesd216 (2011-04) > W25Q32BV data sheet Revision F (2011-04-01) > EN25QH16 data sheet Revision F (2011-06-01) > > todo: > - handle programmers which have a problem with the dummy bytes needed AMD SB[678]x0 SPI has a way to specify sending one dummy byte between write and read, IIRC it is called DropOneClkOnRead or somthing like that. Quite a few other SPI masters have the one-dummy-byte functionality as well. This needs to be implemented in a generic way (I have a totally bitrotted patch for it), but it should not hold back this patch. > - move sfdp_add_uniform_eraser to spi25.c for further use like > spi_get_erasefn_from_opcode? > - is setting the generic SPI unlock method safe? > - what page_size should be set? > > Tested-by: David Hendricks <dhendrix(a)google.com> > on W25Q64CV > > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> > --- > Makefile | 2 +- > chipdrivers.h | 4 + > flash.h | 2 + > flashchips.c | 23 ++++ > flashchips.h | 1 + > flashrom.c | 28 +++++- > sfdp.c | 355 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > spi.h | 5 + > spi25.c | 31 +++++ > 9 files changed, 449 insertions(+), 2 deletions(-) > create mode 100644 sfdp.c > > diff --git a/Makefile b/Makefile > index 83aa038..b890d8a 100644 > --- a/Makefile > +++ b/Makefile > @@ -252,7 +252,7 @@ endif > CHIP_OBJS = jedec.o stm50flw0x0x.o w39.o w29ee011.o \ > sst28sf040.o m29f400bt.o 82802ab.o pm49fl00x.o \ > sst49lfxxxc.o sst_fwhub.o flashchips.o spi.o spi25.o sharplhf00l04.o \ > - a25.o at25.o opaque.o > + a25.o at25.o opaque.o sfdp.o > > LIB_OBJS = layout.o > > diff --git a/chipdrivers.h b/chipdrivers.h > index a1d0cd9..bd81098 100644 > --- a/chipdrivers.h > +++ b/chipdrivers.h > @@ -41,6 +41,7 @@ int spi_block_erase_d7(struct flashctx *flash, unsigned int addr, unsigned int b > int spi_block_erase_d8(struct flashctx *flash, unsigned int addr, unsigned int blocklen); > int spi_block_erase_60(struct flashctx *flash, unsigned int addr, unsigned int blocklen); > int spi_block_erase_c7(struct flashctx *flash, unsigned int addr, unsigned int blocklen); > +erasefunc_t *spi_get_erasefn_from_opcode(uint8_t opcode); > int spi_chip_write_1(struct flashctx *flash, uint8_t *buf, unsigned int start, unsigned int len); > int spi_chip_write_256(struct flashctx *flash, uint8_t *buf, unsigned int start, unsigned int len); > int spi_chip_read(struct flashctx *flash, uint8_t *buf, unsigned int start, int unsigned len); > @@ -58,6 +59,9 @@ int spi_read_chunked(struct flashctx *flash, uint8_t *buf, unsigned int start, u > int spi_write_chunked(struct flashctx *flash, uint8_t *buf, unsigned int start, unsigned int len, unsigned int chunksize); > int spi_aai_write(struct flashctx *flash, uint8_t *buf, unsigned int start, unsigned int len); > > +/* sfdp.c */ > +int probe_spi_sfdp(struct flashctx *flash); > + > /* opaque.c */ > int probe_opaque(struct flashctx *flash); > int read_opaque(struct flashctx *flash, uint8_t *buf, unsigned int start, unsigned int len); > diff --git a/flash.h b/flash.h > index e51b6d4..6bcae71 100644 > --- a/flash.h > +++ b/flash.h > @@ -174,6 +174,8 @@ struct flashctx { > struct registered_programmer *pgm; > }; > > +typedef int (erasefunc_t)(struct flashctx *flash, unsigned int addr, unsigned int blocklen); I believe that typedef to be pretty unreadable, but I see that avoiding the typedef would probably be even worse. > + > #define TEST_UNTESTED 0 > > #define TEST_OK_PROBE (1 << 0) > diff --git a/flashchips.c b/flashchips.c > index 0c8257b..b22e709 100644 > --- a/flashchips.c > +++ b/flashchips.c > @@ -8872,6 +8872,29 @@ const struct flashchip flashchips[] = { > .read = read_memmapped, > .voltage = {3000, 3600}, /* Also has 12V fast program */ > }, > + > + { > + .vendor = "Unknown", > + .name = "SFDP device", > + .bustype = BUS_SPI, > + .manufacture_id = GENERIC_MANUF_ID, > + .model_id = SFDP_DEVICE_ID, > + /* We present our own "report this" text hence we do not > + * want the default "This flash part has status UNTESTED..." > + * text to be printed. */ > + .tested = TEST_OK_PREW, > + .probe = probe_spi_sfdp, > + .unlock = spi_disable_blockprotect, /* is this safe? */ Should be safe AFAICS, but that's not a hard statement, it's a gut feeling. > + .read = spi_chip_read, > + .page_size = 256, /* ? */ Argh, page_size comes to bite us again. Did I already send my "kill most uses of page_size" patch? > + /* FIXME: some vendor extensions define this */ > + .voltage = {}, > + /* Everything below will be set by the probing function. */ > + .write = NULL, > + .total_size = 0, > + .feature_bits = 0, > + .block_erasers = {}, > + }, > > { > .vendor = "Unknown", > diff --git a/flashchips.h b/flashchips.h > index 03efb86..1f2a8ca 100644 > --- a/flashchips.h > +++ b/flashchips.h > @@ -36,6 +36,7 @@ > > #define GENERIC_MANUF_ID 0xffff /* Check if there is a vendor ID */ > #define GENERIC_DEVICE_ID 0xffff /* Only match the vendor ID */ > +#define SFDP_DEVICE_ID 0xfffe Side note: Should we move PROGMANUF_ID and its companion from the bottom of the file to this location to have generic match IDs in one place? > > #define ALLIANCE_ID 0x52 /* Alliance Semiconductor */ > #define ALLIANCE_AS29F002B 0x34 > diff --git a/flashrom.c b/flashrom.c > index ee68344..84fb3fc 100644 > --- a/flashrom.c > +++ b/flashrom.c > @@ -986,7 +986,33 @@ int probe_flash(struct registered_programmer *pgm, int startchip, > * probe_flash() is the first one and thus no chip has been > * found before. The comment above is not really valid anymore. Can you include the following snippet in your patch? @@ -980,11 +980,10 @@ /* If this is the first chip found, accept it. * If this is not the first chip found, accept it only if it is - * a non-generic match. - * We could either make chipcount global or provide it as - * parameter, or we assume that startchip==0 means this call to - * probe_flash() is the first one and thus no chip has been - * found before. + * a non-generic match. SFDP and CFI are generic matches. + * startchip==0 means this call to probe_flash() is the first + * one for this programmer interface and thus no other chip has + * been found on this interface. */ if (startchip == 0 || fill_flash->model_id != GENERIC_DEVICE_ID) break; > */ > - if (startchip == 0 || fill_flash->model_id != GENERIC_DEVICE_ID) > + if (startchip == 0 && fill_flash->model_id == SFDP_DEVICE_ID) { > + msg_cinfo("===\n" > + "SFDP has autodetected a flash chip which is " > + "not natively supported by flashrom yet.\n"); > + if (count_usable_erasers(fill_flash) == 0) > + msg_cinfo("The standard operations read and " > + "verify should work, but to support " > + "erase, write and all other " > + "possible features"); > + else > + msg_cinfo("All standard operations (read, " > + "verify, erase and write) should " > + "work, but to support all possible " > + "features"); > + > + msg_cinfo(" we need to add them manually.\nYou " > + "can help us by mailing us the output of " > + "the following command to flashrom@flashrom." > + "org: \n'flashrom -VV [plus the " > + "-p/--programmer parameter (if needed)]" > + "'\nThanks for your help!\n" > + "===\n"); > + } > + > + if (startchip == 0 || > + ((fill_flash->model_id != GENERIC_DEVICE_ID) && > + (fill_flash->model_id != SFDP_DEVICE_ID))) > break; > > notfound: > diff --git a/sfdp.c b/sfdp.c > new file mode 100644 > index 0000000..7c00ff5 > --- /dev/null > +++ b/sfdp.c > @@ -0,0 +1,355 @@ > +/* > + * This file is part of the flashrom project. > + * > + * Copyright (C) 2011-2012 Stefan Tauner > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; version 2 of the License. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA > + */ > + > +#include <stdint.h> > +#include <stdlib.h> > +#include "flash.h" > +#include "spi.h" > +#include "chipdrivers.h" > + > +static int spi_sfdp_wrapper(struct flashctx *flash, uint32_t address, uint8_t *buf, int len) > +{ > + int i, ret; > + const unsigned char cmd[JEDEC_SFDP_OUTSIZE] = { > + JEDEC_SFDP, > + (address >> 16) & 0xff, > + (address >> 8) & 0xff, > + (address >> 0) & 0xff, > + 0 > + }; > + msg_cspew("spi_sfdp_wrapper: addr=0x%x, len=%d, data:\n", address, len); > + ret = spi_send_command(flash, sizeof(cmd), len, cmd, buf); > + for (i = 0; i < len; i++) > + msg_cspew(" 0x%02x", buf[i]); > + msg_cspew("\n"); > + return ret; > +} > + > +/* FIXME: eventually something similar like this but more generic should be > + * available to split up spi commands. use that then instead */ > +static int spi_sfdp(struct flashctx *flash, uint32_t address, uint8_t *buf, int len) > +{ > + /* FIXME: this is wrong. */ > + int maxstep = 8; Yes, maxstep should be a programmer-specific setting. However, with our current infrastructure there is no way to fix this easily. > + int ret = 0; > + while (len > 0) { > + int step = min(len, maxstep); > + ret = spi_sfdp_wrapper(flash, address, buf, step); > + if (ret) Actually, there is probably a way to determine optimal size for those SFDP requests: Check if ret indicates a "command too long" error and reduce maxstep by one in that case, then retry. Such code is not exactly pretty and I'm not sure if all SPI masters have such a differentiated error code reporting. > + return ret; > + address += step; > + buf += step; > + len -= step; > + } > + return ret; > +} > + > +struct sfdp_tbl_hdr { > + uint8_t id; > + uint8_t v_minor; > + uint8_t v_major; > + uint8_t len; > + uint32_t ptp; /* 24b pointer */ > +}; > + > +static int sfdp_add_uniform_eraser(struct flashctx *f, uint8_t opcode, uint32_t bsize) struct flashctx *flash Just "f" is too short, and if you try to search for it, you'll get thousands of matches you don't want. bsize or blocksize? I prefer the latter for consistency and readability reasons. > +{ > + uint32_t total_size = f->total_size * 1024; > + int i; > + erasefunc_t *erasefn = spi_get_erasefn_from_opcode(opcode); > + if (erasefn == NULL) > + return 1; > + for (i = 0; i < NUM_ERASEFUNCTIONS; i++) { > + struct block_eraser *eraser = &f->block_erasers[i]; > + if (eraser->eraseblocks[0].size != 0 || !eraser->block_erase) > + continue; > + eraser->block_erase = erasefn; > + eraser->eraseblocks[0].size = bsize; > + eraser->eraseblocks[0].count = total_size/bsize; > + msg_cdbg2(" Block eraser %d: %d x %d B with opcode " > + "0x%02x\n", i, total_size/bsize, bsize, > + opcode); > + return 0; > + } > + msg_cinfo("%s: Not enough space to store another eraser (i=%d)." msg_cerr? > + " Please report this at flashrom(a)flashrom.org\n", > + __func__, i); > + return 1; > +} > + Rest of review follows later. > +static int sfdp_fill_flash(struct flashctx *f, uint8_t *buf, uint16_t len) > +{ > + uint32_t tmp32; > + uint8_t tmp8; > + uint32_t total_size; /* in bytes */ > + uint32_t bsize; > + uint8_t opcode_4k = 0xFF; > + int dw, j; > + > + msg_cdbg("Parsing JEDEC SFDP parameter table... "); > + if (len != 9 * 4 && len != 4 * 4) { > + msg_cerr("%s: len out of spec\n", __func__); > + return 1; > + } > + msg_cdbg2("\n"); > + > + /* 1. double word */ > + dw = 0; > + tmp32 = buf[(4 * dw) + 0]; > + tmp32 |= ((unsigned int)buf[(4 * dw) + 1]) << 8; > + tmp32 |= ((unsigned int)buf[(4 * dw) + 2]) << 16; > + tmp32 |= ((unsigned int)buf[(4 * dw) + 3]) << 24; > + > + tmp8 = (tmp32 >> 17) & 0x3; > + switch (tmp8) { > + case 0x0: > + msg_cdbg2(" 3-Byte only addressing.\n"); > + break; > + case 0x1: > + msg_cdbg2(" 3-Byte (and optionally 4-Byte) addressing.\n"); > + break; > + case 0x2: > + msg_cdbg(" 4-Byte only addressing not supported.\n"); > + return 1; > + default: > + msg_cdbg(" Required addressing mode (0x%x) not supported.\n", > + tmp8); > + return 1; > + } > + > + msg_cdbg2(" Writes to the status register have "); > + if (tmp32 & (1 << 3)) { > + msg_cdbg2("to be enabled with "); > + if (tmp32 & (1 << 4)) { > + f->feature_bits = FEATURE_WRSR_WREN; > + msg_cdbg2("WREN (0x06).\n"); > + } else { > + f->feature_bits = FEATURE_WRSR_EWSR; > + msg_cdbg2("EWSR (0x50).\n"); > + } > + } else > + msg_cdbg2("not to be especially enabled.\n"); > + > + msg_cdbg2(" Write granularity is "); > + if (tmp32 & (1 << 2)) { > + msg_cdbg2("at least 64 B.\n"); > + f->write = spi_chip_write_256; > + } else { > + msg_cdbg2("1 B only.\n"); > + f->write = spi_chip_write_1; > + } > + > + if ((tmp32 & 0x3) == 0x1) { > + opcode_4k = (tmp32 >> 8) & 0xFF; /* will be dealt with later */ > + } > + > + /* 2. double word */ > + dw = 1; > + tmp32 = buf[(4 * dw) + 0]; > + tmp32 |= ((unsigned int)buf[(4 * dw) + 1]) << 8; > + tmp32 |= ((unsigned int)buf[(4 * dw) + 2]) << 16; > + tmp32 |= ((unsigned int)buf[(4 * dw) + 3]) << 24; > + > + if (tmp32 & (1 << 31)) { > + msg_cerr("Flash chip size >= 4 Gb/512 MB not supported.\n"); > + return 1; > + } > + total_size = ((tmp32 & 0x7FFFFFFF) + 1) / 8; > + f->total_size = total_size / 1024; > + msg_cdbg2(" Flash chip size is %d kB.\n", f->total_size); > + > + /* FIXME: double words 3-7 contain unused fast read information */ > + > + if (len == 4 * 4) { > + msg_cdbg("It seems like this chip supports the preliminary " > + "Intel version of SFDP, skipping processing of double " > + "words 3-9.\n"); > + goto proc_4k; > + } > + > + dw = 8; > + for (j = 0; j < 4; j++) { > + /* 8 double words from the start + 2 words for every eraser */ > + tmp32 = buf[(4 * dw) + (2 * j)]; > + if (tmp32 == 0) { > + msg_cdbg2(" Block eraser %d is unused.\n", j); > + continue; > + } > + if (tmp32 >= 31) { > + msg_cdbg2(" Block size of eraser %d (2^%d) is too big." > + "\n", j, tmp32); > + continue; > + } > + bsize = 1 << (tmp32); /* bsize = 2 ^ field */ > + > + tmp8 = buf[(4 * dw) + (2 * j) + 1]; > + if(sfdp_add_uniform_eraser(f, tmp8, bsize)) > + continue; > + /* If there is a valid 4k value in the last double words, > + * we want to override the value from double word 1, hence force > + * skipping its processing: */ > + if (bsize == 4 * 1024) > + opcode_4k = 0xFF; > + } > + > +proc_4k: > + if (opcode_4k != 0xFF) { > + sfdp_add_uniform_eraser(f, opcode_4k, 4 * 1024); > + } > + msg_cdbg("done.\n"); > + return 0; > +} > + > +static int sfdp_fetch_pt(struct flashctx *flash, uint32_t addr, uint8_t *buf, uint16_t len) > +{ > + uint16_t i; > + if (spi_sfdp(flash, addr, buf, len)) { > + msg_cerr("Receiving SFDP parameter table failed.\n"); > + return 1; > + } > + msg_cspew(" Parameter table contents:\n"); > + for(i = 0; i < len; i++) { > + if ((i % 8) == 0) { > + msg_cspew(" 0x%03x: ", i); > + } > + msg_cspew(" 0x%02x", buf[i]); > + if ((i % 8) == 7) { > + msg_cspew("\n"); > + continue; > + } > + if ((i % 8) == 3) { > + msg_cspew(" "); > + continue; > + } > + } > + msg_cspew("\n"); > + return 0; > +} > + > +int probe_spi_sfdp(struct flashctx *flash) > +{ > + int ret = 0; > + uint8_t buf[8]; > + uint32_t tmp32; > + uint8_t nph; > + /* need to limit the table loop by comparing i to uint8_t nph hence: */ > + uint16_t i; > + struct sfdp_tbl_hdr *hdrs; > + uint8_t *hbuf; > + uint8_t *tbuf; > + > + if (spi_sfdp(flash, 0x00, buf, 4)) { > + msg_cerr("Receiving SFDP signature failed.\n"); > + return 0; > + } > + tmp32 = buf[0]; > + tmp32 |= ((unsigned int)buf[1]) << 8; > + tmp32 |= ((unsigned int)buf[2]) << 16; > + tmp32 |= ((unsigned int)buf[3]) << 24; > + > + msg_cdbg2("SFDP signature = 0x%08x (should be 0x50444653)\n", tmp32); > + if (tmp32 != 0x50444653) { > + msg_cdbg("No SFDP signature found.\n"); > + return 0; > + } > + if (spi_sfdp(flash, 0x04, buf, 3)) { > + msg_cerr("Receiving SFDP revision and number of parameter " > + "headers (NPH) failed. "); > + return 0; > + } > + msg_cdbg2("SFDP revision = %d.%d\n", buf[1], buf[0]); > + nph = buf[2]; > + msg_cdbg2("SFDP number of parameter headers (NPH) = %d (+ 1 mandatory)" > + "\n", nph); > + > + /* Fetch all parameter headers, even if we don't use them all (yet). */ > + hbuf = malloc(sizeof(struct sfdp_tbl_hdr) * (nph + 1)); > + hdrs = malloc((nph + 1) * 8); > + if (hbuf == NULL || hdrs == NULL ) { > + msg_gerr("Out of memory!\n"); > + exit(1); /* FIXME: shutdown gracefully */ > + } > + if (spi_sfdp(flash, 0x08, hbuf, (nph + 1) * 8)) { > + msg_cerr("Receiving SFDP parameter table headers failed.\n"); > + goto cleanup_hdrs; > + } > + > + i = 0; > + do { > + uint16_t len; > + hdrs[i].id = hbuf[(8 * i) + 0]; > + hdrs[i].v_minor = hbuf[(8 * i) + 1]; > + hdrs[i].v_major = hbuf[(8 * i) + 2]; > + hdrs[i].len = hbuf[(8 * i) + 3]; > + hdrs[i].ptp = hbuf[(8 * i) + 4]; > + hdrs[i].ptp |= ((unsigned int)hbuf[(8 * i) + 5]) << 8; > + hdrs[i].ptp |= ((unsigned int)hbuf[(8 * i) + 6]) << 16; > + msg_cdbg2("SFDP parameter table header %d/%d:\n", i, nph); > + msg_cdbg2(" ID 0x%02x, version %d.%d\n", hdrs[i].id, > + hdrs[i].v_major, hdrs[i].v_minor); > + len = hdrs[i].len * 4; > + tmp32 = hdrs[i].ptp; > + msg_cdbg2(" Length %d B, Parameter Table Pointer 0x%06x\n", > + len, tmp32); > + > + if (len + tmp32 > UINT16_MAX) { > + msg_cerr("SFDP Parameter Table %d supposedly " > + "overflows addressable SFDP area. This most\n" > + "probably indicates a corrupt SFDP parameter " > + "table header. Aborting SFDP probe!\n", i); > + ret = 0; > + goto cleanup_hdrs; > + } > + > + tbuf = malloc(len); > + if (tbuf == NULL) { > + msg_gerr("Out of memory!\n"); > + exit(1); /* FIXME: shutdown gracefully */ > + } > + if (sfdp_fetch_pt(flash, tmp32, tbuf, len)){ > + msg_cerr("Fetching SFDP parameter table %d failed.\n", > + i); > + free(tbuf); > + break; > + } > + if (i == 0) { /* Mandatory JEDEC SFDP parameter table */ > + if (hdrs[i].id != 0) > + msg_cdbg("ID of the mandatory JEDEC SFDP " > + "parameter table is not 0 as demanded " > + "by JESD216 (warning only).\n"); > + > + if (len != 9 * 4 && len != 4 * 4) { > + msg_cdbg("Length of the mandatory JEDEC SFDP " > + "parameter table is %d B instead of " > + "36 B (i.e. 9 double words) as " > + "demanded by JESD216, skipping " > + "parsing.\n", len); > + } else if (sfdp_fill_flash(flash, tbuf, len) == 0) > + ret = 1; > + } > + > + free(tbuf); > + i++; > + } while(i <= nph); > + > +cleanup_hdrs: > + free(hdrs); > + free(hbuf); > + return ret; > +} Regards, Carl-Daniel -- http://www.hailfinger.org/

2 3

Re: [flashrom] FAILED : mcp61sm -am
by Joshua Roys Feb. 8, 2012

Feb. 8, 2012

On 02/08/2012 02:47 PM, Vince S wrote: > can i restore my bios from my linux session or do i have to reboot (i > have another bios with i can reboot) to flash it from a freedos live usb? > > Hello, Please do NOT reboot. Can you provide the log of when flashrom failed? Also, if you made a backup, you can see if your BIOS is still intact by running `flashrom -v /path/to/backup.foo` Thanks, Josh

1 0