[U-Boot] powerpc SPL framework: Avoiding relocate_code
Scott Wood
scottwood at freescale.com
Thu Sep 12 19:58:57 CEST 2013
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
More information about the U-Boot
mailing list