-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I have taken memtest reloc.c and glued it into libpayload. Check attached patch. It adds -fPIC too.
Then I taken the tint payload and make it dynamic via:
../libpayload/bin/lpgcc -shared -o tint.elf tint.o engine.o io.o utils.o
I added -shared to following rule
$(TARGET).elf: $(OBJS) $(CC) -shared -o $@ $(OBJS)
And -fPIC to CFLAGS
I used Qemu to test this. And it does start tint! Then I changed the loading address with attached simple patch coreboot_change_base.patch and STILL does work! I think I have more luck than I thought.
(Except the stack, I cheated and created the temp 4K stack, but I think this can be fixed quite easily)
Questions:
1) Does it work really work? I can't believe it.
2) If yes I think we will need to ask Eric to re-license this for libpayload
3) I think we can use this to make coreboot_ram to run on ANY address :) if someone manages to add -fPIC to our build system. When the coreboot_ram is created one need to add -shared too.
Rudolf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi again,
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.
Rudolf
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.
Thanks, Myles
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Well It could work. I forgot to attach the actual linker ;) again taken from memtest86 This does work for libpayload payloads (tint), but here it does not.
Rudolf
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.
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?
What other benefits are there?
Stefan
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.
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? - can the sections and relocations be lzma'ed together? or are they separate files in CBFS?
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
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..
Is this WB?
How does linking go with lzma?
The linker is called in c_start.o and it is reloc.c "stolen" from memtest86. It is a part of the resulting image.
- do the relocations require more RAM? How much?
They do, i think it is just few kilobytes
- can the sections and relocations be lzma'ed together? or are they
separate files in CBFS?
so far I packed resulting image to one text section, just to be able to load it with the stage loader.
Oh and it does work, I made a mistake not to link it to addr 0, but the dynamic loader is doing its own relocation so it got twice big addresses.
Now if only I could fix AMD CAR. I think Stephan is right that dynamic loader might add more complexity. It took me less time to get it working, then fixing the AMD K8 CAR to handle the resume copy properly :)
Anyway, I proved that we can have it, nice result too (at least for me ;)
I will try to fix the AMD CAR somehow now to make resume/suspend work again.
Rudolf
On Thu, Feb 25, 2010 at 01:03:58AM +0100, Rudolf Marek wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I have taken memtest reloc.c and glued it into libpayload. Check attached patch. It adds -fPIC too.
Nice!
However, I think there is a simpler way to achieve the same goal.
The "-fPIC" option causes the compiler to place all relocations into separate pages. This really helps on multi-process operating systems where the OS can then share all the code pages between multiple applications. When the same program/library is loaded twice it only needs to duplicate the handful of relocation pages - all the code can be shared.
On coreboot there isn't any value in placing all the relocations into separate pages as the code isn't going to be "shared" like it would on an OS.
In order to relocate, I think one really only needs to get at the relocation information. So, "-fPIC" shouldn't be needed - instead, one should be able to use something like the ld "--emit-relocs" flag to keep the relocation information. Once the relocs are available, the SELF format could store them as an array of offsets in a new "section". To relocate one should then be able to just do:
u32 reloc_count = ...; u32 *relocs = ...; void *final_code_loc = ...; u32 relocation_delta = final_code_loc - SELF_header_code_loc;
for (i=0; i<reloc_count; i++) *(u32*)(final_code_loc + relocs[i]) += relocation_delta;
The relocations contain a list of all the places in the program that rely on a fixed address. Once we have that list, it should be straight forward to update the program for a new fixed location.
-Kevin
-
Graeme Russ -
Kevin O'Connor -
Myles Watson -
Rudolf Marek -
Stefan Reinauer