First some general discussion. More concrete patch comments will follow.
On Wed, Jul 11, 2007 at 12:15:17PM -0600, Jordan Crouse wrote:
This has the slight side effect of requiring that the user specify a size for the LAR when they create it, but I don't think thats really a bad thing.
One thing you might miss is that I've turned the path name of the bootblock into a constant name 'bootblock'.
Some ideas have been tossed around;
1. teach lar about flash chip sector sizes 2. bootblock at top or at bottom
1 means combining flashrom and lar somehow.. Thoughts?
Unfortunately this isn't as easy as a straight modulus operation because not all flash chips have uniform sector sizes across the entire chip.
The only way I can see it working is to create a lar for a flash chip rather than for a size. The flash chip id could be at the end of the lar (we have a few bytes left right?) and lars could also be generic, ie. not yet adapted to any chip. This generic lar is what we do right now, with a fixed 8k-or-so sector size and a fixed total size.
We would also want a flag for each file indicating whether it can be moved or if it must remain at it's current offset. This flag limits which lar files can be reflashed independently by flashrom.
And we'd need to add some lar knowledge to flashrom, but only enough to pick files out of lars.
2 depends on the target architecture. If we can autodetect we should not make it an option, just stick with assuming top for now and fix when it's needed.
It also requires that the user specify a size when the LAR is created.
So we're approaching the flash chip. Can we do something more clever than just specify the size already? I'm not sure. I think a fixed size is fine for now.
//Peter