On 2017-05-18 16:59, Lothar Waßmann wrote:
Manfred Schlaegl manfred.schlaegl@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.
Thanks a lot for your help and time!
Best regards Manfred