On Tue, May 5, 2009 at 9:28 AM, ron minnich <[email protected]> wrote: > On Tue, May 5, 2009 at 8:20 AM, Myles Watson <[email protected]> wrote: >> On Tue, May 5, 2009 at 9:06 AM, ron minnich <[email protected]> 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. Agreed. I think it should be used very sparingly even if we have it.
> 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. OK. >> 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. How hard would that be? I'd be happy to test on SimNOW and a Tyan board. Thanks, Myles -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
