On Fri, Feb 26, 2010 at 12:26 PM, Stefan Reinauer <[email protected]> wrote: > On 2/26/10 2:23 AM, Stefan Reinauer wrote: > > On 2/25/10 11:44 PM, Myles Watson wrote: >> >> In case someone wants to look into this. The attached patch tries to do >> relocable coreboot_ram. It does not work. It looks like dynamic linker >> does not >> fix call to hardware main in the c_start.o - reason is unknown. > > Relocating coreboot_ram seems like a great idea. It seems like there was a > lot of discussion on the mailing list with v3 about PIC and why it couldn't > work for us. My memory about it is fuzzy now, but a little searching might > turn something up.
I have recently put a lot of effort into getting the x86 port of U-Boot to fully relocatable. Have a look at the git tree of U-Boot. This is the one that does all the work: http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h=1c409bc7101a24ecd47a13a4e851845d66dc23ce > > The idea sounds incredibly sweet. > > But lets make sure we gain from it in the end... > Relocating coreboot_ram would safe us two 1MB sized memcpy on the resume > path, so we would safe at least 200 microseconds of boot time in the case > we're resuming. (assuming memory is 6.4G/s, DDR2-800 aka PC2-6400) .... > 0.2milliseconds of 400+... worth the complexity? > > minus the time added needed by the linker for the linking.. > > How does linking go with lzma? > - do the relocations require more RAM? How much? Yes, but only a little. The binary size is larger as it needs the relocation information table, but this does need need to be loaded into RAM. > - can the sections and relocations be lzma'ed together? or are they separate > files in CBFS? > Regards, Graeme -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
