* Ed Swierk eswierk@arastra.com [070811 03:58]:
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.
I think you observed an interesting point. I wonder whether anything in that area will ever require that restoration. I am pretty close to say it's just bogus and dangerous and should be dropped, just as you do in your patch.
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;
}