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?

Thanks,
Steve

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/.wh.network-online.target.wants. This file was/is empty.

Any help would be appreciated.
Thanks,
Steve

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/multi-user.target.wants/.wh.docker-compose.service 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 colibri-imx7d.lab.moseleynet.net --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.

Drew

@drew.tx
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.

@drew.tx
Yes, manually adding what was in the tar file of the failed isolate attempt did NOT work, which is an empty file .wh.network-online.target.wants. In the disable case, it is removing network-online.target.wants But my other case of adding the blacklist file for the driver under /etc/modprobe.d directory, still does not work.
Any suggestions?

Which module and OS version are you running?

Drew

torizonOS 6.6.1 and the Verdin imx8m-plus.

@drew.tx ,
Here is an interesting thing. I went back and re-unpacked the torizon-core-docker-verdin-imx8mp-Tezi_6.6.1+build.14.tar, and then ran the isolate command with my device with all the changes I have made. The only thing that shows up is these last 2 changes, the modprobe.d directory and the blacklist file .conf. And that also shows up in the .tcattr file. However, the other file that is the 0 size wh.network-online.target.wants file is in the systemd/system folder, but not mentioned in the .tcattr file. Shouldn’t it be?

Steve

The “.wh.*” files are not actually created in the resultant filesystem but are used to instruct tcb to delete a file. So there are no attributes associated with it.

Also, when you run isolate, it will compare what is currently in /etc with what is in /usr/etc to figure out what has changed. Basically /usr/etc is the read-only contents of the last OStree deployment done.

So if you isolate, then deploy, make changes, and isolate again, you will only see the changes made after the deployment. We probably need better docs in this area but the best practice is to use a separate changes directory for each isolate and try to keep them to a single coherent feature change each time.

Drew

Hi @drew.tx,
Yes, I already figured that out. But I guess I would’ve expected to see all my changes since I went back to the original tar file, which should have no changes in it after the unpack of it. Obviously, I don’t quite get how everything is working.
Regardless, it still is not deleting the network-online.target.wants directory, and thus the boot time is 7-9 seconds slower.
The other blacklisted file change is to keep the processor from doing things it doesn’t need to do. But I really need these to work in the installer as I don’t want production to have to fiddle with doing the changes. All my other changes including fstab (mounting the sdcard at a known location) works great. Not sure why this is not working.

Steve

Hi @drew.tx ,
I think the reason network-online file doesn’t work is because that folder gets created at startup. I just realized that I get a message when I run the union command that says:
Can’t remove /usr/etc/systemd/system/network-online.target.wants: File not found. Ignoring…
I didn’t see that it was an error, although it doesn’t say it’s an error, it just says that message. I don’t remember seeing that before, but it definitely just did happen.
It appears to be created at first startup. When the network-online.target.wants is created, it’s just a symlink to the /usr/lib/systemd-networkd-wait-online.service file. I am not sure how to fix this.

Steve

I guess 5th time is a charm. Now it worked for both items. Go figure, don’t know why it worked this time.

Steve

OK. Glad to hear.
Drew