diff options
author | Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> | 2009-05-26 21:25:08 +0000 |
---|---|---|
committer | Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> | 2009-05-26 21:25:08 +0000 |
commit | 15aa7c65430312c14df2854f6086c5e44de9a79d (patch) | |
tree | 1f802b306afb2a7ab4f1009da21ac202488fda25 /sst28sf040.c | |
parent | 90e8e613183a817553511f670852100a42fe39be (diff) | |
download | flashrom-15aa7c65430312c14df2854f6086c5e44de9a79d.tar.gz flashrom-15aa7c65430312c14df2854f6086c5e44de9a79d.tar.bz2 flashrom-15aa7c65430312c14df2854f6086c5e44de9a79d.zip |
Use REMS instead of RES in the ICH SPI default opcode table
RES is Read Electronic Signature (1 Byte, identical for different chips)
REMS is Read Electronic Manufacturer Signature (2 Bytes, mostly unique)
RDID is Read JEDEC ID (3 bytes, unique)
Of the chips which don't support RDID, a sizable portion supports REMS
which gives us both a manufacturer ID and a device ID. This is clearly
superior to having only a device ID (the RES case) which has multiple
documented collisions.
The RES/REMS problem is aggravated by inconsistent naming in vendor data
sheets. What's in a name? Considering that we have 1-byte IDs, 2-byte
IDs and 3+byte IDs with varying names but mostly consistent opcodes, it
makes sense to set our own standard about how the opcodes are called.
The best way forward would be to have the ICH SPI driver reprogram the
opcode menu on the fly if the opcode menu doesn't contain the requested
opcode and the opcode menu is not locked. Until that happens, this patch
improves detection accuracy by a factor of 256 for some chips.
Corresponding to flashrom svn r549.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Tested-by: Uwe Hermann
with the flash chip "SST SST25VF040.REMS".
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
Diffstat (limited to 'sst28sf040.c')
0 files changed, 0 insertions, 0 deletions