Attention is currently required from: Felix Singer, Bora Guvendik, Zhixing Ma, Hannah Williams, Anil Kumar K, Cliff Huang, Jérémy Compostella, Kapil Porwal.
Hello Bora Guvendik, Zhixing Ma, build bot (Jenkins), Hannah Williams, Anil Kumar K, Tarun Tuli, Cliff Huang, Subrata Banik, Kapil Porwal, Nick Vaccaro,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/73619
to look at the new patch set (#13).
Change subject: soc/intel/cmn/cse: Handle EOP completion asynchronously ......................................................................
soc/intel/cmn/cse: Handle EOP completion asynchronously
coreboot supports three instances of sending EOP: 1. At CSE `.final' device operation 2. Early as with Alder Lake in chip_operations.init if `SOC_INTEL_CSE_SEND_EOP_EARLY' is selected 3. At BS_PAYLOAD_BOOT as designed for Meteor Lake if `SOC_INTEL_CSE_SEND_EOP_LATE' is selected
Currently, Alder Lake uses #3 as it results in better and more stable boot time. However, what would deliver even better result is to not actively wait for CSE completion.
This patch introduces a new `SOC_INTEL_CSE_SEND_EOP_ASYNC' Kconfig which split the action of sending EOP request and receiving EOP completion response from the CSE.
This patch used in conjunction with #1 can significantly improves the overall boot time on a Raptor Lake design. For example `SOC_INTEL_CSE_SEND_EOP_ASYNC' on a skolas board can deliver up to 36 ms boot time improvement as illustrated below.
| # | Late EOP | Async EOP | |----------+----------+-----------| | 1 | 1020.052 | 971.272 | | 2 | 1015.911 | 971.821 | | 3 | 1038.415 | 1021.841 | | 4 | 1020.657 | 993.751 | | 5 | 1065.128 | 1020.951 | | 6 | 1037.859 | 1023.326 | | 7 | 1042.010 | 984.412 | |----------+----------+-----------| | Mean | 1034.29 | 998.20 | | Variance | 4.76 % | 5.21 % |
The improvement is not stable but comparing coreboot and FSP performance timestamps demonstrate that the slowness is caused by a lower memory frequency (SaGv point) at early boot which is not an issue addressed by this patch.
We also observe some improvement on an Alder Lake design. For example, the same configuration on a kano board can deliver up to 10 ms boot time improvement as illustrated below.
| # | Late EOP | Async EOP | |----------+----------+-----------| | 0 | 1067.719 | 1050.106 | | 1 | 1058.263 | 1056.836 | | 2 | 1064.091 | 1056.709 | | 3 | 1068.614 | 1055.042 | | 4 | 1065.749 | 1056.732 | | 5 | 1069.838 | 1057.846 | | 6 | 1066.897 | 1053.548 | | 7 | 1060.850 | 1051.911 | |----------+----------+-----------| | Mean | 1065.25 | 1054.84 |
The improvement is more limited on kano because a longer PCIe initialization delays EOP in the Late EOP configuration which make it faster to complete.
CSME team confirms that: 1. End-Of-Post is a blocking command in the sense that BIOS is requested to wait for the command completion before loading the OS or second stage bootloader. 2. The BIOS is not required to actively wait for completion of the command and can perform other operations in the meantime as long as they do not involve HECI commands.
On Raptor Lake, coreboot does not send any HECI command after End-Of-Post. FSP-s code review did not reveal any HECI command being sent as part of the `AFTER_PCI_ENUM', `READY_TO_BOOT' or `END_OF_FIRMWARE' notifications.
If any HECI send and receive command has been sent the extra code added in `cse_receive_eop()' should catch it.
According to commit 387ec919d9f7 ("soc/intel/alderlake: Select SOC_INTEL_CSE_SEND_EOP_LATE"), FSP-silicon can sometimes (on the first boot after flashing of a Marasov board for instance) request coreboot to perform a global request out of AFTER_PCI_ENUM notification. Global request relies on a HECI command. Even though, we tested that it does not create any issue, `SOC_INTEL_CSE_SEND_EOP_ASYNC' flag should not be associated to the `SOC_INTEL_CSE_SEND_EOP_EARLY' flag to prevent potential a global reset command to "conflict" with the EOP command.
BUG=b:276339544 BRANCH=firmware-brya-14505.B TEST=Tests on brya0 with and `SOC_INTEL_CSE_SEND_EOP_ASYNC' show End-Of-Post sent soon after FSP-s and EOP message receive at `BS_PAYLOAD_BOOT'. Verify robustness by injecting a `GET_BOOT_STATE' HECI command with or without `heci_reset'. The implementation always successfully completed the EOP before moving to the payload. As expected, the boot time benefit of the asynchronous solution was under some injection scenario undermined by this unexpected HECI command.
Change-Id: Ib09dcf9140eb8a00807a09e2af711021df4b416f Signed-off-by: Jeremy Compostella jeremy.compostella@intel.com --- M src/soc/intel/common/block/cse/Kconfig M src/soc/intel/common/block/cse/cse.c M src/soc/intel/common/block/cse/cse_eop.c 3 files changed, 213 insertions(+), 35 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/19/73619/13