Re: Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters
On Tue, May 09, 2023 at 12:22:02AM +0100, Pete Batard wrote:
> Interesting; TIL.
>
> I guess I'm probably not the only person who thought DT was something that
> was only cooked recently by Linux kernel maintainers, since that's when it
> became mainstream for the majority of the x86/PC based end-user crowd.
You are definitely not the only one. The ability to attach an fdt
devicetree file to the kernel on systems that didn't have openfirmware
to provide the data was a more recent addition, but it was simply taking
advantage of a system that was already present for years.
> Well, the thing is overall units tends to correlate pretty closely to
> overall end-users. And, while one may try to plan for what one expects/hopes
> the end-user landscape to shift towards, one must still strive to create
> software that makes life easier for the current one. In terms of units, ACPI
> has certainly been more widespread, even if it's mostly due to the
> homogeneity of the dominant arch and platform (x86 based PC).
Certainly it is hard to fight against anything Microsoft and Intel have
decided they are going to use. Neither one seems to care much what
anyone else is doing already.
> > Apple is almost certainly back to devicetree on their arm devices since
> > they used it on their powerpc based systems already in the past.
>
> If that's the case, then (I'm going to assume that) it's shame Apple didn't
> use their position to join the discussion and provide some opposition to
> Microsoft, when it came to going with ACPI-only for SBBR...
Apple doesn't seem interested in their OS being able to run on anyone
else's hardware or anyone else's OS running on their hardware. So not
complyoing with standards probably suits them just fine.
> I'd venture to say that there's been a bit of a chicken and egg problem
> there, which SBBR is in part trying to solve, by attempting to remove one of
> the hurdle people face when getting an ARM64 server, i.e. how the heck am I
> going to install my OS/distro of choice on this machine, instead of being
> constrained by whatever custom version of some other OS/distro the
> manufacturer of the platform decided to go with.
Being able to install an OS certainly is handy, although being able to
even buy the hardware is probably the first step.
> I do agree that we're still early in the game here, if game there eventually
> is, which is the *precise* reason why a group of us worked together to
> provide an SBBR implementation on the commonplace and relatively limited Pi
> platforms, i.e. something that is everything but an ARM server, to both
> provide an easy to access working implementation as well as demonstrate to
> ARM64 system manufacturers that, if this can be accomplished for the Pi with
> limited effort, this should certainly be achievable for their platform.
Certainly useful to have a small cheap platform to be able to work on it.
Unfortunate that even a Pi is a bit hard to get a hold of these days.
> 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.
> I'm going to go further than that and say that not even Microsoft
> appears/appeared to care that much about running Windows on ARM systems, as
> we pretty much offered them a golden opportunity to chase a goal they should
> be exceedingly familiar with, and, what's more, one that Apple will never
> challenge them on, namely running their OS on *cheap* commonplace hardware.
> But they pretty much ignored the crowd that was interested in running
> Windows on the Pi, even as Windows 11 21H2 does run very decently on an 8 GB
> Pi 4 and, current hardware price hike notwithstanding, could have gained
> significant traction with the low income masses. This, in turn, could have
> provided Microsoft with a means to bring (or should I say lock-in) those
> masses into the Windows ecosystem. But instead, it appears they looked at
> what Apple was doing with controlling both the hardware and software through
> an expensive platform, and decided they wanted a piece of that pie, which I
> doubt will benefit them much in terms of trying to keep Windows as the
> dominant OS.
I am not sure why they are trying to make hardware. I get the impression
they make most of their money from subscription services these days,
and Azure.
> Now, as an aside, since the above may make it look like I'm trying to
> advocate for Microsoft and we're on a GNU/Linux mailing list after all,
> please bear in mind that, even as I am primarily a Windows developer these
> days, I am far from rooting for Microsoft or any proprietary software
> company for that matter. In fact, the main software I develop on Windows is
> also designed to allow people break away from the abomination that is
> closed-source proprietary software, like Windows, *if they so choose* (since
> you cannot offer people freedom without also giving them choice). As such, I
> am kind of supporting SBBR for Windows on account that I expect both a
> server-targeted specification to percolate to mainstream platforms
> eventually as well as the masses running these end-user platforms to be
> initially more interested in running Windows, if they have the choice, as
> opposed to some other OS. From there, if we have something familiar like
> UEFI, I am hoping these users may become more receptive to switching to a
> free OS. Oh, and for the record, I have quite a different view when it comes
> to the interest there has been with regards to running Windows on ARM, due
> to the direct feedback we got once in turned out that the Pi UEFI firmware
> could be used to get Windows to run on these platforms, even when it
> originally did so with atrocious performance on the severely limited Pi 3.
> But of course, that interest wasn't from people trying to run these
> platforms as servers in the first place.
>
> Yeah, while I do hope that this wasn't the case, I too assume that there
> weren't much of anybody in the room to try to counter Microsoft.
I would expect Microsoft simply had no intension of adding anything new.
They already had UEFI and ACPI support, so why change it. Certainly it
is the interface of the most common platform out there, so using it does
make some sense.
> But again, I have no idea how ARM and SBBR actually came about, along with
> who actually got invited to participate in the discussion, and who might
> have declined to do so...
Yeah I am sure someone knows.
--
Len Sorensen
Reply to: