* Ed Swierk <[EMAIL PROTECTED]> [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; > } > -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios