[coreboot] Using lar from payload

[Kevin O'Connor]

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