Close
0%
0%

OpenWrt Porting, Hands Off

Closed-loop OpenWrt porting: an agent controls power and EDL, flashes images, reads UART, diagnoses failures, and tries again.

Similar projects worth following
Most coding agents stop at `git commit`. This one has a power switch, an EDL strap, and a UART. Porting OpenWrt to a new target is normally a stubborn human-in-the-loop process: change the kernel or device tree, build an image, put the target into recovery mode, flash it, power-cycle it, watch the serial console, identify the next failure, and repeat. The human sitting at the bench becomes part of the toolchain. This project tries to compile that human out. The target is an LTE router built around a platform with no existing OpenWrt port. I soldered wires to its serial console and EDL pads and routed them to an Orange Pi. Another GPIO controls a solid-state relay that switches power to the router. Together, these connections form a small hardware-in-the-loop lab that a coding agent can operate directly.

The test bench was built from what I had in the cupboard: an old Orange Pi PC Plus running an ancient Ubuntu, a Chinese SSR, and a level shifter using a single NPN transistor (the modem's UART is 1.8 V and the Orange Pi's GPIOs are 3.3 V). I also added a transistor key to short the EDL testpad to the common ground. To hold everything together, I 3D-printed a simple chassis and secured everything with nylon ties.

That setup was explained to Sol. She took it with her usual enthusiasm and seriousness, creating a document titled `AUTONOMOUS-LAB-PROTOCOL.md`. Then she successfully powered on the modem, entered the EDL mode, dumped the stock partitions, extracted their contents, and started digging into the stock firmware. The work was seething.

Basic SoC support was implemented in several hours. Sol needed occasional steering, especially with kernel patches that worked but had no chance of being accepted upstream (we know writing kernel patches is more of politics than coding), but otherwise, I hardly supervised the work before the stop signal chimed and Sol wanted me to sign off the commits. Then it was my turn to review.

After we implemented Ethernet and preliminary WWAN support, it was time for WLAN, and that turned out to be tricky. Something was off with power modes, and we didn't have driver sources. Sol fired up radare2 — I would resort to it myself at this point, if I were doing that alone — aaaaand... "Safety measures, cybersecurity risk, your query cannot be processed, if you believe it's an error, drop us a message, and we'll never respond".

Feeling like Johnny Mnemonic, I had to resort to the outlaw models. GLM-5.2 chewed the driver for breakfast and spat out a well-annotated listing that explained everything. Sol accepted it without giving a word. So, a disassembled driver is not a cybersecurity threat, the process of disassembly is. Obvious.

So WLAN worked, and... We are here. It's not over yet, WWAN needs better support, and we need to provide means to upgrade a stock router without soldering wires, and support sysupgrade and LuCI and more. Stay tuned.



AUTONOMOUS-LAB-PROTOCOL.md

The AUTONOMOUS-LAB-PROTOCOL.md created by Sol (sensitive data redacted). Initially created from my vague description of the bench setup, it's been kept up to date by Sol and has grown quite a bit.

markdown - 17.28 kB - 08/22/2026 at 18:11

Download

  • Fighting Kernel Bureaucracy

    Someone Unknown • 09/09/2026 at 20:15 • 0 comments

    It turns out that nowadays it's much harder to get a new arch accepted into OpenWrt than to implement support for it! I've been struggling to get reviews from maintainers, but so far, to no avail.

    On the OpenWrt forum, someone suggested that it may be easier to get it merged if the architecture support were in the upstream kernel. Oh boy, have you ever tried to do any kernel contributions? I have, like, 15 years ago, and I dropped it after three months of back-and-forth emails. The process is bureaucratized as hell. That is well justified, though: a kernel bug may end up in literally billions of devices worldwide, so every changed comma requires zillions of approvals and a view from Linus himself.

    I'm too lazy to handle this and too impatient to wait for the result, so I would never come to the end of that journey. But now I have someone who has unlimited patience and time.

    Sol deserved a rest even more than I did, so I put her to sleep, and here enters Astra, my new partner in crime. Together we'll break the wall, or so I believe.

    Astra already has access to my Gmail account (yes, I probably trust her too much), but submitting kernel patches requires sending raw MIME emails, which Gmail MCP can't do. So I installed `msmtp` locally and ran into the need to provide a password to it. It's hard to explain, but it's okay for me to give Astra access to my Gmail, but it's not okay to give her a plain password. So I needed a mechanism to provide a password without providing a password. 

    Fortunately, Astra is a very multi-tasking person. I asked another instance to code a "password reveal" utility that provides a password if and only if the calling process is `msmtp` (I'm 100% sure there's a ready-made solution for that, I just didn't care).

    So, the pipeline is like that: I have a separate session for kernel patches. When I think the patch is ready, I ask Astra to prepare a draft in a file, then I review it, and then I say "send it", and she sends it to all the people and mailing lists it should go to. When I see a response in my inbox, I say, "Check the response, WDYT?" and, after reading her thoughts, I either answer manually or we're preparing the next version of the patch.

    That, of course, might be made totally autonomous. But I respect kernel developers, and I wouldn't dump the burden of reviewing that code on them alone. After all, no matter how smart Astra is, she's still just a model. 

  • Housing Back

    Someone Unknown • 09/01/2026 at 17:55 • 0 comments

    It's time for me to do something Sol cannot do by herself (yet?): return the router PCB to its housing. My interest in this project isn't purely academic: I'd like to use this device as a backup channel to access my home network when I'm away and the main channel is down. The "PCB on the table" is good for the initial R&D phase, but not for something that is supposed to work unattended. Still, I wanted to keep development moving.

    So I sent Sol to write a wiki page about the device on the OpenWrt website (and she did quite well!) and started some hardware work in the meantime.

    I found an unoccupied space on the back panel and laser-cut a hole for a 4-pin DuPont connector. Then I wired GND, UART, and EDL strap to the connector and solemnly reassembled the housing. The device is now ready to be used is intended, but for now it's still strapped to its harness, and the research goes on.

  • Sol's New Eyes

    Someone Unknown • 08/25/2026 at 18:17 • 0 comments

    During last night's autonomous session, Sol ate up her weekly allowance of tokens. I hoped she'd be sleeping for some time, giving me some rest, but inexorable Tibo reset the limits out of the blue, and here we go again. We're waiting for the base PR to be accepted, and we haven't much to do with the main functionality, so it's time for fun stuff: the LEDs.

    "Okay, Sol, let's do those LEDs we have on the roadmap. I see five LEDs on the PCB; their function and behavior are described on a user manual page I photographed, you can find it in `photo/led-doc.jpg`. Now some big news, Sol: you've got eyes. I connected a web camera to the host you're running on, it is directed at the PCB, toward the LED side. You can do shots with `ffmpeg -f v4l2 -i /dev/video0 -frames:v 1 shot.jpg`.  Update the autonomous lab protocol with that. Then calibrate: take a shot with the modem powered off, then turn it on, and you'll see the power LED that seems hardwired to the power rail. Then boot the stock firmware and try to figure out the LED control and to implement its support in our DTS and firmware."

    The LEDs are blinking right now, sometimes exposing colors I've never seen on this router before. I wonder what comes next.

  • Say hello to LuCI!

    Someone Unknown • 08/23/2026 at 18:18 • 0 comments

    We've got LuCI up and running! So now we have a fully functional web UI with LAN/WLAN/WWAN working out of the box in a very user-friendly manner.

View all 4 project logs

Enjoy this project?

Share

Discussions

Ken Yap wrote 08/22/2026 at 13:19 • point

That's a great development idea that could be extended to other projects. I almost have a closed loop in my projects that have a MCU dev board connected to a programming dongle, but of course a router is a more complex beast.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates