Raspberry Pi Zero W and Funtoo

After finding the PaPiRus ePaper panel, I picked up a Raspberry Pi Zero W to drive it. To be perfectly honest, the early Raspberry Pis never really excited me. However, the Raspberry Pi Zero’s small footprint caught my attention. Add in WiFi and Bluetooth, as found on the Zero W, and you have a solid IoT starter board.

Thanks to the popularity of the Raspberry Pi, both Funtoo and Gentoo have guides on setting up Funtoo/Gentoo on a Raspberry Pi. Getting a base system up and running is straightforward. Though, if you have to compile anything it will take a while.

WiFi

Getting WiFi to work requires some compiling. Funtoo’s guide for setting up WiFi on the Raspberry Pi 3 works for the Zero W for the driver side. On the userland side, you will probably want something like NetworkManager and wpa_supplicant. Unfortunately, neither package come installed in the base install for Funtoo/Gentoo.

Normally, chrooting in from a liveCD with working networking, installing the requisite package, and rebooting is sufficient. However, in this case, you’ll need to setup Qemu on your workstation and then use it to chroot into the ARM environment to compile and install NetworkManager. This will take quite some time.

Playing with PaPiRus

PaPiRus is a ePaper pHAT for the Raspberry Pi Zero. It contains an I2C LM75 temperature sensor, a few push button switches, a SPI NOR flash, and a ePaper panel. Unfortunately, it does not have an I2C memory device to store the device tree overlay information needed for auto-configuration of the SoC.

Since the installer for PaPiRus’ driver, and the manual instructions for that matter, assume a Debian based system, they do not work with Funtoo. Instead, follow the “Install Driver – Option 2” instructions, and rather than apt-get, use the following:

emerge -av sys-fs/fuse dev-python/pillow media-fonts/freefonts

After running make rpi-install the last few steps diverge from the “Install Driver – Option 2” instructions. Since Funtoo by default uses OpenRC rather than Systemd, the epd-fuse.service isn’t going to work. Instead, the OpenRC script below can be used (save as /etc/init.d/epd-fuse).

#!/sbin/openrc-run
# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

EPD_MOUNTPOINT=/dev/epd

depend() {
        need localmount
}

start() {
        EPD_SIZE=2.0
        EPD_OPTS="-o allow_other -o default_permissions"
        ebegin "Starting epd-fuse"
        mkdir -p $EPD_MOUNTPOINT
        if ! grep -qw fuse /proc/filesystems; then
                modprobe fuse >/dev/null 2>&1 || eerror $? "Error loading fuse module"
        fi
        if ! grep -qw $EPD_MOUNTPOINT /proc/mounts; then
                /usr/sbin/epd_fuse --panel=$EPD_SIZE $EPD_OPTS $EPD_MOUNTPOINT >/dev/null 2>&1 || \
                        eerror $? "Error mounting control filesystem"
        fi
        eend ${?}
}

stop() {

        ebegin "Stopping epd-fuse"
        if grep -qw $EPD_MOUNTPOINT /proc/mounts; then
                umount $EPD_MOUNTPOINT >/dev/null 2>&1 || \
                        eerror $? "Error unmounting control filesystem"
        fi
        eend ${?}
}

After saving the epd-fuse script, rc-service epd-fuse start can be used to start the driver. Of course, installing Systemd and uninstalling OpenRC is an option. However, that is quite a bit of effort for something that is overkill for a Raspberry Pi.

Other things to consider, while Funtoo places fonts under /usr/share/fonts, the font packages and directory structure of /usr/share/fonts differs from what PaPiRus expects. The easy way to resolve this is to modify the examples with the correct font location.

Pitfalls

Rather than the older module blacklist/modprobe method for enabling various SOC features, the Raspberry Pi kernel has moved to Device Tree Blobs. Which is not entirely bad. However, they can be difficult to get working.

For short-term testing, to get the PaPiRus to work, I ended up using dtoverlay to enable the SPI and I2C buses, and then had to use modprobe to remove the LM75 driver so that the I2C bus was available to the epd-fuse driver.

-John Havlik

[end of transmission, stay tuned]

Notes on XPS 15 9550 Linux Support

Tired of waiting for a 3D XPoint based SSD to become available, I decided to grab a 512GB Intel SSD 600p for my XPS 15 9550. The intent was to switch over from Windows 10 to Linux on the 9550 while preserving the original SSD should I want to go back.

The actual SSD swap was not too difficult. A Torx T5 and small Phillips screwdriver are needed to remove the back of the 9550 and the m.2 SSD. This being my first NVMe system, I ran into a few gotchas while getting Linux installed. Though, the bulk of the issues are related to Broadcom’s poor Linux support.
Continue reading

Automatically Reconnect a Bluetooth Device in KDE Plasma 5

If  you’re having issues getting your Bluetooth device to automatically reconnect between KDE sessions (or rebooting your computer), try opening a terminal (e.g. Konsole) and clear the contents of your /var/lib/bluetooth directory. After doing this you will need to restart the bluetooth daemon. For reference, in a Gentoo/Funtoo system, the following will accomplish this:

rm -rf /var/lib/bluetooth/*
/etc/init.d/bluetooth restart

Note that the above needs to be run as root (or use sudo). After removing the contents of your /var/lib/bluetooth directory, you will need re-pair your device in the Bluetooth manager. When paring your device, make sure it is set a trusted device.

Now, KDE should automatically reconnect the Bluetooth device after rebooting your computer. Note that the device may not reconnect until after you have logged in. To reconnect sooner, try using a command line Bluetooth device manager.

-John Havlik

[end of transmission, stay tuned]

Working Around “[drm] stuck on render ring” on Intel GMA

After acquiring a Broadwell generation Core i3 NUC (the NUC5i3RYK to be exact) and installing Linux, KDE/X.Org would lockup and crash frequently. Checking dmesg, the following messages appeared:

[drm] stuck on render ring
[drm] GPU HANG:…

From the dmesg report, it is clear the crashes were caused by the GPU hanging. After further inspection of the dmesg logs, it appears this is due to a bug between Intel’s graphics and IOMMU drivers. The easiest way to work around this is to disable Intel IOMMU support.

Since I had compiled IOMMU support into my kernel, removing IOMMU support involved a kernel recompile. When configuring your kernel using menuconfig, make sure that “Support for Intel IOMMU using DMA Remapping Devices” under “Device Drivers > IOMMU Hardware Support” is unchecked. This is equivalent to ensuring that INTEL_MMU = n in your .config file. For the NUC, that was all that was required to keep the GPU driver from crashing and taking X.Org and KDE down with it.

-John Havlik

[end of transmission, stay tuned]