Issue #514 has been reported by Patrick Georgi.
---------------------------------------- Feature #514: Determine SMM memory requirements on build time https://ticket.coreboot.org/issues/514
* Author: Patrick Georgi * Status: New * Priority: Normal * Target version: none * Start date: 2023-11-17 ---------------------------------------- When I tried to normalize the ramstage's heap size, and increase it on most platforms while doing so, I broke resume on a bunch of boards because SMM couldn't cache the ramstage properly anymore. This led to a [revert](https://review.coreboot.org/c/coreboot/+/78850) and so we're back to a few ground rules plus tons of exceptions for the heap size, all of which seem to be determined experimentally.
All necessary information is known at compile time, so we should be able to verify the memory layout and make it break the build if it doesn't work out.
Some thoughts that might help implement this:
- We need to do a full verification if CONFIG_TSEG_STAGE_CACHE == y. - The constraints are that - CONFIG_SMM_TSEG_SIZE needs to be larger than the sum of smm (tseg code + data), CONFIG_SMM_RESERVED_SIZE, CONFIG_IED_REGION_SIZE, and AMD's HIGH_MEMORY_SCRATCH (currently: 0x30000) if CONFIG_DRIVERS_AMD_PI is enabled - CONFIG_SMM_RESERVED_SIZE must be large enough to hold ramstage + postcar + refcode (as loaded by the stage loader, ie. uncompressed) + ~64 byte overhead for IMD headers - STM has additional requirements (reach out to Eugene Myers who's our domain expert on STM), among others: - memory requirements per CPU, calculated by a formula (this could be based on CONFIG_MAX_CPUS, I guess?) - The easiest approach might be to build a tool at build time which includes config.h (so we have all the CONFIG_* around), and various coreboot library portions: - CBFS adapted to work from a file loaded from disk - IMD that works on a memory buffer (sized from CONFIG_SMM_RESERVED_SIZE) - The tool would be spliced into the build process using the build system's INTERMEDIATE facility, copying a coreboot.rom to another coreboot.rom if and only if the tool decides that the memory map is properly dimensioned.
With such build time verification we should be able to clean up various memory sizing configuration values by a fair amount, so there's less variability on them. Creating a tool that computes a full memory map is more complex because it requires rebuilding/relinking a couple of stages (e.g. build ramstage to determine its size, then rebuild it with the computed memory layout that includes ramstage size)