Re: Debian on Pine64 H64B?
On Tue, Sep 07, 2021 at 03:02:20PM +0100, Pete Batard wrote:
> On 2021.09.07 13:31, Reco wrote:
> > 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.
>
> I disagree.
>
> The reason why the firmware needs to be written on boot media is
> because the system was designed *NOT* to have its boot firmware on SPI
> flash.
>
> So that's a pure design issue.
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.
I did not make those rules, RMS made them before my time.
> For instance, if the PI 4 SPI was large enough to accommodate the 3 MB
> we need, we would happily run UEFI (and the proprietary blobs) from
> there, instead of boot media.
I agree, but sadly it does not change anything in the grand scheme of
things. SPI flash can be modified by user, modification requires
non-free blobs.
> 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. 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.
If you're looking for a cheap as possible SBC, I suggest you to look at
NanoPIs.
> If you want to be pedantic about what constitute free vs non-free
> according to whether the manufacturer of the system took provisions
> for firmware blobs to reside on SPI flash or on a different media, be
> my guest. But, in my view, there is no difference there, as it's just
> a matter of someone deciding from where the firmware files should be
> booted.
Again, I did not make those rules.
> Heck, if you want to go that way, what do you make of a Pi system
> where the firmware blobs reside on a small SD card, that acts as an
> SPI flash equivalent, and the system is installed on a different media
> (e.g USB, which is what would typically be used, especially on the Pi
> 4, as it is *much* faster that SD anyway)? Does that not qualify as a
> DSFG compliant? Because that's already completely possible for the
> Raspberry Pi if you want to go that route.
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,
that makes OS image one step closer to DFSG.
But this hypothetical addon looks user-modifiable to me, so ... see
above.
> > 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.
>
> And nobody forces you to use the SD card where the non-free blobs
> reside to also be your Debian boot media, so you can consider it the
> same as you would consider as SPI flash on a PC, i.e. orthogonal to
> Debian and its installation process.
I'm merely a Debian user, not DM or DD. I do not speak for Debian
Project, and my apologies if my writing convinced you differently.
I agree that using a separate media would be a viable workaround in this
case, but I'm sure there are others who will say their word in the case
I'm wrong.
Reco
Reply to: