[U-Boot] arm: wrong Relocation and not cleared BSS

[V, Aneesh]

Albert,

> -----Original Message-----
> From: Albert ARIBAUD [mailto:albert.aribaud at free.fr]
> Sent: Tuesday, November 02, 2010 1:11 PM
> To: V, Aneesh
> Cc: Darius at theia.denx.de; hs at denx.de; u-boot at 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