On Thu, May 18, 2017 at 9:04 PM, Manfred Schlaegl <manfred.schla...@ginzinger.com> wrote: > On 2017-05-18 16:59, Lothar Waßmann wrote: >> 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. >> > > Yes! That's it! > > Using a watchpoint I tracked the corruption down to an early write to a > static variable in our custom code. > > So finally: > The whole thing was a problem in a custom modification and was solved there. > It has no implication on u-boot itself.
Any pointers on which kind of custom modification, because I could see the similar issue with upstream u-boot. thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
