Systems · 16 pages
- Overview
- Wi-Fi router
- Smartwatch / fitness tracker
- Drone flight controller
- Drone — IMU & sensor fusion
- Drone — BLDC ESC
- EV charger
- EV charger — power stage
- Smart thermostat
- Automotive ECUASIL
- Automotive — AUTOSAR stack
- Industrial motor drive
- Motor drive — FOC algorithm
- IoT sensor node
- Medical wearable
- Industrial gateway
Wi-Fi router (Wi-Fi 6 consumer)
How a $150 Wi-Fi 6 router is actually built — quad Cortex-A53, dedicated MAC/PHY, NPU offload, OpenWrt. Plus where ASUS, Linksys, GL.iNet differ.
A mid-range consumer Wi-Fi 6 router (AX3000-class, $80–$250 retail) is genuinely one of the most complex pieces of consumer electronics you can hold. It's a small Linux server with multi-radio MIMO transceivers, hardware packet acceleration, and a real-time switching fabric — all behind a plastic case and a web UI that pretends it's just a "router."
At a glance
- Product class
- Wi-Fi 6 (802.11ax) AX3000/AX5400 home router
- Typical SoC
- MediaTek MT7986A / Qualcomm IPQ8074 / Broadcom BCM6750
- Application core
- 4× Cortex-A53 @ 1.4–2.0 GHz
- Architecture
- ARMv8-A, AArch64, NEON
- L1 / L2 cache
- 32 KB I/D L1 per core, 1 MB shared L2
- RAM
- 256 MB – 1 GB DDR4 / DDR3L
- Storage
- 128 MB NAND flash + optional 32 MB NOR (boot)
- OS
- OpenWrt 23.x or vendor-customized Linux 5.x
- Radios
- 802.11ax 4×4 (5/6 GHz) + 802.11ax 2×2 (2.4 GHz)
- Wired ports
- 1× 2.5 GbE WAN, 4× 1 GbE LAN (typical)
- NPU / accelerator
- Vendor packet-processing engine, NAT/QoS offload
- Power
- 8–15 W typical, 24 W peak
- Certifications
- FCC Part 15, CE RED, Wi-Fi Alliance (Wi-Fi 6 certified)
What's inside the SoC
The Cortex-A cluster runs Linux and the control plane. The packet-processing engine is where the magic happens at line rate: every NAT translation, every QoS classification, every wireless-to-Ethernet bridge. Without it, the A53 cluster couldn't sustain 1 Gbps of NAT'd traffic — let alone 2.5 GbE.
The software stack
Power on
│
▼
┌─────────────────────────────────┐
│ Boot ROM (Cortex-A in EL3) │ verifies BL2 signature
└────────────┬────────────────────┘
▼
┌─────────────────────────────────┐
│ BL2 (vendor) │ sets up DDR, loads BL31
└────────────┬────────────────────┘
▼
┌─────────────────────────────────┐
│ BL31 / TF-A (EL3 secure mon.) │ PSCI services
└────────────┬────────────────────┘
▼
┌─────────────────────────────────┐
│ U-Boot (EL2/EL1) │ loads kernel from NAND
└────────────┬────────────────────┘
▼
┌─────────────────────────────────┐
│ Linux kernel 5.x │ ARM64, multi-core
└────────────┬────────────────────┘
▼
┌─────────────────────────────────┐
│ OpenWrt / vendor userspace │ procd, netifd, hostapd, ...
└─────────────────────────────────┘This is the standard ARMv8-A boot chain — see Boot flow & EL levels for the gory details.
Key userspace components
- hostapd / wpad — the Wi-Fi MAC software layer. Handles association, authentication (WPA3-SAE), key management. Talks to the kernel
mac80211subsystem via nl80211. - netifd — OpenWrt's network configuration daemon. Brings interfaces up, configures DHCP, applies firewall.
- firewall4 (nftables) — packet filtering. The slow-path filtering happens here when the NPU can't classify a flow.
- dnsmasq — local DNS + DHCP server.
- uhttpd + LuCI — the web UI you actually use to configure the thing.
- ubus — inter-process RPC bus (think D-Bus, simpler).
Where ARM cores meet the radio
The interesting design choice is how the Cortex-A cluster talks to the Wi-Fi MAC/PHY.
┌────────────────────────────────────────┐
│ Linux kernel │
│ ┌────────────────────────────────┐ │
│ │ cfg80211 / nl80211 (userspace)│ │
│ └─────────────┬──────────────────┘ │
│ ▼ │
│ ┌────────────────────────────────┐ │
│ │ mac80211 (soft MAC layer) │ │
│ └─────────────┬──────────────────┘ │
│ ▼ │
│ ┌────────────────────────────────┐ │
│ │ Vendor driver (e.g. mt76) │ │
│ └─────────────┬──────────────────┘ │
└─────────────────┼──────────────────────┘
│ shared DMA buffers
▼
┌────────────────────────────────────────┐
│ Wi-Fi MAC firmware │
│ (runs on dedicated MCU inside SoC) │
└─────────────────┬──────────────────────┘
▼
┌────────────────────────────────────────┐
│ PHY / RF (analog + DSP) │
└────────────────────────────────────────┘The Wi-Fi MAC's low-latency real-time work (responding to ACKs within microseconds, channel switching, beacon scheduling) runs on a dedicated MCU inside the SoC — often itself an ARM Cortex-M or a vendor-specific core. The Linux driver hands packets to it via DMA-mapped descriptors and signals via doorbell registers. The MAC firmware is opaque to the kernel and is delivered as a binary blob.
This split — Linux for control plane, dedicated MCU for time-critical MAC — is the same pattern you'll see in drone flight controllers (control loop on M7, telemetry on host) and automotive ECUs (Cortex-R for safety, M cores for I/O).
Fast path vs slow path
The single most important number on a router's spec sheet is NAT throughput, and the only way to hit gigabit-plus NAT is to NOT route every packet through Linux's IP stack.
┌────────────────────────────┐
│ Slow path (Linux) │ first packet of a flow
│ - netfilter rules │ ↓
│ - IPsec, complex QoS │ classified by NPU
│ - flow learning │
└─────────────┬──────────────┘
▼
┌────────────────────────────┐
│ NPU flow table (hardware) │ subsequent packets
│ - 5-tuple → action │ matched + forwarded
│ - NAT translation │ in hardware, zero CPU
│ - QoS marking │
└────────────────────────────┘The first packet of a flow goes to Linux, gets classified, and triggers the kernel to push a flow descriptor into the NPU's flow table. Every subsequent packet matches that descriptor and is forwarded entirely in hardware — never touching the A53 cores.
This is why a router with a single 1.4 GHz Cortex-A53 can route 2.5 Gbps. The CPU only sees ~1% of packets.
Power and thermals
A Wi-Fi 6 router is always-on, but it doesn't run at full tilt all the time:
- Idle: ~6 W. CPU at scaling-min frequency (300 MHz), one radio chain awake, NPU mostly idle.
- Single client streaming 4K: ~9 W. One radio chain active, NPU forwarding.
- Peak (multi-client AX traffic): 12–18 W. All radio chains + amplifiers, NPU + CPU active.
The CPU is rarely the dominant power draw. The RF power amplifiers consume most of the budget. A 4×4 5 GHz radio at FCC-max power can draw 5–8 W just for the PAs.
Thermal design is fan-less but uses metal heat spreaders bonded to the SoC and to the PA shields. Routers in plastic-only enclosures (small/cheap ones) thermal-throttle and you'll see Wi-Fi speeds drop after ~10 minutes of sustained load.
Memory and storage layout
SPI-NOR flash (8–32 MB):
0x00000000 - 0x00040000 Boot ROM patches, vendor BL2
0x00040000 - 0x00080000 U-Boot
0x00080000 - 0x000A0000 U-Boot env + factory MAC/calibration
0x000A0000 - end Recovery firmware (rare; usually on NAND)
NAND flash (128 MB – 1 GB):
/ (UBI) rootfs (SquashFS, read-only)
/overlay (UBI) user changes (OverlayFS)
/tmp (tmpfs) logs, runtime state
/reserve factory-locked partition (do not touch)
DDR4 RAM (256 MB – 1 GB):
Linux kernel + userspace
Wi-Fi DMA descriptor rings (carved out, kernel-pinned)
NPU flow-table memory (shared with kernel)The factory MAC/calibration partition is critical and per-device-unique. Never overwrite it during firmware flashing — that's how you brick a router permanently. OpenWrt's sysupgrade knows to preserve it; manual dd doesn't.
Real products
| Product | SoC | Cortex-A53 cluster | Notes |
|---|---|---|---|
| Xiaomi AX3000 (Redmi AX6S) | MediaTek MT7621 + MT7905/MT7975 | 2× MIPS 1004Kc | Older MIPS-based; still very popular in flashing community |
| GL.iNet Flint 2 (GL-MT6000) | MediaTek MT7986A | 4× Cortex-A53 @ 2.0 GHz | OpenWrt-first, ships unlocked |
| ASUS RT-AX86U / AX88U | Broadcom BCM4908 | 4× Cortex-A53 @ 1.8 GHz | Strong stock firmware (Asuswrt) |
| Linksys WRT3200ACM (legacy) | Marvell Armada 385 | 2× Cortex-A9 @ 1.8 GHz | Wi-Fi 5 era; archetype of OpenWrt-friendly design |
| TP-Link Archer AX6000 | Broadcom BCM4908 | 4× Cortex-A53 @ 1.8 GHz | Mass-market, stock fw only |
| Banana Pi BPI-R3 | MediaTek MT7986A | 4× Cortex-A53 @ 2.0 GHz | Bare board for makers/hackers |
For maximum hackability, look for OpenWrt-first vendors (GL.iNet, Banana Pi). For polish + warranty, the big consumer brands (ASUS, TP-Link) deliver but lock down the firmware.
What makes routers "feel fast"
A router with 5 Gbps theoretical bandwidth that feels sluggish on a web UI has one of these problems:
- Crappy stock firmware that runs heavy daemons (cloud telemetry, mesh management, parental controls all written in Lua) on the A53s. Hits CPU at "I just want to load the admin page" time.
- Bug in NPU driver that drops connections to slow path under specific traffic mixes. Suddenly the A53s are doing all the routing.
- Insufficient RAM, causing OOM-kills of hostapd at moments of heavy multicast (mDNS storms from many smart-home devices).
Stock firmware quality varies enormously between vendors. The hardware in $200 routers is mostly fine — the firmware is where the differences live.
See also
- Cortex-A overview — what makes it different from Cortex-M.
- Boot flow & EL levels — the BL1/BL2/BL31/U-Boot chain.
- MMU & paging — required for Linux.
- DMA — how the Wi-Fi MAC hands packets to the kernel.
- TrustZone — used for secure boot.
- OpenWrt project (external) — the open-source firmware most routers can flash.