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:
Are the above versions officially compatible with the Yocto Nanbield release (and its respective kernel version)?
Are there any known limitations or regressions if we integrate this driver/firmware and wpa_supplicant_2.12 into Nanbield?
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
Dear @Ram2 ,
Hope you are doing well!
According to your description, you have 2 requirements:
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
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
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
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 further
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
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
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:
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?
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
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