We've been using flashrom quite successfully for months to program an
SST49LF160C chip, but today we came across one flash image that
flashrom kept failing to verify after writing it.
When we dumped the contents of the flash after the verify, we saw that
one byte at offset 0x1e5555 was getting changed from 0x4c to 0x08.
I managed to narrow down the corruption to the chip probe process,
when probe_28sf040() is called followed by probe_jedec(). The
comments in probe_28sf040() indicate that it's trying to restore the
value at offset 0 after writing probe commands to that location. But
the chip interprets the write to offset 0 as the beginning of a
command, and the reads and writes in the subsequent call to
probe_jedec() somehow forms a write-byte command if some magic values
are present in the flash (is it a coincidence that the part ID is
0x4c?).
All of this sounds ridiculously unlikely, and without understanding
the details of the flash protocols it's hard to know whether I'm
misdiagnosing the problem. The attached patch removes the seemingly
unnecessary restoring of the value at location 0 in probe_28sf040(),
and indeed fixes the problem.
--Ed
Index: LinuxBIOSv2-2571/util/flashrom/sst28sf040.c
===================================================================
--- LinuxBIOSv2-2571.orig/util/flashrom/sst28sf040.c
+++ LinuxBIOSv2-2571/util/flashrom/sst28sf040.c
@@ -106,10 +106,7 @@ static __inline__ int write_sector_28sf0
int probe_28sf040(struct flashchip *flash)
{
volatile uint8_t *bios = flash->virt_addr;
- uint8_t id1, id2, tmp;
-
- /* save the value at the beginning of the Flash */
- tmp = *bios;
+ uint8_t id1, id2;
*bios = RESET;
myusec_delay(10);
@@ -127,8 +124,6 @@ int probe_28sf040(struct flashchip *flas
if (id1 == flash->manufacture_id && id2 == flash->model_id)
return 1;
- /* if there is no SST28SF040, restore the original value */
- *bios = tmp;
return 0;
}
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
