[LinuxBIOS] New LAR access functions
peter at stuge.se
Thu Jul 12 20:16:10 CEST 2007
On Thu, Jul 12, 2007 at 07:59:42PM +0200, Stefan Reinauer wrote:
> * Peter Stuge <peter at stuge.se> [070712 19:25]:
> > Re these files, I desperately want a fallback so that something
> > intelligent can be done also without any flash description files.
> This could just be assume a block size of 4, 8 or 16k for the
> archive. Currently blocks are aligned to 16 bytes. Smallest sector
> size I have seen was 256 bytes I think.
Block size could be 1 until the larball needs to be repacked to match
the flash chip contets so that flashrom can reflash a single file
from it. Then block sizes need to match the flash chip.
It could be argued that flashrom shouldn't try to fix the larball
since this is an error in the process preceding the flashrom
invocation and the process should be fixed to produce correct
larballs for the target flash chip?
> > I would love to compile the latest list available into the binary
> > at build time, and allow a newer text file to override it at run
> > time. (Maybe even replace in the binary with ELF tricks? :)
> objcopy is your friend here. Hey, we could pack the descriptions
> into a lar file and link that into the binary ;)
I like it.
> > Hard to say. Sharing of single flash chips between multiple readers
> > on a single board supports having varying sector sizes, but lower
> > cost probably supports uniform sector sizes. OTOH flash may be so
> > cheap anyway that the little extra cost for varying sector sizes win.
> What does SPI do? Just like DIP, PLCC will probably go away in some
> ys. (By the time we have large flash chips ;-)
Fortunately this doesn't depend on the interface. It's just about how
the memory is organized internally.
> > At least they know about sectors and page sizes already.
> Do they? ;) Not for the non-uniform sizes at least...
> Usually flashing works like this:
> erase all of the chip with jedec
> rewrite it with whatever function is defined to do so
The few drivers I just checked didn't do chip erase but did sector
erase over the entire chip instead. (Chip erase wasn't available at
Yes, it needs a bit of hacking. No doubt.
> > Note this means the bootblock eats up 64kb of SST49LF080A chips.
> > Plenty of room for serial recovery yay. :)
> :-) On the 080A we can almost say we have that space.
Agreed. Not much to do anyway. Just make the most of the space.
> Our bootblock is already pretty large (16k).. I wonder whether we
> can shrink it. (Before we make it big again.. :)
That would be nice. What takes up 16k?
More information about the coreboot