Last updated: 2021-04-24

Low-level development

ARM (sunxi)

I saw in the sunxi family the opportunity to have a fully owner-controlled mobile device, with no hidden managment engine or binary blobs. With the availability Pinebook and PinePhone, mainline Linux support has become the limiting factor for that dream. My contributions include:

  • The power management firmware and related firmware support in TF-A
  • The DRAM frequency scaling driver
  • Runtime and system power management support in several device drivers
  • Major updates to the sun8i-codec audio driver to support the modem and BT audio interfaces
  • Initial U-Boot support and automatic device tree selection functionality

I have also helped with various bugfixes and improved support for some of the less popular sunxi single-board computers:

x86 (coreboot)

I ported coreboot to the Foxconn G41S-K motherboard, with the hope that it would allow me to use my SATA controller in AHCI mode. Unfortunately, that turned out to be a chipset limitation, not a BIOS limitation. But I had fun and learned a lot in the process. I later ported coreboot to the Intel DQ45EK board.

I also contributed the coreboot framebuffer drivers to Linux. This allows smaller Linux payloads, since a full graphics driver (like i915) is no longer needed.

Application development

I wrote the initial version of the WireGuard Android app.

Back when it was still relevant, I helped port Cyanogenmod and other aftermarket firmware to the Samsung Galaxy Player 5.0. I also developed a stock-based custom Gingerbread firmware for that device.

Packaging and system administration

I have published the system-wide and user-specific portions of my service bundles for s6-rc.

My Portage configuration (including /etc/portage, my overlay, and my patches to the main Gentoo tree) can be found on my binhost.

About Me

Last updated: 2021-04-24

I am an enthusiastic tinkerer, focused on embedded software and system integration. Generally everything I do as a hobby is open source. You can find more information about my personal projects on this website, as well as on my GitHub profile.

Contact Information

My usual online handle is smaeul, a permutation of my first name.

The best way to reach me directly is through email at It is the common communication medium that practically everyone shares, and it has a vendor-independent mechanism for push notifications, so most of my other contact methods get forwarded there anyway.

I do not participate in walled-garden social media.

My background

I come from the American Midwest: the land of corn, cows, and Google Fiber. I started reading books on programming from a young age, first on C++, and then on x86 assembly. My hobby was playing with DOS programs and boot sectors written in assembly until I got to university and started writing POSIX-flavored C in earnest.

My first introduction to Linux was Red Hat 8, installed from a pair of scratched CDs in the back of a book checked out from my local public library. These were the days of HAL, and Kudzu, and out-of-tree Fast Ethernet drivers. Having no Internet connection at the time, it wasn't terribly useful, but I remember fondly the KDE desktop and the sample songs that shipped with Kmid.

The first public project I released was a "BuildSkin", a tool to customize skins for The Lord of the Rings Online (an MMORPG). It allowed users to combine XML fragments from various sources; most "skins" were expanded or rearranged versions of a single in-game window. It also provided an engine for resolving mathematical expressions in the X/Y/Width/Height of UI elements. This made life easier for skin developers, who no longer had to do the math by hand, and no longer had to ship a separate copy of their skin for each supported screen resolution.

To me, the beauty of free and open source software is that it is as flexible as your imagination! When a proprietary program doesn't work the way you want, you're out of luck. But if you want to make an open-source application behave differently, all you have to do is write a patch.

I avoid having unused or excessively complicated programs and libraries on my computing systems. I refer to this principle as "minimizing the problem space". Simply put, fewer lines of code provide fewer places for bugs to hide. This principle led me first from Debian to Arch (to rid myself of the mess of Perl wrapper scripts that Debian adds to everything), and then to Gentoo (to reduce the number of library dependencies).

At the time (2015), I had several other reasons for choosing Gentoo. For one, its use of keywords provided more stability than what was available on Arch. Second, I had a growing number of patched or custom packages on Arch; Gentoo's overlay facility and /etc/portage/patches made these much easier to manage. And finally, Gentoo was one of three distributions that had musl support, which I wanted to use as soon as possible.

Nowadays, the ecosystem around musl is much more mature. I still write a lot of patches, but they are mostly trivial. So I made things more challenging by switching my workstation to a big-endian CPU archicture (powerpc64).

Licensed CC-BY 4.0 by Samuel Holland.