[U-Boot] [PATCH] board_r - fixup functions table after relocation

[Alexey Brodkin]

On Wed, 2014-01-15 at 22:43 +0100, Albert ARIBAUD wrote:
> Hi Alexey,
> 
> On Wed, 15 Jan 2014 15:19:56 +0400, Alexey Brodkin
> <Alexey.Brodkin at synopsys.com> wrote:
> 
> > "init_sequence_r" is just an array that consists of compile-time
> > adresses of init functions. Since this is basically an array of integers
> > (pointers to "void" to be more precise) it won't be modified during
> > relocation - it will be just copied to new location as it is.
> 
> IIRC, in ARM we switched from GOT to ELF relocation precisely so that
> data would be relocated as well as code, and I think it actually is,
> otherwise we'd have a lot of complains. Therefore I fail to understand
> the statements above. Can someone tell me what I'm getting wrong?

Unfortunately I don't have any supported in U-Boot ARM board handy and
run U-boot on another architecture at all (Synopsys DesignWare ARC) so
I'm not sure if on ARM functions from "init_sequence_r" list are
executed from "RAM" (i.e. from location where they were relocated).

I use GOT relocation and see following outputs.

1. Without manual "init_sequence_r" modification:
================
U-Boot 2014.01-rc1-00207-ga065b75-dirty (Jan 16 2014 - 21:30:12)
initcall: 81000890
U-Boot code: 81000000 -> 8103FE00  BSS: -> 81044278
initcall: 810008f4
DRAM:  initcall: 81000a84
Monitor len: 00044278
Ram size: 10000000
Ram top: 90000000
initcall: 81000b24
initcall: 81000b48
initcall: 81000b5c
Reserving 272k for U-Boot at: 8ffbb000
initcall: 81000bd0
Reserving 2048k for malloc() at: 8fdbae00
initcall: 81000c24
Reserving 64 Bytes for Board Info at: 8fdbadc0
initcall: 81000c9c
initcall: 81000cb0
Reserving 132 Bytes for Global Data at: 8fdbad3c
initcall: 81000d18
initcall: 81000de8
initcall: 81000e78
initcall: 8100092c
256 MiB
initcall: 81000e5c
initcall: 81000e1c
New Stack Pointer is: 8fdbad20
initcall: 81000e94
initcall: 81000ed4
Relocation Offset is: 0efbb000
Relocating to 8ffbb000, new gd at 8fdbad3c, sp at 8fdbad20
initcall: 81000f60
initcall: 81001074
initcall: 81001088
initcall: 810010f4
initcall: 81001120
initcall: 810011b0
Now running in RAM - U-Boot at: 8ffbb000
initcall: 81000760
================

2. With manual "init_sequence_r" modification
================
U-Boot 2014.01-rc1-00207-ga065b75-dirty (Jan 16 2014 - 21:26:42)
initcall: 81000890
U-Boot code: 81000000 -> 8103FE00  BSS: -> 81044278
initcall: 810008f4
DRAM:  initcall: 81000a84
Monitor len: 00044278
Ram size: 10000000
Ram top: 90000000
initcall: 81000b24
initcall: 81000b48
initcall: 81000b5c
Reserving 272k for U-Boot at: 8ffbb000
initcall: 81000bd0
Reserving 2048k for malloc() at: 8fdbae00
initcall: 81000c24
Reserving 64 Bytes for Board Info at: 8fdbadc0
initcall: 81000c9c
initcall: 81000cb0
Reserving 132 Bytes for Global Data at: 8fdbad3c
initcall: 81000d18
initcall: 81000de8
initcall: 81000e78
initcall: 8100092c
256 MiB
initcall: 81000e5c
initcall: 81000e1c
New Stack Pointer is: 8fdbad20
initcall: 81000e94
initcall: 81000ed4
Relocation Offset is: 0efbb000
Relocating to 8ffbb000, new gd at 8fdbad3c, sp at 8fdbad20
initcall: 81000f60
initcall: 8ffbc074
initcall: 8ffbc088
initcall: 8ffbc0f4
initcall: 8ffbc120
initcall: 8ffbc1b0
Now running in RAM - U-Boot at: 8ffbb000
initcall: 8ffbb760
================

Note how in second case mapped initcalls executed.

If anybody may try to build U-Boot with global "DEBUG" defined and paste
his log in this thread it would be helpful.

Maybe it's just my faulty implementation of relocation but it might be
that nobody ever noticed this because I think only initcalls are
affected.

-Alexey