Subrata Banik has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/48847 )
Change subject: soc/intel/alderlake: Update CPU microcode patch base address/size ......................................................................
Patch Set 2:
(1 comment)
https://review.coreboot.org/c/coreboot/+/48847/1/src/soc/intel/alderlake/fsp... File src/soc/intel/alderlake/fsp_params.c:
https://review.coreboot.org/c/coreboot/+/48847/1/src/soc/intel/alderlake/fsp... PS1, Line 112:
What if FSP(UCODE loader) fails to load UCODE?
Consider this is 2nd time patching just needed for mcheck init flow as coreboot always use FIT way of loading ucode and this is not related to ucode update flow. In API mode if FSP fails to load ucode then FSP don't care because this is not chronical error do it will notify bootloader. But i believe this could be part of FSP info hob where FSP can dump this information and bootloader can parse to know the exact failure.
I think coreboot should check if UCODE is loaded succesfully or nor.
I think you are referring to mcheck init is successful or not, not the ucode load because ucode load would be always successful as part of FIT loading process
If UCODE load fails, coreboot should trigger CrOS Recovery mode. I think we should have a separate discussion on this.
2nd ucode load failure don't cause recovery rather there should be some information pass through between FSP and bootloader so that we avoid debugging such weird issue.
For now, let this patch be in.