GPIO Power-Off Overlay Not Working After Migration to Scarthgap (Apalis iMX8QP)

Technical Support
, , ,
1

Hi everyone,

We’re currently migrating our project from the Kirkstone Yocto branch to Scarthgap, along with updating to Boot2Qt 6.8.4. We’re using the Apalis iMX8QP on the Ixora Carrier Board v1.2A.

Under Kirkstone and kernel 5.15.x, we had a GPIO-based power-off functionality working reliably using a apalis-imx8_gpio-poweroff_overlay.dts device tree overlay.
apalis-imx8_gpio-poweroff_overlay.dts (372 Bytes)

After updating to Scarthgap and kernel 6.6.84:

  • The overlay still appears to apply correctly in U-Boot:
Applying Overlay: apalis-imx8_gpio-poweroff_overlay.dtbo
  • However, the power-off behavior no longer works — the system does not shut down via the designated GPIO as it did before.

Are additional configuration steps or changes required in Scarthgap to enable this functionality?

Some discution has already been done here (Subject: Issues After Migrating Yocto/BitBake Build to Scarthgap (Boot2Qt/Qt 6.8.4 / Toradex Apalis iMX8))

Edit:
From what I know the issue might be due to some changes in device trees between kirkstone and scarthgap branches (I don’t see any reason for this issue to be Boot2Qt related).

2

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:

Hello! Thank you for your detailed description of the migration and the issue.

To restore GPIO-based power-off functionality on the Apalis iMX8QP with Scarthgap (kernel 6.6.84), there are a few important steps to review:

1. Kernel Configuration

For i.MX8-based modules, kernel support for the GPIO power-off driver is controlled by the CONFIG_POWER_RESET_GPIO configuration option. This feature must be enabled in the kernel. Changes in newer kernels (6.x) might mean the configuration was not carried over from your previous build.

  • Action: Please ensure CONFIG_POWER_RESET_GPIO is enabled in your kernel build.
  • Check with:
    zcat /proc/config.gz | grep POWER_RESET_GPIO
    or
    grep POWER_RESET_GPIO /boot/config-$(uname -r)
  • If it is not set to y or m, you will need to enable it and rebuild the kernel.

GPIO Power-Off Documentation

2. Device Tree Overlay and Pinmuxing

  • The overlay must properly describe both the GPIO controller and the correct signal.
  • Example node (for illustration):
    gpio-poweroff {
    compatible = "gpio-poweroff";
    gpios = <&gpio3 23 GPIO_ACTIVE_LOW>;
};
    Double-check your overlay against this pattern, ensuring:
    • The GPIO controller reference and pin number are still valid in the newer kernel and device tree.
    • The GPIO settings (such as GPIO_ACTIVE_LOW) match your hardware’s requirements.

If the pinctrl or GPIO numbering scheme has changed in the device tree between kernel versions, you may need to adapt your overlay.

GPIO Power-Off Device Tree Example

3. Overlay Compatibility

Device tree overlays can sometimes conflict with changes in base device trees or have subtle incompatibilities after major kernel bumps.

  • Action: Review the overlay log in U-Boot and dmesg for any errors or warnings indicating a misapplied overlay or ignored nodes.
  • Consider testing the overlay merged directly in the device tree (as opposed to an overlay) as a debugging step.

Device Tree Overlay Limitations

4. Hardware Path Verification

The Apalis Evaluation Board uses the LTC2954 controller with a FORCE_OFF# pin (X61-5). This pin must be toggled as per board design to initiate full power-off via GPIO.

  • Double-check your hardware signal path to ensure nothing in the new software stack or configuration is inhibiting the poweroff sequence.

Carrier Board Documentation

Summary Checklist

  • Confirm CONFIG_POWER_RESET_GPIO is enabled.
  • Verify overlay GPIO definitions and referenced controller/path.
  • Review dmesg/U-Boot logs for overlay application issues.
  • Double-check against the board manual for correct FORCE_OFF# line usage.

If you provide your overlay’s relevant snippet and/or dmesg log after poweroff attempt, I can help examine for issues more precisely.

Best regards, Toradex AI Assistant.

3

@ToradexAI
Yes, CONFIG_POWER_RESET_GPIO is enabled:

root@b2qt-apalis-imx8:~# zcat /proc/config.gz | grep POWER_RESET_GPIO
CONFIG_POWER_RESET_GPIO=y
CONFIG_POWER_RESET_GPIO_RESTART=y

And yes our hardware is correct since it worked with kirkstone branch

4

Thanks for your response.

Please remember to tick the “Solution” checkbox below if my response solves your question. If you have follow-up questions, just continue to tag me using @ToradexAI in your new posts.

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

Thank you for confirming that CONFIG_POWER_RESET_GPIO is enabled. Since the kernel configuration is correct and your hardware worked with Kirkstone, the issue is likely related to device tree changes between kernel versions.

For i.MX8/8X based modules, you need to correctly mux the GPIO pin that you choose to use. Here’s the reference example from the documentation for Colibri iMX8X that shows the proper device tree configuration:

gpio-poweroff {
    compatible = "gpio-poweroff";
    gpios = <&gpio3 23 GPIO_ACTIVE_LOW>;
};

Notice in the reference (GPIO Power-off documentation) that the pinmux setting for the GPIO might also require updating. For example, the pinmux for the used GPIO should be set appropriately; a common requirement after kernel upgrades is to adapt pin configuration flags, as shown here:

-    SC_P_QSPI0B_SS0_B_LSIO_GPIO3_IO23    0x20
+    SC_P_QSPI0B_SS0_B_LSIO_GPIO3_IO23    0x21

(source: see GPIO power-off link above)

What to check in your overlay:

  1. Double-check the overlay references the correct GPIO controller and pin for your usage (controller & pin numbers can change, depending on kernel/device tree updates!).
  2. Ensure the GPIO is properly muxed in the pinctrl configuration block.
  3. Compare your device tree overlay to the reference above (including pinmux value) and update as needed for kernel 6.6.x.
  4. Check dmesg after shutdown for any “gpio-poweroff” errors or GPIO-related messages.
  5. You can also test controlling the GPIO from user space as a troubleshooting step (GPIO Linux development guide).

Could you please share your apalis-imx8_gpio-poweroff_overlay.dts file content? This will help identify any overlay structure or compatibility issues caused by updates between Kirkstone and Scarthgap.

Best regards, Toradex AI Assistant.

5

@ToradexAI

Here is the content since you are not able to download the file I linked earlier

// SPDX-License-Identifier: GPL-2.0-or-later OR MIT

// GPIO power off handling
#include <dt-bindings/gpio/gpio.h>

/dts-v1/;
/plugin/;

/ {
	compatible = "toradex,apalis-imx8", "toradex,apalis-imx8-v1.1";
};

&{/} {
	gpio_poweroff: gpio-poweroff {
		compatible = "gpio-poweroff";
		gpios = <&lsio_gpio4 2 GPIO_ACTIVE_LOW>;
		timeout-ms = <3000>;
		priority = <1>;
	};
};
6

Thanks for your response.

Please remember to tick the “Solution” checkbox below if my response solves your question. If you have follow-up questions, just continue to tag me using @ToradexAI in your new posts.

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

Thank you for providing your overlay content.

Given the move from Kirkstone (kernel 5.15.x) to Scarthgap (kernel 6.6.x), it’s likely that the main issue is related to missing or outdated pinmux configuration for the GPIO you’re using in your overlay. In kernel 6.6.x for i.MX8, the way pinmuxing is handled has changed slightly, and correct pinmux settings are required for the GPIO to function (especially for system functions like power-off).

What’s missing:
Your overlay references &lsio_gpio4 2, but does not set up the proper pinmux for the corresponding pin. In the device tree for i.MX8, you typically need to:

  1. Define a pinctrl setting that configures the relevant pin as GPIO.
  2. Reference this pinctrl setting in your gpio_poweroff node or ensure the base device tree applies this configuration for your chosen pin.

Recommended Fix

  1. Identify exactly which SoC pad is mapped to lsio_gpio4 2
    Make sure you are using the same pad (physical pin) as before.

  2. Add the pinmux to your overlay.
    For example, you can add a pinctrl section like this (adapt for your chosen pin):

/ {
    fragment@0 {
        target-path = "/";
        __overlay__ {
            gpio_poweroff: gpio-poweroff {
                compatible = "gpio-poweroff";
                gpios = <&lsio_gpio4 2 GPIO_ACTIVE_LOW>;
                pinctrl-names = "default";
                pinctrl-0 = <&pinctrl_gpio_poweroff>;
                timeout-ms = <3000>;
                priority = <1>;
            };
        };
    };

    fragment@1 {
        target = <&pinctrl_hog_0>;
        __overlay__ {
            pinctrl_gpio_poweroff: pinctrl-gpio-poweroff {
                fsl,pins = <
                    SC_P_<YOUR_PIN>      0x21
                >;
            };
        };
    };
};
  • Replace SC_P_<YOUR_PIN> with your exact SoC pad enum for the pin routed to lsio_gpio4 2.
  • Note the 0x21 is typical for output in 6.6.x and may differ from older examples (0x20)—see the GPIO Power-Off documentation for more detail.
  1. Apply and test this overlay. Then check dmesg after shutdown or reboot for relevant messages.

Troubleshooting

  • Double-check that lsio_gpio4 2 still maps to the correct hardware pin in apalis-imx8.dtsi and apalis-imx8qxp.dtsi under the new kernel.
  • Confirm your overlay does not conflict with another part of the base device tree on Scarthgap.
  • Test the GPIO from userspace to confirm you can toggle it.

Resources

If you adjust your overlay as above and ensure the pinmux is correct, GPIO-based power-off should work as before.

Best regards, Toradex AI Assistant.

7

@ToradexAI
So after fixing the overlay like so

// SPDX-License-Identifier: GPL-2.0-or-later OR MIT

// GPIO power off handling
#include <dt-bindings/gpio/gpio.h>

/dts-v1/;
/plugin/;

/ {
    compatible = "toradex,apalis-imx8", "toradex,apalis-imx8-v1.1";
};

&{/} {
    gpio_poweroff: gpio-poweroff {
        compatible = "gpio-poweroff";
        gpios = <&lsio_gpio4 2 GPIO_ACTIVE_LOW>;
        timeout-ms = <3000>;
        priority = <1>;
        // Make sure the pin is configured as GPIO
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_gpio6>;
    };
};

// If enabled, this would change the pin muxing as well
&flexcan3 {
    status = "disabled";
};

without much success.

To test things a bit further I tryed to set the gpio from the command line with:
gpioset -c 4 2=0

At first, it prompted me this:
gpioset: unable to request lines on chip '/dev/gpiochip4': Device or resource busy

Seems ok since when doing a gpioinfo, it prompts that gpiochip4 line 2 is used by gpio-poweroff as prompted by gpioinfo:

gpiochip4 - 32 lines:
line   0: "MXM3_18"        input
line   1: "MXM3_11/GPIO5" input
line   2: "MXM3_13/GPIO6" output active-low consumer="gpio-poweroff"

So I disabled the overlay in /boot/overlay.txt, and after runing gpioset -c 4 2=0, it worked and shutdown my system via the force_off pin of the ixora power-supply chip as expected.

All that made me think of a point, by updating from kirkstone to scarthgap the libgpiod as gone from v1.6.4 to v2.1.2 introducing breaking changes in its API. Could it be that the gpio-poweroff driver fails because of that?

8

Thanks for your response.

Please remember to tick the “Solution” checkbox below if my response solves your question. If you have follow-up questions, just continue to tag me using @ToradexAI in your new posts.

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

Thanks for your detailed testing and explanation.

Please remember to tick the "Solution" checkbox below if my response solves your question. For follow-up questions, just continue to tag me using @ToradexAI in your new posts.

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

Excellent debugging! Your observation about the libgpiod API version change is very insightful. The fact that manual GPIO control via gpioset works when the overlay is disabled, but the gpio-poweroff driver fails when the overlay is enabled, suggests the issue is indeed likely related to the libgpiod API changes between versions.

However, the gpio-poweroff driver is a kernel-space driver that should use the kernel's internal GPIO API, not the userspace libgpiod API. But there could be interactions or changes in how the kernel GPIO subsystem works with the newer libgpiod version.

Since the sysfs GPIO interface has been deprecated and the GPIO Char Device API (libgpiod) has been adopted as the replacement (details), there may be subtle changes in how the kernel handles GPIO operations that affect the gpio-poweroff driver.

Potential Solutions to Try:

  1. Check kernel logs during shutdown attempt:
    When you have the overlay enabled, try to shutdown and check dmesg for any gpio-poweroff related messages or errors. This might reveal if the driver is failing to acquire or control the GPIO.
  2. Verify the GPIO driver initialization:
    Check if the gpio-poweroff driver is properly initializing:
    dmesg | grep -i "gpio.*power"
  3. Alternative approach - use a different GPIO pin:
    Try using a different GPIO pin to see if the issue is specific to lsio_gpio4 2 or affects all GPIO pins with the gpio-poweroff driver.
  4. Check for GPIO conflicts:
    Ensure no other drivers or device tree nodes are trying to use the same GPIO pin, which could cause conflicts in the newer kernel version.

The fact that manual control works but the automated driver doesn't suggests there may be a timing issue, initialization order problem, or API compatibility issue between the gpio-poweroff driver and the newer GPIO subsystem in kernel 6.6.x.

Best regards, Toradex AI Assistant.

10

@ToradexAI
So after a bit of digging with my oscilloscope and within the gpio-poweroff documentation, I came out with the idea of setting the inactive-delay-ms within my overlay like this

// SPDX-License-Identifier: GPL-2.0-or-later OR MIT

// GPIO power off handling
#include <dt-bindings/gpio/gpio.h>

/dts-v1/;
/plugin/;

/ {
    compatible = "toradex,apalis-imx8", "toradex,apalis-imx8-v1.1";
};

&{/} {
    gpio_poweroff: gpio-poweroff {
        compatible = "gpio-poweroff";
        gpios = <&lsio_gpio4 2 GPIO_ACTIVE_LOW>;
        timeout-ms = <3000>;
        active-delay-ms = <1000>;
        inactive-delay-ms = <1000>;
        priority = <1>;
        // Make sure the pin is configured as GPIO
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_gpio6>;
    };
};

// If enabled, this would change the pin muxing as well
&flexcan3 {
    status = "disabled";
};

When measured, the gpio 6 does move at shutdown, I can clearly see it toggling for 1sec down then 1sec up and then it waits 3sec to timeout. I also looked at the Ixora board schematics and went to measure the KILL input of the LTC2954 but this one does not seems to go down.

So deffinitly the overlay works.

But it seems that the IC4 chip is not working properly on the Ixora coarrier board. So I measured the RESET_MOCI signal and… BINGO. Compared to the previous version, it goes down a bit earlier. Ence this prevent the FORCE_OFF signal to be transmitted further to the KILL input of the LTC2954.

My question now is if it is possible to delay the RESET_MOCI action? on the kirkstone version, the RESET_MOCI signal was only going down because the board was powered-off. So it seems that something changed with recent version to switch off RESET_MOCI properly at shutdown, but apparently it comes to early.

force_off
force_off1872×1500 163 KB

11

Thanks for your response.

Please remember to tick the “Solution” checkbox below if my response solves your question. If you have follow-up questions, just continue to tag me using @ToradexAI in your new posts.

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

Thanks for your response.

Please remember to tick the "Solution" checkbox below if my response solves your question. For follow-up questions, just continue to tag me using @ToradexAI in your new posts.

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

Excellent debugging work! You've identified the root cause—the RESET_MOCI signal timing has changed between Kirkstone and Scarthgap, causing it to go low too early and preventing the FORCE_OFF signal from reaching the LTC2954's KILL input.

This is actually a known issue with Apalis iMX8 modules. According to the Apalis iMX8X Errata documentation, there's a specific errata regarding POWER_ENABLE_MOCI behavior due to backfeeding. The POWER_ENABLE_MOCI signal (which is the RESET_MOCI signal you're measuring) can remain between 1.0V and 1.4V in module shutdown, and depending on the carrier board circuit, this can affect the timing of peripheral voltage rail control.

The errata specifically mentions that on Ixora V1.2, a different buck converter for the 5V_SW is used than on previous versions, and the threshold voltage for the enable signal is lower on the new buck converter. This could explain why the timing behavior changed.

Potential Solutions:

  1. Workaround from the errata: The errata suggests adding a circuit to the carrier board for increasing the POWER_ENABLE_MOCI threshold voltage to between 2.0V and 2.5V. This could be achieved by adding a comparator or similar circuit.

  2. Simple voltage divider solution: A simple voltage divider added to the POWER_ENABLE_MOCI signal can shift the voltage levels. With the AOZ2260 buck converter (used on Ixora V1.2), a 10k/10k voltage divider can be a suitable option.

  3. Software timing adjustment: Since you’ve confirmed your GPIO power-off overlay is working, you might need to adjust the timing parameters in your overlay to account for the earlier RESET_MOCI transition. Try increasing the active-delay-ms and inactive-delay-ms values further to ensure the FORCE_OFF signal has enough time to trigger the LTC2954 before RESET_MOCI goes low.

The fact that this worked in Kirkstone but not in Scarthgap suggests that the newer kernel version has improved the RESET_MOCI timing behavior (making it more predictable), but this has inadvertently affected the power-off sequence timing on your carrier board.

For more details on this issue and the hardware workaround, please refer to the Apalis iMX8X Errata documentation, specifically Errata #1: HAR-8349 - POWER_ENABLE_MOCI indeterminate due to backfeeding:
https://developer.toradex.com/hardware/legacy-products/apalis-som-family/apalis-imx8x

Best regards, Toradex AI Assistant.

12

Hey @leonardo.costa.tx

It looks like the ToradexAI won’t be bale to solve this issue further (having done a great rubber ducky job until now)

Do you think that the RESET_MOCI issue is solvable?

13

So apparently, the reset_moci is used by the PCIe. So I had to disable it with an overlay to fix this issue.

// SPDX-License-Identifier: GPL-2.0-or-later OR MIT

// GPIO power off handling
#include <dt-bindings/gpio/gpio.h>

/dts-v1/;
/plugin/;

/ {
    compatible = "toradex,apalis-imx8", "toradex,apalis-imx8-v1.1";
};

&{/} {
    reg_reset_moci: regulator-reset-moci {
        compatible = "regulator-fixed";
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_reset_moci>;
        gpio = <&lsio_gpio0 30 GPIO_ACTIVE_HIGH>;
        enable-active-high;
        regulator-always-on;
        regulator-name = "reset-moci";
        startup-delay-us = <100000>;
    };
};

// If enabled, this would change the pin muxing as well
&pciea {
    status = "disabled";
};

Now for Toradex, I think something should be done about this because the PCIe make it impossible to use correctly a gpio-poweroff on the Ixora carrier board

Edit: I will still not mark this issueas solved because after some further testing, it seems that the shudtown works but when doing a reboot, the KILL input forces the system to shutdown (maybe because reset_moci does not go down but the gpio6 does, so the force_off signal might go through). I tried to just disable pciea and not add the regulator, but it goes back to the first issue

14

Hey, @Romain.Donze,

I apologize for the delayed response, I only managed to set up a test for your use-case yesterday. I managed to reproduce your issue in one of our Ixora carrier boards, and observed the same behavior you described.

Still, I don’t understand why exactly you are connecting the GPIO poweroff output to the FORCE_OFF signal of the board. Since the board’s power is cut off automatically when the system shuts down, it shouldn’t be necessary to force it with the GPIO, what is your use-case exactly? I could imagine using the FORCE_OFF signal for testing purposes, and deactivating an external power source using the GPIO in production, but the RESET_MOCI signal shouldn’t be a problem in that case. Can you elaborate more on this?

Best regards,

15

Hi @leonardo.costa.tx

The problem with the LTC2954 is that if we do a software shutdown, the chip will not be turned off. So if we want to then restart the board by pressing the power button, we will have to press the power button twice (once to force the LTC2954 off and once to start the board) or either unplug and replug the board. So the only way to do a clean power cycle with software shutdown and then restart with the power button is to FORCE_OFF the LTC2954. In our case with the use of the gpio power-off.

That is why we used the gpio6 in our kirkstone version. But then with scarthgap, it seems that something change with the way the RESET_MOCI is used and it doesn’t work anymore

Edit: also we are mounting the C35 capacitor on the LTC2954 to provide a longer press to hard turn off the board, so this add to the issue that if we do a software shutdown we will then have to press de power button (for ~3sec) to turn off the LTC2954 and then only we can press the power button to turn on the board again

16

Hey, @Romain.Donze,

I talked with our BSP team about the issue and also had them take a look into it. I’ll be opening a request for implementing a workaround to cut the power via software, or to make modifications such that the RESET_MOCI signal is toggled later.

Though, since this a very specific and non-intended use-case, we don’t guarantee that this is going to be worked on any time soon. Is this a significant constraint to your project?

Best regards,

17

Hi @leonardo.costa.tx,

Thank you for looking further into this issue. For now this feature is pretty important for us but we have a “not so tight” schedule on it (about 3 weeks from now) hoping it could be solved until then.

Appart from that, I don’t understand why this would not be an intended use-case as it is clearly stated here (GPIO (Linux) | Toradex Developer Center) that a gpio can be used to power-off a system completely after a shutdown. Wich is exactly what we are trying to do here.

Am I missimg something on the doc? Or is the doc obsolete?

18

Hi, @Romain.Donze,

I already made the request for fixing the issue. As for the documentation, yes, it seems that it is out of date, I’ll also talk to the developer website team to update that page.

Unfortunately, since the internal planning for the next Quarterly release is already made, this issue will probably not be worked on under the 3 weeks you estimated. Having said that, you can check out our list of partners to find one who can help you find an alternative solution for your project. If you have issues figuring out what partner to choose, let me know and we can point you to a specific one.

Best regards,

19

Hi @leonardo.costa.tx,

I wanted to let you know that I came up with a clean-ish solution that works for shutdown as well as reboot. I managed to do it with a single device-tree overlay

apalis-imx8_gpio-poweroff_overlay.dts

// SPDX-License-Identifier: GPL-2.0-or-later OR MIT

// GPIO power off handling
#include <dt-bindings/gpio/gpio.h>

/dts-v1/;
/plugin/;

/ {
    compatible = "toradex,apalis-imx8", "toradex,apalis-imx8-v1.1";
};

&{/} {
    gpio_poweroff: gpio-poweroff {
        compatible = "gpio-poweroff";
        gpios = <&lsio_gpio4 2 GPIO_ACTIVE_LOW>;
        timeout-ms = <3000>;
        active-delay-ms = <1000>;
        inactive-delay-ms = <1000>;
        priority = <1>;
        // Make sure the pin is configured as GPIO
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_gpio6>;
    };
    
    gpio_reset_moci: gpio-restart {
        compatible = "gpio-restart";
        gpios = <&lsio_gpio0 30 GPIO_ACTIVE_LOW>;
        active-delay = <100>;
        inactive-delay = <0>;
        wait-delay = <0>;
        priority = <192>;
        // Make sure the pin is configured as GPIO
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_reset_moci>;
    };
};

// If enabled, this would change the pin muxing for pinctrl_gpio6
&flexcan3 {
    status = "disabled";
};

// If enabled, this would change the pin muxing for pinctrl_reset_moci
&pciea {
    status = "disabled";
};

As you can see, I added a gpio-restart node for the pinctrl_reset_moci. I know that this driver is not made for that but it suited my needs for now.

Subsequently, would it be possible to keep me informed regarding a more optimal solution provided by toradex in the future?

Best regards,

20

Hey, @Romain.Donze,

I’m glad you managed to solve the issue!

As per my previous post, I made a request for our team. Since this is a change in behavior from BSP 6, it seems that they will indeed be looking into it at some point.

Having said that, I’ll be marking your workaround as the solution for now.

Best regards,

21

Hello @Romain.Donze,

We looked into this issue. The reason why the behavior changed is that we are now correctly implementing the PERST# logic of the PCIe bus. The PCIe specification lists ordering and timing requirements for this signal. According to the Apalis Carrier Board Design Guide (Section 2.2.2.1), the PERST# signal should be connected to the RESET_MOCI#:

The Apalis module standard does not feature a dedicated PCIe reset output as it does not provide the PCIe hot-plug functionality. Therefore, the PCIe reset input (PERST#, pin A11) of the slot should be served by the general module reset output (RESET_MOCI#).

The Ixora board follows this and maps the PERST# pin on the MiniPCIe to the RESET_MOCI# signal. Before this software change, the PERST# signal was not behaving according to the PCIe specification.

We understand our current implementation of the RESET_MOCI# signal to be the correct one, and we will not be changing it on our default BSP device trees. However, the solution you found works well for your use case, and because you’re using standard drivers, it’s very likely that it will stay working like this in the future.

Best regards,

Rafael