I've just updated today from a very old custom build of OpenWRT 14 to the most recent LEDE version (17.01) on my R7500v1 (at least I think it is v1 - bought in feb 2015).
The second wifi chip is not working. So 2.4 Ghz works but 5.0 Ghz not. Does this work for anybody with a R7500v1? Or did I missed something to install or configure (I've installed the factory.img from here using tftp method)?
I've also tried to restart the kernel module with this outcome:
root@LEDE:~# rmmod ath10k_pci
root@LEDE:~# rmmod ath10k_core
root@LEDE:~# modprobe ath10k_core
root@LEDE:~# modprobe ath10k_pci
root@LEDE:~# dmesg |tail -30
[ 17.078582] ipq806x-gmac-dwmac 37400000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[ 17.078706] br-lan: port 1(eth1) entered forwarding state
[ 17.086535] br-lan: port 1(eth1) entered forwarding state
[ 17.092189] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
[ 17.098216] ipq806x-gmac-dwmac 37200000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[ 19.077957] br-lan: port 1(eth1) entered forwarding state
[ 159.589049] ath10k_pci 0001:01:00.0: disabling bus mastering
[ 181.272218] ath10k_pci 0001:01:00.0: enabling bus mastering
[ 181.276261] ath10k_pci 0001:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
[ 181.440893] ath10k_pci 0001:01:00.0: Direct firmware load for ath10k/pre-cal-pci-0001:01:00.0.bin failed with error -2
[ 181.440928] ath10k_pci 0001:01:00.0: Falling back to user helper
[ 181.483263] firmware ath10k!pre-cal-pci-0001:01:00.0.bin: firmware_loading_store: map pages failed
[ 181.483467] ath10k_pci 0001:01:00.0: Direct firmware load for ath10k/cal-pci-0001:01:00.0.bin failed with error -2
[ 181.491228] ath10k_pci 0001:01:00.0: Falling back to user helper
[ 181.543832] firmware ath10k!cal-pci-0001:01:00.0.bin: firmware_loading_store: map pages failed
[ 181.544416] ath10k_pci 0001:01:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000
[ 181.551455] ath10k_pci 0001:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
[ 181.561726] ath10k_pci 0001:01:00.0: firmware ver 10.2.4-1.0-00016 api 5 features no-p2p,raw-mode,mfp crc32 0c5668f8
[ 181.624582] ath10k_pci 0001:01:00.0: board id is not exist in otp, ignore it
[ 181.624658] ath10k_pci 0001:01:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
[ 181.630772] ath10k_pci 0001:01:00.0: Falling back to user helper
[ 181.661140] firmware ath10k!QCA988X!hw2.0!board-2.bin: firmware_loading_store: map pages failed
[ 181.661372] ath10k_pci 0001:01:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
[ 182.883543] ath10k_pci 0001:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1
[ 182.965425] ath: EEPROM regdomain: 0x0
[ 182.965447] ath: EEPROM indicates default country code should be used
[ 182.965462] ath: doing EEPROM country->regdmn map search
[ 182.965481] ath: country maps to regdmn code: 0x3a
[ 182.965497] ath: Country alpha2 being used: US
[ 182.965510] ath: Regpair used: 0x3a
I'm not sure what this means but I find the board configuration (I guess it's the configuration) here:
it wasn't, at least not in upstream OpenWrt/ LEDE?
I think this is still the current state of affairs, maybe you'll find some vendor driver in some router's GPL tarball featuring this chipset, but integrating that into netifd and hostapd is another question.
I know it worked before I had a custom build from version 14 where both networks worked. but I read enough now to understand why I always lost my connection
I will think about a new router with better customization abilities.
If it was supported in vanilla LEDE/ OpenWrt in the past (and not some third party community build or the vendor's OpenWrt based SDK), it should still work - but in case of Quantenna QT3840BC I can't imagine the former to be true.
Sounds like the custom build you had had the Quantenna stuff integrated. There seems little chance of it being supported upstream since it appears to have been an ad hoc solution to get AC to market quicker.
As the 5GHz support is still something expected in future releases of Openwrt, could someone share compiled version of existing driver with small how-to for installation? It is described on R7500 v1 hardware page:
qtnfmac in the mainline kernel has gained support for the QSR1000 family of chipsets recently, at least since yesterday's mac80211 update in master, you might be able to get it working (that would still require quite some work on your side, creating a package, providing the firmware, checking if you need to provide something equivalent to precal/ ART, etc. - but at least it should be possible now, a driver exists.)
@slh I appreciate your answer but unfortunately I'm just plain user with very little knowledge of internals and I won't be able to do what you've mentioned
The problem just is that the remaining steps can only be done by someone with the device on their desk - and it will most likely require quite some tinkering as well.
I have the device but I don't have required skills. So, what is the situation with the driver mentioned on hardware page? My understanding is that it is confirmed that it works (say, "unofficially") -- does it require similar effort you mentioned or just compilation of the code? I'm not clear about this, I thought that compilation would be enough.
Those driver sources haven't been touched or modified for 3 years now, it's very unlikely (pretty much impossible) that they're even compiling against current kernels. To get them working with more current kernels and the current wireless subsystem would require quite some porting work (no, I've not looked at it in any form of detail, but drivers constantly need to be adapted for changing in-kernel APIs with almost every new kernel version, no activity in three years isn't promising anything good). While they might provide some amount of reference (in terms of how firmwares/ radio calibration/ etc. may have to be supplied), it's probably easier to get qtnfmac with QSR1000 support running in current OpenWrt/ master, using the kernel 5.2 derived mac80211 subsystem and drivers.
--
Personally I've been looking for a Netgear r7500v1 or a ZyXEL NBG6816 (or basically anything cheap from the ipq806x target, which would allow me the freedom of experimenting, without 'breaking' my network (by testing random stuff on my nbg6817) all the time) for a while now, but none have entered my price range for experiments with an unknown outcome yet.
thanks @slh, great explanation! what you say about compilation agrees with what I got on another forum where very experienced person attempted to compile it with no success. and probably that person also understands the efforts required, he recommended to wait for "official" support.
but anyway, if anyone has it working in current Openwrt, please share. hope dies last
Well, getting qtnfmac (with QSR1000 support) compiled and packaged up is the easy part (as a mainline driver, this comes basically for free via backports/ mac80211), the difficult part (betting that the QSR1000 support actually works, which is uncertain) is hooking it all up properly (firmware, calibration data, setup orchestration). Definitely worth a shot though and more sane than working on the old vendor drivers.
