* [U-Boot] [PATCH] arm: Correct comments in crt0.S for the recent SPL improvements
@ 2015-08-01 14:55 Simon Glass
2015-09-12 7:01 ` Albert ARIBAUD
0 siblings, 1 reply; 2+ messages in thread
From: Simon Glass @ 2015-08-01 14:55 UTC (permalink / raw)
To: u-boot
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.
*
* 2. 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)
- *
* 3. 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.
*
- * 4. 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.
*
* 5. 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().
+ *
+ * 6. 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.
+ *
+ * 7. Branch to board_init_r().
*
- * 6. 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.
*
* 2. 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)
- *
* 3. 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.
*
- * 4. 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.
*
* 5. 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.
*
- * 6. Branch to board_init_r().
+ * 6. 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.
+ *
+ * 7. 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
^ permalink raw reply related [flat|nested] 2+ messages in thread* [U-Boot] [PATCH] arm: Correct comments in crt0.S for the recent SPL improvements
2015-08-01 14:55 [U-Boot] [PATCH] arm: Correct comments in crt0.S for the recent SPL improvements Simon Glass
@ 2015-09-12 7:01 ` Albert ARIBAUD
0 siblings, 0 replies; 2+ messages in thread
From: Albert ARIBAUD @ 2015-09-12 7:01 UTC (permalink / raw)
To: u-boot
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.
> *
> * 2. 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)
> - *
> * 3. 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.
> *
> - * 4. 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.
> *
> * 5. 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().
> + *
> + * 6. 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.
> + *
> + * 7. Branch to board_init_r().
> *
> - * 6. 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.
> *
> * 2. 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)
> - *
> * 3. 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.
> *
> - * 4. 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.
> *
> * 5. 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.
> *
> - * 6. Branch to board_init_r().
> + * 6. 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.
> + *
> + * 7. 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,
--
Albert.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2015-09-12 7:01 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-08-01 14:55 [U-Boot] [PATCH] arm: Correct comments in crt0.S for the recent SPL improvements Simon Glass
2015-09-12 7:01 ` Albert ARIBAUD
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox