leandrof/u-boot
1
0
Fork 1
Code Issues Pull Requests Packages Projects Releases Wiki Activity

x86: Use the existing stack when chain-loading

Browse Source 
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>
This commit is contained in:
Simon Glass 2020-04-26 09:13:00 -06:00 committed by Bin Meng
parent cfe7a1068b
commit 86ee14f58b
1 changed files with 14 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
arch/x86/cpu/start_from_spl.S
View File

@ -14,18 +14,30 @@
.globl _start .globl _start
.type _start, @function .type _start, @function
_start: _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 movl $(CONFIG_SYS_CAR_ADDR + CONFIG_SYS_CAR_SIZE - 4), %eax
#ifdef CONFIG_DCACHE_RAM_MRC_VAR_SIZE #ifdef CONFIG_DCACHE_RAM_MRC_VAR_SIZE
subl $CONFIG_DCACHE_RAM_MRC_VAR_SIZE, %eax subl $CONFIG_DCACHE_RAM_MRC_VAR_SIZE, %eax
#endif #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 * already set up. This has the happy side-effect of putting gd in a
* new place separate from SPL, so the memset() in * new place separate from SPL, so the memset() in
* board_init_f_init_reserve() does not cause any problems (otherwise * board_init_f_init_reserve() does not cause any problems (otherwise
* it would zero out the gd and crash) * 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 call board_init_f_alloc_reserve
mov %eax, %esp mov %eax, %esp