Albert, > -----Original Message----- > From: Albert ARIBAUD [mailto:albert.arib...@free.fr] > Sent: Tuesday, November 02, 2010 1:11 PM > To: V, Aneesh > Cc: dar...@theia.denx.de; h...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot