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
pgpW4NeolJrst.pgp
Description: PGP signature
-- coreboot mailing list [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
