Re: Debian on Pine64 H64B?
On Tue, Sep 07, 2021 at 11:00:29AM +0100, Pete Batard wrote:
> Hi Reco,
>
> On 2021.09.07 10:42, Reco wrote:
> > Hi.
> >
> > On Tue, Sep 07, 2021 at 10:29:40AM +0100, Pete Batard wrote:
> > > Hi Gunnar,
> > >
> > > On 2021.09.06 18:59, Gunnar Wolf wrote:
> > > > Gene Heskett dijo [Sat, Sep 04, 2021 at 09:43:07AM -0400]:
> > > > > (...)
> > > > > So I found my own solutions. So, debian-arm, please make up your mind, do
> > > > > you support the pi's or do you NOT support the pi's?
> > > >
> > > > Debian has a very clear line set: We do _NOT_ ship non-free software,
> > > > no exceptions. Given the Raspberries need a non-free firmware blob for
> > > > the GPU to hand over execution to the ARM CPU at bootup... Yes, that
> > > > clearly means no official Debian images exist for Raspberry Pi
> > > > hardware.
> > >
> > > I'd say that's not really true, since it's very much possible to
> > > install Bullseye on the Pi 4 using *vanilla* unmodified ARM64 Debian
> > > ISOs [1]. And the same has been true for Buster on the Pi 3 for some
> > > time too [2].
> >
> > A small nitpick. While it's indeed possible to boot rebuilt UEFI on
> > Raspberry Pi3 (which is free software, since it's patched TianoCore),
> > and boot unmodified Debian ARM64 via said UEFI - the booting of UEFI
> > itself still requires Broadcom blobs, which are non-free software.
>
> 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.
Yet there's a difference. Intel ME or AMD PSP do not require firmware to
be written on a boot media, thus making the boot media redistributable
and (other blobs excluded) - DFSG-compliant.
In the case of the Raspberry Pi 3 (unsure about RPi 4) it's required to
have non-free Broadcom blobs in the first partition of SD card.
The resulting media for Raspberry Pi 3 is non-DFSG compliant, because
each and every file on a media that's used to boot is within the scope
of Debian. Or it cannot be provided by Debian officially.
I'm not writing that to imply that x86 or RPi is somehow more or less
"free" compared to each other. Compared to other ARM boards I've dealt
with, both x86 and RPis are equally non-free ;)
And of course, the porting of UEFI on RPi 3 (have not tried this on RPi
4) is an important achievement by itself, because while UEFI is an
overcomplicated and overengineered beast, it's still the best effort of
standartization of ARM booting we have these days.
> If the idea is that the Pi platform is less free than the x86 platform
> because you need to provide non-free blobs for boot, you may want to
> take a closer look at how modern x86 PCs behave in that matter,
> because they are just as non-free as the Pi, albeit in a manner that
> makes it less visible to the user.
I did not meant that. But I can compare Raspberry Pi to, say, kirkwood
subarch (QNAP TS series), where all you need to boot is a free software
without exceptions, starting with the bootloader.
Or, I can compare it to Odroid N2/N2+, where all non-free blobs are
contained to SPI, and the proper free OS is booted via simple kexec.
> But again, it doesn't matter because the provision of non-free blobs
> is then moved outside of what Debian needs to concern itself with
> (it's now part of TF-A/UEFI bringup, which is the place where these
> blobs should logically reside), which allows the use of blob-free
> Debian images.
But still, if [1] haven't stalled - all this discussion we're having
today would be pointless.
Reco
[1] https://github.com/christinaa/rpi-open-firmware
Reply to: