[U-Boot] powerpc SPL framework: Avoiding relocate_code

[Scott Wood <scottwood@freescale.com>]

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...

> 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.

If you are talking about a NAND buffer style boot (i.e. not a PBL-using
chip), then you must relocate, so the NAND buffer can be reused for I/O
(and in any case the SRAM is much larger than the NAND buffer on
Freescale PPC chips that I'm familiar with).

-Scott