Change in ...coreboot[master]: soc/intel/basecode: Add support for updating ucode loaded via FIT

[Nico Huber (Code Review)]

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 36:
> > > > 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.
>
> Nico, Consider the fact that in case of Chrome devices, when we are in "recovery" mode, we need to have absolutely assured way of loading all FW pieces from immutable storage and hence runtime (before cpu reset) selection capability to switch from RO to RW was deemed important and hence the usage of top swap. Other platforms can chose to simply add another uCode entry into FIT and be done with it. I do think that OEMs, when they ship products, will ensure that a bootable uCode is in place which just works. Let me know if you have any other specific concerns.

Thanks for the reasoning, I didn't know about the "recovery"
constraints. I don't have real concerns here, I only tried to
discuss alternatives. And already learned a lot.

Though, I'm still wondering about all the possible and allowed
paths coreboot may take. If I understand you correctly, when
booting to recovery with top-swap set, we'd have to disable it
and reset (to ensure that we run from immutable storage next
time). Wouldn't it result in mostly the same sequence when we'd
use one FIT with multiple entries, erase the RW entries when
booting in recovery and then reset? I'm not proposing to do it
like that, just wondering if it would be feasible.