AIROC™ Wi-Fi and Wi-Fi Bluetooth Combos

Hi all,

Noticed the "Test Environment" in the https://community.infineon.com/gfawx74859/attachments/gfawx74859/WiFiBluetoothLinux/1911/2/cypress-fmac-v5.4.18-2021_0527.zip.

I'm curious about the criteria of kernel revision selection. Could you help me to understand it?

I would like to build a exactly the same test environment. Could you please share following (or more) detailed info?

• The hardware of ARM (MCIMX6SX-SDB) and X86
  • The model
• The software of ARM (MCIMX6SX-SDB) and X86
  • The OS and it's revision
  • The FW/image or SDK for i.MX6?

"Test Environment
----------------
* ARM (MCIMX6SX-SDB)
        * Linux v4.14.78 (NXP imx_4.14.78_1.0.0_ga)
        * backports
* x86
        * Linux v4.12
        * backports

"

Thanks,

David Zou

Hi,

We have a number of existing products that are using the CYW43430 (Murata 1DX) and are in need of retesting to suit RED (Declaration of Conformity for European Union’s Radio Equipment Directive) and EN301 EU requirements. This will shortly prevent our client from selling current product into the EU. We were using the test blobs and scripts from Murata but the check the test house cannot perform is the  modulated Bluetooth LE test with the ability to vary the transmit power.  Murata suggested we contact you for update blobs and whatever.

 Thanks.

Hello everybody,

I am trying to use brcmfmac for wifi/Bluetooth combo chip Cypress CYW89359(chip id 4359). Till now, I use the bcmdhd driver provided by U-Blox.

To load the bcmdhd driver, currently I use these parameters (in /etc/modprobe.d/jody-w1-driver-sdio.conf):

options jody_w1_sdio firmware_path=/lib/firmware/brcm/jody-w1-sdio/fw_bcmdhd_RSDB.bin nvram_path=/lib/firmware/brcm/jody-w1-sdio/jody-w163-04a.nvram clm_path=/lib/firmware/brcm/jody-w1-sdio/4359b1.clm_blob

To build the new brcmfmac driver, I followed these instructions:

https://github.com/Infineon/ifx-linux-wireless/

Unfortunately, I fail to bring up a working wlan0 device!

• In the package, v5.4.18 there is a brcmfmac4359-sdio.bin firmware file under.
  • cypress-fmac-v5.4.18/firmware/
• In the package, cypress-fmac-v5.10.9-2021, there is no “..4359-sdio..” anymore.
  
  • All files were renamed to cypress-fmac.. under cypress-fmac-v5.10.9-2021/firmware/

I would have expected a file to exist there, as under point 18 in “release notes”, support for my chip was added:

https://github.com/Infineon/ifx-linux-wireless/blob/master/RELEASE.md

v5.10.9-2022_0511: brcmfmac: add support for BCM4359 SDIO chipset [v5.6-rc1]

But in the same release, there was no firmware file for 4359 available any more.

After a long search, I found this: So CYW/BCM89359 is not (anymore?) supported?:

https://de.osdn.net/projects/immortalwrt/scm/git/immortalwrt/commits/52de8bf86e616de1b86ec2ab5e874029339adb16

“cypress firmware: drop several packages

1. Drop package: cypress-firmware-4359-pcie
   This binary is no longer provided and there are not many details what
   happened.
2. Drop package: cypress-firmware-4359-sdio
   This binary is no longer provided, but in this case, to compare it with
   PCIe package mention as first, there was added
   support in Linux-firmware [1], but no sign of firmware file.
3. Drop package: cypress-firmware-89459-pcie [2]
   According to Infineon: "CYW89459 is an automotive Wi-Fi chip which is not
   supported in the broad market community."

So my question: Is CYW89359 not supported (anymore)?

Even when I had the 4359-sdio.bin firmware file, I still needed to get a 4359-sdio.txt file. The driver was loaded then and a wlan0 device appeared, but unfortunately, I get this error message:

brcmf_fil_cmd_data Firmware error: BCME_UNSUPPORTED (-23)

I found this thread, but it is about bcm4339 and not bcm4359:

https://community.infineon.com/t5/Wi-Fi-Bluetooth-for-Linux/BCM4339-Moving-from-bcmdhd-to-brcmfmac/m-p/123250

Best regards,

Michael

Hello!

We have recently purchased a few Wifi+BT M.2 modules  (with Infineon CYW43439, CYW4373E and CYW43012 controllers, all with SDIO host interface) and are in the process of integrating these modules on IMX's i.MX8ULP-CS EVK with linux kernel version 5.10.104 (and soon 5.15.x).

We have some questions and would appreciate any help that you folks could provide in guiding us in the right direction.

What we have done so far:
=========================

1. Begin with Infineon's march update for the 'brcmfmac' driver shipped (as an 'in-tree' driver) in the linux 5.x kernel sources.
- Update name: cypress-fmac-v5.10.9-2022_0331.zip
- Location: https://community.infineon.com/t5/Wi-Fi-Bluetooth-for-Linux/Cypress-Linux-WiFi-Driver-Release-FMAC-2022-03-31/td-p/342879

2. Apply the contained patches to the 'in-tree' brcmfmac driver (in the linux 5.10.104 kernel) per instructions in the README file contained in the above mentioned update package.

3. Acquire NVRAM settings files from the murata github repo @ https://github.com/murata-wireless/cyw-fmac-nvram ('master' branch). The above referred Infineon update did not provide these files.

4. Use applicable firmware binaries provided in the Infineon update.

4. Ensure that the (now patched) in-tree brcmfmac driver:
- detects all 3 Infineon controllers correctly,
- loads the matching firmware and nvram settings
- exposes a functioning 'mlan0' interface.

5. Ensure successful access point connectivity, along with subsequent basic network connectivity (ssh, scp etc.) tests.

Our questions:
==============

1. Under what licence (OSS or otherwise) are these these patches provided under? The 'cypress-patches' sub directory in the update package does not contain this information.  The COPYING file in that directory does mention the linux kernel licence, so is it safe to assume that same license applies to the patches as well?

2. These patches produce patching errors when applied to a 5.15.x kernel (5.15.47 in our case).  Is there an ETA when these patches will be ported to the 5.15.x kernel?

3. Are we correct in our approach in using the in-tree brcmfmac driver along the murata supplied NVRAM settings file (instead of the 'fmac' driver provided by murata)?

2. Are we correct in using the Infineon supplied firmware binaries or should we be using the ones from murata @ https://github.com/murata-wireless/cyw-fmac-fw ('master' branch)?

3. Are we correct in using the murata supplied NVRAM settings files for the Infineon modules? If not, where should we get these NVRAM settings files?

We are on a tight schedule and would be grateful for any help you folks could provide.

Hello everyone,
I'm customizing Android 6 to fit a SoC that comes with muRata LBEE5KL1DX (CYW4343W).
I successfully embedded Cypress Linux WiFi Driver Release (FMAC) [2022-03-31].
NVRAM file comes from muRata repository, firmware and clm_blob files come from the above archive.
If an access point uses (WPA2-PSK) either TKIP encryption only or its combination, Android sometime takes till 2~3 minutes sometime within few seconds to acquire a dynamic address and establish the connection.
If an access point uses (WPA2-PSK) AES encryption only, Android always connects it within few seconds.
I digged in calling kernel module in this way

     insmod /system/lib/modules/brcmfmac.ko debug=0x00108414

but I didn't achieve good results.
Using TKIP encryption, the board sometime has to receive several dozen of DHCP offers before establish a connection. Using AES encryption, radio quickly connects 10/10 times. The same behaviour using different access points (Sitecom, Digicom, Netgear).
What you think about ?

Thanks in advance for whatever help and best regards.
Alessandro

Hi,

I'm trying to optimize power consumption on our board based on the cyw43907 dev kit. Our device will typically hibernate for a few hours, connect to a server for a few seconds and go back to hibernate. The setup time/consumption when waking up from hibernate is thus important.

I'm measuring peak current of ~700mA when connecting to wifi.

Can we reduce the peak consumption (at a small cost to emission power)? I tried to set wwd_wifi_set_tx_power to 20 instead of the default 31, but it did not change the current.

Thanks,

Cédric

Hi,

I'm trying to make a reasonably fast application on a CYW43907 and am getting a long 5sec delay when getting the reply to an https request.

I'm using cy_http_client.c which uses core_http_client.c

In receiveAndParseHttpResponse the call to   pTransport->recv takes 5secs.

Here is the uart log (I added a few outputs to see where it took some time.

2022-06-14 09:56:47,375,375 INFO COM10: b'[F4] : [L5] : 0042 00:00:07.105 cy_http_client_write_header(): END \r\n'
2022-06-14 09:56:47,375,375 INFO COM10: b'cy_http_client_send\r\n'
2022-06-14 09:56:47,377,377 INFO COM10: b'[F4] : [L5] : 0043 00:00:07.113 cy_http_client_send(): START \r\n'
2022-06-14 09:56:47,378,378 INFO COM10: b'[F4] : [L5] : 0044 00:00:07.118 Acquire object mutex : 0x4c07d8..!\r\n'
2022-06-14 09:56:47,379,379 INFO COM10: b'[F2] : [L4] : 0045 00:00:07.124 sendHttpRequest\r\n'
2022-06-14 09:56:47,383,383 INFO COM10: b'[F2] : [L5] : 0046 00:00:07.128 1F\x8d\xf8\x1f0BF\x16\x9b[F2] : [L5] : 0047 00:00:07.130 1F\x8d\xf8\x1f0BF\x16\x9b[F2] : [L5] : 0048 00:00:07.131 A request body was not sent: pRequestBodyBuf is NULL.[F2] : [L4] : 0049 00:00:07.131 receiveAndParseHttpResponse\r\n'
2022-06-14 09:56:52,435,435 INFO COM10: b'[F2] : [L4] : 0050 00:00:12.206 currentReceived\r\n'
2022-06-14 09:56:52,773,773 INFO COM10: b'[F2] : [L4] : 0051 00:00:12.210 parseHttpResponse\r\n'
2022-06-14 09:56:52,773,773 INFO COM10: b'[F2] : [L5] : 0052 00:00:12.214 Response parsing: Found the start of the response message.[F2] : [L5] : 0053 00:00:12.214 OK\r\n'

It seems it takes 5sec to get the output of: 

currentReceived = pTransport->recv( pTransport->pNetworkContext,
pResponse->pBuffer + totalReceived,
pResponse->bufferLen - totalReceived ); 

Here is the wireshark capture of the exact same exchange, we can see that the device did receive and ack very fast. So it's not a network issue but really a processing issue.

I would guess that there is some error conditions during reception + a 5sec timeout somewhere. But I have not yet digged deeper. 

What could cause this 5sec delay?

Thanks

Cédric