In-system update of DTB in R28.2

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.

I agree it makes updating dtb more difficult for each L4T update.

If you apt-get install gparted and run"sudo gparted", you should see several dtb partitions for R28.2, e.g.

/dev/mmcblk0p6 bootloader-dtb
/dev/mmcblk0p13 bpmp-fw-dtb
/dev/mmcblk0p26 kernel-dtb

Partition /dev/mmcblk0p26 is for kernel dtb, which is encrypted for R28.2.

It’s possible to encrypt kernel dtb using modified tegraflash.py (e.g., adding -keep) from Jetpack and then use “dd” to replace kernel dtb in-system.

By default, “tegraflash.py” deletes encrypted dtb files after flashing, -keep should keep the encrypted dtb files.

“teflgraash.py” and associated files should run on TX2/TX2i, but I have not tried it.

The key is to find the source code to encrypt dtb files.

It may be possible to change bootloader of R28.2 to use plain dtb files.

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.

hi all,

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,

JetPack/JetPack-3.2/_installer/logs/64_TX2/flash_os_tx2.log

-OR-

you could perform DTB partial update

$ sudo ./flash.sh -r -k kernel-dtb jetson-tx2 mmcblk0p1

checking the flashing log again to see the signing commands,
it should be something like this,

./tegraflash.py --bl nvtboot_recovery_cpu.bin  --chip 0x18 --applet mb1_recovery_prod.bin  --cfg flash.xml  --sdram_    config P3310_A00_8GB_Samsung_8GB_lpddr4_204Mhz_A02_l4t.cfg --sdram_config P3310_A00_8GB_Samsung_8GB_lpddr4_204Mhz_A0    2_l4t.cfg --misc_config tegra186-mb1-bct-misc-si-l4t.cfg --pinmux_config tegra186-mb1-bct-pinmux-quill-p3310-1000-c0    3.cfg --pmic_config tegra186-mb1-bct-pmic-quill-p3310-1000-c03.cfg --pmc_config tegra186-mb1-bct-pad-quill-p3310-100    0-c03.cfg --prod_config tegra186-mb1-bct-prod-quill-p3310-1000-c03.cfg --scr_config minimal_scr.cfg --scr_cold_boot_    config mobile_scr.cfg --br_cmd_config tegra186-mb1-bct-bootrom-quill-p3310-1000-c03.cfg --dev_params emmc.cfg  --cfg      flash.xml --bins "mb2_bootloader nvtboot_recovery.bin; mts_preboot preboot_d15_prod_cr.bin; mts_bootpack mce_mts_d    15_prod_cr.bin; bpmp_fw bpmp.bin; bpmp_fw_dtb tegra186-a02-bpmp-quill-p3310-1000-c01-00-te770d-ucm2.dtb; tlk tos.img    ; eks eks.img; bootloader_dtb tegra186-quill-p3310-1000-c03-00-base.dtb"  --cmd "sign;

here’s brief steps for your to update the DTB files more easily.

  1. build the DTB
  2. replace new DTB files with $OUT/bootloader/tegra186.dtb
  3. generate signed files with tegraflash.py
  4. copy the signed DTB to target device.
  5. replace the kernel-dtb partition (/dev/mmcblk0p26) with dd command.

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)?

hello linuxdev,

we’re under investigation internally for simplify commands to generate encrypt files.
will get back to you while we come out conclusions.
thanks

Hi Jerry,
It’d help developers if the commands to generate encrypted DTB files can run on TX2s.
Thanks

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?

hello 337247537,

I’m able to generate bpmp-fw-dtb signed files with the commands in comment #7.
could you please double check, thanks

ok,thanks

This is an old thread, but I’ll add some info:

On Jetpack 4.5 I could extract the DTB from the partition like this:
gdisk -l /dev/mmcblk0 | grep -i 'kernel-dtb'

…gives partition number 30. After some investigation, I find that the offset needed is 400 bytes:

dd if=/dev/mmcblk0p30 of=test.dtb skip=400 iflag=skip_bytes

I also discovered another helpful tool - fdtdump has a ‘scan’ flag, so it can look for the DTB header:

fdtdump -s /dev/mmcblk0p30