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 38:
Patch Set 36: I do understand the process in this change. Let me elaborate my theory more accurately. You can have a RO FIT with entries to both RO MCU and RW MCU (at least that is what I understood earlier). Booting with the process of this change and top-swap disabled should have the same effect as booting with such a two-entry FIT and erased RW MCU. Right?
It's a design goal in Chromebooks that stuff like recovery mode remains predictable (ie. rely on read-only data _only_), while still allowing features like dev mode. (There's also the option of disabling write protect, but that's a whole different story.)
The top-swap solution provides this feature under these constraints even for FIT-based ucode updates. Your proposal requires erasing a block in RW even though it might not be "ours" anymore, but managed by the device owner (eg. in dev mode).
Well, in this change, the stage ucode might not be "yours" anymore and you rely on the TS bit that might not be "yours" anymore either. I don't want to debate about this (whose nvram is whose), just wanted to know the reasoning. Thank you :)
Erasing the stage ucode everytime to go into recovery wouldn't be wise, so I prefer the TS solution, too.