I have a process where I install a custom kernel/DTB on an existing TX1 system that has been initially setup with the Jetpack install… Here’s my process-
I copy the kernel and DTB binaries over to the system, then I write the new kernel image to /boot and I install the DTB into /dev/mmcblk0p13 using ‘dd’, and then reboot.
This process works fine on R28.1, but it doesn’t work correctly on R28.2. First of all, I noticed that the DTB partition has changed to mmcblk0p14 on R28.2, so I tried writing it there instead. It still doesn’t work, and it appears that Tegraboot is complaining that the DTB is corrupted.
[0000.668] Bootloader DTB Load Address: 0x83000000
[0000.673] Loading NvTbootKernelDTB
[0000.767] Verifying NvTbootKernelDTB in OdmNonSecureSBK mode
[0000.807] NvTbootKernelDTB is corrupted!
[0000.811] Error in NvTbootLoadBinary: 0x14 !
[0000.815] Error is 14
I dumped a copy of the DTB partition from a working system for inspection with a hex editor, and I noticed 1024 bytes at the beginning before the actual DTB data starts. I don’t see this on the DTB partition from R28.1.
Is there some sort of header that needs to be added to the DTB binary in R28.2? I seem to be missing something here.
hello dmillard,
you’re right, there are changes for the DTB format.
you could also check the flashing process message to find out the DTB file will be encrypted.
hence, the steps to update the DTB partition for R28.2 has changed,
please refer to this topic to update the DTB partition: [url]https://devtalk.nvidia.com/default/topic/1031374/jetson-tx1/how-to-update-only-dtb-in-r28-2/post/5247510/#5247510[/url]
thanks
OK, so I need to update my kernel and DTB from a live running TX1, i.e. self-update. I don’t have a PC connected to the TX1, so I can’t run the flash script. If the DTB is encrypted, how can I create an encrypted version to be installed?
I haven’t tried, but I saw in another post near this one that the “–no-flash” option might produce signed files (I’ve not used this…I will experiment with it later). Perhaps one of those signed files could be created based on your DTB file and then that could be installed with dd (just don’t test it on something you can’t flash if it fails…or extract the existing partition with dd, slice off those leading bytes, and use this with --no-flash and see if it produces the same leading bytes).
@linuxdev-
Thanks for the suggestion. I tried it out, and it turns out that when the --no-flash option is used, the script bails out before creating the signed version of the device tree. I’m digging into the python code from nVidia to see if there’s a convenient way to sign my own images somehow.
It would seem that in Jetpack 3.2 the device tree is now signed, with the option to encrypt it. Even if you don’t encrypt it, you still need to generate the signature header with a “dummy key” of some sort.
If there isn’t a check of the signature, then perhaps just a dd copy of an existing signature prefixing the binary device tree would get by (this would occupy the right number of bytes using whatever bytes are allowed…a temporary place holder prior to actually finding out how to sign).
Yeah, I had the same thought. So I took the header from the nVidia signed DTB and tacked it onto the beginning of my own DTB, and the bootloader complained that the DTB was corrupted. I’m guessing there’s some sort of hash or checksum that makes the header unique for each dataset.
I’ve discovered that the tegraflash.py script creates a temporary directory, and stores the signed DTB there during the install process and at the end of the process the temp directory is deleted. If you call tegraflash.py with the --keep option, then it doesn’t delete the temporary directory, and I can go grab the signed version for my own use. It’s not convenient, but at least it works.