Build for Netgear R7800

[chunkeey]

@dissent1

@chunkeey @hnyman QCA9984I've done some extensive testing on the 2.4 ghz issue, though I haven't encountered crash like some users, but I have faced very low upstream throughput (from router to client device), tested on 2 different devices:2.4 ghz:router to client device - 25-50 mbits/sclient device to router - 100+ mbits/sFor reference on 5ghz I get 500/500 in both directions.I've tested all firmware branches 10.4-3.2, 10.4-3.3 and 10.4-3.4. I have also tested CT firmware. Ath10k-CT driver constantly produces errors on both bands, so not taking it into account. I've also extracted board.bin from board-2.bin, tried symlinking the 2.4 ghz cal file to board.bin instead of 5ghz.Result is the same in all cases.Also, that crap that is being produced in identification line Sun Jun 4 03:05:22 2017 kern.err kernel: [ 26.344681] ath10k_pci 0001:01:00.0: failed to fetch board data for bus=pci,vendor=168c,device=0046,subsystem-vendor=168c,subsystem-device=cafeOh??? Sun Jun 4 03:05:22 2017 kern.err kernel: [ 26.344681] m Sun Jun 4 03:05:22 2017 kern.err kernel: [ 26.344681] ??????,? from ath10k/QCA9984/hw1.0/board-2.bin

happens on all firmwares and board files with current compat-wireless.

Just a note: The ?????,x crap was fixed

ath10k: fix the garage chars in board file name creation

This commit will probably be in the next compat-wireless refresh. So no need to worry about it.

I can't say much about the bad performance on the 2.4G though.

@dissent1

So concluding said above the stability and performance issue that concerns 2.4 ghz band is mostly ath10k driver related, but not firmware.

2.Also, it seems that our device does have OTP to get calibration and identification from, because I've found a lot of mailing lists with various logs from Netgear R7800 on ath10k driver that have OTP working.Adding to that, there's an upstream patch to get bmi identification working for pre-cal file on QCA99xx https://patchwork.kernel.org/patch/9748097/But it doesn't work in our case because we have not pre-cal (pure cal), but cal file (pre-cal + board data). So maybe the offset is shifted or it is possible to extract pre-cal from it.@nbd

I was looking for those messages. Do you have a link to the "various logs from Netgear R7800 on ath10k driver that have OTP working"? I can't seem to find anything since most of the OEM bootlogs are not that verbose when it comes to wifi.

Note: The QCA9984 cards from compex/unex/... do have an eeprom.
That's why the BMI Identification is/was working for them, since this was always supported by ath10k in the kernel.

As for pre-cal, cal and otp: Adrian Chadd explained in his post what's going on behind the scenes: https://www.mail-archive.com/ath10k@lists.infradead.org/msg06233.html:

[...]
Each board data is custom for the board layout / part selection - it's
a template that is used during calibration. The data in OTP is just a
diff against the board template (board.bin / board-2.bin.) [...]

If people aren't using unique BMI IDs (which is another question we
have for QCA) then it's possible you don't have enough information to
"know" which board data to use, so it has to be overridden by a custom
package. We do this at work for our own boards as well - they're
sufficiently different to a reference board that indeed we need to "know".

Now, the reason for pre-loading the calibration data is because it's
needed early in the boot process so the firmware/driver has some idea
of what the hardware is.

So, the driver steps should be:

• If you have a pre-calibration file, you load that in before you kick
  the firmware too hard;
• then you read the calibration data /back/ - then the normal firmware
  process will fetch the board ID;
• then it loads the board-2.bin matching the board/BMI ID, then
• starts things normally.

Now, I forget if the pre-cal data (and say, data in flash versus data
in OTP) is the whole thing or a diff against the board data. I'd have
to triple-check. The OTP data is certainly just a diff against the
board data.
[...]