Cleanup is done — everything is now in a repo:
https://github.com/Gameplayer-1-8/openwrt_mrx80_v2
It contains a sysupgrade and an initramfs image, the full source changes against OpenWrt main (ce16dd8, kernel 6.12.100), hardware documentation, and the tools I used to pull the device data apart.
What works
Both radios, DSA switch with real wan/lan1/lan2/lan3 ports, LuCI, sysupgrade, boots from NAND on its own, serial console in and out. Per-unit WiFi calibration is read from 0:art at runtime, so no hand-injected caldata.
Roughly 50 MB RAM free with both radios up. 5 GHz tops out around 350 Mbit with both cores saturated — mainline ath11k has no NSS offload for IPQ5018.
Correction to my first post
I have to walk back what I wrote at the top of this thread. Memory was never the problem on this device. There were no OOM kills, and the box idles at ~50 MB available with both radios loaded. The 911-ath11k-reduce-dma-buffer patch is in the repo, but it is inherited, not the fix — I ended up raising its ring sizes again, because DP_TX_COMP_RING_SIZE also caps in-flight TX descriptors and cutting it hurts throughput for no benefit here.
What actually looked like a memory problem was a boot that silently stopped right after kmodloader: done. That turned out to be nothing at all: with no network configured that is simply the last line a successful boot prints, and console input was dead so the board looked hung. I chased that for a long time. If you are debugging this SoC, verify the box is actually stuck before assuming it is — a heartbeat script writing to /dev/console settles it in one boot.
The five things that actually cost time
Each verified on hardware, all documented in the repo README.
1. NAND ECC strength is 4, not 8. U-Boot prints it: ECC:4-bit. Decoding at <8> returns data that looks perfectly clean — stable across reads, no ECC errors logged — but with silently flipped bits. It corrupted caldata read from 0:art so the WiFi firmware asserted in phyrf_bdf.c:605, produced mtdsplit: error occured while reading from "rootfs", and made tp_data report "both volume tables are corrupted" when the volume was in fact intact. Get this right before writing anything to NAND.
2. The RTL8367S reset is GPIO 26, and U-Boot hides the problem. U-Boot only runs rtk_switch_init when it falls through to its prompt. On the plain autoboot path into NAND it never touches the switch, so the chip stays in reset and MDIO reads return 0xffff forever. Every TFTP test goes through the prompt, so the switch works there and fails only from flash. Do not be misled by the OEM DTB's //soc/mdio@90000 phy-reset-gpio = <0x06 0x27 0x00> (GPIO 39) — that is the MDIO/PHY reset, a different pin for a different job.
3. The CPU link must be 1G SGMII, not 2.5G HSGMII. U-Boot sets the switch to 2.5G and the OEM runs it that way, but 3.125 GBaud is not reliable on this board:
|
2.5G HSGMII |
1G SGMII |
| ping 32 B ×50 |
6 % loss |
0 % |
| ping 1400 B DF ×50 |
4–13 % loss |
0 % |
| 20 × HTTP GET |
8–11 / 20 |
20 / 20 |
The loss is invisible in every counter (errs 0 drop 0 fifo 0 on the conduit) because frames mangled on the SerDes are dropped by the PCS layer before the MAC sees a frame. 1 Gbit is ample here.
4. DEVICE_DTS_CONFIG must be config@mp02.1 to match this board's machid 0x8040000. A manual bootm works with any name because U-Boot falls back to the FIT default, so it looks cosmetic — but bootipq selects by machid, prints Config not available and drops into the OEM HTTP recovery mode.
5. No pinctrl on &blsp1_uart1, or console RX dies while TX keeps working (printk busy-polls, so the port looks healthy while not one RX interrupt arrives). The mux value is not wrong; inheriting U-Boot's pin setup is what works.
Caveats before anyone flashes this
- The MAC address is hard-coded in the DTS for my unit. Yours is in the
tp_data UBI volume, file default-mac, six raw bytes. The README explains how to read it. Reading it at runtime is the main thing still missing for this to be upstream-ready.
- LED-to-port mapping and which socket is WAN come from the reference fork and the GPL sources and are not physically confirmed.
- The ath11k ring sizes shipped here are not throughput-tested.
Recovery is always available: sysupgrade never touches 0:SBL1 or 0:APPSBL, so U-Boot survives and you can always TFTP an initramfs back.