[U-Boot] Build failures with older toolchain

[Premi, Sanjeev]

> -----Original Message-----
> From: u-boot-bounces at lists.denx.de 
> [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Premi, Sanjeev
> Sent: Tuesday, November 30, 2010 7:56 PM
> To: u-boot at lists.denx.de
> Subject: Re: [U-Boot] Build failures with older toolchain
> 
> > -----Original Message-----
> > From: u-boot-bounces at lists.denx.de 
> > [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Premi, Sanjeev
> > Sent: Monday, November 29, 2010 8:38 PM
> > To: Wolfgang Denk
> > Cc: u-boot at lists.denx.de
> > Subject: Re: [U-Boot] Build failures with older toolchain
> > 
> 
> [snip]...[snip]
> 
> > > >
> > > >      I am process of downloading the 2009q3 version from 
> > > codesourcery
> > > >      Albert mentioned he is using it. Are you on the same 
> > version as
> > > >      well?
> > > 
> > > No, I'm using ELDk 4.2
> > 
> > [sp] Okay, so I downloaded both 2009-q3 and 2010.09-50 
> versions of the
> >      Codesourcery Lite edition.
> >      
> >      There is no difference in the observations between 
> > 2009q3 and 2010q1.
> > 

[snip]...[snip]

There were some good patches posted recently esp the bss_debug
tool and fix for ARM relocation from Andreas. Applied them in
order to get more information.

In addition, added print indicating the function being called
in for (init_funcptr= ....) loop within board_init_f().

Also added a print in the function omap3_evm_get_revision() just
to see if it ever gets called in due to incorrect sequencing.

I could confirm that functions in init_sequence[] are called
and omap3_evm_get_revision() is not called in this sequence.

When everything failed, I went back to the u-boot.lds and
changed the way overlay is defined.

...AND PROBLEM SEEMS TO BE SOLVED!

I can now compile u-boot with both 2009q1 and 2010q1 without
any error. (yet to try with 2010.09)

To verify, I wanted to do a before-and-after comparison but
couldn't have done for the omap3_evm - used omap3_beagle instead.

I haven't yet tried running the binary on the board; but here
are top level observations:

1) .bss and .rel.dyn are starting at same address.
2) The size of .rodata has increased. (Why? not yet spent time on?)

Sending the patch in next few mins:

~sanjeev

(Comparison: "<before" and ">after")

753c753
< .rodata         0x80035578     0x9f38
---
> .rodata         0x80035578     0x9f46
757c757
<  .rodata        0x8003571c       0xbc arch/arm/lib/libarm.o
---

=== [contents deleted] ===

< .u_boot_cmd     0x80041aac      0x658
---
> .u_boot_cmd     0x80041abc      0x658

=== [contents deleted] ===

967,968c967,973
< .rel.dyn        0x80042104     0x5af0
<                 0x80042104                __rel_dyn_start = .
---
> .dynsym         0x80042114       0xa0
>                 0x80042114                __dynsym_start = .
>  *(.dynsym)
>  .dynsym        0x80042114       0xa0 arch/arm/cpu/armv7/start.o
> 
> .rel.dyn        0x800421b4     0x5af0
>                 0x800421b4                __rel_dyn_start = .

=== [contents deleted] ===

984,985c986,987
< .bss            0x80042104    0x31ba8
<                 0x80042104                __bss_start = .
---
> .bss            0x800421b4    0x31bb4 load address 0x80047ca4
>                 0x80073d68                __bss_start = .

=== [contents deleted] ===

< .dynbss         0x80073cac        0x0
---
> .dynbss         0x80073d68        0x0 load address 0x80079858