Unable to flash new kernel-dtb, Ubuntu 16.04


I read a lot of topics discussing about problems flashing the TX2. Mine was flashed (not be me) successfully, but to install a camera driver, I need to reflash the kernel dtb after replacing the boot Image.

I plugged my tx2 on my host pc running Ubuntu 16.04 (no VM) and put it into recovery mode. Cable is USB micro B (took it from a cellphone charger). Port on host is USB 3.0 (no USB 2 at all).

So my TX2 is visible through lsusb with the right product id

Bus 001 Device 028: ID 0955:7c18 NVidia Corp.

Here is the output of the command I ran when I try running the command for the second (and next) time : sudo ./flash.sh -r -k kernel-dtb jetson-tx2 mmcblk0p1

./tegraflash.py --chip 0x18 --applet "/home/user/Téléchargements/Linux_for_Tegra/bootloader/mb1_recovery_prod.bin" --cmd "dump eeprom boardinfo cvm.bin" --skipuid 
Welcome to Tegra Flash
version 1.0.0
Type ? or help for help and q or quit to exit
Use ! to execute system commands
[   0.0013 ] Generating RCM messages
[   0.0020 ] tegrarcm_v2 --listrcm rcm_list.xml --chip 0x18 --download rcm /home/user/Téléchargements/Linux_for_Tegra/bootloader/mb1_recovery_prod.bin 0 0
[   0.0025 ] RCM 0 is saved as rcm_0.rcm
[   0.0029 ] RCM 1 is saved as rcm_1.rcm
[   0.0029 ] List of rcm files are saved in rcm_list.xml
[   0.0029 ] 
[   0.0029 ] Signing RCM messages
[   0.0035 ] tegrasign_v2 --key None --list rcm_list.xml --pubkeyhash pub_key.key
[   0.0040 ] Assuming zero filled SBK key
[   0.0068 ] 
[   0.0068 ] Copying signature to RCM mesages
[   0.0073 ] tegrarcm_v2 --chip 0x18 --updatesig rcm_list_signed.xml
[   0.0080 ] 
[   0.0080 ] Boot Rom communication
[   0.0086 ] tegrarcm_v2 --chip 0x18 --rcm rcm_list_signed.xml --skipuid
[   0.0095 ] Boot Rom communication failed
[   3.1151 ] 
Error: Return value 3
Command tegrarcm_v2 --chip 0x18 --rcm rcm_list_signed.xml --skipuid
Reading board information failed.

All I did was following the camera’s constructor’s instructions so I did not come up with this command by myself.

More info: the “Linux_for_Tegra” folder comes from this archive “Tegra186_Linux_R28.1.0_aarch64.tbz2” and I replaced the dtb file “tegra186-quill-p3310-1000-c03-00-base.dtb” by the one provided by the camera constructor.

Any help would be much appreciated.

EDIT: The second error message (below) only appears the first time I run the command after putting the tx2 into recovery mode. Every other times after this one get to the first error message. So I need to find out how to solve the second error message.
I will get a USB A male male cable tomorrow, which I will try with the included NVidia cable micro B to USB A female, as a replacement for my cellphone charger cable. I will also try to test on Ubuntu 14 if the administration finds me one.

Thanks for your future help.

./tegraflash.py --chip 0x18 --applet "/home/user/Téléchargements/Linux_for_Tegra/bootloader/mb1_recovery_prod.bin" --cmd "dump eeprom boardinfo cvm.bin" --skipuid 
Welcome to Tegra Flash
version 1.0.0
Type ? or help for help and q or quit to exit
Use ! to execute system commands
[   0.0014 ] Generating RCM messages
[   0.0021 ] tegrarcm_v2 --listrcm rcm_list.xml --chip 0x18 --download rcm /home/user/Téléchargements/Linux_for_Tegra/bootloader/mb1_recovery_prod.bin 0 0
[   0.0027 ] RCM 0 is saved as rcm_0.rcm
[   0.0030 ] RCM 1 is saved as rcm_1.rcm
[   0.0030 ] List of rcm files are saved in rcm_list.xml
[   0.0030 ] 
[   0.0031 ] Signing RCM messages
[   0.0037 ] tegrasign_v2 --key None --list rcm_list.xml --pubkeyhash pub_key.key
[   0.0042 ] Assuming zero filled SBK key
[   0.0070 ] 
[   0.0071 ] Copying signature to RCM mesages
[   0.0076 ] tegrarcm_v2 --chip 0x18 --updatesig rcm_list_signed.xml
[   0.0085 ] 
[   0.0085 ] Boot Rom communication
[   0.0091 ] tegrarcm_v2 --chip 0x18 --rcm rcm_list_signed.xml --skipuid
[   0.0099 ] RCM version 0X180001
[   0.0111 ] Boot Rom communication completed
[   1.0197 ] 
[   1.0219 ] tegrarcm_v2 --isapplet
[   1.0238 ] Applet version 01.00.0000
[   1.0267 ] 
[   1.0287 ] Retrieving EEPROM data
[   1.0289 ] tegrarcm_v2 --oem platformdetails eeprom cvm /home/user/Téléchargements/Linux_for_Tegra/bootloader/cvm.bin
[   1.0307 ] Applet version 01.00.0000
[   1.0677 ] Saved platform info in /home/user/TTraceback (most recent call last):
  File "./tegraflash.py", line 1101, in <module>
  File "./tegraflash.py", line 1008, in tegraflash_run_commands
  File "/usr/lib/python2.7/cmd.py", line 221, in onecmd
    return func(arg)
  File "./tegraflash.py", line 664, in do_dump
    tegraflash_dump(exports, args)
  File "/home/user/Téléchargements/Linux_for_Tegra/bootloader/tegraflash_internal.py", line 884, in tegraflash_dump
    tegraflash_dumpeeprom(args, dump_args[1:])
  File "/home/user/Téléchargements/Linux_for_Tegra/bootloader/tegraflash_internal.py", line 924, in tegraflash_dumpeeprom
  File "/home/user/Téléchargements/Linux_for_Tegra/bootloader/tegraflash_internal.py", line 167, in run_command
  File "/home/user/Téléchargements/Linux_for_Tegra/bootloader/tegraflash_internal.py", line 135, in print_process
    outputchar = output.decode('ascii')
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 0: ordinal not in range(128)
Reading board information failed.

Some micro-B USB cables from chargers have poor quality on data lines (and some even have no data wires at all). The cable which comes with the kit is best, but I would always be suspicious of a cable which goes with charging some other device. You may want to purchase a cable specifically sold as a micro-B USB cable and advertises use with data (perhaps this won’t fix anything, but if it does, it’ll save a lot of grief).

Note that you cannot run two operations on the recovery mode Jetson without restarting in recovery mode between uses. lsusb is not a use, but cloning or flashing are.

I’d suggest only trying after freshly putting the Jetson in recovery mode and using a known data cable type-B micro USB (versus one advertising as a charger cable…cables advertised for data work with charging as well so long as it is type-B).

Thanks for your infos.

I got a better cable and tried on a Debian 9. The error mentioned above is gone but I have another one, which might not be related to hardware.

Here are the new logs :

./tegraflash.py --chip 0x18 --applet "/home/user/Téléchargements/Linux_for_Tegra/bootloader/mb1_recovery_prod.bin" --cmd "dump eeprom boardinfo cvm.bin" --skipuid 
Welcome to Tegra Flash
version 1.0.0
Type ? or help for help and q or quit to exit
Use ! to execute system commands
[   0.0022 ] Generating RCM messages
[   0.0031 ] tegrarcm_v2 --listrcm rcm_list.xml --chip 0x18 --download rcm /home/user/Téléchargements/Linux_for_Tegra/bootloader/mb1_recovery_prod.bin 0 0
[   0.0041 ] RCM 0 is saved as rcm_0.rcm
[   0.0054 ] RCM 1 is saved as rcm_1.rcm
[   0.0054 ] List of rcm files are saved in rcm_list.xml
[   0.0054 ] 
[   0.0055 ] Signing RCM messages
[   0.0075 ] tegrasign_v2 --key None --list rcm_list.xml --pubkeyhash pub_key.key
[   0.0086 ] Assuming zero filled SBK key
[   0.0140 ] 
[   0.0140 ] Copying signature to RCM mesages
[   0.0149 ] tegrarcm_v2 --chip 0x18 --updatesig rcm_list_signed.xml
[   0.0162 ] 
[   0.0163 ] Boot Rom communication
[   0.0173 ] tegrarcm_v2 --chip 0x18 --rcm rcm_list_signed.xml --skipuid
[   0.0184 ] RCM version 0X180001
[   0.0194 ] Boot Rom communication completed
[   1.0258 ] 
[   1.0273 ] tegrarcm_v2 --isapplet
[   1.0285 ] Applet version 01.00.0000
[   1.0471 ] 
[   1.0484 ] Retrieving EEPROM data
[   1.0485 ] tegrarcm_v2 --oem platformdetails eeprom cvm /home/user/Téléchargements/Linux_for_Tegra/bootloader/cvm.bin
[   1.0496 ] Applet version 01.00.0000
[   1.0828 ] Saved platform info in /home/user/Téléchargements/Linux_for_Tegra/bootloader/cvm.bin
[   1.1610 ] 
Board ID(3310) version(B00) 
copying bctfile(/home/user/Téléchargements/Linux_for_Tegra/bootloader/t186ref/BCT/P3310_A00_8GB_Samsung_8GB_lpddr4_204Mhz_A02_l4t.cfg)... done.
copying misc_config(/home/user/Téléchargements/Linux_for_Tegra/bootloader/t186ref/BCT/tegra186-mb1-bct-misc-si-l4t.cfg)... done.
copying pinmux_config(/home/user/Téléchargements/Linux_for_Tegra/bootloader/t186ref/BCT/tegra186-mb1-bct-pinmux-quill-p3310-1000-c03.cfg)... done.
copying pmic_config(/home/user/Téléchargements/Linux_for_Tegra/bootloader/t186ref/BCT/tegra186-mb1-bct-pmic-quill-p3310-1000-c03.cfg)... done.
copying pmc_config(/home/user/Téléchargements/Linux_for_Tegra/bootloader/t186ref/BCT/tegra186-mb1-bct-pad-quill-p3310-1000-c03.cfg)... done.
copying prod_config(/home/user/Téléchargements/Linux_for_Tegra/bootloader/t186ref/BCT/tegra186-mb1-bct-prod-quill-p3310-1000-c03.cfg)... done.
copying scr_config(/home/user/Téléchargements/Linux_for_Tegra/bootloader/t186ref/BCT/minimal_scr.cfg)... done.
copying scr_cold_boot_config(/home/user/Téléchargements/Linux_for_Tegra/bootloader/t186ref/BCT/mobile_scr.cfg)... done.
copying bootrom_config(/home/user/Téléchargements/Linux_for_Tegra/bootloader/t186ref/BCT/tegra186-mb1-bct-bootrom-quill-p3310-1000-c03.cfg)... done.
copying dev_params(/home/user/Téléchargements/Linux_for_Tegra/bootloader/t186ref/BCT/emmc.cfg)... done.
Existing bootloader(/home/user/Téléchargements/Linux_for_Tegra/bootloader/nvtboot_cpu.bin) reused.
	populating kernel to rootfs... done.
	populating initrd to rootfs... done.
	populating extlinux.conf.emmc to rootfs... done.
	populating /home/user/Téléchargements/Linux_for_Tegra/kernel/dtb/tegra186-quill-p3310-1000-c03-00-base.dtb to rootfs... done.
Making Boot image... done.
Existing sosfile(/home/user/Téléchargements/Linux_for_Tegra/bootloader/mb1_recovery_prod.bin) reused.
copying tegraboot(/home/user/Téléchargements/Linux_for_Tegra/bootloader/t186ref/nvtboot.bin)... done.
Existing mb2blfile(/home/user/Téléchargements/Linux_for_Tegra/bootloader/nvtboot_recovery.bin) reused.
Existing mtspreboot(/home/user/Téléchargements/Linux_for_Tegra/bootloader/preboot_d15_prod_cr.bin) reused.
Existing mts(/home/user/Téléchargements/Linux_for_Tegra/bootloader/mce_mts_d15_prod_cr.bin) reused.
Existing mb1file(/home/user/Téléchargements/Linux_for_Tegra/bootloader/mb1_prod.bin) reused.
Existing bpffile(/home/user/Téléchargements/Linux_for_Tegra/bootloader/bpmp.bin) reused.
copying bpfdtbfile(/home/user/Téléchargements/Linux_for_Tegra/bootloader/t186ref/tegra186-a02-bpmp-quill-p3310-1000-c01-00-te770d-ucm2.dtb)... done.
Existing scefile(/home/user/Téléchargements/Linux_for_Tegra/bootloader/camera-rtcpu-sce.bin) reused.
Existing spefile(/home/user/Téléchargements/Linux_for_Tegra/bootloader/spe.bin) reused.
copying wb0boot(/home/user/Téléchargements/Linux_for_Tegra/bootloader/t186ref/warmboot.bin)... done.
Existing tosfile(/home/user/Téléchargements/Linux_for_Tegra/bootloader/tos.img) reused.
Existing eksfile(/home/user/Téléchargements/Linux_for_Tegra/bootloader/eks.img) reused.
copying dtbfile(/home/user/Téléchargements/Linux_for_Tegra/kernel/dtb/tegra186-quill-p3310-1000-c03-00-base.dtb)... done.
Reusing existing system.img... 
file does not exist.

Any hints on this one ?

Ok so i cloned my rootfs via this post https://devtalk.nvidia.com/default/topic/1000105/jetson-tx2/tx2-cloning/.

I checked the raw image and its ok. I used mv to move my cloned img to bootloader/system.img and the flash seems to work. (seems comes from the fact that my cable is still not in optimal conditions, because its old)

Thanks to linuxdev and mods for the help I found all over the forum.

That last log line is:

file does not exist.

What was the exact command line? I’m not sure which file it is suggesting is missing, perhaps system.img (which may not matter if the command was not flashing rootfs…but will matter if it was).

Yes indeed, it suggests system.img is missing, because I didnt clone before. It was the same command line: sudo ./flash.sh -r -k kernel-dtb jetson-tx2 mmcblk0p1

It is possible not to flash rootfs? Cause that would be better for my use case

I think I understand how this works now.

I got the patched flash.sh for R27.1.

I cloned the rootfs of my tx2 successfully (tested it by mounting it) and renamed the raw file as system.img, after modifying a dtb file.

I launched the apply_binaries.sh script as mentioned in another thread.

Now I launch the command below

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

AND it should work. Am I right?

So, now my problem changed since I understand more what I am doing: my cable is brand new, optimized for data transfer but I still cant get the flash.sh script work more than 1 try out of 20 as I am still getting the UnicodeDecodeError ???
I mean, I managed to clone my rootfs twice so its not just in my head.

I changed the cable, I tried another host port, I tried another host, do we need a specific brand of cable? An official NVidia one maybe?

I think what the logic is is that if you say to reuse it won’t regenerate system.img from system.img.raw. Rootfs would still be flashed…unless you explicity name something different to flash, e.g., a dtb or kernel. If it turns out that saying to reuse system.img still tests for this file existing even though it won’t be installing it, then this is probably a bug in flash.sh.

It’s always a good idea to have a clone before doing anything major.

I believe the flash command you gave will work as expected.

Your observation here is quite interesting:


There have been known issues in the past related to other locales or characters not normally found in en_US. Is your host local en_US? What character set are you using if not the default for Ubuntu? Are there any spaces in the path to files? Are there any non-English accent marks in paths to files, e.g., circumflex or 16-bit (UTF-16) characters?

1 Like

My host is in fr_FR with utf-8 character set.

No spaces in paths to files BUT, as you can see in my first post, one of my repositories to Linux_for_Tegra/ is Téléchargements/ so YES I had non-English accent marks. I removed them and the script worked as expected. As a reminder, first post error was :

File "/home/user/Téléchargements/Linux_for_Tegra/bootloader/tegraflash_internal.py", line 135, in print_process
    outputchar = output.decode('ascii')
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 0: ordinal not in range(128)

… so you see the path had accents…

Maybe it could be specified somewhere around the script because there might be someone else in the wild who’s going to have the same issue :)

Now when I flash, the files when I reboot are unchanged. I only have one dtb file to trasnfer so I did

tar xvf Tegra186_Linux_R27.1.0_aarch64.tbz2
cd Linux_for_Tegra/
cp ../patched_flash.sh flash.sh
sudo ./flash.sh -r -k APP -G my_backup.img jetson-tx2 mmcblk0p1
mv my_backup.img.raw bootloader/system.img
cp ../my_new_dtb_c03_base_file.dtb kernel/dtb/
sudo ./apply_binaries.sh
sudo ./flash.sh -r -k kernel-dtb jetson-tx2 mmcblk0p1

All went well according to the console output.

I looked at the size of my new dtb file and compared it to the original. The original c03_base.dtb file has a size of 243K and my new one has a size of 202K.

So I reboot my TX2 and I do

ls -lh /boot

and I find out that the c03_base.dtb file weights 243K and not 202K as expected. Same with the dtb file in /boot/dtb/ which has the same name.

Am I checking this wrong?

The dtb in “/boot” is not used (it is left over from older versions). In previous releases there was a file path named in extlinux.conf (the “FDT” key/value pair), but the flash script currently places this in a partition instead.

Note: You can explore current device tree by viewing “/proc/device-tree/”…this is a reflection in RAM of the device tree as seen by the kernel.

That’s much clearer, thanks.

Since I need to update my tegra for driver needs, I have a couple more questions:

  • I cloned the content of my tegra with R27.1. Let’s suppose I install R28.1 and then for some reasons I need to go back to R27.1. I reinstall R27.1 and then, can I use my raw clone to restore the OS, files and libraries? Won’t the libraries be broken? I would expect everything to be fine but I have doubts.

  • Now, let’s say I mount my raw clone, modify it and unmount it on a linux machine. Can I use the new raw file to restore a tegra and expect my modifications to be there?

Your R27.1 clone can be restored exactly to any system currently set up as R27.1. You could in fact place a copy of your clone as “bootloader/system.img” and then flash with the “-r” to install both R27.1 and the clone at the same time. Example:

sudo ./flash.sh -r jetson-tx2 mmcblk0p1

…versus doing this for a new install which isn’t a clone:

sudo ./flash.sh -S 29318MiB jetson-tx2 mmcblk0p1

The “-r” prevents “system.img” and “system.img.raw” from being created (no “-r” would overwrite your clone if it has the system.img naming…protect your clone).

A clone is an exact bit-for-bit copy of the entire partition. Whatever was there before will be there now…files are not copied…30GB of bits are copied. The other content in other partitions is related to booting. Booting does have some assumptions about the rootfs.

Your loopback mounted changes on a PC will be exactly and perfectly mimicked when restoring with that modified clone. I put ssh keys in and network setup. My host does ssh login without password perfectly. I’ve also done “apt update” and “apt-get upgrade”, fixed any libglx.so issues, added some packages, so on, prior to cloning. On loopback I’ve copied some files I use for reference from my host…these too are perfectly preserved via the clone.

Do understand that historically “system.img.raw” did not always exist. Originally there was only “system.img” in uncompressed/raw format. Flash takes a lot longer though, so eventually flash.sh still generated “system.img” as it always had, then moved it to name “system.img.raw”, and makes this into a “sparse” (compressed) format with name “system.img” (the “mksparse” program converts from raw to sparse). The flash itself takes care of this raw/sparse format and does not care if “system.img” is raw or sparse…it just needs that name. The time taken for flashing with a raw image is hours instead of minutes.

A sparse image is useless other than for flashing (the Jetson itself is required to convert from this form of sparse back to raw). A raw image can be mounted and used just like any other file system via loopback. Protect your raw image. If you want to store it long term compress it (e.g., “bzip2 -9 backup.img.raw”).