On 2021.09.09 04:43, Paul Wise wrote:
On Tue, Sep 7, 2021 at 10:00 AM Pete Batard wrote:
Yes, but that is *outside* of the scope of Debian, just like booting
Debian on UEFI x86 based PCs also requires the use of intel or AMD
non-free blobs (for RAM bringup, ME and all the other stuff that CPU
manufacturers have decided they no longer want to open) that are
integrated into the UEFI firmware and that you don't see or have to
provide yourself, but that are very much present still.
I definitely disagree here, boot firmware needs libre licensing,
source code, reproducible builds etc too.
Okay, maybe I didn't express myself properly here, because we're
basically on the same page. I am not saying that where possible, Debian
should not care about providing what you suggest. I'm only saying that,
*WHEN* that is not possible, as is the case on x86 PC and on Pi, Debian
should be flexible enough to understand that taking a hard stance so as
to penalize users, and declaring "Thou shall not boot this platform with
Debian", even as it's most certainly possible to leave the issue of
proprietary blobs outside of what Debian needs to concern itself with
(by, for instance, placing the onus on users to sort the use of
proprietary blobs where needed, and not on Debian), is not in anybody's
interest.
Debian should be able to
provide all the software installed on a system, including the boot
firmware, RAM bringup etc.
100% agree on the should.
The issue is that, by the time the "should" becomes reality (if it
becomes reality), and if you take the stance that no system should boot
Debian until that is the case, you have alienated the modern x86 PC user
base, the Raspberry Pi user base, as well as a bunch of other user
bases, that also would really like to see a completely free system
running Debian, but can't because the complexity of boot and lack of
volunteers to work on providing alternative libre blobs for their system
means they have no choice but to compromise. And considering that I'm
certainly not seeing Debian taking a hard stance against x86 PC boot,
that requires nonfree blobs, I can't help myself asking why the Pi
platform should be treated any differently.
We even have TianoCore in Debian, but we
are missing edk2-platforms and coreboot. The only reason we can't
provide boot firmware on x86 and have to resort to vendor provided
firmware and fwupd is that it is all proprietary forks of TianoCore.
My understanding is that RAM bringup is not a proprietary fork of
TianoCore. It is used by people producing UEFI firmware from Tiano, but
it's not something you can pick the source of, as opposed to what is the
case for Tiano....
Thus, unless I'm mistaken then, I think it's a bit disingenuous to
pretend that the situation with non free blobs on x86 is any better than
the one on the Raspberry Pi. And this is my whole point.
On other platforms like POWER and some ARM devices, the firmware is
libre so we could provide it and in some cases we do already.
And, as mentioned before, there has been some work to provide
replacements for the nonfree blobs on the Raspberry Pi with [1].
So, there again, if that effort was completed we "could" provide libre
firmware. And I'm all for Debian developers investing their time into
that effort to see it completed, if it genuinely bothers them that the
Pi platform, just like the x86 PC platform, has currently to rely on
nonfree blobs.
But I have to stress out that debating in "could" or "should", as we are
doing, does very little to bring a working solution to the end users who
are stuck with platforms that cannot (yet) be liberated, which currently
means:
- Accepting the use of nonfree blobs for RAM bringup and other stuff on
x86 PC (that are provided, outside of the scope of Debian, by a UEFI
firmware residing on an EEPROM, and that Debian does not need to provide)
- Accepting the use of nonfree blobs for pre-UEFI boot on Raspberry Pi
(that are provided, outside of the scope of Debian, by a UEFI firmware
residing on an SD or USB partition, and that Debian does not need to
provide).
Again, my issue is that I see it very disingenuous to have folks here
make it look like the situation for Debian on x86 PC is somehow
different than the situation for Debian on Raspberry Pi (when booted in
UEFI mode), because, when you do look at it objectively, it really isn't.
It's the same thing for both platform, where early boot (currently)
requires the use of proprietary nonfree blobs and where, as long as
nobody has provided a free equivalent for those, it makes little sense
to try to penalize the large amount of existing platform users for the
sake of "purity", especially when nobody is asking that Debian should
provide or even make it easy to obtain these nonfree blobs.
On the other hand, even as I get the feeling that some people have been
eager to present it that way, I am certainly NOT saying that the
situation with using nonfree blobs for platform bringup is something we
should blindingly accept. I too would much rather see a boot process
that is libre from end to end, on any platform. But not at the sake of
alienating a significantly large group platform users if that can't be
achieved in a reasonable timeframe. And that is why, as much as it
actually bothers me that indeed Debian cannot currently be the purveyor
of a completely libre solution from CPU reset, for either x86 PC and
Raspberry Pi, I have no choice but to advocate the current compromise,
as I believe that the ability for users to install Debian, so that they
are then in a better position to work on liberating the remaining
elements that are nonfree on their system, is better than the
alternative, especially when this is a stance that Debian clearly
already applies when it comes to x86 PC...
Regards,
/Pete
[1] https://github.com/christinaa/rpi-open-firmware
