[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters

Well, I guess at this stage, and to help provide some more context about the DT vs ACPI conundrum, I'm going to stop tiptoeing around the literal elephant in the room, but not without first adding a preliminary notice that I wasn't privy to whatever discussions occurred with regards to the SBBR standard (I'm just a mere downstream developer, that got involved well after SBBR was crafted), so part of it is yet again going to be pure speculation.

The "elephant" in the room, in our case, is Microsoft since, from what I understand, they did drive part of the design of the standard... which of course makes sense since they do have an OS that they would like to see people install on ARM servers and therefore will be interested in an emerging ARM standard that's likely to affect them. And likewise, the ARM folks, when devising a new standard, most certainly wanted feedback from the company that still holds the lion's share of installed OSes out there. So, any decision that was taken as part of the writing of the standard is likely to have had Microsoft's footprint in one way or another.

That's not to say that (again from what I understand) Microsoft got free reign, and that people interested in promoting the standard for Linux, BSD or something else got the short end of the stick. But of course, now that you know that Microsoft did play a part in this whole SBBR endeavour, it might give you yet a different perspective on this whole ACPI vs DT matter...

On 2023.05.08 12:15, James Addison wrote:
Somewhat agree, yep - although I think that in this case, there should
be various paths available (u-boot, EDK2, ACPI/DT), and if possible
I'd like to understand what is the approach that provides the most
compatibility and free software support with the fewest moving parts.
To me, the reliability and human-time cost savings from simpler, more
open and straightforward systems outweigh many other factors,
especially over the long term.

Agreed. But to others such as Microsoft, not having to integrate something foreign when they already have good support for both UEFI and ACPI in their OS was probably something that they had some strong opinions about. In other words, while I like to imagine that Microsoft did consider whether it would make sense to add support for DT for Windows on ARM, and ultimately decided against it on a technical basis rather than on an "it'll make life simpler for us", it appears that the consensus settled on not having DT being part of the standard.

That's partly the reason I've been wondering about the power
consumption and operating-system-compatibility questions: as I
understand it, those were key reasons that server hardware vendors had
a preference for ACPI when determining the server standards in the
mid-2010s, and so a few years since then, it could be helpful to
figure out whether those continue to make a difference, and how
Devicetree/FOSS driver implementations compare.

If Microsoft and the people who drove the SBBR standard did review things objectively, this might indeed be part of why they decided not to add DT support.

I think that's great, and I've had a good experience with EDK2 +
Devicetree.  My concerns about ACPI are basically that it seems like a
less-readable, larger-surface-area standard with more opaque processes
surrounding it.  But I'm not an expert.

Yeah, neither am I, and I'll trust Linus and the kernel folks when they decided that ACPI was such a liability that they had to devise something better... This being said, I do wonder if DT has been holding all its promises and doesn't come with its own pitfalls, now that we've seen it used in practice for a few years. At least, as someone who has had to help with implementing code that *alters* the original DT provided by the Pi Foundation, so that it can actually be used downstream of UEFI boot (which is something we have to do in the current Pi UEFI firmware [1]) and has had to look from the sidelines at the annoyance of still having to use a compiled-in format (couldn't some bz2 of plaintext, with a little extra processing/runtime compilation from the kernel, work well enough so that one could make editing of DT a lot friendlier for the end users? Talk about doing away with binary formats...), I can't say I'm entirely convinced that DT couldn't have been improved further.

Getting slightly further off-topic, but for my own education: what is
an example of a UEFI feature that a user might want to use?

Well, the big one would of course be Secure Boot.

Others would be the ability to have an interface from the OS, that allows one to modify boot order/boot entries and read/write some (relatively) standardised pre-boot environment variables. Oh and don't forget the ESP, which is a lot more user friendly as a means to alter your bootloaders and boot environment (just copy/edit at the file system level, from your OS and with your utilities of choice, or use a full blown shell if you need to) than using the (AFAIK) much more limited means of accomplishing the same with something like u-boot.

Plus, UEFI has an official standard, and standards are (for the most part) a good thing.

(to my mind, most of my preferences are: I want to use a standard,
easily-obtained installer,

I believe UEFI gives you that.

for each system install to be straightforward
Well, the standardised ESP and boot variables of UEFI should give you that too (that is, as long as Microsoft doesn't abuse the ability to change/alter the UEFI boot entries from the OS, in order to disregard the user's choice and force Windows first, which they do tend to do).

and for the system to boot, for each system's devices
to function correctly,

Before OS handover, if your bootloader is UEFI compliant, it will have access to all of the system's devices for which UEFI has a driver.

and for those to occur while minimizing the
amount of extraneous runtime code and I/O (roughly in that order of
precedence, and with FOSS practices helping a lot to achieve and
maintain those in the long-term).

I'd say UEFI drivers are usually fairly lean, at least for the base ones provided by EDK2, even if supporting the UEFI standard may make it look like they are encumbered with extraneous stuff. But that's standards for you, and they exist to ensure that, if you do follow them, you're not going to end up with something like a nasty Linux Shim boot loop for instance (which is something that recently happened to me with a driver I had put together, and that wasn't fully UEFI compliant [2])...

perhaps ranty, but it's intended to
explain why I don't love standards that include unusual and/or
unproven quirks, and binary blobs)

As we've seen above, I'd go further than that, and consider that DT isn't exactly ideal in that respect, as it still, in essence, works with binary blobs...

As to quirks, for having worked with the EDK2 folks, I'd say that if there's something that they strive to avoid, it's unusual quirks or anything that's left open to interpretation (which is another thing that's caused me some grief with the RPi UEFI implementation, as we did identify an element from the specs that was subject to interpretation, and the specs were refined... but in a different direction than what we would have wanted [3]).

If I were to imagine a two-line chart of device and hardware support
over time, with one line each representing the ACPI and Devicetree
approaches, then based on this standardization and industry backing, I
would expect ACPI to be the upper line for some duration of time
(decade?) until the point at which the drawbacks and disadvantages of
the extraneous functionality and complexity that I sense (but can't
really confirm, yet) outweigh the industry momentum placed behind it.

However, with what I have mentioned initially and the weight that Microsoft has, the only way you're going to have vendors moving away from ACPI is if Microsoft decides to add support for DT in Windows (or something else that they see better than ACPI)... which I don't really see happening in the near to medium term, since, much to their benefit, Microsoft did manage to get the ARM SBBR specs to go with ACPI and thus continue business as usual as far as Windows is concerned.

And I think that's a shame, because if the same effort and backing had
been placed behind a simpler, more open and maintainable approach
(namely the other line, Devicetree) then I think that overall
ecosystem cost savings and user/consumer respect improvements could
have been increased -- and that _should_ be good business.

Again, I am hoping that there was some consideration given by Microsoft and other members of the SBBR committee as to whether it made sense to go with Device Tree. One of the problems I would see however is that, I doubt the Linux folks consulted with Microsoft when they introduced Device Tree (then again why and how would they) to see if Microsoft had some interest for using it in the long run, and if so, what they could do to make it more palatable for Windows usage.

And that's the old problem of ecosystems being split on OS lines, when it would be nice if we could look a bit further than that, with Linuxfolks most likely not that eager to ask Microsoft if they have some input on the direction they wanted to take when they introduced DT, and, likewise, Microsoft unlikely to want to use some "Not Invented Here" technologies like DT, even more so when you have the other elephant in the room for the "Not Invented Here", i.e. Apple, which seems so adverse to compromising with anybody that it provides the worst example to follow such as, using their own version of EFI on x86 based hardware rather than UEFI, and then dropping that altogether on their ARM based silicon, to now use their own completely custom pre OS execution environment. At this stage, I should probably add that it's going to be fat chance to ever see Apple use SBBR on their hardware even, if on paper, it should have been a perfect target for it and sure would have make booting and installing Debian on Apple Silicon easier... even if one were to be constrained to use ACPI over DT.

Ultimately it feels like a question of time, though, and
delaying progress based on revenues and partnerships from a margin of
unnecessary cost passed on to purchasers feels wrong.

To me, it looks like mostly a question of reducing development cost as well as what one can get away with by not going out of their way to try to talk and seek compromise with other parties. And, as usual, it's the end-users that pay the price by having hardware and OSes that restrict what they should be able to do with it, starting with their ability to install the OS they prefer on modern ARM64 hardware.

And that's actually the reason why I think efforts like SBBR should be supported, because they are trying to break the status quo, even if it appears that Microsoft might have gotten what they wanted at the detriment of Linux, and even if Apple are unlikely to ever want to touch SBBR with a ten foot pole...

My understanding is that the Linux development community has (and
continues to) pay the cost of maintaining ACPI compatibility, while
Devicetree (also with cost to support and develop) appears
well-supported across multiple architectures

Well supported across architectures: yes.
Well supported across OSes: Unfortunately no, when you do consider Windows.

And that is the main issue here. SBBR is not just for Linux, or for Windows. So, yes, someone, on the OS side, is likely to have to do extra work, whose only purpose will be to allow people to install a completely different OS. And yes, that sucks. But if it benefits end-users, it's the price one has to pay.



[1] https://github.com/tianocore/edk2-platforms/blob/master/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c#L470-L507
[2] https://github.com/rhboot/shim/issues/558#issuecomment-1490993221
[3] https://bugzilla.tianocore.org/show_bug.cgi?id=3336

Reply to: