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:
- RW needs to stay the same as changing it would break ChromeOS mechanism
Sorry, I don't really understand this point or what you mean by "would break ChromeOS mechanism". ChromeOS should continue to boot just fine under ToT coreboot and depthcharge. If it doesn't on a specific platform that's a bug that we can fix. There should be no need to bend over backwards just to be able to reuse the unmodified ChromeOS RW when you're recompiling the whole rest of the firmware anyway. That's one of the reasons we're using open-source firmware, after all, there's no secret sauce in our release images, you can rebuild all of it yourself and it will work just as well.
I understand that there are certain things that are problematic with the RW_LEGACY solution. (But I'm not actually sure they're impossible to solve, FWIW... for example, it should be possible to recreate ACPI tables and replace what coreboot wrote in an RW_LEGACY payload if you wanted to, just a bit more cumbersome.) But in those cases, you can still just rebuild coreboot to include those ACPI/SMMSTORE/whatever changes that you need to support Windows, but then still use depthcharge on top of that modified coreboot, and use it to select which OS to boot. You can also have a different FMAP for that (e.g. to create a distinct SMMSTORE section) because you're rebuilding the entire RO anyway.
Unless you're saying that you really need different ACPI tables between ChromeOS and Windows, because Windows will refuse to boot with the ChromeOS ones and ChromeOS will refuse to boot with the Windows ones? In that case, I guess you do need a differentiation mechanism earlier in coreboot, and maybe you should be using the `normal/bootblock`/`fallback/bootblock` mechanism for that then (I think that would at least be more appropriate for this purpose than vboot, which really wasn't designed to be used this way). But you can still build the ChromeOS part for that from ToT. (I don't think that should be necessary, though? Surely, there should be a way to write some unified ACPI tables that both systems can be happy with? I'm pretty sure we managed to do that a couple of years back when we were toying with a dual-boot solution, we certainly weren't planning to boot through two totally separate versions of coreboot.)
I totally agree with making dual boot easier and removing pain points where possible, I just think what you're trying to do with vboot here is really going in the wrong direction and there should be a better way.