libgpiod<\/code> (the modern GPIO API), which makes the resulting code highly portable. <\/p>\n\n\n\nI asked my friend Claude to summarize my findings in the blog post below.<\/p>\n\n\n\n![\"\"](\"https:\/\/blog.shahada.abubakar.net\/wp-content\/uploads\/2026\/06\/IMG_20260627_234159-1024x1024.jpg\")
<\/figure>\n\n\n\n
\n\n\n\nSometimes you want a handful of GPIO lines on a regular PC \u2014 to drive an LED, read a button, bit-bang a sensor, or wire up a hobby KVM \u2014 without buying a dedicated USB-GPIO chip. It turns out a Raspberry Pi Pico (the ~$4 RP2040 board) can do exactly that, and the lines show up as a normal gpiochip<\/code> device that libgpiod<\/code> manages just like any other GPIO controller.<\/p>\n\n\n\nThis post walks through the whole thing on a Debian 13 (trixie) desktop: how the trick works, how to build and flash the firmware, how to build the kernel drivers Debian no longer ships, and finally how to blink the Pico’s onboard LED through libgpiod<\/code>.<\/p>\n\n\n\nThe problem: a Pico is not a gpiochip<\/h2>\n\n\n\n
libgpiod<\/code> is just userspace tooling on top of the Linux kernel’s GPIO character-device interface \u2014 the \/dev\/gpiochipN<\/code> nodes. Those nodes are created by kernel drivers<\/em>. A bare Pico is a microcontroller running its own firmware; the host kernel has no idea its pins exist, so nothing appears and there’s nothing for libgpiod<\/code> to talk to.<\/p>\n\n\n\nTo make the Pico’s lines manageable by libgpiod<\/code>, we need a kernel driver on the PC that exposes them as a gpiochip<\/code>. We’re not going to write one. Instead we’ll make the Pico impersonate a device that already has a mainline kernel driver<\/em>.<\/p>\n\n\n\nHow the solution works: the DLN-2 disguise<\/h2>\n\n\n\n
The Diolan DLN-2<\/a> is a commercial USB-to-I2C\/SPI\/GPIO adapter. Crucially, Linux has shipped mainline drivers for it since kernel 3.18 \u2014 a small family of modules:<\/p>\n\n\n\n\ndln2<\/code> \u2014 the MFD (multi-function device) core that talks the USB protocol<\/li>\n\n\n\ngpio-dln2<\/code> \u2014 registers the GPIO lines as a gpiochip<\/code><\/li>\n\n\n\ni2c-dln2<\/code> \u2014 registers an I2C adapter (\/dev\/i2c-N<\/code>)<\/li>\n\n\n\nspi-dln2<\/code> \u2014 registers an SPI controller<\/li>\n\n\n\ndln2-adc<\/code> \u2014 exposes the ADC through the IIO subsystem<\/li>\n<\/ul>\n\n\n\nSo if the Pico speaks the DLN-2 USB protocol, the kernel’s existing dln2<\/code> stack binds to it and we get a real gpiochip<\/code> for free. That’s exactly what notro’s pico-usb-io-board<\/code><\/a> firmware does: it turns the Pico into a USB I\/O board implementing the DLN-2 protocol (plus two CDC UARTs as a bonus).<\/p>\n\n\n\nThe full data path looks like this:<\/p>\n\n\n\n
your program\n \u2502\n libgpiod (userspace)\n \u2502\n \/dev\/gpiochipN\n \u2502\n gpio-dln2 \u2500\u2500\u2510\n i2c-dln2 \u251c\u2500 kernel modules\n spi-dln2 \u2500\u2500\u2518\n \u2502\n dln2 (MFD core)\n \u2502 USB\n \u25bc\n Raspberry Pi Pico\n running pico-usb-io-board firmware\n (speaks the DLN-2 protocol)<\/code><\/pre>\n\n\n\nTwo wrinkles make this a little more involved than “flash and go,” and they’re the reason for most of this post:<\/p>\n\n\n\n
\n- The firmware needs building.<\/strong> notro’s repo was archived in January 2025 and is pinned to an old Pico SDK, so it no longer compiles against a current toolchain. We’ll use the
tao-j<\/code> fork<\/a>, whose key commit updates the bundled pico-sdk<\/code> to 2.2.0 and fixes the resulting compile errors. (It changes nothing about runtime behavior \u2014 same protocol, same USB ID, same kernel contract.)<\/li>\n\n\n\n- Debian 13 dropped the drivers.<\/strong> trixie’s stock kernel no longer builds the DLN-2 modules. We’ll build them ourselves with DKMS so they survive kernel upgrades.<\/li>\n<\/ol>\n\n\n\n
One honest caveat before we start: this is GPIO over USB<\/em>. It’s great for setting outputs, reading inputs, and catching button\/edge events, but USB round-trip latency means it is not<\/strong> suitable for microsecond-accurate timing or fast bit-banging. For that you’d write Pico-side firmware to handle the timing-critical part locally.<\/p>\n\n\n\nWhat you’ll need<\/h2>\n\n\n\n\n- A Raspberry Pi Pico (RP2040). The steps target the original Pico; a Pico 2 \/ RP2350 is possible but needs extra board-config work not covered here.<\/li>\n\n\n\n
- A Debian 13 (trixie) desktop, kernel
6.12.x<\/code> (this post was written against 6.12.94+deb13-amd64<\/code>).<\/li>\n\n\n\n- A USB cable and the Pico’s BOOTSEL button.<\/li>\n\n\n\n
- Root access on the PC.<\/li>\n<\/ul>\n\n\n\n
\n\n\n\nPart 1 \u2014 Build the firmware and flash it<\/h2>\n\n\n\n1.1 Install the build toolchain<\/h3>\n\n\n\n
The Pico SDK cross-compiles with the ARM bare-metal toolchain and builds a couple of native host tools along the way, so you need both:<\/p>\n\n\n\n
sudo apt update\nsudo apt install git cmake build-essential python3 \\\n gcc-arm-none-eabi libnewlib-arm-none-eabi libstdc++-arm-none-eabi-newlib<\/code><\/pre>\n\n\n\n1.2 Clone the fork (with submodules)<\/h3>\n\n\n\n
pico-sdk<\/code> is a git submodule<\/strong> of the project, and the SDK has its own submodules (TinyUSB). A recursive clone pulls everything \u2014 this is the single most common thing people get wrong:<\/p>\n\n\n\ngit clone --recurse-submodules https:\/\/github.com\/tao-j\/pico-usb-io-board.git\ncd pico-usb-io-board<\/code><\/pre>\n\n\n\nIf you ever forget the flag, fix it with:<\/p>\n\n\n\n
git submodule update --init --recursive<\/code><\/pre>\n\n\n\n1.3 Build<\/h3>\n\n\n\n
The project wraps the normal CMake flow in a script:<\/p>\n\n\n\n
.\/build.sh<\/code><\/pre>\n\n\n\n(You can set BUILD_DIR<\/code> to redirect the build output elsewhere.) When it finishes, find the firmware image:<\/p>\n\n\n\nfind . -name '*.uf2'<\/code><\/pre>\n\n\n\nThat .uf2<\/code> is what you flash.<\/p>\n\n\n\n1.4 Flash via BOOTSEL<\/h3>\n\n\n\n
The Pico’s ROM bootloader presents itself as a USB mass-storage drive, so flashing is just a file copy \u2014 no special tool required:<\/p>\n\n\n\n
\n- Unplug the Pico.<\/li>\n\n\n\n
- Press and hold the BOOTSEL button<\/strong>.<\/li>\n\n\n\n
- While holding it, plug the Pico into the PC.<\/li>\n\n\n\n
- Release BOOTSEL once a drive named
RPI-RP2<\/code><\/strong> appears.<\/li>\n\n\n\n- Copy the firmware onto it:<\/li>\n<\/ol>\n\n\n\n
cp .\/build\/pico-usb-io-board.uf2 \/media\/$USER\/RPI-RP2\/ # adjust path to your .uf2\nsync<\/code><\/pre>\n\n\n\nThe Pico reboots automatically as the copy completes, the drive disappears, and it comes back running the firmware. Confirm it enumerated:<\/p>\n\n\n\n
lsusb | grep 1d50:6170<\/code><\/pre>\n\n\n\nYou should see the device at USB ID 1d50:6170<\/code>. (That’s an Openmoko FOSS product ID the firmware uses \u2014 remember it, because it matters in Part 3.)<\/p>\n\n\n\n
\n\n\n\nPart 2 \u2014 Build the dln2 kernel drivers for Debian 13<\/h2>\n\n\n\n
At this point the Pico is on the bus, but nothing binds to it. If you try to load the driver:<\/p>\n\n\n\n
# modprobe -b dln2\nmodprobe: FATAL: Module dln2 not found in directory \/lib\/modules\/6.12.94+deb13-amd64<\/code><\/pre>\n\n\n\nThis isn’t a missing package \u2014 it’s a config choice. Debian trixie trimmed a number of modules that earlier releases shipped, and the DLN-2 family is in that set. Confirm it on your machine:<\/p>\n\n\n\n
grep -E 'DLN2' \/boot\/config-$(uname -r)<\/code><\/pre>\n\n\n\nIf you get # CONFIG_MFD_DLN2 is not set<\/code> or no output at all, the modules simply weren’t built. The good news: the driver sources are mainline and self-contained, so we can compile just those five files against our installed kernel headers and wrap them in DKMS so they auto-rebuild on every kernel update.<\/p>\n\n\n\n2.1 Install DKMS, headers, and kernel source<\/h3>\n\n\n\nsudo apt install dkms build-essential linux-headers-$(uname -r) linux-source-6.12<\/code><\/pre>\n\n\n\n2.2 Stage the driver source under \/usr\/src<\/h3>\n\n\n\n
DKMS requires the source to live permanently in \/usr\/src\/<name>-<version>\/<\/code>, since it re-reads it on every rebuild. Extract the five driver files there:<\/p>\n\n\n\nsudo mkdir -p \/usr\/src\/dln2-1.0\ncd \/usr\/src\/dln2-1.0\nsudo tar xf \/usr\/src\/linux-source-6.12.tar.xz --wildcards --strip-components=4 \\\n '*\/drivers\/mfd\/dln2.c' \\\n '*\/drivers\/gpio\/gpio-dln2.c' \\\n '*\/drivers\/i2c\/busses\/i2c-dln2.c' \\\n '*\/drivers\/spi\/spi-dln2.c' \\\n '*\/drivers\/iio\/adc\/dln2-adc.c'<\/code><\/pre>\n\n\n\nConfirm you ended up with five flat .c<\/code> files:<\/p>\n\n\n\nls \/usr\/src\/dln2-1.0\n# dln2-adc.c dln2.c gpio-dln2.c i2c-dln2.c spi-dln2.c<\/code><\/pre>\n\n\n\nThe --strip-components=4<\/code> drops the *\/drivers\/<subsys>\/<\/code> path prefixes so the files land flat. If your tar<\/code> puts them in subdirectories instead, just move them up:<\/p>\n\n\n\nsudo find . -name '*.c' -exec mv -t . {} +\nsudo rm -rf drivers<\/code><\/pre>\n\n\n\nYou do not<\/strong> need dln2.h<\/code> \u2014 it ships in linux-headers<\/code> as include\/linux\/mfd\/dln2.h<\/code> and resolves at build time.<\/p>\n\n\n\n2.3 Add the Makefile and dkms.conf<\/h3>\n\n\n\nsudo tee \/usr\/src\/dln2-1.0\/Makefile >\/dev\/null <<'EOF'\nobj-m += dln2.o gpio-dln2.o i2c-dln2.o spi-dln2.o dln2-adc.o\nEOF<\/code><\/pre>\n\n\n\nsudo tee \/usr\/src\/dln2-1.0\/dkms.conf >\/dev\/null <<'EOF'\nPACKAGE_NAME=\"dln2\"\nPACKAGE_VERSION=\"1.0\"\nAUTOINSTALL=\"yes\"\n\nMAKE[0]=\"make -C ${kernel_source_dir} M=${dkms_tree}\/${PACKAGE_NAME}\/${PACKAGE_VERSION}\/build modules\"\nCLEAN=\"make -C ${kernel_source_dir} M=${dkms_tree}\/${PACKAGE_NAME}\/${PACKAGE_VERSION}\/build clean\"\n\nBUILT_MODULE_NAME[0]=\"dln2\"\nBUILT_MODULE_NAME[1]=\"gpio-dln2\"\nBUILT_MODULE_NAME[2]=\"i2c-dln2\"\nBUILT_MODULE_NAME[3]=\"spi-dln2\"\nBUILT_MODULE_NAME[4]=\"dln2-adc\"\n\nDEST_MODULE_LOCATION[0]=\"\/updates\/dkms\"\nDEST_MODULE_LOCATION[1]=\"\/updates\/dkms\"\nDEST_MODULE_LOCATION[2]=\"\/updates\/dkms\"\nDEST_MODULE_LOCATION[3]=\"\/updates\/dkms\"\nDEST_MODULE_LOCATION[4]=\"\/updates\/dkms\"\nEOF<\/code><\/pre>\n\n\n\nAUTOINSTALL=\"yes\"<\/code> is the line that makes DKMS rebuild against future kernels automatically. The DEST_MODULE_LOCATION<\/code> entries are effectively forced to \/updates\/dkms<\/code> by modern DKMS but still have to be present.<\/p>\n\n\n\n2.4 Register, build, install<\/h3>\n\n\n\nsudo dkms add -m dln2 -v 1.0\nsudo dkms build -m dln2 -v 1.0\nsudo dkms install -m dln2 -v 1.0<\/code><\/pre>\n\n\n\nVerify and load:<\/p>\n\n\n\n
dkms status dln2 # should report: installed\nsudo modprobe dln2 # should now succeed<\/code><\/pre>\n\n\n\n\nSecure Boot note:<\/strong> if Secure Boot is enabled (mokutil --sb-state<\/code> says enabled), unsigned out-of-tree modules won’t load. Enroll a Machine Owner Key (mokutil --import<\/code>, reboot to confirm) and configure DKMS signing so each build is signed. If Secure Boot is disabled, ignore this.<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\nPart 3 \u2014 Bind the driver to the Pico<\/h2>\n\n\n\n
Loading dln2<\/code> still doesn’t grab the Pico, for a subtle reason: the firmware advertises USB ID 1d50:6170<\/code>, but the in-kernel dln2<\/code> driver only matches Diolan’s real ID. So we have to tell the driver to also accept our ID, via a udev rule that loads the module and writes the ID to the driver’s new_id<\/code>:<\/p>\n\n\n\nsudo tee \/etc\/udev\/rules.d\/40-usb-dln2.rules >\/dev\/null <<'EOF'\nACTION==\"add\", SUBSYSTEM==\"usb\", \\\n ATTR{idVendor}==\"1d50\", ATTR{idProduct}==\"6170\", \\\n RUN+=\"\/sbin\/modprobe -b dln2\"\n\nACTION==\"add\", SUBSYSTEM==\"drivers\", ENV{DEVPATH}==\"\/bus\/usb\/drivers\/dln2\", \\\n ATTR{new_id}=\"1d50 6170 ff\"\nEOF\n\nsudo udevadm control --reload<\/code><\/pre>\n\n\n\nNow replug the Pico and check:<\/p>\n\n\n\n
gpiodetect<\/code><\/pre>\n\n\n\nYou should see something like:<\/p>\n\n\n\n
gpiochip0 [INTC1056:00] (473 lines)\ngpiochip1 [dln2] (29 lines)<\/code><\/pre>\n\n\n\ngpiochip1 [dln2]<\/code> is your Pico, now a first-class GPIO controller on the system.<\/p>\n\n\n\n
\n\n\n\nPart 4 \u2014 Demonstration: light the onboard LED<\/h2>\n\n\n\n
The Pico’s onboard LED is wired to GPIO 25<\/strong>, and on this firmware GPIO 25 is “sticky” \u2014 it holds its state after the controlling process exits, which makes it a perfect test pin.<\/p>\n\n\n\nA note on libgpiod v1 vs v2<\/h3>\n\n\n\n
Debian 13 ships libgpiod v2<\/strong>, whose command-line syntax differs from the v1 examples you’ll find all over the web. Two changes trip people up:<\/p>\n\n\n\n\n- The chip is passed with
-c<\/code>, not as a positional argument: gpioset -c <chip> <line>=<value><\/code>.<\/li>\n\n\n\n- That
-c<\/code> value is the chip’s device name or path<\/strong> (gpiochip1<\/code> \/ \/dev\/gpiochip1<\/code>), not<\/strong> the label in brackets (dln2<\/code>). Passing the label gives cannot find GPIO chip character device 'dln2'<\/code>.<\/li>\n<\/ul>\n\n\n\nSo the literal command is:<\/p>\n\n\n\n
gpioset -c gpiochip1 25=1<\/code><\/pre>\n\n\n\n\u2026and the LED lights up.<\/p>\n\n\n\n
Do it the robust way<\/h3>\n\n\n\n
The chip number<\/em> isn’t stable \u2014 gpiochip1<\/code> today might enumerate as gpiochip2<\/code> after a reboot or replug, depending on ordering against the host’s own controllers. Don’t hardcode it. Resolve the chip by its dln2<\/code> label instead:<\/p>\n\n\n\nchip=$(gpiodetect | awk '\/\\[dln2\\]\/{print $1}')\n\ngpioset -c \"$chip\" 25=1 # LED on\ngpioset -c \"$chip\" 25=0 # LED off<\/code><\/pre>\n\n\n\nThat always finds the Pico whatever number it landed on.<\/p>\n\n\n\n
Reading and watching pins<\/h3>\n\n\n\n
The same -c<\/code> pattern applies to the rest of the toolset:<\/p>\n\n\n\ngpioget -c \"$chip\" 12 # read an input pin\ngpiomon -c \"$chip\" 12 # watch for edge events<\/code><\/pre>\n\n\n\nOne behavioral gotcha: in v2, gpioset<\/code> exits immediately by default and releases the line. GPIO 25 holds its value because it’s sticky, but on a normal output pin releasing the line drops it back to default. To hold an ordinary output, keep the process alive:<\/p>\n\n\n\ngpioset -c \"$chip\" -t0 12=1 # hold 12 high until Ctrl-C<\/code><\/pre>\n\n\n\nPin caveats<\/h3>\n\n\n\n
A few pins behave specially on this firmware: GPIO 23 and 24 aren’t on the Pico header and will error; GPIO 4 and 5 get claimed as I2C pins, and GPIO 17 as SPI chip-select, if those sub-drivers load. If you want 4, 5, or 17 as plain GPIO, prevent i2c-dln2<\/code> \/ spi-dln2<\/code> from loading.<\/p>\n\n\n\n
\n\n\n\nWrapping up<\/h2>\n\n\n\n
With three pieces in place \u2014 the DLN-2-speaking firmware on the Pico, the DKMS-built dln2<\/code> kernel modules, and the udev rule that binds them \u2014 a $4 microcontroller becomes a genuine libgpiod<\/code>-managed GPIO controller on your Debian desktop. Because the kernel sees a standard gpiochip<\/code>, everything downstream just works: the gpio*<\/code> CLI tools, the C\/C++\/Python libgpiod<\/code> bindings, and any software that already speaks to GPIO character devices. You also get an I2C adapter, an SPI controller, an ADC, and two UARTs from the same firmware as a bonus.<\/p>\n\n\n\nThe DKMS wrapper means a kernel upgrade won’t silently break your setup \u2014 DKMS rebuilds the modules automatically, and dkms status<\/code> flags it if a future kernel ever needs refreshed source. Just keep the USB-over-latency limitation in mind, and this is a remarkably cheap and flexible way to get real GPIO onto a PC.<\/p>\n\n\n\nCredits<\/h3>\n\n\n\n\n- notro\/pico-usb-io-board<\/a> \u2014 the original DLN-2 firmware for the Pico.<\/li>\n\n\n\n
- tao-j\/pico-usb-io-board<\/a> \u2014 the fork that keeps it building against current Pico SDK (2.2.0).<\/li>\n\n\n\n
- The DLN-2 kernel drivers are mainline Linux, originally contributed by Octavian Purdila, Daniel Baluta, and Laurentiu Palcu.<\/li>\n<\/ul>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
When developing for embedded Linux, I prefer to do the heavy lifting on my desktop PC and port the code over later. However, a common roadblock is that most desktops lack native GPIO support....<\/p>\n","protected":false},"author":1,"featured_media":9603,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[116],"tags":[],"class_list":["post-9598","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-linux"],"_links":{"self":[{"href":"https:\/\/blog.shahada.abubakar.net\/index.php?rest_route=\/wp\/v2\/posts\/9598","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.shahada.abubakar.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.shahada.abubakar.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.shahada.abubakar.net\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.shahada.abubakar.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=9598"}],"version-history":[{"count":4,"href":"https:\/\/blog.shahada.abubakar.net\/index.php?rest_route=\/wp\/v2\/posts\/9598\/revisions"}],"predecessor-version":[{"id":9604,"href":"https:\/\/blog.shahada.abubakar.net\/index.php?rest_route=\/wp\/v2\/posts\/9598\/revisions\/9604"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.shahada.abubakar.net\/index.php?rest_route=\/wp\/v2\/media\/9603"}],"wp:attachment":[{"href":"https:\/\/blog.shahada.abubakar.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=9598"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.shahada.abubakar.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=9598"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.shahada.abubakar.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=9598"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}