Orin Port A.01 GPIO does not work during boot

Hi Folks -

We have a custom carrier board for Orin that uses port A.01 (a.k.a. GPIO05 or DAP6_DOUT). We have tried to set the GPIO to an OUTPUT 1 with the excel pinmux spreadsheet and manually by adding the correct entry to the GPIO file:

/ { 
       gpio@2200000 {
                 ....
                 gpio_main_default: default {
                                 ....
                        gpio-output-high = <
                                TEGRA234_MAIN_GPIO(Y, 0)
                                TEGRA234_MAIN_GPIO(Y, 1)
                                TEGRA234_MAIN_GPIO(Y, 2)
                                TEGRA234_MAIN_GPIO(Z, 0)
                                TEGRA234_MAIN_GPIO(Q, 1)
                                TEGRA234_MAIN_GPIO(G, 3)
                                TEGRA234_MAIN_GPIO(AC, 7)
                                TEGRA234_MAIN_GPIO(K, 5)
                                TEGRA234_MAIN_GPIO(A, 0)
                                TEGRA234_MAIN_GPIO(A, 1)
                                TEGRA234_MAIN_GPIO(A, 2)
                                TEGRA234_MAIN_GPIO(A, 3)
                                >;
                };
        };
};

We also include an entry to our device tree to “redirect” the regulator@114 for PCIE that uses this pin to another unused pin:

        fixed-regulators { 
                regulator@114 {
                        gpio = <&tegra_main_gpio TEGRA234_MAIN_GPIO(P, 4) 1>;
                };
        };

Checking the device tree after boot in /proc/device-tree, these changes “took”.

Unfortunately, during boot, something else is controlling this pin and leaves it in the off state. We watch during the boot cycle, and it starts high and stays high until this part in UEFI:

Loading driver at 0x00804C69000 EntryPoint=0x00804C73F38 PcieControllerDxe.efi
PROGRESS CODE: V03040002 I0

PCIe Controller-1 Link is DOWN
PCIe Controller-4 Link is DOWN
PCIe Controller-5 Link is DOWN
PROGRESS CODE: V03040003 I0

At this point, the pin goes low and stays low until the application starts. Once in the application, we can turn the pin on again using the /sys/class/gpio features. However, we need it on during boot to get peripherals to initialize correctly.

We tried to force it high by setting the pin as the enable for a fixed-regulator, regulator-always-on, but it turned on after the peripheral initialization so it didn’t do any good. If we could turn it on first, that would good too.

Does any one know what is controlling this pin, and how we can take control back? Alternately, how can we force the pin back high at the start of kernel initialization?

Thanks,
sam

@WayneWWW solved this problem for us when he solved our other problem over at UEFI with RGMII is slow to boot. The key realization is that there are two device tree files to change.

To change pinmux and GPIO, change both

DTB_FILE = my-custom-board.dtb
TBCDTB_FILE = my-custom-board.dtb

This changes the pinmux and gpio for both the bootloader and the device tree.

Thank you @WayneWWW. Please consider this issue resolved.

-sam

1 Like

Glad to know issue resolved, topic closed.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.