Hi Jordan,
On Wed, Oct 22, 2008 at 09:36:54AM -0600, Jordan Crouse wrote:
On 21/10/08 21:20 -0400, Kevin O'Connor wrote:
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 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.
[...]
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.
The current lar code supports running a LAR blob in ROM (execute_in_place() in lib/lar.c). I was kinda thinking that one could change process_file() to call something like execute_in_place("ulzma") instead of calling ulzma() directly.
I didn't think performance would be that important, as I thought we currently only decompress stage2 and the payload. Are extra LAR scans very expensive?
Thanks for your comments. -Kevin