* [U-Boot] [PATCH v3] armv8: spl: Call board_init_r from crt0_64 in SPL
@ 2016-07-18 16:01 Jeremy Hunt
2016-07-23 0:13 ` [U-Boot] [U-Boot, " Tom Rini
0 siblings, 1 reply; 2+ messages in thread
From: Jeremy Hunt @ 2016-07-18 16:01 UTC (permalink / raw)
To: u-boot
As part of the startup process for boards using the SPL, the
meaning of board_init_f changed such that it should return normally
rather than calling board_init_r directly. (see
db910353a126d84fe8dff7a694ea792f50fcfb6a )
This was fixed in 32-bit arm, but broke when SPL was added to
64 bit arm. This fixes crt0_64 so that it calls board_init_r
during the SPL and removes the direct call from board_init_f
from the arm SPL example.
Signed-off-by: Jeremy Hunt <Jeremy.Hunt@DEShawResearch.com>
Acked-by: Simon Glass <sjg@chromium.org>
---
Changes in v3:
- Commit message typo
Changes in v2:
- Add comment pointing to Board Initialization Flow
- Remove old global data pointer setup code
arch/arm/lib/crt0_64.S | 3 +--
arch/arm/lib/spl.c | 24 +++++++++++-------------
2 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S
index cad22c7..91b19e0 100644
--- a/arch/arm/lib/crt0_64.S
+++ b/arch/arm/lib/crt0_64.S
@@ -108,6 +108,7 @@ relocation_return:
* Set up final (full) environment
*/
bl c_runtime_cpu_setup /* still call old routine */
+#endif /* !CONFIG_SPL_BUILD */
/* TODO: For SPL, call spl_relocate_stack_gd() to alloc stack relocation */
@@ -130,6 +131,4 @@ clear_loop:
/* NOTREACHED - board_init_r() does not return */
-#endif /* !CONFIG_SPL_BUILD */
-
ENDPROC(_main)
diff --git a/arch/arm/lib/spl.c b/arch/arm/lib/spl.c
index e428868..bc33538 100644
--- a/arch/arm/lib/spl.c
+++ b/arch/arm/lib/spl.c
@@ -25,22 +25,20 @@ gd_t gdata __attribute__ ((section(".data")));
#endif
/*
- * In the context of SPL, board_init_f must ensure that any clocks/etc for
- * DDR are enabled, ensure that the stack pointer is valid, clear the BSS
- * and call board_init_r. We provide this version by default but mark it
- * as __weak to allow for platforms to do this in their own way if needed.
+ * In the context of SPL, board_init_f() prepares the hardware for execution
+ * from system RAM (DRAM, DDR...). As system RAM may not be available yet,
+ * board_init_f() must use the current GD to store any data which must be
+ * passed on to later stages. These data include the relocation destination,
+ * the future stack, and the future GD location. BSS is cleared after this
+ * function (and therefore must be accessible).
+ *
+ * We provide this version by default but mark it as __weak to allow for
+ * platforms to do this in their own way if needed. Please see the top
+ * level U-Boot README "Board Initialization Flow" section for info on what
+ * to put in this function.
*/
void __weak board_init_f(ulong dummy)
{
- /* Clear the BSS. */
- memset(__bss_start, 0, __bss_end - __bss_start);
-
-#ifndef CONFIG_SPL_DM
- /* TODO: Remove settings of the global data pointer here */
- gd = &gdata;
-#endif
-
- board_init_r(NULL, 0);
}
/*
--
2.4.4
^ permalink raw reply related [flat|nested] 2+ messages in thread
* [U-Boot] [U-Boot, v3] armv8: spl: Call board_init_r from crt0_64 in SPL
2016-07-18 16:01 [U-Boot] [PATCH v3] armv8: spl: Call board_init_r from crt0_64 in SPL Jeremy Hunt
@ 2016-07-23 0:13 ` Tom Rini
0 siblings, 0 replies; 2+ messages in thread
From: Tom Rini @ 2016-07-23 0:13 UTC (permalink / raw)
To: u-boot
On Mon, Jul 18, 2016 at 12:01:02PM -0400, Jeremy Hunt wrote:
> As part of the startup process for boards using the SPL, the
> meaning of board_init_f changed such that it should return normally
> rather than calling board_init_r directly. (see
> db910353a126d84fe8dff7a694ea792f50fcfb6a )
> This was fixed in 32-bit arm, but broke when SPL was added to
> 64 bit arm. This fixes crt0_64 so that it calls board_init_r
> during the SPL and removes the direct call from board_init_f
> from the arm SPL example.
>
> Signed-off-by: Jeremy Hunt <Jeremy.Hunt@DEShawResearch.com>
>
> Acked-by: Simon Glass <sjg@chromium.org>
Applied to u-boot/master, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160722/05c299ec/attachment.sig>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2016-07-23 0:13 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-07-18 16:01 [U-Boot] [PATCH v3] armv8: spl: Call board_init_r from crt0_64 in SPL Jeremy Hunt
2016-07-23 0:13 ` [U-Boot] [U-Boot, " Tom Rini
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.