How to determine the hexadecimal encoding of GPIO?

Version

R32.6.1

Then can I reboot ?

I suggest that instead of replacing the old entry you make a new one. Then, if something goes wrong, you can use the serial console during boot to pick the original. You could eliminate the original content if the new content works well. Example, based on your listed extlinux.conf:

TIMEOUT 30
DEFAULT updated

MENU TITLE L4T boot options

LABEL updated
      MENU LABEL updated tree
      LINUX /boot/Image
      INITRD /boot/initrd
      FDT /boot/new.dtb
      APPEND ${cbootargs} quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      INITRD /boot/initrd
      APPEND ${cbootargs} quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0

Assuming security fuses are not burned, and if there is no FDT entry in extlinux.conf, then it boots to the signed partition device tree. Otherwise it will boot to the FDT entry of extlinux.conf. No need to flash if just working on the FDT entry.

Incidentally, a .dtsi file is a subset of a .dts file. The dtc tool (“sudo apt-get install device-tree-compiler”) @JerryChang mentioned is used quite often to convert between formats. You won’t be able to convert a .dtsi file though since it is only a fragment. If you have a complete .dts or .dtb file, then you can easily convert back and forth between formats. A lot of people take the binary .dtb and convert it to the source .dts, edit, and then convert it back to the binary .dtb for testing.

1 Like

Thanks! Your suggestion is very helpful !!
However, I still have a problem. When I try to convert the .dtb file in /boot , the out put .dts file usually use hex code, like this

That’s why I asked how to convert a .dtsi file set to a .dtb.

In addition, I would like to ask how to determine whether the change will take effect.

Hello, is there anyone else who can answer my question?
I still want to find a PIN. I want to use a high-level trigger to wake up my Jetson at a specified time.
As for the prompt given above, I tried to use the trigger IO port of the SD card, but it did not lead out a pin, so I cannot use it.

In addition, I modified extlinux.conf, but it doesn’t seem to work. In order to determine whether the dtb file I modified works, I deleted the startup function of the power key, but it seems that it still starts when I press the PWR BTN, so I guess the changes I made may not take effect.
The part I changed is :

gpio-keys {
		compatible = "gpio-keys";
		gpio-keys,name = "gpio-keys";
		status = "okay";

		sw_wake {
			label = "sw-wake";
			interrupt-parent = <0x26>;
			interrupts = <0x0 0xb3 0x4>;
			linux,code = <0x74>;
			wakeup-source;
		};

		forcerecovery {
			label = "force-recovery";
			gpios = <0x13 0x30 0x1>;
			linux,code = <0x8f>;
			gpio-key,wakeup;
			debounce-interval = <0x0a>;
			nvidia,pmc-wakeup = <0x56 0x0 0x43 0x01>;
		};


		wakeup_key {
			label = "wakeup_key";
			gpios = <0x13 0x69 0x1>;  //GPIO13 
			linux,code = <0x74>; //Wakeup
			gpio-key,wakeup;
			debounce-interval = <0x1e>;
			nvidia,pmc-wakeup = <0x56 0x0 0x4 0x0>; 
		};
	};

So I want to confirm two things:

  1. How to determine whether the changed CBoot (extlinux. conf) takes effect?
  2. How can I change the existing pin so that I can get a wake-up Jetson pin?

FYI, passing content as hexadecimal is not a problem. That notation is passed to the driver, and in the C language, if I enter “37” or “0x25” the result is the same. Device tree content is basically passed to drivers. Hexadecimal is used extensively in the device tree and in the kernel. Is there a problem with hexadecimal?

Also, if the kernel sees something passed to it which a particular driver does not understand, then typically it is just ignored without error (this is not an actual argument to a C function whereby the arguments are strongly typed…it is an environment which is iterated through and each “interesting” part is passed to the interested code, while other parts are ignored; you might get a warning when running that code, but this is different than an actual dtc tool error).

If you make a change, then you can examine it in a subdirectory of “/proc/device-tree”. This is the kernel, in RAM, reflecting the structure of the device tree as it sees it. It is true though that in some cases earlier boot code can change this before passing it to the kernel, but that is rare. And so if you’ve made a change, then compare your change and see if it made its way in. To export that content as a “.dts” source file:
dtc -I fs -O dts -o extracted.dts /proc/device-tree
(then compare that node in extracted.dts to the node you edited)

Also, a full serial console boot log usually shows what is used from extlinux.conf.

Hello!
I try to compile the dtb file , but it said that there is a syntax error , can you tell me how to write it?

power_key {
			label = "power-key";
			gpios = <&tegra_aon_gpio TEGRA194_AON_GPIO(EE, 4) GPIO_ACTIVE_LOW>;
			linux,code = <KEY_WAKEUP>;
			gpio-key,wakeup;
			debounce-interval = <30>;  
			nvidia,pmc-wakeup = <&tegra_pmc PMC_WAKE_TYPE_GPIO 29 PMC_TRIGGER_TYPE_HIGH>;   // ERROR
		};

		wake_key {
			label = "wakeup-key";
			gpios = <&tegra_main_gpio TEGRA194_MAIN_GPIO(N, 1) GPIO_ACTIVE_LOW>; 
			linux,code = <KEY_WAKEUP>;
			gpio-key,wakeup;
			nvidia,pmc-wakeup = <&tegra_pmc PMC_WAKE_TYPE_GPIO 4 PMC_TRIGGER_TYPE_HIGH>;    // ERROR
			debounce-interval = <30>;
		};

BTW,
if the wakeup pin of GPIO13 is NO, can I use GPIO13 as wake up pin ?


If not, how can the regenerated pinmux file (. dtsi ->. cfg) overwrite the current pin mapping?

And what‘s the real mean of these code ?

hello 7175380,

please refer to kernel documentation for using this wake up events.
nvidia,pmc-wakeup : <pmc_phandle event_type event_offset trigger_type>
pmc_phandle: the phandle of PMC device tree node
event_type: 0 = PMC_WAKE_TYPE_GPIO; 1 = PMC_WAKE_TYPE_EVENT
event_offset: the offset of PMC wake mask register
trigger_type: set 0 when event_type is PMC_WAKE_TYPE_GPIO,
if event_type is PMC_WAKE_TYPE_EVENT,
0 = PMC_TRIGGER_TYPE_NONE
1 = PMC_TRIGGER_TYPE_RISING
2 = PMC_TRIGGER_TYPE_FALLING
4 = PMC_TRIGGER_TYPE_HIGH
8 = PMC_TRIGGER_TYPE_LOW

Hello JerryChang! Thanks for your reply!

About this one, what is the the phandle of PMC device tree node of Xavier NX ?

And about this one, how to solve it?

hello 7175380,

honestly, you may trace the code.

please see-also developer guide, Pinmux Changes.
there’s python script to convert pinmux dts into cfg format.
i.e. $OUT/Linux_for_Tegra/kernel/pinmux/t19x/pinmux-dts2cfg.py

Sorry, I didn’t describe my problem clearly.
My mean is that I have got the cfg file and how can I overwrite the current pin mapping?

hello 7175380,

you need to update the PINMUX_CONFIG, then please perform full flash the target to apply the cfg file.
please also check flash configuration file, i.e. p3668.conf.common

PINMUX_CONFIG="tegra19x-mb1-pinmux-p3668-a01.cfg";