The router worked. That is the part I keep coming back to. It sat on the shelf doing exactly what a cheap travel router should do: NAT, a DHCP lease, a 2.4GHz radio that reached the far end of the spare room. It had done this without complaint for three years. And then on a quiet Sunday I decided it could be better, which is how most of my hardware disasters begin.
The plan was reasonable on paper. The stock firmware was a vendor build frozen at some kernel from the Obama administration, no WireGuard, no sensible DNS options, an admin panel that loaded like it was being delivered by post. OpenWrt has supported this exact SoC for years. There was a wiki page. There was a sysupgrade image. There was, I told myself, nothing that could go wrong that I had not already done twice before.
the first mistake
The first mistake was trusting the model number on the label. These little boxes get revised constantly and the silkscreen lies. The "v2" on the sticker was, on closer inspection of the flash chip, very much not a v2. Same enclosure, same plastic, completely different SPI flash and a slightly different RAM layout. I found this out the honest way, by flashing the v2 image and watching the power LED settle into a slow, contemplative blink that meant the bootloader had loaded a kernel it did not believe in.
A blinking power LED is not the end of the world. It is, however, the end of the web interface, the end of SSH, and the end of any recovery method that involves the device cooperating. I had bricked it at the application layer but the bootloader was, in principle, still alive underneath. That distinction is the whole game. If U-Boot still boots, you have a way back. You just have to go and find it.
finding the console
So out came the magnifier and the multimeter. There were four unpopulated through-holes near the corner, which on a board like this is almost always the UART. Ground was easy: continuity to the shield. The rest is a short ritual. Power the board, probe each pad against ground with the meter on DC volts, and the one that sits at a steady 3.3V is your VCC (don't connect that one), the one that twitches as the thing tries to boot is TX, and the remaining quiet pad is RX.
I soldered in a four-pin header, mostly because hooking flying leads onto bare pads while a board is live is a good way to short something and turn an annoying afternoon into an expensive one. Then a USB-to-serial adapter, 3.3V logic, TX to RX and RX to TX, ground to ground. Leave the adapter's VCC disconnected; the board has its own power and you do not want two supplies arguing.
picocom -b 115200 /dev/ttyUSB0
115200 8N1 is the usual guess and it was right. The reward for all that squinting was a wall of boot text scrolling past, then the line every recovery hinges on:
Hit any key to stop autoboot: 3
I hit a key. I have never hit a key faster.
the way back
At the U-Boot prompt the device is, briefly, completely yours. The bootloader does not care that the kernel is wrong; it just sits there waiting. From here the recovery is unglamorous. Set the board's IP, set a server IP, point it at a TFTP server on the laptop, and pull the correct image straight into RAM and on into flash.
setenv ipaddr 192.168.1.1
setenv serverip 192.168.1.2
tftpboot 0x80060000 openwrt-correct.bin
The trick most people miss is the address. The load address and the flash offset are specific to the board, and the wiki for the actual hardware revision had them. The ones for the v2 I had been so confident about would have happily written a perfectly good image to the wrong place and bricked it harder. I checked them three times. Then I wrote it, watched the erase-and-program counter tick across the terminal, and power-cycled.
It came up. Real OpenWrt, correct flash layout, a kernel that believed in itself. The whole detour, from "this works fine" to "this works fine again, plus WireGuard," took the better part of four hours for a device that costs less than the soldering iron I used to rescue it.
what i actually took away
I do not regret it, which I appreciate is the sort of thing people say after a bad decision. But the serial header is the point. The flashing was incidental; half the value of these projects is that they force you to learn the recovery path before you need it, and a UART console is the recovery path for almost everything in this class of hardware. Now that the header is soldered in, the next time I do something stupid to it, I am ninety seconds from a prompt instead of four hours from one.
The other lesson, which I will absolutely ignore the next time, is to read the flash chip before you trust the sticker. The enclosure is marketing. The silkscreen is aspiration. The flash chip is the only thing on the board that tells the truth, and it was sitting there the whole time waiting for me to ask it.