On Sun, Sep 27, 2009 at 11:15 PM, Joakim Tjernlund
<joakim.tjernl...@transmode.se> wrote:
> Wolfgang Denk <w...@denx.de> wrote on 23/09/2009 20:23:14:
>>
>> Dear Peter Tyser,
>>
>> In message <1253710639.3968.19.ca...@ptyser-laptop> you wrote:
>> >
>>
>> > Nice! It'd be great to have the magical 20 lines of assembly put into
>> > some semi-understandable c.
>>
>> :-)
>
> I have worked some more on this but all boards need to be converted to use
> the new C-variants.
>
> Anyhow, I have also been thinking/working on making U-boot
> fully PIC and reached a important conclusion. The GOT holds absolute
> ptr values and there is not much one can do about it sans modifying gcc.
> So before u-boot is relocated to RAM one must manually add any offset to
> all global/static data and string literals. The majority of strings
> are passed directly to printf and friends so the offset can be added inside
> printf. The remaining few data accesses needs to be dealt with directly,
> example:
> - for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
> + for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr;
> ++init_fnc_ptr) {
>
> Only code called before relocation to RAM needs this, mostly the _f()
> functions.
> Would this be an acceptable change?
>
I think you might want to look at the x86 relocation work I have just
submitted for comment. It processes all relocation sections generated by
gcc/ld using the ELF data structures defined in elf.h - I generate code at
a text base equal to the boot flash (0x38004000) so I can easily check if
the relocation entry is with the executable. After the elf relocation
processing, there is ZERO need for any offset compensation once I've jumped
into the relocated code
And its all in C ;)
> Jocke
>
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
