On 2017-05-18 17:37, Jagan Teki wrote: > 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! >
For compatibility reasons we use a custom environment implementation. In this implementation we had an write access to a static variable in env_init. env_init is called before relocation. As Lothar stated out .bss overlaps .rel at this stage, so we corrupted .rel. Hope that helped! Best regards, Manfred _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
