I want to modify the device tree. jetpack4.6 l4t32.6.1 carrier is xaviernx’s
But when I modify the extlinux.conf, it does not work. It’s the offical image. I don’t change anything.
LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
INITRD /boot/initrd
FDT /boot/dtb/kernel_tegra186-p3636-0001-p3509-0000-a01.dtb
APPEND ${cbootargs} quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2
Technically this is the TX2 forum, and you’d want the Xavier NX forum.
FYI, there is some device tree “magic” going on prior to reaching the actual Linux kernel booting, but mostly I’d expect that changes to the device tree file, as named in the extlinux.conf file’s FDT entry to do as you expect. Note that once the system boots up you should be able to track what the current tree has by two methods. The first is to use dtc (use “sudo apt-get install device-tree-compiler” on the Jetson if you don’t have this), and the other is to browse “/proc/device-tree”.
To export:
dtc -I fs -O dts -o extracted.dts /proc/device-tree
To browse just pretend “/proc/device-tree” is the root of the tree, and that any directory is a branch in the tree, and that any file is a leaf. For example:
cd /proc/device-tree
cat chosen/bootargs
Note that the extlinux.conf entry tends to APPEND environment variable “${cbootargs}” first, and that this is determined from the device tree’s “chosen->bootargs”. You could compare (there is a possibility of earlier boot stages editing bootargs slightly).
If your changes did not make it in, then you might post which changes you made. Do note that if the .dtb file is not found from the FDT entry, then it will revert to using the one in a partition instead. Also if any security fuses are burned, then the FDT entry will always be ignored and read will only be from a properly signed partition for the device tree. Can you verify your changes made their way in?
Btw, kernel arguments are typically ignored except by the parts of the kernel which are specifically looking for those arguments. So if you were to add an argument to the APPEND (either via the extlinux.conf file or via device tree chosen->bootargs), and the kernel does not know anything about the argument, then it might be a useful test to see edits. You could for example add “by_tree” to the device tree entry for APPEND, and add “by_file” to the end of the actual extlinux.conf APPEND, and see if they appear after rebooting.
Tip: For debugging you usually want a serial console boot log, and you want the extlinux.conf APPEND to not have the “quiet” parameter.
@linuxdev
Hello!
I follow your step.
cat chosen/bootargs
I compare with the log of nano. I found that there is no variable “extlinux.conf” in the bootargs, but nano works well.
nano:
tegraid=21.1.2.0.0 ddr_die=4096M@2048M section=512M memtype=0 vpr_resize usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 console=ttyS0,115200n8 debug_uartport=lsport,4 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec=0x1000@0xff780000 core_edp_mv=1075 core_edp_ma=4000 gpt earlycon=uart8250,mmio32,0x70006000 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0
tx2nx:
console=ttyS0,115200 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2 video=tegrafb earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x1772e0000 gpt rootfs.slot_suffix= tegra_fbmem=0x800000@0x96088000 lut_mem=0x2008@0x96085000 usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 no_console_suspend boot.slot_suffix= boot.ratchetvalues=0.2031647.1 vpr_resize bl_prof_dataptr=0x10000@0x175840000 sdhci_tegra.en_boot_part_access=1 quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2
nano extlinux.conf
LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
INITRD /boot/initrd
FDT /boot/tegra210-p3448-0000-p3449-0000-b00.dtb
APPEND ${cbootargs} quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0
tx2nx extlinux.conf
LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
INITRD /boot/initrd
FDT /boot/tegra186-p3636-0001-p3509-0000-a01.dtb
APPEND ${cbootargs} quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2
tx2nx boot error:
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
913 bytes read in 25 ms (35.2 KiB/s)
1: primary kernel
Retrieving file: /boot/initrd
7238344 bytes read in 206 ms (33.5 MiB/s)
Retrieving file: /boot/Image
34484232 bytes read in 867 ms (37.9 MiB/s)
append: console=ttyS0,115200 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2 video=tegrafb earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x1772e0000 gpt rootfs.slot_suffix= tegra_fbmem=0x800000@0x96088000 lut_mem=0x2008@0x96085000 usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 no_console_suspend boot.slot_suffix= boot.ratchetvalues=0.2031647.1 vpr_resize bl_prof_dataptr=0x10000@0x175840000 sdhci_tegra.en_boot_part_access=1 quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2
Retrieving file: /boot/tegra186-p3636-0001-p3509-0000-a01.dtb
192309 bytes read in 40 ms (4.6 MiB/s)
Flattened Device Tree blob at 82400000
Booting using the fdt blob at 0x82400000
ERROR: reserving fdt memory region failed (addr=0 size=0)
ERROR: reserving fdt memory region failed (addr=0 size=0)
ERROR: reserving fdt memory region failed (addr=0 size=0)
Using Device Tree in place at 0000000082400000, end 0000000082431f34
copying carveout for /host1x@13e00000/display-hub@15200000/display@15200000…
copying carveout for /host1x@13e00000/display-hub@15200000/display@15210000…
copying carveout for /host1x@13e00000/display-hub@15200000/display@15220000…
DT property /chosen/nvidia,bluetooth-mac missing in source; can’t copy
DT property /chosen/nvidia,wifi-mac missing in source; can’t copy
DT property /reserved-memory/ramoops_carveout/alloc-ranges missing in source; can’t copy
DT property /reserved-memory/ramoops_carveout/size missing in source; can’t copy
Starting kernel …
The boot log stays here.
dtc -I fs -O dts -o extracted.dts /proc/device-tree
I can see the source is tegra186-p3636-0001-p3509-0000-a01.dts.
I don’t change anything. It’s official image.
I compile the dts from source_sync.sh. The same error.
@linuxdev his issue is for tx2-nx so it is okay to file on tx2 forum.
1 Like
Originally you said you wanted to redefine the dtb. Then I see this:
Everything which follows is because I am thinking you want to change the device tree (the “.dtb” file). Note that a “.dts” source file must first be compiled to become a “.dtb” binary file before it can be used in booting. The two are the same thing, but one is plain text and the other is binary. When building a tree from the kernel source this is also true, but the kernel tends to put together the “whole” of the device tree from different configured “pieces” of the tree…these are the “.dtsi” files which are simple pieces of a tree. Correct me if I am wrong, but I’m concentrating on getting your changes to the device tree to be applied.
What follows is about detecting if changes made their way in to the device tree/dts/dtb. Simply building a kernel will never change the device tree. Even if you do build the device tree from kernel source and install it, then it won’t differ unless something triggered a change in the device tree (for example, changing certain driver features might cause the device tree to change).
You would never see the word “extlinux.conf” in bootargs. An example of how the kernel command line arguments are generated will probably clear up any confusion (and the purpose of doing so is to see if your changes made it to the booting Jetson). What follows is simply to explain how changes to a device tree would show up, and is not normally information you’d need to know. I apologize that this is long, but it is actually simple with some patience…
During boot arguments are created which are passed to the Linux kernel command line at the moment the kernel starts running. That preparation of arguments is via things the bootloader does. The effect as a whole creates final list of arguments to pass to the kernel is shown whenever you run the command “cat /proc/cmdline”. If you can show changes to this show up, then you know your other device tree changes also went in (or at least that the other changes tried to go in).
The file “extlinux.conf” has the line “APPEND”. That line starts with what it inherits from the bootloader, but then appends more to it. The beginning of the kernel arguments is via inheritance because of the “${cbootargs}” you see in extlinux.conf. Had this been left out, then most bootloader arguments to the kernel would be missing (and likely boot would fail). Then, in addition to what is inherited, more arguments are appended if and only if the “extlinux.conf” file has more at the end of the “APPEND” beyond the “${cbootargs}”.
To illustrate consider this “APPEND”:
APPEND ${cbootargs} quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0
Compare to this kernel command line (I’ll use the NX as an example):
# cat /proc/cmdline
console=ttyS0,115200 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2 video=tegrafb earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x1772e0000 gpt rootfs.slot_suffix= tegra_fbmem=0x800000@0x96088000 lut_mem=0x2008@0x96085000 usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 no_console_suspend boot.slot_suffix= boot.ratchetvalues=0.2031647.1 vpr_resize bl_prof_dataptr=0x10000@0x175840000 sdhci_tegra.en_boot_part_access=1 quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2
Look for the word “quiet”. It exists in both the extlinux.conf “APPEND” and in the cmdline. The word “quiet” is actually the first word to the right of “${cbootargs}”. This means that in the cmdline all content up to, but excluding quiet is from the earlier boot stages. Everything at quiet and to the right is from the extlinux.conf. Everything prior/left of "quiet’ should be visible in the device tree at “/proc/device-tree/chosen/bootargs”. If not, then this was not the device tree which was loaded.
This is a nice tool to see if changes actually made their way in from the device tree because you could add some inert word to the device tree’s chosen->bootargs and see if it shows up. An example would be to add the word “mytestword” in the tree, and then reboot and see if it shows up in “/proc/cmdline”. As a contrived example:
chosen {
...
bootargs = "console=ttyS0,115200 androidboot.presilicon=true firmware_class.path=/etc/firmware mytestword";
...
};
(notice that it has “mytestword” in this version, and rebooting would make this show up in cmdline…this is harmless because “mytestword” is not something any driver is looking for)
All of the above is just to show you a way to verify your device tree changes are actually being used.
A serial console boot log is also important because there is debug information showing which tree is added, or if not, then why it failed. To see all of this though you would have to remove the word “quiet” from the “extlinux.conf”. The fact is that your current extlinux.conf is purposely hiding some log information because it has “quiet” in it. In debugging the “quiet” is your enemy.
I suggest you go into every “extlinux.conf” and delete the word “quiet”. Then get a serial console boot log, perhaps after adding the debug “fake” kernel command “mytestword” into the device tree “chosen->bootargs”. Then we can verify what truly loaded, and if there is an error, then we can find out if it was from the bootloader content, versus if it was from the extlinux.conf content. If you don’t have a serial UART USB cable, then we can live with the “dmesg” output after the “quiet” is removed, but a serial console boot log would show much more detail.
1 Like
I plan to redefine the dtb. But It doesn’t work when I modify the dts and add FDT to extlinux.conf . So I give up the plan and add the official dtb(/boot/tegra186-p3636-0001-p3509-0000-a01.dtb) FDT to extlinux.conf.
I have deleted “quiet” from “ extlinux.conf” of tx2nx. But the boot log is the same. It still stops at Starting kernel ...
cat /proc/device-tree/chosen/bootargs
I copy the bootargs to the chosen{bootargs} of dts and compile. I FDT it, but it still stops at Starting kernel ...
chosen {
board-has-eeprom;
bootargs =“console=ttyS0,115200 video=tegrafb earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x1772e0000 gpt rootfs.slot_suffix= tegra_fbmem=0x800000@0x96088000 lut_mem=0x2008@0x96085000 usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 no_console_suspend boot.slot_suffix= boot.ratchetvalues=0.2031647.1 vpr_resize bl_prof_dataptr=0x10000@0x175840000 sdhci_tegra.en_boot_part_access=1”;
stdout-path = &uarta;
nvidia,tegra-joint_xpu_rail;
};
I remember there is a bug in uboot. Let me check if similar topic.
Here it is.
@WayneWWW
It seems to work well. I can redefine the dtb now.
Thanks everybody!
1 Like
@WayneWWW
Why not merge the u-boot code?
This was already merged. Just didn’t catch the rel-32.6 release.
1 Like