Request for a tool to update device tree locally.

Hello,

There have been many discussions on this in the forms.

https://devtalk.nvidia.com/default/topic/973177/?comment=5004118

https://devtalk.nvidia.com/default/topic/1020708/jetson-tx2/method-to-modify-use-different-device-tree-in-r28-1/post/5195927/#5195927

https://devtalk.nvidia.com/default/topic/1021660/jetson-tx1/is-there-any-other-method-in-l4t-r28-1-to-update-dtb-file-for-tx1-besides-flashing-the-dtb-partitio-/post/5200056/#5200056

It seems that since the last few L4T releases, the device-tree is being used by uboot and other parts of the boot process. And hence instead of using the extlinux.conf to define which device-tree to use, the newer releases seem to be using device-tree that’s flashed into a special partition (mmcblk0p13) which is then loaded at boot and used as device-tree firmware.

And since L4T 28.x this is now true for both TX1 and TX2.

This is all fine and dandy, except that there is no tool to update the device-tree from the TX1/TX2 itself. One needs

  1. A separate x86 machine
  2. Ubuntu 16.06 installed on it
  3. Jetpack release

Before the appropriate “sudo ./flash -k -r DTB” command can be invoked.

This is backwards!! If nVidia is trying to push for industrial usage (TX2i) of the TX1/2 modules, there needs to be a mechanism for them to self-provision without a need for an external x86 machine.

We’re in the era of ARM machines. nVidia ship full desktops on this TX1/2 OS builds and yet why is there is a dependency on an EXTERNAL X86 machine to update the device-tree.

And it’s not that updating the device-tree is something rare and not needed by many people. Just looking through the forum there are so many posts about using SPI which requires a device-tree change. https://elinux.org/Jetson/TX1_SPI

So this is a request (I’m sure many others will agree with me) to nVidia to provide a tool to update device-trees locally from the TX1/2. This shouldn’t be that hard if the device-tree is located on a separate partition, the tool would just need to update the partition after verifying if the device-tree is valid.

hello notthetup,

since R28.2, device tree partition need an encrypted DTB,
there’s encrypt process in the bootloader, cboot would add some key entries before passing to u-boot.

you’re able to perform DTB partial update with the following command,

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

or,
there’s an alternative way to build DTB and create signed files with tegraflash.py.

please refer to Topic 1035622 for more details, thanks

Thanks @JerryChang.

I will investigate the tegraflash.py command. I hope it doesn’t require a binary to actually do the signing. I really hope I can run tegraflash.py on a TX1/2.

Hi @JerryChang,

As I suspected tegraflash.py seems to call tegrarcm internally. And tegrarcm is a binary compiled for x86, not for ARM. So you can’t run tegraflash.py on a TX1.

file tegrarcm
tegrarcm: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.8, not stripped

So my request stands. It would be really handy to a mechanism for updating DTB without needing an external computer.

hello notthetup,

may I have your confirmation about your use-case.

would you like to re-compile device tree on Jetson platform?
you may take a try with below:
how about using commands to convert DTB file into a txt file for editing, and convert it to another new DTB file.
for example,

to disassembler the dtb file into txt file for edit
$ dtc -I dtb -O dts -o temp.dts tegra.dtb

to convert the DTS into a DTB
$ dtc -I dts -O dtb -o output.dtb temp.dts

after that, overwrite the device tree with the “dd” commands, performing warm-reboot to make the dtb modification takes effect.
thanks

Hello,

Yes. That is my usecase.

I was under the impression that this will not work because as you said,

“since R28.2, device tree partition need an encrypted DTB”.

But if this can work, I’ll be very happy to do this.

hello notthetup,

Jetson-TX2 indeed need an encrypted DTB, it needs a host machine to generate signed files with tegraflash.py
we did not verified those steps in comment #5, looking forward of your testing result.
thanks

Thanks!

Do you know which partition the DTB goes in for TX1 on R28.2?

gdisk shows me the following but I can’t seem to decode the dtb from /dev/mmcblk0p14

Number  Start (sector)    End (sector)  Size       Code  Name
   1              34        29360161   14.0 GiB    0700  APP
   2        29360162        29364257   2.0 MiB     0700  TBC
   3        29364258        29372449   4.0 MiB     0700  EBT
   4        29372450        29376545   2.0 MiB     0700  BPF
   5        29376546        29388833   6.0 MiB     0700  WB0
   6        29388834        29397025   4.0 MiB     0700  RP1
   7        29397026        29409313   6.0 MiB     0700  TOS
   8        29409314        29413409   2.0 MiB     0700  EKS
   9        29413410        29417505   2.0 MiB     0700  FX
  10        29417506        29679649   128.0 MiB   0700  BMP
  11        29679650        29720609   20.0 MiB    0700  SOS
  12        29720610        29851681   64.0 MiB    0700  EXI
  13        29851682        29982753   64.0 MiB    0700  LNX
  14        29982754        29990945   4.0 MiB     0700  DTB
  15        29990946        29995041   2.0 MiB     0700  NXT
  16        29995042        30007329   6.0 MiB     0700  MXB
  17        30007330        30019617   6.0 MiB     0700  MXP
  18        30019618        30023713   2.0 MiB     0700  USP
  19        30023714        30777310   368.0 MiB   0700  UDA

hello notthetup,

below commands works for me,

ls -al /dev/disk/by-partlabel

OK. Tested this out… It doesn’t work. I am testing on a Jetson-TX1 on R28.2

Extracted the current DTB

dtc -I fs -O dts -o extracted.dts /proc/device-tree

Recompiled without any changes.

dtc -I dts -O dtb -o output.dtb extracted.dts

Flashed it back using dd

sudo dd if=output.dtb of=/dev/mmcblk0p14

And the board refuses to boot with this error…

[0000.379] Loading NvTbootBootloaderDTB
[0000.473] Verifying NvTbootBootloaderDTB in OdmNonSecureSBK mode
[0000.604] Bootloader DTB Load Address: 0x83000000
[0000.608] Loading NvTbootKernelDTB
[0000.702] NvTbootKernelDTB is not valid
[0000.706] Error in NvTbootLoadBinary: 0x14 !
[0000.710] Error is 14

For reference, the partition table is this.

ubuntu@tegra-ubuntu:~$ ls -al /dev/disk/by-partlabel
total 0
drwxr-xr-x 2 root root 420 Oct 22 07:54 .
drwxr-xr-x 7 root root 140 Oct 22 07:54 ..
lrwxrwxrwx 1 root root  15 Oct 22 07:54 APP -> ../../mmcblk0p1
lrwxrwxrwx 1 root root  16 Oct 22 07:54 BMP -> ../../mmcblk0p10
lrwxrwxrwx 1 root root  15 Oct 22 07:54 BPF -> ../../mmcblk0p4
lrwxrwxrwx 1 root root  16 Oct 22 07:54 DTB -> ../../mmcblk0p14
lrwxrwxrwx 1 root root  15 Oct 22 07:54 EBT -> ../../mmcblk0p3
lrwxrwxrwx 1 root root  15 Oct 22 07:54 EKS -> ../../mmcblk0p8
lrwxrwxrwx 1 root root  16 Oct 22 07:54 EXI -> ../../mmcblk0p12
lrwxrwxrwx 1 root root  15 Oct 22 07:54 FX -> ../../mmcblk0p9
lrwxrwxrwx 1 root root  16 Oct 22 07:54 LNX -> ../../mmcblk0p13
lrwxrwxrwx 1 root root  16 Oct 22 07:54 MXB -> ../../mmcblk0p16
lrwxrwxrwx 1 root root  16 Oct 22 07:54 MXP -> ../../mmcblk0p17
lrwxrwxrwx 1 root root  16 Oct 22 07:54 NXT -> ../../mmcblk0p15
lrwxrwxrwx 1 root root  15 Oct 22 07:54 RP1 -> ../../mmcblk0p6
lrwxrwxrwx 1 root root  16 Oct 22 07:54 SOS -> ../../mmcblk0p11
lrwxrwxrwx 1 root root  15 Oct 22 07:54 TBC -> ../../mmcblk0p2
lrwxrwxrwx 1 root root  15 Oct 22 07:54 TOS -> ../../mmcblk0p7
lrwxrwxrwx 1 root root  16 Oct 22 07:54 UDA -> ../../mmcblk0p19
lrwxrwxrwx 1 root root  16 Oct 22 07:54 USP -> ../../mmcblk0p18
lrwxrwxrwx 1 root root  15 Oct 22 07:54 WB0 -> ../../mmcblk0p5

hello notthetup,

thanks for the update,
it turns out you must need a host machine to generate signed files with tegraflash.py
thanks

Ah well. That’s a bummer.

Hopefully, Nvidia will take this as a feedback. It would very very useful to be able to do this without a host machine. Especially when we have to setup a large number of TX1s, this doesn’t scale!

Are there any new developments on this topic - specifically for compiling and encrypting a modified DTS for the Jetson Nano?

hello filippo.alimonda,

the status reaming the same as comment #11.
you must need a host machine to running with tegraflash.py for generating a signed file.

may I know what’s your use-case,
you should initial another new issue ticket if you would like further supports.
thanks

I am trying to free-up the serial console UART so I can use it as a GP UART. Just out of curiosity, I wanted to check if the dtb encryption tool had been ported to run on Nano/ARM, but no problem - I will go about it using a host machine.

Thanks

I have figured out the format of the signature header and created a python script to sign DTB files and possibly others. I have uploaded the code at https://github.com/kmartin36/nv-tegra-sign/. It currently generates identical signed files to those made by flash.sh but without needing any x86 binaries. I cannot guarantee that it will not be broken by a future update, but it works with jetpack 4.2 and the TX2. I have not tried the Nano or TX1.

Thanks @kevinmbecause. This is cool and super useful. Would you be able to document how to use the script? Maybe a simple example? Thanks!

@kevinmbecause

Wonderful! I wonder why NVIDIA could not just provide a tool as simple as this?!?!

It did not work for me, any pointers to debugging it, it is R32.3.1 TX2

Hello, please, try with my pull_request:
https://github.com/kmartin36/nv-tegra-sign/pull/1