Re: Debian on Pine64 H64B?
On 2021.09.07 15:55, Reco wrote:
It's illogical, but still - as long as the device has non-modifiable
firmware it's considered good, proper and "free".
If said firmware can be modified (as in - reflashed in EEPROM), or worse
- the device requires firmware to be uploaded on it at every poweron -
one has to distinguish between free and non-free firwmare.
Okay, then we're on the same page that there's no fundamental difference
between modern x86 PC and Raspberry Pi, as PCs have reflashable EEPROM.
My point of contention here is that there's no reason to treat RPi and
x86 PCs differently, because, since both these platforms use proprietary
blobs for boot (at least for any PC produced in the next 10 years), they
both must be considered non-free.
And my point is that, since we are dealing with non free systems, it
makes little difference whether the non-free blobs reside in an EEPROM
or on boot media.
But the system was designed to be as cheap as possible, and therefore,
to spare the cost of flash, with the result of requiring uses to
provide firmware from the boot media.
I have to disagree here.
Not sure what you're disagreeing with. It's pretty obvious that one
thing the Raspberry Pi Foundation has been doing to cut cost was to use
a boot method that does not require the adding of a flash chip to the
board (which is further evidenced by newer revisions of the Pi 4 having
done away with the flash that was previously used for the xHCI firmware
when they figured out a way to load it from the boot media as well).
The goal of the Pi Foundation has always been to provide the cheapest
platform they could, and eliminating the need of an Flash EEPROM for
platform bringup is one effective way to do that.
Again, that does not mean that I approve or am happy with that decision,
but I don't think there's much to disagree about what the intention of
the Pi Foundation has been, and why they happily went with an SoC that
allowed users to provide all the firmware blobs needed for early boot on
their own boot media.
If there's one thing that RPi design shows us,
it's how to make a profit on a bad-selling SOC initially intended for
media players.
I mean, the primary CPU is initalized by GPU.
The "main" OS is actually a second-class citizen running in a confined
environment, making RPIs unsuitable for any serious kind of realtime.
The lack of proper RTC (I know there's separate addons for that).
Network and I/O added as an afterthought, attached via USB (RPi 4 not
included).
Overheating problems.
I don't disagree with that. I've had to deal with the Broadcom quirks
and bugs (including a major screwup with DMA access above 3 GB for the
SoC used on the Pi 4), and I too would much rather have preferred the Pi
Foundation to go with something where corners had clearly not been cut.
But I don't think it's really relevant to this discussion, outside of
justifying why we don't happen to be dealing with non-free blobs that
are semi-hidden in an EEPROM, as we do for other systems.
If you're looking for a cheap as possible SBC, I suggest you to look at
NanoPIs.
I'm not looking for anything. I'm a happy user of NanoPC-T4 (running
armbian), which I think does a much better job than a Pi 4. But I'm also
realist in that the Pi 4 has enough momentum to make it a very
attractive platform for many, regardless of its obvious flaws, and
therefore, that we need to make sure that users are in a position to
install OSes like Debian without penalizing them more for using non-free
blobs than x86 PC users are being penalized for having non-free blobs in
their platform's firmware.
As long as the booting process does not require the OS to deal with
non-free blobs directly, i.e. - not having those at filesystem or first
megabytes of media does not have any impact on the boot process - yep,
I kind of feel like you are making rules here.
The only part I can agree with is the "as long as the booting process
does not require the OS to deal with non-free blobs directly", which,
IMO, the UEFI installation processes for Debian that I linked to do
qualify for. These processes are specifically designed so that Debian
does not even have to know whether these non-free blobs exist, since
they are only being used for TF-A/UEFI bringup. And as a matter of fact,
we could actually delete them from the media altogether, from within
UEFI, before UEFI hand-off, and it'd create no issue whatsoever (outside
of inconveniencing users by forcing them to copy these files again for
the next boot). Of course they would still be present in memory, but
since your concern appears to be with what resides on the media...
So, as I said, these blobs are orthogonal to the Debian boot process and
should be considered as if they were internal to UEFI, in the same
manner as Intel ME or RAM set-up blobs of Intel UEFI PC platforms are
considered to be internal to x86 UEFI firmware.
But this hypothetical addon looks user-modifiable to me, so ... see
above.
I'd say flash EEPROM on PC is user modifiable too on PC, so...
I agree that using a separate media would be a viable workaround in this
case
Okay. In that case you may want to consider, again, that the only reason
the process we describe does not ask users to create 2 media is purely
for convenience, and therefore that it's a bit pointless to declare that
the one media method is bad whereas the two media method is okay,
especially as I have to maintain that what happens with the one-media
method and non-free blobs is no different that what happens with x86 PC
installation of Debian, when the UEFI firmware (which is user-modifiable
since, for instance, and provided someone did the groundwork, you can
replace it with coreboot -- which does include non-free blobs required
by modern platforms) also contains non-free blobs.
In other words, if that's your concern, nobody is claiming that the
Raspberry Pi platform even remotely qualifies as a free platform. But it
needs to be considered that, in that respect, and even as the
proprietary blobs are being provided on user media rather than hidden in
an EEPROM, it is no different than the equally non-free modern x86 PCs.
As such I don't believe that trying to make a big fuss over the fact
that the procedure we advise to use for single media installation of
vanilla Debian does end up with non-free blobs on the same media, is
warranted. Just like what's the case for x86 PC, Debian OS will never
have to concern itself with these blobs, let alone care about their
existence.
Regards,
/Pete
Reply to: