Hello we are attempting to get the WF111 WiFi module running on our IMX6ULEVK board. I'm fairly new to yocto, with first exposure about six weeks ago so I apologize if this is something obvious.
External Build:
1) Enable the following with "bitbake menuconfig virtual/kernel" as per AN996: WF111 LINUX DRIVER INSTALLATION
cfg80211 - wireless configuration API
Generic IEEE 802.11 Networking Stack (mac80211)
IEEE 802.11 for Host AP (Prism2/2.5/3 and WEP/TKIP/CCMP)
2) Build target with "bitbake fsl-image-machine-test"
3) cd $BUILD_DIR/tmp/work-shared/imx6ulevk/kernel-source/; make modules_prepare ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi-
NOTE: cat include/generated/utsrelease.h outputs: #define UTS_RELEASE "3.14.52+"
On my target the kernel version is: 3.14.52-1.1.1_ga+gdb1bcba
4) Change directory to wf111 driver source root.
run: make install_static KDIR=${KERNEL_SRC} ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
NOTE: I get "WARNING: Symbol version dump Module.symvers is missing"
5) scp all files to target in proper location.
NOTE: insmod / modprobe fail with "modprobe: ERROR: could not insert 'unifi_sdio': Exec format error" with dmesg showing "unifi_sdio: no symbol version for module_layout"
6) cp Module.symvers from $BUILD_DIR/tmp/work-shared/imx6ulevk/kernel-build-artifacts/ to $BUILD_DIR/tmp/work- shared/imx6ulevk/kernel-source/
7) repeat step 4
NOTE: I get several warnings about undefined symbols. They are __gnu_mcount_nc, wireless_send_event, __stack_chk_fail, kmem_cache_alloc_trace, and __stack_chk_guard
8) repeat step 5
NOTE: insmod / modprobe fail, dmesg showing "unifi_sdio: version magic '3.14.52+ mod_unload modversions ARMv7 p2v8 ' should be '3.14.52-1.1.1_ga+gdb1bcba SMP preempt mod_unload modversions ARMv7 p2v8 '"
9) modify $BUILD_DIR/tmp/work-shared/imx6ulevk/kernel-source/include/generated/utsrelease.h to be:
#define UTS_RELEASE "3.14.52-1.1.1_+gdb1bcba SMP preempt"
NOTE: yes, I realize this is a poor idea, but I'm out of other ideas.
10) repeat step 4 - get same warnings on undefined symbols
11) repeat step 5 - modprobe: ERROR: could not insert 'unifi_sdio': Unknown symbol in module, or unknown parameter (see dmesg)
NOTE: dmesg shows:
unifi_sdio: Unknown symbol __stack_chk_guard (err 0)
unifi_sdio: Unknown symbol kmem_cache_alloc_trace (err 0)
unifi_sdio: Unknown symbol __stack_chk_fail (err 0)
unifi_sdio: Unknown symbol wireless_send_event (err 0)
unifi_sdio: Unknown symbol __gnu_mcount_nc (err 0)
Integrated Build:
Found a .bb recipe on github for building the wf111 driver source and integrating it into the targets rootfs directly (this is ideal). However it has the same issues as the external build.
In the target filesystem unifi_sdio.ko is located at /lib/modules/3.14.52+/extra/ instead of /lib/modules/3.14.52-1.1.1_ga+gdb1bcba/extra/.
Running insmod on that .ko yields the same "ERROR: could not insert 'unifi_sdio': Exec format error"
The .bb recipe is pasted below:
DESCRIPTION = "WF111 driver and bin utils"
SECTION = "wireless driver"
LICENSE = "CLOSED"
INSANE_SKIP_${PN} = "already-stripped"
DEPENDS += "imx-test"
SRC_URI = " \
file://wf111-linux-driver_5.2.2-r1_armv7-a.tar.gz \
"
do_compile () {
cd ${WORKDIR}/wf111-linux-driver_5.2.2-r1_armv7-a
unset LDFLAG
make install_static KDIR=${STAGING_KERNEL_DIR} ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
}
do_install (){
install -d ${D}
cp -rf ${WORKDIR}/wf111-linux-driver_5.2.2-r1_armv7-a/output/* ${D}
}
FILES_${PN} = "/usr/* \
/lib* "
已解决! 转到解答。
Hello Sam Musso,
My apologies for the delay.
Since the driver was already on a Yocto layer I went the Yocto route (which if I understand correctly is also valid for your scenario and was a second step once you tested the driver).
You are using the 3.14.52 BSP Release so you would need to use the Fido branch of the engicam layer.
$ cd <BSP_RELEASE_DIR>/sources
$ git clone https://github.com/engicam-stable/meta-engicam -b fido
Once the layer is cloned you would need to add the new later editing the bblayers.conf file located the following path:
<BSP_RELEASE_DIR>/<BUILD_DIR>/conf/bblayers.conf
And add the following line to add the new layer.
BBLAYERS += " ${BSPDIR}/sources/meta-engicam "
This should make the wf111-driver available through bitbake. You can then add it to your image by adding the following line to the <BUILD_DIR>/conf/local.conf
IMAGE_INSTALL_append += "wf111-driver"
However, as mentioned by the AN996 from Silabs, it is necessary to enable the following kernel options:
http://www.silabs.com/Support%20Documents/RegisteredDocs/AN996.pdf
CONFIG_WIRELESS_EXT
CONFIG_MODULES
CONFIG_FW_LOADER
One alternative on how to do this is as mentioned by Chris Hossack on the following thread:
https://community.nxp.com/thread/376369
This involves adding an addendum to the kernel recipe in order to change its configuration. The correct way to do this would be on a new layer but for the sake of simplifying things and testing it I added it to my local copy of the meta-engicam layer. (If you create a new layer just don’t forget to add it to the bblayer.conf file).
We’ll make an append file that adds the required options. From the default BSP configuration the result would be the following, which I saved in a file called WF111.cfg. For more details on how to create this file please check Chris Hossack’s thread.
CONFIG_WIRELESS_EXT=y
CONFIG_WEXT_CORE=y
CONFIG_WEXT_PROC=y
CONFIG_WEXT_SPY=y
CONFIG_WEXT_PRIV=y
CONFIG_CFG80211_WEXT=y
CONFIG_LIB80211=y
CONFIG_LIB80211_CRYPT_WEP=y
CONFIG_LIB80211_CRYPT_CCMP=y
CONFIG_LIB80211_CRYPT_TKIP=y
# CONFIG_LIB80211_DEBUG is not set
CONFIG_HOSTAP=y
# CONFIG_HOSTAP_FIRMWARE is not set
Since we are appending the kernel layer we need to add the addendum on the same path as that of the original kernel recipe but within our layer and create the append file there, also add the WF111.cfg file to this same directory:
/<BSP_DIR>/sources/meta-engicam/recipes-kernel/linux/linux-imx_3.14.52.bbappend
The linux-imx_3.14.52.bbappend file would contain the following:
SRC_URI += "file://WF111.cfg"
do_configure_append() {
#this is run from
#./tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/3.14.52-r0/git
cat ../*.cfg >> ${B}/.config
}
After creating this recipe you should be able to bake any image from the BSP and see the driver there. I tested with the core-minimal-image and found that the files were indeed added to /lib/firmware.
$ bitbake core-image-minimal
I hope this information helps!
Hi gusarambula, thanks for the quick reply!
You're right:
<BUILD_DIR>/tmp/work/<MACHINE>/linux-imx/<KERNEL-VERSION>/git
seems like the correct directory to build the driver against. Copying Module.symvers from BUILD_DIR/tmp/work-shared/imx6ulevk/kernel-build-artifacts to BUILD_DIR/tmp/work-shared/imx6ulevk/kernel-source every time definitely seemed kludgy.
However building against that directory still yields a two main issues. The first is that ./include/generated/utsrelease.h still has UTS_RELEASE "3.14.52+" whereas the target is 3.14.52-1.1.1_ga+gdb1bcba. When I insmod / modprobe the module, it fails and dmesg has the same "unifi_sdio: version magic '3.14.52+ mod_unload modversions ARMv7 p2v8 ' should be '3.14.52-1.1.1_ga+gdb1bcba SMP preempt mod_unload modversions ARMv7 p2v8 '". I can spoof this by just manually changing UTS_RELEASE to 3.14.52-1.1.1_ga+gdb1bcba but again that seems like a bandaid rather than the solution.
The second issue is that the 5 previously mentioned symbols are still undefined. It appears the driver is expecting the kernel to have been built with these symbols, so finding a way to configure the kernel to have them is a priority. I did read that __gnu_mcount_nc is really only necessary for performance profiling, which seems optional. It may be possible to prevent the module from needing that symbol via compiler flags during the build. wireless_send_event is definitely necessary for the module to run, and is related to CONFIG_WIRELESS_EXT=y being present in the kernel .config, which it is. So I'm not sure why it's not being found by the module during build or run time.
The layer I found that included the WF111 driver is GitHub - engicam-stable/meta-engicam: Engicam yocto meta layer . I actually just ripped the wf111-driver recipe from the layer and inserted it into poky at sources/poky/meta/recipes-core/wf111-driver and included it to the image by adding wf111-driver to IMAGE_INSTALL. We aren't even sure we want to go with this wifi module in production so I just wanted to get a working module before I took the time to integrate the module into the build the "yocto way". I'm aware what I tried is bad form :smileywink:
If you have any insights into what may be going wrong with building the module externally I would greatly appreciate it. Let me know if you have any progress on building the recipe with the BSP as well.
Cheers,
Sam
Hello Sam Musso,
My apologies for the delay.
Since the driver was already on a Yocto layer I went the Yocto route (which if I understand correctly is also valid for your scenario and was a second step once you tested the driver).
You are using the 3.14.52 BSP Release so you would need to use the Fido branch of the engicam layer.
$ cd <BSP_RELEASE_DIR>/sources
$ git clone https://github.com/engicam-stable/meta-engicam -b fido
Once the layer is cloned you would need to add the new later editing the bblayers.conf file located the following path:
<BSP_RELEASE_DIR>/<BUILD_DIR>/conf/bblayers.conf
And add the following line to add the new layer.
BBLAYERS += " ${BSPDIR}/sources/meta-engicam "
This should make the wf111-driver available through bitbake. You can then add it to your image by adding the following line to the <BUILD_DIR>/conf/local.conf
IMAGE_INSTALL_append += "wf111-driver"
However, as mentioned by the AN996 from Silabs, it is necessary to enable the following kernel options:
http://www.silabs.com/Support%20Documents/RegisteredDocs/AN996.pdf
CONFIG_WIRELESS_EXT
CONFIG_MODULES
CONFIG_FW_LOADER
One alternative on how to do this is as mentioned by Chris Hossack on the following thread:
https://community.nxp.com/thread/376369
This involves adding an addendum to the kernel recipe in order to change its configuration. The correct way to do this would be on a new layer but for the sake of simplifying things and testing it I added it to my local copy of the meta-engicam layer. (If you create a new layer just don’t forget to add it to the bblayer.conf file).
We’ll make an append file that adds the required options. From the default BSP configuration the result would be the following, which I saved in a file called WF111.cfg. For more details on how to create this file please check Chris Hossack’s thread.
CONFIG_WIRELESS_EXT=y
CONFIG_WEXT_CORE=y
CONFIG_WEXT_PROC=y
CONFIG_WEXT_SPY=y
CONFIG_WEXT_PRIV=y
CONFIG_CFG80211_WEXT=y
CONFIG_LIB80211=y
CONFIG_LIB80211_CRYPT_WEP=y
CONFIG_LIB80211_CRYPT_CCMP=y
CONFIG_LIB80211_CRYPT_TKIP=y
# CONFIG_LIB80211_DEBUG is not set
CONFIG_HOSTAP=y
# CONFIG_HOSTAP_FIRMWARE is not set
Since we are appending the kernel layer we need to add the addendum on the same path as that of the original kernel recipe but within our layer and create the append file there, also add the WF111.cfg file to this same directory:
/<BSP_DIR>/sources/meta-engicam/recipes-kernel/linux/linux-imx_3.14.52.bbappend
The linux-imx_3.14.52.bbappend file would contain the following:
SRC_URI += "file://WF111.cfg"
do_configure_append() {
#this is run from
#./tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/3.14.52-r0/git
cat ../*.cfg >> ${B}/.config
}
After creating this recipe you should be able to bake any image from the BSP and see the driver there. I tested with the core-minimal-image and found that the files were indeed added to /lib/firmware.
$ bitbake core-image-minimal
I hope this information helps!
Hello Sam Musso,
I have not worked with this driver in particular but the manufacturer’s directions are very good as a starting point.
I believe the problem may reside on where you are working the kernel source code. Perhaps you can use the directory you are using:
BUILD_DIR/tmp/work-shared/imx6ulevk/kernel-source
But when I’ve worked adding modules I use the linux-imx folder in:
<BUILD_DIR>/tmp/work/<MACHINE>/linux-imx/<KERNEL-VERSION>/git
You can see an example of how to add an NFC module driver to the i.MX6BSP on the following link:
https://community.nxp.com/docs/DOC-331906
As for the .bb recipe, have you integrated the layer containing this recipe and then added it to your image? I’ve seen the problem you mention of a different folder for the kernel version modules but shouldn’t cause a problem. It seems that the .ko are there, just not on the right formar? If you could share the layer in which this recipe is included I can try to add it to the BSP to replicate the issue.
Please keep us posted on your findings. If I find any useful information I’ll let you know.
Regards,