> > >> The project is https://gitlab.com/CentOS/automotive/src/ukiboot and reads > > >> UKI (https://uapi-group.org/specifications/specs/unified_kernel_image) > > >> images from raw data partitions. Just like ABL reads Android Boot images. > > >> > > >> > Are you planning to add it to the EBBR specification? > > >> > > > >> > > >> I haven't thought about it before but I also didn't know that u-boot had > > >> this requirement. Probably it should be documented somewhere to make it > > >> more clear? Maybe I didn't look enough but didn't find a doc in the repo. > > > > > > We are not strictly and only EBBR requirements, if there is good reason > > > > That's good to know. Heinrich's answer seemed to imply that u-boot was > > limited to EBBR requirements. > > It's one of the main users, yes, but it shouldn't be seen as *only* for > that.
Also to note that EBBR is a living spec and can evolve, typically the way we've done that historically is to have an implementation, or at least patches, in U-Boot first to prove out the idea before putting something in the spec so IMO this is the right way to go about this. > > > to add more features (and tests). But Heinrich's follow-up question is > > > > Oh, I missed the lib/efi_selftest directory. I'll see to add a test then. > > Thanks. Yes, the lack of tests was the first thing I noticed on the patches ;-) > > > quite important. I feel like there's already a half dozen offerings of > > > A/B update that works within UEFI. > > > > > > > I just brought the A/B boot protocol used by ukiboot because I was asked > > how I was using the EFI_PARTITION_INFO_PROTOCOL. But I'm not proposing to > > add a new A/B update mechanism for u-boot, just to implement an existing > > EFI protocol... > > Yes, this was more a lament for the ecosystem as a whole really. The > concept of A/B(/Golden) with various security features is pretty old at > this point, there's many implementations. I wish there was not "here is > yet another" in the space. > > But regardless, we should aim to have U-Boot be able to be used with it. > Otherwise my crystal ball says that a few years down the line it'll be > hard to use Fedora-IoT-distro on common-device with U-Boot. There's a basic concept of a fallback with the UEFI bootnext bits but yes, if UEFI actually had the ability to deal with proper A/B we wouldn't need a dozen different ways to do it, sigh, of course there's some harder things that also need to be addressed like changes for signing keys etc. The other initial feedback I would ask is around a Kconfig to make it optional, will everyone want/need it, what's the size impact? Cheers, Peter
