QCA4019: calibration files and board files

QCA4019: calibration files and board files

[Sven Eckelmann]

[-- 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

Re: QCA4019: calibration files and board files

[Sven Eckelmann]

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

On Dienstag, 17. Januar 2017 12:54:52 CET Sven Eckelmann wrote:
> 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.
[...]
> 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

*bump*

Kind regards,
	Sven

[-- 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

Re: QCA4019: calibration files and board files

[Adrian Chadd]

[snip]

hi!

ok, so here's what's going on behind the scenes.

* I can't talk about what Christian did, where he got the board data
from, etc, etc. You mentioned a DK style board, but didn't say which.
* For example, the ath10k in the "official" QSDK software reference
platform doesn't work out of the box on DK07, because the BMI IDs
aren't in the default IPQ4017 config (eg DK07 can be 2G/5G/pcie or
5G/5G/pcie, depending!)
* .. and the cascade/besra NICs that ship in the DK07 reference boards
also don't exist in the ath10k board-2.bin file because again they're
boards whose BMI IDs aren't shipped;
* .. so, after chatting with QCA as a customer, I discovered which
board.bin template files I needed from their firmware release to match
the boards that we have, and I built custom board-2.bin files with the
relevant stuff, and it works.

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.) The data
in /flash/ on ath9k is the whole calibration block; but in OTP for
ath9k is just the diff against a template. I don't recall what
happened for ath10k and it's too early for me (read: not enough
coffee) to read the source to see if the ath10k board data is the
same.

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.

It's possible they could shave off some of these steps if you have
pre-cal data, but I bet it's done like this to minimise the amount of
special casing going on. Each step may have a special case, but once
you get to the "fetch board ID" step it should continue along
correctly.

HTH,



-adrian

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

Re: QCA4019: calibration files and board files

[Sven Eckelmann]

[-- Attachment #1.1.1: Type: text/plain, Size: 5156 bytes --]

Thanks for the insights

On Montag, 30. Januar 2017 08:36:19 CET Adrian Chadd wrote:
[...]
> * I can't talk about what Christian did, where he got the board data
> from, etc, etc. You mentioned a DK style board, but didn't say which.

    model = "Qualcomm Technologies, Inc. IPQ40xx/AP-DK01.1-C1";
    compatible = "qcom,ipq40xx-apdk01.1", "qcom,ipq40xx";

This is actually how the board (unfortunately) still identifies itself
and selects the device tree according to this compatibility string.

> * For example, the ath10k in the "official" QSDK software reference
> platform doesn't work out of the box on DK07, because the BMI IDs
> aren't in the default IPQ4017 config (eg DK07 can be 2G/5G/pcie or
> 5G/5G/pcie, depending!)
> * .. and the cascade/besra NICs that ship in the DK07 reference boards
> also don't exist in the ath10k board-2.bin file because again they're
> boards whose BMI IDs aren't shipped;

It is using IDs which are already available in the board-2.bin. They are the 
same ids which are already used in all the board-2.bin files from Christian 
Lamparter ("bus=ahb,bmi-chip-id=0,bmi-board-id=16" + "bus=ahb,bmi-chip-
id=0,bmi-board-id=17"). They all have the same IDs but different content. This 
was the problem I saw the first time and which confused me a lot.

At 0:ART 0x1000 I saw:

    refDesignId = 0x10, 
    customerId = 0x0, 
    projectId = 0x0, 

At 0:ART 0x5000 I saw:

    refDesignId = 0x11, 
    customerId = 0x0, 
    projectId = 0x0, 

> [17:33:44] <adri> how big is the precal data block?
> [17:33:49] <adri> in bytes?
> [17:36:22] <adri> there, responded


Btw. it looks to me that the calibration data in the 0:ART is exactly 12064 
bytes long. Just because you've asked about it in #ath10k. There is something 
else at 0x9000 which is 12500 bytes long - no idea what this could be.

> [17:36:32] <adri> the TL;DR is - the BMI IDs aren't freaking unique between
> vendors too :(

So I would guess that the manufacturer should have allocated new IDs and set 
them in the pre-cal parts of the ART partition (but only when they use a 
different reference board.bin). But I am a little bit confused that it is 
called refDesignId (which seems to suggest that 16/17 are referencing the 
DK01.1-C1 somehow). And I am also currently unsure if customerId or projectId 
should end up as ATH10K_BMI_CHIP_ID_FROM_OTP (bmi-chip-id). A quick test 
(modifying these values in the ART) showed that they are basically ignored and 
chip-id stayed at 0 (changing the refDesignId seemed to work).

[...]
> 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".

Hm, looks like we also have to poke the manufacturer and QCA about this.

> 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.

Yes, this was what I would expect from the OTP data. See below regarding my 
guess regarding the pre-cal data.

> It's possible they could shave off some of these steps if you have
> pre-cal data, but I bet it's done like this to minimise the amount of
> special casing going on. Each step may have a special case, but once
> you get to the "fetch board ID" step it should continue along
> correctly.

You are talking about (possibly) shaving off the board-2.bin loading? This is 
at least what I would have expected when looking at the QCA988x based boards 
with calibration data in the flash. But this would not explain why Christian 
Lamparter (which seems to have pre-cal data in the flash of the AC58U) had do 
exchange his board-2.bin to get the board working.

Let us ask Raja Mani about it (who implemented it for ath10k [1]). It looks to 
me that point 4 in his commit message is talking about 
ath10k_download_and_run_otp in ath10k_core_pre_cal_config. And the device will 
just copy parts of the pre-calibration data over the board(-2).bin data. So it 
would count as a diff and therefore requires the correct board-2.bin. So each 
board.bin would require an own id (bad idea - really bad idea when we only 
have 1 byte for bmi-board-id and a lot of vendors with their own board.bin 
files).


Kind regards,
	Sven

[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?
id=3d9195ea19e4854d7daa11688b01905e244aead9

[-- Attachment #1.1.2: art.xz --]
[-- Type: application/x-xz, Size: 14184 bytes --]

[-- 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

Re: QCA4019: calibration files and board files

[Sven Eckelmann]

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

Hi Anilkumar Kolli,

we've noticed that your change in QSDK [1] removed the call to
ath10k_download_and_run_otp in ath10k_download_cal_data after the call to
ath10k_core_get_board_id_from_otp. We reported [2] this to ath10k when we
asked for some clarifications regarding the loading process of the pre-cal +
board-2.bin data.

It was also told us by QCA (private mail) and by Adrian Chadd [3] that the
ath10k_download_and_run_otp step should have been done.

The used release were we noticed this was
caf_AU_LINUX_QSDK_RELEASE_DATE_R1_TARGET_ALL.5.0.639.021.

Will this be fixed in the QSDK? Why is a different implementation used than in
the official ath10k version [4]?

Kind regards,
	Sven


[1] https://source.codeaurora.org/quic/qsdk/oss/system/feeds/wlan-open/commit/?id=cd78cb8fcbc28af3e538743177f106ec8c5fe295
[2] http://lists.infradead.org/pipermail/ath10k/2017-January/009025.html
[3] http://lists.infradead.org/pipermail/ath10k/2017-January/009104.html
[4] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3d9195ea19e4854d7daa11688b01905e244aead9

[-- 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

Re: QCA4019: calibration files and board files

[akolli]

On 2017-02-08 16:33, Sven Eckelmann wrote:
> Hi Anilkumar Kolli,
> 
> we've noticed that your change in QSDK [1] removed the call to
> ath10k_download_and_run_otp in ath10k_download_cal_data after the call 
> to
> ath10k_core_get_board_id_from_otp. We reported [2] this to ath10k when 
> we
> asked for some clarifications regarding the loading process of the 
> pre-cal +
> board-2.bin data.
> 
> It was also told us by QCA (private mail) and by Adrian Chadd [3] that 
> the
> ath10k_download_and_run_otp step should have been done.
> 
> The used release were we noticed this was
> caf_AU_LINUX_QSDK_RELEASE_DATE_R1_TARGET_ALL.5.0.639.021.
> 
> Will this be fixed in the QSDK? Why is a different implementation used 
> than in
> the official ath10k version [4]?
> 

Thanks for pointing this, I broke the sequence in qsdk while loading cal 
data
from flash MTD partitions. I will revert these changes in QSDK patch[1].

@@ -224,21 +224,13 @@
  +		 * from board data content and caldata content downloaded in
  +		 * previous steps.
  +		*/
-+		goto load_bdata_and_run_otp;
++		goto done;
  +	}
  +
   	ret = ath10k_download_cal_file(ar, ar->cal_file);
   	if (ret == 0) {
   		ar->cal_mode = ATH10K_CAL_MODE_FILE;
-@@ -1401,6 +1520,7 @@ static int ath10k_download_cal_data(stru
- 		   "boot did not find target EEPROM entry, try OTP next: %d\n",
- 		   ret);
-
-+load_bdata_and_run_otp:
- 	ret = ath10k_download_and_run_otp(ar);
- 	if (ret) {
- 		ath10k_err(ar, "failed to run otp: %d\n", ret);
-@@ -2024,6 +2144,8 @@ static int ath10k_core_probe_fw(struct a
+@@ -2025,6 +2144,8 @@ static int ath10k_core_probe_fw(struct a
   			   "could not load pre cal data: %d\n", ret);
   	}

Thanks,
Anil.

> Kind regards,
> 	Sven
> 
> 
> [1]
> https://source.codeaurora.org/quic/qsdk/oss/system/feeds/wlan-open/commit/?id=cd78cb8fcbc28af3e538743177f106ec8c5fe295
> [2] 
> http://lists.infradead.org/pipermail/ath10k/2017-January/009025.html
> [3] 
> http://lists.infradead.org/pipermail/ath10k/2017-January/009104.html
> [4]
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3d9195ea19e4854d7daa11688b01905e244aead9

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

Re: QCA4019: calibration files and board files

[Adrian Chadd]

Heh, as a QSDK user, thankyou for fixing this!



-adrian

On 9 February 2017 at 02:26,  <akolli@codeaurora.org> wrote:
> On 2017-02-08 16:33, Sven Eckelmann wrote:
>>
>> Hi Anilkumar Kolli,
>>
>> we've noticed that your change in QSDK [1] removed the call to
>> ath10k_download_and_run_otp in ath10k_download_cal_data after the call to
>> ath10k_core_get_board_id_from_otp. We reported [2] this to ath10k when we
>> asked for some clarifications regarding the loading process of the pre-cal
>> +
>> board-2.bin data.
>>
>> It was also told us by QCA (private mail) and by Adrian Chadd [3] that the
>> ath10k_download_and_run_otp step should have been done.
>>
>> The used release were we noticed this was
>> caf_AU_LINUX_QSDK_RELEASE_DATE_R1_TARGET_ALL.5.0.639.021.
>>
>> Will this be fixed in the QSDK? Why is a different implementation used
>> than in
>> the official ath10k version [4]?
>>
>
> Thanks for pointing this, I broke the sequence in qsdk while loading cal
> data
> from flash MTD partitions. I will revert these changes in QSDK patch[1].
>
> @@ -224,21 +224,13 @@
>  +               * from board data content and caldata content downloaded in
>  +               * previous steps.
>  +              */
> -+              goto load_bdata_and_run_otp;
> ++              goto done;
>  +      }
>  +
>         ret = ath10k_download_cal_file(ar, ar->cal_file);
>         if (ret == 0) {
>                 ar->cal_mode = ATH10K_CAL_MODE_FILE;
> -@@ -1401,6 +1520,7 @@ static int ath10k_download_cal_data(stru
> -                  "boot did not find target EEPROM entry, try OTP next:
> %d\n",
> -                  ret);
> -
> -+load_bdata_and_run_otp:
> -       ret = ath10k_download_and_run_otp(ar);
> -       if (ret) {
> -               ath10k_err(ar, "failed to run otp: %d\n", ret);
> -@@ -2024,6 +2144,8 @@ static int ath10k_core_probe_fw(struct a
> +@@ -2025,6 +2144,8 @@ static int ath10k_core_probe_fw(struct a
>                            "could not load pre cal data: %d\n", ret);
>         }
>
> Thanks,
> Anil.
>
>> Kind regards,
>>         Sven
>>
>>
>> [1]
>>
>> https://source.codeaurora.org/quic/qsdk/oss/system/feeds/wlan-open/commit/?id=cd78cb8fcbc28af3e538743177f106ec8c5fe295
>> [2] http://lists.infradead.org/pipermail/ath10k/2017-January/009025.html
>> [3] http://lists.infradead.org/pipermail/ath10k/2017-January/009104.html
>> [4]
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3d9195ea19e4854d7daa11688b01905e244aead9
>
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k

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

Re: QCA4019: calibration files and board files

[Sven Eckelmann]

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

On Donnerstag, 9. Februar 2017 15:56:59 CET akolli@codeaurora.org wrote:
[...]
> Thanks for pointing this, I broke the sequence in qsdk while loading cal 
> data
> from flash MTD partitions. I will revert these changes in QSDK patch[1].
> 
> @@ -224,21 +224,13 @@
>   +		 * from board data content and caldata content downloaded in
>   +		 * previous steps.
>   +		*/
> -+		goto load_bdata_and_run_otp;
> ++		goto done;
>   +	}
>   +
>    	ret = ath10k_download_cal_file(ar, ar->cal_file);
>    	if (ret == 0) {
>    		ar->cal_mode = ATH10K_CAL_MODE_FILE;
> -@@ -1401,6 +1520,7 @@ static int ath10k_download_cal_data(stru
> - 		   "boot did not find target EEPROM entry, try OTP next: %d\n",
> - 		   ret);
> -
> -+load_bdata_and_run_otp:
> - 	ret = ath10k_download_and_run_otp(ar);
> - 	if (ret) {
> - 		ath10k_err(ar, "failed to run otp: %d\n", ret);
> -@@ -2024,6 +2144,8 @@ static int ath10k_core_probe_fw(struct a
> +@@ -2025,6 +2144,8 @@ static int ath10k_core_probe_fw(struct a
>    			   "could not load pre cal data: %d\n", ret);
>    	}

We now got answer from QCA support (Eric Guo, case 02807752). He told us now
that the data on the ART partition is *not* the pre-calibration data
and instead is the full calibration data (he is is not really clear about that
part).

It looks to me now that this information is contradicting your implementation
(which now loads the data from 0:ART partition [1] like pre-cal data [2] and
then loads the board-2.bin [3]). 

I have doubt regarding his explanation but I got no actual spec - only
information which seems to be contradicting (or to vague) . Is is possible
to get some confirmation from you about whether the data from the 0:ART
partition is pre-cal data or not and whether the board-2.bin should be
used when the data from 0:ART is used.

It could also be that Eric and I are just using the terms "pre-cal" and
"calibration" data differently. My understanding until now was that:

 * pre-cal data + board-2.bin info == actual calibration data

Maybe he is using a different definitions like

 * pre-cal data == some incomplete calibration data from somewhere else
                   (he never specified it - just that it exists)
 * calibration data == incomplete calibration data from 0:ART
                       (what I've described in the past as pre-cal data)
 * (pre-cal or calibration data) + board-2.bin info == actual calibration data

Would be nice if this confusion could be cleared up by you.

Kind regards,
	Sven

[1] 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=b9910f7bd128b719562b6807388ef5519e7676c1#n123
[2] 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=b9910f7bd128b719562b6807388ef5519e7676c1#n213
[3] 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=b9910f7bd128b719562b6807388ef5519e7676c1#n222


[-- 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

Re: QCA4019: calibration files and board files

[Rajkumar Manoharan]

On 2017-02-27 23:58, Sven Eckelmann wrote:
> It looks to me now that this information is contradicting your 
> implementation
> (which now loads the data from 0:ART partition [1] like pre-cal data 
> [2] and
> then loads the board-2.bin [3]).
> 
Both reading from ART and loading pre-cal data file are same.

> I have doubt regarding his explanation but I got no actual spec - only
> information which seems to be contradicting (or to vague) . Is is 
> possible
> to get some confirmation from you about whether the data from the 0:ART
> partition is pre-cal data or not and whether the board-2.bin should be
> used when the data from 0:ART is used.
> 
In QCA4019 platform, only radio specific calibration (pre-cal-data) is 
stored in flash.
Board specific contents are read from board-2.bin. For each radio 
appropriate board
data should be loaded. To fetch correct board data from board-2.bin 
bundle, pre-cal/radio
specific caldata should be loaded first to get proper board id.

> My understanding until now was that:
> 
>  * pre-cal data + board-2.bin info == actual calibration data
> 
Correct.

>  * pre-cal data == some incomplete calibration data from somewhere else
>                    (he never specified it - just that it exists)
>  * calibration data == incomplete calibration data from 0:ART
>                        (what I've described in the past as pre-cal 
> data)
>  * (pre-cal or calibration data) + board-2.bin info == actual 
> calibration data
> 
> Would be nice if this confusion could be cleared up by you.
> 
Following methods are used to read radio specific caldata.

1) In some platform which lags DT support, init.d script is used to read
the calibrations content from flash memory and write it in file system 
at boot time.
This is done by dd command.

2) DT entry “qcom,ath10k-pre-calibration-data" is used to pass 
calibration data
from flash to driver. But it needs CoreBSB support to transfer the 
contents from
flash to device tree.

qcom,pre-calibration-data ==> only radio specific calibration.
qcom,calibration-data ==> {radio specific + board specific calibration}.

3) Reading calibration data directly from ART partition by mtd_read 
operation. This one
can be removed from QSDK either by init script or by DT support.

"qcom,calibration-data" is used for qca988x on AP148 plaform. Here 
calibration data mean
both radio + board contents. Always calibration content are stored in 
ART partition.

-Rajkumar

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

Re: QCA4019: calibration files and board files

[Sven Eckelmann]

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

On Dienstag, 28. Februar 2017 19:22:32 CET Rajkumar Manoharan wrote:
> On 2017-02-27 23:58, Sven Eckelmann wrote:
> > It looks to me now that this information is contradicting your 
> > implementation
> > (which now loads the data from 0:ART partition [1] like pre-cal data 
> > [2] and
> > then loads the board-2.bin [3]).
> > 
> Both reading from ART and loading pre-cal data file are same.
> 
> > I have doubt regarding his explanation but I got no actual spec - only
> > information which seems to be contradicting (or to vague) . Is is 
> > possible
> > to get some confirmation from you about whether the data from the 0:ART
> > partition is pre-cal data or not and whether the board-2.bin should be
> > used when the data from 0:ART is used.
> > 
> In QCA4019 platform, only radio specific calibration (pre-cal-data) is 
> stored in flash.
> Board specific contents are read from board-2.bin. For each radio 
> appropriate board
> data should be loaded. To fetch correct board data from board-2.bin 
> bundle, pre-cal/radio
> specific caldata should be loaded first to get proper board id.
> 
> > My understanding until now was that:
> > 
> >  * pre-cal data + board-2.bin info == actual calibration data
> > 
> Correct.
[...]

Thanks a lot for the confirmation

Kind regards,
	Sven

[-- 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

Re: QCA4019: calibration files and board files

[Christian Lamparter]

On Tuesday, February 28, 2017 7:22:32 PM CET Rajkumar Manoharan wrote:
> On 2017-02-27 23:58, Sven Eckelmann wrote:
> > It looks to me now that this information is contradicting your 
> > implementation
> > (which now loads the data from 0:ART partition [1] like pre-cal data 
> > [2] and
> > then loads the board-2.bin [3]).
> > 
> Both reading from ART and loading pre-cal data file are same.
> 
> > I have doubt regarding his explanation but I got no actual spec - only
> > information which seems to be contradicting (or to vague) . Is is 
> > possible
> > to get some confirmation from you about whether the data from the 0:ART
> > partition is pre-cal data or not and whether the board-2.bin should be
> > used when the data from 0:ART is used.
> > 
> In QCA4019 platform, only radio specific calibration (pre-cal-data) is 
> stored in flash.
> Board specific contents are read from board-2.bin. For each radio 
> appropriate board data should be loaded. To fetch correct board data
> from board-2.bin bundle, pre-cal/radio specific caldata should be
> loaded first to get proper board id.
> 
> > My understanding until now was that:
> > 
> >  * pre-cal data + board-2.bin info == actual calibration data
> > 
> Correct.
>
> >  * pre-cal data == some incomplete calibration data from somewhere else
> >                    (he never specified it - just that it exists)
> >  * calibration data == incomplete calibration data from 0:ART
> >                        (what I've described in the past as pre-cal 
> > data)
> >  * (pre-cal or calibration data) + board-2.bin info == actual 
> > calibration data
> > 
> > Would be nice if this confusion could be cleared up by you.
> > 
> Following methods are used to read radio specific caldata.
> 
> 1) In some platform which lags DT support, init.d script is used to read
> the calibrations content from flash memory and write it in file system 
> at boot time.
> This is done by dd command.
> 
> 2) DT entry “qcom,ath10k-pre-calibration-data" is used to pass 
> calibration data
> from flash to driver. But it needs CoreBSB support to transfer the 
> contents from flash to device tree.
>
> qcom,pre-calibration-data ==> only radio specific calibration.
> qcom,calibration-data ==> {radio specific + board specific calibration}.
> 
> 3) Reading calibration data directly from ART partition by mtd_read 
> operation. This one can be removed from QSDK either by init script
> or by DT support.
> 
> "qcom,calibration-data" is used for qca988x on AP148 plaform. 
> Here calibration data mean both radio + board contents.
> Always calibration content are stored in ART partition.

Ok. Thanks for the clarification.

So, pre-cal data (from flash) + board-2 (from fs) is the 
right way for now.

However, this is a bit of a problem for LEDE/OpenWRT.

You see: The board-2.bin will have to be baked into the rootfs-image
of the LEDE/OpenWRT firmware.
But in order to do that, the board-2.bin needs to be extracted from
the vendor's binary firmware image (via unsquashfs). Or if we are 
lucky: from the source archive, if the vendor left them in there.

The problem is: these raw board.bin files sourced from the binary
firmware image lack a redistributable license.
And therefore they can't be shipped with LEDE/OpenWRT. 
(The raw board.bin files from the source archive [1] are usually
in the  madwifi-11n directory, which has a redistributable 
license file [2] and can be converted to board-2.bin with the 
ath10k-bdencoder [3]. But there's no explicit statement that
this is possible.)

The way I see it atm, developers would need to ask the vendors
for  permission and LEDE/OpenWRT needs to setup something like
a board-2.bin repository (similar to linux-firmware [0]) for 
all the IPQ40XX devices (and future devices?)...

...

Is there a way around this problem? 
Can somebody ask around in the Legal Department? And clarify if:

1. Whenever the board-2.bin are copyright-able in the first place?
   INAL. These files just contain calibration values/parameters
   and no programs. From what I know facts/numbers are not copyright-able.
   But I don't know if it applies here or not. And if there is a
   difference between US/Europe/China/... laws.

2. What license these board.bin files should have.
   They are generated by the halphy_tools' eepromUtil utility.
   Are these files all original, or do they classify as
   derived works?

3. Most importantly: Can this be handled differently for future devices?
   Like adding a redistributable license text inside the board.bin files?
   (Like a header or trailer. A trailer would have the advantage that if
   the caldata length is fixed (like 12064 bytes for IPQ40XX), the trailer
   won't be uploaded to the device. So a trailer can be easily added to 
   existing files).

(4. Any workaround?
    Like trying to get by with just the precal-data from flash like in [4]?)

Thanks,
Christian

[0] <https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/README>
[1] <https://github.com/paul-chambers/netgear-r7800/tree/master/git_home/madwifi-11n.git/halphy_tools/host/eepromUtil/release_ipq4019>
[2] <https://github.com/paul-chambers/netgear-r7800/blob/master/git_home/madwifi-11n.git/COPYING>
[3] <https://github.com/qca/qca-swiss-army-knife/blob/master/tools/scripts/ath10k/ath10k-bdencoder>
[4] <https://www.mail-archive.com/ath10k@lists.infradead.org/msg05911.html>

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

Re: QCA4019: calibration files and board files

[Sven Eckelmann]

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

Hi Adrian,

On Montag, 30. Januar 2017 08:36:19 CET Adrian Chadd wrote:
> 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".

Did you get any feedback from QCA? Our requests regarding registration of two 
own bmi-board-ids for our product were always answered (slightly simplified) 
with "don't change the BDF files", "always use board-2.bin from driver/
firmware" and "ask your ODM". This basically didn't help us and didn't answer 
the question and creates quite a big problem for us because the ODM insists 
that we should use his BDF [1] files with modifications [tm]. We just found 
out that the ODM used a modified version of the DK04.1 BDF files but used the 
bmi-board-id's for the AP-DK01.1-C1 - so we still have a long road ahead.

We are still trying to get more information. But I though that I could ask you 
in the meantime whether you had more success and have a status update.

Kind regards,
	Sven

[1] According to QCA, the BDF files are just the single board files inside
    the board-2.bin

[-- 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

Re: QCA4019: calibration files and board files

[Adrian Chadd]

"use your own bmi ids". :-)

(yeah, this is going to make open source firmware for these things
more painful than it should be. :( )



-adrian


On 7 March 2017 at 01:54, Sven Eckelmann <sven.eckelmann@openmesh.com> wrote:
> Hi Adrian,
>
> On Montag, 30. Januar 2017 08:36:19 CET Adrian Chadd wrote:
>> 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".
>
> Did you get any feedback from QCA? Our requests regarding registration of two
> own bmi-board-ids for our product were always answered (slightly simplified)
> with "don't change the BDF files", "always use board-2.bin from driver/
> firmware" and "ask your ODM". This basically didn't help us and didn't answer
> the question and creates quite a big problem for us because the ODM insists
> that we should use his BDF [1] files with modifications [tm]. We just found
> out that the ODM used a modified version of the DK04.1 BDF files but used the
> bmi-board-id's for the AP-DK01.1-C1 - so we still have a long road ahead.
>
> We are still trying to get more information. But I though that I could ask you
> in the meantime whether you had more success and have a status update.
>
> Kind regards,
>         Sven
>
> [1] According to QCA, the BDF files are just the single board files inside
>     the board-2.bin

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

Re: QCA4019: calibration files and board files

[Sven Eckelmann]

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

On Dienstag, 7. März 2017 08:30:54 CET Adrian Chadd wrote:
> "use your own bmi ids". :-)
> 
> (yeah, this is going to make open source firmware for these things
> more painful than it should be. :( )

Thanks for the reply. I was just informed that the firmware binary will behave 
differently depending on the bmi-board-id (even when the rest of the content 
is the same).

The selection of an own bmi id is therefore also not an actual option. Ok, 
maybe in some cases but not in general.

The method to have a single board-2.bin for QCA4019 and to let ath10k select 
the right one using bmi-board-id, bmi-chip-id and bus is simply not working.

Either the board-2.bin is simply not used and only the pre-cal data is used 
(as seen in Christian Lamparter's/Michal Kazior's patch [1]) or each board has 
to come with its own board-2.bin. The latter brings up the license problem 
mentioned by Christian [2]. Both have the problem that QCA (for some reason) 
wants that always the board-2.bin is used which comes with the "ath10k" 
firmware binary [3].

Kind regards,
	Sven

[1] https://www.mail-archive.com/ath10k@lists.infradead.org/msg05911.html
[2] https://www.mail-archive.com/ath10k@lists.infradead.org/msg06509.html
[3] btw. this QCA seems to contradict itself here by helping ODMs to
    create their own boardata files

[-- 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

Re: QCA4019: calibration files and board files

[Valo, Kalle]

Sven Eckelmann <sven.eckelmann@openmesh.com> writes:

> On Dienstag, 7. März 2017 08:30:54 CET Adrian Chadd wrote:
>> "use your own bmi ids". :-)
>> 
>> (yeah, this is going to make open source firmware for these things
>> more painful than it should be. :( )
>
> Thanks for the reply. I was just informed that the firmware binary will behave 
> differently depending on the bmi-board-id (even when the rest of the content 
> is the same).
>
> The selection of an own bmi id is therefore also not an actual option. Ok, 
> maybe in some cases but not in general.
>
> The method to have a single board-2.bin for QCA4019 and to let ath10k select 
> the right one using bmi-board-id, bmi-chip-id and bus is simply not working.
>
> Either the board-2.bin is simply not used and only the pre-cal data is used 
> (as seen in Christian Lamparter's/Michal Kazior's patch [1]) or each board has 
> to come with its own board-2.bin. 

I haven't followed the discussion very closely, so I might be way off,
but for laptop SMBIOS implementations Waldemar added a variant field to
board-2.bin so that we can have multiple images for the same subsystem
id. Could it help here also?

https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=ath-next&id=1657b8f84ed9fc1d2a100671f1d42d6286f20073

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

Re: QCA4019: calibration files and board files

[Sven Eckelmann]

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

On Donnerstag, 9. März 2017 11:51:13 CET Valo, Kalle wrote:
[...]
> I haven't followed the discussion very closely, so I might be way off,
> but for laptop SMBIOS implementations Waldemar added a variant field to
> board-2.bin so that we can have multiple images for the same subsystem
> id. Could it help here also?
> 
> https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/
> ?h=ath-next&id=1657b8f84ed9fc1d2a100671f1d42d6286f20073

Thanks for the pointer.

I also saw this morning but haven't invested a lot of time when I saw it. But 
let's play around with some ideas around "variant". Maybe someone else has 
some better ideas or comments.

The information about the variant has to come from somewhere. Currently, the 
OTP binary is returning only the bmi-chip-id and bmi-board-id. There doesn't 
seem to be any "project"/"customer" id returned by it (even when it exists in 
the EEPROM). And even when there would be, the already existing devices don't 
seem to have it and i don't know if QCA actually allocates them for customers. 
I would therefore postpone the use of pre-cal data to generate the the variant 
string for now (but I will ask the ODM to get some info from QCA).

Let us see how the SMBIOS does it. dmi_walk is used to go through the entries 
and search for the entry. We don't have this here. So let's check what we have 
with the QCA4019

This looks at least like a doable thing with the device tree. It must be a 
string but this can easily be stored in the device tree itself. 

The RT-AC58U  could therefore have following entries:

    		wifi@a000000 {
    			status = "okay";
    			qcom,ath10k-calibration-variant = "RT-AC58U";
    		};
    
    		wifi@a800000 {
    			status = "okay";
    			qcom,ath10k-calibration-variant = "RT-AC58U";
    		};

Some code has to be added to ath10k_core_probe_fw. I can prepare this later 
(when I find the time).

The board-2.bin would then require entries for bus=ahb,bmi-chip-id=0,bmi-
board-id=16,variant=RT-AC58U and bus=ahb,bmi-chip-id=0,bmi-board-
id=17,variant=RT-AC58U.

Kind regards,
	Sven

[-- 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

Re: QCA4019: calibration files and board files

[Sven Eckelmann]

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

On Donnerstag, 9. März 2017 13:46:00 CET Sven Eckelmann wrote:
> The board-2.bin would then require entries for bus=ahb,bmi-chip-id=0,bmi-
> board-id=16,variant=RT-AC58U and bus=ahb,bmi-chip-id=0,bmi-board-
> id=17,variant=RT-AC58U.

Small remark: I know the SMBIOS format would be "BDF_<Customer ID>_<Extension>
\0" and the variant string would usually end up as something like 
"variant=DE_1AB". But we usually don't seem to have the customer ids + 
extension(?) for these boards.

Kind regards,
	Sven

[-- 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

Re: QCA4019: calibration files and board files

[Christian Lamparter]

On Thursday, March 9, 2017 1:46:00 PM CET Sven Eckelmann wrote:
> On Donnerstag, 9. März 2017 11:51:13 CET Valo, Kalle wrote:
> [...]
> > I haven't followed the discussion very closely, so I might be way off,
> > but for laptop SMBIOS implementations Waldemar added a variant field to
> > board-2.bin so that we can have multiple images for the same subsystem
> > id. Could it help here also?
> > 
> > https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/
> > ?h=ath-next&id=1657b8f84ed9fc1d2a100671f1d42d6286f20073
> 
> Thanks for the pointer.
I've added Waldemar.

From what I can tell, adding something like a variant to the bmi-id would
help. I looked at the patch note and it strikes me a bit odd that the
used variant was a non-descriptive "DE_1AB" string? Isn't this bit arbitrary?
What is encoded in these variant strings? Are these variants "unique"? 
Who will distribute these special board-2.bin that contain all the 
different variants?

Also the patch says that if the variant isn't found, it will fall back to
the default. In case of the Asus RT-AC58U, this will not really work.
From what I can tell, ASUS added a PA chip and 5 dBi Antennas. They had to
redo the calibration and ended up with different values for the PA, AGC, 
Edges, Slobes, the lot... However, they kept the the project/customer id.
So the board-2.bin found on codeaurora and in the ath10k-repository will
not work.

> 
> I also saw this morning but haven't invested a lot of time when I saw it. But 
> let's play around with some ideas around "variant". Maybe someone else has 
> some better ideas or comments.
> 
> The information about the variant has to come from somewhere. Currently, the 
> OTP binary is returning only the bmi-chip-id and bmi-board-id. There doesn't 
> seem to be any "project"/"customer" id returned by it (even when it exists in 
> the EEPROM). And even when there would be, the already existing devices don't 
> seem to have it and i don't know if QCA actually allocates them for customers. 
> I would therefore postpone the use of pre-cal data to generate the the variant 
> string for now (but I will ask the ODM to get some info from QCA).
> 
> Let us see how the SMBIOS does it. dmi_walk is used to go through the entries 
> and search for the entry. We don't have this here. So let's check what we have 
> with the QCA4019
> 
> This looks at least like a doable thing with the device tree. It must be a 
> string but this can easily be stored in the device tree itself. 
> 
> The RT-AC58U  could therefore have following entries:
> 
>     		wifi@a000000 {
>     			status = "okay";
>     			qcom,ath10k-calibration-variant = "RT-AC58U";
>     		};
>     
>     		wifi@a800000 {
>     			status = "okay";
>     			qcom,ath10k-calibration-variant = "RT-AC58U";
>     		};
> 
> Some code has to be added to ath10k_core_probe_fw. I can prepare this later 
> (when I find the time).
> 
> The board-2.bin would then require entries for bus=ahb,bmi-chip-id=0,bmi-
> board-id=16,variant=RT-AC58U and bus=ahb,bmi-chip-id=0,bmi-board-
> id=17,variant=RT-AC58U.
This brings up a issue: Who will distribute these board-2.bin?
I would prefer them being added to the codeaurora or the
ath10k-firmware repository. Will this be possible? 

Thanks,
Christian

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

Re: QCA4019: calibration files and board files

[Waldemar Rymarkiewicz]

On 9 March 2017 at 14:11, Christian Lamparter <chunkeey@googlemail.com> wrote:
> On Thursday, March 9, 2017 1:46:00 PM CET Sven Eckelmann wrote:
>> On Donnerstag, 9. März 2017 11:51:13 CET Valo, Kalle wrote:
>> [...]
>> > I haven't followed the discussion very closely, so I might be way off,
>> > but for laptop SMBIOS implementations Waldemar added a variant field to
>> > board-2.bin so that we can have multiple images for the same subsystem
>> > id. Could it help here also?
>> >
>> > https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/
>> > ?h=ath-next&id=1657b8f84ed9fc1d2a100671f1d42d6286f20073
>>
>> Thanks for the pointer.
> I've added Waldemar.


If bmi ids are valid you will not use SMBIOS variant at all. See
ath10k_core_create_board_name().

> From what I can tell, adding something like a variant to the bmi-id would
> help. I looked at the patch note and it strikes me a bit odd that the
> used variant was a non-descriptive "DE_1AB" string? Isn't this bit arbitrary?

Well, DE here stands for customer ID, but I haven't seen any  spec how
this is defined..

Adding Aeolus who perhaps can help to explain.

> What is encoded in these variant strings? Are these variants "unique"?

I guess so, QCA is assigning customers ID.

> Who will distribute these special board-2.bin that contain all the
> different variants?

hmmm.. I would expect QCA.

>
> Also the patch says that if the variant isn't found, it will fall back to
> the default.

Yes, because if it happens that user uses board with smbios variant
set but have no entry for this variant in board-2.bin (old
board-2.bin) it will fail to boot. We got reports on that, so we
decided to fallback to default  bdf. Otherwise already shipped devices
working so far after kernel upgrade will stop to work.

 In case of the Asus RT-AC58U, this will not really work.
> From what I can tell, ASUS added a PA chip and 5 dBi Antennas. They had to
> redo the calibration and ended up with different values for the PA, AGC,
> Edges, Slobes, the lot... However, they kept the the project/customer id.
> So the board-2.bin found on codeaurora and in the ath10k-repository will
> not work.

If I understand properly, Asus uses modified board-2.bin  so default
found on codeaurora and ath10k-repo will not work. Right? Use the
proper one?


/Waldek

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

Re: QCA4019: calibration files and board files

[Adrian Chadd]

Hi,

I mean - it's binary data required to make something work, I don't
know if copyright applies?

Guess we should ask QCA again a bit more. :)

Yes, we likely need a separate repository of board data files indexed
by actual board.


-adrian

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