[coreboot] cbfs XIP patch

ron minnich rminnich at gmail.com
Tue May 5 17:28:01 CEST 2009


On Tue, May 5, 2009 at 8:20 AM, Myles Watson <mylesgw at gmail.com> wrote:
> On Tue, May 5, 2009 at 9:06 AM, ron minnich <rminnich at gmail.com> wrote:
>> 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've tried in v3, but have been warned that the way we get PIE in v3 is really
not legitimate, and not guaranteed to keep working. Some form of PIE
that gnubin experts would accept
would be very good to have.

I don't think we'll ever escape the need for some way to force files
into specific locations. The ROMSTRAP
code from nvidia is not the first example, nor will it be the last.


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

It is now and always has been. I don't know how to make it otherwise.

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

I agree. The chipset vendors will always create challenges in this
area, however. And we must still solve our own ROM code issues as
well.

One option is to do the FILO trick and make %cs point to the start of
the ROM code that you are running. This is easy: have a GDT entry for
fallback code and a GDT entry for normal code. Then it suffices to do
load the %cs with the right segment index for fallback or normal.
This approach would remove the need for XIP for our ROM segments.

ron




More information about the coreboot mailing list