[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.dehttp://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