A couple weeks ago we said the Radxa Dragon Q6A was on the way as a second reference platform for Headwaters. As of this week it is no longer on the way. The image builds, the board boots unattended, the plain Waveshare RS485 CAN HAT brings up can0 at 500 kbit/s, and the full Headwaters stack runs on it the same way it runs on the CM5. Both targets are now real.
The price story, with actual numbers
The reason the Q6A target exists is cost. Now that the build is verified, the numbers are easy to compare.
A 4 GB Dragon Q6A is roughly fifteen dollars more than a 4 GB Raspberry Pi CM5 at current US street prices. That premium is the entire downside, and it disappears the moment you account for what you do not have to buy alongside the Q6A.
- No carrier board. The CM5 is a compute module. It does nothing on its own. You need a base board with an NVMe slot, power input, headers, and connectors before it can run anything. The Q6A is a single-board computer with all of that on-module already, including the NVMe slot. You still bring your own M.2 drive on either path, but on the Q6A you do not buy a carrier to host it.
- Cheaper CAN hat. The CM5 build uses the Waveshare RS485 CAN HAT (B), which carries a built-in 12 V to 5 V buck and the input protection. The Q6A accepts 12 V directly and pairs with the plain Waveshare RS485 CAN HAT, the small low-cost MCP2515 board with the 12 MHz oscillator. Same CAN bus, same job, noticeably less money.
Net effect: the fifteen-dollar premium on the module is more than offset by deleting a carrier board and stepping down to the cheaper hat. The Q6A Headwaters lands cheaper than the CM5 Headwaters, with fewer parts to source and assemble.
What it took to make first boot reliable
The interesting engineering this round was not the application stack. The application stack is identical between the two platforms. The interesting work was getting the Q6A to boot unattended, every time, with the CAN hat installed.
The hat itself is fine. The catch is that the Q6A's debug UART is muxed to header pins 8 and 10, and the RX line on pin 10 has no on-board bias resistor. Once the Waveshare hat sits on the header, EMI from the MCP2515's SPI clock capacitively couples enough noise into that floating RX line for the SoC's UART block to decode phantom serial bytes. The stock Radxa bootloader reads the console during its autoboot wait window, sees those phantoms as keystrokes, and traps the board at the boot menu waiting for a human.
Three lighter fixes were tried first and ruled out. Setting UEFI variables from Linux did not stick because the SPI NOR firmware re-seeds them on every boot. A hardware pull-up on pin 10 would have worked, but Headwaters is a no-modifications-required build. Disabling the kernel-side console did nothing because the trap is in firmware before the kernel ever runs.
The fix that landed is a small patch to the upstream embloader source that short-circuits the menu when the loader timeout is set to zero. The patched embloader.efi is built from upstream tag 0.4 during the image build, installed onto the EFI system partition, and verified by sha256 before the image is finalized. Boards flashed with the new image come up with no keypress, no serial console, no babysitter. With or without the hat installed.
The CAN bring-up itself
The plain Waveshare hat we target uses a 12 MHz crystal feeding the MCP2515. The earlier device-tree overlay was carrying an 8 MHz value left over from a different variant. That was a one-line fix, but it would have been a fairly confusing day for anyone tracing a bus that ran at the wrong bitrate. The overlay is now correct and lives in the repo.
Bring-up is also race-free. The earlier service used a path condition that fired before the MCP2515 SPI driver finished binding, so on cold boot the service would skip silently and can0 would never come up. The new headwaters-can0-up.sh polls for the netdev with a thirty-second deadline, configures it at 500 kbit/s when it appears, and exits cleanly if the hat is not installed. No boot stall on the bench, no race in production.
Both targets stay supported. That is the point.
If you were waiting to see whether the Q6A path was real before pulling the trigger on parts, it is real. If you already have a CM5 in a drawer, nothing about that build has changed. The two images come out of the same Docker artifacts and the same map tiles. Pick the one you can actually source today.
The reason both targets are supported, even though the Q6A wins on price, is sourcing resilience. Two SoC vendors. Two board vendors. One Headwaters. When one SKU goes allocation-only or quietly EOL, you take the other path and keep going.
Where to find it
The image build, the patched embloader, the device-tree overlay, the first-boot services, and the operator setup guide all live in the RADXAQ6A directory of the Headwaters repository. The README covers what is disabled and why. The SETUP guide walks through EDL mode, flashing the SPI NOR firmware, flashing the OS, and first boot end to end.
Two paths to the same Headwaters. Pick the one that is on the shelf.