Re: Feedback from the community -> ARM
On Fri, 2021-06-11 at 10:32 +0200, Marcin Juszkiewicz wrote:
> Ask Raspberry/Pi vendor then. Make them work on getting support for
> their product into mainline, make use of available standards during
> design of their next products.
Ist this criticism fair?
I am running on my aarch64 RPi4 currently:
root@pi:~# uname -a
Linux pi 5.10.0-7-arm64 #1 SMP Debian 5.10.40-1 (2021-05-28) aarch64
root@pi:~# dmesg | head -4
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd083]
[ 0.000000] Linux version 5.10.0-7-arm64
(firstname.lastname@example.org) (gcc-10 (Debian 10.2.1-6) 10.2.1
20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian
[ 0.000000] efi: EFI v2.70 by https://github.com/pftf/RPi4
[ 0.000000] efi: ACPI 2.0=0x33a20018 SMBIOS=0x37100000 SMBIOS
3.0=0x370e0000 MEMATTR=0x358cc018 MOKvar=0x358ce000 RNG=0x372db798
root@pi:~# dpkg -l "*5.10.0-7*"
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture
ii linux-image-5.10.0-7-arm64 5.10.40-1 arm64 Linux
5.10 for 64-bit ARMv8 machines (signed)
a stock Debian kernel, that does everything I need (USB mass storage
for disk, GigE for network, HDMI for install). It has no WiFi, but
I have had lots of arm64 hardware that did not either.
> Properly designed Arm board should boot generic ISO written into USB
> stick (dd if=d-i.iso of=/dev/sda). Several SBC work that way already
> (or can have their firmware flashed to be that way).
Yes, this would be preferrable, but booting via EFI partition
is not that bad either. And can be considered a standard way
of booting too. Having to copy the files to FAT32 is an inconvenience,
but on the other hand ISO9660 is an obsolete inconvenience too
(wo installs from real, rotating physical media today?).
BTW I've had quite some problems getting even run of the mill
PC hardware boot from USB media into UEFI. Tianocore for Pi
has really become quite good.
> Distributions should not waste time on getting SBC systems working
> but SBC vendors should make them 'just work' with distributions.
"Should", yes. But I very rarely hear the same criticism concerning
Asus mainboards or Dell notebooks, when they do not consider
Linux distributions that much either.
> You go to store, buy x86-64 laptop/computer and expect it to just
> work with Debian.
Have you tried that recently? Bought some arbitrary laptop without
knowing detailed lists of included components, and inserted a
netinstall USB key? Chances are good this won't work that much
better than installing on RPi4, because you need at least
firmware-realtek (non-free) to get any networking at all.
> 'of the mill notebook': connect cables, plug USB stick with generic
> installer, boot, install, use. Then use the same USB stick with
> another notebook from different vendor.
And get no networking for netinstall? The last 4 or 5 amd64
computers I installed for myself (i.e. not dedicated server
hardware, that is *a lot* better) needed some non-free drivers,
making install just about as convenient as on the RPi4. Mainly
it was for networking (both wired and WiFi).
> RPi4: find out how it boots, prepare SD card with RPi4 specific
> installer, boot, install, use. And then rewrite SD card for another
> I see a difference.
So do I. "find out how it boots" is much more complicated with
the RPi4, as there is very little official Debian documentation
on this topic. There are probably 4 or 5 ways to boot the Pi 4,
and no official guidance which to pick or which are considered
supported or better supported ways of installing.
I have installed on Sparcstations in the past, and install
was complicated (IIRC bootp/tftp netboot, ...) but at least
there was official documentation on how to get your Sparc machine
up. In the official release notes, and not by googling various
tutorials of variyng degrees of trustworthyness.
This documentation is sorely missing for the Pi today. And Sun
did not care too much about Debian back then either.
> Let me be honest: if someone wants to use R/Pi SBC then R/Pi OS is
> what they should use. To not waste time of other distribution
And if I buy an Asus mainboard, then I should use Windows and
not waste the time of distribution maintainers? What about the
other official Debian ports?
What I want to say is not that I think I am entitled to ask
anything from Debian porters and developers (I am certainly not),
but the double standard of accepting that Asus, Dell, Acer, etc.
could not care less about Debian support for non-server/workstation
class hardware, and not even documenting how to best install
on Raspberry Pi (yes, the Raspberry Pi foundation probably does not
care too much about Debian either) surprises me a bit.
Is there a way to help here?
There are probably about 10 million RPi4+400 machines out by now
and only about 400 aarch64 entries in popcon. Why is that? To me that
is a missed opportunity. I read lots and lots of postings about
people installing Kubernetes setups on 5 or so Pi4 machines (aarch64)
because the pi fills a niche there (cheap, but also good value for
money). Why should these people all be steered towards Ubuntu? And no,
I don't imagine these people going out and buying Mustang ARM boards.
> This way you get 'probably working' kernel with all out-of-tree
> patches needed to get board working and functional + set of packages
> with out-of-tree patches to get userspace running.
My Pi 4 runs an unpatched arm64 kernel directly from Debian. To me it
seems completely functional except for missing WiFi drivers in my
headless setup. It runs for months without any problems. What am I
On the other hand I often hear people recommending obscure SBCs
that only boot with very specific, old kernels, *over the Raspberry
Pi*. Most RPi patches have been upstreamed before 5.10 or so
(luckily for bullseye), with WiFi in 5.12 AFAIK.
> Debian, Fedora and other distros usually do not ship those out-of-
> patches because they are not even on a way to mainline projects.
These patches are basically no longer needed for the Pi4, and
other distributions (Ubuntu, Fedora) are much much easier to
install on the pi.
> Check doc, write new one, send to maintainer. Or even to this ML.
I will try.