* [U-Boot] powerpc SPL framework: Avoiding relocate_code
@ 2013-09-09 11:13 Prabhakar Kushwaha
2013-09-12 17:58 ` Scott Wood
0 siblings, 1 reply; 5+ messages in thread
From: Prabhakar Kushwaha @ 2013-09-09 11:13 UTC (permalink / raw)
To: u-boot
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:
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?
Please advice.
Regards,
Prabhakar
^ permalink raw reply [flat|nested] 5+ messages in thread* [U-Boot] powerpc SPL framework: Avoiding relocate_code
2013-09-09 11:13 [U-Boot] powerpc SPL framework: Avoiding relocate_code Prabhakar Kushwaha
@ 2013-09-12 17:58 ` Scott Wood
2013-09-13 9:53 ` Prabhakar Kushwaha
0 siblings, 1 reply; 5+ messages in thread
From: Scott Wood @ 2013-09-12 17:58 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] powerpc SPL framework: Avoiding relocate_code
2013-09-12 17:58 ` Scott Wood
@ 2013-09-13 9:53 ` Prabhakar Kushwaha
2013-09-16 20:46 ` Scott Wood
0 siblings, 1 reply; 5+ messages in thread
From: Prabhakar Kushwaha @ 2013-09-13 9:53 UTC (permalink / raw)
To: u-boot
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
>> 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
in u-boot-spl.lds we have :-
#ifdef CONFIG_SYS_MPC85XX_NO_RESETVEC
.bootpg ADDR(.text) - 0x1000 :
{
KEEP(*(.bootpg))
} :text = 0xffff
#else
.resetvec ADDR(.text) + RESET_VECTOR_OFFSET : {
KEEP(*(.resetvec))
} = 0xffff
#endif
/*
* Make sure that the bss segment isn't linked at 0x0, otherwise its
* address won't be updated during relocation fixups.
*/
. |= 0x10;
. = ALIGN(4);
__bss_start = .;
.bss : {
*(.sbss*)
*(.bss*)
}
. = ALIGN(4);
__bss_end = .;
from above lds, we put resetvec at 0xfffffffc And place BSS just after
it. Hence at 0x0.
Ideally __bss_start should not be put after 0xfffffffc as it is making
relocation a requirement.
Regards,
Prabhakar
^ permalink raw reply [flat|nested] 5+ messages in thread* [U-Boot] powerpc SPL framework: Avoiding relocate_code
2013-09-13 9:53 ` Prabhakar Kushwaha
@ 2013-09-16 20:46 ` Scott Wood
0 siblings, 0 replies; 5+ messages in thread
From: Scott Wood @ 2013-09-16 20:46 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] powerpc SPL framework: Avoiding relocate_code
@ 2013-09-09 11:10 Prabhakar Kushwaha
0 siblings, 0 replies; 5+ messages in thread
From: Prabhakar Kushwaha @ 2013-09-09 11:10 UTC (permalink / raw)
To: u-boot
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:
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?
Please advice.
Regards,
Prabhakar
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-09-16 20:46 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-09 11:13 [U-Boot] powerpc SPL framework: Avoiding relocate_code Prabhakar Kushwaha
2013-09-12 17:58 ` Scott Wood
2013-09-13 9:53 ` Prabhakar Kushwaha
2013-09-16 20:46 ` Scott Wood
-- strict thread matches above, loose matches on Subject: below --
2013-09-09 11:10 Prabhakar Kushwaha
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox