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

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

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

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

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.



Reply to: