Priority: High - blocking customer test, new hardware just received
Summary:
We are bringing up a new batch of Verdin iMX8MP + Zinnia carrier board gateways for a customer test. The SparkLAN WPEQ-268AXIBT PCIe mini card, which works correctly on our existing Verdin iMX8MP + Ivy carrier board gateways, is not detected on the new Zinnia boards. We need this resolved quickly as it is currently blocking the test.
Environment:
- SoM: Verdin iMX8MP
- Carrier boards: Ivy (working) and Zinnia (not working)
- Torizon OS: nightly build 7.8.0-devel-20260819+build.519, same build flashed to both carrier variants
- PCIe card: SparkLAN WPEQ-268AXIBT (mini PCIe WiFi/BT)
- The two firmware images are built from the same pipeline and differ only in the carrier board device tree selection (verdin-imx8mp-ivy vs verdin-imx8mp-zinnia)
Observations:
1. On Ivy, the PCIe card is detected and works as expected.
2. On Zinnia (identical Torizon build, only the carrier device tree differs), the PCIe card is not detected at all.
3. Comparing the two carrier dtsi files, the Ivy dtsi explicitly enables the PCIe controller and PHY:
/* Verdin PCIE_1 */
&pcie {
status = "okay";
};
&pcie_phy {
status = "okay";
};
The Zinnia dtsi has no &pcie or &pcie_phy reference at all, PCIe is simply not enabled for this carrier in the device tree we have. Both full dtsi files a
imx8mp-verdin-ivy.dtsi.txt (10.3 KB)
imx8mp-verdin-zinnia.dtsi.txt (6.7 KB)
re attached for reference (imx8mp-verdin-ivy.dtsi and imx8mp-verdin-zinnia.dtsi).
4. As a test, we swapped the Zinnia build to use the Ivy carrier device tree while running on the actual Zinnia hardware. With this combination we do see a PCIe bridge/root port appear (lspci shows the controller), but the WiFi card behind it still does not enumerate.
Our interpretation:
Enabling &pcie / &pcie_phy alone brings the controller up, but the mini-PCIe card itself likely needs carrier-specific power/reset/WAKE control (regulator, reset-gpios, PCIe REFCLK enable, or similar) that is wired differently on Zinnia than on Ivy. Since the Ivy dtsi's PCIe-adjacent GPIO assignments do not match the physical wiring of the Zinnia board, forcing the Ivy device tree does not correctly bring up the card even though the bridge itself appears.
Question for Toradex:
Could you confirm the correct device tree changes required to enable the mini-PCIe socket (WiFi card) on the Zinnia carrier board for Verdin iMX8MP? Specifically we are looking for:
- The correct &pcie / &pcie_phy enablement for Zinnia
- Any carrier-specific reset/power/WAKE GPIO or regulator nodes needed for the mini-PCIe socket on Zinnia, analogous to what already works on Ivy
- Confirmation of pinctrl groups required, if different from Ivy
Urgency note: this is currently blocking a customer test on newly received Zinnia hardware. We do not need a production-grade fix immediately, a working nightly build with correct PCIe/WiFi enablement for Zinnia would be sufficient to unblock testing.
Hi, I’m the Toradex AI Assistant.
I might make mistakes or occasionally get you wrong. Our support team will step in if needed.
Based on the available documentation, I can confirm that the Zinnia carrier board does include a mini PCIe slot and is designed to support PCIe devices(1). However, the specific device tree configuration details needed to enable the mini PCIe socket on Zinnia are not present in the sources I have access to.
What the documentation confirms:
The Zinnia carrier board specifications show(1):
- PCIe: 1x (Mini PCIe)
- Compatible with the entire Verdin System on Modules Family, including Verdin iMX8M Plus
The Verdin Carrier Board Design Guide provides general mini PCIe implementation requirements(2)(3):
- Mini PCIe cards require both PCIe and USB 2.0 interfaces to be compliant
- The carrier must provide proper power rails (+3.3V, +1.5V, and optionally +12V)
- A dedicated PCIe reset (PCIE_1_RESET#) with level shifting from 1.8V to 3.3V is required
- The WAKE# signal can be connected to CTRL_WAKE1_MICO#
- An SMB interface with bidirectional level shifter may be needed (I2C_1 with 1.8V to 3.3V conversion)
Critical gap:
Your analysis is correct — the Zinnia device tree currently lacks the &pcie and &pcie_phy enablement nodes that are present in the Ivy dtsi. However, I don’t have access to the Zinnia-specific carrier board datasheet or schematic that would detail:
- The exact GPIO assignments for PCIe power control, reset, and WAKE signals on Zinnia
- The regulator nodes controlling the mini PCIe power rails
- Zinnia-specific pinctrl configurations
Recommended next steps:
Since this is blocking your customer test and involves hardware-specific implementation details not covered in the available documentation, I recommend:
-
Check the Toradex Developer Center for Zinnia-specific device tree examples or carrier board documentation at https://developer.toradex.com/hardware/verdin-som-family/carrier-boards/zinnia-carrier-board/
-
Contact Toradex support directly via the Community or GitHub with your specific dtsi files and hardware details — they can provide the carrier-specific GPIO mappings and device tree nodes needed for Zinnia’s mini PCIe implementation.
Given the urgency and the fact that Zinnia is listed as being in “Sample Production” phase(1), Toradex support should be able to provide the correct device tree configuration quickly.
Best regards,
Toradex AI Assistant
Did you like my answer? 
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
Hello @JormenJanssen,
The issue is that the Zinnia Carrier Board has no PCIe signals on its mPCIe slot.
It actually has USB 3.0, making it only compatible with modems that can operate with USB 2.0 or USB 3.0.
The short term solution would be to use the Ivy or a USB 2.0/3.0 modem.
We could make a custom Zinnia with PCIe on the mPCIe slot.
This could also be a default alternate configuration at some point in the future as well.
However, this will take some time and discussions to decide.
This requirement is tracked internally and we may reach out again for more information.
Best Regards,
Bruno
