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.brod...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
