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
