[coreboot] Using lar from payload
jordan.crouse at amd.com
Thu Oct 23 16:41:26 CEST 2008
On 22/10/08 20:45 -0400, Kevin O'Connor wrote:
> 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.
Well, esentially, thats what execute_in_place() does - but thats
just semantics. One problem though, execute_in_place doesn't grok
arguments, which you will need to do the compression.
> 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?
Anything having to do with the ROM is expensive. In fact, after talking
to Marc and others, I have serious doubts that this method will be very
effective. So, If you don't execute from ROM, then it gets shadowed
everywhere. So then coreboot and the payloads are going to copy the
compressor to memory, but where should it live? Then you think that
the code should stay resident, and then you are talking about services,
and you are right back at the discssion about keeping a permanent service
middle layer in memory, and then that distracts you from the matter at hand.
So I'll have to retract what I said yesterday - I'm back to thinking that
our best bet is a generic compression library containing the LZMA and
nrv2b code that payloads can consume. You still have the duplication,
but at least you don't need to get your hands dirty with the code.
Systems Software Development Engineer
Advanced Micro Devices, Inc.
More information about the coreboot