Re: [U-Boot] [PATCH] arm: Correct comments in crt0.S for the recent SPL improvements

[Albert ARIBAUD]

Hello Simon,

On Sat,  1 Aug 2015 08:55:46 -0600, Simon Glass  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 
> Reported-by: Tim Harvey 
> ---
> 
>  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 

[U-Boot] [PATCH] arm: Correct comments in crt0.S for the recent SPL improvements

[Simon Glass]

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 s...@chromium.org
Reported-by: Tim Harvey thar...@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