wcn3990 firmware

[Dmitry Baryshkov]

On Wed, 2 Aug 2023 at 19:45, Kalle Valo <kvalo at kernel.org> wrote:
>
> 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?

As we are nearly ready to send a pull request to linux-firmware, I
wanted to check if the following commit ([1]) is fine with you. An
alternative approach would be to push wlanmdsp.mbn as
ath10k/WCN3990/wlanmdsp-something.mbn and add two symlinks, from
qcom/qcm2290 and qcom/qrb4210.

As a reminder, the wlanmdsp.mbn is not loaded directly via remoteproc
/ firmware loader, but instead it is loaded by the modem DSP using
tqftp protocol (and tqftpserv will load it from the directory with
modem.mbn).

[1] https://github.com/lumag/linux-firmware/commit/f29e3265b02430630222fb3aba8b76ebcba632be

-- 
With best wishes
Dmitry