[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-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
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Saturday, November 20, 2010 12:21 AM To: u-boot@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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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 linkingIs 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
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Saturday, November 20, 2010 1:44 AM To: Premi, Sanjeev Cc: u-boot@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 linkingIs 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@denx.de The use of anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity. -- Edsger Dijkstra
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Monday, November 22, 2010 2:44 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Saturday, November 20, 2010 1:44 AM To: Premi, Sanjeev Cc: u-boot@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 linkingIs 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@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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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,
-----Original Message----- From: Albert ARIBAUD [mailto:albert.aribaud@free.fr] Sent: Monday, November 22, 2010 8:02 PM To: Premi, Sanjeev Cc: Wolfgang Denk; u-boot@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.
-----Original Message----- From: Albert ARIBAUD [mailto:albert.aribaud@free.fr] Sent: Monday, November 22, 2010 8:02 PM To: Premi, Sanjeev Cc: Wolfgang Denk; u-boot@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=aaeb0a890a050b58be87fa2b165e...
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.
Le 22/11/2010 16:02, Premi, Sanjeev a écrit :
-----Original Message----- From: Albert ARIBAUD [mailto:albert.aribaud@free.fr] Sent: Monday, November 22, 2010 8:02 PM To: Premi, Sanjeev Cc: Wolfgang Denk; u-boot@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=aaeb0a890a050b58be87fa2b165e...
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,
-----Original Message----- From: Albert ARIBAUD [mailto:albert.aribaud@free.fr] Sent: Monday, November 22, 2010 8:54 PM To: Premi, Sanjeev Cc: u-boot@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@free.fr] Sent: Monday, November 22, 2010 8:02 PM To: Premi, Sanjeev Cc: Wolfgang Denk; u-boot@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.
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,
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Monday, November 22, 2010 8:57 PM To: Albert ARIBAUD Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain
-----Original Message----- From: Albert ARIBAUD [mailto:albert.aribaud@free.fr] Sent: Monday, November 22, 2010 8:54 PM To: Premi, Sanjeev Cc: u-boot@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@free.fr] Sent: Monday, November 22, 2010 8:02 PM To: Premi, Sanjeev Cc: Wolfgang Denk; u-boot@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 andarmv7/u-boot.lds
to be similar. Your commit mentions about the new ld vs. old; Ihad seen this
earlier as well. It was the reason for me to tryCodeSourcery
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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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@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@lilith:~/src/u-boot$
Best regards, Sanjeev
Amicalement,
-----Original Message----- From: Albert ARIBAUD [mailto:albert.aribaud@free.fr] Sent: Monday, November 29, 2010 4:03 PM To: u-boot@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@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@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.
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
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Monday, November 29, 2010 5:00 PM To: Premi, Sanjeev Cc: Albert ARIBAUD; u-boot@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]
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
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Monday, November 29, 2010 5:35 PM To: Premi, Sanjeev Cc: Albert ARIBAUD; u-boot@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 fromcodesourcery
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@denx.de Vulcans do not approve of violence. -- Spock, "Journey to Babel", stardate 3842.4
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,
-----Original Message----- From: Albert ARIBAUD [mailto:albert.aribaud@free.fr] Sent: Monday, November 29, 2010 9:04 PM To: Premi, Sanjeev Cc: Wolfgang Denk; u-boot@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 Inotice 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.
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Monday, November 29, 2010 8:38 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain
[snip]...[snip]
I am process of downloading the 2009q3 version fromcodesourcery
Albert mentioned he is using it. Are you on the sameversion 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 between2009q3 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
On 30.11.2010 15:25, Premi, Sanjeev wrote:
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Monday, November 29, 2010 8:38 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain
[snip]...[snip]
I am process of downloading the 2009q3 version fromcodesourcery
Albert mentioned he is using it. Are you on the sameversion 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 between2009q3 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.*/
- 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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
-----Original Message----- From: Dirk Behme [mailto:dirk.behme@googlemail.com] Sent: Tuesday, November 30, 2010 10:15 PM To: Premi, Sanjeev Cc: u-boot@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@lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Monday, November 29, 2010 8:38 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain
[snip]...[snip]
I am process of downloading the 2009q3 version fromcodesourcery
Albert mentioned he is using it. Are you on the sameversion 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 between2009q3 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 inomap3_evm_get_revision()
leads to the linker error I noted with Codesourcery2010q1-202.
With 2009q1-203, definition of variable itself issufficient 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 thetestcase I have created
to explain these observations: 1) When macros both _EXCLUDE_ME_1 and _EXCLUDE_ME_2are undefined, the
problem is - as described. 2) When only macro _EXCLUDE_ME_1 is defined, thecompilation succeeds
with Codesourcery 2010q1-202; but fails with 2009q1-203. 3) When both macros _EXCLUDE_ME_1 and _EXCLUDE_ME_2are defined, the
compilation succeeds with both codesourcery versions. OMAP3EVM is obviously not the only file usingstatics. I see their usage
in many files including OMAP3Beagle as well - onereason I did not even
suspect this to be problem. I haven't yet been able to conclude the cause offailure - but appears
to be related to handling of static variables acrosscompiler versions.
Still need to investigate further on this... Board revision needs to be detected early duringinitialization. How is
this handled for other boards? (I am currently tryingto 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 removedcompletely to reduce
* scope of the debug exercise.*/
- 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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Tuesday, November 30, 2010 7:56 PM To: u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Monday, November 29, 2010 8:38 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain
[snip]...[snip]
I am process of downloading the 2009q3 version fromcodesourcery
Albert mentioned he is using it. Are you on the sameversion 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 between2009q3 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
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:
- .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.
- 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,
-----Original Message----- From: Albert ARIBAUD [mailto:albert.aribaud@free.fr] Sent: Wednesday, December 01, 2010 8:33 PM To: Premi, Sanjeev Cc: u-boot@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:
- .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.
- 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.
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
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Monday, November 29, 2010 4:05 PM To: Premi, Sanjeev Cc: Albert ARIBAUD; u-boot@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@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
participants (4)
-
Albert ARIBAUD -
Dirk Behme -
Premi, Sanjeev -
Wolfgang Denk