Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/27369 )
Change subject: soc/intel/basecode: Add support for updating ucode loaded via FIT ......................................................................
Patch Set 35:
Ofc, it's too late for current products. But is there any change planned for the FIT update mechanism. e.g. a rule that multiple updates for one processor signature are allowed and the newest would be applied. That would make this much easier, would allow a single RO FIT with some entries pointing to RO and some to the MCU RW and we wouldn't need the top-swap feature any more.
If you haven't tried, add multiple microcode patches in FIT for the same processor signature, you will find that FIT will pick the latest revision and load. However there is no fallback if there is a failure.
Hmm, that's not allowed by the Coffee Lake BWG.
2 FITs, 1 for normal boot, another for recovery boot. Even if the CPU manages to load the latest revision (from the normal boot FIT) and that results in a hang/reboot loop. We need a tried and tested patch to recover from the hang/reboot for which the top-swap FIT will be used.
That's just relaying the problem of dependable firmware from MCU to coreboot. If things are really that bad that you expect Intel to sign an MCU that results in a boot failure, you shift the problem to this update mechanism here. How can you be sure that no OEM will acciden- tally ship devices with a broken update mechanism in RO? If it's broken, you need a way to recover; a fallback fallback? I understand why you are doing this. I just don't see that it's a good solution.