Re: Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters
On Tue, May 09, 2023 at 09:53:54AM -0400, Lennart Sorensen wrote:
>On Tue, May 09, 2023 at 12:22:02AM +0100, Pete Batard wrote:
>
>> Again, I'd prefer to go with number end-users as a better measure, since
>> we're not developing for the greater variety but for is likely to benefit
>> the greater masses. Of course, if ARM64 system manufacturers collectively
>> decide they want to ignore Windows and SBBR, and go with openfirmware, I'll
>> be more than happy to let Microsoft add openfirmware compatibility to
>> Windows on ARM, as long as the end-users stop having to jump through
>> system-specific hoops to install the OS they want.
>
>Well certainly devicetree makes the kernel and driver handling much
>simpler and more consistent, but the boot loader on all the different
>arm systems isn't standardized. Using UEFI on SBBR means a standard
>grub2 uefi boot loader should work on any system, so that does seem
>like a benefit. Of course that really just means UEFI might be a big
>improvement, not that ACPI vs devicetree is. No idea if UEFI can work
>with devicetree or not. Being an intel thing I would not be surprised
>if ACPI is rather tied into it, since that would make sense. A quick
>look at wikipedia says UEFI actually provides devicetree services on
>RISC processor systems. I guess that makes sense since pretty much all
>RISC systems seem to have used openfirmware or something similar so
>their OS would expect that. Little endian only though of course.
UEFI doesn't have to push ACPI, no. Indeed, some of the UEFI platforms
out there (e.g. Macchiatobin) let you choose whether to pass on DT or
ACPI to the boot loader / OS.
AIUI the main reason that Microsoft went with ACPI on the Arm platform
is just that they already had ACPI for x86. It's therefore much easier
for them to push the same requirements onto new platforms, of course.
DT for Arm is very much *not* just for Linux (see FreeBSD and other
OSes, and of course various boot loaders). However, there is still an
outstanding historical mess: lofs of Linux developers think that the
DT configuration on various platforms is theirs to change as they
please to suit the Linux kernel.
The original DT plan was to only ever include DT sources with the
Linux tree as a *temporary* thing until a reasonable number of
platforms provided DT data directly from firmware. DT was just meant
to be a static description *of the hardware*. But (like a lot of
"temporary" things), we're now a lot of years later and there's no
sign this is ever going to change. There's certainly no will to have a
fight about this.
Against that background, I genuinely think Microsoft have done the
sensible thing by sticking to ACPI rather than embracing DT for Arm
platforms...
--
Steve McIntyre, Cambridge, UK. steve@einval.com
Dance like no one's watching. Encrypt like everyone is.
- @torproject
Reply to: