[U-Boot] v2010-rc2: OMAP3 broken

[Heiko Schocher]

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?

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany