* 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
[email protected]
http://www.linuxbios.org/mailman/listinfo/linuxbios
