[U-Boot-Users] [PATCH] Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections
With recent toolchain versions, some boards would not build because or errors like this one (here for ocotea board when building with ELDK 4.2): ppc_4xx-ld: section .bootpg [fffff000 -> fffff23b] overlaps section .bss [fffee900 -> fffff8ab]
For many boards, the .bss section is big enough that it wraps around at the end of the address space (0xFFFFFFFF), so the problem will not be visible unless you use a 64 bit tool chain for development. On some boards however, changes to the code size (due to different optimizations) we bail out with section overlaps like above.
The fix is to add the NOLOAD attribute to the .bss and .sbss sections, telling the linker that .bss does not consume any space in the image.
Signed-off-by: Wolfgang Denk wd@denx.de --- board/BuS/EB+MCF-EV123/u-boot.lds | 2 +- board/LEOX/elpt860/u-boot.lds | 2 +- board/MAI/AmigaOneG3SE/u-boot.lds | 2 +- board/Marvell/db64360/u-boot.lds | 2 +- board/Marvell/db64460/u-boot.lds | 2 +- board/RPXClassic/u-boot.lds | 2 +- board/RPXlite/u-boot.lds | 2 +- board/RPXlite_dw/u-boot.lds | 2 +- board/RRvision/u-boot.lds | 2 +- board/adder/u-boot.lds | 2 +- board/ads5121/u-boot.lds | 2 +- board/adsvix/u-boot.lds | 2 +- board/altera/dk1c20/u-boot.lds | 2 +- board/altera/dk1s10/u-boot.lds | 2 +- board/altera/ep1c20/u-boot.lds | 4 ++-- board/altera/ep1s10/u-boot.lds | 4 ++-- board/altera/ep1s40/u-boot.lds | 4 ++-- board/amcc/acadia/u-boot-nand.lds | 2 +- board/amcc/acadia/u-boot.lds | 2 +- board/amcc/bamboo/u-boot-nand.lds | 2 +- board/amcc/bamboo/u-boot.lds | 2 +- board/amcc/bubinga/u-boot.lds | 2 +- board/amcc/ebony/u-boot.lds | 2 +- board/amcc/katmai/u-boot.lds | 2 +- board/amcc/luan/u-boot.lds | 2 +- board/amcc/ocotea/u-boot.lds | 2 +- board/amcc/sequoia/u-boot-nand.lds | 2 +- board/amcc/sequoia/u-boot.lds | 2 +- board/amcc/taihu/u-boot.lds | 2 +- board/amcc/taishan/u-boot.lds | 2 +- board/amcc/walnut/u-boot.lds | 2 +- board/amcc/yosemite/u-boot.lds | 2 +- board/amcc/yucca/u-boot.lds | 2 +- board/amirix/ap1000/u-boot.lds | 2 +- board/armadillo/u-boot.lds | 2 +- board/assabet/u-boot.lds | 2 +- board/at91rm9200dk/u-boot.lds | 2 +- board/atmel/atstk1000/u-boot.lds | 2 +- board/c2mon/u-boot.lds | 2 +- board/cds/mpc8541cds/u-boot.lds | 2 +- board/cds/mpc8548cds/u-boot.lds | 2 +- board/cds/mpc8555cds/u-boot.lds | 2 +- board/cerf250/u-boot.lds | 2 +- board/cm4008/u-boot.lds | 2 +- board/cm41xx/u-boot.lds | 2 +- board/cm5200/u-boot.lds | 2 +- board/cmc_pu2/u-boot.lds | 2 +- board/cobra5272/u-boot.lds | 2 +- board/cogent/u-boot.lds | 2 +- board/cradle/u-boot.lds | 2 +- board/cray/L1/u-boot.lds | 2 +- board/csb226/u-boot.lds | 2 +- board/csb272/u-boot.lds | 2 +- board/csb472/u-boot.lds | 2 +- board/csb637/u-boot.lds | 2 +- board/dave/B2/u-boot.lds | 2 +- board/dave/PPChameleonEVB/u-boot.lds | 2 +- board/davinci/dv-evm/u-boot.lds | 2 +- board/davinci/schmoogie/u-boot.lds | 2 +- board/davinci/sonata/u-boot.lds | 2 +- board/dbau1x00/u-boot.lds | 4 ++-- board/delta/u-boot.lds | 2 +- board/dnp1110/u-boot.lds | 2 +- board/eltec/bab7xx/u-boot.lds | 2 +- board/eltec/elppc/u-boot.lds | 2 +- board/eltec/mhpc/u-boot.lds | 2 +- board/emk/top860/u-boot.lds | 2 +- board/ep7312/u-boot.lds | 2 +- board/ep88x/u-boot.lds | 2 +- board/eric/u-boot.lds | 2 +- board/esd/adciop/u-boot.lds | 2 +- board/esd/apc405/u-boot.lds | 2 +- board/esd/ar405/u-boot.lds | 2 +- board/esd/ash405/u-boot.lds | 2 +- board/esd/canbt/u-boot.lds | 2 +- board/esd/cms700/u-boot.lds | 2 +- board/esd/cpci2dp/u-boot.lds | 2 +- board/esd/cpci405/u-boot.lds | 2 +- board/esd/cpci440/u-boot.lds | 2 +- board/esd/cpci750/u-boot.lds | 2 +- board/esd/cpciiser4/u-boot.lds | 2 +- board/esd/dasa_sim/u-boot.lds | 2 +- board/esd/dp405/u-boot.lds | 2 +- board/esd/du405/u-boot.lds | 2 +- board/esd/hh405/u-boot.lds | 2 +- board/esd/hub405/u-boot.lds | 2 +- board/esd/ocrtc/u-boot.lds | 2 +- board/esd/pci405/u-boot.lds | 2 +- board/esd/plu405/u-boot.lds | 2 +- board/esd/pmc405/u-boot.lds | 2 +- board/esd/tasreg/u-boot.lds | 2 +- board/esd/voh405/u-boot.lds | 2 +- board/esd/vom405/u-boot.lds | 2 +- board/esd/wuh405/u-boot.lds | 2 +- board/esteem192e/u-boot.lds | 2 +- board/etx094/u-boot.lds | 2 +- board/evb4510/u-boot.lds | 2 +- board/evb64260/u-boot.lds | 2 +- board/exbitgen/u-boot.lds | 2 +- board/fads/u-boot.lds | 2 +- board/flagadm/u-boot.lds | 2 +- board/freescale/m5235evb/u-boot.lds | 2 +- board/freescale/m5249evb/u-boot.lds | 2 +- board/freescale/m5253evbe/u-boot.lds | 2 +- board/freescale/m5329evb/u-boot.lds | 2 +- board/freescale/m54455evb/u-boot.lds | 2 +- board/freescale/mpc8544ds/u-boot.lds | 2 +- board/freescale/mpc8641hpcn/u-boot.lds | 2 +- board/g2000/u-boot.lds | 2 +- board/gcplus/u-boot.lds | 2 +- board/gen860t/u-boot-flashenv.lds | 2 +- board/gen860t/u-boot.lds | 2 +- board/genietv/u-boot.lds | 2 +- board/gth/u-boot.lds | 2 +- board/gth2/u-boot.lds | 4 ++-- board/hermes/u-boot.lds | 2 +- board/hymod/u-boot.lds | 2 +- board/icu862/u-boot.lds | 2 +- board/idmr/u-boot.lds | 2 +- board/impa7/u-boot.lds | 2 +- board/incaip/u-boot.lds | 4 ++-- board/innokom/u-boot.lds | 2 +- board/ip860/u-boot.lds | 2 +- board/ivm/u-boot.lds | 2 +- board/ixdp425/u-boot.lds | 2 +- board/jse/u-boot.lds | 2 +- board/kb9202/u-boot.lds | 2 +- board/kup/kup4k/u-boot.lds | 2 +- board/kup/kup4x/u-boot.lds | 2 +- board/lantec/u-boot.lds | 2 +- board/lart/u-boot.lds | 2 +- board/logodl/u-boot.lds | 2 +- board/lpc2292sodimm/u-boot.lds | 2 +- board/lpd7a40x/u-boot.lds | 2 +- board/lubbock/u-boot.lds | 2 +- board/lwmon/u-boot.lds | 2 +- board/lwmon5/u-boot.lds | 2 +- board/m5271evb/u-boot.lds | 2 +- board/m5272c3/u-boot.lds | 2 +- board/m5282evb/u-boot.lds | 2 +- board/mbx8xx/u-boot.lds | 2 +- board/ml2/u-boot.lds | 2 +- board/modnet50/u-boot.lds | 2 +- board/mousse/u-boot.lds | 2 +- board/mp2usb/u-boot.lds | 2 +- board/mpc7448hpc2/u-boot.lds | 2 +- board/mpc8540ads/u-boot.lds | 2 +- board/mpc8540eval/u-boot.lds | 2 +- board/mpc8560ads/u-boot.lds | 2 +- board/mpc8568mds/u-boot.lds | 2 +- board/mpl/mip405/u-boot.lds | 2 +- board/mpl/pip405/u-boot.lds | 2 +- board/mpl/vcma9/u-boot.lds | 2 +- board/mvs1/u-boot.lds | 2 +- board/mx1ads/u-boot.lds | 2 +- board/mx1fs2/u-boot.lds | 2 +- board/nc650/u-boot.lds | 2 +- board/netphone/u-boot.lds | 2 +- board/netstal/hcu4/u-boot.lds | 2 +- board/netstal/hcu5/u-boot.lds | 2 +- board/netstar/u-boot.lds | 2 +- board/netta/u-boot.lds | 2 +- board/netta2/u-boot.lds | 2 +- board/netvia/u-boot.lds | 2 +- board/ns9750dev/u-boot.lds | 2 +- board/nx823/u-boot.lds | 2 +- board/omap1510inn/u-boot.lds | 2 +- board/omap1610inn/u-boot.lds | 2 +- board/omap2420h4/u-boot.lds | 2 +- board/omap5912osk/u-boot.lds | 2 +- board/omap730p2/u-boot.lds | 2 +- board/pb1x00/u-boot.lds | 4 ++-- board/pcippc2/u-boot.lds | 2 +- board/pcs440ep/u-boot.lds | 2 +- board/pleb2/u-boot.lds | 2 +- board/pm854/u-boot.lds | 2 +- board/pm856/u-boot.lds | 2 +- board/ppmc7xx/u-boot.lds | 2 +- board/prodrive/alpr/u-boot.lds | 2 +- board/prodrive/p3mx/u-boot.lds | 2 +- board/prodrive/p3p440/u-boot.lds | 2 +- board/prodrive/pdnb3/u-boot.lds | 2 +- board/psyent/pci5441/u-boot.lds | 4 ++-- board/psyent/pk1c20/u-boot.lds | 4 ++-- board/purple/u-boot.lds | 4 ++-- board/pxa255_idp/u-boot.lds | 2 +- board/quantum/u-boot.lds | 2 +- board/r360mpi/u-boot.lds | 2 +- board/r5200/u-boot.lds | 2 +- board/rbc823/u-boot.lds | 2 +- board/rmu/u-boot.lds | 2 +- board/rsdproto/u-boot.lds | 2 +- board/sandburst/karef/u-boot.lds | 2 +- board/sandburst/metrobox/u-boot.lds | 2 +- board/sbc2410x/u-boot.lds | 2 +- board/sbc405/u-boot.lds | 2 +- board/sbc8560/u-boot.lds | 2 +- board/sbc8641d/u-boot.lds | 2 +- board/sc3/u-boot.lds | 2 +- board/sc520_cdp/u-boot.lds | 2 +- board/sc520_spunk/u-boot.lds | 2 +- board/scb9328/u-boot.lds | 2 +- board/shannon/u-boot.lds | 2 +- board/siemens/CCM/u-boot.lds | 2 +- board/siemens/IAD210/u-boot.lds | 2 +- board/siemens/SMN42/u-boot.lds | 2 +- board/siemens/pcu_e/u-boot.lds | 2 +- board/sixnet/u-boot.lds | 2 +- board/smdk2400/u-boot.lds | 2 +- board/smdk2410/u-boot.lds | 2 +- board/snmc/qs850/u-boot.lds | 2 +- board/snmc/qs860t/u-boot.lds | 2 +- board/spc1920/u-boot.lds | 2 +- board/spd8xx/u-boot.lds | 2 +- board/ssv/adnpesc1/u-boot.lds | 2 +- board/stxgp3/u-boot.lds | 2 +- board/stxssa/u-boot.lds | 2 +- board/stxxtc/u-boot.lds | 2 +- board/svm_sc8xx/u-boot.lds | 2 +- board/sx1/u-boot.lds | 2 +- board/tb0229/u-boot.lds | 4 ++-- board/tqm85xx/u-boot.lds | 2 +- board/tqm8xx/u-boot.lds | 2 +- board/trab/u-boot.lds | 2 +- board/trizepsiv/u-boot.lds | 2 +- board/uc100/u-boot.lds | 2 +- board/v37/u-boot.lds | 2 +- board/versatile/u-boot.lds | 2 +- board/voiceblue/u-boot.lds | 2 +- board/w7o/u-boot.lds | 2 +- board/wepep250/u-boot.lds | 2 +- board/westel/amx860/u-boot.lds | 2 +- board/xaeniax/u-boot.lds | 2 +- board/xilinx/ml300/u-boot.lds | 2 +- board/xm250/u-boot.lds | 2 +- board/xpedite1k/u-boot.lds | 2 +- board/xsengine/u-boot.lds | 2 +- board/zeus/u-boot.lds | 2 +- board/zylonite/u-boot.lds | 2 +- cpu/mpc5xx/u-boot.lds | 2 +- cpu/mpc5xxx/u-boot-customlayout.lds | 2 +- cpu/mpc5xxx/u-boot.lds | 2 +- cpu/mpc8220/u-boot.lds | 2 +- cpu/mpc824x/u-boot.lds | 2 +- cpu/mpc8260/u-boot.lds | 2 +- cpu/mpc83xx/u-boot.lds | 2 +- nand_spl/board/amcc/acadia/u-boot.lds | 2 +- nand_spl/board/amcc/bamboo/u-boot.lds | 2 +- nand_spl/board/amcc/sequoia/u-boot.lds | 2 +- 249 files changed, 260 insertions(+), 260 deletions(-)
Patch exceeds mailing list's message size limit.
Please see ftp://ftp.denx.de/pub/tmp/Fix-linker-scripts-BSS-NOLOAD.patch
On Fri, 7 Dec 2007 12:16:54 +0100 Wolfgang Denk wd@denx.de wrote:
With recent toolchain versions, some boards would not build because or errors like this one (here for ocotea board when building with ELDK 4.2): ppc_4xx-ld: section .bootpg [fffff000 -> fffff23b] overlaps section .bss [fffee900 -> fffff8ab]
For many boards, the .bss section is big enough that it wraps around at the end of the address space (0xFFFFFFFF), so the problem will not be visible unless you use a 64 bit tool chain for development. On some boards however, changes to the code size (due to different optimizations) we bail out with section overlaps like above.
The fix is to add the NOLOAD attribute to the .bss and .sbss sections, telling the linker that .bss does not consume any space in the image.
YAY! I've been having to work around this for a while now. Looking forward to trying it out.
josh
Hi All,
This fix doesn't work with binutils-2.18. I'm building u-boot for the amcc yosemite board using cygwin and cross binutils-2.18/gcc-4.2.2 for a powerpc-eabi target. The linker complains that "section .text can't be allocated in segment 0." The .bss section is by default a NOLOAD section with binutils-2.18 meaning it occupies no space in the file. However, the .bss section is an ALLOC section meaning it does occupy space in target memory. The linker runs an error check to make sure all sections will fit within the file and all sections will fit within target memory. All sections do fit within the file, however the sections do not fit within target memory because of the wrap around end of memory.
We could definitely drop the TEXT_BASE address lower which would fix the problem, but isn't ideal since the image would take up more flash for no reason. We could link with TEXT_BASE=0 and then burn it to flash at address 0xFFF80000 (this is where the current TEXT_BASE is for the yosemite board). Whats the reason it's linked at 0xFFF80000 anyway? Is there an elf loader which burns it into flash? There's also the 'AT' attribute in the linker script which may help, however, I don't quite understand the use of it yet. Any suggestions on how to approach this?
Thanks, Brian
Josh Boyer-3 wrote:
On Fri, 7 Dec 2007 12:16:54 +0100 Wolfgang Denk wd@denx.de wrote:
With recent toolchain versions, some boards would not build because or errors like this one (here for ocotea board when building with ELDK 4.2): ppc_4xx-ld: section .bootpg [fffff000 -> fffff23b] overlaps section .bss [fffee900 -> fffff8ab]
For many boards, the .bss section is big enough that it wraps around at the end of the address space (0xFFFFFFFF), so the problem will not be visible unless you use a 64 bit tool chain for development. On some boards however, changes to the code size (due to different optimizations) we bail out with section overlaps like above.
The fix is to add the NOLOAD attribute to the .bss and .sbss sections, telling the linker that .bss does not consume any space in the image.
YAY! I've been having to work around this for a while now. Looking forward to trying it out.
josh
SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
brino schrieb:
Hi All,
This fix doesn't work with binutils-2.18. I'm building u-boot for the amcc yosemite board using cygwin and cross binutils-2.18/gcc-4.2.2 for a powerpc-eabi target.
Yes, binutils-2.18 have this broken. binutils-2.17 work fine.
The linker complains that "section .text can't be allocated in segment 0." The .bss section is by default a NOLOAD section with binutils-2.18 meaning it occupies no space in the file. However, the .bss section is an ALLOC section meaning it does occupy space in target memory. The linker runs an error check to make sure all sections will fit within the file and all sections will fit within target memory. All sections do fit within the file, however the sections do not fit within target memory because of the wrap around end of memory.
We could definitely drop the TEXT_BASE address lower which would fix the problem, but isn't ideal since the image would take up more flash for no reason. We could link with TEXT_BASE=0 and then burn it to flash at address 0xFFF80000 (this is where the current TEXT_BASE is for the yosemite board). Whats the reason it's linked at 0xFFF80000 anyway? Is there an elf loader which burns it into flash? There's also the 'AT' attribute in the linker script which may help, however, I don't quite understand the use of it yet. Any suggestions on how to approach this?
I am about to verify the latest binutils-snapshot. There have been the following patch included: http://sourceware.org/ml/binutils/2007-11/msg00235.html which should fix that issue.
Please be patient... I'll give you an update ASAP.
Regards,
Clemens Koller __________________________________ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com
[CCed to current thread at binutils list: Re: binutils-2.18 and U-Boot]
Clemens Koller schrieb:
brino schrieb:
Hi All,
This fix doesn't work with binutils-2.18. I'm building u-boot for the amcc yosemite board using cygwin and cross binutils-2.18/gcc-4.2.2 for a powerpc-eabi target.
Yes, binutils-2.18 have this broken. binutils-2.17 work fine.
In the latest binutils-snapshot (at least):
$ ld -v GNU ld (GNU Binutils) 2.18.50.20071212
this problem was fixed by: http://sourceware.org/ml/binutils/2007-11/msg00235.html
U-Boot commit 41be969f4957115ed7b1fe8b890bfaee99d7a7a2 Author: Wolfgang Denk wd@denx.de Date: Thu Dec 6 10:21:19 2007 +0100 Release v1.3.1 compiled a $ make TQM8540_config target with gcc-4.2.2 within an native mpc8540 environment.
I cannot run-test now, but I will close binutils bug 5205 now: http://www.sourceware.org/bugzilla/show_bug.cgi?id=5205
Thanks for the detailed report to Brian and for the fix to Nathan. :-)
Regards,
In message 1197026214-31034-1-git-send-email-wd@denx.de you wrote:
With recent toolchain versions, some boards would not build because or errors like this one (here for ocotea board when building with ELDK 4.2): ppc_4xx-ld: section .bootpg [fffff000 -> fffff23b] overlaps section .bss [fffee900 -> fffff8ab]
For many boards, the .bss section is big enough that it wraps around at the end of the address space (0xFFFFFFFF), so the problem will not be visible unless you use a 64 bit tool chain for development. On some boards however, changes to the code size (due to different optimizations) we bail out with section overlaps like above.
The fix is to add the NOLOAD attribute to the .bss and .sbss sections, telling the linker that .bss does not consume any space in the image.
Signed-off-by: Wolfgang Denk wd@denx.de
Applied, after re-rworking it for the boards changed, renamed or added meanwhile.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Saturday 12 January 2008, Wolfgang Denk wrote:
In message 1197026214-31034-1-git-send-email-wd@denx.de you wrote:
With recent toolchain versions, some boards would not build because or errors like this one (here for ocotea board when building with ELDK 4.2): ppc_4xx-ld: section .bootpg [fffff000 -> fffff23b] overlaps section .bss [fffee900 -> fffff8ab]
For many boards, the .bss section is big enough that it wraps around at the end of the address space (0xFFFFFFFF), so the problem will not be visible unless you use a 64 bit tool chain for development. On some boards however, changes to the code size (due to different optimizations) we bail out with section overlaps like above.
The fix is to add the NOLOAD attribute to the .bss and .sbss sections, telling the linker that .bss does not consume any space in the image.
Signed-off-by: Wolfgang Denk wd@denx.de
Applied, after re-rworking it for the boards changed, renamed or added meanwhile.
Thanks. This fixes overlapping problems with bss as seen on Ocotea with ELDK 4.2. But unfortunately I still have other overlapping problems for example on Katmai with ELDK 4.2:
[stefan@ubuntu u-boot (master)]$ ./MAKEALL katmai Configuring for katmai board... 44x_spd_ddr2.c: In function 'initdram': 44x_spd_ddr2.c:392: warning: 'selected_cas' may be used uninitialized in this function ppc_4xx-ld: section .bootpg [fffff000 -> fffff377] overlaps section .data.rel.local [ffffeba8 -> fffff3f7] ppc_4xx-ld: u-boot: section .bootpg lma 0xfffff000 overlaps previous sections ppc_4xx-ld: u-boot: section .data.rel.ro lma 0xfffff3f8 overlaps previous sections ppc_4xx-ld: u-boot: section .u_boot_cmd lma 0xfffff408 overlaps previous sections make: *** [u-boot] Error 1
These error are not seen with ELDK 4.1 by the way. Any ideas what might be causing this and/or how to solve it?
Thanks.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Dear Stefan,
in message 200801131459.19164.sr@denx.de you wrote:
Thanks. This fixes overlapping problems with bss as seen on Ocotea with ELDK 4.2. But unfortunately I still have other overlapping problems for example on Katmai with ELDK 4.2:
...
ppc_4xx-ld: u-boot: section .bootpg lma 0xfffff000 overlaps previous sections ppc_4xx-ld: u-boot: section .data.rel.ro lma 0xfffff3f8 overlaps previous sections ppc_4xx-ld: u-boot: section .u_boot_cmd lma 0xfffff408 overlaps previous sections make: *** [u-boot] Error 1
This problem comes from the fact that the code has become larger when using GCC 4.2.x; this is somewhat a surprise as we all expect more recent versions of the compiler to provide better optimization.
Please see this thread for discussion of the problem: http://gcc.gnu.org/ml/gcc/2008-01/msg00228.html
Basicly, it comes down to this explanation:
| GCC does not use the load and store multiple instructions because the source | file declares r29 a global variable: | | register volatile gd_t *gd asm ("r29"); | | The bug fix mentioned above inhibits GCC from using lmw/stmw if global | registers are present in the contiguous register sequence because GCC | incorrectly would overwrite the register. If the register variable declaration | is removed, GCC uses the lmw/stmw instructions. r29 is a bad choice for a | global register variable.
So far, it is not clear to me what a better choice for a global register variable could be (i. e. which register we can chose for our purpose without causing the same or other problems.
A possible approach to this problem is to avoid using a global register variable and use a plain global variable instead. The necessary code for this is already there (just commented out); when I implemented this initially, I decided to use a global register variable because it gave slightly smaller code.
Here is an overview of the effect (test build of current top of tree for the "katmai" (PPC440SPe) board):
ELDK Version Register-Var. Globale Var. text data bss dec text data bss dec 4.0 243292 13700 322340 579332 244160 13808 322340 580308 4.1 243292 13700 322340 579332 244160 13808 322340 580308 4.2 section ... overlaps previous 245496 13188 322340 581024
As you can see, the difference in code size is less than 1 KiB.
My suggestion is to change the code to use a plain global variable, however I need feedback if we can / want to do that as it effects *ALL* PowerPC boards.
Please comment.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Monday 04 February 2008, Wolfgang Denk wrote:
A possible approach to this problem is to avoid using a global register variable and use a plain global variable instead. The necessary code for this is already there (just commented out); when I implemented this initially, I decided to use a global register variable because it gave slightly smaller code.
Here is an overview of the effect (test build of current top of tree for the "katmai" (PPC440SPe) board):
ELDK Version Register-Var. Globale Var. text data bss dec text data bss dec 4.0 243292 13700 322340 579332 244160 13808 322340 580308 4.1 243292 13700 322340 579332 244160 13808 322340 580308 4.2 section ... overlaps previous 245496 13188 322340 581024
As you can see, the difference in code size is less than 1 KiB.
Nice.
My suggestion is to change the code to use a plain global variable, however I need feedback if we can / want to do that as it effects *ALL* PowerPC boards.
Acked-by for this change from me. I tested successfully on AMCC Katmai, which now fits again in the 256k with GCC 4.2.2.
Thanks.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
On Mon, Feb 04, 2008 at 12:32:36AM +0100, Wolfgang Denk wrote:
So far, it is not clear to me what a better choice for a global register variable could be (i. e. which register we can chose for our purpose without causing the same or other problems.
r2 is generally used for this purpose.
-Scott
In message 20080204165640.GC19264@ld0162-tx32.am.freescale.net you wrote:
On Mon, Feb 04, 2008 at 12:32:36AM +0100, Wolfgang Denk wrote:
So far, it is not clear to me what a better choice for a global register variable could be (i. e. which register we can chose for our purpose without causing the same or other problems.
r2 is generally used for this purpose.
Hm... R2 is documented to be the TOC pointer?
It seems we could use R15, but I hesitate a bit...
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message 20080204165640.GC19264@ld0162-tx32.am.freescale.net you wrote:
On Mon, Feb 04, 2008 at 12:32:36AM +0100, Wolfgang Denk wrote:
So far, it is not clear to me what a better choice for a global register variable could be (i. e. which register we can chose for our purpose without causing the same or other problems.
r2 is generally used for this purpose.
Hm... R2 is documented to be the TOC pointer?
The ABI document says, "Register r2 is reserved for system use and should not be changed by application code."
Linux uses it for the "current" pointer.
-Scott
In message 47A764BC.3000303@freescale.com you wrote:
Hm... R2 is documented to be the TOC pointer?
The ABI document says, "Register r2 is reserved for system use and should not be changed by application code."
OK, tried this, and seems to work. Well, let's throw it out and see what else it breaks ;-)
Patch posted - my own tests look good, so I will apply it ;-)
Best regards,
Wolfgang Denk
-----Original Message----- From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users-bounces@lists.sourceforge.net] On Behalf Of Wolfgang Denk Sent: den 14 februari 2008 23:19 To: Scott Wood Cc: u-boot-users@lists.sourceforge.net; Stefan Roese Subject: Re: [U-Boot-Users] [PPC] PLEASE READ - was: [PATCH] Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections
In message 47A764BC.3000303@freescale.com you wrote:
Hm... R2 is documented to be the TOC pointer?
The ABI document says, "Register r2 is reserved for system use and should not be changed by application code."
OK, tried this, and seems to work. Well, let's throw it out and see what else it breaks ;-)
Patch posted - my own tests look good, so I will apply it ;-)
Works here too, limited testing though
Jocke
On Mon, 2008-02-04 at 20:14 +0100, Wolfgang Denk wrote:
In message 20080204165640.GC19264@ld0162-tx32.am.freescale.net you wrote:
On Mon, Feb 04, 2008 at 12:32:36AM +0100, Wolfgang Denk wrote:
So far, it is not clear to me what a better choice for a global register variable could be (i. e. which register we can chose for our purpose without causing the same or other problems.
r2 is generally used for this purpose.
Hm... R2 is documented to be the TOC pointer?
It seems we could use R15, but I hesitate a bit...
I think the register approach is needed if we ever want to make u-boot fully relocateable.
There are a few global data accesses that needs to be fixed before that can happen though. There should not be any global data accesses before relocate_code has done its thing. One of the first things that happens in board_init_f is: for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) { if ((*init_fnc_ptr) () != 0) { hang (); } } init_sequence is a global variable.
Is this table really needed? Why not move it inside board_init_f and save some bytes?
The next is access is env_get_char, this probably needs to move into GD.
I figured global data accesses wasn't allowed(other than GD) at all before relocate_code()?
Jocke
In message 1202291955.25864.43.camel@gentoo-jocke.transmode.se you wrote:
I think the register approach is needed if we ever want to make u-boot fully relocateable.
Good point.
There are a few global data accesses that needs to be fixed before that can happen though. There should not be any global data accesses before relocate_code has done its thing. One of the first things that happens in board_init_f is: for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) { if ((*init_fnc_ptr) () != 0) { hang (); } } init_sequence is a global variable.
Is this table really needed? Why not move it inside board_init_f and save some bytes?
The original idea of the table was that a user could provide (in his board config file) a private version to allow for easy, #ifdef free board specific initialization sequences.
Unfortunately I never found the time or resources to complete this.
The next is access is env_get_char, this probably needs to move into GD.
I figured global data accesses wasn't allowed(other than GD) at all before relocate_code()?
They are not exactly forbidden, you just have to know exactly what you can expect - i. e., usually they just don't make much sense ;-)
Best regards,
Wolfgang Denk
-----Original Message----- From: wd@denx.de [mailto:wd@denx.de] Sent: den 6 februari 2008 23:11 To: joakim.tjernlund@transmode.se Cc: Scott Wood; u-boot-users@lists.sourceforge.net; Stefan Roese Subject: Re: [U-Boot-Users] [PPC] PLEASE READ - was: [PATCH] Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections
In message 1202291955.25864.43.camel@gentoo-jocke.transmode.se you wrote:
I think the register approach is needed if we ever want to make u-boot fully relocateable.
Good point.
There are a few global data accesses that needs to be fixed before that can happen though. There should not be any global data accesses before relocate_code has done its thing. One of the first things that happens in board_init_f is: for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) { if ((*init_fnc_ptr) () != 0) { hang (); } } init_sequence is a global variable.
Is this table really needed? Why not move it inside board_init_f and save some bytes?
The original idea of the table was that a user could provide (in his board config file) a private version to allow for easy, #ifdef free board specific initialization sequences.
Unfortunately I never found the time or resources to complete this.
I see, there are a lot of #ifdef in there that can be made more generic to cut down on the #ifdef's to a minimum. I read between the lines that you would not object too much if the table was removed?
The next is access is env_get_char, this probably needs to move into GD.
I figured global data accesses wasn't allowed(other than GD) at all before relocate_code()?
They are not exactly forbidden, you just have to know exactly what you can expect - i. e., usually they just don't make much sense ;-)
Yeah, sadly I just noticed that constant strings are referenced via the GOT so you can't print those for PPC if you want to make it relocateable.
Any idea how to avoid GOT references for constant strings?
Jocke
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
A possible approach to this problem is to avoid using a global register variable and use a plain global variable instead.
Sounds like a good idea to me. If the code works, then this would simplify things a great deal. The code that reads and writes the gd_t isn't time-critical anyway.
In message 47A74E10.5000106@freescale.com you wrote:
A possible approach to this problem is to avoid using a global register variable and use a plain global variable instead.
Sounds like a good idea to me. If the code works, then this would simplify things a great deal. The code that reads and writes the gd_t isn't time-critical anyway.
Except for the declaration of the variable itself, *nothing* changes. What do you mean would become simpler?
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
Except for the declaration of the variable itself, *nothing* changes. What do you mean would become simpler?
A normal global variable is simpler than one that's tied to a specific register, wouldn't you say? I wasn't trying to be that insightful.
In message 47A76677.6080308@freescale.com you wrote:
Except for the declaration of the variable itself, *nothing* changes. What do you mean would become simpler?
A normal global variable is simpler than one that's tied to a specific register, wouldn't you say? I wasn't trying to be that insightful.
No, I wouldn't say that. To me a pointer that can live all the time in a register is simpler than one that lives somewhere in a memory location and has to be loaded for use - you can see this from the code size as well.
Also, it's pretty convenient for debugging, for example when you need to figure out where U-Boot was relocated to in RAM - just add the offset in struct global_data and you have the relocation offset, for example.
Best regards,
Wolfgang Denk
participants (9)
-
brino -
Clemens Koller -
Joakim Tjernlund -
Joakim Tjernlund
-
Josh Boyer -
Scott Wood -
Stefan Roese -
Timur Tabi -
Wolfgang Denk