Attention is currently required from: Arthur Heymans, Patrick Georgi, Subrata Banik, Maulik V Vaghela, Rizwan Qureshi, Angel Pons, Sridhar Siricilla, Lean Sheng Tan, Patrick Rudolph. Hello Arthur Heymans, build bot (Jenkins), Patrick Georgi, Subrata Banik, Maulik V Vaghela, Rizwan Qureshi, Sridhar Siricilla, Lean Sheng Tan, Angel Pons, Patrick Rudolph,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/62566
to look at the new patch set (#3).
Change subject: intel/block/cpu: Provide a way to cache the flash region temporary ......................................................................
intel/block/cpu: Provide a way to cache the flash region temporary
Since FSP version 2.1 EFI_MP_SERVICES_PPI can be used to bring up all the APs. For some SOCs it is mandatory that MP init is driven by FSP in order to have the full features enabled (e.g. Elkhart Lake or Alder Lake). In this mode FSP does the real MP init while coreboot provides some callbacks (hybrid mode). In this set up, early MTRR setup is done by FSP, too. Later in the boot flow, in BS_WRITE_TABLES exit, the MTRR setup is re-configured by coreboot native code based on the registered resources. This is done before payload is loaded. Now, in this scenario, the SPI flash linear address range is not registered as a resource (since the common SPI driver in src/soc/intel/common/block/spi is shared across multiple SPI controllers and therefore cannot distinguish where the flash is actually located at). This in turn leads to an uncached flash range when coreboot re-configures the MTRRs. The result of this chain is that loading the payload from flash with TPM_MEASURED_BOOT selected takes much longer now (on mc_ehl1 it takes ~12 seconds for 4.5 MB).
This patch adds a Kconfig option to enable flash caching in this scenario, Once the switch is selected (which can be done on SOC level), a call to 'mtrr_use_temp_range()' right after the MTRR setup has been performed by coreboot ensures that the flash region is coverd by a MTRR. This MTRR setup is still tempirary and will be removed before payload is executed. But in turn, it speeds up payload loading a lot when TPM_MEASURED_BOOT is selected (on mc_ehl1 now to ~4 seconds).
The call to 'mtrr_use_temp_range()' has to be done after MTRR setup as otherwise there will be no free variable MTRR slot available due to the missing initialization of the MTRR structure.
Here is the timestamp snippet showing the payload load time as a comparison between current upstream and the patched version:
upstream: 90:starting to load payload 1,072,459 (1,802) 958:calling FspNotify(ReadyToBoot) 12,818,079 (11,745,619)
with this patch: 90:starting to load payload 1,072,663 (2,627) 958:calling FspNotify(ReadyToBoot) 5,299,535 (4,226,871)
Change-Id: If19beaefc8fd3bbbe4b181820993abcd882bbbe1 Signed-off-by: Werner Zeh werner.zeh@siemens.com --- M src/soc/intel/common/block/cpu/Kconfig M src/soc/intel/common/block/cpu/mp_init.c 2 files changed, 11 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/66/62566/3