The ath9k card on the HAT¶

The bring-up of item 034: an Atheros AR9462 on the Waveshare PCIe to MiniPCIe HAT+ as a third radio for survey and spectral.

The first card, 2026-11-03¶

The HAT on the Pi 5's PCIe connector, its FFC cable as shipped in the HAT's connector and inserted at the Pi with the contacts toward the USB ports; the AR9462 (AR5B22, half-size, sold as Duokon by Qinxiny at Amazon.nl) on the HAT's bracket, two antennas; the HAT's USB cable unplugged. Bootloader 2026/05/11, kernel 6.18.50, sensor-1.

The card never came up: on every boot brcm-pcie 1000110000.pcie: link down, and lspci showed only the RP1 behind the internal controller (0002:01:00.0). The HAT's PWR LED lit red while the Pi was on. Each change below with a boot of its own:

• The external controller came up with status okay and probed on the first boot, before dtparam=pciex1 was set, which the overlay README gives as off by default, and with no HAT EEPROM in the device tree (/proc/device-tree/hat absent). The firmware enabled it from the HAT's pull on PCIE_DET_WAKE, the one way the Raspberry Pi Connector for PCIe gives for a board to ask for a probe: the FFC cable carried that pin and the 5 V, which the connector gives on pins 1 and 2 (1 A in all), before it was reseated.
• The USB test: the card's Bluetooth runs over the HAT's USB cable. In a USB 2 port, usb 1-2 and then usb 3-2 on the other controller, it attached as a low-speed device and failed with device descriptor read/64, error -71 and device not accepting address, then unable to enumerate USB device. Bluetooth over USB is a full-speed device: a pull-up on the line of a low-speed device and the protocol errors are what D+ and D− swapped give, or a contact that fails. A line pulled up means the card's side has power from the slot. No Bluetooth adapter came up and bluetooth.service stayed inactive. The cable was for this test only (rule 1).
• Waveshare lists the RTL8852BE, AX200, AX210 and BE200 as tested, no Atheros card; no report online has an ath9k card working on this HAT or on a Pi 5 through any mini PCIe adapter. One forum reply claims the HAT's FFC cable is made reversed; the one user who tried it saw the HAT's PWR LED and the card's LED go out (OpenWrt forum), and the connector's specification warns that a cable the wrong way round can short the Pi or the board. The cable stays as shipped.

What is left is the card or the PCIe path from the Pi's connector to the slot, the external connector never used before on this Pi.

The second card, 2026-11-04¶

An AR9462 sold as Yosoo (AR5B22, the same seller, Qinxiny) in place of the first card, with the same HAT, FFC cable and antennas and the HAT's USB cable unplugged. Bootloader 2026/05/11, kernel 6.18.50, sensor-1.

It did not come up either. The boot of 20:18 gave brcm-pcie 1000110000.pcie: link down, lspci showed only the RP1 behind the internal controller, and no ath9k module loaded. An install had taken the first card's test lines out of /boot/firmware/linkside.txt, so this boot had no PCIe line at all: the default Gen 2, and the external controller at status okay from the HAT's pull, as on the first card's first boot. Gen 1 was not tried with this card; it made no difference with the first.

A link that does not train comes before any driver, so ath9k plays no part in this yet.

What the two cards rule out, and what they leave:

• CLKREQ#. The external port runs brcm,clkreq-mode safe, read from the Pi's device tree: the binding has the reference clock driven unconditionally there, and pcie-brcmstb.c clears the CLKREQ bits before PERST# goes up and applies the mode only after the link check. A card that leaves CLKREQ# alone should still see a clock. Not measured.
• The 1.5 V of mini PCIe. Waveshare does not say whether the slot carries it, but data sheets of half-size AR9462 cards list one supply, 3.3 V (Advantech AMO-WIFI07E), and the chip has switching regulators of its own. No sheet of the AR5B22 itself turned up. An unlikely cause.
• ath9k on the Pi 5. Not the chip family as such: an AR928X and an AR9580 worked on a Pi 5 through a Pineberry HAT AI! and an M.2 to mini PCIe adapter (first-hand).
• This HAT with Atheros. No report has one working. The only first-hand report of an Atheros card on it is a failure with the same symptom, an AR958x with only the RP1 in lspci, unresolved (OpenWrt forum). A Radxa E25 has it too: an AR5B22 and a QCA6174A without a link where an Intel card came up, no cause given (Radxa forum).

The link training, logged at the boot of 20:51 with pcie_brcmstb.trace_ltssm=1 on the kernel's command line, a parameter built into this kernel: the external port went between Detect.Active and Detect.Quiet in rounds 12 ms apart, 36 events from 23.5 to 95.5 ms after PERST# went up, and never reached Polling. In the same boot the internal port to the RP1 went from Detect.Active to Polling.Active at once and on to L0. The port's state machine runs as it should and looks for a receiver on its transmit pair, and finds none.

So the link fails before any exchange between the two sides, which takes every cause after the first handshake out: a Gen 2 or Gen 1 speed, equalization, a protocol the two do not share. Left are a break in the pair from the Pi to the card, in the FFC cable, its connectors or the HAT, and a card that does not switch its receiver on: no supply on the pins it uses, PERST# not reaching it, or a dead card. Two cards of one seller could both be dead, but the HAT's path is what they share. The trace does not tell these apart.