[coreboot] Using lar from payload

[Jordan Crouse]

On 21/10/08 21:20 -0400, Kevin O'Connor wrote:
> Hi,
> 
> I was looking through the coreboot code to see if I could access the
> lar directly from SeaBIOS.  It looks like this is pretty straight
> forward, so I think I might end up trying it.
> 
> However, I ran into one thing that looks like it will make things a
> little difficult.  Currently, the lar code itself has the
> decompression code linked into it.  If lar traversing code is added to
> SeaBIOS, it looks like it will also have to support the various
> decompress functions.  That will lead to a notable increase in payload
> size.
> 
> I seem to recall reading somewhere that the original plan for the lar
> was to put the decompressors in their own lar files.  That would be
> ideal for the SeaBIOS case, because then it could invoke the
> decompress routines without having to duplicate them.
> 
> Would it be possible to move the decompressors to their own lar files?
> Looking at the code it doesn't seem too difficult.

I think this is doable.  To simplify everything, the code would have to
be run in place on the ROM, and it would have to run with only the stack
and nothing else (looking briefly at the lzma and nrv2b code, this wouldn't
be a problem, but it is a design consideration for future compression
schemes).

The LZMA code from v3 is 4236 bytes (off topic rant - there HAS to be a
cleaner C or assembly implementation out there somewhere).  I am pretty
sure nrv2b code is even smaller, but I don't have a compiled version handy.
Looking briefly at some of the other compression candidates (believe in 
change - vote LZO!), it looks like at most we would sacrifice somewhere
between 4k and 8k of space (probably 1-2 erase blocks in the brave new
partial rewrite world) per method.  Based on current usage,  I
expect that we would only end up using a single decompressor per LAR.  
Bonus is that the decompressor code would disappear from coreboot, so
our net size increase will be about zero (excepting alignment and LAR
headers).

The downside is that the utility will have to live as a component in
the LAR which will have an effect on performance when accessing the
other components.  A possibility is that we could point directly to the
decompressor in the master LAR header that lives underneath the
reset vector.  My magic eight ball sees a LAR re-design in our future,
so this is something that we should address (can anybody think of any
other "utilities" we can share in the lar.  ELF/multiboot loader comes
to mind).

In the mean time, somebody needs to play build master - we need the LZMA
and NRV2B code to be wholy contained in a single binary with an entry point.
Best best for a container is a ELF with a single .text segment and nothing
else.  A binary blob would be fine too, assuming that we know the entry
point.  Coreboot and the payloads will need to know how to jump to the 
code and back out. 

For the moment, I think that it would be best if the code lived separately
from the LAR utility and then was included while the ROM was constructed. 
I think this will encourage other compression schemes.  And we should take
advantage of this to clean up our existing compression schemes as well.
Maybe we can find some smaller code (fitting everything into a single
typical erase block would be heavenly).

Oh, and as long as I'm talking - we need to teach LAR how to use 
off-the-shelf libraries to _compress_ the payloads - if we could eliminate
all compression code from LAR and coreboot and libpayload - that would
rock!

Jordan
-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.