ath11k: incorrect board_id retrieval

ath11k: incorrect board_id retrieval

[Sven Eckelmann]

Hi,

I've noticed that manufacturers of cards gave me various information what 
board_id they expected a device (QCN9074) is detected as. But ath11k only 
retrieves the board id as 0xff - thus the ath11k driver is always loading the 
wrong BDF. Commercially available boards with a problem like this are:

* 8devices Pineapple
  - 2GHz: 160 (0xa0)
  - 5GHz: 161 (0xa1)
  - 6GHz: 162 (0xa2)
* Compex WLE3000H5
* (maybe there is not a single one which works?)

If I would use these boards in one with a devicetree then I could just 
overwrite it using qcom,board_id (and/or qcom,ath11k-calibration-variant). But 
this isn't the case when I want to use a couple of these cards in a simple x86 
system. All off them (even when they are significantly different) are reported
as

    ath11k_pci 0000:03:00.0: chip_id 0x0 chip_family 0x0 board_id 0xff soc_id 0xffffffff

So I would have to hack the driver to implement my own (pci id? based)
board.bin retrieval code.


So my question would be: Is the ath11k based board_id retrieval just broken? 
Or are these cards broken?


The way the firmware is initialized definitely changed between ath10k and 
ath11k. Previously, the otp.bin took care of retrieving the (pre-cal) data 
from the EEPROM/OTP on the card or retrieved it via driver from the host 
systems flash/filesystem. And then the otp.bin was reporting the board_id to 
the driver. Based on that, the driver was able to select the correct BDF.

But now, the firmware is started and immediately afterwards, it is already 
asked to report the target capabilities. And the target capabilities are 
including the board_id - the part which doesn't seem to work correctly. Only 
after that, the driver sends the BDF + (pre)caldata. So the firmware (if the 
precaldata comes from the flash/filesystem) doesn't have the chance to get the 
board_id [1] from the (pre)caldata. Which sounds wrong to me. But I have no
access to anything which would allow me to check how it should actually work.

Kind regards,
	Sven

[1] i think it was the refDesignId, projectId or something like this in ath10k



-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

Re: ath11k: incorrect board_id retrieval

[Sven Eckelmann]

On Friday, 26 November 2021 15:48:17 CET Sven Eckelmann wrote:
> I've noticed that manufacturers of cards gave me various information what 
> board_id they expected a device (QCN9074) is detected as. But ath11k only 
> retrieves the board id as 0xff - thus the ath11k driver is always loading the 
> wrong BDF. Commercially available boards with a problem like this are:
>
> * 8devices Pineapple
>   - 2GHz: 160 (0xa0)
>   - 5GHz: 161 (0xa1)
>   - 6GHz: 162 (0xa2)
> * Compex WLE3000H5
> * (maybe there is not a single one which works?)

Just retrieved the next card (EmWicon WMX7205 - could be the same as jjPlus 
WMX7205) and it has exactly the same problem:

    ath11k_pci 0000:05:00.0: failed to fetch board data for bus=pci,vendor=17cb,device=1103,subsystem-vendor=17cb,subsystem-device=0108,qmi-chip-id=2,qmi-board-id=255 from ath11k/WCN6855/hw2.0/board-2.bin
    ath11k_pci 0000:05:00.0: failed to fetch board-2.bin or board.bin from WCN6855/hw2.

Of course, the only provided keys (all with board_id != 255) are:

* bus=pci,vendor=17cb,device=1103,subsystem-vendor=17cb,subsystem-device=3374,qmi-chip-id=2,qmi-board-id=262
* bus=pci,vendor=17cb,device=1103,subsystem-vendor=17cb,subsystem-device=3374,qmi-chip-id=2,qmi-board-id=266
* bus=pci,vendor=17cb,device=1103,subsystem-vendor=17cb,subsystem-device=3374,qmi-chip-id=18,qmi-board-id=266

So until now, I could not find a single card for which ath11k returned a 
board-id != 255 (unless it was overwritten via the devicetree).

> So my question would be: Is the ath11k based board_id retrieval just broken? 
> Or are these cards broken?

Kind regards,
	Sven



-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

Re: ath11k: incorrect board_id retrieval

[Sven Eckelmann]

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

On Thursday, 2 December 2021 15:43:03 CET Sven Eckelmann wrote:
[...]
> Just retrieved the next card (EmWicon WMX7205 - could be the same as jjPlus 
> WMX7205) and it has exactly the same problem:
> 
>     ath11k_pci 0000:05:00.0: failed to fetch board data for bus=pci,vendor=17cb,device=1103,subsystem-vendor=17cb,subsystem-device=0108,qmi-chip-id=2,qmi-board-id=255 from ath11k/WCN6855/hw2.0/board-2.bin
>     ath11k_pci 0000:05:00.0: failed to fetch board-2.bin or board.bin from WCN6855/hw2.
> 
> Of course, the only provided keys (all with board_id != 255) are:
> 
> * bus=pci,vendor=17cb,device=1103,subsystem-vendor=17cb,subsystem-device=3374,qmi-chip-id=2,qmi-board-id=262
> * bus=pci,vendor=17cb,device=1103,subsystem-vendor=17cb,subsystem-device=3374,qmi-chip-id=2,qmi-board-id=266
> * bus=pci,vendor=17cb,device=1103,subsystem-vendor=17cb,subsystem-device=3374,qmi-chip-id=18,qmi-board-id=266
> 
> So until now, I could not find a single card for which ath11k returned a 
> board-id != 255 (unless it was overwritten via the devicetree).

According to the manufacturer, the board itself should identify itself as 

    chip_id: 0x2, chip_family: 0xb,   board_id: 0x301, soc_id: 0x400c0200

I have therefore dumped the memory region with the qmi response via kgdb. You 
can easily see that the response has following sections:


* 0x02 (len  4) - resp
* 0x02 (len  4) - resp
* 0x10 (len  8) - chip_info
* 0x12 (len  4) - soc_info_valid
* 0x13 (len 21) - fw_version_info
* 0x14 (len 77) - fw_build_id
* 0x15 (len  1) - num_macs
* 0x16 (len  4) - voltage_mv
* 0x17 (len  4) - time_freq_hz
* 0x1A (len  8) - ????

So the section 0x11 with the board_id is completely missing. For some reason.

> > So my question would be: Is the ath11k based board_id retrieval just broken? 
> > Or are these cards broken?

Kind regards,
	Sven

[-- Attachment #1.1.2: qmi_wlanfw_cap_resp_msg_v01_ei.bin --]
[-- Type: application/octet-stream, Size: 165 bytes --]

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

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

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

RE: ath11k: incorrect board_id retrieval

[Seevalamuthu M (QUIC)]

Hi Sven,

> -----Original Message-----
> From: ath11k <ath11k-bounces@lists.infradead.org> On Behalf Of Sven
> Eckelmann
> Sent: Friday, November 26, 2021 8:18 PM
> To: ath11k@lists.infradead.org
> Subject: ath11k: incorrect board_id retrieval
> 
> WARNING: This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
> 
> Hi,
> 
> I've noticed that manufacturers of cards gave me various information what
> board_id they expected a device (QCN9074) is detected as. But ath11k only
> retrieves the board id as 0xff - thus the ath11k driver is always loading the
> wrong BDF. Commercially available boards with a problem like this are:
> 
> * 8devices Pineapple
>   - 2GHz: 160 (0xa0)
>   - 5GHz: 161 (0xa1)
>   - 6GHz: 162 (0xa2)
> * Compex WLE3000H5
> * (maybe there is not a single one which works?)
> 
> If I would use these boards in one with a devicetree then I could just
> overwrite it using qcom,board_id (and/or qcom,ath11k-calibration-variant).
> But this isn't the case when I want to use a couple of these cards in a simple
> x86 system. All off them (even when they are significantly different) are
> reported as
> 
>     ath11k_pci 0000:03:00.0: chip_id 0x0 chip_family 0x0 board_id 0xff soc_id
> 0xffffffff
> 
> So I would have to hack the driver to implement my own (pci id? based)
> board.bin retrieval code.
> 
> 
> So my question would be: Is the ath11k based board_id retrieval just
> broken?
> Or are these cards broken?


[seevalam] : Incase of QCN9074 in x86 setup, need to program OTP with board_id. Please fuse board id in OTP and try.

> 
> 
> The way the firmware is initialized definitely changed between ath10k and
> ath11k. Previously, the otp.bin took care of retrieving the (pre-cal) data from
> the EEPROM/OTP on the card or retrieved it via driver from the host systems
> flash/filesystem. And then the otp.bin was reporting the board_id to the
> driver. Based on that, the driver was able to select the correct BDF.
> 
> But now, the firmware is started and immediately afterwards, it is already
> asked to report the target capabilities. And the target capabilities are
> including the board_id - the part which doesn't seem to work correctly. Only
> after that, the driver sends the BDF + (pre)caldata. So the firmware (if the
> precaldata comes from the flash/filesystem) doesn't have the chance to get
> the board_id [1] from the (pre)caldata. Which sounds wrong to me. But I
> have no access to anything which would allow me to check how it should
> actually work.
> 
> Kind regards,
>         Sven
> 
> [1] i think it was the refDesignId, projectId or something like this in ath10k
> 
> 
> 
> --
> ath11k mailing list
> ath11k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath11k[seevalam] 

Regards,
Seevalamuthu M

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

Re: ath11k: incorrect board_id retrieval

[Sven Eckelmann]

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

On Wednesday, 15 December 2021 18:42:13 CET Seevalamuthu M (QUIC) wrote:
> [seevalam] : Incase of QCN9074 in x86 setup, need to program OTP with board_id. Please fuse board id in OTP and try.

Thank you for the confirmation. So it seems like 8devices and Compex aren't 
correctly setting the OTP for board_id retrieval when 
they manufacture the card. Which basically breaks the retrieval of the
correct BDF (especially when having cards with different board_ids in the 
device).

I am now just guessing that it is the same for WCN6855 v2.0 - which would mean 
that EmWicon/jjPlus are also not correctly initializing the OTP.

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: 102 bytes --]

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

Re: ath11k: incorrect board_id retrieval

[Sven Eckelmann]

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

On Friday, 26 November 2021 15:48:17 CET Sven Eckelmann wrote:
[...]
> * 8devices Pineapple
>   - 2GHz: 160 (0xa0)
>   - 5GHz: 161 (0xa1)
>   - 6GHz: 162 (0xa2)
> * Compex WLE3000H5
> * (maybe there is not a single one which works?)
> 
> If I would use these boards in one with a devicetree then I could just 
> overwrite it using qcom,board_id (and/or qcom,ath11k-calibration-variant). But 
> this isn't the case when I want to use a couple of these cards in a simple x86 
> system. All off them (even when they are significantly different) are reported
> as
> 
>     ath11k_pci 0000:03:00.0: chip_id 0x0 chip_family 0x0 board_id 0xff soc_id 0xffffffff

I've send my 6GHz modules back to 8devices. They told me that this problem was 
identified and fixed in their calibration process. I've just got them back 
from them and now I see following reported by ath11k:

    ath11k_pci 0000:03:00.0: chip_id 0x0 chip_family 0x0 board_id 0xa2 soc_id 0xffffffff

So it is definitely not a firmware problem and it should be fixed by the 
manufacturers (similar to what 8devices did).

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: 102 bytes --]

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

Re: ath11k: incorrect board_id retrieval

[Kalle Valo]

Sven Eckelmann <sven@narfation.org> writes:

> On Friday, 26 November 2021 15:48:17 CET Sven Eckelmann wrote:
> [...]
>> * 8devices Pineapple
>>   - 2GHz: 160 (0xa0)
>>   - 5GHz: 161 (0xa1)
>>   - 6GHz: 162 (0xa2)
>> * Compex WLE3000H5
>> * (maybe there is not a single one which works?)
>> 
>> If I would use these boards in one with a devicetree then I could just 
>> overwrite it using qcom,board_id (and/or qcom,ath11k-calibration-variant). But 
>> this isn't the case when I want to use a couple of these cards in a simple x86 
>> system. All off them (even when they are significantly different) are reported
>> as
>> 
>>     ath11k_pci 0000:03:00.0: chip_id 0x0 chip_family 0x0 board_id 0xff soc_id 0xffffffff
>
> I've send my 6GHz modules back to 8devices. They told me that this problem was 
> identified and fixed in their calibration process. I've just got them back 
> from them and now I see following reported by ath11k:
>
>     ath11k_pci 0000:03:00.0: chip_id 0x0 chip_family 0x0 board_id 0xa2 soc_id 0xffffffff
>
> So it is definitely not a firmware problem and it should be fixed by the 
> manufacturers (similar to what 8devices did).

So the device is working fine now?

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

Re: ath11k: incorrect board_id retrieval

[Sven Eckelmann]

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

On Wednesday, 13 April 2022 09:01:49 CEST Kalle Valo wrote:
> Sven Eckelmann <sven@narfation.org> writes:
> 
> > On Friday, 26 November 2021 15:48:17 CET Sven Eckelmann wrote:
> > [...]
> >> * 8devices Pineapple
> >>   - 2GHz: 160 (0xa0)
> >>   - 5GHz: 161 (0xa1)
> >>   - 6GHz: 162 (0xa2)
> >> * Compex WLE3000H5
> >> * (maybe there is not a single one which works?)
> >> 
> >> If I would use these boards in one with a devicetree then I could just 
> >> overwrite it using qcom,board_id (and/or qcom,ath11k-calibration-variant). But 
> >> this isn't the case when I want to use a couple of these cards in a simple x86 
> >> system. All off them (even when they are significantly different) are reported
> >> as
> >> 
> >>     ath11k_pci 0000:03:00.0: chip_id 0x0 chip_family 0x0 board_id 0xff soc_id 0xffffffff
> >
> > I've send my 6GHz modules back to 8devices. They told me that this problem was 
> > identified and fixed in their calibration process. I've just got them back 
> > from them and now I see following reported by ath11k:
> >
> >     ath11k_pci 0000:03:00.0: chip_id 0x0 chip_family 0x0 board_id 0xa2 soc_id 0xffffffff
> >
> > So it is definitely not a firmware problem and it should be fixed by the 
> > manufacturers (similar to what 8devices did).
> 
> So the device is working fine now?

8devices Pineapple (after RMA) - yes.

For Compex WLE3000H5 - not that I would know about any fixed HW revision.

And for the EmWicon WMX7205/jjPlus WMX7205, it seems like the 
vendor=17cb,device=1103,subsystem-vendor=17cb,subsystem-device=0108 is used 
for identification of the actual vendor/product [0] (and not the board_id like 
on other devices). But as you can see, they say that it 
is a QCA product while it actually isn't actually one

And the manufacturer is also not able to provide a BDF which is compatible 
(signed? [1]) for the usage with ath11k's firmware blob.

Kind regards,
	Sven

[0] https://lore.kernel.org/all/CACT4oud4hmkjrAPkOr0sG1DNNgcgQaKT2JNJzcivZey9b5Hpiw@mail.gmail.com/
[1] https://lore.kernel.org/all/DM6PR02MB69248F37B55ACCC868F8B82BE0769@DM6PR02MB6924.namprd02.prod.outlook.com/

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

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

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k