Compatibility Check for IW611 WLAN Driver/Firmware and WPA Supplicant 2.12 with Yocto Nanbield

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Compatibility Check for IW611 WLAN Driver/Firmware and WPA Supplicant 2.12 with Yocto Nanbield

840 Views
Ram2
Contributor III

Hi NXP Support Team,

As part of our ongoing BSP integration on the i.MX8QXP platform using the Yocto Nanbield release, we are evaluating the below WLAN driver/firmware package and WPA supplicant version for compatibility:

  • Driver-Firmware: SD-WLAN-UART-BT-IW611-LNX_6_12_20-IMX8-18.99.3.p25.10-18.99.3.p25.10-MM6X18537.p15-GPL

  • WPA Supplicant Version: wpa_supplicant_2.12

We would like your guidance on the following:

  1. Are the above versions officially compatible with the Yocto Nanbield release (and its respective kernel version)?

  2. Are there any known limitations or regressions if we integrate this driver/firmware and wpa_supplicant_2.12 into Nanbield?

  3. Are there any preferred or recommended versions of the WLAN driver/firmware and WPA supplicant specifically validated for Nanbield?

Please let us know if additional testing or patches are required when using these versions in the Nanbield environment.

Looking forward to your confirmation and guidance

0 Kudos
Reply
12 Replies

216 Views
Rita_Wang
NXP TechSupport
NXP TechSupport

@weidong_sun Could you help check again, for the update from customer, great thanks~~

0 Kudos
Reply

798 Views
weidong_sun
NXP TechSupport
NXP TechSupport

Dear @Ram2 ,

 

Hope you are doing well!

According to your description, you have 2 requirements:

  • SD-WLAN-UART-BT-IW611-LNX_6_12_20-IMX8-18.99.3.p25.10-18.99.3.p25.10-MM6X18537.p15-GPL
  • wpa_supplicant 2.12

 There are 2 methods for you.

1. Using  LF6.6.3_1.0.0 bsp  for Yocto Project 4.3 (Nanbield)

In the bsp, WiFi driver version is :

• BSP version: Linux 6.6.3-1.0.0
• Wi-Fi and Bluetooth/Bluetooth LE Firmware version: 18.99.2.p66.17
• Driver version: MM6X18437.p3-GPL

wpa_supplicant version should be v2.10

(1) Compile WiFi driver and wpa_supplicant 2.12 separately, and then replace the original ones in the image.

(2) you can try to integrate them to the Yocto Version, no limitations.

2. Using  LF6.12.20_2.0.0 bsp  for Yocto Project 5.2 (Walnascar)

The bsp version is the latest one, it has includes driver you want to use.

SD-WLAN-UART-BT-IW611-LNX_6_12_20-IMX8-18.99.3.p25.10-18.99.3.p25.10-MM6X18537.p15-GPL

But in the bsp, wpa_supplicant is v2.11,  you can try to replace it with v2.12 if you can get corresponding wpa_supplicant-2.12.bb

 

 

Thanks!
Regards,

weidong

0 Kudos
Reply

690 Views
Ram2
Contributor III

Hi @weidong_sun 

We have cloned . Using  LF6.12.20_2.0.0 bsp  for Yocto Project 5.2 (Walnascar)
But didnt find the rite path where exactly the nxp wifi recipe in latest one

2. we have tried to implement bbappend as well on top of existing the 6.6.3 but still its picking older moal.ko and mlan.ko due to packages , since its getting updated with latest .ko

Could you please provide integration yocto recipe steps for it or helpful inputs from your end so we can acheive to integrate it 

0 Kudos
Reply

679 Views
weidong_sun
NXP TechSupport
NXP TechSupport

Hello @Ram2 ,

 

See the .bb file in yocoto source folder.

# cd source

./meta-freescale/recipes-kernel/kernel-modules/kernel-module-nxp-wlan_git.bb

......

SRCBRANCH = "lf-6.6.52_2.2.0"
MRVL_SRC ?= "git://github.com/nxp-imx/mwifiex.git;protocol=https"

......

The driver is patched based on the version for lf-6.6.52_2.2.0. and then verified on L6.12.20 kernel.

For your application, LF6.12.20_2.0.0 bsp is no problem,  no need to focus on it, in the latest Linux bsp, always the latest Wi-Fi driver version is supported.

As for wpa_supplicant-2.11 or wpa_supplicant-2.12, I think both are OK, but wpa_supplicant-2.11 has been ready in default bsp, no need to change it to ver 2.12. Just my personal opinion for you.

 

>>we have tried to implement bbappend as well on top of existing the 6.6.3 but still its picking older moal.ko and mlan.ko due to packages , since its getting updated with latest .ko

Actually you can also build the latest Wi-Fi driver independently, get 2 .ko files , then replace old 2 .ko files, the method is more flexible.

 

Thanks!

Regards,

weidong

 

0 Kudos
Reply

642 Views
Ram2
Contributor III

Hi @weidong_sun 

Thanks for reply

Just wanted to inform that I have followed as you informed
Cloned separetely driver and generated driver .ko files and replaced in target
when I reboot I see kernel panic I m not sure why its is can you please help me with flow to proceed furtherwifi-crash-logs-1.pngwifi-crash-3.pngwifi-crash-2.png
Do you see any dependecny
1. My work around was just generatred .ko files first and instead of building in yocto
2. First I have done scp to target to replaced with latest .ko files 
i.e under cp -rf moal.ko /usr/lib/modules/6.6.3-lts-next-gd4e47fe015ab/updates/     
                cp -rf mlan.ko /usr/lib/modules/6.6.3-lts-next-gd4e47fe015ab/updates/  
 
Please find the logs pasted

0 Kudos
Reply

613 Views
weidong_sun
NXP TechSupport
NXP TechSupport

Hi @Ram2 ,

 

Follow the steps below to make a test, please!

===========================

1. Building default Yocto bsp to create images for you board.

2.. Downloading images you built and starting your board.

3.. Building the  wifi driver you want to use.

-- Kernel directory should be like this:

tmp/work/imx8mm_ddr4_evk-poky-linux/linux-imx/6.6.52+git/build

##export KERNELDIR= ....(absolute path)...  input it using your pat

--Setting cross compilation environment, should be like this:

# source /opt/fsl-imx-wayland/6.6-nanbield/environment-setup-armv8a-poky-linux

[Note]

Toolchain should be the one you exported from yocto source  (populate_sdk), it menas you your image  and wifi driver must be built using the same cross compiler.

--Copying mlan.ko & moal.ko after building wifi driver to your board home directory.

--Copying companion firmware of the version of wifi driver to board (/lib/firmware/nxp)

4.. Loading Wi-Fi driver on your board.

# cd ~/

# insmod mlan.ko

# insmod moal.ko mod_para=nxp/wifi_mod_para.conf

Don't use modprobe command, it will load default wifi driver in image, NOT yours.

===========================

 

Try it, please!
Thanks!

Regards,

weidong

 

0 Kudos
Reply

828 Views
Rita_Wang
NXP TechSupport
NXP TechSupport

Which linux BSP version are you using? For the i.MX8QXP board you using the board you design yourself or the NXP board? Thanks.

0 Kudos
Reply

825 Views
Ram2
Contributor III

Hi @Rita_Wang 

 

BSP Version : L6.6.3 
Yocto : Nanbield
iMX8QXP :  Is NXP but its custom board its a designed target

0 Kudos
Reply

809 Views
Rita_Wang
NXP TechSupport
NXP TechSupport

I help creat case 00724744 to our Wifi team engineer, they will give you update there as soon as possible.

0 Kudos
Reply

822 Views
Rita_Wang
NXP TechSupport
NXP TechSupport

I will help confirm it.

0 Kudos
Reply

237 Views
Ram2
Contributor III

Dear NXP Team,

As per your suggestion, we have been following the recommended steps to rebuild and load the NXP Wi-Fi driver mlan.ko, moal.ko against the Yocto BSP kernel. On our local builds the process works correctly — the .ko modules load without error when inserted using insmod.

However, when the same procedure is executed in our CI pipeline (different build host), we observe a mismatch in the kernel release string (uname -r) and the vermagic embedded in the .ko files.

Local build (working):

  • uname -r: kernel-module-mlan-6.6.3-lts-next-gd4e47fe015ab_git-r0_arm64.deb

  • but your layer is producing:
    vermagic (mlan/moal): kernel-module-mlan-6.6.3-lts-next-gd4e47fe015ab_git-r0_arm64.deb

  • Modules load correctly.

CI build (failing):

  • uname -r: 6.6.3-lts-next-g88dffeae470f

  • vermagic (mlan/moal): kernel-module-mlan-6.6.3-lts-next-g<hash>_1.0-r0_arm64.deb

  • insmod fails with Unknown symbol errors.

  • Root cause: the kernel in CI has CONFIG_LOCALVERSION_AUTO=y, which appends a git hash (-g88dffeae470f) to the release string, while our Wi-Fi driver is compiled expecting a fixed localversion.

Because of this difference, the same Wi-Fi driver sources behave differently across local and CI builds.

Our questions:

  1. What is the recommended way from NXP side to ensure a consistent kernel release string between BSP kernel and external Wi-Fi modules (across different build environments)?

    • Should we always fix CONFIG_LOCALVERSION and disable CONFIG_LOCALVERSION_AUTO?

    • Or is there an alternate NXP-recommended approach to build out-of-tree Wi-Fi modules in a reproducible way?

  2. The moal.ko driver also reports missing PM/QoS symbols when built against the CI kernel (e.g., cpu_latency_qos_add_request, device_wakeup_enable). Locally we enabled CONFIG_PM, CONFIG_PM_SLEEP, CONFIG_PM_RUNTIME, and CONFIG_PM_QOS, which resolves the issue. Could you please confirm if these kernel options are mandatory for moal?

We would like to stabilize this build process so the Wi-Fi driver works reliably across both local development and CI builds. Please guide us on the best practice to align kernel build config and Wi-Fi driver integration.

Error we are facing like :
mlan: disagrees about version of symbol module_layout
moal: disagrees about version of symbol module_layout

Please help us to unblock asap 
Since it is a blocker 

0 Kudos
Reply

210 Views
weidong_sun
NXP TechSupport
NXP TechSupport

Dear @Ram2 ,

 

This is a very common problem, and can usually be addressed as follows:
1. Disable CONFIG_LOCALVERSION_AUTO in CI
CONFIG_LOCALVERSION_AUTO=n
2. Set a fixed CONFIG_LOCALVERSION
CONFIG_LOCALVERSION="-gd4e47fe015ab_git-r0"
[Note]
This can be done by:
Editing defconfig or .config directly.
Or appending to your Yocto kernel recipe:
KERNEL_LOCALVERSION = "-gd4e47fe015ab_git-r0"
3. Using the same .config for kernel configuration (Local & CI)
OR
4. Copying your local_config (.config) to Yocto on the CI side, and in Yocto like this:

SRC_URI += "file://local_config"
do_configure_prepend() {
cp ${WORKDIR}/local_config ${S}/.config

OR
5. Using the same kernel source on both local and CI sides


We do not officially provide a standard method.

 

Thanks!

Regards,

weidong