Attention is currently required from: 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 2:
(2 comments)
Commit Message:
https://review.coreboot.org/c/coreboot/+/80567/comment/742cfa98_773a77ef : 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.
Thanks for explaining! I do get the argument to have the kernel do it as it's easier to update than the firmware. The boottime argument is a bit misleading: it needs to be done, whether by the kernel or by the firmware: it's just moving where it's done. Now things are ofc different if kernel has a newer version (as it gets updated more frequently you say), then this makes total sense as then both coreboot and kernel would be doing the same thing.
Maybe add the OS/FW situation to the commit message?
done. updated the commit msg,
Patchset:
PS1:
Is there something specific about mtl for this or does it make sense on more platforms?
nothing specific to MTL and we are planning to land this for other SOCs as well,.