[coreboot] r3406 - trunk/util/flashrom
Stefan Reinauer
stepan at coresystems.de
Wed Jul 2 18:14:39 CEST 2008
Peter Stuge wrote:
> On looking closer, all drivers do this. Erase before write. I don't
> think that is right?
>
> I would like that behavior only when explicitly saying both erase and
> write. Otherwise, the layout stuff will be erasing and rewriting data
> that is not actually part of the selected region in the layout.
>
I think a write of a given block should always automatically erase that
very block first, but not more.
There should not be a situation where the user has to know that she can
only write the flash after she set all the bits to 1 by erasing it.
That's hardware knowledge that the tool must have, not the user.
(Otherwise she would use dd for the task)
But I agree the way we do deleting + writing is ugly.
In /dev/bios my data structure for the flash chips had an array of
blocks for each chip, so /dev/bios would see if the block at a given
address is 4, 8, 112K or whether it could write the whole chip with a
granularity of 256 bytes.
>>> Better make -Ewv work then, and apply the swapopts patch for -ewv. :)
>>>
>> and -ezytgrl !
>>
>
> Hm? :)
>
That's what I thought, too, when I read that line. What's Ewv, ewv and
why is swapopts involved in automatically erasing flash chips?
> I have been contemplating adding -T to run a full test cycle on a
> chip, actually. Automated testing is always nice. Maybe require -Tf
> to actually do anything?
>
Something that prints out TEST_OK_PREW or the human understandable
version of that in the end? I love this idea.
-T should print a big warning "You are going to destroy the data on this
chip if you run the command again with -f"
Stefan
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080702/171c31f9/attachment.sig>
More information about the coreboot
mailing list