should I use the same operation for the kernel? If so, can you help me with the command? I see kernel/Image so I’m assuming I update that but I’m not sure on the partition as I don’t see that in flash.xml.
I tried “FDT /boot/tegra186-quill-p3310-1000-c03-00-base.dtb” (in fact pointed to another dtb, all the updated dtbs and kernel Image in a sub-directory under /boot/, e.g. /boot/test_kernel) with R28.1 and it worked. And this method seems more convenient when developing. One important thing is that there should not be any spaces in the “FDT” line after “.dtb”.Otherwise the dtb file can’t be retrieved.
There may be issues if a device tree changes between U-Boot stage and the kernel running. A good example is that USB2 is supported in U-Boot, but USB3 is not. If the USB port is configured as USB2 in the kernel, then you can boot with a USB SATA external hard drive and things just work. If you configure the port to be USB3 in the kernel, then when the controller transitions from USB2 to USB3 the USB hard drive will be lost, and boot will fail.
There may be other hardware where a continuity of service fails as the device tree changes between U-Boot and kernel load. If the device tree is valid though, I would think that restarting the network would succeed…but keep in mind that if the device tree changed, then the driver must change, and the driver and device tree must match.
yep, I agree but not really sure I can do much about this. It may be that u-boot/Linux are sharing the device tree? At any rate, if I have the kernel consume a different device tree the Ethernet adapter doesn’t get loaded. Restarting networking is a no go at that point ;)
The device tree is really hardware state, although there is software which might or might not use it. You might consider starting by extracting the total device tree state at the moment of boot and editing that instead of using whatever file is assumed to match:
However, I found a way to make the “FDT” work as it’s not convenient for us to flash DTB in recovery mode as this:
On one TX2 flashed DTB in “official” way:
dd if=/dev/mmcblk0p15 of=test.dtb
Put test.dtb on another TX2, and make “FDT” point to it.
Sorry, I thought this work but it didn’t. I wrote something wrong in the extlinux.conf and another kernel booted that made me think it works.Put test.dtb on another TX2, use dd again should work:
dd if=test.dtb of=/dev/mmcblk0p15
When I looked into the “flash.sh” dtb related part, I found the script append bootargs to the original DTB with some “sed” commands. Hopefully we can use “FDT” and bootargs appended directly instead of using “flash.sh”.
I was trying to flash the device tree utilizing the method proposed in this post. And actually the operation successfully completed. But when I tried to Reverse Compile the “newly” flashed device tree file in /boot/dtb I saw that my changes were not applied to the device tree file. Moreover the modified date was the original one, though file’s size was changed from 267.8kB to 268.0kB.
BTW, when I verified (Reverse Compile) my *.dtb file that I thought that I flashed (the *.dtb file) I saw my changes.
The dtb file is used in different locations now. Some of its content has moved to the boot loader itself, so this file named in extlinux.conf or found in “/boot” is not a complete reflection of what your system used. See the above posts about using flash instead of extlinux.conf.
You’ll see in the posts earlier in this thread what basically is an evolution of getting both the TX1 and TX2 to use the same R28.1 L4T version (the driver packages differ, but the kernel and rootfs are now the same). Because of this change device tree ended up moving to within the boot support partitions.
To see what your system actually used instead of a file you think was used always look at “/proc” (this would have been true prior to the device tree changes of R28.1, but back then we knew the extlinux.conf named dtb file was used so it wasn’t really necessary). You can reverse compile the exact idea of what the kernel thinks the device tree is via: