Hi,
Please find attached the flashrom report. The program was not able to
detect the bios.
Regards,
*Jean-Christophe CHARRON *
5 rue de Delincourt
Le Poteau
60240 REILLY
France
*jeanchristophe.charron(a)gmail.com
*
Hello!
I would like to upgrade my BIOS, but when I run flashrom it says "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!" so here I am ^^
Could you tell me if it's okay to use flashrom to upgrade my BIOS please?
Thanks
LH
Writing untested since I currently have no possibility to flash the
chip somewhere else if it should fail.
flashrom v0.9.5.2-r1517 on Linux 3.2.0-23-generic-pae (i686), built
with libpci 3.1.8, GCC 4.6.3, little endian
flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OS timer resolution is 1 usecs, 2026M loops
per second, 10 myus = 10 us, 100 myus = 100 us, 1000 myus = 992 us,
10000 myus = 10170 us, 4 myus = 8 us, OK.
Initializing internal programmer
No coreboot table found.
DMI string system-manufacturer: "System Manufacturer"
DMI string system-product-name: "System Name"
DMI string system-version: "System Version"
DMI string baseboard-manufacturer: "ASUSTeK Computer INC."
DMI string baseboard-product-name: "P4G8X "
DMI string baseboard-version: "REV 1.xx"
DMI string chassis-type: "Tower"
Found chipset "Intel ICH4/ICH4-L" with PCI ID 8086:24c0. Enabling
flash write...
BIOS Lock Enable: disabled, BIOS Write Enable: disabled, BIOS_CNTL is 0x0
OK.
The following protocols are supported: FWH.
Probing for Atmel AT49LH002, 256 kB: probe_82802ab: id1 0xd4, id2
0x54, id1 parity violation, id1 is normal flash content, id2 is normal
flash content
Probing for Intel 82802AB, 512 kB: probe_82802ab: id1 0x00, id2 0xf8,
id1 parity violation, id1 is normal flash content, id2 is normal flash
content
Probing for Intel 82802AC, 1024 kB: probe_82802ab: id1 0xff, id2 0xff,
id1 parity violation, id1 is normal flash content, id2 is normal flash
content
Probing for PMC Pm49FL002, 256 kB: probe_jedec_common: id1 0xbf, id2 0x60
Probing for PMC Pm49FL004, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60
Probing for Sharp LHF00L04, 1024 kB: probe_82802ab: id1 0xff, id2
0xff, id1 parity violation, id1 is normal flash content, id2 is normal
flash content
Probing for SST SST49LF002A/B, 256 kB: probe_jedec_common: id1 0xbf, id2 0x60
Probing for SST SST49LF003A/B, 384 kB: probe_jedec_common: id1 0xbf, id2 0x60
Probing for SST SST49LF004A/B, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60
Found SST flash chip "SST49LF004A/B" (512 kB, FWH) at physical address
0xfff80000.
Lock status for 0x000000 (size 0x010000) is 00, full access
Lock status for 0x010000 (size 0x010000) is 00, full access
Lock status for 0x020000 (size 0x010000) is 00, full access
Lock status for 0x030000 (size 0x010000) is 00, full access
Lock status for 0x040000 (size 0x010000) is 00, full access
Lock status for 0x050000 (size 0x010000) is 00, full access
Lock status for 0x060000 (size 0x010000) is 00, full access
Lock status for 0x070000 (size 0x010000) is 00, full access
Probing for SST SST49LF004C, 512 kB: probe_82802ab: id1 0x00, id2
0xf8, id1 parity violation, id1 is normal flash content, id2 is normal
flash content
Probing for SST SST49LF008A, 1024 kB: probe_jedec_common: id1 0xff,
id2 0xff, id1 parity violation, id1 is normal flash content, id2 is
normal flash content
Probing for SST SST49LF008C, 1024 kB: probe_82802ab: id1 0xff, id2
0xff, id1 parity violation, id1 is normal flash content, id2 is normal
flash content
Probing for SST SST49LF016C, 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 0x00, id2 0xf8,
id1 parity violation, id1 is normal flash content, id2 is normal flash
content
Probing for ST M50FLW040B, 512 kB: probe_82802ab: id1 0x00, id2 0xf8,
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 M50FW002, 256 kB: probe_82802ab: id1 0xd4, id2 0x54,
id1 parity violation, id1 is normal flash content, id2 is normal flash
content
Probing for ST M50FW016, 2048 kB: probe_82802ab: id1 0xff, id2 0xff,
id1 parity violation, id1 is normal flash content, id2 is normal flash
content
Probing for ST M50FW040, 512 kB: probe_82802ab: id1 0x00, id2 0xf8,
id1 parity violation, id1 is normal flash content, id2 is normal flash
content
Probing for ST M50FW080, 1024 kB: probe_82802ab: id1 0xff, id2 0xff,
id1 parity violation, id1 is normal flash content, id2 is normal flash
content
Probing for Winbond W39V040FA, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60
Probing for Winbond W39V040FB, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60
Probing for Winbond W39V040FC, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60
Probing for Winbond W49V002FA, 256 kB: probe_jedec_common: id1 0xbf, id2 0x60
Probing for Winbond W39V080FA, 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 W39V080FA (dual mode), 512 kB: probe_jedec_common:
id1 0xbf, id2 0x60
Found SST flash chip "SST49LF004A/B" (512 kB, FWH).
Lock status for 0x000000 (size 0x010000) is 00, full access
Lock status for 0x010000 (size 0x010000) is 00, full access
Lock status for 0x020000 (size 0x010000) is 00, full access
Lock status for 0x030000 (size 0x010000) is 00, full access
Lock status for 0x040000 (size 0x010000) is 00, full access
Lock status for 0x050000 (size 0x010000) is 00, full access
Lock status for 0x060000 (size 0x010000) is 00, full access
Lock status for 0x070000 (size 0x010000) is 00, full access
Reading flash... done.
Restoring PCI config space for 00:1f:0 reg 0x4e
Am 23.02.2012 02:26 schrieb Stefan Tauner:
> The chip features a complete 1.0 SFDP JEDEC flash parameter table and also a
> vendor-specific extension table (defining voltages, lock bits etc).
> NB: the MX25L6436 uses the same RDID as the MX25L6405.
>
> Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>
with the changes below.
> On Mon, 20 Feb 2012 19:49:38 +0100 Carl-Daniel Hailfinger wrote:
>
>> Am 20.02.2012 17:07 schrieb Stefan Tauner:
>>> TODO:
>>> - how should the SFDP data be supplied/selected by the user?
>>> - option A (suggested one): add a default table with a legit complete table
>> Good idea.
>>
>>> and a programmer option to use a binary file instead.
>> I think having the file+builtin combination is overkill. Builtin should
>> be sufficient, unless you plan to focus more on making flashrom a
>> verification tool for flash vendors.
> some of them would need it. *cough* ;)
Right. I'd leave that as a possible future option, not something we
should change in the patch right now.
>>> […]
>>> + case JEDEC_SFDP:
>>> + if (emu_chip != EMULATE_WINBOND_W25Q64CV)
>>> + break;
>>> + offs = writearr[1] << 16 | writearr[2] << 8 | writearr[3];
>>> + /*
>>> + * FIXME: There is one dummy byte (i.e. 8 clock cycles) to be
>>> + * transferred after the address. Since we can not observe the
>>> + * clock, we would need to check for appropriate writecnt and/or
>>> + * readcnt and recalculate the parameters below.
>>> + */
>>> + /* FIXME: this could be more sophisticated. */
>>> + memcpy(readarr, sfdp_table + offs,
>>> + min(sizeof(sfdp_table) - offs, readcnt));
>> That memcpy will segfault if offs>sizeof(sfdp_table). Suggestion:
>> Replace the whole case statement with this (some 80 col reformatting may
>> be needed):
>>
>> case JEDEC_SFDP:
>> int toread;
>> if (emu_chip != EMULATE_WINBOND_W25Q64CV)
>> break;
>> if (writecnt < 4)
>> break;
>> offs = writearr[1] << 16 | writearr[2] << 8 | writearr[3];
>> /* The response is shifted if more than 4 bytes are written. */
>> offs += writecnt - 4;
> first of all... this breaks the implementation atm, because it uses
> a writecnt of 5 to include the dummy byte
>
> secondly i am not sure i understand your intention about the
> shifting. i guess the following: flashrom cant cope with concurrent
> write and read bytes... so you are specifying that if we write more
> bytes than needed we miss the bytes read in the beginning.. which
> seems fair enough.
>
> therefor i have changed 4 to 5 in the writecnt-related lines..
Not what I meant.
The big issue with SFDP and FAST READ and other commands is that the
dummy byte after command+address can be either a written or read byte
(the chip does not care). Our emulation should be able to handle both.
This means a writecnt of 4 is completely legal, but in that case we have
to set the copy destination to &readarr[1] instead of &readarr[0]. My
logic tried to address that, but it was not completely correct.
I have annotated your patch with my suggested changes at the end of this
mail. They seem to work in my tests.
> you are trying to support wrapping around for continous reads here
> (at least for the first wrap around afaics) while the specs say that
> this is not allowed at all (whatever that actually means...). so i
> would rather just read up to the boundary and reply 0xFF after that.
> makes that patch simpler too :)
We have a differing opinion about how to interpret the spec, but I'm
happy with your interpretation, especially if it simplifies the code.
>>> @@ -657,6 +730,7 @@ static int dummy_spi_send_command(struct flashctx *flash, unsigned int writecnt,
>>> case EMULATE_ST_M25P10_RES:
>>> case EMULATE_SST_SST25VF040_REMS:
>>> case EMULATE_SST_SST25VF032B:
>>> + case EMULATE_WINBOND_W25Q64CV:
>>> if (emulate_spi_chip_response(writecnt, readcnt, writearr,
>>> readarr)) {
>>> msg_pdbg("Invalid command sent to flash chip!\n");
> beside that i have also changed the emulated chip to the macronix chip,
> because it features a second table (that we might want to parse if it is
> used by other vendors too... one can at least hope :)
> it helps testing another execution path too...
Good.
> diff --git a/dummyflasher.c b/dummyflasher.c
> index afe0518..794a2f6 100644
> --- a/dummyflasher.c
> +++ b/dummyflasher.c
> @@ -629,7 +681,33 @@ static int emulate_spi_chip_response(unsigned int writecnt,
> /* emu_jedec_ce_c7_size is emu_chip_size. */
> memset(flashchip_contents, 0xff, emu_jedec_ce_c7_size);
> break;
> - default:
> + case JEDEC_SFDP: {
> + unsigned int toread;
> + if (emu_chip != EMULATE_MACRONIX_MX25L6436)
> + break;
> + if (writecnt < 5)
Replace with
if (writecnt < 4)
> + break;
> + offs = writearr[1] << 16 | writearr[2] << 8 | writearr[3];
Insert
+ /* SFDP expects one dummy byte after the address. */
+ if (writecnt < 5) {
+ /* The dummy byte was not written, make sure it is read
+ * instead. Shifting and shortening the read array does
+ * achieve the goal.
+ */
+ readarr += 5 - writecnt;
+ readcnt -= 5 - writecnt;
+ writecnt = 5;
+ }
> + /* The response is shifted if more than 4 bytes are written. */
> + offs += writecnt - 5;
> + /* The SFDP spec suggests wraparound is allowed as long as it
> + * does not happen in a single continuous read. */
> + if (offs >= sizeof(sfdp_table)) {
> + msg_pdbg("Wrapping the start address around the SFDP "
> + "table boundary (using 0x%x instead of 0x%x)."
> + "\n",
> + (unsigned int)(offs % sizeof(sfdp_table)),
> + offs);
> + offs %= sizeof(sfdp_table);
> + }
> + toread = min(sizeof(sfdp_table) - offs, readcnt);
> + memcpy(readarr, sfdp_table + offs, toread);
> + if (toread < readcnt)
> + msg_pdbg("Crossing the SFDP table boundary in a single "
> + "continuous chunk produces undefined results "
> + "after that point.\n");
> + break;
> + } default:
> /* No special response. */
> break;
> }
Regards,
Carl-Daniel
--
http://www.hailfinger.org/