On 2021.02.19 16:01, Arnd Bergmann wrote:
The main purpose of the Tianocore port to the Raspberry Pi (as I
understand it) is to give developers a chance to hack on Tianocore
without having to buy or risk breaking an expensive server.
No.
It can be used as such, yes. But that is certainly not the reason I and
some other developers got involved in this project.
Granted, we did use this opportunity to try to make it a showcase of
SBBR, but this was done *precisely* with the idea to demonstrate to
platform vendors that, if the Pi was able to get there, it shouldn't be
that complicated for them to add SBBR compliance in their platform too.
So, I would turn that around to state that the main purpose of the
Tianocore port to the Raspberry Pi was to prove that, as opposed to what
many are assuming, SBBR compliance is actually not that difficult to
implement and is probably something vendors should consider to add for
their platform.
Having Tianocore onto an SD card to get booted instead of a kernel
is not really all that different to having a Debian netinstall kernel/initrd
on the SD card.
Except, and this is the main point, it provides a familiar environment
to the user, who can reap the benefits of some much needed
uniformization between platforms.
Why, when it is absolutely possible to achieve it, as was demonstrated
on a cheap platform like the Pi (that actually comes with horrible
quirks to be able to accomplish so, especially in terms of xHCI
support), should end users have to juggle with heteroclitic means of
configuring their system for OS installation? Why shouldn't they be able
to take a single ARM64 installation source for their favourite Linux
distro, and expect that to work on their ARM64 platform, just like it
does on their x86 PC?
This goal can be achieved. And, precisely for those who seem to doubt
that it can be achieved, we are using one of the cheapest and most
widespread platform to demonstrate it (because it makes sense to use
that as a example).
2. Working with mainline kernel to add whatever ACPI drivers are needed
to support their platform, which too is arguably better than requiring
everyone to use your "custom" version of the kernel.
The only thing that is needed for platform support is to have
the actual device drivers upstream, ACPI has nothing to do with
it.
Except that the SBBR specs clearly points to ACPI being the preferred
method of describing the platform hardware, so that the same SBBR
platform can be used for Linux, Windows or whatever other OS a user may
choose, it does make sense to want to prefer ACPI over the Linux-centric
Device Tree.
Now, that does not mean that you can't support both (and in fact the
Raspberry Pi UEFI firmware does). But in terms of following the specs,
you want to prefer ACPI over something else.
The reason that servers tend to just work is that they follow SBSA,
which defines a minimum set of hardware that just works, but that
doesn't help you on non-server hardware.
I don't believe the Raspberry Pi was ever developer with SBSA in mind.
And yet it has an SBBR compliant UEFI firmware.
We certainly don't want to add ACPI support for all those non-server
platforms to the kernel, in addition to the support that we already
have.
Can you explain why?
What's the downside there?
Isn't the whole point of a kernel to support the hardware that a large
enough number of users want to see supported, regardless of how it is
being discovered? Or is there a secret clause that I'm not aware of, and
that states "(*) as long as that hardware is not being discovered
through ACPI"?
Regards,
/Pete
