QCA4019: calibration files and board files
sven.eckelmann at open-mesh.com
Tue Jan 17 03:54:52 PST 2017
I've just tested LEDE-IPQ40XX  after the official open QSDK 1.1.3  was
not able to boot on an ap.dk01.1-c1-like device. This seemed to work
exceptionally well (the device basically worked after the first build) but I
got a little suspicious when looking at the code which it uses for getting the
wifi devices up and running.
Spoiler: My actual questions are at the end of the mail.
Info about how wifi device (cal) is initialized in LEDE-IPQ40xx
The device by default has two things (please correct me when I missed
* two QCA4019 EEPROM sections (12064 bytes each) in the 0:ART partition
- starting at 4096 -> will be stored as ath10k/pre-cal-ahb-a000000.wifi.bin
- starting at 20480 -> will be stored as ath10k/pre-cal-ahb-a800000.wifi.bin
* board-2.bin file from https://github.com/kvalo/ath10k-firmware/tree/master/QCA4019/hw1.0
- contains 6 specific subsections (16 and 17 are used)
What confuses me now is that Christian Lamparter created a new package 
which creates special board-2.bin files for each device. It is currently
unknown how they were created (simply using the pre-cal files?) and why this
would be necessary. At least in the past (QCA988x) it was not necessary to
overwrite the board(-2).bin with an AP specific version. Either board.bin +
OTP or the wifi EEPROM (cal files, ...) did the job.
My question is therefore, which steps are now necessary to get the QCA4019
devices working correctly. Looking at ath10k_download_cal_data seems to
* ath10k_core_pre_cal_config is tried at first:
- get data from pre-cal files (ART?) or DT under qcom,ath10k-pre-calibration-data
- get board ids (see values from the board-2.bin sections) via OTP
- ath10k_download_and_run_otp will start when everything looks good:
+ first try to use the board data (from board-2.bin)
!!! from board-2.bin and not pre-cal !!!!
+ tries to run OTP
- QCA4019 wifi should now be ready and no extra steps for cal/board data
* if pre-cal didn't work then it falls back to the standard routine
+ ath10k_download_cal_file -> loads cal file to board and then stops
+ ath10k_download_cal_dt -> loads cal DT entry to board and then stops
+ ath10k_download_cal_eeprom -> loads cal EEPROM data to board and then stops
+ ath10k_download_and_run_otp -> loads board(-2).bin data to board, executes
OTP and then stops (see last step of ath10k_core_pre_cal_config)
I have absolutely no information how this is supposed to work and whether the
pre-cal data will really be preserved somehow by the firmware when
ath10k_core_pre_cal_config loads the AP vendor neutral board-2.bin data and
executes the OTP. But the ath10k commit  introducing it, seems to describe
this process quite well. Now there is only the problem - why are there
modified board-2.bin files in LEDE-IPQ40xx  which are generated in an
unknown way and seem to be important to get 5GHz working.
Info about how wifi device (cal) is initialized in QSDK 1.1.3
Lets have a look at the QSDK 1.1.3 output:
[ 13.407078] ath10k_ahb a000000.wifi: Direct firmware load for ath10k/pre-cal-ahb-a000000.wifi.bin failed with error -2
[ 13.407122] ath10k_ahb a000000.wifi: Firmware failed to load from user helper
[ 13.416797] ath10k_ahb a000000.wifi: Direct firmware load for ath10k/cal-ahb-a000000.wifi.bin failed with error -2
[ 13.423883] ath10k_ahb a000000.wifi: Firmware failed to load from user helper
[ 13.435634] ath10k_ahb a000000.wifi: Firmware loaded from user helper succesfully
[ 13.441352] ath10k_ahb a000000.wifi: qca4019 hw1.0 target 0x01000000 chip_id 0x003b00ff sub 0000:0000
[ 13.448922] ath10k_ahb a000000.wifi: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
[ 13.462938] ath10k_ahb a000000.wifi: firmware ver 10.4-3.2.1-00039 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param crc32 dda04a00
[ 13.524630] ath10k_ahb a000000.wifi: Firmware loaded from user helper succesfully
[ 13.525478] ath10k_ahb a000000.wifi: board_file api 2 bmi_id 0:16 crc32 9e6ce62c
[ 14.835890] ath10k_ahb a000000.wifi: htt-ver 2.2 wmi-op 6 htt-op 4 cal file max-sta 512 raw 0 hwcrypto 1
Here we can see that the loading seems to work differently. It doesn't stop
after pre-cal (which should send board-2.bin data + execute OTP). Problem
here seems to be that there is no helper script at all to generate the
Instead we now have a patch called
a00-0058-ath10k-add-qca40xx-mtd-caldata-download-sup.patch . Or to say it
in the (slightly modified) words of Michael Kazior: "I find it frustrating QCA
doesn't try to work with upstream on fixing these things right."  ;)
But what we see here is that ART is used for the pre-cal-* data (see
ath10k_core_probe_fw) and then also used again in ath10k_download_cal_data
(instead of the board data). The board-2.bin data doesn't seem to be
downloaded via ath10k_download_and_run_otp. Even when the comment in this
patch describes it (before jumping out of function without doing the mentioned
+ /* Download board data and run otp. This step will make sure
+ * the target derives final version of board specific info
+ * from board data content and caldata content downloaded in
+ * previous steps.
+ goto done;
At least we know now that the pre-cal-* data is really the one from the ART
partition. But we don't know why the board-2.bin data is never send to the HW.
And also not why the otp_exe_param is never executed via ath10k_bmi_execute.
But it is interesting that it was executed before a QCA988x change was
introduced . So I am guessing that it is just a(nother) bug in the open
QSDK and the board-2.bin data should be send to the device and OTP
(otp_exe_param) should have been executed.
Which therefore brings me back to the initial questions:
* Is it known what was modified in the board data and why the board-2.bin
from ath10k/QSDK open don't "work"? At least there must be something
essential when each vendor ships completely different versions (according
to the LEDE-IPQ40xx package ).
* How were the board-2.bin files from Christian generated
(not the tool to generate the TLV sections of board-2.bin. But the input
files used for the actual board data sections).
* Is the QCA4019 ath10k board data + cal loading order really correct:
- load ART data as pre-cal-* to device
- execute BMI_PARAM_GET_EEPROM_BOARD_ID
- load correct board data from board-2.bin to device
- execute bmi_otp_exe_param
 caf_AU_LINUX_QSDK_RELEASE_DATE_R1_TARGET_ALL.5.0.639.021.xml from
git://codeaurora.org/tools/repo.git (yes, I gave up trying to
understand their different version numbers)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the ath10k