Big Button Studio

Getting a Graphical Desktop Working on the Raspberry Pi 3B+ with NixOS 25.11 and the 6.18 Kernel

2026-08-14T00:00:00Z

TL;DR

The Raspberry Pi 3B+ stops at boot when vc4 KMS starts, on the 6.18 kernel with NixOS 25.11. The v3d node in the firmware device tree has no clocks property. So clk_disable_unused disables the V3D clock, and the driver locks the CPU. The fix is a one-line device tree overlay that adds the clock: &v3d { clocks = <&firmware_clocks 5>; }. Add the overlay to the firmware partition. The steps are at the end of this post.

The problem

The Raspberry Pi 3B+ can run a graphical desktop with NixOS. The desktop needs the vc4 KMS driver and a /dev/dri/card0 device. On a recent kernel, this does not work by default. The 3B+ stops at boot when vc4 KMS starts. This post describes the cause and a fix.

The configuration is nixos-25.11 stable, nixos-hardware, the linux-rpi 6.18 kernel, and the standard firmware-KMS path (dtoverlay=vc4-kms-v3d).

The symptom

When vc4 starts the display, the 3B+ stops at boot. There is no card0, there is no HDMI output, and the boot does not finish. A serial console shows the cause. Route the PL011 UART to the GPIO header with dtoverlay=disable-bt, because the mini-UART is not reliable on the 3B+. The vc4 component master binds its parts and then stops:

[   16.15] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[   16.15] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
[   16.17] vc4-drm soc:gpu: bou                        <- the log stops here

The log stops in the middle of a line. This is the sign of a hard lockup. The CPU stops on a bus access. It is not a clean -EPROBE_DEFER. The kernel parameter clk_ignore_unused makes the 3B+ boot. This is a large clue, but the parameter keeps every unused clock enabled, which is not a precise fix.

The cause

The vc4 driver uses the component framework. It starts only after all of its sub-devices bind: HVS, HDMI, the pixelvalves, and V3D. On the 3B+, the boot stops at V3D.

The V3D node in the device tree has no clocks property. So vc4_v3d gets no clock, and it depends on the firmware to keep the V3D clock enabled. The firmware keeps it enabled, until clk_disable_unused runs early in boot (about 2.4 seconds). This function finds a clock that no driver holds, and disables it. vc4_v3d binds later (about 16 seconds) and reads the V3D_IDENT registers. The V3D block has no clock, and the CPU stops on the read. clk_ignore_unused prevents the problem, because it does not disable the clock.

The first hypothesis was the HDMI state-machine clock and the simpledrm framebuffer. Both were wrong. The cause is V3D.

The correct fix is in the upstream kernel. raspberrypi/linux #7156 gives the node its clock:

&v3d {
    clocks = <&firmware_clocks 5>;   /* 5 = RPI_FIRMWARE_V3D_CLK_ID */
};

Now vc4_v3d holds the clock and enables it again. clk_disable_unused then has no effect.

Why the problem happens on NixOS

The fix is already in the 6.18 kernel source. It is in the kernel's own compiled DTBs. But the 3B+ still stops at boot. The reason is the source of the device tree.

The NixOS Pi sd-image sets useGenerationDeviceTree = false. With this setting, the board uses the firmware DTB from the raspberrypifw package, not the kernel DTB. In nixos-25.11, raspberrypifw has the date April 2025. This date is before #7156. So the kernel is from June 2026, and the device tree is from April 2025. The board uses the old device tree.

This is a version mismatch. It is not a kernel bug or a NixOS bug. The kernel is new, and the firmware DTB is old.

The fix: patch the firmware DTB with an overlay

One option is to use the kernel DTB. Do not use this option. The kernel DTB fixes V3D, but it describes the USB controller (dwc_otg) in a way that the April firmware does not expect. In a test, a USB sound card lost audio data continuously. There were 4 FIQ errors at boot with the firmware DTB, and 22 continuous errors with the kernel DTB. Keep the firmware DTB, and add only the missing property with a small overlay.

v3d-clocks-overlay.dts:

/dts-v1/;
/plugin/;
/ {
    compatible = "brcm,bcm2835";
    fragment@0 {
        target = <&v3d>;
        __overlay__ {
            clocks = <&firmware_clocks 5>;
        };
    };
};

In the NixOS sd-image, compile the overlay at build time. Copy it to the firmware partition. Add a line to config.txt after dtoverlay=vc4-kms-v3d:

let
  v3dClocksOverlay = pkgs.runCommand "v3d-clocks.dtbo" { } ''
    ${pkgs.dtc}/bin/dtc -@ -I dts -O dtb -o "$out" ${./v3d-clocks-overlay.dts}
  '';
in {
  sdImage.postBuildCommands = ''
    # After you finalize config.txt with `dtoverlay=v3d-clocks` added:
    $MT/mcopy -o -i "$img@@$OFF" ${v3dClocksOverlay} ::/overlays/v3d-clocks.dtbo
  '';
}

The overlay is on the firmware partition. The overlay becomes active after a reflash, not after a deploy-rs push. After the reflash, the 3B+ boots correctly. The card0 device appears, and the desktop starts. There is no kernel parameter, and the sound card works.

Fix in steps

These commands create a small flake that builds a graphical sd-image for the Pi 3B+ with the fix. Run them in a new, empty directory. The flake uses nixos-hardware's raspberry-pi-3 module, the sd-image-aarch64.nix module, and a minimal XFCE desktop.

1. Create the overlay source file.

cat > v3d-clocks-overlay.dts <<'EOF'
/dts-v1/;
/plugin/;
/ {
    compatible = "brcm,bcm2835";
    fragment@0 {
        target = <&v3d>;
        __overlay__ {
            clocks = <&firmware_clocks 5>;
        };
    };
};
EOF

2. Create a NixOS module that compiles the overlay and adds it to the image.

cat > vc4-fix.nix <<'EOF'
{ pkgs, lib, ... }:
let
  v3dClocksOverlay = pkgs.runCommand "v3d-clocks.dtbo" { } ''
    ${pkgs.dtc}/bin/dtc -@ -I dts -O dtb -o "$out" ${./v3d-clocks-overlay.dts}
  '';
in
{
  sdImage.compressImage = lib.mkForce false;
  sdImage.postBuildCommands = lib.mkAfter ''
    eval "$(${pkgs.util-linux}/bin/partx "$img" -o START,SECTORS --nr 1 --pairs)"
    OFF=$((START * 512))
    MT=${pkgs.mtools}/bin
    $MT/mcopy -o -i "$img@@$OFF" ${v3dClocksOverlay} ::/overlays/v3d-clocks.dtbo
    cfg=$(mktemp)
    $MT/mtype -i "$img@@$OFF" ::config.txt > "$cfg"
    printf '\n[all]\ndtoverlay=v3d-clocks\n' >> "$cfg"
    $MT/mcopy -o -i "$img@@$OFF" "$cfg" ::config.txt
  '';
}
EOF

3. Create the flake. It builds a graphical (XFCE) image and imports the fix module.

cat > flake.nix <<'EOF'
{
  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-25.11";
    nixos-hardware.url = "github:NixOS/nixos-hardware";
  };

  outputs = { self, nixpkgs, nixos-hardware, ... }: {
    nixosConfigurations.rpi3 = nixpkgs.lib.nixosSystem {
      system = "aarch64-linux";
      modules = [
        nixos-hardware.nixosModules.raspberry-pi-3
        "${nixpkgs}/nixos/modules/installer/sd-card/sd-image-aarch64.nix"
        ./vc4-fix.nix
        ({ pkgs, ... }: {
          system.stateVersion = "25.11";

          # A minimal graphical desktop, auto-logged-in.
          services.xserver.enable = true;
          services.xserver.displayManager.lightdm.enable = true;
          services.xserver.desktopManager.xfce.enable = true;
          services.displayManager.autoLogin = {
            enable = true;
            user = "pi";
          };

          users.users.pi = {
            isNormalUser = true;
            initialPassword = "raspberry";
            extraGroups = [ "wheel" "video" ];
          };

          # 1 GB board: add swap.
          swapDevices = [{ device = "/swapfile"; size = 1024; }];
        })
      ];
    };
  };
}
EOF

4. Build the image. The Pi 3B+ is aarch64. On an x86_64-linux builder, set boot.binfmt.emulatedSystems = [ "aarch64-linux" ] first, to build with QEMU. If the directory is a git repository, run git add . first, because flakes ignore untracked files.

nix build .#nixosConfigurations.rpi3.config.system.build.sdImage

Note on the kernel. This flake tracks nixos-hardware, so the linux-rpi kernel can be newer than the binary cache. If the cache does not have the kernel, the build compiles it. Under QEMU emulation on an x86_64 builder, this can take a few hours. To avoid a long build, pin nixos-hardware to a revision whose kernel is in the cache. Add the commit to the flake URL, for example nixos-hardware.url = "github:NixOS/nixos-hardware/<commit>";.

5. Find the image file.

ls result/sd-image/

6. Find the SD card device name. The name is like /dev/sda or /dev/mmcblk0.

lsblk

7. Write the image to the SD card.

CAUTION: The next command erases all data on the target device. Make sure that the device is the SD card, and not a disk. Replace /dev/sdX with the device name from step 6.

sudo dd if=result/sd-image/*.img of=/dev/sdX bs=4M conv=fsync status=progress

8. Boot the board. Insert the SD card into the 3B+, and start it. The XFCE desktop starts and logs in as user pi. The card0 device is present.

Summary

If the 3B+ stops at boot when KMS starts on a recent kernel, examine the v3d node in the device tree. If the node has no clocks property, the firmware DTB is older than the kernel. A one-line overlay is a better fix than clk_ignore_unused or a full DTB change. The complete fix is in the nixpkgs domain. Keep raspberrypifw at the same version as the kernel.

Prove It

2026-05-19T00:00:00Z

I haven't written a line of code in over 5 months now.

At the start of the new paradigm I was reading a lot more code, and I think it was making me better at the craft of coding. I'd see best practices used in languages I was unfamiliar with to solve a problem that I had articulated. I was reading code where I understood the intent and I was working backwards to understand the implementation. A few months in I started to trust the generated code more. The sense that I was sharpening the craft of writing code gave way to the sense that I was losing it.

Now, for many personal and professional projects, I hold a mental model of how all the pieces fit together, but it's not grounded in having read the actual code. It's grounded in the conversations I've had about how the system works. Sometimes that understanding has diverged from reality, either because I misunderstood something or because a question I asked got answered incorrectly.

It feels like I've stepped up the management chain: less time writing code, more time articulating what I want clearly enough, more time in conversations about what got built. But I don't think the core of the work has changed that much.

Designing Things

If I'm honest I was never a great software engineer, it was always a means to an end. I began my career in R&D where I was mostly following my curiosity and testing if an idea worked, and code was the tool I used to do that. Through working with some brilliant mentors and being humbled in numerous code reviews I eventually learned a little more of the craft of coding. I now sometimes get handed research code that needs to be moved to production and feel a pang of nostalgia as I'm trying to figure out where to add the error handling.

Most of the architecture work I've done has been around answering questions. In most companies those questions start with money:

"How much will it cost to run this new model?"

and then break down into smaller sub-questions:

"What compression do we need to get X many video frames from Y cameras to be decoded on a server with Z CPUs?"

"How many GPUs do we need to process X many video frames?"

"What is the optimal batch size and model instance count for this model architecture on this model of GPU?"

Answering them gives you the raw data you need to make decisions about how to build a system. Running experiments to answer these questions is probably how I spend >80% of my time when doing architecture work. There is of course other work involved, but these experiments have some of the largest impact on the final architecture of a system. Most of the code written to answer these experiments is thrown away, but the knowledge gained from writing them is retained. I've worked on greenfield projects where we spent a few months running these types of experiments and then only spent a week or two to build the system. When done well the systems that resulted from this process were minimal & beautiful.

Prove why a design decision is correct, don't speculate.

As far as I can tell this hasn't changed under the new paradigm, the work is still figuring out what questions we need to ask and running the experiments to get the answers. Code is now cheaper to write and throw away, we can run more experiments quicker and hopefully iterate to something better.

The other side of the coin with code being cheaper to write is I rarely see code being removed. Problems are solved with speculative additions. End-to-end tests & performance metrics are often harder to write (especially any that involve humans in the loop), but with wide-ranging additions being so cheap to make, it's more important than ever to have them. Otherwise your systems will balloon in size and complexity and become harder to reason about.

I don't know how to review PRs anymore. You open the diff and see ten thousand green lines added to an already complicated system. New functionality, new abstractions, new dependencies. The code might work, but the harder question is whether it should exist at all, and how do you prove that?

In a pipeline with a subjective quality measure, a media processing chain, an AI model, anything where the output is "does this feel right," measuring the impact of a change is hard. Even objective metrics get hard when the end-to-end tests aren't in place, or when running them needs a human in the loop, or physical hardware, or both. The change in front of you might be a real improvement, might be neutral, might be a regression that no one notices for three weeks.

What's the end-to-end impact of this change? What metrics are you using to measure that? What's your sample size? Is the test you're pointing me at actually exercising the thing you changed, or just the thing you added? You need to be both a data scientist and a research engineer now, designing the experiment that proves the change earns its place, and rigorously measuring the result.

Prove why additions are needed, don't speculate.

When I was first told "every line of code you write is a piece of technical debt that you're adding to the system" it crystallized a lot of the frustrations I'd had with my own work and pushed me to build simpler systems. Systems that solved the immediate problems and didn't speculate about future problems. The new paradigm is challenging this for me in strange ways. I'm still trying to build for the problem in front of me, but code feels so cheap.

I recently trained a MIDI generating LLM as a side project. I'd written it in Python, then spent a few hours porting it to run in the browser with WebAssembly, and then to C++ so I could run it on an STM32 microcontroller with a neural accelerator. Each port unlocked a different way of interacting with the thing I'd made. The browser version let anyone with a web browser play with it without costing me any compute. The embedded version opened the possibility of a dedicated hardware synthesizer. Two wildly different product directions, both trivial to explore.

Probably one of them, maybe both, I'll never touch again. In the old framing that's three weekends spent on dead-end ports, code I've taken on the maintenance burden of. In the new paradigm it's cheap exploration, code that exists and doesn't matter.

The ability to try an idea, fail quickly, and pivot is faster than ever, and I think what's actually changed is where the discipline lives. It's not in writing less code. It's in deleting more of it. Pruning your git tree so that your context window doesn't fill up with dead ends and experiments. Proving that each addition is valuable and measurably improves your system.

Debugging Things

I started my career in the broadcast industry where once or twice a year I'd work on some kind of live production. Snakes of cables would wind their way from a stage to a cramped port-a-cabin around the back of the venue. It would be filled with the fan noise of some experimental broadcast system whirring away in a server rack. There would be a huddle of engineers standing around broadcast monitors and computer screens frantically debugging things as the clock counted down. We'd have to be ready to capture what was happening on stage when it started happening. No ifs, buts, or maybes.

It left me with a taste for a good SEV. You have to bring calm, focused, methodical problem solving into a stressful situation. You have to act as an information filter, sorting facts from assumptions, organizing information as it comes in and using that to form hypotheses about how a system might be broken. Testing those hypotheses and integrating your findings back into the pool of facts you're using to synthesize new ones. I love a good Agatha Christie mystery and this tickles the same part of my brain that loves an unraveling mystery, the amassing of proof that lets you reach a conclusion.

The new paradigm is both a blessing and a curse to debugging.

The curse is that Claude presents facts and assumptions with the same confidence. You read a line of reasoning, it sounds right, and you don't always notice the assumption the chain rests on is a guess about how the code behaves. The chain builds on it, you build on the chain, and before you know it you're going in circles with no sense of where the wrong turn was. The way I find out is usually by interrogating the model about why it tried something, and watching the justification dissolve.

The defence I've landed on is not very subtle. Give it everything. All the logs, all the error messages, screenshots of metrics graphs, anything concrete about how the system is behaving. It eats context fast and triggers compaction more often than I'd like, but it makes it harder for an assumption to slip into the chain and pass itself off as a fact. When you ask why a decision was made you can ask Claude to point to the data the decision rests on. I find myself building quick tools to make this easier, throwaway Python scripts that produce spectrograms of audio data, anything that turns the system's behavior into something inspectable.

Over the 2025 holidays when it felt like the new paradigm began to take hold I was debugging the firmware for a synth engine I'd been working on, one of my last hand-written pieces of code. I was seeing glitches in the audio output on my oscilloscope, and I couldn't figure out why. It was one of those problems that was pulling the joy from the work. Out of a mix of frustration and curiosity I hooked a debug probe onto the RP2040, plugged my oscilloscope into my LAN so I could pull screenshots from it over the network, and pointed Claude Code at it.

I watched as my code got rewritten, the lights on my debug probe flashed as the code was loaded onto the circuit board, and the oscilloscope made a clicking noise as it captured a screenshot of the waveform. This cycle repeated a few times as I sat watching it. Unceremoniously the problem was solved. The synth engine worked. What might've taken me hours of frustration at best, or joined the pile of abandoned projects at worst, was solved. My focus was back on the parts that felt fun.

I think this worked because I'd built a loop that could be iterated on. I'd articulated the end state, remove the glitch that periodically drops the output to zero. I'd given the model the tools to make changes, the code and the debug probe. And I'd given it a way to measure success, the oscilloscope screenshots. It was harder for Claude to make assumptions about what does and doesn't work when after each change it could see the impact.

Concluding Things

I'm in the process of changing jobs, and there's something wonderful about calling old colleagues to ask them to be references. I get to check in with some of the smartest people I know and catch up about how their personal and professional lives are going. There's electricity in the air. Everyone is figuring out how to do the work in this new paradigm. There's less cynicism than I expected, and more excitement. People have been telling me about experimental projects that used to need management approval getting finished in a lazy afternoon and already shipping. About the personal project they had shelved being picked back up and revisited through this new lens.

I'll be moving back to a startup from the relative comfort of a large organization. It seems like a mad time to be doing it. The tech sector is up in the air, and I have a job that should weather the storm for at least a few more years. But the pull of getting to play in this new paradigm in an environment where my work can have such a direct impact on the success or failure of a company is incredibly alluring. That live production energy, the feeling of being cramped in a port-a-cabin with smart people solving problems to a deadline.

The craft of my work has been changed forever. The work itself hasn't changed. Gather data, hypothesize, prove it, build, ship.

Getting the Kingst LA2016 Logic Analyzer Working on Linux with Sigrok

2026-01-17T00:00:00Z

Here's how I got the Kingst LA2016 logic analyzer working on Linux with the open-source sigrok/PulseView software.

The Problem

When you first plug in the LA2016 and try to scan for devices with sigrok, you'll likely see something like this:

$ sigrok-cli --scan
sr: resource: Failed to open resource 'kingst-la-01a2.fw'
sr: kingst-la2016: MCU firmware upload failed.
The following devices were found:
demo - Demo device with 13 channels: D0 D1 D2 D3 D4 D5 D6 D7 A0 A1 A2 A3 A4

Or possibly it won't show up at all:

sigrok-cli --scan
The following devices were found:
demo - Demo device with 13 channels: D0 D1 D2 D3 D4 D5 D6 D7 A0 A1 A2 A3 A4

Two issues here:

Old sigrok version - The Kingst LA2016 driver was added to libsigrok relatively recently. The version in Ubuntu/Debian repositories (0.5.2) is too old.
Missing firmware - The LA2016 needs firmware uploaded to its MCU and FPGA each time it's connected. This firmware isn't open source and must be extracted from Kingst's official software.

Here's how to fix both.

Step 1: Get the Nightly Sigrok Builds

Grab the nightly AppImages directly from sigrok.org:

cd ~/Software  # or wherever you keep things
mkdir logic-analyzer && cd logic-analyzer

wget https://sigrok.org/download/binary/pulseview/pulseview-NIGHTLY-x86_64-release.AppImage
wget https://sigrok.org/download/binary/sigrok-cli/sigrok-cli-NIGHTLY-x86_64-release.AppImage
chmod +x *.AppImage

These contain a much newer libsigrok with full Kingst support.

Step 2: Download the Kingst Linux Software

Download KingstVIS for Linux from: https://www.qdkingst.com/en/download

tar -xzf KingstVIS_v3.6.5.tar.gz

Step 3: Extract the Firmware

Clone the sigrok-util repository, which contains the extraction script:

git clone https://github.com/sigrok/sigrok-util.git

Now run the extractor against the Linux binary:

python3 sigrok-util/firmware/kingst-la/sigrok-fwextract-kingst-la2016 KingstVIS/KingstVIS

You should see output like:

resource fwusb/fw01A2, file kingst-la-01a2.fw, size 5430, checksum 720551a9
resource fwfpga/LA2016, file kingst-la2016-fpga.bitstream, size 178542, checksum 20694ff1
...

The script extracts firmware for the entire Kingst product line. For the LA2016, you need kingst-la-01a2.fw and kingst-la2016-fpga.bitstream.

Step 4: Install the Firmware

Copy the firmware files where sigrok can find them:

sudo mkdir /usr/share/sigrok-firmware
sudo cp kingst-la*.fw /usr/share/sigrok-firmware/
sudo cp kingst-la*-fpga.bitstream /usr/share/sigrok-firmware/

Step 5: Set Up Permissions

Create a udev rule so you don't need root to access the device:

sudo tee /etc/udev/rules.d/60-kingst.rules << 'EOF'
# Kingst Logic Analyzers
SUBSYSTEM=="usb", ATTR{idVendor}=="77a1", ATTR{idProduct}=="01a2", MODE="0666", GROUP="plugdev"
EOF

sudo udevadm control --reload-rules
sudo udevadm trigger

Unplug and replug your LA2016.

Step 6: Verify It Works

./sigrok-cli-NIGHTLY-x86_64-release.AppImage --scan

You should now see:

The following devices were found:
kingst-la2016 - Kingst LA2016 with 16 channels: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Launch PulseView:

./pulseview-NIGHTLY-x86_64-release.AppImage

Select the Kingst LA2016 from the device dropdown and you're ready to capture.

Quick Capture Test

From the command line, capture 1000 samples at 1 MHz:

./sigrok-cli-NIGHTLY-x86_64-release.AppImage -d kingst-la2016 --config samplerate=1M --samples 1000 -O ascii

Troubleshooting

"Cannot open device" or permission denied

Check lsusb | grep 77a1 to confirm the device is connected
Verify udev rules: cat /etc/udev/rules.d/60-kingst.rules
Make sure you replugged the device after adding rules

"Failed to open resource" errors

Firmware files aren't where sigrok expects them
Try SIGROK_FIRMWARE_DIR=/path/to/firmware ./pulseview-NIGHTLY-x86_64.AppImage

Device detected but capture fails

Try a lower sample rate first (1 MHz)
Check USB connection - use a good cable and preferably USB 3.0 port

Tested with Kingst LA2016, KingstVIS v3.6.5, and sigrok nightly builds from January 2026.