QCA4019: calibration files and board files

Sven Eckelmann sven.eckelmann at open-mesh.com
Tue Jan 17 03:54:52 PST 2017


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

 * 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

 * 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

    +		/* 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.


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
   - load correct board data from board-2.bin to device
   - execute bmi_otp_exe_param

Kind regards,

[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