wcn3990 firmware

Kalle Valo kvalo at kernel.org
Wed Aug 2 09:45:47 PDT 2023

Dmitry Baryshkov <dmitry.baryshkov at linaro.org> writes:

> On 02/08/2023 13:28, Kalle Valo wrote:
>> Dmitry Baryshkov <dmitry.baryshkov at linaro.org> writes:
>>> On 24/07/2023 22:38, Dmitry Baryshkov wrote:
>>>> Hello Kalle, colle
>>>> Yet-another firmware question (I remember the standard answer of not
>>>> using firmware not coming from your side). I see that for
>>>> wcn3990/hw1.0 we have wlanmdsp.mbn with the version
>>>> WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1
>>>> We have got the newer wlanmdsp.mbn released under
>>>> redistribution-permissive license (LICENSE.qcom from
>>>> linux-firmware). The file has the version
>>>> WLAN.HL.3.3.7.c2-00723-QCAHLSWMTPLZ-1. It was released for the
>>>> ath10k embedded into Qualcomm QRB2210 / QRB4210 SoCs.
>>> Update: with the current wlanmdsp.mbn I'm getting the following error
>>> from the DSP:
>>> [   22.468121] qcom_q6v5_pas 6080000.remoteproc: fatal error received:
>>> EX:kernel:0x0:SigVerify:0x173:PC=0xc10dd460
>>> The board is not fused, but the signature format was changed (and so
>>> were some of the fields).
>>> It seems we will have to provide the updated file somehow to
>>> linux-firmware. What would be the preferred way for us to do so?
>> I cannot take firmware files from a 3rd party.
> Ack
>> Also I don't follow the
>> WCN3990 firmware development so I can't really comment how that firmware
>> release works with different WCN3990 hardware, board files and/or
>> calibration data.
> It seems to work pretty normal. I have pointed out the only issue we
> have stumbled so far in
> https://bugzilla.kernel.org/show_bug.cgi?id=217748 (the warning during
> scan).
>> But if you think that release should be submitted to
>> linux-firmware that's up to you.
> This obviously means that we should not push it to
> <linux-firmware>/ath10k/WCN3990, correct?

That's the only directory ath10k uses, right? So how would any other
directory work?



More information about the ath10k mailing list