On Tue, May 5, 2009 at 9:06 AM, ron minnich <[email protected]> wrote: > On Tue, May 5, 2009 at 5:29 AM, Myles Watson <[email protected]> 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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
