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