diff options
author | Simon Glass <sjg@chromium.org> | 2015-08-01 08:55:46 -0600 |
---|---|---|
committer | Albert ARIBAUD <albert.u.boot@aribaud.net> | 2015-09-12 09:00:35 +0200 |
commit | ed64190f67a28e9830371d424998b8aa924be9f3 (patch) | |
tree | 3a0c74a999ed3a9ed62d0bf1ab548c1c27c3d7c6 /arch/arm | |
parent | e8b81eef4499c32b11d5f120171f39f67db0db59 (diff) | |
download | u-boot-imx-ed64190f67a28e9830371d424998b8aa924be9f3.zip u-boot-imx-ed64190f67a28e9830371d424998b8aa924be9f3.tar.gz u-boot-imx-ed64190f67a28e9830371d424998b8aa924be9f3.tar.bz2 |
arm: Correct comments in crt0.S for the recent SPL improvements
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>
Diffstat (limited to 'arch/arm')
-rw-r--r-- | arch/arm/lib/crt0.S | 26 | ||||
-rw-r--r-- | 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 */ |