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

[Lothar Waßmann]

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.


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 | info at karo-electronics.de
___________________________________________________________