[coreboot] Using lar from payload

[Kevin O'Connor]

On Thu, Oct 23, 2008 at 08:41:26AM -0600, Jordan Crouse wrote:
> On 22/10/08 20:45 -0400, Kevin O'Connor wrote:
> > 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.

Hrmm - I thought the current decompress code runs from the rom today.
Aren't the LAR "boot block" functions all XIP?

>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.

I definitely don't want to implement services.

Why can't we run XIP from the rom?  Wont the icache mask the rom
latency?  Also, we're only talking about uncompressing a few files -
stage2, the payload, maybe one or two option roms.  Is the latency
going to be noticable (ie, on the order of a second)?

> 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.

By consume, you mean link with (eg, by adding to libpayload)?  Or, are
you suggesting it be somewhere where payloads can extract it from
flash at runtime?

Thanks,
-Kevin