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