[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian on Pine64 H64B?

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...



[1] https://github.com/christinaa/rpi-open-firmware

Reply to: