On Sun, 2009-09-27 at 15:15 +0200, Joakim Tjernlund 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:
> > >
> > > My "fix" to the linker script was to change:
> > > __bss_start = .;
> > > into:
> > > __bss_start = . | 4;
> > >
> > > ie, a big hack, but it did work:) I'll take a peek at a more proper
> > > link script workaround.
> >
> > 32 bit alignment of the BSS segment might not be sufficient. Be
> > careful!
>
> Any progress on this ?
I've been swamped the last few days, but think I have a workaround. I
hope to test it tomorrow or tues. I'll send an email when I have a more
definitive answer.
> > > 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.
Great!
> 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?
Could you describe the advantages of generating a fully PIC U-Boot
image? I understand you could execute the image from different places
in flash, but on the boards I've worked with this isn't a huge concern.
For example, its possible to have a preliminary flash mapping that
U-Boot executes from, then after relocation to RAM that flash mapping
can be modified. So where U-Boot initially executes from isn't all that
important for me. Is there some killer feature that a fully PIC U-Boot
provides to make adding the got_off() workarounds you mention
worthwhile?
Thanks,
Peter
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
