WF111 Driver Build against FSL Yocto

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

WF111 Driver Build against FSL Yocto

跳至解决方案
6,044 次查看
sammusso
Contributor III

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. 

I've downloaded the driver source from silabs and am following the instructions in http://www.silabs.com/Support%20Documents/RegisteredDocs/AN996.pdf to build the driver. I'm getting caught up when the instructions refer to the kernel source directory. Looking through the build directory in yocto I found $BUILD_DIR/tmp/work-shared/imx6ulevk/kernel-source/ but I've run into a number of issues passing that directory as KDIR to make. Here are my notes outlining everything I've tried so far. 

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* "

标签 (4)
1 解答
3,380 次查看
gusarambula
NXP TechSupport
NXP TechSupport

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!

在原帖中查看解决方案

5 回复数
3,380 次查看
sammusso
Contributor III

Many thanks! I was able to get it running with your help! Appending the kernel options was definitely the tricky bit there. 

Thanks again, 
Sam

3,380 次查看
aydogmus
Contributor II

Hi sammusso,

I have also have problems with wf111 module, link is here:

https://community.nxp.com/thread/449753 

thanks in advance,

Abdulaziz.

0 项奖励
回复
3,380 次查看
sammusso
Contributor III

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

0 项奖励
回复
3,381 次查看
gusarambula
NXP TechSupport
NXP TechSupport

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!

3,380 次查看
gusarambula
NXP TechSupport
NXP TechSupport

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,

0 项奖励
回复