[flashrom] probe for SST20EE010 fails
lists at gknw.net
Mon Jun 21 17:12:42 CEST 2010
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
>> 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?
More information about the flashrom