Tag: ARM64

Really leaving the Linux desktop behind

I’m excited to start a new chapter of my life tomorrow. I will be starting a new job working at an excellent company with excellent benefits and a comfortable wage.

It also has nothing to do with Linux distributions.

I have asked, and been granted, clearance to work on open source software during my off time. And I do plan on writing libre software. However, I really no longer believe in the dream of the Linux desktop that I set out to create in 2015. And I feel it might be beneficial for everyone if I describe why.

1. Stability.

My goal for the Linux desktop started with stability. Adélie is still dedicated to shipping only LTS releases, and I still feel that is useful. However, it has made more difficult because Qt has removed LTS from the open source community, plainly admitting they want us to be their beta testers and that paid commercial users are the only ones who deserve stability. This is obviously an antithesis to having a stable libre desktop environment.

Mozilla keeps pushing release cycles narrower together, in a desperate attempt to compete with evil G (more on this in the next section). This means that the yearly ESR releases, which Adélie depends on for some modicum of stability, are unfortunately being left behind by whiz bang web developers that don’t understand not everyone wants to run Fx Nightly.

I think that stability may be the point that is the easiest to argue it could still be fixed. You might be able to sway me on that. There are some upstreams finally dedicating themselves to better release engineering. And I’ve been happy to find that even most power users don’t care about running the bleeding edge as long as their computer works correctly.

My overall hope for the future: more libre devs understand the value of stable cycles and release engineering.

My fear for the future: everything is running off Git main forever.

2. Portability.

It’s been harder and harder for me to convince upstreams to support PowerPC, ARM, and other architectures. This even as Microsoft and Apple introduce flagship laptop models based on ARM, and Raptor continues to sell out of their Talos and Blackbird PPC systems.

A significant portion of issues with portability come from Google code. The Go runtime does not support many non-x86 architectures. And the ones it does, it does poorly. PPC support in Golang is 64-bit only and requires a Power8, which is equivalent to an x86 program requiring a Skylake or newer. You could probably get away with it for an end-user application, but no one would, or should, accept that in a systems programming language.

Additionally, the Chromium codebase is not amenable to porting to other architectures. Even when the Talos user community offered a PowerPC port, they rejected it outright. This is in addition to their close ties to glibc which means musl support requires thick patches with thousands and thousands of lines. They won’t accept patches for Skia or WebP for big endian support. They, in general, do not believe in the quality of portability as something desireable.

This would be fine and good since GCC Go works, and we do have Firefox, Otter (which can still use Qt WebKit), and Epiphany for browsers. However, increasingly, important software like KMail is depending on WebEngine, which is a Chromium embedded engine. This means KDE’s email client will not run on anything other than x86_64 and ARMv8, even though the mail client itself is portable.

This also has ramifications of user security and privacy. The Chromium engine regularly has large, high-risk security holes, which means even if you do have a downstream patch set to run on musl or PowerPC, you need to ensure you forward-port as they release. And their release models are insanely paced. They rewrite large portions of the engine with significant, distressing regularity. This makes it unsuitable for tracking in a desktop that requires stability and security, in addition to portability.

And with more and more Qt and KDE apps (IMO, mistakenly) depending on WebEngine, this means more and more other apps are unsuitable for tracking.

My overall hope for the future: more libre devs care about accepting patches for running on non-x86 architectures. The US breaks up Google and kills Chromium for violating antitrust and RICO laws.

My fear for the future: everything is Chrome in the future.

3. The graphics stack.

I’ve made no secret of the fact that my personal opinion is that it would still, even today, be easier to fix X11 than to make Wayland generally acceptable for widespread use. But, let’s put that aside for now. Let’s also put aside the fact that they don’t want to work on making it work on nvidia GPUs, which represent half of the GPU market.

At the behest of one of my friends, who shall remain nameless, I spent part of my December break trying to bring up Wayland on my PowerBook G4. This computer runs KDE Plasma 5.18 (the current LTS release) under X11 with no issues or frameskip. It has a Radeon 9600XT with hardware OpenGL 2.1 support.

It took days to bring up anything on it because wlroots was being excessively difficult with handling the r300 for some reason. Once that was solved, it turned out it was drawing colours wrong. Days of hacking at it revealed that there are likely some issues in Mesa causing this, and that this is likely why Qt Quick requires the Software backend on BE machines.

When I asked the Wayland community for a few pointers at what to look at, since Mesa is far outside of my typical purview of code (graphics code is still intimidating to me, even at 30), I was met with nothing but scorn and criticism.

In addition, I was still unable to find a Wayland compositor that supports framebuffers and/or software mode, which would have removed the need to fix Mesa yet. Framebuffer support would also allow it to run on computers that run LXQt fine, like my Pentium III and iBook G3, both of which having Rage 128 cards that don’t have hardware GL2. This was also met with scorn and criticism.

Why should I bother improving the Wayland ecosystem to support the hardware I care about if they actively work against me, then blame the fact that cards like the S3 Trio64 and Rage128 don’t have DRM2 drivers?

My overall hope for the future: either Wayland compositors supporting more varied kinds of hardware, or X11 being improved and obviating the need for Wayland.

My fear for the future: you need an RX 480 to use a GUI on Linux.

4. Usability.

This is more of an objective point than a subjective one, but the usability of desktop Linux seems to be eternally stuck just below that of other environments. ElementaryOS is closest to fixing this, but there is still much to be desired from my point of view before they’re ready for prime time.

In conclusion.

I still plan to run Linux – likely Adélie – on all servers I use. (My fallback would be Gentoo, even after all these years and disagreements, if you were wondering.)

However, I have been slowly migrating my daily personal life from my Adélie laptop to a Mac running Catalina. And, sad as it is to say, I’ve found myself happier and with more time to do what I want to do.

It is my genuine hope that maybe in a few years, if the Linux ecosystem seems to be learning any of these lessons, maybe I can come back to it and contribute in earnest once again. Until then, it’s system/kernel level work and hacking POSIX conformance in to musl for me. The Linux desktop has simply diverged too far from what I need.

Booting a custom kernel/OS on the Raspberry Pi 3 B (64-bit)

On Wednesday afternoon, we were having a discussion of various 64-bit ARM SoCs on the Adélie Linux chat. I mentioned that the only one I had was a PINE64, which did not support graphical display on the version of the Linux kernel we ship. Michael, one of our contributors, suggested I should buy a Raspberry Pi 3 for testing graphical software (such as KDE and Firefox). I was surprised to learn that Target carries the RPi3 and they had a few in stock locally. Off I went, stopping in for a 128 GB µSD card as well.

Then began the fun: I had a RPi 2B some years ago, but it was lost in the move. I only have experience booting these things using NOOBS, and I wanted to use NOOBS anyway because that would allow me an easy way to have multiple system images and choose which one to boot. This will let me perform 32-bit ARM testing on the RPi3 later on, when we support 32-bit ARM a bit better. Therefore the first order of business was to figure out how NOOBS’ boot menu works, so that I could write a custom configuration with the partition layout how I desired:

  • Shared /home, 40 GB XFS
  • 64-bit /boot volume, 1 GB FAT32
  • 64-bit root (/) volume, 39 GB ext4
  • 32-bit /boot volume, 1 GB FAT32
  • 32-bit root (/) volume, 39 GB ext4

Since NOOBS erases the SD card on first boot, I booted NOOBS once on the Pi before continuing. Then I went to work in fdisk on my Talos:


Disk /dev/sdb: 119.3 GiB, 128043712512 bytes, 250085376 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xb41dea51

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sdb1            8192    137215    129024    63M  e W95 FAT16 (LBA)
/dev/sdb2          137216 250085375 249948160 119.2G  5 Extended
/dev/sdb5          139264    204797     65534    32M 83 Linux
/dev/sdb6          206848  81995775  81788928    39G 83 Linux
/dev/sdb7        81997824  84092927   2095104  1023M  c W95 FAT32 (LBA)
/dev/sdb8        84094976 167981055  83886080    40G 83 Linux
/dev/sdb9       167983104 170078207   2095104  1023M  c W95 FAT32 (LBA)
/dev/sdb10      170080256 250085375  80005120  38.2G 83 Linux

Through trial and error, with a fairly good reference and reading the source code of NOOBS, I was able to divine the layout of my desired installed_os.json file. Once NOOBS is booted for the first time, it makes a small “settings” partition; this was /dev/mmcblk0p5 on the Pi and /dev/sdb5 in the SD card reader of my workstation.


[
        {
                "description": "A friendly, easy-to-use desktop environment that uses little resources",
                "folder": "/mnt/os/Adelie64",
                "icon": "/settings/os/adelie.png",
                "name": "Adélie Linux (64-bit)",
                "partitions" : [ "/dev/mmcblk0p7", "/dev/mmcblk0p8" ],
                "release_date": "2019-02-21"
        },
        {
                "description": "A friendly, easy-to-use desktop environment that uses little resources",
                "folder": "/mnt/os/Adelie32",
                "icon": "/settings/os/adelie.png",
                "name": "Adélie Linux (32-bit)",
                "partitions" : [ "/dev/mmcblk0p9", "/dev/mmcblk0p10" ],
                "release_date": "2019-02-21"
        }
]

I placed this file in the root of the settings partition (/dev/sdb5 in this example) and downloaded the header image from our Web site to /os/adelie.png on the same. Now the structure looked like:


gwyn /mnt/PiStuff # tree
.
├── cache
│   ├── data7
[ lots of irrelevant files removed ]
├── installed_os.json
├── lost+found
├── noobs.conf
├── os
│   └── adelie.png
└── wpa_supplicant.conf

I then unpacked the Adélie Linux aarch64 root FS image to the root partition (/dev/sdb8 in this example). I downloaded the needed firmware files for /boot from the official Raspberry Pi Foundation GitHub repository, and put them in the boot partition (/dev/sdb7 in this example). Then came a full day of trial and error with the kernel.

Kernel config

Our Adélie easy-kernel package boots great on the PINE64 and a few other SoCs, but it needed small adjustments to be comfortable booting on the Raspberry Pi 3 B. In addition to the configuration knobs noted by the Raspberry Pi Foundation, we added CONFIG_FB_SSD1307=m and CONFIG_FB_UDL=m for eventual support of the Pi’s touchscreen interface. (I have not yet tested that and do not know if this is sufficient or not.)

Next was spending four hours trying to understand why the system booted properly but had no display on-screen. dmesg contained:


[   11.423042] vc4-drm soc:gpu: failed to bind 3f902000.hdmi (ops vc4_hdmi_ops [vc4]): -517
[   11.423147] vc4-drm soc:gpu: master bind failed: -517

As it turns out, this was because I was using DTB files from a different kernel build. It’s incredibly important to use the DTB files that ship with the kernel you are testing with! After installing the correct DTB files to the SD card and booting again, a different message was output:


[   14.347564] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi  3f902000.hdmi mapping ok
[   14.348456] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
[   14.348689] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
[   14.349175] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[   14.349459] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops [vc4])
[   14.349687] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops [vc4])
[   14.349903] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops [vc4])
[   14.349968] vc4-drm soc:gpu: failed to allocate buffer with size 16777216
[   14.349995] vc4-drm soc:gpu: failed to allocate buffer with size 16777216
[   14.350080] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
[   14.350092] vc4_v3d 3fc00000.v3d: Failed to allocate memory for tile binning: -12. You may need to enable CMA or give it more memory.
[   14.350195] vc4-drm soc:gpu: failed to bind 3fc00000.v3d (ops vc4_v3d_ops [vc4]): -12
[   14.386347] vc4-drm soc:gpu: master bind failed: -12
[   14.386385] vc4-drm: probe of soc:gpu failed with error -12

This was correct; the solution was adding cma=256M@256M to the kernel command line. The final command line that I use is: root=/dev/mmcblk0p8 rootwait ro cma=256M@256M.

I rebuilt Mesa with VC4 support; our 32-bit ARM package had it already, but we did not enable it on 64-bit ARM. Then I installed KDE and X.Org: blackjack ~ # apk add kde x11 mesa-dri-vc4. Behold!

Adélie Linux running KDE Plasma 5 on a Raspberry Pi 3 in 64-bit mode

Please consider supporting our continued adventures bringing quality Libre Software to more platforms! You can find ways to help out on the Adélie Linux Contribution page, or directly on Patreon, PayPal, or Ko-fi. I hope this article was able to help you learn something new about your Pi.