* QCA4019: calibration files and board files @ 2017-01-17 11:54 Sven Eckelmann 2017-01-23 8:30 ` Sven Eckelmann ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Sven Eckelmann @ 2017-01-17 11:54 UTC (permalink / raw) To: ath10k; +Cc: Christian Lamparter, Michal Kazior [-- 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: QCA4019: calibration files and board files 2017-01-17 11:54 QCA4019: calibration files and board files Sven Eckelmann @ 2017-01-23 8:30 ` Sven Eckelmann 2017-01-30 16:36 ` Adrian Chadd 2017-02-08 11:03 ` Sven Eckelmann 2 siblings, 0 replies; 20+ messages in thread From: Sven Eckelmann @ 2017-01-23 8:30 UTC (permalink / raw) To: ath10k; +Cc: Christian Lamparter, Michal Kazior [-- 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: QCA4019: calibration files and board files 2017-01-17 11:54 QCA4019: calibration files and board files Sven Eckelmann 2017-01-23 8:30 ` Sven Eckelmann @ 2017-01-30 16:36 ` Adrian Chadd 2017-01-31 10:12 ` Sven Eckelmann 2017-03-07 9:54 ` Sven Eckelmann 2017-02-08 11:03 ` Sven Eckelmann 2 siblings, 2 replies; 20+ messages in thread From: Adrian Chadd @ 2017-01-30 16:36 UTC (permalink / raw) To: Sven Eckelmann; +Cc: Christian Lamparter, Michal Kazior, ath10k [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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: QCA4019: calibration files and board files 2017-01-30 16:36 ` Adrian Chadd @ 2017-01-31 10:12 ` Sven Eckelmann 2017-03-07 9:54 ` Sven Eckelmann 1 sibling, 0 replies; 20+ messages in thread From: Sven Eckelmann @ 2017-01-31 10:12 UTC (permalink / raw) To: Adrian Chadd; +Cc: Christian Lamparter, Michal Kazior, ath10k, Raja Mani [-- 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: QCA4019: calibration files and board files 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 1 sibling, 1 reply; 20+ messages in thread From: Sven Eckelmann @ 2017-03-07 9:54 UTC (permalink / raw) To: Adrian Chadd; +Cc: Christian Lamparter, simon.wunderlich, Michal Kazior, ath10k [-- 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: QCA4019: calibration files and board files 2017-03-07 9:54 ` Sven Eckelmann @ 2017-03-07 16:30 ` Adrian Chadd 2017-03-09 10:59 ` Sven Eckelmann 0 siblings, 1 reply; 20+ messages in thread From: Adrian Chadd @ 2017-03-07 16:30 UTC (permalink / raw) To: Sven Eckelmann Cc: Christian Lamparter, simon.wunderlich, Michal Kazior, ath10k "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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: QCA4019: calibration files and board files 2017-03-07 16:30 ` Adrian Chadd @ 2017-03-09 10:59 ` Sven Eckelmann 2017-03-09 11:51 ` Valo, Kalle 0 siblings, 1 reply; 20+ messages in thread From: Sven Eckelmann @ 2017-03-09 10:59 UTC (permalink / raw) To: Adrian Chadd; +Cc: Christian Lamparter, simon.wunderlich, Michal Kazior, ath10k [-- 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: QCA4019: calibration files and board files 2017-03-09 10:59 ` Sven Eckelmann @ 2017-03-09 11:51 ` Valo, Kalle 2017-03-09 12:46 ` Sven Eckelmann 0 siblings, 1 reply; 20+ messages in thread From: Valo, Kalle @ 2017-03-09 11:51 UTC (permalink / raw) To: Sven Eckelmann Cc: Christian Lamparter, Adrian Chadd, ath10k, michal.kazior, simon.wunderlich 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: QCA4019: calibration files and board files 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 0 siblings, 2 replies; 20+ messages in thread From: Sven Eckelmann @ 2017-03-09 12:46 UTC (permalink / raw) To: Valo, Kalle Cc: Christian Lamparter, Adrian Chadd, ath10k, michal.kazior, simon.wunderlich [-- 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: QCA4019: calibration files and board files 2017-03-09 12:46 ` Sven Eckelmann @ 2017-03-09 12:54 ` Sven Eckelmann 2017-03-09 13:11 ` Christian Lamparter 1 sibling, 0 replies; 20+ messages in thread From: Sven Eckelmann @ 2017-03-09 12:54 UTC (permalink / raw) To: Valo, Kalle Cc: Christian Lamparter, Adrian Chadd, ath10k, michal.kazior, simon.wunderlich [-- 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: QCA4019: calibration files and board files 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 1 sibling, 1 reply; 20+ messages in thread From: Christian Lamparter @ 2017-03-09 13:11 UTC (permalink / raw) To: Sven Eckelmann Cc: Adrian Chadd, ath10k, Valo, Kalle, michal.kazior, ext.waldemar.rymarkiewicz, simon.wunderlich 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: QCA4019: calibration files and board files 2017-03-09 13:11 ` Christian Lamparter @ 2017-03-09 14:18 ` Waldemar Rymarkiewicz 2017-03-09 16:11 ` Adrian Chadd 0 siblings, 1 reply; 20+ messages in thread From: Waldemar Rymarkiewicz @ 2017-03-09 14:18 UTC (permalink / raw) To: Christian Lamparter Cc: Adrian Chadd, ath10k, Yang, Aeolus, Valo, Kalle, michal.kazior, Sven Eckelmann, simon.wunderlich 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: QCA4019: calibration files and board files 2017-03-09 14:18 ` Waldemar Rymarkiewicz @ 2017-03-09 16:11 ` Adrian Chadd 0 siblings, 0 replies; 20+ messages in thread From: Adrian Chadd @ 2017-03-09 16:11 UTC (permalink / raw) To: Waldemar Rymarkiewicz Cc: ath10k, Yang, Aeolus, Valo, Kalle, michal.kazior, Sven Eckelmann, Christian Lamparter, simon.wunderlich 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: QCA4019: calibration files and board files 2017-01-17 11:54 QCA4019: calibration files and board files Sven Eckelmann 2017-01-23 8:30 ` Sven Eckelmann 2017-01-30 16:36 ` Adrian Chadd @ 2017-02-08 11:03 ` Sven Eckelmann 2017-02-09 10:26 ` akolli 2 siblings, 1 reply; 20+ messages in thread From: Sven Eckelmann @ 2017-02-08 11:03 UTC (permalink / raw) To: shashidhar.lakkavalli; +Cc: Anilkumar Kolli, ath10k [-- 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: QCA4019: calibration files and board files 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 0 siblings, 2 replies; 20+ messages in thread From: akolli @ 2017-02-09 10:26 UTC (permalink / raw) To: Sven Eckelmann; +Cc: ath10k, shashidhar.lakkavalli 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: QCA4019: calibration files and board files 2017-02-09 10:26 ` akolli @ 2017-02-09 10:44 ` Adrian Chadd 2017-02-28 7:58 ` Sven Eckelmann 1 sibling, 0 replies; 20+ messages in thread From: Adrian Chadd @ 2017-02-09 10:44 UTC (permalink / raw) To: akolli; +Cc: shashidhar.lakkavalli, ath10k, Sven Eckelmann 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: QCA4019: calibration files and board files 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 1 sibling, 1 reply; 20+ messages in thread From: Sven Eckelmann @ 2017-02-28 7:58 UTC (permalink / raw) To: akolli Cc: Rajkumar Manoharan, ath10k, Mohammed Shafi Shajakhan, Raja Mani, Tamizh chelvam, shashidhar.lakkavalli [-- 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: QCA4019: calibration files and board files 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 0 siblings, 2 replies; 20+ messages in thread From: Rajkumar Manoharan @ 2017-03-01 3:22 UTC (permalink / raw) To: Sven Eckelmann Cc: Mohammed Shafi Shajakhan, akolli, Tamizh chelvam, ath10k, shashidhar.lakkavalli 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: QCA4019: calibration files and board files 2017-03-01 3:22 ` Rajkumar Manoharan @ 2017-03-01 7:32 ` Sven Eckelmann 2017-03-01 12:51 ` Christian Lamparter 1 sibling, 0 replies; 20+ messages in thread From: Sven Eckelmann @ 2017-03-01 7:32 UTC (permalink / raw) To: Rajkumar Manoharan Cc: Mohammed Shafi Shajakhan, akolli, Tamizh chelvam, ath10k, shashidhar.lakkavalli [-- 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: QCA4019: calibration files and board files 2017-03-01 3:22 ` Rajkumar Manoharan 2017-03-01 7:32 ` Sven Eckelmann @ 2017-03-01 12:51 ` Christian Lamparter 1 sibling, 0 replies; 20+ messages in thread From: Christian Lamparter @ 2017-03-01 12:51 UTC (permalink / raw) To: ath10k Cc: Rajkumar Manoharan, akolli, Sven Eckelmann, Mohammed Shafi Shajakhan, Tamizh chelvam, shashidhar.lakkavalli, Giori, Kathy 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2017-03-09 16:12 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-01-17 11:54 QCA4019: calibration files and board files Sven Eckelmann 2017-01-23 8:30 ` 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
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.