Hello Simon,
On Sat, 1 Aug 2015 08:55:46 -0600, Simon Glass sjg@chromium.org wrote:
The current comments need a bit of tweaking since we now support stack and global_data relocation in SPL. Also add a reference to the README.
For AArch64 this is not implemented, so leave a TODO for this.
Signed-off-by: Simon Glass sjg@chromium.org Reported-by: Tim Harvey tharvey@gateworks.com
arch/arm/lib/crt0.S | 26 ++++++++++++++++---------- arch/arm/lib/crt0_64.S | 30 ++++++++++++++++++++---------- 2 files changed, 36 insertions(+), 20 deletions(-)
diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S index afd4f10..4c3a94a 100644 --- a/arch/arm/lib/crt0.S +++ b/arch/arm/lib/crt0.S @@ -25,7 +25,8 @@
- the GD ('global data') structure, both located in some readily
- available RAM (SRAM, locked cache...). In this context, VARIABLE
- global data, initialized or not (BSS), are UNAVAILABLE; only
- CONSTANT initialized data are available.
- CONSTANT initialized data are available. GD should be zeroed
- before board_init_f() is called.
- Call board_init_f(). This function prepares the hardware for
- execution from system RAM (DRAM, DDR...) As system RAM may not
@@ -34,24 +35,29 @@
- data include the relocation destination, the future stack, and
- the future GD location.
- (the following applies only to non-SPL builds)
- Set up intermediate environment where the stack and GD are the
- ones allocated by board_init_f() in system RAM, but BSS and
- initialized non-const data are still not available.
- Call relocate_code(). This function relocates U-Boot from its
- current location into the relocation destination computed by
- board_init_f().
- 4a.For U-Boot proper (not SPL), call relocate_code(). This function
- relocates U-Boot from its current location into the relocation
- destination computed by board_init_f().
- 4b.For SPL, board_init_f() just returns (to crt0). There is no
- code relocation in SPL.
- Set up final environment for calling board_init_r(). This
- environment has BSS (initialized to 0), initialized non-const
- data (initialized to their intended value), and stack in system
- RAM. GD has retained values set by board_init_f(). Some CPUs
- have some work left to do at this point regarding memory, so
- call c_runtime_cpu_setup.
- RAM (for SPL moving the stack and GD into RAM is optional - see
- CONFIG_SPL_STACK_R). GD has retained values set by board_init_f().
- For U-Boot proper (not SPL), some CPUs have some work left to do
- at this point regarding memory, so call c_runtime_cpu_setup.
- Branch to board_init_r().
- Branch to board_init_r().
*/
- For more information see 'Board Initialisation Flow in README.
/* diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S index 98a906e..8b34e04 100644 --- a/arch/arm/lib/crt0_64.S +++ b/arch/arm/lib/crt0_64.S @@ -27,7 +27,8 @@
- the GD ('global data') structure, both located in some readily
- available RAM (SRAM, locked cache...). In this context, VARIABLE
- global data, initialized or not (BSS), are UNAVAILABLE; only
- CONSTANT initialized data are available.
- CONSTANT initialized data are available. GD should be zeroed
- before board_init_f() is called.
- Call board_init_f(). This function prepares the hardware for
- execution from system RAM (DRAM, DDR...) As system RAM may not
@@ -36,24 +37,31 @@
- data include the relocation destination, the future stack, and
- the future GD location.
- (the following applies only to non-SPL builds)
- Set up intermediate environment where the stack and GD are the
- ones allocated by board_init_f() in system RAM, but BSS and
- initialized non-const data are still not available.
- Call relocate_code(). This function relocates U-Boot from its
- current location into the relocation destination computed by
- board_init_f().
- 4a.For U-Boot proper (not SPL), call relocate_code(). This function
- relocates U-Boot from its current location into the relocation
- destination computed by board_init_f().
- 4b.For SPL, board_init_f() just returns (to crt0). There is no
- code relocation in SPL.
- Set up final environment for calling board_init_r(). This
- environment has BSS (initialized to 0), initialized non-const
- data (initialized to their intended value), and stack in system
- RAM. GD has retained values set by board_init_f(). Some CPUs
- have some work left to do at this point regarding memory, so
- call c_runtime_cpu_setup.
- RAM (for SPL moving the stack and GD into RAM is optional - see
- CONFIG_SPL_STACK_R). GD has retained values set by board_init_f().
- TODO: For SPL, implement stack relocation on AArch64.
- Branch to board_init_r().
- For U-Boot proper (not SPL), some CPUs have some work left to do
- at this point regarding memory, so call c_runtime_cpu_setup.
- Branch to board_init_r().
*/
- For more information see 'Board Initialisation Flow in README.
ENTRY(_main) @@ -106,6 +114,8 @@ relocation_return: */ bl c_runtime_cpu_setup /* still call old routine */
+/* TODO: For SPL, call spl_relocate_stack_gd() to alloc stack relocation */
/*
- Clear BSS section
*/
2.5.0.rc2.392.g76e840b
Applied to u-boot-arm/master, thanks!
Amicalement,