[PATCH v3 7/7] x86: Use the existing stack when chain-loading

Simon Glass sjg at chromium.org
Sun Mar 8 00:22:20 CET 2020

With chromebook_coral we normally run TPL->SPL->U-Boot. This is the
'bare metal' case.

When running from coreboot we put u-boot.bin in the RW_LEGACY portion
of the image, e.g. with:

   cbfstool image-coral.serial.bin add-flat-binary -r RW_LEGACY \
	-f /tmp/b/chromebook_coral/u-boot.bin -n altfw/u-boot \
	-c lzma -l 0x1110000 -e 0x1110000

In this case U-Boot is run from coreboot (actually Depthcharge, its
payload) so we cannot access CAR. Use the existing stack instead.

Signed-off-by: Simon Glass <sjg at chromium.org>

Changes in v3: None
Changes in v2: None

 arch/x86/cpu/start_from_spl.S | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/x86/cpu/start_from_spl.S b/arch/x86/cpu/start_from_spl.S
index 22cab2dd6c..75c328fd7a 100644
--- a/arch/x86/cpu/start_from_spl.S
+++ b/arch/x86/cpu/start_from_spl.S
@@ -14,18 +14,30 @@
 .globl _start
 .type _start, @function
-	/* Set up memory using the existing stack */
+	/*
+	 * If running from coreboot, CAR is no-longer available. Use the
+	 * existing stack, which is large enough.
+	 */
+	call	x86_detect_coreboot
+	cmp	$0, %eax
+	jne	use_existing_stack
+	jmp	2f
-	 * We don't subject CONFIG_DCACHE_RAM_MRC_VAR_SIZE since memory is
+	 * We don't subtract CONFIG_DCACHE_RAM_MRC_VAR_SIZE since memory is
 	 * already set up. This has the happy side-effect of putting gd in a
 	 * new place separate from SPL, so the memset() in
 	 * board_init_f_init_reserve() does not cause any problems (otherwise
 	 * it would zero out the gd and crash)
+	/* Set up memory using the existing stack */
+	mov	%esp, %eax
 	call	board_init_f_alloc_reserve
 	mov	%eax, %esp

More information about the U-Boot mailing list