On Wed, Jul 02, 2008 at 03:33:10PM +0200, svn@coreboot.org wrote:
Also enable unlocking
Great!
However, I would like to remove the call to erase_winbond_fwhub() in write_winbond_fwhub() - this driver and maybe one or two others do this, and it doesn't seem right. Convenient, sure, but not right.
Better make -Ewv work then, and apply the swapopts patch for -ewv. :)
//Peter
Peter Stuge wrote:
On Wed, Jul 02, 2008 at 03:33:10PM +0200, svn@coreboot.org wrote:
Also enable unlocking
Great!
However, I would like to remove the call to erase_winbond_fwhub() in write_winbond_fwhub() - this driver and maybe one or two others do this, and it doesn't seem right. Convenient, sure, but not right.
I don't get your point, sorry.
Better make -Ewv work then, and apply the swapopts patch for -ewv. :)
and -ezytgrl !
On Wed, Jul 02, 2008 at 04:24:36PM +0200, Stefan Reinauer wrote:
However, I would like to remove the call to erase_winbond_fwhub() in write_winbond_fwhub() - this driver and maybe one or two others do this, and it doesn't seem right. Convenient, sure, but not right.
I don't get your point, sorry.
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.
Better make -Ewv work then, and apply the swapopts patch for -ewv. :)
and -ezytgrl !
Hm? :)
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?
//Peter
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
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
Peter Stuge wrote:
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.
Not at all.
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.
If necessary for those 6 byte to write, yes, that is exactly what you want.
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.
Yes, everyone knows the galep software is crap for exactly stuff like that. The new version does not allow autoerase anymore.
On Wed, Jul 02, 2008 at 06:43:19PM +0200, Stefan Reinauer wrote:
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.
If necessary for those 6 byte to write, yes, that is exactly what you want.
No. I want an error if it is neccessary and I did not also ask for erase.
There are at least two cases where this matters;
Flash coreboot with ff:ff MAC for onboard, set it up to download a nifty flashrom-derivative payload that will reflash the MAC with something useful before shipping. This operation should not automatically erase and rewrite any data that was already in the chip.
Add new files to v3 LAR in flash chip, this should also never erase and rewrite data that was in the chip.
I think you could come with even more. :)
Because the user has not requested erase, I think erasing is a critical bug. :\
Look at the GALEP software for comparison.
Yes, everyone knows the galep software is crap for exactly stuff like that. The new version does not allow autoerase anymore.
Too bad, because it is a nifty feature. But can you imagine the customer response if they _forced_ autoerase (like flashrom) ?
//Peter
-
Peter Stuge -
Stefan Reinauer