Attention is currently required from: Nick Vaccaro, Vladimir Serbinenko, Yu-Ping Wu.
Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/81508?usp=email )
Change subject: Support for creating hybrid vboot images ......................................................................
Patch Set 5:
(1 comment)
Patchset:
PS5: I'm honestly not really sure what you're trying to do here anyway. Can you describe your high-level goal in more detail?
It looks like you're adding a separate CMOS field that can control whether coreboot boots in recovery mode (from the RO partition) or as normal from the RW partition. So I'm assuming that you install the normal ChromeOS coreboot and payload in the RW slot and your own alternative OS firmware and payload in the RO slot? Or the other way round?
But then I don't really understand why you're doing all this work to try to create compatibility between the old RO/RW images from Volteer and the current coreboot ToT. That really only makes sense if you can't change the RO anymore (because it's write-protected)... but you're making a few changes to the RO here anyway, so clearly you'll still have to remove your write-protection and update your RO. So then why don't you just build both your alternative OS firmware and the ChromeOS firmware from ToT and then you don't have to worry about being compatible with some ancient image? Volteer should still build and boot fine in ToT for both coreboot and depthcharge (at least we're trying to keep it that way for all but the super old Chromebooks, and if something broke by accident it's usually an easy fix), so you can still build firmware that can "boot ChromeOS" but with the ToT coreboot code and RO/RW interface.
And for that matter, I also don't think that the vboot RO/RW interface is the right point to select which OS you're booting. That's not really what it's designed for. It's designed to be the cut-off point between updateable and non-updateable firmware, but the differences between the two RW images (and the recovery RO image) are only supposed to be differences in which version of the code they're running, not what boot policy that code follows.
If you want to change boot policy (and maybe make it controllable by a CMOS flag), that would probably belong in the payload according to the usual coreboot philosophy. In fact, we already have such a mechanism in our depthcharge payload that you could simply use for your purposes if you want to. It does pretty much what you want: it can boot either stock ChromeOS or a custom payload that you install, and which one it picks in the next boot can be controlled by a CMOS setting (except that this setting is in the vboot nvdata part of CMOS and you control it with our `crossystem` utility, by running `crossystem dev_default_boot=altfw` or `crossystem dev_default_boot=disk`). It will also display a UI on boot where you can select the boot target manually, but if you set the right GBB flag it will only show for 3 seconds before going with the default. See https://www.chromium.org/chromium-os/developer-library/guides/device/develop... for details on how to use that if you're interested.