[U-Boot] [PATCH] ARM: fixed relocation using proper alignment

[Manfred Schlaegl]

On 2017-05-18 17:37, Jagan Teki wrote:
> On Thu, May 18, 2017 at 9:04 PM, Manfred Schlaegl
> <manfred.schlaegl at ginzinger.com> wrote:
>> On 2017-05-18 16:59, Lothar Waßmann wrote:
>>> Manfred Schlaegl <manfred.schlaegl at 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