x86: Use the existing stack when chain-loading
authorSimon Glass <sjg@chromium.org>
Sun, 26 Apr 2020 15:13:00 +0000 (09:13 -0600)
committerBin Meng <bmeng.cn@gmail.com>
Thu, 30 Apr 2020 09:48:17 +0000 (17:48 +0800)
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@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
arch/x86/cpu/start_from_spl.S

index 22cab2d..905c825 100644 (file)
 .globl _start
 .type _start, @function
 _start:
-       /* 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    locate_coreboot_table
+       cmp     $0, %eax
+       jge     use_existing_stack
+
        movl    $(CONFIG_SYS_CAR_ADDR + CONFIG_SYS_CAR_SIZE - 4), %eax
 #ifdef CONFIG_DCACHE_RAM_MRC_VAR_SIZE
        subl    $CONFIG_DCACHE_RAM_MRC_VAR_SIZE, %eax
 #endif
+       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 */
+use_existing_stack:
+       mov     %esp, %eax
+2:
        call    board_init_f_alloc_reserve
        mov     %eax, %esp