All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sven Eckelmann <sven.eckelmann@open-mesh.com>
To: ath10k@lists.infradead.org
Cc: Christian Lamparter <chunkeey@googlemail.com>,
	Michal Kazior <michal.kazior@tieto.com>
Subject: QCA4019: calibration files and board files
Date: Tue, 17 Jan 2017 12:54:52 +0100	[thread overview]
Message-ID: <1591748.RGYhBEn8I1@bentobox> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 7884 bytes --]

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

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 146 bytes --]

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

             reply	other threads:[~2017-01-17 11:55 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-17 11:54 Sven Eckelmann [this message]
2017-01-23  8:30 ` QCA4019: calibration files and board files Sven Eckelmann
2017-01-30 16:36 ` Adrian Chadd
2017-01-31 10:12   ` Sven Eckelmann
2017-03-07  9:54   ` Sven Eckelmann
2017-03-07 16:30     ` Adrian Chadd
2017-03-09 10:59       ` Sven Eckelmann
2017-03-09 11:51         ` Valo, Kalle
2017-03-09 12:46           ` Sven Eckelmann
2017-03-09 12:54             ` Sven Eckelmann
2017-03-09 13:11             ` Christian Lamparter
2017-03-09 14:18               ` Waldemar Rymarkiewicz
2017-03-09 16:11                 ` Adrian Chadd
2017-02-08 11:03 ` Sven Eckelmann
2017-02-09 10:26   ` akolli
2017-02-09 10:44     ` Adrian Chadd
2017-02-28  7:58     ` Sven Eckelmann
2017-03-01  3:22       ` Rajkumar Manoharan
2017-03-01  7:32         ` Sven Eckelmann
2017-03-01 12:51         ` Christian Lamparter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1591748.RGYhBEn8I1@bentobox \
    --to=sven.eckelmann@open-mesh.com \
    --cc=ath10k@lists.infradead.org \
    --cc=chunkeey@googlemail.com \
    --cc=michal.kazior@tieto.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.