Sierra Wireless MC7411 PCIe modem not detected on Torizon OS 7.3.0

Hello,

I am experiencing a serious issue with my Sierra Wireless MC7411 PCIe modem after updating to Torizon OS 7.3.0+build.18 (scarthgap).
With Torizon OS 6.8.3, the modem was detected and worked correctly using ModemManager (mmcli).
Now, with version 7.3.0, the command:

sh

mmcli -L

returns:

Code

No modems found

System information:

sh

cat /etc/os-release
ID=torizon
NAME="Torizon OS"
VERSION="7.3.0+build.18 (scarthgap)"
VERSION_ID=7.3.0-build.18
VERSION_CODENAME="scarthgap"
PRETTY_NAME="Torizon OS 7.3.0+build.18 (scarthgap)"
CPE_NAME="cpe:/o:openembedded:torizon:7.3.0+build.18"
BUILD_ID="18"
ANSI_COLOR="1;34"
VARIANT="Docker"

Troubleshooting performed:

  • The PCIe bridge is visible with lspci, but the modem itself does not appear.

  • dmesg shows repeated messages like “Phy link never came up”.

  • The MC7411 modem is not detected as a PCIe device.

  • Everything works fine with the same hardware and setup using Torizon OS 6.8.3.

Questions:

  • Were there any changes to the device tree, kernel, or GPIO/power/reset handling between 6.x and 7.x that could affect PCIe enumeration for modems?

  • Can you provide a build of Torizon OS 7.x with the same PCIe/WWAN/MHI support as 6.8.3, or advise how to restore proper modem detection?

  • What are the relevant kernel configuration and device tree differences between the two versions?

Thank you for your support!

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:


ModemManager Configuration on Torizon OS

Based on your description, you’re experiencing issues with your Sierra Wireless MC7411 PCIe modem after upgrading from Torizon OS 6.8.3 to 7.3.0. Let me help you troubleshoot this ModemManager issue.

Basic ModemManager Verification

First, let’s verify the basic ModemManager setup. Torizon OS provides ModemManager out-of-the-box, along with NetworkManager for automatic network detection and configuration(1).

To check if your modem is detected, you should use:

# mmcli -L   
    /org/freedesktop/ModemManager1/Modem/0 [Sierra Wireless, Incorporated] MC7455  

(1)

Potential Device Tree Issues

Since you mention the PCIe bridge is visible but the modem itself doesn’t appear, this could be related to device tree changes between Torizon OS versions. Device tree modifications might be necessary to properly configure the PCIe interface for your modem(2).

Customization Approach

If device tree modifications are needed, you can use TorizonCore Builder to apply custom device tree overlays. The process involves creating a device tree overlay (.dts file) and applying it using TorizonCore Builder(3).

For device tree customization, you would create a configuration file like:

customization:  
  device-tree:  
    include-dirs:  
      - device-trees/include/  
    custom: device-trees/dts-arm32/imx6dl-colibri-eval-v3.dts  
    overlays:  
      add:  
       - device-trees/overlays/colibri-imx6_hdmi_overlay.dts  
        - device-trees/overlays/colibri-imx6_atmel-mxt-connector_overlay.dts  

(4)

Pin Configuration Considerations

The “Phy link never came up” messages in dmesg suggest potential pin configuration issues. You may need to verify that the pins used for PCIe are properly configured and not conflicting with other peripherals(2).

Production Deployment

After making any necessary changes to your board configuration, you can use the isolate command from TorizonCore Builder Tool to generate your custom Torizon OS image for deployment(1).

Recommendations

  1. Check PCIe Device Tree Configuration: Compare the device tree files between Torizon OS 6.8.3 and 7.3.0 to identify any changes affecting PCIe enumeration
  2. Verify Pin Conflicts: Ensure no pin conflicts exist that might prevent proper PCIe operation
  3. Create Custom Overlay: If needed, create a device tree overlay to restore the PCIe configuration that worked in 6.8.3
  4. Test with TorizonCore Builder: Use TorizonCore Builder to apply any necessary customizations

The transition from Torizon OS 6.x to 7.x may have introduced changes in the kernel configuration or device tree that affect PCIe modem detection. Creating a custom image with the appropriate device tree modifications should resolve the issue.

Best regards, Toradex AI Assistant.

Hello @VLengineering,

Thanks for reporting this behavior. I checked the differences between the device trees for kernel 6.6 (for Torizon OS 7.3.0) and kernel 5.15 (for Torizon OS 6.8.3). Please note that I checked this for Verdin iMX8M Plus, however, the changes should be similar for the mini module as well.
I see that:

  1. On branch toradex_5.15-2.2.x-imx : the PCIe endpoint power (epdev_on-supply) is explicitly tied to a 3.3 V regulator, and that regulator is marked regulator-always-on:
//file imx8mp-verdin-dev.dtsi  
/\* Verdin PCIE_1 \*/
   
&pcie {
        epdev_on-supply = <&reg_3p3v>;
        status = "okay";
};
 
//file imx8mp-verdin.dtsi  
reg_3p3v: regulator-3p3v {
                compatible = "regulator-fixed";
                regulator-always-on;
                regulator-max-microvolt = <3300000>;
                regulator-min-microvolt = <3300000>;
                regulator-name = "+V3.3_SW";
        };
  1. On branch toradex_6.6-2.2.x-imx: that epdev_on-supply link is missing, and regulator-always-on is not present on the 3.3 V rail:
//file imx8mp-verdin-dev.dtsi
/* Verdin PCIE_1 */
&pcie {
        status = "okay";
};

reg_3p3v: regulator-3p3v {
                compatible = "regulator-fixed";
                regulator-max-microvolt = <3300000>;
                regulator-min-microvolt = <3300000>;
                regulator-name = "+V3.3_SW";
        };

I’m not entirely sure if the missing epdev_on-supply the reason for the behavior you are seeing. However, I can suggest writing and applying a device tree overlay with the following changes, reboot the module, and test again:

&reg_3p3v {
	regulator-always-on;
};

&pcie {
	epdev_on-supply = <&reg_3p3v>;
};

Here you can find documentation on how to write and apply a device tree overlay: How to Write Device Tree Overlays | Toradex Developer Center
You could also use an existing device tree overlay from overlays - device-tree-overlays.git - Sources for Device Tree Overlays as a starting point.

Please let me know if this helps you.

Hello,

Thank you for your analysis and suggestions.

I would like to add that the Quectel EC25EUGA MINIPCIE modem works correctly, so I am not sure if this issue is related to the definition of the power supply pins. For now, I will proceed with the Quectel modem, which is also the model we plan to use in production.

However, I am concerned that after updating Torizon OS, the functionality of certain peripherals may be lost. Is there any recommended approach from Toradex to minimize the risk of such regressions in the future? Ideally, automated testing after OS updates would be really valuable. Is this something Toradex already provides or plans to implement?

Thank you again for your support.

Hello @VLengineering,

Glad to hear that the Quectel modem that you want to use in production works on both Torizon OS versions. I am still intrigued by the behavior with the Sierra modem. Did you have any modifications in the device tree (or a device tree overlay) for Torizon 6 for the Sierra and Quectel modems? If yes, I would like to compare those relevant changes between kernel 5.15 and 6.6. In case you didn’t make any changes in the device tree, I would say you were just lucky to have the Sierra modem working on Torizon 6. In any case, you should check the datasheet for the modem to find the right pin functionalities and enable those in the device tree to have it working as expected.

However, I am concerned that after updating Torizon OS, the functionality of certain peripherals may be lost. Is there any recommended approach from Toradex to minimize the risk of such regressions in the future? Ideally, automated testing after OS updates would be really valuable. Is this something Toradex already provides or plans to implement?

Our releases for both BSP and Torizon OS are tested on our Hardware environment for the peripheral functionality that those environments offer. Here I am talking about each new version of BSP/Torizon OS release. We do not run such full tests exactly after an OTA update, other than making sure that the device boots to the updated image. It is a redundant test for us since these images are already tested separately for different functionalities. You can check our test results here: Test Results | Toradex Developer Center
It is the responsibility of the user/customer to test these basic functional images in their environment for their peripherals.