QCA4019: calibration files and board files
Sven Eckelmann
sven.eckelmann at open-mesh.com
Tue Jan 17 03:54:52 PST 2017
Hi,
I've just tested LEDE-IPQ40XX [1] after the official open QSDK 1.1.3 [2] 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
something):
* 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)
+ bus=ahb,bmi-chip-id=0,bmi-board-id=16
+ bus=ahb,bmi-chip-id=0,bmi-board-id=17
+ bus=ahb,bmi-chip-id=0,bmi-board-id=18
+ bus=ahb,bmi-chip-id=0,bmi-board-id=19
+ bus=ahb,bmi-chip-id=0,bmi-board-id=20
+ bus=ahb,bmi-chip-id=0,bmi-board-id=21
What confuses me now is that Christian Lamparter created a new package [3]
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
suggest:
* 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
are required
* 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 [4] 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 [3] 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
(pre-)calibration files.
Instead we now have a patch called
a00-0058-ath10k-add-qca40xx-mtd-caldata-download-sup.patch [5]. 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." [7] ;)
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
steps):
+ /* 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 [6]. 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.
Questions
=========
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 [3]).
* 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
Kind regards,
Sven
[1] https://github.com/chunkeey/LEDE-IPQ40XX
[2] 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)
[3] https://github.com/chunkeey/LEDE-IPQ40XX/commit/901d6d3c38063b2fd9ded3e6ae6f21f5ced15f01
[4] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3d9195ea19e4854d7daa11688b01905e244aead9
[5] https://source.codeaurora.org/quic/qsdk/oss/system/feeds/wlan-open/tree/mac80211/patches/a00-0058-ath10k-add-qca40xx-mtd-caldata-download-sup.patch?id=a1feeac0aad9c817035577b32f9ded77dd23cb31
[6] https://source.codeaurora.org/quic/qsdk/oss/system/feeds/wlan-open/commit/?id=cd78cb8fcbc28af3e538743177f106ec8c5fe295
[7] https://www.mail-archive.com/ath10k@lists.infradead.org/msg05896.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20170117/f1f9f0cf/attachment.sig>
More information about the ath10k
mailing list