ConnectCore 6ul Starter Kit wifi driver issues

1 - Yocto Morty with meta-openembedded (morty), meta-fsl-arm (krogoth) and meta-digi-arm (jethro).
2 - core-image-mininal with kernel-modules, kernel-module-qualcomm, qualcomm-firmware, wpa-supplicant
3 - zImage-imx6ul-ccimx6ulstarter-id129.dtb
4 - boot from nfs

When I load the wlan module I receive:
wlan: loading driver v4.2.74.63
hifDeviceInserted: Dumping clocks (50000000,198000000)
HIFDumpCCCR 0(43) 1(3) 2(0) 3(0) 4(0) 5(0) 6(0) 7(6) 8(17) 9(0) A(10) B(0) C(0) D(0) E(0) F(0) 10(0) 11(0) 12(1) 13(3) 14(7) 15(0
AR6000: Set async interrupt delay clock as 2.
ath_hif_sdio: HIF (Atheros/multi-bss)
AR6000: configuration opcode 3 is not used for Linux SDIO stack
Board extended Data download address: 0x0
ol_download_firmware: Using 0x1234 for the remainder of init
__ol_transfer_bin_file: Loading setup file qsetup30.bin
ar6k_wlan mmc0:0001:1: Direct firmware load for qsetup30.bin failed with error -2
ar6k_wlan mmc0:0001:1: Falling back to user helper

Using my generated kernel, dtb and wlan module works like a charm for the rootfs presented in

I’m wondering if there is some trick in the 82004000_2P rootfs which makes the wifi module works.

core-image-minimal is not prepared to work with DEY. Please use core-image-base on dey-2.0.r4. You can extend core-image-minimal to work in DEY in the same way as it is done for core-image-base:

Also, mixing layers at different revisions is not recommended. You should stick with Jethro.

Hi all !
I have the same problem.
When I use the kernel (4.1.28), device tree, wlan module, and rootfs shipped together, then the Wifi is OK.

When I try to use another rootfs (home made) whith the provided kernel, device tree, wlan module, and firmware binaries from the provided rootfs, but with my own rootf, then the wlan module fails to load …

Did anyone find the trick they use in the yocto rootfs ??

I found the parameters from the modprobe configuration provided with wlan module patches :

insmod wlan.ko asyncintdelay=0x2 writecccr1=0xf2 writecccr1value=0xf writecccr2=0xf1 writecccr2value=0xa8 writecccr3=0xf0 writecccr3value=0xa1 writecccr4=0x15 writecccr4value=0x30

But this does not fix the problem.

Any clue ?
Thanks :slight_smile:

Hi once again !

I finaly found the solution :

When you use the kernel from digi/dey, they have activated the “user helper” (CONFIG_FW_LOADER_USER_HELPER)

When you load the wlan module, it will look for an inexistant qsetup30.bin firmware.
When the kernel fails to load the firmware, it asks the userspace helper (usually udev, but any equivalent would fit).
If this helper does not find the firmware, then the module loading goes on, and succeeds.
But if you don’t have a “user helper” in your rootfs, then the module fails to load !!!

You can thus either (depending on your configuration and/or needs) :

  • remove the user helper config from your kernel, - provide a user helper,
  • modify the wlan driver so it goes on when there is no user helper, as it would when the firmware is not present !

Hope this will help :slight_smile: