[U-Boot] v2010-rc2: OMAP3 broken

[Albert ARIBAUD]

Le 29/11/2010 16:04, Heiko Schocher a écrit :
> Hello Albert,
>
> Albert ARIBAUD wrote:
>> I'll take a look this evening at builds with and without the SORT() from
>> an ELF relocation tables perspective.
>
> I debugged on the beagle board a little bit in this problem, and here
> what I found:
>
> Hier it goes wrong:
>
> arch/arm/cpu/armv7/start.S
>
> fixloop:
>          ldr     r0, [r2]                /* r0<- location to fix up, IN FLASH! */
>   104:   e5920000        ldr     r0, [r2]
>          add     r0, r0, r9              /* r0<- location to fix up in RAM */
>   108:   e0800009        add     r0, r0, r9
>
> and later here
>
> fixrel:
>          /* relative fix: increase location by offset */
>          ldr     r1, [r0]
>
> Here the version with sort:
>
> OMAP35xx>t;r
>      Core number       : 0
>      Core state        : debug mode (ARM)
>      Debug entry cause : Single Step
>      Current PC        : 0x80008104
>      Current CPSR      : 0x200001d3 (Supervisor)
> GPR00: 80008000 8ff1df84 80046d7c 8004d6ac
> GPR04: 8ff1df80 8ff1df84 8ffbcd80 8ff7e000
> GPR08: 4020ffa0 0ff76000 8004d6ac 00000000
> GPR12: 00000000 8ff1df80 8000aef0 80008104
> PC   : 80008104    CPSR: 200001d3
> OMAP35xx>t;r
>      Core number       : 0
>      Core state        : debug mode (ARM)
>      Debug entry cause : Single Step
>      Current PC        : 0x80008108
>      Current CPSR      : 0x200001d3 (Supervisor)
> GPR00: 00000000 8ff1df84 80046d7c 8004d6ac
>         ^^^^^^^^
>         Ups... not good
>
> GPR04: 8ff1df80 8ff1df84 8ffbcd80 8ff7e000
> GPR08: 4020ffa0 0ff76000 8004d6ac 00000000
> GPR12: 00000000 8ff1df80 8000aef0 80008108
> PC   : 80008108    CPSR: 200001d3
> OMAP35xx>t;r
>
>
> Here without sort:
>
> GPR00: 80008000 8ff1df84 80046d74 8004d6a4
> GPR04: 8ff1df80 8ff1df84 8ffbcd78 8ff7e000
> GPR08: 4020ffa0 0ff76000 8004d6a4 00000000
> GPR12: 00000000 8ff1df80 80010730 80008104
> PC   : 80008104    CPSR: 200001d3
> OMAP35xx>ti;r
>      Core number       : 0
>      Core state        : debug mode (ARM)
>      Debug entry cause : Single Step
>      Current PC        : 0x80008108
>      Current CPSR      : 0x200001d3 (Supervisor)
> GPR00: 80008020 8ff1df84 80046d74 8004d6a4
>         ^^^^^^^^
>         Yep, thats better
> GPR04: 8ff1df80 8ff1df84 8ffbcd78 8ff7e000
> GPR08: 4020ffa0 0ff76000 8004d6a4 00000000
> GPR12: 00000000 8ff1df80 80010730 80008108
> PC   : 80008108    CPSR: 200001d3
> OMAP35xx>ti;r
>      Core number       : 0
>      Core state        : debug mode (ARM)
>      Debug entry cause : Single Step
>      Current PC        : 0x8000810c
>      Current CPSR      : 0x200001d3 (Supervisor)
>
>
> System Map:
>
> with sort:
>
> 80046d7c B __bss_start
> 80046d7c R __rel_dyn_start
> 80046d7c b timestamp
> 80046d80 b lastinc
> 80046d84 B gpmc_cfg
>
> without sort:
>
> 80046d74 R __rel_dyn_start
> 80046d78 b htab
> 80046d84 B ___strtok
> 80046d88 B z_verbose
>
> timestamp comes after the "__rel_dyn_end" entry in this case!
>
> Further debugging pointed my that in:
>
> in arch/arm/cpu/armv7/omap-common/timer.c timer_init() sets
> timestamp to 0, before relocation is executed, which leads
> that the memory @80046d7c gets overwritten to 0, which
> results in crashing in the fixrel case ...
>
> So it seems to me the "sort" version intermix the "rel dyn"
> section entries with "normal" vars in bss ... Which raises
> the question:
>
> Why is the rel.dyn Section in the bss section?
>
The .rel.dyn section is not "in" or "out" of the BSS: they are 
overlapped, i.e. they should start at the same address.

As indicated in the documentation, BSS should never be used before 
relocation; it actually *cannot* be written into by boards which start 
from NOR, and is set to zero for all boards right after relocation.

Since BSS does not exist before relocation, and .rel.dyn does not exist 
after relocation, they can use the same location: overlaying them is the 
best approach in order to get the smallest binary in Flash *and* the 
smallest image in RAM.

We can add code to try and catch the most obvious corruption of the 
relocation tables due to BSS being accessed before relocation, but we 
can't be sure to catch them all. The real solution is to fix the BSS usage.

> bye,
> Heiko

Amicalement,
-- 
Albert.