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

[dhaval v sharma (Code Review)]

dhaval v sharma 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:
> 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.

The thing is: the FIT has to be part of immutable FW too(if we do not do that we lose the whole purpose of recovery mode). So we do not have flexibility to update RO FIT in the field to extend additional uCode patches. In this specific design when we select RO using top swap we are absolutely assured that "NO" immutable code executes in the boot path. This whole logic although may sound a bit complex, addresses the requirements of Chrome recovery requirements as well as IA uCode loading requirements (through FIT before CPU reset). Hope to see simplified implementations in future if either side some requirements can be eased up.