Albert,
-----Original Message----- From: Albert ARIBAUD [mailto:albert.aribaud@free.fr] Sent: Tuesday, November 02, 2010 1:11 PM To: V, Aneesh Cc: Darius@theia.denx.de; hs@denx.de; u-boot@lists.denx.de; Augulis Subject: Re: arm: wrong Relocation and not cleared BSS
Le 02/11/2010 08:18, V, Aneesh a écrit :
Thanks. This helps. I did the .lds change and it seems to be
booting
now.
Good!
However, I can't still explain my earlier observation because even
in
the absence of this fix .rel.dyn had some content and the offsets should have been different if I were to believe objdump.
Do you have any clue?
There were two issues:
First, "older" linkers always emitted input relocation sections with the name ".rel.dyn" whereas "newer" linkers emitted them with names of the form ".rel*". As our linker files only took ".rel.dyn" to form the output section, using newer linkers would produce empty .rel.dyn sections.
My .rel.dyn was not empty even before taking your fix.
This is what puzzled me. When I dumped the ELF headers with 'objdump -h' .rel.dyn seemed to have some content: Please see the diff of objdump's output before and after applying your patch.
Please note that .rel.dyn was there even without the patch having the same size but at a different offset.
So, this is what it looks like to me: Even when our rule in .lds was not correct the linker generated .rel.dyn section by default putting together the 'rel*' sections that were not covered by any rules. But since it didn't use our rule for this, the labels associated with our rule indicated zero size.
**************************************************************** @@ -9,7 +9,7 @@ Idx Name Size VMA LMA File off Algn CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .interp 00000011 80e9e6d0 80e9e6d0 000266d0 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA - 3 .dynamic 00000080 80ea343c 80ea343c 0002b43c 2**2 + 3 .dynamic 00000080 80e9f7ec 80e9f7ec 000277ec 2**2 CONTENTS, ALLOC, LOAD, DATA 4 .dynsym 00000100 80ea34c8 80ea34c8 0002b4c8 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA @@ -17,12 +17,12 @@ Idx Name Size VMA LMA File off Algn CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .hash 00000054 80e9e7a4 80e9e7a4 000267a4 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA - 7 .rel.dyn 00003c50 80e9e7f8 80e9e7f8 000267f8 2**2 - CONTENTS, ALLOC, LOAD, READONLY, DATA - 8 .data 00000ff4 80ea2448 80ea2448 0002a448 2**2 + 7 .data 00000ff4 80e9e7f8 80e9e7f8 000267f8 2**2 CONTENTS, ALLOC, LOAD, DATA - 9 .got.plt 0000000c 80ea34bc 80ea34bc 0002b4bc 2**2 + 8 .got.plt 0000000c 80e9f86c 80e9f86c 0002786c 2**2 CONTENTS, ALLOC, LOAD, DATA + 9 .rel.dyn 00003c50 80e9f878 80e9f878 00027878 2**2 + CONTENTS, ALLOC, LOAD, READONLY, DATA 10 .u_boot_cmd 00000540 80ea35c8 80ea35c8 0002b5c8 2**2 CONTENTS, ALLOC, LOAD, DATA 11 .bss 00031210 80ea3b08 80ea3b08 0002bb08 2**3 ****************************************************************
Second, a fix to the first issue was RFCed to the list which worked on several boards but tx25 would not boot completely. The root cause of this second issue is that CONFIG_SYS_NAND_U_BOOT_SIZE in the board config file hard-codes the size of the u-boot binary that will be read from NAND and put in RAM. When/if u-boot grows in size, this constant must be adjusted, and it was not.
What hit you was the first issue for sure, and this explains why _rel_dyn_start_ofs and _rel_dyn_end_ofs are identical. What *could* have hit you was the second issue *if* your board boots from NAND *and* if u-boot grew beyond your CONFIG_SYS_NAND_U_BOOT_SIZE.
We did not face the second issue because we are loading the entire u-boot.bin using a separate preloader.
BTW, Wolfgang, couldn't this 'constant' be generated once objcopy has produced u-boot.bin? A script could 'du' its size, round it up as required, and generate a .h with the result so that the SPL would always compile with a correct value.
Best regards, Aneesh
Amicalement,
Albert.
Best regards, Aneesh