Hi David, thanks for your response.
To me it looks like qca953x already uses 25 MHz clock, or am I looking at the wrong value: https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/dts/qca953x.dtsi#L27 Best Adrian On 5 November 2019 16:46:59 CET, David Bauer <m...@david-bauer.net> wrote: >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 >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel >>
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel