Kyösti Mälkki has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/34976 )
Change subject: cpu/intel/car: Make stack guards more useful on C_ENV_BOOTBLOCK ......................................................................
Patch Set 5:
(1 comment)
https://review.coreboot.org/c/coreboot/+/34976/5/src/cpu/intel/car/romstage.... File src/cpu/intel/car/romstage.c:
https://review.coreboot.org/c/coreboot/+/34976/5/src/cpu/intel/car/romstage.... PS5, Line 43: _car_stack_end
But why assume 0x2000? […]
_car_stack_end - 0x2000 was the location of the stack guards before this change (DCACHE_RAM_ROMSTAGE_STACK_SIZE). Along the years we fixed some native raminits to honour that stack allocation without smashing the guards. Makes sense to maintain that?
I believe commit message explains +256 rationale already. With C_ENV_BOOTBLOCK and no VBOOT, attempting to use more than DCACHE_BSP_STACK_SIZE is likely to crash in the middle of romstage as stack would extend outside CAR. If stack usage only gradually increased with code changes, we have a period of commits were we get the error in logs instead of a sudden death with a completely innocent looking change.