Attention is currently required from: Arthur Heymans, Dinesh Gehlot, Eran Mitrani, Jakub Czapiga, Kapil Porwal, Tarun.
Subrata Banik has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/80567?usp=email )
Change subject: soc/intel/mtl: Skip RW CBFS ucode update if RO is locked ......................................................................
Patch Set 1:
(1 comment)
Commit Message:
https://review.coreboot.org/c/coreboot/+/80567/comment/0e3b9b08_50b221c0 : PS1, Line 16: 3. The kernel can still load microcode updates without affecting : AP FW boot time. :
How is the kernel faster than coreboot at loading microcode? Isn't this just moving the process of updating the microcode update to a later stage?
you got it correct, there is nothing like kernel is faster than coreboot. we see two reasons to support this migration
- microcode part of the RW CBFS is mostly for patching ucode hot fixes for production device which can be any way loaded by OS. Hence, it just moving the responsibility to OS as there is not much value of doing ucode loading from RW CBFS during boot. May be another 500ms later (by kernel) than what coreboot is doing today.
- any attempt to update ucode part of RW CBFS requires firmware qualification by OEM and pushing the FW update for the device, which is costly (and FW update is not that frequent compared to the OS update). hence, atleast for the chromeos device, we don't push any ucode update for in-field device using AP FW rather we perfer to patch those using linux-firmware.
In short, this commit msg line is just conveying that, any attempt to load ucode update by kernel doesn't impact AP FW aka BIOS boot time which we are measuring using `cbmem -t` and <1sec is critical goal for us to meet this KPI.
I hope it explains the motivation behind pushing this CL.