Hello,
I need to remotely (thus without USB and recovery mode) update the fdt on a jetson tx1 based board.
How must I proceed ?
That depends on release. With R28.1 you could use dd to the partition. With newer releases this gets signed first before being put into the partition, so it won’t work without using the flash tool itself (which signs). There has been a question out for some time now as to how to sign the device tree without the flash tool since the flash tool requires the Jetson to be present, but is still waiting for answers.
One workaround is that if you have a second Jetson of the same model, and you use the flash tool, then perhaps you could extract the partition with dd from that and then copy it to the remote system and install with dd…I’m not sure how the encryption step works, so this would be an experiment (I can’t test, I have only one TX1 and don’t know if differences between individual TX1s might matter, e.g., some serial number).
I believe it is also possible to save the intermediate generated encrypted dtb during the dtb flash and have it not be erased when done.
To start with be sure to see this note on a flash.sh patch for R28.2 (perhaps also R28.2.1?) to avoid flashing the rootfs when trying to flash only the dtb:
https://devtalk.nvidia.com/default/topic/1036286/jetson-tx1/flashing-just-dtb-on-28-2-and-tx1/post/5264465/#5264465
A URL on the topic (TX1 and TX2 have different trees, but share the same flash tools):
https://devtalk.nvidia.com/default/topic/1035622/jetson-tx2/in-system-update-of-dtb-in-r28-2/post/5262418/#5262418
Example flash under R28.2 with patch:
sudo ./flash.sh -r -k DTB -d <path/to/device tree> mmcblk0p1 jetson-tx1
Alternately, after replacing the dtb which a regular flash would have used:
sudo ./flash.sh -r -k kernel-dtb jetson-tx1 mmcblk0p1
Sorry, I don’t remember what was needed to keep the intermediate signed/encrypted copy of the dtb from the flash tool. Anyone remember how to keep the intermediate signed copy of a dtb which the flash.sh tool generates? Anyone know if there is any limitation of using the signed copy of one Jetson with another (assuming the same host flashed both)?
Hi linuxdev,
thank you for your detailed answer. Actually I am far from my devkit at the moment, and hoped to get an answer from nvidia people.
Actually I already separate compilation and prepation from USB flashing.
On a central server I do
DTB=/home2/phdm/g5-tmp/binaries/kernel/./arch/arm64/boot/dts/tegra210-jetson-tx1-p2597-2180-01-devkit-with-2179-0.dtb
sudo ./flash.sh --no-flash -k DTB -d ${DTB} -x 0x21 jetson-tx1 mmcblk0p1
and on another computer, where the same partitions are mounted using NFS, and where the devkit is connected using USB and is in recovery mode, I do then, from the ‘bootloader’ directory beneath
sudo ./tegraflash.py --bl cboot.bin --bldtb tegra210-jetson-tx1-p2597-2180-a01-devkit-with-2179-0.dtb --chip 0x21 --applet nvtboot_recovery.bin --cfg flash.xml --bct P2180_A00_LP4_DSC_204Mhz.cfg --bct P2180_A00_LP4_DSC_204Mhz.cfg --cfg flash.xml --cmd "sign; write DTB ./signed/tegra210-jetson-tx1-p2597-2180-a01-devkit-with-2179-0.dtb.encrypt; reboot"
Is signed/tegra210-jetson-tx1-p2597-2180-a01-devkit-with-2179-0.dtb.encrypt the file which I could use to overwrite the DTB partition ?
I can’t answer…within “tegra210-jetson-tx1-p2597-2180-a01-devkit-with-2179-0.dtb.encrypt” it sounds correct to use prefix “tegra210-jetson-tx1-p2597-2180-a01-devkit…”, and you do want the suffix “…dtb.encrypt”. I do not know about the in-between content “-with-2179-0”. It might be correct. Basically, if this is signed from what was originally “tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb” then it is probably correct. Do you have a log to say what created “tegra210-jetson-tx1-p2597-2180-a01-devkit-with-2179-0.dtb.encrypt”?
My logs show on R28.2 that the destination is to both the RP1 and DTB partitions. I suspect the command you gave goes to both partitions, but I don’t know, I have not tried to do a separate sign/flash.
Hi linuxdev,
here you are (I actually patched flash.sh to stop at the actual flashing statement and print it)
##############################################################################
# L4T BSP Information:
# R28 (release), REVISION: 2.0, GCID: 10567845, BOARD: t210ref, EABI: aarch64,
# DATE: Fri Mar 2 04:58:16 UTC 2018
###############################################################################
copying bctfile(/home2/g5/icar-cam5/28.2/Linux_for_Tegra/bootloader/t210ref/BCT/P2180_A00_LP4_DSC_204Mhz.cfg)... done.
copying bootloader(/home2/g5/icar-cam5/28.2/Linux_for_Tegra/bootloader/t210ref/cboot.bin)... done.
populating kernel to rootfs... done.
populating initrd to rootfs... done.
populating extlinux.conf.emmc to rootfs... done.
populating /home2/phdm/g5-tmp/binaries/kernel/arch/arm64/boot/dts/tegra210-jetson-tx1-p2597-2180-a01-devkit-with-2179-0.dtb to rootfs... done.
done.
Making Boot image... done.
copying bcffile(/home2/g5/icar-cam5/28.2/Linux_for_Tegra/bootloader/t210ref/cfg/board_config_p2597-devkit.xml)... done.
Existing sosfile(/home2/g5/icar-cam5/28.2/Linux_for_Tegra/bootloader/nvtboot_recovery.bin) reused.
copying tegraboot(/home2/g5/icar-cam5/28.2/Linux_for_Tegra/bootloader/t210ref/nvtboot.bin)... done.
Existing bpffile(/home2/g5/icar-cam5/28.2/Linux_for_Tegra/bootloader/bpmp.bin) reused.
copying wb0boot(/home2/g5/icar-cam5/28.2/Linux_for_Tegra/bootloader/t210ref/warmboot.bin)... done.
Existing tosfile(/home2/g5/icar-cam5/28.2/Linux_for_Tegra/bootloader/tos.img) reused.
Existing eksfile(/home2/g5/icar-cam5/28.2/Linux_for_Tegra/bootloader/eks.img) reused.
copying dtbfile(/home2/phdm/g5-tmp/binaries/kernel/arch/arm64/boot/dts/tegra210-jetson-tx1-p2597-2180-a01-devkit-with-2179-0.dtb)... done.
Existing tbcfile(/home2/g5/icar-cam5/28.2/Linux_for_Tegra/bootloader/nvtboot_cpu.bin) reused.
copying tbcdtbfile(/home2/g5/icar-cam5/28.2/Linux_for_Tegra/kernel/dtb/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb)... done.
copying cfgfile(/home2/g5/icar-cam5/28.2/Linux_for_Tegra/bootloader/t210ref/cfg/gnu_linux_tegraboot_emmc_full.xml) to flash.xml... done.
creating gpt(ppt.img)...
*** GPT Parameters ***
device size -------------- 31276924928
bootpart size ------------ 8388608
userpart size ------------ 31268536320
Erase Block Size --------- 2097152
sector size -------------- 4096
Partition Config file ---- flash.xml
Visible partition flag --- GP1
Primary GPT output ------- PPT->ppt.img
Secondary GPT output ----- GPT->gpt.img
Target device name ------- none
*** PARTITION LAYOUT(24 partitions) ***
[ BCT] BH 0 8191 4.0MiB
[ NVC] BH 8192 16383 4.0MiB nvtboot.bin
[ PPT] UH 0 4095 2.0MiB
[ GP1] UH 4096 8191 2.0MiB
[ APP] UH 8192 29368319 14336.0MiB system.img
[ TBC] UV 29368320 29372415 2.0MiB nvtboot_cpu.bin
[ EBT] UV 29372416 29380607 4.0MiB cboot.bin
[ BPF] UV 29380608 29384703 2.0MiB bpmp.bin
[ WB0] UV 29384704 29396991 6.0MiB warmboot.bin
[ RP1] UV 29396992 29405183 4.0MiB tegra210-jetson-tx1-p2597-2180-a01-devkit-with-2179-0.dtb
[ TOS] UV 29405184 29417471 6.0MiB tos.img
[ EKS] UV 29417472 29421567 2.0MiB eks.img
[ FX] UV 29421568 29425663 2.0MiB
[ BMP] UV 29425664 29687807 128.0MiB bmp.blob
[ SOS] UV 29687808 29728767 20.0MiB
[ EXI] UV 29728768 29859839 64.0MiB
[ LNX] UV 29859840 29990911 64.0MiB boot.img
[ DTB] UV 29990912 29999103 4.0MiB tegra210-jetson-tx1-p2597-2180-a01-devkit-with-2179-0.dtb
[ NXT] UV 29999104 30003199 2.0MiB
[ MXB] UV 30003200 30015487 6.0MiB
[ MXP] UV 30015488 30027775 6.0MiB
[ USP] UV 30027776 30031871 2.0MiB
[ UDA] UV 30031872 61067263 15154.0MiB
[ GPT] UH 61067264 61071359 2.0MiB
copying flasher(/home2/g5/icar-cam5/28.2/Linux_for_Tegra/bootloader/t210ref/cboot.bin)... done.
Existing flashapp(/home2/g5/icar-cam5/28.2/Linux_for_Tegra/bootloader/tegraflash.py) reused.
*** Updating [DTB] with tegra210-jetson-tx1-p2597-2180-a01-devkit-with-2179-0.dtb ***
./tegraflash.py --bl cboot.bin --bldtb tegra210-jetson-tx1-p2597-2180-a01-devkit-with-2179-0.dtb --chip 0x21 --applet nvtboot_recovery.bin --cfg flash.xml --bct P2180_A00_LP4_DSC_204Mhz.cfg --bct P2180_A00_LP4_DSC_204Mhz.cfg --cfg flash.xml --cmd "sign; write DTB ./signed/tegra210-jetson-tx1-p2597-2180-a01-devkit-with-2179-0.dtb.encrypt; reboot"
Now run in bootloader:
/home2/g5/icar-cam5/28.2/Linux_for_Tegra/bootloader
sudo ./tegraflash.py --bl cboot.bin --bldtb tegra210-jetson-tx1-p2597-2180-a01-devkit-with-2179-0.dtb --chip 0x21 --applet nvtboot_recovery.bin --cfg flash.xml --bct P2180_A00_LP4_DSC_204Mhz.cfg --bct P2180_A00_LP4_DSC_204Mhz.cfg --cfg flash.xml --cmd "sign; write DTB ./signed/tegra210-jetson-tx1-p2597-2180-a01-devkit-with-2179-0.dtb.encrypt; reboot"
Right now my TX1 has R28.2 on it, so I don’t have a reference log from a flash to compare. It seems what you have is correct, but since “-with-2179-0” is new I can’t say for sure. I’ve unpacked R28.2.1 and looked for references to where this might be at, but haven’t can’t confirm one way or another.
Can someone with R28.2.1 on a TX1 confirm if “tegra210-jetson-tx1-p2597-2180-a01-devkit-with-2179-0.dtb” is what shows up in a normal flash? If so, then it looks like what you have is correct.
Hi linuxdev,
Sorry. I forgot to mention that 2179-0 is the name of a custom daughter board, and so the top-level dts file is called “tegra210-jetson-tx1-p2597-2180-a01-devkit-with-2179-0.dts”
On my evk, /dev/mmcblk0p6 (RP1) and /dev/mmcblk0p14 (DTB) are different, but at the moment I cannot say if one of them is a exact copy of signed/tegra210-jetson-tx1-p2597-2180-a01-devkit-with-2179-0.dtb.encrypt
I don’t know the details of how the signing is verified, so I can’t say whether the alternate carrier would have any effect or not. The concepts should stay the same based on release, but have you tried first to see if manually flashing over micro-USB with that dtb works? I’m guessing you have it running already and know it works, but I don’t know.
If manually flashing over micro-USB works, then have you tried saving from that particular dtb flash and manually attempting to dd it in place on a different local board first (I don’t know if something like a serial number would be part of the signing, this would be a test)?
Be sure to verify partition sizes. After you flash over micro-USB you might try to use dd to copy this out (but only to the exact byte size of the original dtb with its signing), and then checking if the extracted matches the signed from the original via “sha1sum” of each file.
FYI, I consider NFS to be unreliable and a bad choice for such a thing, but consider that if you find a correct way to dd, then you could use scp to copy the file over first, and then dd it via ssh. If you do choose to stick with NFS I’d consider first copying the signed data to a tmp location and then using dd from there (thus NFS wouldn’t get in the way).
Perhaps someone from NVIDIA can confirm if a signed version saved from the host side will work on a different Jetson. I am going to guess that signing is the first step in making a secure boot system, but that the Jetson itself won’t care who signs it (nor with which key) until secure boot is enabled.