Hi, I've a chip which is from SST and labeled as PH29EE010 150-3CF. flashrom doesnt detect this chip although it should as -L stats: flashrom -L | grep 29EE010 SST SST29EE010 P R W 128 Parallel
if I check for the chip it still fails and reads flash content: flashrom -V -c SST29EE010 flashrom v0.9.2-r1039 on Linux 2.6.27-3 (i586), built with libpci 2.2.4-pre4, GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21), little endian flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OS timer resolution is 9 usecs, 200M loops per second, 10 myus = 17 us, 100 myus = 231 us, 1000 myus = 1042 us, 10000 myus = 10133 us, 36 myus = 45 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: "P5A-B" DMI string baseboard-version: "REV 1.XX" DMI string chassis-type: "Unknown" Found chipset "ALi M1533", enabling flash write... chipset PCI ID is 10b9:1533, OK. This chipset supports the following protocols: Non-SPI. Probing for SST SST29EE010, 128 KB: probe_jedec_common: id1 0x25, id2 0xfb, id1 is normal flash content, id2 is normal flash content No EEPROM/flash device found. Note: flashrom can never write if the flash chip isn't found automatically.
but if I now probe for Winbond W29C011 then flashrom of course fails but shows the right flash ID: flashrom -V -c W29EE011 flashrom v0.9.2-r1039 on Linux 2.6.27-3 (i586), built with libpci 2.2.4-pre4, GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21), little endian flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OS timer resolution is 8 usecs, 29M loops per second, delay more than 10% too short (got 24% of expected delay), recalculating... 32M loops per second, delay more than 10% too short (got 25% of expected delay), recalculating... 34M loops per second, delay more than 10% too short (got 27% of expected delay), recalculating... 33M loops per second, delay more than 10% too short (got 25% of expected delay), recalculating... 32M loops per second, delay loop is unreliable, trying to continue 10 myus = 11 us, 100 myus = 24 us, 1000 myus = 285 us, 10000 myus = 1605 us, 32 myus = 14 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: "P5A-B" DMI string baseboard-version: "REV 1.XX" DMI string chassis-type: "Unknown" Found chipset "ALi M1533", enabling flash write... chipset PCI ID is 10b9:1533, OK. This chipset supports the following protocols: Non-SPI. Probing for Winbond W29EE011, 128 KB: probe_w29ee011: id1 0xbf, id2 0x07 No EEPROM/flash device found. Note: flashrom can never write if the flash chip isn't found automatically.
so what is obvious is the huge difference with the calibrating loop, and then that the probe for W29EE011 gives "id1 0xbf, id2 0x07" which is exactly what the datasheet from SST outlines for the SST29EE010 ...
I really wonder what goes on there sine - as -L shows - this chip is marked as "P R W" ...
Gün.
Am Freitag, den 11.06.2010, 02:54 +0200 schrieb Guenter:
Hi, I've a chip which is from SST and labeled as PH29EE010 150-3CF.
I am comparing the two differences in your output:
flashrom -V -c SST29EE010
[...]
Calibrating delay loop... OS timer resolution is 9 usecs, 200M loops per second, 10 myus = 17 us, 100 myus = 231 us, 1000 myus = 1042 us, 10000 myus = 10133 us, 36 myus = 45 us, OK.
Delay loop calibration worked fine here, but...
flashrom -V -c W29EE011
[...]
Calibrating delay loop... OS timer resolution is 8 usecs, 29M loops per second, delay more than 10% too short (got 24% of expected delay), recalculating... 32M loops per second, delay more than 10% too short (got 25% of expected delay), recalculating... 34M loops per second, delay more than 10% too short (got 27% of expected delay), recalculating... 33M loops per second, delay more than 10% too short (got 25% of expected delay), recalculating... 32M loops per second, delay loop is unreliable, trying to continue 10 myus = 11 us, 100 myus = 24 us, 1000 myus = 285 us, 10000 myus = 1605 us, 32 myus = 14 us, OK.
... here delay calibration fails horribly. Delay loop calibration precision should be completely independent of the chip you specify. Is this problem reproducible? The result is that the delays in the probe sequence are much shorter in the second flashrom run than they are in the first flashrom run.
Probing for SST SST29EE010, 128 KB: probe_jedec_common: id1 0x25, id2 0xfb, id1 is normal flash content, id2 is normal flash content No EEPROM/flash device found.
Also, another difference is that this chip is probed with the JEDEC standard probe command, while
Probing for Winbond W29EE011, 128 KB: probe_w29ee011: id1 0xbf, id2 0x07 No EEPROM/flash device found.
this chip is probed with a traditional probe command. The traditional probe command consists of two parts, one is a "general extended command prefix" with extended meaning anything except "write", and the second command tells that the expended command requested is "probe". After JEDEC standardization, this "general extended command prefix" is only used in front of erase instructions, so you could also call it "erase prefix". And now guess what happens: There are flash chips that really do expect an erase command if they get the erase prefix and get totally confused if no valid erase command is sent after this prefix.
This is why you have to explicitly request the traditional probe for the W29EE011.
so what is obvious is the huge difference with the calibrating loop, and then that the probe for W29EE011 gives "id1 0xbf, id2 0x07" which is exactly what the datasheet from SST outlines for the SST29EE010 ...
According to the data sheet, a delay of 10µs is needed after the probe command before reading the ID, but possibly only with the more modern probe command. The classical probe command is not described in that detail in the data sheet.
So there are two possibilities about what your problem could be a) You have a chip from an ancient series that only supports the classical probe command and not the JEDEC probe command b) The timing is stricter on the JEDEC probe command and therefore on your system where the flashrom delay loop seems unreliable the JEDEC probe fails
Could you please check the output of a "flashrom -V" run without specifying a chip? It would be interesting whether the ID can be read successfully for any of the probes except the W29EE011 probe.
Regards, Michael Karcher
Hi Michael, Am 11.06.2010 08:04, schrieb Michael Karcher:
Am Freitag, den 11.06.2010, 02:54 +0200 schrieb Guenter:
I've a chip which is from SST and labeled as PH29EE010 150-3CF.
I am comparing the two differences in your output:
flashrom -V -c SST29EE010
[...]
Calibrating delay loop... OS timer resolution is 9 usecs, 200M loops per second, 10 myus = 17 us, 100 myus = 231 us, 1000 myus = 1042 us, 10000 myus = 10133 us, 36 myus = 45 us, OK.
Delay loop calibration worked fine here, but...
flashrom -V -c W29EE011
[...]
Calibrating delay loop... OS timer resolution is 8 usecs, 29M loops per second, delay more than 10% too short (got 24% of expected delay), recalculating... 32M loops per second, delay more than 10% too short (got 25% of expected delay), recalculating... 34M loops per second, delay more than 10% too short (got 27% of expected delay), recalculating... 33M loops per second, delay more than 10% too short (got 25% of expected delay), recalculating... 32M loops per second, delay loop is unreliable, trying to continue 10 myus = 11 us, 100 myus = 24 us, 1000 myus = 285 us, 10000 myus = 1605 us, 32 myus = 14 us, OK.
... here delay calibration fails horribly. Delay loop calibration precision should be completely independent of the chip you specify. Is this problem reproducible? The result is that the delays in the probe sequence are much shorter in the second flashrom run than they are in the first flashrom run.
I tried to reproduce it; and it happens rarely now and then; I tried this with a script which runs flashrom 50 times, and few times the script showed 15, 20 times this issue, but mostly the script ran without this issue. I can though say that I saw this issue on four machines already - all different hardware - but all had a similar AMD processor; one was a AMD Geode, and the others were AMD K6-2 400/500 MHz. So maybe its a problem with older AMD processors?
Probing for SST SST29EE010, 128 KB: probe_jedec_common: id1 0x25, id2 0xfb, id1 is normal flash content, id2 is normal flash content No EEPROM/flash device found.
Also, another difference is that this chip is probed with the JEDEC standard probe command, while
Probing for Winbond W29EE011, 128 KB: probe_w29ee011: id1 0xbf, id2 0x07 No EEPROM/flash device found.
this chip is probed with a traditional probe command. The traditional probe command consists of two parts, one is a "general extended command prefix" with extended meaning anything except "write", and the second command tells that the expended command requested is "probe". After JEDEC standardization, this "general extended command prefix" is only used in front of erase instructions, so you could also call it "erase prefix". And now guess what happens: There are flash chips that really do expect an erase command if they get the erase prefix and get totally confused if no valid erase command is sent after this prefix.
This is why you have to explicitly request the traditional probe for the W29EE011.
so what is obvious is the huge difference with the calibrating loop, and then that the probe for W29EE011 gives "id1 0xbf, id2 0x07" which is exactly what the datasheet from SST outlines for the SST29EE010 ...
According to the data sheet, a delay of 10µs is needed after the probe command before reading the ID, but possibly only with the more modern probe command. The classical probe command is not described in that detail in the data sheet.
So there are two possibilities about what your problem could be a) You have a chip from an ancient series that only supports the classical probe command and not the JEDEC probe command
hmm, I have 2 other chips of different production year which I could test with once I have some play time :)
b) The timing is stricter on the JEDEC probe command and therefore on your system where the flashrom delay loop seems unreliable the JEDEC probe fails
nope; probing fails always - regardless of delay loop result (which is in most cases ok, as I wrote above).
Could you please check the output of a "flashrom -V" run without specifying a chip? It would be interesting whether the ID can be read successfully for any of the probes except the W29EE011 probe.
no, the chip ID doest show up with any other probe.
Perhaps it is a timing problem; can you perhaps suggest some values I might try on this board / chip combo? I dont know what the timing values mean, maybe you can explain them a bit? F.e. I saw somewhere: .probe_timing = 1, /* 150 ns */ so what stands the usual 10 for? Or should I try with TIMING_IGNORED?
Thanks, Gün.
-
Guenter -
Michael Karcher