Francois already replied more elegantly, but I'll respond regardless. On Thu, Oct 22, 2020 at 14:15:47 -0600, Simon Glass wrote: > > If you are looking for a Linux-centric way of getting a > > fully-vertically-integrated OS up and running with a minimum of code, > > then that is arguably closer to the artist formerly known as LBBR: > > https://developer.arm.com/architectures/system-architectures/arm-systemready/ls > > although that probably carries other baggage you are also not > > interested in. And quite possibly does *not* add the bits you want. > > > > I'm not saying what you're asking for wouldn't be useful, but that I > > don't think EBBR is the answer. > > But then it begs the question, what is EBBR for.
It defines the interfaces to which any operating system can connect in order to boot, without having any prior knowledge of that platform. It's about general purpose computing and off-the shelf operating systems. It's not about standardising fully-vertically-integrated u-boot(or coreboot)+linux setups. The de-facto reference implementation for U-Boot was initially written by Alex Graf to enable the standard UEFI SuSe installer (and post install, bootloader) to run unmodified on U-Boot platforms. > I had assumed that we > were trying to get devices to use it, if they don't want to use > ACPI... I'm confused. ACPI can be used without UEFI. UEFI can be used without ACPI. EBBR is about defining a minimal subset of UEFI that is still useful to enable generic OS installers (or cloud images, or...). Any codebase can implement that subset, and U-Boot now does. But a codebase that does not implement a subset of UEFI cannot be compliant with EBBR. Hence EBBR does not try to describe such things. > but if it doesn't cover the needs, it's just an n+1 solution, > as I said above. For the problem it is not trying to solve, absolutely. It is also not a solution for RCU or ending wars. > It seems to me that we could standardise some of these things without > too much trouble. By focussing on EFI (only) and not on how we can > standardise all the boot flows, we might be missing the point. Which would nullify all the reasons for which the EBBR were actually created. There is no connection between what the EBBR is and what you are asking for. There doesn't need to be any natural conflict between what that is and the EBBR, and it would certainly be useful if it could be made compatible with whatever specification you end up creating. Best Regards, Leif _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
