Hello Adrian, during the CPE210v2 bringup it was discovered that the CPE210 has the wrong bootstrap option set for it's 25 MHz reference clock. Because of this, the device was originally not even booting with ar71xx.
On ath79, the reference clock is not detected based on the bootstrap option, but set by the DTS. The twist however is the ath9k driver, whose OF patch still reads this register. [0] On ar71xx, the platform data was always set to true for the QCA9533 [1] So you can try to force the settings for 25MHz reference clock for all QCA953x regardless of the bootstrap settings to keep the behavior in line with ar71xx. I have no device to verify this, however it's a good candidate for the root cause. ;) [0] https://github.com/openwrt/openwrt/blob/master/package/kernel/mac80211/patches/ath/552-ahb_of.patch#L237 [1] https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/patches-4.14/620-MIPS-ath79-add-support-for-QCA953x-SoC.patch#L260 Best wishes David On 11/5/19 3:05 PM, Adrian Schmutzler wrote: > Hi, > > for quite some time already we are struggling with broken WiFi on some > TP-Link CPE devices having QCA9533 rev. 2 (QCA9533-BL3A SOC) in common. > > I'd be happy on some help here, since I've exhausted my debugging > capabilities. > > > 1. Symptoms: WiFi looks up on the device, some TX traffic is shown in > ifconfig, RX is zero. The AP cannot be found by clients. "iw dev wlan0 scan" > returns nothing. > > 2. Affected devices: TP-Link CPE210 v2/v3, CPE220 v3 (all QCA9533 rev. 2?); > no other QCA9533 devices known to be affected (specific to CPE or to QCA9533 > rev. 2?) > > 3. For a certain model, there are devices which are working correctly and > others which don't. There is no known indicator to find out whether a device > works or not. The state of a device does not change as far as we know (always > working or never working). > > 4. So far, only 2.4 GHZ-only devices were affected > > 5. There is no diagnostic output that indicates a WiFi problem. dmesg/logread > look normal, there is no difference when compared between working and > not-working devices (despite RX=0/scan as stated above) > > 6. The problem seems to be present from the beginning (device support > patches), it just has been overlooked since it's not occurring on every > device. > > 7. The ar71xx firmware for all devices works flawlessly, so it is an > ath79-specific problem. > > > Other findings that might be connected or not: > > a. On ath79 phy0 uses irq=11/irq=12 and on ar71xx irq=47. eth0 uses irq=4 on > both targets. > > b. The following gpio is only found on ar71xx: gpio-495 ( |ath9k-phy0 ) in lo > > > I currently own a CPE210v2 with the bug and can test suggestions (if I'm > capable of implementing them). > There is a device support PR for the CPE220 v3 suffering from the same > problem: https://github.com/openwrt/openwrt/pull/2514 > > Despite, further reading may be found in forum discussion and bug report: > https://bugs.openwrt.org/index.php?do=details&task_id=2333 > https://bugs.openwrt.org/index.php?do=details&task_id=2478 > https://forum.openwrt.org/t/ath79-tp-link-cpe210-v2-0-wifi-not-working/40666 > > Initial support for CPE210 v2/v3 was done by me and bluelineXY, both already > involved in the discussion. ;-) > > Thanks for any hints! > > Adrian > > > _______________________________________________ > openwrt-devel mailing list > [email protected] > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
