Hello, while in R28.1 we were able to dd the DTB file into the mmcblk0p15 partition, the partition layout in R28.2 is different, and none of the partitions seem to contain the device tree file. Instead of the raw binary dtb, every partition now has some extra headers with same “GSHV” magic, that is not even recognized by the file command.
Why does NVidia make life of developers always harder? Pre-28.1 had a nice file based DTB, making it easy to boot from SD, then in 28.1 we got it hidden on special partition, making SD boot impossible, and in 28.2 it is totally forbidden to change the DTB?
Is somewhere a roadmap/plan of what the planned changes are and will be - together with some reasoning, because so far we only see a bunch of random changes by each release, making the previous development efforts unusable. Product development and client support requires a way to upgrade - which is impossible with the never-ending changes how the platform even operates.
Who does lead the Tegra platform software development? Give me the name.
And JETPACK does not allow flashing 28.1 anymore? You have just rendered all our work unusable.
Unfortunately, I found some binaries used by “tegraflash.py”, e.g., “tegrasign_v2” can’t run on TX2.
I hope Nvidia can release source code of those binaries.
The binaries which are for flash were all intended to run on an x86_64 host. The python code is just a wrapper to other code. A Jetson could not self-flash anyway since it does not have a BIOS (and U-Boot was not designed for such a general case). Imagine downloading the operating system and building a file system replacement…on the file system which would then require holding itself plus the future replacement.
This of course doesn’t mean it wouldn’t be useful to be able to boot to external media (e.g., an SD card or USB flash drive) to do this. There may be ways to support specific cases even if general flash use with JetPack can’t work directly from the Jetson.
In part I believe the dtb signing is probably from ordinary open source tools, but I’ve not seen details such as specific applications/protocols/examples. It looks feasible.
The intention was not to flash DTB using “tegraflash.py” but to find the way to sign/unsign DTB so “dd” could be used to flash “kernel-dtd” partition in system without using micro USB cable and a laptop.
This would be something very useful to see an example of. Perhaps NVIDIA could give an example of using the open source signing tools to do this? All that I’ve found says these are the tools used…I just haven’t found a specific tool or arguments to say what key is used, so on.
The major question is what application is called by tegrasign_v2, and what the content of pub_key.key is. After that it might be possible to do this manually.
there’s encrypt process in the bootloader, cboot would add some key entries before passing to u-boot.
however, please check the JetPack logs for flashing message, you should be able to check the commands to generate the encrypt files.
for example,
I am curious…the given tegraflash.py command seems to do many things beyond just signing…is there a way to break down just the sign step using individual signing tools (e.g., pgp tools or OpenSSH tools)?
From what I’ve seen, the dtb is not actually encrypted… there is just a 1k header that gets appended to the dtb before it is flashed to the DTB/RP1 partitions. I’m guessing that header is some sort of signature to validate the dtb (and is created from tegraflash.py).
I came to this conclusion b/c when I dd’d from offset 1k in those partitions, I can decompile using dtc just like the 28.1 dtb without doing any sort of decryption.
The way I am currently trying to update the DTB is in a safer manner, where I simply specify the DTB in the application partition in it’s /boot/extlinux/extlinux.conf. That way, the system should boot using the specified dtb (which can be included in the updated partition) instead of the one written to the actual partition so that we don’t have to do a risky dd operation that could be killed in the middle of an update, bricking the vehicle.
Strangely, before I realized that the DTB gets modified before getting flashed to the DTB partitions, we were still able to specify a DTB in extlinux.conf, except we would get very strange behavior and loss of wifi (cpu utilization would be super high regardless of actual processes running). I was surprised the system would boot up at all if the device tree was not in the right format…
Anyone have any insight here? Also, using the FDT specifier in extlinux.conf seems like the best way to update the device tree…is there a better/promoted way that is still safe to do during an OTA?
What is the recommended power loss safe way to update the DTB? dd-ing to a non-redundant partition is not safe for remote update. Is my method above the recommended way? Am I only having issues b/c I was not using the signed DTB in the updated user partition instead of the unsigned DTB?
The extlinux.conf DTB entry cannot be used in R28+. Some of the preboot environment requires use of the dtb in the partitions instead of via that file, and makes edits which are merged into and inherited to different boot software along the way. You might get lucky and if you use a small subset of the dtb perhaps it’ll do what you want…but some of what you see in the dtb needs to run before the Linux kernel (or even U-Boot) ever sees your dtb (and this content is edited and passed on to other stages of boot).
Hi JerryChang,
Could you please tell how to flash bpmp-fw-dtb only except flash all of roorfs?
I use cammond like this “./flash.sh -r -k bpmp-fw-dtb jetson-tx2 mmcblk0p1”.But error message like this " File to be written cannot be of zero size
[ 24.9074 ]
Error: Return value 10
Command tegradevflash_v2 --write bpmp-fw-dtb /home/ext/Linux_for_Tegra/bootloader/t186ref/signed/tegra186-a02-bpmp-quill-p3310-1000-c04-00-te770d-ucm2_sigheader.dtb.encrypt"
I find under /bootloader/t186ref/signed/floder there no such file named tegra186-a02-bpmp-quill-p3310-1000-c04-00-te770d-ucm2_sigheader.dtb.encrypt. So I need to generate this file first. How to do this?