ath10k-firmware: QCA4019 hw1.0: Add GL.iNet GL-B1300 specific BDFs

ath10k-firmware: QCA4019 hw1.0: Add GL.iNet GL-B1300 specific BDFs

[Dongming Han]

[-- Attachment #1: Type: text/plain, Size: 1678 bytes --]

Hi,

Tying to upstream BDFs of GL.iNet GL-B1300 to ath10k-firmware.
This router uses two changed BDFs based on
boardData_1_0_IPQ4019_Y9803_wifi0.bin & boardData_1_0_IPQ4019_Y9803_wifi1.bin.
We changed BDF for target power of both BDFs and FEM control parameter
antCtrlCommon2_G_0_0 of boardData_1_0_IPQ4019_Y9803_wifi0.

I'm not quite sure if ath10k driver need to add these two changed BDF
to work properly
for this board.

I think the ART data is made based on BDF. Maybe the antCtrlCommon logic
and target power parameter is passed to driver by ART but not BDF?
That way we're all happier no need to mantain these change. Please advise.

Now to the questions from the wiki page [1]:

* description for what hardware this is:

  - it is a IPQ4028 based router. More information [2]

* origin of the board file (did you create it yourself or where you
  downloaded)

  - we create it. Can also be extracted from manufacturer firmware[3].

* ids to be used with the board file (ATH10K_BD_IE_BOARD_NAME in ath10k)

  - bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=GL-B1300
   sha256sum: 34d5b821826aad1699666ec95df19a1767245ab424068161275a7ace947eedee
  - bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=GL-B1300
   sha256sum: d0abd802b3d04b51f4a40883157e86b1ff3a204c660d0aa3365ae8e55f625a3e

* attach the actual board file (board.bin)

  - The name of the files are equal to the id string in the board-2.bin
    (minus the ".bin")

Many thanks to Sven for his guidance.

[1] https://wireless.wiki.kernel.org/en/users/drivers/ath10k/boardfiles
[2] https://github.com/openwrt/openwrt/commit/04d3308b6248ef21a6f0bc3378b342906c2d2865
[3] http://www.gl-inet.com/firmware/b1300/clean/

[-- Attachment #2: bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=GL-B1300.bin --]
[-- Type: application/octet-stream, Size: 12064 bytes --]

[-- Attachment #3: bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=GL-B1300.bin --]
[-- Type: application/octet-stream, Size: 12064 bytes --]

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

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

Re: ath10k-firmware: QCA4019 hw1.0: Add GL.iNet GL-B1300 specific BDFs

[Sven Eckelmann]

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

On Dienstag, 27. März 2018 14:48:05 CEST Dongming Han wrote:
> I think the ART data is made based on BDF. Maybe the antCtrlCommon logic
> and target power parameter is passed to driver by ART but not BDF?
> That way we're all happier no need to mantain these change. Please advise.

The antCtrlCommon is part of biModalHeader and this one is taken from the BDF 
and not from the pre-cal data (ART). Same is true for the target power limits.

I am only aware of following things which are taken from the pre-cal data 
(ART):

* mac
* hal_cal version info
* custData
* regDmn
* txrxMask
* calFreqPier*
* calPierData*
* rxGainCalTbl
* param_for_tuning_caps*

Of course, also the bmi ids are taken from the ART before you load the correct 
BDF from the board-2.bin (otherwise, the chip would not know what it actually 
is).

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: ath10k-firmware: QCA4019 hw1.0: Add GL.iNet GL-B1300 specific BDFs

[Sebastian Gottschall]

correct me if i'm wrong. but isnt the board data stored in flash memory 
on these devices like on every other router i know using ath10k chipsets?
this all sounds a little bit curious for me

Sebastian

Am 27.03.2018 um 09:19 schrieb Sven Eckelmann:
> On Dienstag, 27. März 2018 14:48:05 CEST Dongming Han wrote:
>> I think the ART data is made based on BDF. Maybe the antCtrlCommon logic
>> and target power parameter is passed to driver by ART but not BDF?
>> That way we're all happier no need to mantain these change. Please advise.
> The antCtrlCommon is part of biModalHeader and this one is taken from the BDF
> and not from the pre-cal data (ART). Same is true for the target power limits.
>
> I am only aware of following things which are taken from the pre-cal data
> (ART):
>
> * mac
> * hal_cal version info
> * custData
> * regDmn
> * txrxMask
> * calFreqPier*
> * calPierData*
> * rxGainCalTbl
> * param_for_tuning_caps*
>
> Of course, also the bmi ids are taken from the ART before you load the correct
> BDF from the board-2.bin (otherwise, the chip would not know what it actually
> is).
>
> Kind regards,
> 	Sven
>
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


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

Re: ath10k-firmware: QCA4019 hw1.0: Add GL.iNet GL-B1300 specific BDFs

[Sven Eckelmann]

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

On Mittwoch, 28. März 2018 08:23:43 CEST Sebastian Gottschall wrote:
> correct me if i'm wrong. but isnt the board data stored in flash memory 
> on these devices like on every other router i know using ath10k chipsets?
> this all sounds a little bit curious for me

The BDF is stored either in the board.bin or board-2.bin on routers which use 
ath10k. Similar files (raw BDFs with other names) exist on devices which use 
the QCA driver. These files don't contain the device specific information (see 
my earlier mail for the things which seem to be device specific). So they are 
basically part of the rootfs.

The device specific information are stored somewhere else on the device. This 
can for example be in the ART or on a dedicated EEPROM [1]. The OTP binary 
(running on the wifi chip) is receiving both files from the driver, combining 
them and adjusting some things here and there. The combined memory region is 
then given to the actual wifi firmware.

Yes, this all is rather complicated and I think was introduced with the QCA 
802.11ac Wave2 chips. This especially ended up be a problem when QCA was only 
providing board-ids for its own reference designs. Unfortunately, these board 
ids are used to identify the BDFs in the board-2.bin. So we had to introduce 
an additional, optional information that we can use to differentiate between 
different BDFs which have the same board-id - the so called (qcom,ath10k-
calibration-)variant.

It could now be that you're statement was actual suggesting something else:

* Why don't you just use the information from ART and load it as cal data 
  instead of pre-cal data?

   - The firmware seems to behave differently when we do that. Maybe the
     "additional modifications" are not done by the OTP in that case. 
     Maybe QCA can tell you more about that.
   - But there are also another things which we will discuss in the next
     point.

* Why don't you load the information from ART and use it as pre-cal and BDF?

  - The BDF can also contain other information than the pre-cal data in the 
    sections which are not copied from the pre-cal data. This happens all
    the time during the development but can also happen later. Maybe this was
    the reason why QCA implemented this mechanism. It is for example planned 
    to update the A42 BDFs in some weeks.


Small (cut-down) story at the end and why we need special BDFs. During the 
initial development of the A42 OpenWrt support, the HW manufacturer told us 
that we should use the official QCA BDFs with some QCA internal code (which 
translate to bmi-board-id 16/17). We did that and noticed that the board was 
consuming a sh*tload of power and performed worse than a dead horse. After 
some attempts to communicate the problem and some first incorrect assumptions 
from both sides (but with help from some brave OSS developers), the HW 
manufacturer told us about his "official" BDFs which were actually not looking 
like the QCA files at all but had the same IDs. Reason for that was the 
removal of the QCA reference design non-SoC radio components and the 
replacement with their own design. This is where the story of the 
(qcom,ath10k-calibration-)variant began (for me).

Kind regards,
	Sven

[1] I just use this here as placeholder for "any kind of non-volatile memory
    which is no the main storage"

[-- 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: ath10k-firmware: QCA4019 hw1.0: Add GL.iNet GL-B1300 specific BDFs

[Kalle Valo]

Dongming Han <workspace4hdm@gmail.com> writes:

> Tying to upstream BDFs of GL.iNet GL-B1300 to ath10k-firmware.
> This router uses two changed BDFs based on
> boardData_1_0_IPQ4019_Y9803_wifi0.bin & boardData_1_0_IPQ4019_Y9803_wifi1.bin.
> We changed BDF for target power of both BDFs and FEM control parameter
> antCtrlCommon2_G_0_0 of boardData_1_0_IPQ4019_Y9803_wifi0.
>
> I'm not quite sure if ath10k driver need to add these two changed BDF
> to work properly
> for this board.
>
> I think the ART data is made based on BDF. Maybe the antCtrlCommon logic
> and target power parameter is passed to driver by ART but not BDF?
> That way we're all happier no need to mantain these change. Please advise.
>
> Now to the questions from the wiki page [1]:
>
> * description for what hardware this is:
>
>   - it is a IPQ4028 based router. More information [2]
>
> * origin of the board file (did you create it yourself or where you
>   downloaded)
>
>   - we create it. Can also be extracted from manufacturer firmware[3].
>
> * ids to be used with the board file (ATH10K_BD_IE_BOARD_NAME in ath10k)
>
>   - bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=GL-B1300
>    sha256sum: 34d5b821826aad1699666ec95df19a1767245ab424068161275a7ace947eedee
>   - bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=GL-B1300
>    sha256sum: d0abd802b3d04b51f4a40883157e86b1ff3a204c660d0aa3365ae8e55f625a3e
>
> * attach the actual board file (board.bin)
>
>   - The name of the files are equal to the id string in the board-2.bin
>     (minus the ".bin")

Added now, please check:

https://github.com/kvalo/ath10k-firmware/commit/3af9ae584691acbe2356e30fac8380ad4840d8a6

New:
bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=GL-B1300

Changed:


Deleted:

1 board image(s) added, 0 changed, 0 deleted, 18 in total

New:
bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=GL-B1300

Changed:


Deleted:

1 board image(s) added, 0 changed, 0 deleted, 19 in total

-- 
Kalle Valo

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