From: Prabhakar Kushwaha <prabhakar@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] powerpc SPL framework: Avoiding relocate_code
Date: Fri, 13 Sep 2013 15:23:39 +0530 [thread overview]
Message-ID: <5232E0A3.8090307@freescale.com> (raw)
In-Reply-To: <1379008737.2536.15.camel@snotra.buserror.net>
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
next prev parent reply other threads:[~2013-09-13 9:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2013-09-16 20:46 ` Scott Wood
-- strict thread matches above, loose matches on Subject: below --
2013-09-09 11:10 Prabhakar Kushwaha
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5232E0A3.8090307@freescale.com \
--to=prabhakar@freescale.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.