On Fri, Feb 26, 2010 at 12:26 PM, Stefan Reinauer stepan@coresystems.de 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=1c409bc710...
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