Ok, there's no ath10k calibration data there whatsoever. Probably the embedded PCI-E card has the calibration data stored on-board. Can you just
Then check if 5 GHz WLAN works and whether it has a sensible MAC-address.
(not near my nbg6716 right now but)
without the pre-cal files the ath10k modules refuse to load.
without the 11-ath10k-caldata no (pre-)cal file
ergo no 5Ghz?
or put differently how to check mac etc, without the ath10k modules loaded?
It doesn't load because the (nonexistent) calibration data from flash is bogus and crashes the firmware. If you remove the files I listed, the on-board calibration data is tried next, and it just might work after reboot.
Well... with the bogus calibration data in the pre-cal file the 5Ghz works just fine.
without that file present the firmware crashes. cfr. the logs i posted earlier. e.g.
I recall that bogus pre-calibration data can't crash the firmware. It runs, but probably uncalibrated.
you are probably correct.
so preferably we figure out where/how to get proper calibration data.
or figure out how to get the hotplug script to create the pre-cal file instead (but let it run uncalibrated)
or maybe use this option with ath10k: skip_otp=y (haven't tried it yet, but i'm assuming it'll run uncalibrated as well)
There are basically four ways to store calibration data:
If you buy a QCA988x card from Compex (I have one), option 1 is used. NBG6616 and Archer C7 v2 (both of which I also have) use option 3. NBG6716 obviously uses some other option, I'd guess 1 or 2, since 4 is quite rare. Following my previous instructions will tell us which it is. Pre-cal is only used with board-2.bin file, so that is not the correct way to do this.
I stand corrected... i guess it must be option 1.
removed (pre)-cal files
removed hotplug ath10k script
rebooted
5Ghz is up with a valid Zyxel MAC address
Perfect! I'll send a patch.
great, looking forward to seeing the nbg6716's 5Ghz fixed in an official release.
many thanks for looking into this.
As Lede 17.01.5 is around the corner, can someone please apply the patch by malaakso to the lede-17.01 branch?
18.06 is around the corner, and "beta" builds are already up.
You'd have to check the source code to see if the patch has been applied or if the issue still exists.
The patch only got applied to master and is included in the openwrt-18.06 branch but is still missing in lede-17.01 branch which will be used for the 17.01.5 release. So yes, this issue still exists in the lede-17.01 branch, which is the reason i asked for a cherry-pick to fix this issue for the 17.01.5 release.
Ask in the mailing list. Devs don't care otherwise.
Did that, devs don't care either.
You could try again on the mailing list, asking if there speaks anything against including this patch in 17.01.5.
BTW: Any special reason why you need it in 17.01.5 (and why waiting for 18.06 is no option for you)?
I asked one of the devs on IRC to look into it for 17.01.5.
Never said i need it 
The thought behind that is the following: there is a bug which affects the 17.01-branch and there is a planned maintenance release coming up. In my opinion thats enough reason to backport a known working patch even though i am not in the need for it to be applied onto 17.01. Maybe there are projects out there that use 17.01 as their base and therefore benefit from this fix.
this same bug has resurfaced in the 21 and the 22 series - probably while migrating to ath79 from ar71xx
Behaviour and fix are the same, wrong caldata preventing the firmware load. : https://forum.openwrt.org/t/5ghz-wifi-doesn-t-work-on-zyxel-nbg6716-after-upgrading-to-22-03-0/136699/5?u=undef
Could you apply (your same patch) to ath79, so it can be included in the next release?
thanks!