On Wed, Jul 02, 2008 at 06:14:39PM +0200, Stefan Reinauer wrote:
On looking closer, all drivers do this. Erase before write. I don't think that is right?
I think a write of a given block should always automatically erase that very block first, but not more.
I disagree.
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.
This stands in contrast with the layout and (current) -s/-e options.
If I tell flashrom to only write to a six-byte area in the chip - I sure do not want the eraseblock to be erased.
That's hardware knowledge that the tool must have, not the user.
I disagree. This is a major characteristic of flash technology and I don't think we should be hiding it.
Look at the GALEP software for comparison. They have a check box for enabling/disabling automatic erase on chip program. Their software does not sport the same layout/-s/-e features as flashrom does, they only deal with full chip operations, yet IIRC they still have erase-before-write disabled by default.
(Otherwise she would use dd for the task)
Not really true, because the write sequence is still annoying to do by hand.
But I agree the way we do deleting + writing is ugly.
..
granularity
Not good enough I think. I do not want flashrom to ever erase flash cells that the user did not explicitly request.
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?
-E currently does erase, -w write and -v verify.
When running flashrom with -E, it will exit() after the erase is finished, and so -Ewv does not work.
Because all flash drivers (incorrectly IMO) erase before write, -Ewv is not needed, but since I want to change that, I also have to let flashrom do -Ewv in one go.
Swapopts is involved, because I would like to change -E into -e, to have lowercase options for all common commands.
I have been contemplating adding -T to run a full test cycle
Something that prints out TEST_OK_PREW or the human understandable version of that in the end? I love this idea.
Yeah.
-T should print a big warning "You are going to destroy the data on this chip if you run the command again with -f"
Yep, that's what I had in mind too.
//Peter