Problems with QCA9377 SDIO on NXP i.MX8MPlus SOM

Problems with QCA9377 SDIO on NXP i.MX8MPlus SOM

[Lukas F. Hartmann]

Hi,

I'm trying to get the QCA9377 SDIO module on Boundary Devices'
i.MX8MPlus SOM working with the ath10k mainline driver (from Linux git
tip). Currently it can scan and see some APs and authenticate, but not
associate (timeout). Several months ago I thought this was an SDIO
signalling issue with the SoC, but I'm not sure anymore, because I fixed
up the qcacld driver for the current Linux kernel and it works fine on
the same system (i.e. I can rmmod ath10k_sdio and insmod wlan.ko and it
works).

I wonder if it is some kind of firmware/driver mismatch. I pasted the
relevant dmesg output after my signature below.

This is after I tried to build my own board-2.bin including bdwlan30.bin
from qcacld-2.0-CNSS.LEA.NRT_3.0 (source:
https://github.com/8devices/qcacld-2.0/tree/CNSS.LEA.NRT_3.0/firmware_bin/sdio).
It gets picked up but doesn't seem to make a difference. I also tried
assembling my own firmware-5-sdio.bin from qwlan30.bin and otp30.bin but
this triggers a firmware crash (with register dump) when loading
ath10k_sdio.ko.

The qcacld driver works with that firmware, though.

Any pointers on how to debug this are most appreciated.

Best
Lukas
-- 
Lukas F. Hartmann, CEO
MNT Research GmbH
https://mntre.com
--

root@reform:~# cat /sys/kernel/debug/mmc1/ios 
clock:		50000000 Hz
actual clock:	50000000 Hz
vdd:		21 (3.3 ~ 3.4 V)
bus mode:	2 (push-pull)
chip select:	0 (don't care)
power mode:	2 (on)
bus width:	2 (4 bits)
timing spec:	7 (sd uhs DDR50)
signal voltage:	1 (1.80 V)
driver type:	0 (driver type B)

output from qcacld in dmesg:

[ 5482.570652] wlan: loading driver v4.5.25.57
[ 5482.575281] hifDeviceInserted: Dumping clocks (50000000,200000000)
[ 5482.770932] ol_download_firmware: chip_id:0x5020001 board_id:0x0
[ 5482.777325] ar6k_wlan mmc1:0001:1: Direct firmware load for bdwlan30.b00 failed with error -2
[ 5482.785885] __ol_transfer_bin_file: Failed to get bdwlan30.b00:-2
[ 5482.791995] __ol_transfer_bin_file: Trying to load default bdwlan30.bin
[ 5482.798961] Board extended Data download address: 0x0
[ 5482.817983] __ol_transfer_bin_file: Loading setup file qsetup30.bin
[ 5482.824316] ar6k_wlan mmc1:0001:1: Direct firmware load for qsetup30.bin failed with error -2
[ 5482.832858] __ol_transfer_bin_file: Failed to get qsetup30.bin:-2
[ 5483.273017] ar6k_wlan mmc1:0001:1: Direct firmware load for wlan/wlan_mac.bin failed with error -2
[ 5483.282584] target uses HTT version 3.58; host uses 3.28
[ 5483.287906] *** Warning: host/target HTT versions are different, though compatible!
[ 5483.295848] Host SW:4.5.25.57, FW:0.0.0.26, HW:QCA93x7_REV1_1
[ 5483.302792] ENTER sme_set_btc_coex_dutycycle = 30
[ 5483.302811] ENTER sme_set_btc_coex_dutycycle =30
[ 5483.308765] ath_hif_sdio: HIF (Atheros/multi-bss)
[ 5483.318575] wlan: driver loaded in 748000

output from ath10k_sdio in dmesg:

[ 4541.308975] ath10k_sdio mmc1:0001:1: qca9377 hw1.1 sdio target 0x05020001 chip_id 0x00000000 sub 0000:0000
[ 4541.318711] ath10k_sdio mmc1:0001:1: kconfig debug 1 debugfs 1 tracing 0 dfs 0 testmode 0
[ 4541.327201] ath10k_sdio mmc1:0001:1: firmware ver WLAN.TF.1.1.1-00061-QCATFSWPZ-1 api 5 features ignore-otp crc32 7746e551
[ 4541.483782] ath10k_sdio mmc1:0001:1: board_file api 2 bmi_id N/A crc32 0708e68d
[ 4542.590752] ath10k_sdio mmc1:0001:1: htt-ver 3.32 wmi-op 4 htt-op 3 cal otp max-sta 32 raw 0 hwcrypto 1
[ 4542.590822] ath10k_sdio mmc1:0001:1: failed to write to address 0x12ff5: -84
[ 4542.607255] ath10k_sdio mmc1:0001:1: failed to write skb to 0x12ff5 asynchronously: -84
[ 4542.763766] mmc1: queuing unknown CIS tuple 0x01 [d9 01 ff] (3 bytes)
[ 4542.778083] mmc1: queuing unknown CIS tuple 0x1a [01 01 00 02 07] (5 bytes)
[ 4542.788463] mmc1: queuing unknown CIS tuple 0x1b [c1 41 30 30 ff ff 32 00] (8 bytes)
[ 4542.796938] mmc1: queuing unknown CIS tuple 0x14 [] (0 bytes)
[ 4542.804476] ath: EEPROM regdomain: 0x0
[ 4542.804481] ath: EEPROM indicates default country code should be used
[ 4542.804484] ath: doing EEPROM country->regdmn map search
[ 4542.804487] ath: country maps to regdmn code: 0x3a
[ 4542.804490] ath: Country alpha2 being used: US
[ 4542.804493] ath: Regpair used: 0x3a
[ 4544.003032] ath10k_sdio mmc1:0001:1: failed to write to address 0x12ff5: -84
[ 4544.010191] ath10k_sdio mmc1:0001:1: failed to write skb to 0x12ff5 asynchronously: -84
[ 4544.231838] mmc1: queuing unknown CIS tuple 0x01 [d9 01 ff] (3 bytes)
[ 4544.246204] mmc1: queuing unknown CIS tuple 0x1a [01 01 00 02 07] (5 bytes)
[ 4544.256610] mmc1: queuing unknown CIS tuple 0x1b [c1 41 30 30 ff ff 32 00] (8 bytes)
[ 4544.265092] mmc1: queuing unknown CIS tuple 0x14 [] (0 bytes)
[ 4545.426883] ath10k_sdio mmc1:0001:1: failed to write to address 0x12ff5: -84
[ 4545.434040] ath10k_sdio mmc1:0001:1: failed to write skb to 0x12ff5 asynchronously: -84
[ 4567.496221] wlan0: authenticate with 48:5d:35:8d:55:12
[ 4567.534325] wlan0: send auth to 48:5d:35:8d:55:12 (try 1/3)
[ 4567.627347] wlan0: authenticate with 48:5d:35:8d:55:12
[ 4567.632620] wlan0: send auth to 48:5d:35:8d:55:12 (try 1/3)
[ 4567.667287] wlan0: authenticated
[ 4567.674326] wlan0: associate with 48:5d:35:8d:55:12 (try 1/3)
[ 4567.680220] ath10k_sdio mmc1:0001:1: failed to write to address 0x12efd: -84
[ 4567.687294] ath10k_sdio mmc1:0001:1: failed to write skb to 0x12efd asynchronously: -84
[ 4568.806313] wlan0: associate with 48:5d:35:8d:55:12 (try 2/3)
[ 4568.812548] ath10k_sdio mmc1:0001:1: failed to write to address 0x12efd: -84
[ 4568.819730] ath10k_sdio mmc1:0001:1: failed to write skb to 0x12efd asynchronously: -84
[ 4569.830306] wlan0: associate with 48:5d:35:8d:55:12 (try 3/3)
[ 4569.836513] ath10k_sdio mmc1:0001:1: failed to write to address 0x12efd: -84
[ 4569.843668] ath10k_sdio mmc1:0001:1: failed to write skb to 0x12efd asynchronously: -84
[ 4570.822310] wlan0: association with 48:5d:35:8d:55:12 timed out
[ 4575.974307] ath10k_sdio mmc1:0001:1: failed to flush transmit queue (skip 0 ar-state 1): 0
[ 4581.094297] ath10k_sdio mmc1:0001:1: failed to flush transmit queue (skip 0 ar-state 1): 0
[ 4581.443674] wlan0: authenticate with 48:5d:35:8d:55:11
[ 4581.448877] wlan0: 80 MHz not supported, disabling VHT
[ 4581.502006] wlan0: send auth to 48:5d:35:8d:55:11 (try 1/3)
[ 4581.607963] wlan0: authenticate with 48:5d:35:8d:55:11
[ 4581.613157] wlan0: send auth to 48:5d:35:8d:55:11 (try 1/3)
[ 4581.640901] wlan0: authenticated
[ 4581.646306] wlan0: associate with 48:5d:35:8d:55:11 (try 1/3)
[ 4581.652315] ath10k_sdio mmc1:0001:1: failed to write to address 0x12f3d: -84
[ 4581.659408] ath10k_sdio mmc1:0001:1: failed to write skb to 0x12f3d asynchronously: -84
[ 4582.790278] wlan0: associate with 48:5d:35:8d:55:11 (try 2/3)
[ 4582.796375] ath10k_sdio mmc1:0001:1: failed to write to address 0x12f3d: -84
[ 4582.803528] ath10k_sdio mmc1:0001:1: failed to write skb to 0x12f3d asynchronously: -84
[ 4583.814279] wlan0: associate with 48:5d:35:8d:55:11 (try 3/3)
[ 4583.821362] ath10k_sdio mmc1:0001:1: failed to write to address 0x12f3d: -84
[ 4583.831060] ath10k_sdio mmc1:0001:1: failed to write skb to 0x12f3d asynchronously: -84
[ 4584.838284] wlan0: association with 48:5d:35:8d:55:11 timed out
[ 4590.054286] ath10k_sdio mmc1:0001:1: failed to flush transmit queue (skip 0 ar-state 1): 0
[ 4595.174331] ath10k_sdio mmc1:0001:1: failed to flush transmit queue (skip 0 ar-state 1): 0
[ 4597.950346] wlan0: authenticate with 48:5d:35:8d:55:12
[ 4597.988680] wlan0: send auth to 48:5d:35:8d:55:12 (try 1/3)
[ 4598.076586] wlan0: authenticate with 48:5d:35:8d:55:12
[ 4598.081867] wlan0: send auth to 48:5d:35:8d:55:12 (try 1/3)
[ 4598.109777] wlan0: authenticated
[ 4598.114288] wlan0: associate with 48:5d:35:8d:55:12 (try 1/3)
[ 4598.120331] ath10k_sdio mmc1:0001:1: failed to write to address 0x12efd: -84
[ 4598.127455] ath10k_sdio mmc1:0001:1: failed to write skb to 0x12efd asynchronously: -84
[ 4598.822274] wlan0: associate with 48:5d:35:8d:55:12 (try 2/3)
[ 4598.828390] ath10k_sdio mmc1:0001:1: failed to write to address 0x12efd: -84
[ 4598.835547] ath10k_sdio mmc1:0001:1: failed to write skb to 0x12efd asynchronously: -84
[ 4599.814254] wlan0: associate with 48:5d:35:8d:55:12 (try 3/3)
[ 4599.820427] ath10k_sdio mmc1:0001:1: failed to write to address 0x12efd: -84
[ 4599.827654] ath10k_sdio mmc1:0001:1: failed to write skb to 0x12efd asynchronously: -84
[ 4600.814891] wlan0: association with 48:5d:35:8d:55:12 timed out

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

Re: Problems with QCA9377 SDIO on NXP i.MX8MPlus SOM

[Kalle Valo]

"Lukas F. Hartmann" <lukas@mntre.com> writes:

> I'm trying to get the QCA9377 SDIO module on Boundary Devices'
> i.MX8MPlus SOM working with the ath10k mainline driver (from Linux git
> tip). Currently it can scan and see some APs and authenticate, but not
> associate (timeout). Several months ago I thought this was an SDIO
> signalling issue with the SoC, but I'm not sure anymore, because I fixed
> up the qcacld driver for the current Linux kernel and it works fine on
> the same system (i.e. I can rmmod ath10k_sdio and insmod wlan.ko and it
> works).
>
> I wonder if it is some kind of firmware/driver mismatch. I pasted the
> relevant dmesg output after my signature below.
>
> This is after I tried to build my own board-2.bin including bdwlan30.bin
> from qcacld-2.0-CNSS.LEA.NRT_3.0 (source:
> https://github.com/8devices/qcacld-2.0/tree/CNSS.LEA.NRT_3.0/firmware_bin/sdio).
> It gets picked up but doesn't seem to make a difference. I also tried
> assembling my own firmware-5-sdio.bin from qwlan30.bin and otp30.bin but
> this triggers a firmware crash (with register dump) when loading
> ath10k_sdio.ko.
>
> The qcacld driver works with that firmware, though.
>
> Any pointers on how to debug this are most appreciated.

Trying significantly older ath10k from an older kernel is something to
try in case there are recent regressions in ath10k.

I don't have an ath10k SDIO device myself so I don't know the state of
SDIO support in ath10k. Does anyone else from the list know?

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

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

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

Re: Problems with QCA9377 SDIO on NXP i.MX8MPlus SOM

[Gary Bisson]

Hi Lukas & Kalle,

On Tue, Jun 13, 2023 at 11:05:14AM +0300, Kalle Valo wrote:
> 
> EXTERNAL EMAIL: Be careful with attachments and links.
> 
> "Lukas F. Hartmann" <lukas@mntre.com> writes:
> 
> > I'm trying to get the QCA9377 SDIO module on Boundary Devices'
> > i.MX8MPlus SOM working with the ath10k mainline driver (from Linux git
> > tip). Currently it can scan and see some APs and authenticate, but not
> > associate (timeout). Several months ago I thought this was an SDIO
> > signalling issue with the SoC, but I'm not sure anymore, because I fixed
> > up the qcacld driver for the current Linux kernel and it works fine on
> > the same system (i.e. I can rmmod ath10k_sdio and insmod wlan.ko and it
> > works).
> >
> > I wonder if it is some kind of firmware/driver mismatch. I pasted the
> > relevant dmesg output after my signature below.
> >
> > This is after I tried to build my own board-2.bin including bdwlan30.bin
> > from qcacld-2.0-CNSS.LEA.NRT_3.0 (source:
> > https://github.com/8devices/qcacld-2.0/tree/CNSS.LEA.NRT_3.0/firmware_bin/sdio).
> > It gets picked up but doesn't seem to make a difference. I also tried
> > assembling my own firmware-5-sdio.bin from qwlan30.bin and otp30.bin but
> > this triggers a firmware crash (with register dump) when loading
> > ath10k_sdio.ko.

As far as I know, the ath10k driver only supports (deprecated) LEH
firmware [1]. That is information I got a long time ago and I can't seem
to find the email back. But basically what I was told is that the LEH &
LEA firmwares had different frames format to exchange data between the
host and the chip, therefore drivers & firmware have to match.
And at that time I was told that ath10k only supported the LEH firmware
for SDIO, which is why we haven't invested much time on it as LEH
firmware is 1) old/deprecated as qcom hasn't updated it for 6 years now
and 2) it contains bugs affecting the performance in our case (diversity
not working etc).

Since I don't have the insight info about the LEA vs. LEH firmware
behavior I'm afraid I can't help much but at least I would say that
trying LEA firmware on ath10k driver is expected to fail (timeout).

Maybe Kalle have more info on the matter and maybe the above doesn't
apply any more and ath10k has evolved to support LEA firmware.

> > The qcacld driver works with that firmware, though.
> >
> > Any pointers on how to debug this are most appreciated.
> 
> Trying significantly older ath10k from an older kernel is something to
> try in case there are recent regressions in ath10k.
> 
> I don't have an ath10k SDIO device myself so I don't know the state of
> SDIO support in ath10k. Does anyone else from the list know?

FYI we have a branch in our repo with the firmware that worked on ath10k
at some point [2].

Regards,
Gary

[1] https://github.com/boundarydevices/qca-firmware/tree/bd-sdmac-qcacld
[2] https://github.com/boundarydevices/qca-firmware/tree/bd-sdmac-ath10k

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

Re: Problems with QCA9377 SDIO on NXP i.MX8MPlus SOM

[Lukas F. Hartmann]

Hi Gary & Kalle,

Gary Bisson <bisson.gary@gmail.com> writes:

>> Trying significantly older ath10k from an older kernel is something to
>> try in case there are recent regressions in ath10k.
>> 
>> I don't have an ath10k SDIO device myself so I don't know the state of
>> SDIO support in ath10k. Does anyone else from the list know?
>
> FYI we have a branch in our repo with the firmware that worked on ath10k
> at some point [2].

Thanks, I looked at this FW now and it is exactly the same as the
"untested" in the ath10k-firmware repo
https://github.com/kvalo/ath10k-firmware/tree/master/QCA9377/hw1.0/untested

So if that worked with ath10k several years ago (when?) I could try to
reconstruct an older version and try to bisect for a regression, though
I imagine it will be complicated to make these old versions work with
APIs that have changed in the meantime in Linux.

Best
Lukas
-- 
Lukas F. Hartmann, CEO
MNT Research GmbH
https://mntre.com

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

Re: Problems with QCA9377 SDIO on NXP i.MX8MPlus SOM

[Bastian Krause]

Hi Lukas and everybody else,

On 6/13/23 17:35, Lukas F. Hartmann wrote:
> Gary Bisson <bisson.gary@gmail.com> writes:
> 
>>> Trying significantly older ath10k from an older kernel is something to
>>> try in case there are recent regressions in ath10k.
>>>
>>> I don't have an ath10k SDIO device myself so I don't know the state of
>>> SDIO support in ath10k. Does anyone else from the list know?
>>
>> FYI we have a branch in our repo with the firmware that worked on ath10k
>> at some point [2].
> 
> Thanks, I looked at this FW now and it is exactly the same as the
> "untested" in the ath10k-firmware repo
> https://github.com/kvalo/ath10k-firmware/tree/master/QCA9377/hw1.0/untested
> 
> So if that worked with ath10k several years ago (when?) I could try to
> reconstruct an older version and try to bisect for a regression, though
> I imagine it will be complicated to make these old versions work with
> APIs that have changed in the meantime in Linux.

I just wanted to check if I understood this correctly and whether this
is still the latest information: The QCA9377 connected via SDIO won't
work with the ath10k driver right now, correct? Neither with [1] nor
with any other known firmware, right?

Thanks for the previous information, by the way. I'm also stuck with a
QCA9377 (Telit module) connected via SDIO and I'm not too keen on using
the qcacld driver. With Kernel 6.5, I see basically the same output as
pasted here [2] with slightly different register dumps.

Regards,
Bastian

[1] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ath10k/QCA9377/hw1.0
[2] https://gist.github.com/mntmn/7d18cba485572bf0690267f37647cacb

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


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

Re: Problems with QCA9377 SDIO on NXP i.MX8MPlus SOM

[w.wadepohl]

We are using a QCA9377 based device (8devices Redbean) with the ath10k 
over SDIO together with kernel 5.10. It works well. We also use qcacld 
for regulative testing purpose. All our patches are mainlined.

Am 04.09.2023 16:28 schrieb Bastian Krause:
> Hi Lukas and everybody else,
> 
> On 6/13/23 17:35, Lukas F. Hartmann wrote:
>> Gary Bisson <bisson.gary@gmail.com> writes:
>> 
>>>> Trying significantly older ath10k from an older kernel is something 
>>>> to
>>>> try in case there are recent regressions in ath10k.
>>>> 
>>>> I don't have an ath10k SDIO device myself so I don't know the state 
>>>> of
>>>> SDIO support in ath10k. Does anyone else from the list know?
>>> 
>>> FYI we have a branch in our repo with the firmware that worked on 
>>> ath10k
>>> at some point [2].
>> 
>> Thanks, I looked at this FW now and it is exactly the same as the
>> "untested" in the ath10k-firmware repo
>> https://github.com/kvalo/ath10k-firmware/tree/master/QCA9377/hw1.0/untested
>> 
>> So if that worked with ath10k several years ago (when?) I could try to
>> reconstruct an older version and try to bisect for a regression, 
>> though
>> I imagine it will be complicated to make these old versions work with
>> APIs that have changed in the meantime in Linux.
> 
> I just wanted to check if I understood this correctly and whether this
> is still the latest information: The QCA9377 connected via SDIO won't
> work with the ath10k driver right now, correct? Neither with [1] nor
> with any other known firmware, right?
> 
> Thanks for the previous information, by the way. I'm also stuck with a
> QCA9377 (Telit module) connected via SDIO and I'm not too keen on using
> the qcacld driver. With Kernel 6.5, I see basically the same output as
> pasted here [2] with slightly different register dumps.
> 
> Regards,
> Bastian
> 
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ath10k/QCA9377/hw1.0
> [2] https://gist.github.com/mntmn/7d18cba485572bf0690267f37647cacb

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