[U-Boot] Build failures with older toolchain

[U-Boot] Build failures with older toolchain

[Premi, Sanjeev]

Hi all,

I pulled u-boot about an hour ago and master is at this commit:

    Author: Matthias Weisser <weisserm@arcor.de>
    Date:   Thu Nov 18 09:35:09 2010 +0100

        Makefile: Fix build with USE_PRIVATE_LIBGCC

(plus a small change in omap3_config.h - unrelated) 

When trying to build u-boot I was constantly, getting these errors:
arm-none-linux-gnueabi-ld: section .bss [8003f5c8 -> 8007e327] overlaps section .rel.dyn [8003f5c8 -> 80044e57]
arm-none-linux-gnueabi-ld: section .dynsym [80044e58 -> 80044ef7] overlaps section .bss [8003f5c8 -> 8007e327]
arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5c8 overlaps previous sections

Tried to build omap3_beagle and there were no issues; unable to
debug for long, I decided to come back on this problem later.
Opened a new window and started working on my Linux tree.

Returned back to u-boot, and this time build was successful for no
evident change. Took me some time to realise that the toolchain
I was using to work on Linux repo was different - I use an env
script based on activity.

To verify the doubts, I explicitly ran this command with two different
versions of toolchain in my path and I see different results. Here are
last few lines of final build step


Failure with Codesourcery 2009q1-203:

h/arm/lib/eabi_compat.o -L /opt/codesourcery/2009q1-203/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3 -lgcc -Map u-boot.map -o u-boot
arm-none-linux-gnueabi-ld: section .bss [8003f5c8 -> 8007e327] overlaps section .rel.dyn [8003f5c8 -> 80044e57]
arm-none-linux-gnueabi-ld: section .dynsym [80044e58 -> 80044ef7] overlaps section .bss [8003f5c8 -> 8007e327]
arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5c8 overlaps previous sections
make: *** [u-boot] Error 1
premi # pwd
/home/premi/git/u-boot
premi #

Success with Codesourcery 2010q1-202:

19/u-boot/arch/arm/lib/eabi_compat.o -L /opt/codesourcery/2010q1-202/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/armv4t -lgcc -Map u-boot.map -o u-boot
arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003e8e8 overlaps previous sections
arm-none-linux-gnueabi-objcopy -O srec u-boot u-boot.srec
arm-none-linux-gnueabi-objcopy --gap-fill=0xff -O binary u-boot u-boot.bin
premi # pwd
/home/premi/git/u-boot
premi #

The configuration for beagle still build successfully for both toolchain versions.
Any clues/ suggestions? Is there a recent change which hasn't yet been adapted or
ported for omap3evm?

Best regards,
Sanjeev

[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: Saturday, November 20, 2010 12:21 AM
> To: u-boot at lists.denx.de
> Subject: [U-Boot] Build failures with older toolchain
> 
> Hi all,
> 
> I pulled u-boot about an hour ago and master is at this commit:
> 
>     Author: Matthias Weisser <weisserm@arcor.de>
>     Date:   Thu Nov 18 09:35:09 2010 +0100
> 
>         Makefile: Fix build with USE_PRIVATE_LIBGCC
> 
> (plus a small change in omap3_config.h - unrelated) 
> 
> When trying to build u-boot I was constantly, getting these errors:
> arm-none-linux-gnueabi-ld: section .bss [8003f5c8 -> 
> 8007e327] overlaps section .rel.dyn [8003f5c8 -> 80044e57]
> arm-none-linux-gnueabi-ld: section .dynsym [80044e58 -> 
> 80044ef7] overlaps section .bss [8003f5c8 -> 8007e327]
> arm-none-linux-gnueabi-ld: u-boot: section .bss vma 
> 0x8003f5c8 overlaps previous sections
> 
> Tried to build omap3_beagle and there were no issues; unable to
> debug for long, I decided to come back on this problem later.
> Opened a new window and started working on my Linux tree.
> 
> Returned back to u-boot, and this time build was successful for no
> evident change. Took me some time to realise that the toolchain
> I was using to work on Linux repo was different - I use an env
> script based on activity.
> 
> To verify the doubts, I explicitly ran this command with two different
> versions of toolchain in my path and I see different results. Here are
> last few lines of final build step
> 
> 
> Failure with Codesourcery 2009q1-203:
> 
> h/arm/lib/eabi_compat.o -L 
> /opt/codesourcery/2009q1-203/bin/../lib/gcc/arm-none-linux-gnu
> eabi/4.3.3 -lgcc -Map u-boot.map -o u-boot
> arm-none-linux-gnueabi-ld: section .bss [8003f5c8 -> 
> 8007e327] overlaps section .rel.dyn [8003f5c8 -> 80044e57]
> arm-none-linux-gnueabi-ld: section .dynsym [80044e58 -> 
> 80044ef7] overlaps section .bss [8003f5c8 -> 8007e327]
> arm-none-linux-gnueabi-ld: u-boot: section .bss vma 
> 0x8003f5c8 overlaps previous sections
> make: *** [u-boot] Error 1
> premi # pwd
> /home/premi/git/u-boot
> premi #
> 
> Success with Codesourcery 2010q1-202:
> 
> 19/u-boot/arch/arm/lib/eabi_compat.o -L 
> /opt/codesourcery/2010q1-202/bin/../lib/gcc/arm-none-linux-gnu
> eabi/4.4.1/armv4t -lgcc -Map u-boot.map -o u-boot
> arm-none-linux-gnueabi-ld: u-boot: section .bss vma 
> 0x8003e8e8 overlaps previous sections
> arm-none-linux-gnueabi-objcopy -O srec u-boot u-boot.srec
> arm-none-linux-gnueabi-objcopy --gap-fill=0xff -O binary 
> u-boot u-boot.bin
> premi # pwd
> /home/premi/git/u-boot
> premi #
> 
> The configuration for beagle still build successfully for 
> both toolchain versions.
> Any clues/ suggestions? Is there a recent change which hasn't 
> yet been adapted or
> ported for omap3evm?

Here is my log of git-bisect:
Was trying to find if any commit made changes that could be specific to toolchain version.

Due to state of the omap3evm, 2 changes in configs/omap3_evm.h had to be done manually
at some stage - to avoid compile errors due to undefined symbols.

premi # git bisect log
git bisect start
# good: [e0ccbe367ed4465db930a37a850c889827fb076b] Merge branch 'master' of http://git.denx.de/u-boot
git bisect good e0ccbe367ed4465db930a37a850c889827fb076b
# bad: [e3dae922877505c89823b17acaefdf83a6d92ce2] work in progress
git bisect bad e3dae922877505c89823b17acaefdf83a6d92ce2
# good: [f2b382ea066d02d5ba44870024cc1295e85782ef] Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx
git bisect good f2b382ea066d02d5ba44870024cc1295e85782ef
# good: [d75c2a3d7f34ff1eb9920ad72483cff7cb6d358f] Merge branch 'master' of git://git.denx.de/u-boot-imx
git bisect good d75c2a3d7f34ff1eb9920ad72483cff7cb6d358f
# good: [a72dbae2ccd38d2b32f8b814f5a528c88be65bd3] fsl_pci_init: Make fsl_pci_init_port() PCI/PCIe aware
git bisect good a72dbae2ccd38d2b32f8b814f5a528c88be65bd3
# good: [a72dbae2ccd38d2b32f8b814f5a528c88be65bd3] fsl_pci_init: Make fsl_pci_init_port() PCI/PCIe aware
git bisect good a72dbae2ccd38d2b32f8b814f5a528c88be65bd3
# good: [a72dbae2ccd38d2b32f8b814f5a528c88be65bd3] fsl_pci_init: Make fsl_pci_init_port() PCI/PCIe aware
git bisect good a72dbae2ccd38d2b32f8b814f5a528c88be65bd3
# good: [227b72515546fca535dbd3274f6d875d97f494fe] Merge branch 'master' of git://git.denx.de/u-boot-ti
git bisect good 227b72515546fca535dbd3274f6d875d97f494fe
# good: [8ad25bf8d9233eb7d0b614612108622a59069354] Net: clarify board/cpu_eth_init calls
git bisect good 8ad25bf8d9233eb7d0b614612108622a59069354
# bad: [f7ac99fdd9eaf64df9731c2e8fdf97e9d3e2c82a] net: e1000: typo using wrong argument to sizeof
git bisect bad f7ac99fdd9eaf64df9731c2e8fdf97e9d3e2c82a
# good: [858ecd9ac3434e011e84d5fd9013bd1ee199dbdc] tx25: fix linker file for newer ld support
git bisect good 858ecd9ac3434e011e84d5fd9013bd1ee199dbdc
# bad: [6d8962e814c15807dd6ac5757904be2a02d187b8] Switch from archive libraries to partial linking
git bisect bad 6d8962e814c15807dd6ac5757904be2a02d187b8
premi #

This points leads me to this commit:
 
    commit 6d8962e814c15807dd6ac5757904be2a02d187b8
    Author: Sebastien Carlier <sebastien.carlier@gmail.com>
    Date:   Fri Nov 5 15:48:07 2010 +0100

    Switch from archive libraries to partial linking

Is this related to toolchain version?
Still doesn't explain why failure occurs for omap3_evm; not omap3_beagle...

~sanjeev

> 
> Best regards,
> Sanjeev
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 

[U-Boot] Build failures with older toolchain

[Wolfgang Denk]

Dear "Premi, Sanjeev",

In message <B85A65D85D7EB246BE421B3FB0FBB59302477EABCA@dbde02.ent.ti.com> you wrote:
>
> This points leads me to this commit:
>  
>     commit 6d8962e814c15807dd6ac5757904be2a02d187b8
>     Author: Sebastien Carlier <sebastien.carlier@gmail.com>
>     Date:   Fri Nov 5 15:48:07 2010 +0100
> 
>     Switch from archive libraries to partial linking
> 
> Is this related to toolchain version?
> Still doesn't explain why failure occurs for omap3_evm; not omap3_beagle...

This commit may require further changes to board specific linker scripts.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The use of anthropomorphic terminology when  dealing  with  computing
systems is a symptom of professional immaturity.   -- Edsger Dijkstra

[U-Boot] Build failures with older toolchain

[Premi, Sanjeev]

> -----Original Message-----
> From: Wolfgang Denk [mailto:wd at denx.de] 
> Sent: Saturday, November 20, 2010 1:44 AM
> To: Premi, Sanjeev
> Cc: u-boot at lists.denx.de
> Subject: Re: [U-Boot] Build failures with older toolchain
> 
> Dear "Premi, Sanjeev",
> 
> In message 
> <B85A65D85D7EB246BE421B3FB0FBB59302477EABCA@dbde02.ent.ti.com>
>  you wrote:
> >
> > This points leads me to this commit:
> >  
> >     commit 6d8962e814c15807dd6ac5757904be2a02d187b8
> >     Author: Sebastien Carlier <sebastien.carlier@gmail.com>
> >     Date:   Fri Nov 5 15:48:07 2010 +0100
> > 
> >     Switch from archive libraries to partial linking
> > 
> > Is this related to toolchain version?
> > Still doesn't explain why failure occurs for omap3_evm; not 
> omap3_beagle...
> 
> This commit may require further changes to board specific 
> linker scripts.

[sp] Both boards share the same 'u-boot.lds' And there is no board
     specific lds. Still trying to figure what could be wrong.

~sanjeev

> 
> Best regards,
> 
> Wolfgang Denk
> 
> -- 
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> The use of anthropomorphic terminology when  dealing  with  computing
> systems is a symptom of professional immaturity.   -- Edsger Dijkstra
> 

[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: Monday, November 22, 2010 2:44 PM
> To: Wolfgang Denk
> Cc: u-boot at lists.denx.de
> Subject: Re: [U-Boot] Build failures with older toolchain
> 
> > -----Original Message-----
> > From: Wolfgang Denk [mailto:wd at denx.de] 
> > Sent: Saturday, November 20, 2010 1:44 AM
> > To: Premi, Sanjeev
> > Cc: u-boot at lists.denx.de
> > Subject: Re: [U-Boot] Build failures with older toolchain
> > 
> > Dear "Premi, Sanjeev",
> > 
> > In message 
> > <B85A65D85D7EB246BE421B3FB0FBB59302477EABCA@dbde02.ent.ti.com>
> >  you wrote:
> > >
> > > This points leads me to this commit:
> > >  
> > >     commit 6d8962e814c15807dd6ac5757904be2a02d187b8
> > >     Author: Sebastien Carlier <sebastien.carlier@gmail.com>
> > >     Date:   Fri Nov 5 15:48:07 2010 +0100
> > > 
> > >     Switch from archive libraries to partial linking
> > > 
> > > Is this related to toolchain version?
> > > Still doesn't explain why failure occurs for omap3_evm; not 
> > omap3_beagle...
> > 
> > This commit may require further changes to board specific 
> > linker scripts.
> 
> [sp] Both boards share the same 'u-boot.lds' And there is no board
>      specific lds. Still trying to figure what could be wrong.

Tried the same stuff for overo and no issues!

Since there linker scripts are same between omap3_evm, omap3_beagle
and omap3_overo, only difference could have been board specific code.

I was hoping to find some code that might be offending the linker;
unable to find by inspection, I reduced the default configuration
for the evm to as low as I could - still see:

arm-none-linux-gnueabi-ld: section .bss [800fe358 -> 800fee1b] overlaps section .rel.dyn [800fe358 -> 8010076f]
arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x800fe358 overlaps previous sections

I am still not sure why the start of .bss and .rel.dyn for omap3_evm start at same address
but 

Looking for more pointers!
Specifically, a "big" generic change that somehow didn't touch the omap3evm; but did touch others.
...will start looking at the git-log immediately after this mail.

~sanjeev

> 
> ~sanjeev
> 
> > 
> > Best regards,
> > 
> > Wolfgang Denk
> > 
> > -- 
> > DENX Software Engineering GmbH,     MD: Wolfgang Denk & 
> Detlev Zundel
> > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 
> Groebenzell, Germany
> > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: 
> wd at denx.de
> > The use of anthropomorphic terminology when  dealing  with  
> computing
> > systems is a symptom of professional immaturity.   -- 
> Edsger Dijkstra
> > 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 

[U-Boot] Build failures with older toolchain

[Albert ARIBAUD]

Le 22/11/2010 14:50, Premi, Sanjeev a ?crit :
> Tried the same stuff for overo and no issues!
>
> Since there linker scripts are same between omap3_evm, omap3_beagle
> and omap3_overo, only difference could have been board specific code.
>
> I was hoping to find some code that might be offending the linker;
> unable to find by inspection, I reduced the default configuration
> for the evm to as low as I could - still see:
>
> arm-none-linux-gnueabi-ld: section .bss [800fe358 ->  800fee1b] overlaps section .rel.dyn [800fe358 ->  8010076f]
> arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x800fe358 overlaps previous sections
>
> I am still not sure why the start of .bss and .rel.dyn for omap3_evm start at same address

That is because they are voluntarily overlapped. This looks like the 
patch I recently did, which in essence does overlap BSS (which is not 
used before relocation) and relocation tables (which are not used after 
relocation) so that the FLASH and RAM footprint remain minimal.

This should not result in a linker message unless the .lds does not 
follow the same structure (order and attributes of output sections) as, 
for instance, the arm926ejs u-boot.lds.

> but
>
> Looking for more pointers!
> Specifically, a "big" generic change that somehow didn't touch the omap3evm; but did touch others.
> ....will start looking at the git-log immediately after this mail.
>
> ~sanjeev

Look up the u-boot.lds files. Are they shared?

Amicalement,
-- 
Albert.

[U-Boot] Build failures with older toolchain

[Premi, Sanjeev]

> -----Original Message-----
> From: Albert ARIBAUD [mailto:albert.aribaud at free.fr] 
> Sent: Monday, November 22, 2010 8:02 PM
> To: Premi, Sanjeev
> Cc: Wolfgang Denk; u-boot at lists.denx.de
> Subject: Re: Build failures with older toolchain
> 
> Le 22/11/2010 14:50, Premi, Sanjeev a ?crit :
> > Tried the same stuff for overo and no issues!
> >
> > Since there linker scripts are same between omap3_evm, omap3_beagle
> > and omap3_overo, only difference could have been board 
> specific code.
> >
> > I was hoping to find some code that might be offending the linker;
> > unable to find by inspection, I reduced the default configuration
> > for the evm to as low as I could - still see:
> >
> > arm-none-linux-gnueabi-ld: section .bss [800fe358 ->  
> 800fee1b] overlaps section .rel.dyn [800fe358 ->  8010076f]
> > arm-none-linux-gnueabi-ld: u-boot: section .bss vma 
> 0x800fe358 overlaps previous sections
> >
> > I am still not sure why the start of .bss and .rel.dyn for 
> omap3_evm start at same address
> 
> That is because they are voluntarily overlapped. This looks like the 
> patch I recently did, which in essence does overlap BSS (which is not 
> used before relocation) and relocation tables (which are not 
> used after 
> relocation) so that the FLASH and RAM footprint remain minimal.
> 
> This should not result in a linker message unless the .lds does not 
> follow the same structure (order and attributes of output 
> sections) as, 
> for instance, the arm926ejs u-boot.lds.

[sp] Thanks for the pointer. I will take a look at it. I am still
     surprised why the problem doesn't show up on beagle and overo
     which share the same lds.

> 
> > but
> >
> > Looking for more pointers!
> > Specifically, a "big" generic change that somehow didn't 
> touch the omap3evm; but did touch others.
> > ....will start looking at the git-log immediately after this mail.
> >
> > ~sanjeev
> 
> Look up the u-boot.lds files. Are they shared?

[sp] Before sending the previous mail. I compared the u-boot.lds
     generated for omap3_evm and omap3_beagle and they are identical!

> 
> Amicalement,
> -- 
> Albert.
> 

[U-Boot] Build failures with older toolchain

[Premi, Sanjeev]

> -----Original Message-----
> From: Albert ARIBAUD [mailto:albert.aribaud at free.fr] 
> Sent: Monday, November 22, 2010 8:02 PM
> To: Premi, Sanjeev
> Cc: Wolfgang Denk; u-boot at lists.denx.de
> Subject: Re: Build failures with older toolchain
> 
> Le 22/11/2010 14:50, Premi, Sanjeev a ?crit :
> > Tried the same stuff for overo and no issues!
> >
> > Since there linker scripts are same between omap3_evm, omap3_beagle
> > and omap3_overo, only difference could have been board 
> specific code.
> >
> > I was hoping to find some code that might be offending the linker;
> > unable to find by inspection, I reduced the default configuration
> > for the evm to as low as I could - still see:
> >
> > arm-none-linux-gnueabi-ld: section .bss [800fe358 ->  
> 800fee1b] overlaps section .rel.dyn [800fe358 ->  8010076f]
> > arm-none-linux-gnueabi-ld: u-boot: section .bss vma 
> 0x800fe358 overlaps previous sections
> >
> > I am still not sure why the start of .bss and .rel.dyn for 
> omap3_evm start at same address
> 
> That is because they are voluntarily overlapped. This looks like the 
> patch I recently did, which in essence does overlap BSS (which is not 
> used before relocation) and relocation tables (which are not 
> used after 
> relocation) so that the FLASH and RAM footprint remain minimal.

[sp] Are you referring to this patch?
     http://git.denx.de/?p=u-boot.git;a=commitdiff;h=aaeb0a890a050b58be87fa2b165eec5fa947dc86

     I see the change for arm926ejs/u-boot.lds and armv7/u-boot.lds
     to be similar.

     Your commit mentions about the new ld vs. old; I had seen this
     earlier as well. It was the reason for me to try CodeSourcery
     Lite 2010-q1 but there I get a different error - mentioned in my
     first post.

     Which toolchain version are you using?

~sanjeev

> 
> This should not result in a linker message unless the .lds does not 
> follow the same structure (order and attributes of output 
> sections) as, 
> for instance, the arm926ejs u-boot.lds.
> 
> > but
> >
> > Looking for more pointers!
> > Specifically, a "big" generic change that somehow didn't 
> touch the omap3evm; but did touch others.
> > ....will start looking at the git-log immediately after this mail.
> >
> > ~sanjeev
> 
> Look up the u-boot.lds files. Are they shared?
> 
> Amicalement,
> -- 
> Albert.
> 

[U-Boot] Build failures with older toolchain

[Albert ARIBAUD]

Le 22/11/2010 16:02, Premi, Sanjeev a ?crit :
>> -----Original Message-----
>> From: Albert ARIBAUD [mailto:albert.aribaud at free.fr]
>> Sent: Monday, November 22, 2010 8:02 PM
>> To: Premi, Sanjeev
>> Cc: Wolfgang Denk; u-boot at lists.denx.de
>> Subject: Re: Build failures with older toolchain
>>
>> Le 22/11/2010 14:50, Premi, Sanjeev a ?crit :
>>> Tried the same stuff for overo and no issues!
>>>
>>> Since there linker scripts are same between omap3_evm, omap3_beagle
>>> and omap3_overo, only difference could have been board
>> specific code.
>>>
>>> I was hoping to find some code that might be offending the linker;
>>> unable to find by inspection, I reduced the default configuration
>>> for the evm to as low as I could - still see:
>>>
>>> arm-none-linux-gnueabi-ld: section .bss [800fe358 ->
>> 800fee1b] overlaps section .rel.dyn [800fe358 ->   8010076f]
>>> arm-none-linux-gnueabi-ld: u-boot: section .bss vma
>> 0x800fe358 overlaps previous sections
>>>
>>> I am still not sure why the start of .bss and .rel.dyn for
>> omap3_evm start at same address
>>
>> That is because they are voluntarily overlapped. This looks like the
>> patch I recently did, which in essence does overlap BSS (which is not
>> used before relocation) and relocation tables (which are not
>> used after
>> relocation) so that the FLASH and RAM footprint remain minimal.
>
> [sp] Are you referring to this patch?
>       http://git.denx.de/?p=u-boot.git;a=commitdiff;h=aaeb0a890a050b58be87fa2b165eec5fa947dc86
>
>       I see the change for arm926ejs/u-boot.lds and armv7/u-boot.lds
>       to be similar.
>
>       Your commit mentions about the new ld vs. old; I had seen this
>       earlier as well. It was the reason for me to try CodeSourcery
>       Lite 2010-q1 but there I get a different error - mentioned in my
>       first post.
>
>       Which toolchain version are you using?

I usually try the 2009q3 Code Sourcery and the ELDK 4.2 toolchains.

Can you compare the ld invocation command lines for a failure case and a 
success case? The difference could be in the linker options.

Amicalement,
-- 
Albert.

[U-Boot] Build failures with older toolchain

[Premi, Sanjeev]

> -----Original Message-----
> From: Albert ARIBAUD [mailto:albert.aribaud at free.fr] 
> Sent: Monday, November 22, 2010 8:54 PM
> To: Premi, Sanjeev
> Cc: u-boot at lists.denx.de
> Subject: Re: Build failures with older toolchain
> 
> Le 22/11/2010 16:02, Premi, Sanjeev a ?crit :
> >> -----Original Message-----
> >> From: Albert ARIBAUD [mailto:albert.aribaud at free.fr]
> >> Sent: Monday, November 22, 2010 8:02 PM
> >> To: Premi, Sanjeev
> >> Cc: Wolfgang Denk; u-boot at lists.denx.de
> >> Subject: Re: Build failures with older toolchain
> >>
> >> Le 22/11/2010 14:50, Premi, Sanjeev a ?crit :
> >>> Tried the same stuff for overo and no issues!
> >>>
> >>> Since there linker scripts are same between omap3_evm, 
> omap3_beagle
> >>> and omap3_overo, only difference could have been board
> >> specific code.
> >>>
> >>> I was hoping to find some code that might be offending the linker;
> >>> unable to find by inspection, I reduced the default configuration
> >>> for the evm to as low as I could - still see:
> >>>
> >>> arm-none-linux-gnueabi-ld: section .bss [800fe358 ->
> >> 800fee1b] overlaps section .rel.dyn [800fe358 ->   8010076f]
> >>> arm-none-linux-gnueabi-ld: u-boot: section .bss vma
> >> 0x800fe358 overlaps previous sections
> >>>
> >>> I am still not sure why the start of .bss and .rel.dyn for
> >> omap3_evm start at same address
> >>
> >> That is because they are voluntarily overlapped. This 
> looks like the
> >> patch I recently did, which in essence does overlap BSS 
> (which is not
> >> used before relocation) and relocation tables (which are not
> >> used after
> >> relocation) so that the FLASH and RAM footprint remain minimal.
> >
> > [sp] Are you referring to this patch?
> >       
> http://git.denx.de/?p=u-boot.git;a=commitdiff;h=aaeb0a890a050b
> 58be87fa2b165eec5fa947dc86
> >
> >       I see the change for arm926ejs/u-boot.lds and armv7/u-boot.lds
> >       to be similar.
> >
> >       Your commit mentions about the new ld vs. old; I had seen this
> >       earlier as well. It was the reason for me to try CodeSourcery
> >       Lite 2010-q1 but there I get a different error - 
> mentioned in my
> >       first post.
> >
> >       Which toolchain version are you using?
> 
> I usually try the 2009q3 Code Sourcery and the ELDK 4.2 toolchains.
> 
> Can you compare the ld invocation command lines for a failure 
> case and a 
> success case? The difference could be in the linker options.

[sp] Identical :(
     Would you want me to share the build logs or the last step?
     The generated u-boot.lds is also same. It was my first step.

     Then I started looking if there is any "forced" addition on
     specific section that may not be going well with linker/
     relocation changes - reason for trying a minimal config.

~sanjeev

> 
> Amicalement,
> -- 
> Albert.
> 

[U-Boot] Build failures with older toolchain

[Albert ARIBAUD]

Le 22/11/2010 16:27, Premi, Sanjeev a ?crit :

>       Would you want me to share the build logs or the last step?
>       The generated u-boot.lds is also same. It was my first step.

Obviously you don't have the ELF binary for the failure case, but maybe 
you have the map file for it? Then can you make the map files available 
to me outside of the list?

Otherwise, if you are building the current master without patches, I 
should be able to install and use the same toolchain as you and compile 
the same targets, and see the issue on my side -- only this will have to 
wait for a couple of days.

Amicalement,
-- 
Albert.

[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: Monday, November 22, 2010 8:57 PM
> To: Albert ARIBAUD
> Cc: u-boot at lists.denx.de
> Subject: Re: [U-Boot] Build failures with older toolchain
> 
> > -----Original Message-----
> > From: Albert ARIBAUD [mailto:albert.aribaud at free.fr] 
> > Sent: Monday, November 22, 2010 8:54 PM
> > To: Premi, Sanjeev
> > Cc: u-boot at lists.denx.de
> > Subject: Re: Build failures with older toolchain
> > 
> > Le 22/11/2010 16:02, Premi, Sanjeev a ?crit :
> > >> -----Original Message-----
> > >> From: Albert ARIBAUD [mailto:albert.aribaud at free.fr]
> > >> Sent: Monday, November 22, 2010 8:02 PM
> > >> To: Premi, Sanjeev
> > >> Cc: Wolfgang Denk; u-boot at lists.denx.de
> > >> Subject: Re: Build failures with older toolchain
> > >>
> > >> Le 22/11/2010 14:50, Premi, Sanjeev a ?crit :
> > >>> Tried the same stuff for overo and no issues!
> > >>>
> > >>> Since there linker scripts are same between omap3_evm, 
> > omap3_beagle
> > >>> and omap3_overo, only difference could have been board
> > >> specific code.
> > >>>
> > >>> I was hoping to find some code that might be offending 
> the linker;
> > >>> unable to find by inspection, I reduced the default 
> configuration
> > >>> for the evm to as low as I could - still see:
> > >>>
> > >>> arm-none-linux-gnueabi-ld: section .bss [800fe358 ->
> > >> 800fee1b] overlaps section .rel.dyn [800fe358 ->   8010076f]
> > >>> arm-none-linux-gnueabi-ld: u-boot: section .bss vma
> > >> 0x800fe358 overlaps previous sections
> > >>>
> > >>> I am still not sure why the start of .bss and .rel.dyn for
> > >> omap3_evm start at same address
> > >>
> > >> That is because they are voluntarily overlapped. This 
> > looks like the
> > >> patch I recently did, which in essence does overlap BSS 
> > (which is not
> > >> used before relocation) and relocation tables (which are not
> > >> used after
> > >> relocation) so that the FLASH and RAM footprint remain minimal.
> > >
> > > [sp] Are you referring to this patch?
> > >       
> > http://git.denx.de/?p=u-boot.git;a=commitdiff;h=aaeb0a890a050b
> > 58be87fa2b165eec5fa947dc86
> > >
> > >       I see the change for arm926ejs/u-boot.lds and 
> armv7/u-boot.lds
> > >       to be similar.
> > >
> > >       Your commit mentions about the new ld vs. old; I 
> had seen this
> > >       earlier as well. It was the reason for me to try 
> CodeSourcery
> > >       Lite 2010-q1 but there I get a different error - 
> > mentioned in my
> > >       first post.
> > >
> > >       Which toolchain version are you using?
> > 
> > I usually try the 2009q3 Code Sourcery and the ELDK 4.2 toolchains.
> > 
> > Can you compare the ld invocation command lines for a failure 
> > case and a 
> > success case? The difference could be in the linker options.
> 
> [sp] Identical :(
>      Would you want me to share the build logs or the last step?
>      The generated u-boot.lds is also same. It was my first step.
> 
>      Then I started looking if there is any "forced" addition on
>      specific section that may not be going well with linker/
>      relocation changes - reason for trying a minimal config.
> 

Albert,

I saw some more - what I believe related changes - since last week;
but the linker error still persists.

with 2009-q1 toolchain:
-----------------------
busb_phy.o drivers/video/libvideo.o drivers/watchdog/libwatchdog.o common/libcommon.o lib/libfdt/libfdt.o api/libapi.o post/libpost.o arch/arm/cpu/armv7/omap-common/libomap-common.o board/ti/evm/libevm.o --end-group /db/psp_git/users/a0756819/u-boot/arch/arm/lib/eabi_compat.o -L /opt/codesourcery/2009q1-203/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3 -lgcc -Map u-boot.map -o u-boot
arm-none-linux-gnueabi-ld: section .bss [8003f5c0 -> 8007e31f] overlaps section .rel.dyn [8003f5c0 -> 80044e4f]
arm-none-linux-gnueabi-ld: section .dynsym [80044e50 -> 80044eef] overlaps section .bss [8003f5c0 -> 8007e31f]
arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5c0 overlaps previous sections
make: *** [u-boot] Error 1

with 2010-q1 toolchain:
-----------------------
mmon/libomap-common.o board/ti/evm/libevm.o --end-group /db/psp_git/users/a0756819/u-boot/arch/arm/lib/eabi_compat.o -L /opt/codesourcery/2010q1-202/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/armv4t -lgcc -Map u-boot.map -o u-boot
arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003e8e0 overlaps previous sections
arm-none-linux-gnueabi-objcopy -O srec u-boot u-boot.srec
arm-none-linux-gnueabi-objcopy --gap-fill=0xff -O binary u-boot u-boot.bin

Best regards,
Sanjeev

> ~sanjeev
> 
> > 
> > Amicalement,
> > -- 
> > Albert.
> > 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 

[U-Boot] Build failures with older toolchain

[Albert ARIBAUD]

Le 29/11/2010 10:47, Premi, Sanjeev a ?crit :

> Albert,
>
> I saw some more - what I believe related changes - since last week;
> but the linker error still persists.
>
> with 2009-q1 toolchain:
> -----------------------
> busb_phy.o drivers/video/libvideo.o drivers/watchdog/libwatchdog.o common/libcommon.o lib/libfdt/libfdt.o api/libapi.o post/libpost.o arch/arm/cpu/armv7/omap-common/libomap-common.o board/ti/evm/libevm.o --end-group /db/psp_git/users/a0756819/u-boot/arch/arm/lib/eabi_compat.o -L /opt/codesourcery/2009q1-203/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3 -lgcc -Map u-boot.map -o u-boot
> arm-none-linux-gnueabi-ld: section .bss [8003f5c0 ->  8007e31f] overlaps section .rel.dyn [8003f5c0 ->  80044e4f]
> arm-none-linux-gnueabi-ld: section .dynsym [80044e50 ->  80044eef] overlaps section .bss [8003f5c0 ->  8007e31f]
> arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5c0 overlaps previous sections
> make: *** [u-boot] Error 1
>
> with 2010-q1 toolchain:
> -----------------------
> mmon/libomap-common.o board/ti/evm/libevm.o --end-group /db/psp_git/users/a0756819/u-boot/arch/arm/lib/eabi_compat.o -L /opt/codesourcery/2010q1-202/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/armv4t -lgcc -Map u-boot.map -o u-boot
> arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003e8e0 overlaps previous sections
> arm-none-linux-gnueabi-objcopy -O srec u-boot u-boot.srec
> arm-none-linux-gnueabi-objcopy --gap-fill=0xff -O binary u-boot u-boot.bin

Weird... I've compiled v2010.12-rc2, for boards omap3_evm, omap3_overo 
and omap3_beagle, with 2010q1, and here is what I get, which is quite 
different from what you get:

albert at lilith:~/src/u-boot$ ./MAKEALL omap3_evm omap3_overo omap3_beagle
Configuring for omap3_evm board...
start.S: Assembler messages:
start.S:144: Error: constant expression expected -- `ldr 
sp,=((0x4020FFFC-CONFIG_SYS_GBL_DATA_SIZE))'
make[1]: *** [start.o] Erreur 1
make: *** [arch/arm/cpu/armv7/start.o] Erreur 2
make: *** Attente des t?ches non termin?es....
arm-none-linux-gnueabi-size: './u-boot': No such file
Configuring for omap3_overo board...
    text	   data	    bss	    dec	    hex	filename
  212965	  10840	 210624	 434429	  6a0fd	./u-boot
Configuring for omap3_beagle board...
    text	   data	    bss	    dec	    hex	filename
  243182	  11300	 203648	 458130	  6fd92	./u-boot

--------------------- SUMMARY ----------------------------
Boards compiled: 3
Boards with warnings or errors: 1 ( omap3_evm )
----------------------------------------------------------
albert at lilith:~/src/u-boot$

> Best regards,
> Sanjeev

Amicalement,
-- 
Albert.

[U-Boot] Build failures with older toolchain

[Premi, Sanjeev]

> -----Original Message-----
> From: Albert ARIBAUD [mailto:albert.aribaud at free.fr] 
> Sent: Monday, November 29, 2010 4:03 PM
> To: u-boot at lists.denx.de
> Cc: Premi, Sanjeev
> Subject: Re: Build failures with older toolchain
> 
> Le 29/11/2010 10:47, Premi, Sanjeev a ?crit :
> 
> > Albert,
> >
> > I saw some more - what I believe related changes - since last week;
> > but the linker error still persists.
> >
> > with 2009-q1 toolchain:
> > -----------------------
> > busb_phy.o drivers/video/libvideo.o 
> drivers/watchdog/libwatchdog.o common/libcommon.o 
> lib/libfdt/libfdt.o api/libapi.o post/libpost.o 
> arch/arm/cpu/armv7/omap-common/libomap-common.o 
> board/ti/evm/libevm.o --end-group 
> /db/psp_git/users/a0756819/u-boot/arch/arm/lib/eabi_compat.o 
> -L 
> /opt/codesourcery/2009q1-203/bin/../lib/gcc/arm-none-linux-gnu
> eabi/4.3.3 -lgcc -Map u-boot.map -o u-boot
> > arm-none-linux-gnueabi-ld: section .bss [8003f5c0 ->  
> 8007e31f] overlaps section .rel.dyn [8003f5c0 ->  80044e4f]
> > arm-none-linux-gnueabi-ld: section .dynsym [80044e50 ->  
> 80044eef] overlaps section .bss [8003f5c0 ->  8007e31f]
> > arm-none-linux-gnueabi-ld: u-boot: section .bss vma 
> 0x8003f5c0 overlaps previous sections
> > make: *** [u-boot] Error 1
> >
> > with 2010-q1 toolchain:
> > -----------------------
> > mmon/libomap-common.o board/ti/evm/libevm.o --end-group 
> /db/psp_git/users/a0756819/u-boot/arch/arm/lib/eabi_compat.o 
> -L 
> /opt/codesourcery/2010q1-202/bin/../lib/gcc/arm-none-linux-gnu
> eabi/4.4.1/armv4t -lgcc -Map u-boot.map -o u-boot
> > arm-none-linux-gnueabi-ld: u-boot: section .bss vma 
> 0x8003e8e0 overlaps previous sections
> > arm-none-linux-gnueabi-objcopy -O srec u-boot u-boot.srec
> > arm-none-linux-gnueabi-objcopy --gap-fill=0xff -O binary 
> u-boot u-boot.bin
> 
> Weird... I've compiled v2010.12-rc2, for boards omap3_evm, 
> omap3_overo 
> and omap3_beagle, with 2010q1, and here is what I get, which is quite 
> different from what you get:
> 
> albert at lilith:~/src/u-boot$ ./MAKEALL omap3_evm omap3_overo 
> omap3_beagle
> Configuring for omap3_evm board...
> start.S: Assembler messages:
> start.S:144: Error: constant expression expected -- `ldr 
> sp,=((0x4020FFFC-CONFIG_SYS_GBL_DATA_SIZE))'
> make[1]: *** [start.o] Erreur 1
> make: *** [arch/arm/cpu/armv7/start.o] Erreur 2
> make: *** Attente des t?ches non termin?es....
> arm-none-linux-gnueabi-size: './u-boot': No such file
> Configuring for omap3_overo board...
>     text	   data	    bss	    dec	    hex	filename
>   212965	  10840	 210624	 434429	  6a0fd	./u-boot
> Configuring for omap3_beagle board...
>     text	   data	    bss	    dec	    hex	filename
>   243182	  11300	 203648	 458130	  6fd92	./u-boot
> 
> --------------------- SUMMARY ----------------------------
> Boards compiled: 3
> Boards with warnings or errors: 1 ( omap3_evm )
> ----------------------------------------------------------
> albert at lilith:~/src/u-boot$

[sp] Did you apply the patch I sent to off-the-list?
     (pasted below)

     I had been holding this patch until until the problem is
     really solved - just in case there was a relation.

[patch]
diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
index aeb45c6..c93f689 100644
--- a/include/configs/omap3_evm.h
+++ b/include/configs/omap3_evm.h
@@ -348,7 +348,9 @@ extern unsigned int boot_flash_type;
  * Support for relocation
  */
 #define CONFIG_SYS_SDRAM_BASE          PHYS_SDRAM_1
-#define CONFIG_SYS_INIT_SP_ADDR                (LOW_LEVEL_SRAM_STACK - CONFIG_SYS_GBL_D
+#define CONFIG_SYS_INIT_SP_ADDR                (LOW_LEVEL_SRAM_STACK \
+                                               - GENERATED_GBL_DATA_SIZE)
+

 /*
  * Define the board revision statically
[/patch]

> 
> > Best regards,
> > Sanjeev
> 
> Amicalement,
> -- 
> Albert.
> 

[U-Boot] Build failures with older toolchain

[Wolfgang Denk]

Dear "Premi, Sanjeev",

can you *please* quote only _relevant_ parts of previous messages?
Thanks.

In message <B85A65D85D7EB246BE421B3FB0FBB5930247A0A9D4@dbde02.ent.ti.com> you wrote:
>
>      I had been holding this patch until until the problem is
>      really solved - just in case there was a relation.

You mean you are complaining about problems with code you have
modified locally, and then expect us to diagnose your problems without
even telling us 1) that you changed the code and 2) what exactly you
changed?

This not exactly a useful approach.

> [patch]
> diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
> index aeb45c6..c93f689 100644
> --- a/include/configs/omap3_evm.h
> +++ b/include/configs/omap3_evm.h
> @@ -348,7 +348,9 @@ extern unsigned int boot_flash_type;
>   * Support for relocation
>   */
>  #define CONFIG_SYS_SDRAM_BASE          PHYS_SDRAM_1
> -#define CONFIG_SYS_INIT_SP_ADDR                (LOW_LEVEL_SRAM_STACK - CONFIG_SYS_GBL_D
> +#define CONFIG_SYS_INIT_SP_ADDR                (LOW_LEVEL_SRAM_STACK \
> +                                               - GENERATED_GBL_DATA_SIZE)
> +

This patch is corrupted.and does not apply.  Please see
http://www.denx.de/wiki/U-Boot/Patches


I have no idea if it results in a running system (as I have no
hardware to test it), but I can confirm that a patch like this:

diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
index 84b2986..f3df8de 100644
--- a/include/configs/omap3_evm.h
+++ b/include/configs/omap3_evm.h
@@ -330,7 +330,7 @@ extern unsigned int boot_flash_type;
  * Support for relocation
  */
 #define CONFIG_SYS_SDRAM_BASE		PHYS_SDRAM_1
-#define CONFIG_SYS_INIT_SP_ADDR		(LOW_LEVEL_SRAM_STACK - CONFIG_SYS_GBL_DATA_SIZE)
+#define CONFIG_SYS_INIT_SP_ADDR		(LOW_LEVEL_SRAM_STACK - GENERATED_GBL_DATA_SIZE)
 
 /*
  * Define the board revision statically

will result in a clean build:

$ ./MAKEALL omap3_evm
Configuring for omap3_evm board...
   text    data     bss     dec     hex filename
 247396   10384  257384  515164   7dc5c /work/wd/tmp-arm/u-boot

--------------------- SUMMARY ----------------------------
Boards compiled: 1
----------------------------------------------------------




Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Brain fried - Core dumped

[U-Boot] Build failures with older toolchain

[Premi, Sanjeev]

> -----Original Message-----
> From: Wolfgang Denk [mailto:wd at denx.de] 
> Sent: Monday, November 29, 2010 5:00 PM
> To: Premi, Sanjeev
> Cc: Albert ARIBAUD; u-boot at lists.denx.de
> Subject: Re: [U-Boot] Build failures with older toolchain

[snip]

> >      I had been holding this patch until until the problem is
> >      really solved - just in case there was a relation.
> 
> You mean you are complaining about problems with code you have
> modified locally, and then expect us to diagnose your problems without
> even telling us 1) that you changed the code and 2) what exactly you
> changed?

[sp] In my original message I did mention about local change. At least,
     then, I believed them to be unrelated... and mentioned so.

> 
> This patch is corrupted.and does not apply.  Please see
> http://www.denx.de/wiki/U-Boot/Patches
> 

[sp] I shared the patch with Albert off-the-list as he had planned
     to work on it... It was to indicate the change that I was doing.

     BTW, I now notice that few chars on the pasted diff seem to have
     been trimed (not sure why) therefore patch didn't apply. Should
     have been more careful...

     I have posted an updated patch refreshed against the latest
     master few mins back.

> 
> I have no idea if it results in a running system (as I have no
> hardware to test it), but I can confirm that a patch like this:
> 
> diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
> index 84b2986..f3df8de 100644
> --- a/include/configs/omap3_evm.h
> +++ b/include/configs/omap3_evm.h
> @@ -330,7 +330,7 @@ extern unsigned int boot_flash_type;
>   * Support for relocation
>   */
>  #define CONFIG_SYS_SDRAM_BASE		PHYS_SDRAM_1
> -#define CONFIG_SYS_INIT_SP_ADDR		
> (LOW_LEVEL_SRAM_STACK - CONFIG_SYS_GBL_DATA_SIZE)
> +#define CONFIG_SYS_INIT_SP_ADDR		
> (LOW_LEVEL_SRAM_STACK - GENERATED_GBL_DATA_SIZE)

[sp] Although, you the patch I send earlier didn't apply cleanly,
     I was making the same change... and noticing the failures.

     As mentioned earlier, I did not expect to see any errors after
     making this change.

     I am process of downloading the 2009q3 version from codesourcery
     Albert mentioned he is using it. Are you on the same version as
     well?

~sanjeev

[snip]

[U-Boot] Build failures with older toolchain

[Wolfgang Denk]

Dear "Premi, Sanjeev",

In message <B85A65D85D7EB246BE421B3FB0FBB5930247A0AA6E@dbde02.ent.ti.com> you wrote:
>
>      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

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Vulcans do not approve of violence.
	-- Spock, "Journey to Babel", stardate 3842.4

[U-Boot] Build failures with older toolchain

[Premi, Sanjeev]

> -----Original Message-----
> From: Wolfgang Denk [mailto:wd at denx.de] 
> Sent: Monday, November 29, 2010 5:35 PM
> To: Premi, Sanjeev
> Cc: Albert ARIBAUD; u-boot at lists.denx.de
> Subject: Re: [U-Boot] Build failures with older toolchain
> 
> Dear "Premi, Sanjeev",
> 
> In message 
> <B85A65D85D7EB246BE421B3FB0FBB5930247A0AA6E@dbde02.ent.ti.com>
>  you wrote:
> >
> >      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.

     However, the 2010.09-50 returns with screen pages full of the "undefined
     reference errors" and assertion failures in linker - probably due to
     undefined symbols.

     I tried to revert "sort" shared by Wolfgang; even that didn't help.

     I will start working backwards from the errors I notice with 2010.09-50.
     Should I post the errors?

~sanjeev

> 
> Best regards,
> 
> Wolfgang Denk
> 
> -- 
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Vulcans do not approve of violence.
> 	-- Spock, "Journey to Babel", stardate 3842.4
> 

[U-Boot] Build failures with older toolchain

[Albert ARIBAUD]

Le 29/11/2010 16:08, Premi, Sanjeev a ?crit :

>       I will start working backwards from the errors I notice with 2010.09-50.
>       Should I post the errors?

You should post patches against the master branch for others to be able 
to build the same code as you build. Do not post the compile errors, 
though: rather, try and find why they occur and post your conclusions.

> ~sanjeev

Amicalement,
-- 
Albert.

[U-Boot] Build failures with older toolchain

[Premi, Sanjeev]

> -----Original Message-----
> From: Albert ARIBAUD [mailto:albert.aribaud at free.fr] 
> Sent: Monday, November 29, 2010 9:04 PM
> To: Premi, Sanjeev
> Cc: Wolfgang Denk; u-boot at lists.denx.de
> Subject: Re: [U-Boot] Build failures with older toolchain
> 
> Le 29/11/2010 16:08, Premi, Sanjeev a ?crit :
> 
> >       I will start working backwards from the errors I 
> notice with 2010.09-50.
> >       Should I post the errors?
> 
> You should post patches against the master branch for others 
> to be able 
> to build the same code as you build. Do not post the compile errors, 
> though: rather, try and find why they occur and post your conclusions.

[sp] I am working on analysis.

> 
> > ~sanjeev
> 
> Amicalement,
> -- 
> Albert.
> 

[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: 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.
> 
[sp] I have been able to narrow down the problem to one variable defined
     in board/ti/evm.c - omap3_evm_version - declared as:
      static u8 omap3_evm_version;

     Any attempt to assign value this variable in omap3_evm_get_revision()
     leads to the linker error I noted with Codesourcery 2010q1-202.
     
     With 2009q1-203, definition of variable itself is sufficient to cause
     the linker error.

     I have pasted a patch below that constructs the testcase I have created
     to explain these observations:
     1) When macros both _EXCLUDE_ME_1 and _EXCLUDE_ME_2 are undefined, the
        problem is - as described.

     2) When only macro _EXCLUDE_ME_1 is defined, the compilation succeeds
        with Codesourcery 2010q1-202; but fails with 2009q1-203.

     3) When both macros _EXCLUDE_ME_1 and _EXCLUDE_ME_2 are defined, the
        compilation succeeds with both codesourcery versions.

     OMAP3EVM is obviously not the only file using statics. I see their usage
     in many files including OMAP3Beagle as well - one reason I did not even
     suspect this to be problem.

     I haven't yet been able to conclude the cause of failure - but appears
     to be related to handling of static variables across compiler versions.
     Still need to investigate further on this...

     Board revision needs to be detected early during initialization. How is
     this handled for other boards? (I am currently trying to browse non-omap
     boards for pointers). Any quick suggestions would be helpful.

[patch]
diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c
index 09d14f7..e766355 100644
--- a/board/ti/evm/evm.c
+++ b/board/ti/evm/evm.c
@@ -37,15 +37,30 @@
 #include <asm/mach-types.h>
 #include "evm.h"
 
+/* #define _EXCLUDE_ME_1 */	/* Uncomment - works with 2010q1 only */
+/* #define _EXCLUDE_ME_2 */	/* Uncomment - works with 2009q3 as well */
+
+#if !defined(_EXCLUDE_ME_2)
 static u8 omap3_evm_version;
+#endif
 
 u8 get_omap3_evm_rev(void)
 {
+#ifdef _EXCLUDE_ME_2
+	return OMAP3EVM_BOARD_GEN_1; /* Debugging: Don't use the variable */
+#else
 	return omap3_evm_version;
+#endif
+
 }
 
 static void omap3_evm_get_revision(void)
 {
+#ifdef _EXCLUDE_ME_COMPLETELY_
+	/*
+	 * Original code in the function is being removed completely to reduce
+	 * scope of the debug exercise.
+	 */
 #if defined(CONFIG_CMD_NET)
 	/*
 	 * Board revision can be ascertained only by identifying
@@ -80,6 +95,20 @@ static void omap3_evm_get_revision(void)
 	omap3_evm_version = OMAP3EVM_BOARD_GEN_2;
 #endif
 #endif	/* CONFIG_CMD_NET */
+
+#else
+	/*
+	 * Dummy implementation of function just for testing
+	 */
+
+#if !defined(_EXCLUDE_ME_1) && !defined(_EXCLUDE_ME_2)
+	/*
+	 * Dummy assignment just for testing
+	 */
+	omap3_evm_version = OMAP3EVM_BOARD_GEN_2;
+#endif
+
+#endif	/* _EXCLUDE_ME_COMPLETELY_ */
 }
 
 #ifdef CONFIG_USB_OMAP3
[/patch]

[snip]
Removed my observations for Codesourcery 2010.09-50.
Did not get chance to look at them so far...
[/snip]

Best regards,
Sanjeev

[U-Boot] Build failures with older toolchain

[Dirk Behme]

On 30.11.2010 15:25, Premi, Sanjeev wrote:
>> -----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.
>>
> [sp] I have been able to narrow down the problem to one variable defined
>       in board/ti/evm.c - omap3_evm_version - declared as:
>        static u8 omap3_evm_version;
>
>       Any attempt to assign value this variable in omap3_evm_get_revision()
>       leads to the linker error I noted with Codesourcery 2010q1-202.
>
>       With 2009q1-203, definition of variable itself is sufficient to cause
>       the linker error.

Maybe CCing Codesourcery's mailing list

http://www.codesourcery.com/archives/arm-gnu-discuss/maillist.html

could help, too? At least it's worth a try?

Dirk

>       I have pasted a patch below that constructs the testcase I have created
>       to explain these observations:
>       1) When macros both _EXCLUDE_ME_1 and _EXCLUDE_ME_2 are undefined, the
>          problem is - as described.
>
>       2) When only macro _EXCLUDE_ME_1 is defined, the compilation succeeds
>          with Codesourcery 2010q1-202; but fails with 2009q1-203.
>
>       3) When both macros _EXCLUDE_ME_1 and _EXCLUDE_ME_2 are defined, the
>          compilation succeeds with both codesourcery versions.
>
>       OMAP3EVM is obviously not the only file using statics. I see their usage
>       in many files including OMAP3Beagle as well - one reason I did not even
>       suspect this to be problem.
>
>       I haven't yet been able to conclude the cause of failure - but appears
>       to be related to handling of static variables across compiler versions.
>       Still need to investigate further on this...
>
>       Board revision needs to be detected early during initialization. How is
>       this handled for other boards? (I am currently trying to browse non-omap
>       boards for pointers). Any quick suggestions would be helpful.
>
> [patch]
> diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c
> index 09d14f7..e766355 100644
> --- a/board/ti/evm/evm.c
> +++ b/board/ti/evm/evm.c
> @@ -37,15 +37,30 @@
>   #include<asm/mach-types.h>
>   #include "evm.h"
>
> +/* #define _EXCLUDE_ME_1 */	/* Uncomment - works with 2010q1 only */
> +/* #define _EXCLUDE_ME_2 */	/* Uncomment - works with 2009q3 as well */
> +
> +#if !defined(_EXCLUDE_ME_2)
>   static u8 omap3_evm_version;
> +#endif
>
>   u8 get_omap3_evm_rev(void)
>   {
> +#ifdef _EXCLUDE_ME_2
> +	return OMAP3EVM_BOARD_GEN_1; /* Debugging: Don't use the variable */
> +#else
>   	return omap3_evm_version;
> +#endif
> +
>   }
>
>   static void omap3_evm_get_revision(void)
>   {
> +#ifdef _EXCLUDE_ME_COMPLETELY_
> +	/*
> +	 * Original code in the function is being removed completely to reduce
> +	 * scope of the debug exercise.
> +	 */
>   #if defined(CONFIG_CMD_NET)
>   	/*
>   	 * Board revision can be ascertained only by identifying
> @@ -80,6 +95,20 @@ static void omap3_evm_get_revision(void)
>   	omap3_evm_version = OMAP3EVM_BOARD_GEN_2;
>   #endif
>   #endif	/* CONFIG_CMD_NET */
> +
> +#else
> +	/*
> +	 * Dummy implementation of function just for testing
> +	 */
> +
> +#if !defined(_EXCLUDE_ME_1)&&  !defined(_EXCLUDE_ME_2)
> +	/*
> +	 * Dummy assignment just for testing
> +	 */
> +	omap3_evm_version = OMAP3EVM_BOARD_GEN_2;
> +#endif
> +
> +#endif	/* _EXCLUDE_ME_COMPLETELY_ */
>   }
>
>   #ifdef CONFIG_USB_OMAP3
> [/patch]
>
> [snip]
> Removed my observations for Codesourcery 2010.09-50.
> Did not get chance to look at them so far...
> [/snip]
>
> Best regards,
> Sanjeev
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

[U-Boot] Build failures with older toolchain

[Premi, Sanjeev]

> -----Original Message-----
> From: Dirk Behme [mailto:dirk.behme at googlemail.com] 
> Sent: Tuesday, November 30, 2010 10:15 PM
> To: Premi, Sanjeev
> Cc: u-boot at lists.denx.de
> Subject: Re: [U-Boot] Build failures with older toolchain
> 
> On 30.11.2010 15:25, Premi, Sanjeev wrote:
> >> -----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.
> >>
> > [sp] I have been able to narrow down the problem to one 
> variable defined
> >       in board/ti/evm.c - omap3_evm_version - declared as:
> >        static u8 omap3_evm_version;
> >
> >       Any attempt to assign value this variable in 
> omap3_evm_get_revision()
> >       leads to the linker error I noted with Codesourcery 
> 2010q1-202.
> >
> >       With 2009q1-203, definition of variable itself is 
> sufficient to cause
> >       the linker error.
> 
> Maybe CCing Codesourcery's mailing list
> 
> http://www.codesourcery.com/archives/arm-gnu-discuss/maillist.html
> 
> could help, too? At least it's worth a try?

I was thinking of same - only after we understand if there isn't
something we are, possibly, missing in changes to linker scripts.

> 
> Dirk
> 
> >       I have pasted a patch below that constructs the 
> testcase I have created
> >       to explain these observations:
> >       1) When macros both _EXCLUDE_ME_1 and _EXCLUDE_ME_2 
> are undefined, the
> >          problem is - as described.
> >
> >       2) When only macro _EXCLUDE_ME_1 is defined, the 
> compilation succeeds
> >          with Codesourcery 2010q1-202; but fails with 2009q1-203.
> >
> >       3) When both macros _EXCLUDE_ME_1 and _EXCLUDE_ME_2 
> are defined, the
> >          compilation succeeds with both codesourcery versions.
> >
> >       OMAP3EVM is obviously not the only file using 
> statics. I see their usage
> >       in many files including OMAP3Beagle as well - one 
> reason I did not even
> >       suspect this to be problem.
> >
> >       I haven't yet been able to conclude the cause of 
> failure - but appears
> >       to be related to handling of static variables across 
> compiler versions.
> >       Still need to investigate further on this...
> >
> >       Board revision needs to be detected early during 
> initialization. How is
> >       this handled for other boards? (I am currently trying 
> to browse non-omap
> >       boards for pointers). Any quick suggestions would be helpful.
> >
> > [patch]
> > diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c
> > index 09d14f7..e766355 100644
> > --- a/board/ti/evm/evm.c
> > +++ b/board/ti/evm/evm.c
> > @@ -37,15 +37,30 @@
> >   #include<asm/mach-types.h>
> >   #include "evm.h"
> >
> > +/* #define _EXCLUDE_ME_1 */	/* Uncomment - works 
> with 2010q1 only */
> > +/* #define _EXCLUDE_ME_2 */	/* Uncomment - works 
> with 2009q3 as well */
> > +
> > +#if !defined(_EXCLUDE_ME_2)
> >   static u8 omap3_evm_version;
> > +#endif
> >
> >   u8 get_omap3_evm_rev(void)
> >   {
> > +#ifdef _EXCLUDE_ME_2
> > +	return OMAP3EVM_BOARD_GEN_1; /* Debugging: Don't use 
> the variable */
> > +#else
> >   	return omap3_evm_version;
> > +#endif
> > +
> >   }
> >
> >   static void omap3_evm_get_revision(void)
> >   {
> > +#ifdef _EXCLUDE_ME_COMPLETELY_
> > +	/*
> > +	 * Original code in the function is being removed 
> completely to reduce
> > +	 * scope of the debug exercise.
> > +	 */
> >   #if defined(CONFIG_CMD_NET)
> >   	/*
> >   	 * Board revision can be ascertained only by identifying
> > @@ -80,6 +95,20 @@ static void omap3_evm_get_revision(void)
> >   	omap3_evm_version = OMAP3EVM_BOARD_GEN_2;
> >   #endif
> >   #endif	/* CONFIG_CMD_NET */
> > +
> > +#else
> > +	/*
> > +	 * Dummy implementation of function just for testing
> > +	 */
> > +
> > +#if !defined(_EXCLUDE_ME_1)&&  !defined(_EXCLUDE_ME_2)
> > +	/*
> > +	 * Dummy assignment just for testing
> > +	 */
> > +	omap3_evm_version = OMAP3EVM_BOARD_GEN_2;
> > +#endif
> > +
> > +#endif	/* _EXCLUDE_ME_COMPLETELY_ */
> >   }
> >
> >   #ifdef CONFIG_USB_OMAP3
> > [/patch]
> >
> > [snip]
> > Removed my observations for Codesourcery 2010.09-50.
> > Did not get chance to look at them so far...
> > [/snip]
> >
> > Best regards,
> > Sanjeev
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
> >
> 
> 

[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

[U-Boot] Build failures with older toolchain

[Albert ARIBAUD]

Le 01/12/2010 15:56, Premi, Sanjeev a ?crit :

> When everything failed, I went back to the u-boot.lds and
> changed the way overlay is defined.
>
> ...AND PROBLEM SEEMS TO BE SOLVED!

This most probably means some of the code running before relocation uses 
BSS; see below.

> 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.

This is normal and should not have any negative impact as long as code 
that runs before relocation does not access BSS -- and it should not, 
since BSS only exists after relocation.

> 2) The size of .rodata has increased. (Why? not yet spent time on?)

Weird. Can you provide all necessary info for duplicating these two builds?

> Sending the patch in next few mins:

If that's a patch to remove the overlay in the .lds, it's a Nak from me 
already.

> ~sanjeev

Amicalement,
-- 
Albert.

[U-Boot] Build failures with older toolchain

[Premi, Sanjeev]

> -----Original Message-----
> From: Albert ARIBAUD [mailto:albert.aribaud at free.fr] 
> Sent: Wednesday, December 01, 2010 8:33 PM
> To: Premi, Sanjeev
> Cc: u-boot at lists.denx.de; Wolfgang Denk
> Subject: Re: [U-Boot] Build failures with older toolchain
> 
> Le 01/12/2010 15:56, Premi, Sanjeev a ?crit :
> 
> > When everything failed, I went back to the u-boot.lds and
> > changed the way overlay is defined.
> >
> > ...AND PROBLEM SEEMS TO BE SOLVED!
> 
> This most probably means some of the code running before 
> relocation uses 
> BSS; see below.
> 
> > 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.
> 
> This is normal and should not have any negative impact as 
> long as code 
> that runs before relocation does not access BSS -- and it should not, 
> since BSS only exists after relocation.

[sp] Yes. This is what I wanted to confirm to ensure that relocation
     isn't breaking after the changes. In a way it was my testcase
     to see that I get similar map for omap3_beagle before and after
     making changes.
> 
> > 2) The size of .rodata has increased. (Why? not yet spent time on?)
> 
> Weird. Can you provide all necessary info for duplicating 
> these two builds?
> 
> > Sending the patch in next few mins:
> 
> If that's a patch to remove the overlay in the .lds, it's a 
> Nak from me 
> already.

[sp] No. I am not removing relocation. Do look at the patch.
     I just sent from my Linux box..

> 
> > ~sanjeev
> 
> Amicalement,
> -- 
> Albert.
> 

[U-Boot] Build failures with older toolchain

[Wolfgang Denk]

Dear "Premi, Sanjeev",

can you please quote onlye _relevant_ parts of previous messages?
Thanks.

In message <B85A65D85D7EB246BE421B3FB0FBB5930247A0A94F@dbde02.ent.ti.com> you wrote:
>
> with 2009-q1 toolchain:
> -----------------------
> busb_phy.o drivers/video/libvideo.o drivers/watchdog/libwatchdog.o common/libcommon.o lib/libfdt/libfdt.o api/libapi.o post/libpost.o arch/arm/cpu/armv7/omap-common/libomap-common.o board/ti/evm/libevm.o --end-group /db/psp_git/users/a0756819/u-boot/arch/arm/lib/eabi_compat.o -L /opt/codesourcery/2009q1-203/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3 -lgcc -Map u-boot.map -o u-boot
> arm-none-linux-gnueabi-ld: section .bss [8003f5c0 -> 8007e31f] overlaps section .rel.dyn [8003f5c0 -> 80044e4f]
> arm-none-linux-gnueabi-ld: section .dynsym [80044e50 -> 80044eef] overlaps section .bss [8003f5c0 -> 8007e31f]
> arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5c0 overlaps previous sections
> make: *** [u-boot] Error 1
> 
> with 2010-q1 toolchain:
> -----------------------
> mmon/libomap-common.o board/ti/evm/libevm.o --end-group /db/psp_git/users/a0756819/u-boot/arch/arm/lib/eabi_compat.o -L /opt/codesourcery/2010q1-202/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/armv4t -lgcc -Map u-boot.map -o u-boot
> arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003e8e0 overlaps previous sections
> arm-none-linux-gnueabi-objcopy -O srec u-boot u-boot.srec
> arm-none-linux-gnueabi-objcopy --gap-fill=0xff -O binary u-boot u-boot.bin

Are you sure these are the only errors you see?

Because for me, building for omap3_evm fails like this:

start.S: Assembler messages:
start.S:144: Error: constant expression expected -- `ldr sp,=((0x4020FFFC-CONFIG_SYS_GBL_DATA_SIZE))'
make[1]: *** [/work/wd/tmp-arm/arch/arm/cpu/armv7/start.o] Error 1
make: *** [/work/wd/tmp-arm/arch/arm/cpu/armv7/start.o] Error 2
make: *** Waiting for unfinished jobs....
make: *** wait: No child processes.  Stop.

And this is a clear indication that the board support code has not
been adapted yet (CONFIG_SYS_GBL_DATA_SIZE has been replaced by
GENERATED_GBL_DATA_SIZE some time ago).


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You said you  didn't  want  to  use  CGI.pm,  but  methinks  you  are
needlessly reinventing the wheel, one spoke at a time. Either you are
masochistic,  or  you  just haven't seen enough of what CGI.pm can do
for you. -- Randal L. Schwartz in <8cyb81rg81.fsf@gadget.cscaper.com>

[U-Boot] Build failures with older toolchain

[Premi, Sanjeev]

 

> -----Original Message-----
> From: Wolfgang Denk [mailto:wd at denx.de] 
> Sent: Monday, November 29, 2010 4:05 PM
> To: Premi, Sanjeev
> Cc: Albert ARIBAUD; u-boot at lists.denx.de
> Subject: Re: [U-Boot] Build failures with older toolchain
> 
> Dear "Premi, Sanjeev",
> 
> can you please quote onlye _relevant_ parts of previous messages?
> Thanks.

[sp] I do try to snip the messages. I didn't do so this time
     to maintain context - but, may be, I erred on wrong side.

> 
> In message 
> <B85A65D85D7EB246BE421B3FB0FBB5930247A0A94F@dbde02.ent.ti.com>
>  you wrote:
> >

[snip]

> 
> Are you sure these are the only errors you see?
> 
> Because for me, building for omap3_evm fails like this:
> 
> start.S: Assembler messages:
> start.S:144: Error: constant expression expected -- `ldr 
> sp,=((0x4020FFFC-CONFIG_SYS_GBL_DATA_SIZE))'
> make[1]: *** [/work/wd/tmp-arm/arch/arm/cpu/armv7/start.o] Error 1
> make: *** [/work/wd/tmp-arm/arch/arm/cpu/armv7/start.o] Error 2
> make: *** Waiting for unfinished jobs....
> make: *** wait: No child processes.  Stop.
> 
> And this is a clear indication that the board support code has not
> been adapted yet (CONFIG_SYS_GBL_DATA_SIZE has been replaced by
> GENERATED_GBL_DATA_SIZE some time ago).

[sp] I just responded to Albert' message on same issue.

     I stumbled on the current problem while trying to fix just the
     problem you notice here.

     Assuming relation, I had not submitted the patch - so far. But
     it looks to be causing more confusion - so patch follows in next
     few mins.

~sanjeev

> 
> 
> Best regards,
> 
> Wolfgang Denk
> 
> -- 
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> You said you  didn't  want  to  use  CGI.pm,  but  methinks  you  are
> needlessly reinventing the wheel, one spoke at a time. Either you are
> masochistic,  or  you  just haven't seen enough of what CGI.pm can do
> for you. -- Randal L. Schwartz in <8cyb81rg81.fsf@gadget.cscaper.com>
>