Hi Leif and Francois,
On Thu, 22 Oct 2020 at 17:44, Leif Lindholm leif@nuviainc.com wrote:
Francois already replied more elegantly, but I'll respond regardless.
From Francois:
Let’s take concrete examples: chromeOS and Android are defining optimized and secured way of booting a single known OS. This is some form of walled garden and well defined. UEFI main goal is to provide an open way to boot any OSes, OSes that are unknown to UEFI. It can boot MacOS, windows, Linux, FreeBSD and even my hobby OS. EBBR is not about defining a unique boot flow that every one has to conform to. EBBR ambition is to allow any OS to be booted from an embedded board. Think of those vertical solutions: all at a sudden it increases the applicability of those solutions. It brings nothing to walled gardens environments but it does not prevent them to continue evolving their own path. In other words, it is not about standardizing everything into one boot flow, it is about opening the door to an ecosystem of OSes for boards, open source or not. Now, the walled gardens have found elegant solutions to some problems. I think one driving principle for EBBR is that we should leverage all those ideas so that we maximize code reuse.
Yes that is indeed a very concise and elegant explanation. My reading of this is we actually have the same goal to a large extent. But the key point here is 'not standardising...boot flow'. EBBR seems to be more about a sort-of plug-in approach with the EFI API as the common interface. So that seems to be the difference?
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... 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.
(long pause while I contemplated the large disconnect here, finished off the Christmas cake and went back to work)
I suppose I am confused also. It doesn't help that I know very little about distributions generally and I can barely use the grub command line.
I expect from the name EBBR - Embedded Base Boot Requirements, that these are the base requirements for embedded booting. I had assumed that Chrome OS, for example, would eventually conform to this. In my mind, I should be able to boot different operating systems on my computer, including Chrome OS / Chromium OS.
But reading this thread again suggests that EBBR is a standard that requires using EFI protocol to couple firmware with the OS in a defined way. It does not seem very 'base' to me. Nor does it standardise things like verified boot, selecting A/B kernels, setting kernel parameters, the kernel upgrade mechanism, etc. These are presumably all left to distributions to deal with individually. I look at multiboot and actually see more definition of the boot mechanism. Perhaps EBBR would be better described as a distribution-boot convenience.
I am not intending to criticise EBBR since even what you describe sounds very valuable. Also while certain things about EFI are not to my taste (for example, in no particular order, the code style, GUIDs and its propensity to encourage closed-source firmware), I did in fact write the first EFI implementation in U-Boot in 2015 (booting U-Boot from UEFI), and spent much time reviewing and testing Alex's code a year later, as well as encouraging the inclusion of tests, which we now have thanks to Heinrich.
In any case I am not suggesting creating a new specification, but perhaps we could at least figure out what such a specification might solve. I would like to see:
- a dumb 'instruction file' of some sort for each OS on the system, a bit like the grub menu but not Turing-complete :-) - some non-volatile context to describe the user's preferences and system settings
and from those, be able to deterministically define the boot behaviour, with a set of unit tests to check it. It may be that this would be an anathema to distributions, since they would need to collaborate on a shared implementation of it. Perhaps it would also be pointless for distributions since they already have grub and UEFI on x86 and everything on ARM should just follow that path.
Or maybe not? I'm certainly interested in understanding all this better and it's the main reason I try to follow along with this.
Regards, Simon