Check success of pinmux changes on target system

Hello,

we have developed a custom carrier board and have been following the Jetson Xavier NX Adaptation and Bring-Up Guide, as well as the examples in GPIO customization on Jetson Platform - Jetson & Embedded Systems / Jetson Xavier NX - NVIDIA Developer Forums.

In opposite to the modification (modify spreadsheet + generate) and transcription process (dtsi → cfg), i didn’t found any information about how to validate the application of the pin config mods on the target system at run/boot-time.

I see dmesg output like:
GPIO line 339 (wifi-enable) hogged as output/high
but the gpio/int number corresponding to the gpios we changed are not printed there.

Also, the output of /sys/kernel/debug/gpio does not contain an already mapped driver/function for those gpios (so it seems to be available for free usage) but the changes for Req. Init States (None → Drive 1) are not reflected there, nor we can measure any differences in the resulting signal from those gpios!

Does that mean, we look on the right logs, but nothing is applied or are we simply reading the wrong log infos?

Or more generally:
How can we get sure that our pinmux really has been loaded during boot phases?

hello J4n_J4ns3N,

there’s readme file for details of converting the pinmux, gpio and pad dts file to cfg format.
i.e. $OUT/Linux_for_Tegra/kernel/pinmux/t19x/README.txt

after you have created cfg file, you’ll need to replace that and perform a full-flash process to update the target.
you should also check /sys/kernel/debug/pinctrl/2430000.pinmux/pinmux-pins for your pin configurations.

I can’t do a full-flash in my system, too many changes, so can I have a pointer to the flash command that will recreate the info from the .cfg file. I know even if all .cfg files has the correct making the kernel and reloading the DTB will now fix previous .cfgs

Thanks,
Terry

hello terrysu50z,

may I know what’s your actual use-case.
the proper process is flashing the target fully to update the board configuration file.
it’s bootloader stage to parse the info through the *.cfg file, and later the kernel to read from device tree blob.

that is the point to validate my pinmux changes, thx!

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