[coreboot] cbfs XIP patch

Myles Watson mylesgw at gmail.com
Tue May 5 17:20:36 CEST 2009


On Tue, May 5, 2009 at 9:06 AM, ron minnich <rminnich at gmail.com> wrote:
> On Tue, May 5, 2009 at 5:29 AM, Myles Watson <mylesgw at gmail.com> wrote:
>
>> Someone needs to fix remove then.  Right now it moves all entries after it
>> and zeroes the new space.  I guess most of my confusion came from the
>> implementation/design gap.
>
> I think it was my confusion, not yours :-)
>
> But I think we have to have clean support for XIP in ROM, which means
> we have to have a way for cbfs to place a block of code in a
> designated place.
So can we force the compiler to make everything inside a block
relative so that it can be position-independent?

> I like the idea of having the ROM stages visible in cbfs.
So do I.

> If we are certain we don't need XIP then we don't need this patch. But
> if we have XIP we can
> remove some fairly confusing __asm__ code in failover, as well as the
> attendant load scripts.
Does a normal image need to be XIP?

> Also, since the
> stage header has the entry point as well, we get rid of the need to
> have a reset vector at the end of the normal
> and failover ROM images -- a much cleaner way to go.
Yes.

> Some suggestions:
> - adopt a coarser granularity. Were we to adopt, e.g., 512B as a block
> size, then at most the walking code would have to check  4096 items
> on even a 2 Mbyte ROM (as opposed to the current 128K items)
> - zero fill
> - NEXT pointer
>
> All of these will work.
I think this is the easy part.  The harder problems have to do with
what we want to allow to be constrained to a specific location.  The
fewer of those the better to me.

Thanks,
Myles




More information about the coreboot mailing list