On Fri, 2013-09-13 at 15:23 +0530, Prabhakar Kushwaha wrote: > On 09/12/2013 11:28 PM, Scott Wood wrote: > > On Mon, 2013-09-09 at 16:43 +0530, Prabhakar Kushwaha wrote: > >> Hi, > >> > >> SPL framework is used to support multi-stage booting. Where first > >> level boot loader is created via SPL having relocate_code() function. > >> I am working on a Freescale's SoC which has less internal SRAM. > >> I don't want to use relocate_code() as to support this function, I need > >> to reduce SPL bin to SRAM/2 size. > >> > >> is there way to avoid relocate_code function ? > >> > >> I tried with below sequence, but it is not working for me :( > >> > >> .globl relocate_code > >> relocate_code: > >> mr r1,r3 /* Set new stack pointer */ > >> mr r9,r4 /* Save copy of Init Data pointer */ > >> mr r10,r5 /* Save copy of Destination Address */ > >> > >> GET_GOT > >> #ifndef CONFIG_SPL_BUILD > >> > >> -- > >> -- > >> #endif > >> .globl in_ram > >> in_ram: > > Well, you certainly don't want to disable it for all SPLs... > > it should be disabled for those SPL which relocate itself in SRAM, for > other no
Hmm? Any SPL that does relocate itself would need this. > >> The reason is bss "variables" which are mapped to 0x0000_0000 onwards > >> because "bss"section are mapped after 0xfffffffc in lds. They are not > >> available during SPL execution. is there way to relocate bss section in > >> the execution range of SPL? > > Are you talking about a scenario in which the SPL is loaded into SRAM > > rather than (e.g.) the NAND buffer? In that case, why is U-Boot not > > linked at the actual SRAM address? No copy should be needed in that > > case, and the BSS will not be at zero. > > I am linking SPL with the address of SRAM as I want resetvec at > 0xfffffffc but still I am finding bss at 0x0 What address do we start at when PBI loads something into SRAM? -Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
