Arthur Heymans has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/36914 )
Change subject: binaryPI: implement C bootblock ......................................................................
Patch Set 9:
(1 comment)
https://review.coreboot.org/c/coreboot/+/36914/8/src/drivers/amd/agesa/cache... File src/drivers/amd/agesa/cache_as_ram.S:
https://review.coreboot.org/c/coreboot/+/36914/8/src/drivers/amd/agesa/cache... PS8, Line 159: %esp
It can be found in src/vendorcode/amd/pi/<family>/binaryPI/gcccar.inc for each family: For example 00730F01: BSP_STACK_BASE_ADDR = 0x30000 /* Base address for primary cores stack */ BSP_STACK_SIZE = 0x10000 /* 64KB for BSP core */ CORE0_STACK_BASE_ADDR = 0x80000 /* Base address for primary cores stack */ CORE0_STACK_SIZE = 0x4000 /* 16KB for primary cores */ CORE1_STACK_BASE_ADDR = 0x40000 /* Base address for AP cores */ CORE1_STACK_SIZE = 0x1000 /* 4KB for each AP cores */
Procedure with stack alignment is exactly the same as for ROMCC_BOOTBLOCK: https://review.coreboot.org/c/coreboot/+/36914/8/src/drivers/amd/agesa/cache...
I'm a bit lost on the terminology, but I presume it's something like: BSP, (well BSP in LAPIC reg) CORE0: primary cores on different CPU nodes (different packages?) CORE1: all other AP's?
If that's the case only the AP stacks are not getting in the way of coreboot. BTW it's pretty clear in gcccar.inc why CAR is not coherent over AP's since MTRR's set up differ per core.
It might be worth mentioning here that %esp has one of the values you describe here?