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