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