m_o_bz
August 8, 2025, 7:08am
1
Basic info:
hardware: jetson-agx-orin-devkit
JetPack : 6.2
Jetson Linux : 36.4.3
Question:
I want to konw which dtb file on board is current using (or how the system chose using which dtb)
I remove all the dtb file under /boot/ , reboot the board , and it can bootup successfully
rm -rf /boot/*.dtb
there is no dtb file on board , so I guest the system must load the A-kernel-dtb for boot
but when I flash dtb partition, the system device tree has no change
sudo ./flash.sh -r -k A_kernel-dtb jetson-agx-orin-devkit mmcblk0p1
so it seems confused to me, which dtb file is loading in my situation
below is the bootup log
Jetson System firmware version 36.4.3-gcid-38968081 date 2025-01-08T01:18:20+00:
00
ESC to enter Setup.
F11 to enter Boot Manager Menu.
Enter to continue boot.
…L4TLauncher: Attempting GRUB Boot
L4TLauncher: Attempting Direct Boot
EFI stub: Booting Linux Kernel…
EFI stub: Using DTB from configuration table
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: Exiting boot services…
??debugfs initialized
??I/TC: Reserved shared memory is disabled
I/TC: Dynamic shared memory is enabled
I/TC: Normal World virtualization support is dis
Rel-36 BSP reads the device tree from UEFI dtb.
So not related to anything you deleted or updated here.
You could make the bootloader read dtb from rootfs by adding FDT field in your /boot/extlinux/extlinux.conf.
m_o_bz
August 8, 2025, 7:40am
3
what if I don’t add FDT field in extlinux.conf, just use as the SDK default setting, so how to update the UEFI dtb?
seems that I don’t find a UEFI dtb partition here? so I don’t know how to flash the UEFI dtb
[ 9.0151 ] partition_id partition_name StartingLba EndingLba
[ 9.0151 ] 1 APP 3050048 124190679
[ 9.0151 ] 2 A_kernel 40 262183
[ 9.0151 ] 3 A_kernel-dtb 262184 263719
[ 9.0151 ] 4 A_reserved_on_user 263720 328487
[ 9.0151 ] 5 B_kernel 328488 590631
[ 9.0151 ] 6 B_kernel-dtb 590632 592167
[ 9.0151 ] 7 B_reserved_on_user 592168 656935
[ 9.0152 ] 8 recovery 656936 820775
[ 9.0152 ] 9 recovery-dtb 820776 821799
[ 9.0152 ] 10 esp 821800 952871
[ 9.0152 ] 11 recovery_alt 952872 1116711
[ 9.0152 ] 12 recovery-dtb_alt 1116712 1117735
[ 9.0152 ] 13 esp_alt 1117736 1248807
[ 9.0152 ] 14 UDA 1248832 2068031
[ 9.0152 ] 15 reserved 2068032 305004
is the commd like below?
sudo ./flash.sh -r -k DTB jetson-agx-orin-devkit mmcblk0p1
update the whole cpu-bootloader partition or just update everything on the QSPI will update that.
m_o_bz
August 8, 2025, 7:56am
5
ok i try to update bootloader
m_o_bz
August 8, 2025, 8:13am
6
is using command below to update ? seems some time it will no take affect
I modify the pinmux and gpio dtsi and flash bootloader
sudo ./flash.sh -k A_cpu-bootloader jetson-agx-orin-devkit mmcblk0p1
m_o_bz
August 8, 2025, 9:02am
7
I also try to update the whole qspi, but the change in pinmux dtsi is not take affect
sudo ./flash.sh --no-systemimg -c bootloader/generic/cfg/flash_t234_qspi.xml jetson-agx-orin-devkit internal
for example the pinmux in dtsi file ( tegra234-mb1-bct-pinmux-p3701-0000-a04.dtsi)
eqos_txc_pe0 {
nvidia,pins = "eqos_txc_pe0";
nvidia,function = "eqos";
nvidia,pull = <TEGRA_PIN_PULL_NONE>;
nvidia,tristate = <TEGRA_PIN_DISABLE>;
nvidia,enable-input = <TEGRA_PIN_ENABLE>;
};
but in the /proc/device-tree, function is not eqos
eqos_txc_pe0 {
nvidia,tristate = <0x00>;
nvidia,function = "rsvd1";
nvidia,pull = <0x00>;
nvidia,enable-input = <0x01>;
nvidia,pins = "eqos_txc_pe0";
};
how can I double check the UEF dtb file is correct while on the host machine
Pinmux dtsi is not part of kernel/uefi dtb.
It is a input file for MB1 to use. I think you got some misled here. Not every dtsi goes to kernel/uefi dtb.
m_o_bz
August 8, 2025, 10:55am
10
m_o_bz:
eqos_txc_pe0 {
nvidia,pins = "eqos_txc_pe0";
nvidia,function = "eqos";
nvidia,pull = <TEGRA_PIN_PULL_NONE>;
nvidia,tristate = <TEGRA_PIN_DISABLE>;
nvidia,enable-input = <TEGRA_PIN_ENABLE>;
};
so what’s the workflow after update the pinmux dtsi?
the online wiki just says flash , but with no more details, about flash which part image? or am I miss some document, pls corrent me
Which file did you change for the pinmux? The dtsi is located inside of Linux_for_Tegra/bootloader
Your flash log will tell what dtsi got flashed to the board.
m_o_bz
August 8, 2025, 11:01am
12
I change bootloader/generic/BCT/tegra234-mb1-bct-pinmux-p3701-0000-a04.dtsi
and flash log is also this file
copying pinmux_config(/JetPack_6.2_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra/bootloader/generic/BCT/tegra234-mb1-bct-
pinmux-p3701-0000-a04.dtsi)… done.
Please check if you accidentally add your dtsi to the kernel dts file first.
I don’t think /proc/device-tree shall give you anything related to eqos_txc_pe0 pinmux. If there is this thing in your final kernel dtb, please remove it.
The change you made in MB1 dtsi won’t show up in /proc/device-tree.
It will just update the pinmux setting since the MB1 bootloader and keep it until kernel is up. Unless some other drivers change it again.
Read the register is the most precise way to confirm the pinmux is correctly set.
1 Like
m_o_bz
August 8, 2025, 11:06am
14
I also change the file "source/hardware/nvidia/t23x/nv-public/nv-soc/tegra234-soc-overlay.dtsi
the change I made is the same in file bootloader/generic/BCT/tegra234-mb1-bct-
pinmux-p3701-0000-a04.dtsi
Please remove every pinmux setting in your kernel dtb. You don’t need to do those thing multiple times. MB1 setting will cover that.
m_o_bz
August 8, 2025, 11:21am
16
I remove all the mux in "source/hardware/nvidia/t23x/nv-public/nv-soc/tegra234-soc-overlay.dtsi
recompile the dtbs and flash
sudo ./flash.sh -r -k A_kernel-dtb jetson-agx-orin-devkit mmcblk0p1
and also reflash the booloader
sudo ./flash.sh -r -k A_cpu-bootloader jetson-agx-orin-devkit mmcblk0p1
boot the system and check the /proc/device-tree, now there is no eqos_txc_pe0 relate mux config
so currently the only way to konw the pinmux is fine is using reading register?
by the way, reading register seems so not that convenient sometime compare to human readble strings output
what if the output of register is below, which means the pinmux is eqos?
busybox devmem 0x02445058
0x00002440
no other quick and convenient way to check it?
m_o_bz
August 11, 2025, 6:37am
17
I remove all the pinmux in kernel dtsi, only modify the bootloader/generic/BCT/tegra234-mb1-bct-pinmux-p3701-0000-a04.dtsi to as below to test
eqos_txc_pe0 {
nvidia,pins = "eqos_txc_pe0";
nvidia,function = "rsvd1";
nvidia,pull = <TEGRA_PIN_PULL_NONE>;
nvidia,tristate = <TEGRA_PIN_DISABLE>;
nvidia,enable-input = <TEGRA_PIN_ENABLE>;
};
reflash the kernel-deb and bootloader
sudo ./flash.sh -r -k A_kernel-dtb jetson-agx-orin-devkit mmcblk0p1
sudo ./flash.sh -r -k A_cpu-bootloader jetson-agx-orin-devkit mmcblk0p1
enter the system and check, the result is the same, which is eqos pinmux, not rsvd1
busybox devmem 0x02445058
0x00002440
Just to clarify. You need to do full flash. Not -r -k any partition.
m_o_bz
August 11, 2025, 6:46am
19
You mean every time modify the pinmux need to flash all partitions include rootfs partition? why is that? the pinmux affect some binary blob in the rootfs partition?
As I already mentioned, pinmux is handled by MB1 bootloader. It is not any file in rootfs or kernel dtb partition. And to fully flash MB1, you should do full flash.
m_o_bz
August 11, 2025, 6:52am
21
You mean full spi flash like below?
sudo ./flash.sh --no-systemimg -c bootloader/generic/cfg/flash_t234_qspi.xml jetson-agx-orin-devkit internal