Looking in file ipq8071-ax3600.dtsi, i see #include ipq8074.dtsi, but can't see ipq8074.dtsi file in anywhere, is there anything wrong here ?
oh, it in build_dir, i'm just search in target/ dir. thanks
1 Like
I'm really pleased with this device running OpenWRT! Thanks to all involved.
Even on a baseline build of robimarko's branch - without adding NSS offload - I'm seeing a genuine 70MB/sec iperf3 from local wireless to far-side wired on an AX3600-AX3600 WDS link through two solid walls. The 4x4 AX link is indicating PHY rates of ~1400 at 18dBm and up to ~2000 at 26dBm. I wasn't expecting high MCS at > 18dBm based on the 5GHz PA specification (https://www.qorvo.com/products/p/QPF4588, via the teardown at https://www.acwifi.net/9478.html)
2x2 2.4GHz 'N' clients also seem to get better PHY rates than they did on my old Archer C7 at the same indicated power levels. I imagine it is a combination of improved RF/analog chipset design, the AX3600 RF PAs and antennae.
One not so good thing is that the ath10k IoT radio0 seems to perform badly at 2.4GHz. I don't just mean the 1x1 spec, but that actual carrier power as seen by a client is maybe 10-20dBm down from what another AP in the same location with same indicated TX power would give. PHY rates suffer at moderate distances, and radio0 is effectively useless as a 2.4GHz AP on both my AX3600s. On a positive note, radio0 does work well at 5GHz. Even 1x1 AC 433mbps is a useful additional channel.
Does the original Xiaomi firmware only run radio0 in 5GHz band? I thought maybe they cost-reduced the hardware, but the teardown shows full separate 2.4GHz/5GHz RF paths out of radio0. Maybe there is a hardware design bug or 5GHz-only antenna?
I saw that the 2.4GHz PA has a enable pin (https://www.nxp.com/docs/en/data-sheet/BGU7224.pdf) which changes the path by about 20dB. I'll check the DTS to see if there are any obvious GPIO candidates...
2 Likes
@dspalu32
the BGU7224 is a pre-amplifier for the receive chain, not a power amplifier for the transmit chain, according to its data sheet (first sentence General Description).
Ah, right you are! I missed the context completely. I was wondering why all references were to dB gain rather than dBm. That's a dead end then.
For the sake of posterity:
I did audit robimarko's branch GPIO DTS vs. the original Xiaomi(?) (Xiaomi AX3600 DTS), and a live state dump from the original Xiaomi (Adding OpenWrt support for Xiaomi AX3600 - #214 by gmzhuo)
- gpio16: was (2mA, PD), now (8mA, none). Doesn't matter as used for 'qpic' NAND?
- gpio21: was (8mA), now (2mA). Doesn't matter: net blue LED, presumably via FET
- gpio22: was (8mA), now (2mA). Doesn't matter: net yellow LED, presumably via FET
- gpio25: was (PU), now (PD). An orphan input in the MDIO group of the original DTS. I had hoped this might be a hacky tie-high PA enable.
- gpio34: was (8mA), now 12mA. Doesn't matter: reset button
- gpio38 - gpio41: was (PU), now (none). Doesn't matter now: SPI controller (unpopulated SPI flash, I think I saw elsewhere? Adding OpenWrt support for Xiaomi AX3600 - #51 by robimarko, Adding OpenWrt support for Xiaomi AX3600 - #157 by juppin)
- gpio44: was (PU), now (PD). An orphan input in the MDIO group of the original DTS. I had hoped this might be a hacky tie-high PA enable.
- gpio46 - gpio49: was (function1, none) now (function0, PD). Doesn't matter: f1 = hsuart, presumably some other debug UART. The board UART we use is on gpio23/24
- gpio51: was (8mA), now (2mA). Doesn't matter: IoT antenna LED, presumably via FET
- gpio64 - gpio66: was (function1, 6mA) now (function0, 2mA). Sounded promising, but looks like a debug left-over. Named "btcoex" in the original DTS, and f1 is the PTA (Packet Traffic Arbitration) peripheral on the SoC. Presumably this has no context on an AP without BT. ...and wouldn't have applied to the PCI ath10k anyway.
4 Likes
Hm, it could be that they have not limited the channel range properly in the BDF for the IoT radio.
I have seen that before, where they would limit the channels further in SW instead of doing it properly and
then it advertises channels that are outside of the designed amplifier range.
I think this patch solves memory leak.302-ath11k-tx-mgmt-cleanup-fix.patch
after a day available memory just stays around 30% (I only have one wireless client)
and about encap offload I think we are gonna need to wait for the new firmware. They mentioned firmware WLAN.HK.2.5.0.1-00844-QCAHKSWPL-1 supports sending native wifi EAPOL frames in
ethernet mode.
3 Likes
Next time I'm back on Xiaomi firmware (TFTP recovery), I'll see what iw shows for the 1x1 radio and scan. It's still useful even for 2.4GHz, just not as an AP with range. It works well enough overall not to lock it off; disappointing but not broken!
1 Like
@castiel652 I am trying that patch and I am still seeing a leak on AX9000.
Its around 13MB over an hour of operation, after 1:30h its over 30MB of leak.
If you can apply that patch to AX3600-5.10-restart, I am happy to test it as well. Can it be, that the patch only solves the leak with t a specific firmware version? @castiel652 which WLAN FW did you tested with?
1 Like
Where exactly do you see that memory leak?
I'm using my AX9000 as a daily driver since the last week and i don't see a memory leak at all.
I would also be happy to test the memleak patch in my AX3600s, as it could solve the wifi starting acting weird after approx. 1 week (e.g., the browser in my computer starts showing occasional warnings of either broken SSL/TLS or connections resets). That issue is easily "solved" with a router reboot, and that's how I've been daily driving my AX3600s. The broken SSL/TLS usually happens without NSS, while the connections resets happen with NSS -- either way, the issues usually start within the same timeframe (only on the ath11k radio).
Can't really comment much about the IoT radio other than it works (i.e., my washer uses the 2.4Ghz legacy rates and it works).
Interested in testing the patch as well, but I'm new to applying patches to the build system. Is the following procedure correct?
- Place
302-ath11k-tx-mgmt-cleanup-fix.patchinpackage/kernel/mac80211/patches/ath11k/ make package/kernel/mac80211/refresh V=s- make clean and make
If so, the patch doesn't have any effect on my AX3600. Free memory drops to ~20MB after 30 minutes of uptime.
@kirdes Easily, just enable a 2G ath11k radio and leave it running.
If you have traffic periodically it will trigger cleanup and due to a 1G of RAM you most likely don't ever run completely out of RAM, but it's still leaking.
@foxium Yeah, that is right.
2 Likes
Oh well I checked and I didn't delete the other QCA patch when I was testing.
It's actually 143-ath11k-disabling-credit-flow-for-ath11k.patch.
With it available memory goes down when WiFi is up but just stays around 30%.
Without it it just keeps going lower.
But you guys said the patch doesn't really fix the leak so I am out of idea now.
OK, so we need to test 143-ath11k-disabling-credit-flow-for-ath11k.patch instead of 302-ath11k-tx-mgmt-cleanup-fix.patch , or both?
try 143-ath11k-disabling-credit-flow-for-ath11k.patch
I ended up applying both. Running the test now.
MOD: I dont think it fixed anything, I am at 90MB free memory after 1h 32m uptime with 2 clients.
Is it only caused by wifi traffic or any traffic?
How about as temporary measure to generate traffic try running Transmission daemon and connect it to Ubuntu Desktop torrent
Let Transmission download a part file then set download speed limit to zero and leave it to seed the part file
1 Like