freifunk-gluon
[ath79][ipq40xx] verify 5GHz on devices using ath10k QCA9888
This a crossreference to an upstream ticket. The nvmem-cell rework caused certain devices to not detect (some of) their 5GHz radios correctly. Specifically devices with a chip requiring QCA9888 firmware (wifi5 wave2). https://github.com/openwrt/openwrt/issues/14541
Affected are likely (untested so far): TP-Link
- EAP225 variants (outdoor for example)
- Archer C58 v1, C59 v1, C6 v2
ZTE MF281
OpenMesh A62
Plasma Cloud PA2200
(and Linksys Velop WHW03 v1/v2, which we were planning on adding, though I haven't noticed the issue on these while we were testing)
Hello,
I'm unable to test my Tp-Link Archer C59 v1 right now, but on OpenWRT 23.05.5 in dmesg I get:
Sat Dec 7 10:14:26 2024 kern.info kernel: [ 16.345023] ath10k 5.15 driver, optimized for CT firmware, probing pci device: 0x56.
Sat Dec 7 10:14:26 2024 kern.info kernel: [ 16.354794] ath10k_pci 0000:00:00.0: enabling device (0000 -> 0002)
Sat Dec 7 10:14:26 2024 kern.info kernel: [ 16.361624] ath10k_pci 0000:00:00.0: pci irq legacy oper_irq_mode 1 irq_mode 0 reset_mode 0
Sat Dec 7 10:14:26 2024 kern.info kernel: [ 18.895374] ath10k_pci 0000:00:00.0: qca9888 hw2.0 target 0x01000000 chip_id 0x00000000 sub 0000:0000
Sat Dec 7 10:14:26 2024 kern.info kernel: [ 18.904962] ath10k_pci 0000:00:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 0
Sat Dec 7 10:14:26 2024 kern.info kernel: [ 18.924148] ath10k_pci 0000:00:00.0: firmware ver 10.4b-ct-9888-fW-13-5ae337bb1 api 5 features mfp,peer-flow-ctrl,txstatus-noack,wmi-10.x-CT,ratemask-CT,regdump-CT,txrate-CT,flush-all-CT,pingpong-CT,ch-regs-CT,nop-CT,set-special-CT,tx-rc-CT,cust-stats-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT,wmi-bcn-rc-CT crc32 59e741e7
Sat Dec 7 10:14:26 2024 kern.info kernel: [ 19.257555] ath10k_pci 0000:00:00.0: Loading BDF type 0
Sat Dec 7 10:14:26 2024 kern.err kernel: [ 19.268512] ath10k_pci 0000:00:00.0: failed to fetch board data for bus=pci,bmi-chip-id=0,bmi-board-id=20 from ath10k/QCA9888/hw2.0/board-2.bin
Sat Dec 7 10:14:26 2024 kern.info kernel: [ 19.486912] ath10k_pci 0000:00:00.0: board_file api 1 bmi_id 0:20 crc32 3f3d8ea0
Sat Dec 7 10:14:26 2024 kern.warn kernel: [ 21.342408] ath10k_pci 0000:00:00.0: 10.4 wmi init: vdevs: 16 peers: 48 tid: 96
Sat Dec 7 10:14:26 2024 kern.warn kernel: [ 21.350217] ath10k_pci 0000:00:00.0: msdu-desc: 2500 skid: 32
Sat Dec 7 10:14:26 2024 kern.info kernel: [ 21.380347] ath10k_pci 0000:00:00.0: wmi print 'P 48/48 V 16 K 144 PH 176 T 186 msdu-desc: 2500 sw-crypt: 0 ct-sta: 0'
Sat Dec 7 10:14:26 2024 kern.info kernel: [ 21.391723] ath10k_pci 0000:00:00.0: wmi print 'free: 114572 iram: 12644 sram: 29508'
Sat Dec 7 10:14:26 2024 kern.info kernel: [ 21.629032] ath10k_pci 0000:00:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file max-sta 32 raw 0 hwcrypto 1
Maybe I should've specified, that this issue is only happening on OpenWrt 24.10 (or gluon main branch)
for one of the devices, Archer C6 v2, it has been solved via https://github.com/openwrt/openwrt/pull/19035 according to the issue comment https://github.com/openwrt/openwrt/issues/14541#issuecomment-2948520338 , it's "only" a matter of someone working on other devices, not magic ?
looks like tp-link eap225-outdoor devices are unaffected. we've tested at least version 3 and it was able to load the boarddata just fine.
@achterin you mentioned on https://github.com/freifunk-gluon/gluon/pull/3587 that c60 v2 was also affected?
maybe we need an updated list on which device is fixed and which is still affected?
@achterin you mentioned on #3587 that c60 v2 was also affected?
maybe we need an updated list on which device is fixed and which is still affected?
yeah, an updated list would be desirable to track the process. at least for the devices included in gluon. i can't say with 100% certainty that other devices are affected, because i dont own any of them. i just went through the openwrt bugreports and tried to provide testing images for people.
these are the devices with existing bugreports:
- TP-Link Archer C59 v1
- TP-Link Archer C60 v2 (not included in gluon)
- TP-Link Archer C60 v3 (not included in gluon)
most likely the Archer C58 v1 will have the same issue. as @moridius was pinged in the pr adding support (back) for this device, maybe he can help here as well.
as already said: the v3 of the EAP225-Outdoor worked without any issues on the last OpenWrt snapshot, so most likely the other version are unaffected as well.
The C59 v1 looks fixed in openwrt-main: https://github.com/openwrt/openwrt/commit/2a44808374497b83edb76b4e384f280546a62dbe
and it also got backported to openwrt-24.10, so next module update will also bring this fix to gluon.
and it also got backported to openwrt-24.10, so next module update will also bring this fix to gluon.
done.
as there's only ONE C58 in the field according to the multi meshviewer map, i suggest to mark C58 as broken and close this issue - i don't think there will be anyone testing and fixing it from gluon side in the future....
funny thing is: its already marked as broken due to 64MB which will oom in almost every scenario. on the other hand: if the second radio is not detected anymore, 64MB should be enough for single-band use xD in all seriousness, i agree with you, add a remark and be done for now.