Torizoncore >=5.4 Wifi kernel module not loaded automatically

Technical Support
, ,
1

This is kind of a follow-up of Apalis imx8qm 1.1 free GPIO7 causes wifi to be disabled Torizon 5.4 build10 - #14 by bearsh

Module: Apalis iMX8 QuadMax 4GB Wi-Fi / Bluetooth IT V1.1C
Carrierboard: Ixora V1.2A

Using Torizoncore >=5.4 the mwifiex/mwifiex_pcie kernel module is not loaded automatically resulting in a unusable Wifi module. Using Torizoncore 5.3, the module just works after booting.

Executing sudo modprobe mwifiex mwifiex_pcie workarounds the problem.

[edit]
I just saw, there’s a modprobe config file /etc/modprobe.d/mwifiex-blacklist.conf which blacklists the mwifiex* modules. Now I’m wondering why?

3

Greetings @bearsh,

This is actually interesting, so the reason we have a blacklist is due to an issue we had before. The commit here explains why: mwifiex-delay: add recipe · toradex/meta-toradex-torizon@92d6f4f · GitHub

As you can see from the referenced commit, we use a separate systemd service to load the mwifiex drivers. In your case it seems like this didn’t work(?). Could you try checking the logs for this mwifiex-delay.service service and see if perhaps something went wrong.

Best Regards,
Jeremias

4

Hi @jeremias.tx

Thanks for the link and the explanation. No I know why it doesn’t work. The script uses the hostname to determine on which module it is running:

check_target () {
        TARGET=${HOSTNAME%-*}
        echo ${TARGET}
}

select_mwifiex_module () {
        TARGET=$(check_target)
        case $TARGET in
                apalis-imx8)
                        MODULE=mwifiex_pcie
                        ;;
 <snip>

Frankly speaking this approach is anything but reliably. as soon as someone changes the hostname, which I did, it fails. and for a product I don’t want to have the word ‘apalis’ in its hostname but the real product name.

I’m pretty sure the are other ways to reliably determine which module is in use. something which seems to work, at least on the apalis (I don’t have other boards) is to look into the dmesg output, e.g.:

check_target () {
        TARGET=$(dmesg | grep -o -E -m 1 "apalis|colibri|verdin")
        echo ${TARGET}
}

Regards

5

Ahh there’s the issue then. changing the hostname would definitely break this script as you pointed out. I’ll need to report this to the development team to improve the script. In the meantime please workaround this issue.

Thank you for bringing this shortcoming to my attention.

Best Regards,
Jeremias