[U-Boot] powerpc SPL framework: Avoiding relocate_code

[Scott Wood]

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