Hi David and Sean,
I am considering using the Murata WiFi module LBWA1KL1FX which is
based on the CYW43364 / Broadcom BCM43364 Chipset.
Our design criteria is that it must be supported by mainline Linux.
Searching kernel log file to find that you added bcm43364 wireless
chipset to broadcom/brcm80211/brcmfmac driver, could you please advise
how stable and reliable to run brcm80211/brcmfmac for CYW43364 /
Broadcom BCM43364 Chipset?
In addition to add CONFIG_BRCMFMAC and CONFIG_BRCMFMAC_SDIO, should I
also add CONFIG_BRCMFMAC_PROTO_MSGBUF, CONFIG_DMI,
CONFIG_BRCMFMAC_PROTO_BCDC and CONFIG_OF?
Thank you very much.
Kind regards,
Jupiter
+ Kalle
On 4/5/2022 5:02 AM, Jupiter wrote:
> Hi David and Sean,
>
> I am considering using the Murata WiFi module LBWA1KL1FX which is
> based on the CYW43364 / Broadcom BCM43364 Chipset.
>
> Our design criteria is that it must be supported by mainline Linux.
> Searching kernel log file to find that you added bcm43364 wireless
> chipset to broadcom/brcm80211/brcmfmac driver, could you please advise
> how stable and reliable to run brcm80211/brcmfmac for CYW43364 /
> Broadcom BCM43364 Chipset?
Is Murata providing you with firmware or just the hardware.
> In addition to add CONFIG_BRCMFMAC and CONFIG_BRCMFMAC_SDIO, should I
> also add CONFIG_BRCMFMAC_PROTO_MSGBUF, CONFIG_DMI,
> CONFIG_BRCMFMAC_PROTO_BCDC and CONFIG_OF?
I would suggest using menuconfig as it already answers some if not all
of these. CONFIG_DMI and CONFIG_OF are really depending on your platform.
Regards,
Arend
Hi Arend,
Thanks for your response.
>> Our design criteria is that it must be supported by mainline Linux.
>> Searching kernel log file to find that you added bcm43364 wireless
>> chipset to broadcom/brcm80211/brcmfmac driver, could you please advise
>> how stable and reliable to run brcm80211/brcmfmac for CYW43364 /
>> Broadcom BCM43364 Chipset?
>
> Is Murata providing you with firmware or just the hardware.
Good question, we'll buy Murata hardware and we'll use Murata firmware
in linux-firmware so we can run Yocto to build WiFi to the image using
mainline Linux, linux-firmware and other open sources.
I've just checked the firmware, there is no bcm43364 binary in
linux-firmware, only bcm43362 links to cyfmac43362-sdio.bin, is the
cyfmac43362-sdio.bin the right firmware for Murata WiFi module
LBWA1KL1FX (CYW43364 / BCM43364 Chipset)? If not, where is the right
Murata WiFi module LBWA1KL1FX firmware in linux-firmware?
The Broadcom did very good job to support mainline Linux, Cypress
acquired Broadcom wireless IoT, Infineon acquired Cypress wireless,
has anyone known if the Infineon is committed to continually maintain
and support CYW43364 / BCM43364 Chipset driver and firmware in
mainline Linux and linux-firmware?
There is a wired backward tendency in recent years, large vendors
acquired wireless sectors then stopped supporting open source and
mainline Linux, switched its wireless sources to use its proprietary
Linux and SDK. Our original design was using Marvell Avastar 88W8801
chipset, the driver mwifiex and wifiex_sdio worked well for kernel 4,
but after NXP acquired Marvell wireless sector, NXP stopped supporting
mainline Linux, the kernel 5 mwifiex cannot communicate to 88W8801
chipset firmware, we were told to use the proprietary Linux driver
sources which is incompatible to our Yocto / OE build system, we have
no choice but to change the WiFi module.
>> In addition to add CONFIG_BRCMFMAC and CONFIG_BRCMFMAC_SDIO, should I
>> also add CONFIG_BRCMFMAC_PROTO_MSGBUF, CONFIG_DMI,
>> CONFIG_BRCMFMAC_PROTO_BCDC and CONFIG_OF?
>
> I would suggest using menuconfig as it already answers some if not all
> of these. CONFIG_DMI and CONFIG_OF are really depending on your platform.
We'll certainly use the menuconfig that is not the issue, our CPU is
iMX6ULZ running on kernel 5.10, apologize we are not familiar with the
CONFIG_DMI and CONFIG_OF, appreciate your advice.
Thank you very much.
Kind regards,
Jupiter
+ Double Lo
On 4/6/2022 9:36 AM, Jupiter wrote:
> Hi Arend,
>
> Thanks for your response.
>
>>> Our design criteria is that it must be supported by mainline Linux.
>>> Searching kernel log file to find that you added bcm43364 wireless
>>> chipset to broadcom/brcm80211/brcmfmac driver, could you please advise
>>> how stable and reliable to run brcm80211/brcmfmac for CYW43364 /
>>> Broadcom BCM43364 Chipset?
>>
>> Is Murata providing you with firmware or just the hardware.
>
> Good question, we'll buy Murata hardware and we'll use Murata firmware
> in linux-firmware so we can run Yocto to build WiFi to the image using
> mainline Linux, linux-firmware and other open sources.
>
> I've just checked the firmware, there is no bcm43364 binary in
> linux-firmware, only bcm43362 links to cyfmac43362-sdio.bin, is the
> cyfmac43362-sdio.bin the right firmware for Murata WiFi module
> LBWA1KL1FX (CYW43364 / BCM43364 Chipset)? If not, where is the right
> Murata WiFi module LBWA1KL1FX firmware in linux-firmware?
Indeed. As Sean stated in his commit message "The BCM43364 uses the same
firmware as the BCM43430 (which is already included), the only
difference is the omission of Bluetooth".
So for BCM43364 the brcmfmac driver will load brcmfmac43430-sdio.bin.
Now it can be that the Murata WiFi module would need dedicated firmware
that Murata provides. If your project/design is device-tree based
(likely if it is a IMX6 ARM-based SoC) your device-tree will have a
boardname and brcmfmac would try to find
brcmfmac43430-sdio-<boardname>.bin or something like that. If not
present it will fallback to the generic firmware mentioned earlier.
> The Broadcom did very good job to support mainline Linux, Cypress
> acquired Broadcom wireless IoT, Infineon acquired Cypress wireless,
> has anyone known if the Infineon is committed to continually maintain
> and support CYW43364 / BCM43364 Chipset driver and firmware in
> mainline Linux and linux-firmware?
Infineon is listed in the MAINTAINERS file so I suppose they are. Hmm,
there was a patch stripping Infineon names from it. I added the author
of that patch to comment.
> There is a wired backward tendency in recent years, large vendors
> acquired wireless sectors then stopped supporting open source and
> mainline Linux, switched its wireless sources to use its proprietary
> Linux and SDK. Our original design was using Marvell Avastar 88W8801
> chipset, the driver mwifiex and wifiex_sdio worked well for kernel 4,
> but after NXP acquired Marvell wireless sector, NXP stopped supporting
> mainline Linux, the kernel 5 mwifiex cannot communicate to 88W8801
> chipset firmware, we were told to use the proprietary Linux driver
> sources which is incompatible to our Yocto / OE build system, we have
> no choice but to change the WiFi module.
>
>>> In addition to add CONFIG_BRCMFMAC and CONFIG_BRCMFMAC_SDIO, should I
>>> also add CONFIG_BRCMFMAC_PROTO_MSGBUF, CONFIG_DMI,
>>> CONFIG_BRCMFMAC_PROTO_BCDC and CONFIG_OF?
>>
>> I would suggest using menuconfig as it already answers some if not all
>> of these. CONFIG_DMI and CONFIG_OF are really depending on your platform.
>
> We'll certainly use the menuconfig that is not the issue, our CPU is
> iMX6ULZ running on kernel 5.10, apologize we are not familiar with the
> CONFIG_DMI and CONFIG_OF, appreciate your advice.
If your using IMX6 you will likely use device-tree as I mentioned
before. So you probably will have CONFIG_OF enabled. OF stands for
OpenFirmware and the kernel functionality is also used handling
flattened device-trees.
Regards,
Arend
+ the other Kalle ;-)
On 4/6/2022 1:56 PM, Arend van Spriel wrote:
> + Double Lo
>
> On 4/6/2022 9:36 AM, Jupiter wrote:
>> Hi Arend,
>>
>> Thanks for your response.
>>
>>>> Our design criteria is that it must be supported by mainline Linux.
>>>> Searching kernel log file to find that you added bcm43364 wireless
>>>> chipset to broadcom/brcm80211/brcmfmac driver, could you please advise
>>>> how stable and reliable to run brcm80211/brcmfmac for CYW43364 /
>>>> Broadcom BCM43364 Chipset?
>>>
>>> Is Murata providing you with firmware or just the hardware.
>>
>> Good question, we'll buy Murata hardware and we'll use Murata firmware
>> in linux-firmware so we can run Yocto to build WiFi to the image using
>> mainline Linux, linux-firmware and other open sources.
>>
>> I've just checked the firmware, there is no bcm43364 binary in
>> linux-firmware, only bcm43362 links to cyfmac43362-sdio.bin, is the
>> cyfmac43362-sdio.bin the right firmware for Murata WiFi module
>> LBWA1KL1FX (CYW43364 / BCM43364 Chipset)? If not, where is the right
>> Murata WiFi module LBWA1KL1FX firmware in linux-firmware?
>
> Indeed. As Sean stated in his commit message "The BCM43364 uses the same
> firmware as the BCM43430 (which is already included), the only
> difference is the omission of Bluetooth".
>
> So for BCM43364 the brcmfmac driver will load brcmfmac43430-sdio.bin.
> Now it can be that the Murata WiFi module would need dedicated firmware
> that Murata provides. If your project/design is device-tree based
> (likely if it is a IMX6 ARM-based SoC) your device-tree will have a
> boardname and brcmfmac would try to find
> brcmfmac43430-sdio-<boardname>.bin or something like that. If not
> present it will fallback to the generic firmware mentioned earlier.
>
>> The Broadcom did very good job to support mainline Linux, Cypress
>> acquired Broadcom wireless IoT, Infineon acquired Cypress wireless,
>> has anyone known if the Infineon is committed to continually maintain
>> and support CYW43364 / BCM43364 Chipset driver and firmware in
>> mainline Linux and linux-firmware?
>
> Infineon is listed in the MAINTAINERS file so I suppose they are. Hmm,
> there was a patch stripping Infineon names from it. I added the author
> of that patch to comment.
>
>> There is a wired backward tendency in recent years, large vendors
>> acquired wireless sectors then stopped supporting open source and
>> mainline Linux, switched its wireless sources to use its proprietary
>> Linux and SDK. Our original design was using Marvell Avastar 88W8801
>> chipset, the driver mwifiex and wifiex_sdio worked well for kernel 4,
>> but after NXP acquired Marvell wireless sector, NXP stopped supporting
>> mainline Linux, the kernel 5 mwifiex cannot communicate to 88W8801
>> chipset firmware, we were told to use the proprietary Linux driver
>> sources which is incompatible to our Yocto / OE build system, we have
>> no choice but to change the WiFi module.
>>
>>>> In addition to add CONFIG_BRCMFMAC and CONFIG_BRCMFMAC_SDIO, should I
>>>> also add CONFIG_BRCMFMAC_PROTO_MSGBUF, CONFIG_DMI,
>>>> CONFIG_BRCMFMAC_PROTO_BCDC and CONFIG_OF?
>>>
>>> I would suggest using menuconfig as it already answers some if not all
>>> of these. CONFIG_DMI and CONFIG_OF are really depending on your
>>> platform.
>>
>> We'll certainly use the menuconfig that is not the issue, our CPU is
>> iMX6ULZ running on kernel 5.10, apologize we are not familiar with the
>> CONFIG_DMI and CONFIG_OF, appreciate your advice.
>
> If your using IMX6 you will likely use device-tree as I mentioned
> before. So you probably will have CONFIG_OF enabled. OF stands for
> OpenFirmware and the kernel functionality is also used handling
> flattened device-trees.
>
> Regards,
> Arend
On Wed, Apr 6, 2022 at 1:09 PM Jupiter <[email protected]> wrote:
> Our original design was using Marvell Avastar 88W8801
> chipset, the driver mwifiex and wifiex_sdio worked well for kernel 4,
> but after NXP acquired Marvell wireless sector, NXP stopped supporting
> mainline Linux, the kernel 5 mwifiex cannot communicate to 88W8801
> chipset firmware, we were told to use the proprietary Linux driver
> sources which is incompatible to our Yocto / OE build system, we have
> no choice but to change the WiFi module.
Despite what corporations tell you, mainline Linux shouldn't be
dropping support for things just because the corporation moved on. If
you can track down the mwifiex regression (e.g., with bisection),
there's a chance we can fix it. I still see
SDIO_DEVICE_ID_MARVELL_8801 listed in the upstream driver, FWIW.
Unfortunately, without anyone paying attention (Marvell, NXP, ... or
you) that has the hardware, it can be hard to guarantee things stay
working. Hint: while I have (and care about) several Marvell chips, I
don't have that one.
Brian
Hi Brian,
Thanks for your response and comments.
> Despite what corporations tell you, mainline Linux shouldn't be
> dropping support for things just because the corporation moved on. If
> you can track down the mwifiex regression (e.g., with bisection),
> there's a chance we can fix it. I still see
> SDIO_DEVICE_ID_MARVELL_8801 listed in the upstream driver, FWIW.
As an open source advocate, I am keen to debug and to track it down,
but to be honest, we have a very small embedded development team here,
no one has deep knowledge and skill for kernel work, nor is anyone
familiar with git bisect for debugging an embedded device. We can run
our embedded board on console to debug the issue, but we do need
experienced kernel developers to guide us to run git bisect, we tried
last time, it did not work, if you are willing to help and if you are
patient, we can start a new debug thread to work it out.
Another issue, it is not just kernel 5.10 mwifiex driver has been
changed, the version of sd8801_uapsta.bin was also updated to
W14.68.36.p204 by Ganapathi Bhat <[email protected]> who moved to NXP
but soon resigned from NXP we could not contact to Ganapathi. We don't
believe Ganapathi tested the new version firmware with kernel 5.10
driver well, we don't know if it is a driver issue or firmware issue,
it is very hard to debug two moving targets broken in protocol,
especially we could not see the source of firmware. We did test
5.10.81 mwifiex driver with different versions of sd8801_uapsta.bin,
then just found out that different versions of firmware have different
communication issues, so we had no choice but to give up the debug
efforts. In that sense, we don't know if the git bisect would be
effective to resolve this problem.
> Unfortunately, without anyone paying attention (Marvell, NXP, ... or
> you) that has the hardware, it can be hard to guarantee things stay
> working. Hint: while I have (and care about) several Marvell chips, I
> don't have that one.
We did spend a large amount of resources and time debugging and we
raised mwifiex issues many times to this list, unfortunately we did
not get any response until now. If anyone is interested in debugging
it, I'll devote myself to working it out, we are in downunder in
different time zones.
Thank you very much.
Kind regards,
Jupiter
Hi Jupiter,
On Thu, Apr 7, 2022 at 12:08 AM Jupiter <[email protected]> wrote:
> Another issue, it is not just kernel 5.10 mwifiex driver has been
> changed, the version of sd8801_uapsta.bin was also updated to
> W14.68.36.p204 [...]
I wouldn't be surprised if Marvell/NXP provided "updated" firmware (to
fix some CVE) but didn't actually test it with mainline Linux, or at
least not very well. If you're interested in bisecting, I'd stick to
the old firmware if I were you. But it sounds like maybe you aren't
well-equipped to do useful bisecting, so maybe that won't go anywhere.
> We did spend a large amount of resources and time debugging and we
> raised mwifiex issues many times to this list, unfortunately we did
> not get any response until now. If anyone is interested in debugging
> it, I'll devote myself to working it out, we are in downunder in
> different time zones.
I see several conversations where you did eventually get *some* responses:
Re: mwifiex reset buggy
https://lore.kernel.org/linux-wireless/[email protected]/
Re: Failed to can wifi Invalid Sched_scan parameters
https://lore.kernel.org/linux-wireless/CAD=FV=XMR33LONcyuvfLzJNd7vKB7vmiE1VSC_QArXA+Hy4Nsw@mail.gmail.com/
It seems like in those cases, people (rightfully, for this forum)
expected you to be able to do a bit more heavy lifting on
understanding what precisely is going on (e.g., what kind of
supplicant configuration is involved? did this particular environment
(AP, etc.) work previously?).
Unfortunately, it's not easy to remotely debug for you, and in some
cases, we really can't answer your questions for you. For instance,
some questions probably can't be answered without either:
(a) bisection or
(b) source code or documentation for firmware (most of us don't have this).
If you're looking for a higher level support than the limited free
support you get from random people on linux-wireless, then mwifiex
might not be right for you, and you should indeed look for different
hardware.
All I was saying is that if it previously worked well (with a given
firmware, mainline kernel, hardware, and RF environment), then it
should be _possible_ to get it working again. I didn't say it would be
easy.
Regards,
Brian