PINMUX, GPIO Change Overlay

Robotics & Edge Computing Jetson & Embedded Systems Jetson AGX Orin
,
1

Hi Community,

Anyone was able to change the pinmux gpio without reflashing/replacing the entire Image?

$ grep -r “soc_gpio23_pp4” /boot
grep: /boot/Image: binary file matches

I’m not sure I understood the steps on Documentation. I need to reflash my board again to change if a gpio is on pull_up to pull_down? Or just recompiling the Image and replacing it will suffice?

Example:

            soc_gpio23_pp4 {
                nvidia,pins = "soc_gpio23_pp4";
                    nvidia,function = "vi0";

                    + nvidia,pull = <TEGRA_PIN_PULL_UP>;
                    - nvidia,pull = <TEGRA_PIN_PULL_DOWN>;

                    nvidia,tristate = <TEGRA_PIN_ENABLE>;
                    nvidia,enable-input = <TEGRA_PIN_ENABLE>;
                    nvidia,io-high-voltage = <TEGRA_PIN_DISABLE>;
                    nvidia,lpdr = <TEGRA_PIN_DISABLE>;
            };

Can I create an overlay (it should be more or less like that I think):

/dts-v1/;
/plugin/;

/ {
fragment@0 {
    target-path = "/pinmux@2430000";
        __overlay__ {
        soc_gpio23_pp4 {
            nvidia,pins = "soc_gpio23_pp4";
            nvidia,function = "vi0";
            nvidia,pull = <2>;
            nvidia,tristate = <1>;
            nvidia,enable-input = <1>;
            nvidia,io-high-voltage = <0>;
            nvidia,lpdr = <0>;
            };
        };
    };
};

Compile it to dtbo and add that to the /boot/extlinux/extlinux.conf

Or are there an easier way to change that? I saw that we can use busybox but that isn’t reboot persistant, and I don’t want to look for each register while deving.

Thanks

4

Hi @tarcisio.jaolive,

I hope you are doing well.

  • For pinmux changes , you need to reflash the board with the new .dtsi files generated from the spreadsheet and update your machine configuration (board.conf) accordingly, as mentioned in the NVIDIA documentation.

  • Overlay suggestion: Not sure about this approach but if the pin you want to modify is not critical to the bootloader, using a DTB overlay might work to apply changes at runtime and make them persistent after boot. However, changing a boot-critical pin via overlay could also cause boot failures. Might be worth it to give it a try.

  • For keeping the changes done after boot, I suggest creating a systemd service that runs at boot and executes your busybox devmem commands to configure the pinmux at runtime. This allows you to avoid reflashing during development. You could follow this guide for changing the pinmux using busybox: Changing the pinmux

Let me know if this helps.

Best regards,
Nico
Embedded Software Engineer at ProventusNova

6

Hi tarcisio.jaolive,

Are you using the devkit or custom board for AGX Orin?
What’s the Jepack veriosn in use?

Yes, you would need to reflash the board.
Instead of reflashing the whole board, you can simply run the following command to flash QSPI only, which may prevent you erase the APP partition.(i.e. rootfs)

$ sudo ./flash.sh -c bootloader/generic/cfg/flash_t234_qspi.xml jetson-agx-orin-devkit internal

This method is just like what jetson-io tool would do.
There’s a pinctrl driver in kernel can also configure the pinmux according to what you add in device tree, but I would still suggest using pinmux spreadsheet as the generated pinmux/gpio dtsi will be loaded in early boot stage(i.e. MB1) rather than kernel.

7

DevKit AGX,
I did use busybox yesterday to change input to output and it worked, but I don’t know if the pull mode would change if i changed there and not since reboot so I did not wanted to do it until I got an answer here. I did end up changing with the complete flash yesterday. Will test the pseudo-flashing with just the QSPI if i need to do further changes.
@nico.morua What would define a boot-critical pin or not? The GPIO I want to use is set as unused so I imagine it would not be included on that category.
When I tried the dtbo it deactivated my camera overlay so I think that i got the path wrong.

I’ll give you a heads up on the best scenario I find. Thanks.

@KevinFFF
Devkit, R36.4, jetson-io the python library? If yes when i tried to change the pull mode it said it wouldn’t be considered.
I need to test if by using busybox the value actually changes or if the circuit described on the TM only reads some parts of the register at boot and does not change dynamically the pin pull mode.

I’ll do some testing and come back with some sort of report. Thanks for the help.