Manfred Schlaegl <manfred.schla...@ginzinger.com> wrote: > On 2017-05-17 06:13, Lokesh Vutla wrote: > > > > > > On Tuesday 16 May 2017 07:59 PM, Manfred Schlaegl wrote: > >> On 2017-05-11 08:53, Lokesh Vutla wrote: > >>> > >>> > >>> On Wednesday 10 May 2017 07:11 PM, Manfred Schlaegl wrote: > >>>> Using u-boot-2017.05 on i.MX6UL we ran into following problem: > >>>> Initially U-Boot could be started normally. > >>>> If we added one random command in configuration, the newly generated > >>>> image hung at startup (last output was DRAM: 256 MiB). > >>>> > >>>> We tracked this down to a data abort within relocation (relocated_code). > >>>> [...] > >> In a good case (rel_dyn_start aligned to 8 byte), u-boot is starting up > >> normally > >> rel_dyn_start is 0x8785FC28 > >> rel_dyn_end is 0x87857BD0 > >> A dump of this memory area shows no abnormality > >> > >> In a bad case (same source, but rel_dyn_start aligned to 4 byte), the data > >> abort happens > >> rel_dyn_start is 0x8785FC24 > >> rel_dyn_end is 0x87857BCC > >> So we have the same size of 32856 bytes but a memory dump showed exactly > >> one difference, which is > >> very interesting: > >> > >> At offset 0x610 (relative to rel_dyn_start) we have following difference > >> -00000610 30 3e 80 87 17 00 00 00 34 3e 80 87 00 00 00 00 > >> |0>......4>......| > >> +00000610 30 3e 80 87 17 00 00 00 00 00 00 00 17 00 00 00 > >> |0>..............| > > > > Looks like someone is corrupting the data(assuming). Is it all 0's just > > at this location or continuously after this? > > No. Above diff is the only difference of the good and bad case in memory > located between > rel_dyn_start and rel_dyn_end. > > To see if it might be a corruption I compared the the rel_dyn with the > created u-boot.img and > found the same difference > -00000610 30 3e 80 87 17 00 00 00 34 3e 80 87 17 00 00 00 > |0>......4>......| <--- generated image > +00000610 30 3e 80 87 17 00 00 00 00 00 00 00 17 00 00 00 > |0>..............| <--- memory dump > > So it must be some kind of corruption. > This can be caused by a static variable, that is written to prior to relocation. Since the .rel section overlays the .bss section, the write to a variable in the BSS will corrupt the relocation data.
Lothar Waßmann -- ___________________________________________________________ Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Geschäftsführer: Matthias Kaussen Handelsregistereintrag: Amtsgericht Aachen, HRB 4996 www.karo-electronics.de | i...@karo-electronics.de ___________________________________________________________ _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
