[flashrom] probe for SST20EE010 fails

[Michael Karcher]

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