Mwifiex_sdio FW is active

Currently, we are not using the wifi, currently. But I see messages that say “ieee80211 phy0: mwifiex_cfg80211_sched_scan_start : Invalid Sched_scan parameters”. Is there a way to stop this FW from becoming active?
Another product the colibri mentions this, but it talks about connmanctl to turn on the device. I don’t have that in my system, but I see it in the startup dmesg becoming active.

Also, how do I capture the systemd disable serviceX in the install? Is that caught with the isolate command?


Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:

Hello Steve,

To stop the mwifiex firmware from becoming active if you’re not using the WiFi, you can prevent the mwifiex driver from loading at boot time. This can be achieved by blacklisting the mwifiex driver module. Here’s how you can do it:

  1. Create a .conf file in the /etc/modprobe.d/ directory. You can name it something like mwifiex_blacklist.conf.

  2. Inside this file, add the following line to blacklist the mwifiex driver:

    blacklist mwifiex_sdio

    This will prevent the mwifiex driver for SDIO interfaces from being loaded automatically at boot time.

  3. After creating this file, you will need to reboot your system for the changes to take effect.

Regarding your question about capturing the systemd disable service action in the install process, if you’re looking to ensure a service does not start during boot, you can use the systemctl disable command. To capture this in an installation script or process, you can directly include the systemctl disable serviceName.service command in your script.

If you’re asking about capturing this action with the systemd isolate command, it’s important to note that systemd isolate is typically used to switch to a different target or runlevel, not to disable services. To disable a service so it doesn’t start on boot, sticking with systemctl disable is the recommended approach.

Remember, after making these changes, you should test your system to ensure that disabling these components does not affect other functionalities you might need.

Best regards,
Toradex AI Assistant

Please, also check if these links can help you solve your problem:

Toradex’s Linux Images - How to connect to a Wi-Fi network | Toradex Developer Center.

I tried manually putting this in the builder “changes” file structure for the builder, but it did not work. It does work in when it is there. But the builder doesn’t actually take that change, or it just doesn’t do it. Since it was under the /etc directory, I thought it would do it.

Also, I am trying to turn off the NetworkManager-wait-online.service, which of course works, but doesn’t help me for a production build where I want to install the system with these features already set. I don’t want the production guys having to go in and create files or run the
** sudo systemctl disable NetworkManager-wait-online.service**
command. How do I get it into the installer?

I made changes to my build and ran torizoncore-bulider isolate, but it failed with an error leaving an isolated_changes.tar file that contained a folder/file: etc/systemd/system/ This file was/is empty.

Any help would be appreciated.

Hi @Evets

Indeed the isolate does capture the disabling of services. The .wh file that is created in your case is used by tcb to delete the file in the resultant image. It is, as you noted, a zero-byte file. I just ran it locally after disabling the docker-compose service and it isolated the change/usr/etc/systemd/system/ file. Not that it is under /usr/etc rather than /etc which is an artifact of how ostree manages the /etc directory with a three-way merge when applying OTA updates. Not sure what happened when yours failed but in my case it succeeded running the following command:

torizoncore-builder isolate --remote-host --remote-password 1 --changes-directory change --force

This actually stores in in the directory named change in my build host filename rather than in the container volume.

As for the initial question about disabling the firmware, I think the blacklist solution as proposed by the AI bot is the simplest answer.


Right, and I added that into the /usr/etc/directory. But in the install, nothing happened, i.e., the blacklist file did not show up.
I will try to manually put the disabling file into the folder and see if it works.

Yes, manually adding what was in the tar file of the failed isolate attempt did work. But my other case of adding the blacklist file for the driver under /etc/modprobe.d directory, still does not work.
Any suggestions?