Failed to Flash TX2

Hi there,

I built a customized kernel and was trying to flash that into TX2 (replaced the Image file under /boot). Then the board wouldn’t boot somehow. I connected the serial console but couldn’t figure out how I can boot the board. So now I’m trying to flash the TX2 via USB, but I failed to do that:

I downloaded sample Root filesystem (tried both R28.1 and R27.1) from the website and tried to flash the board with:

$ sudo ./ jetson-tx2 mmcblk0p1

And was always stuck at:

[0.0112] Boot Rom communication
[0.0121] tegrarcm_v2 --chip 0x18 --rcm rcm_list_signed.xml --skipuid

Can you help me with this issue? The Linux on my host computer is 16.04. I’m not using a USB hub. I’m using the micro USB cable from the TX2 dev Kit to connect TX2 to my computer. Or it would also be great if you have suggestions for bringing up the board from the serial console.

Thank you!


For the serial console, did you see any output? Setting should be 115200 8N1 (no flow control).

If you are in U-Boot and it sees a key hit, it may have halted waiting for your input. The command “boot” will continue if you interrupted to the command line. If you get a chance post whatever you did see in serial console.

Was this a VM or regular install? It sounds like it was not a VM, but I’d like to make sure since they are a problem.

When flashing on command line you need to use sudo during unpacking of the sample rootfs (do NOT use sudo to unpack the driver package)…you also need to run with sudo. The actual flash command must be done with sudo.

Make sure your “/etc/mke2fs.conf” does not show “ext4” or “metadata_csum” in the ext4 section.

Thank you for your detailed feedback!

Conclusion: I did not use sudo correctly when extracting the files. I followed your instruction on sudos and now I can flash my board! Thank you again!

I documented the following notes while trying every approach. Still posting it here in case it would be helpful for others.

1. Serial Console

The serial console is working. When I hit a key hit to halt it, I see the following (part of the tons of output) in the command line:

[0002.124] I> Updated memory info to DTB
[0002.130] E> "reset" doesn't exist, creating 
[0002.134] E> "pmc-reset-reason" doesn't exist, creating 
[0002.140] E> "pmic-reset-reason" doesn't exist, creating 
[0002.145] I> disabled_core_mask: 0xffffff0c
[0002.155] I> tegrabl_load_kernel_and_dtb: Done

U-Boot 2016.07-g5971907 (Feb 08 2017 - 18:01:58 -0800)

Model: NVIDIA P2771-0000-500
DRAM:  7.8 GiB
MC:   Tegra SD/MMC: 0, Tegra SD/MMC: 1
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@2490000
Hit any key to stop autoboot:  0 
Tegra186 (P2771-0000-500) # 
CTRL-A Z for help | 115200 8N1 | NOR | Minicom 2.7 | VT102 | Offline | ttyUSB0

If I run “boot”, I will get:

Tegra186 (P2771-0000-500) # boot
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
462 bytes read in 87 ms (4.9 KiB/s)
p2771-0000 eMMC boot options
1:      primary kernel
Enter choice:

And then tons of booting output.

2. VM
It’s not a VM.

3. sudo
As stated above, I didn’t use sudo properly while extracting the files. I solved my problem after following the instruction on sudos.

4. .conf file
In /etc/mke2fs.conf of the sample root file system, within [fs_types], I see:

ext4 = {
		features = has_journal,extent,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize
		auto_64-bit_support = 1
		inode_size = 256

Same for R27.1 and R28.1.

Another problem coming:

I started flashing the board, and was finally stuck here:

[   0.3971 ] Updating mb1-bct with firmware information
[   0.3991 ] tegrabct_v2 --chip 0x18 --mb1bct mb1_bct_MB1.bct --updatefwinfo flash.xml.bin
[   0.4002 ] MB1-BCT version: 0xe
[   0.4006 ] 
[   0.4006 ] Updating mb1-bct with storage information
[   0.4030 ] tegrabct_v2 --chip 0x18 --mb1bct mb1_bct_MB1.bct --updatestorageinfo flash.xml.bin
[   0.4040 ] MB1-BCT version: 0xe
[   0.4045 ] 
[   0.4054 ] tegrahost_v2 --align mb1_bct_MB1.bct
[   0.4061 ] 
[   0.4070 ] tegrahost_v2 --appendsigheader mb1_bct_MB1.bct zerosbk
[   0.4079 ] 
[   0.4090 ] tegrasign_v2 --key None --list mb1_bct_MB1_sigheader.bct_list.xml
[   0.4098 ] Assuming zero filled SBK key
[   0.4126 ] 
[   0.4161 ] tegrahost_v2 --updatesigheader mb1_bct_MB1_sigheader.bct.encrypt mb1_bct_MB1_sigheader.bct.hash zerosbk
[   0.4174 ] 
[   0.4175 ] Copying signatures
[   0.4197 ] tegrahost_v2 --chip 0x18 --partitionlayout flash.xml.bin --updatesig images_list_signed.xml
[   0.4331 ] 
[   0.4332 ] Boot Rom communication
[   0.4343 ] tegrarcm_v2 --chip 0x18 --rcm rcm_list_signed.xml
[   0.4351 ] BootRom is not running
[   1.6827 ] 
[   1.6840 ] tegrarcm_v2 --isapplet
[ 1001.6961 ] 
[ 1001.7030 ] tegradevflash_v2 --iscpubl
[ 1001.7051 ] CPU Bootloader is not running on device.
[ 2001.7051 ]

There wasn’t any new output for a long time after the last line above, and I decided to Ctrl-C to stop. Maybe I’ll run this again before going to bed. Any suggestions on this? Or do I simply have to be patient and wait for the flashing process to complete?

Thank you!

Beware that the “/etc/mke2fs.conf” content in question is on the host PC, not the Jetson. The host is what creates the file system. Having 64bit or metadata_csum would not change how flash appears, but it would cause boot to not find a root partition when you actually get to the point where U-Boot hands off to the Linux kernel (it would halt at that point). This won’t be what causes a flash to stop, though it would stop boot of the Jetson.

Is this R28.1? Your log looks like it might be an excerpt skipping something at the start.

Starting at this line it doesn’t look quite right:

[   1.6840 ] tegrarcm_v2 --isapplet

Your log didn’t get a reply to this, it should probably have replied something like this:

[   2.0927 ] Applet version 01.00.0000

…I don’t know the significance of this.

Then a whole lot is missing, the time stamp starts again far in. Is this the whole log?

When logging you’ll see a very long line in the logs due to the progress bar really being new text…the GUI will back up the cursor and erase the old percent complete, but when logging it all is just a series of characters. You can use something like this to get a log with that reduced (this reserves the largest possible partition for rootfs and gawk is cutting down the size of the progress bar in the log):

sudo ./ -S 29318MiB jetson-tx2 mmcblk0p1 2>&1 | gawk '{gsub("[0-9][0-9]+[/][0-9[0-9]+ bytes sent..",".");print}' | tee log.txt

Don’t forget to check if you have enough disk space before starting…from the location of the command run “df -H .” before starting.

“/etc/mke2fs.conf" was good on my host PC.

It is R28.1. Would you recommend R27.1? Or they will end up similarly?

The log I showed was not everything, but was everything on the screen where I was stuck.

I have more than 40GB on my hard disk. I assume that should be enough.

I tried again yesterday night, and flashing was stuck at the same place (CPU Bootloader is not running on device.) for the whole night. I’m not sure if there’s more I can do. I’m now learning about booting the TX2 with SD card, but I have to do everything about the SD card on my host computer since the TX2 doesn’t boot. Any suggestions on this?

Thank you!

I’d definitely recommend R28.1 over R27.1.

Is the serial console the source which was stuck? I would actually recommend against using this during flash, and only connect it after flash (or at least not run the serial console program…I’m not sure what would happen if stray bytes went in during a flash).

I really wish I could see a full log of the flash itself. It is probably a pain to do this over and over (it is certainly time consuming), but if you were to get a complete log of the flash (I posted a way to do this with “tee” and “gawk” cutting out long progress bars) it would help. There are places where some component not running is the way it should be, and in other places not. The timestamps themselves are a bit odd. Here is an excerpt of one of my successful flashes for a TX2 on R28.1…compare this to yours and look closely at timestamps:

<b>[   5.9225 ]</b> tegrarcm_v2 --isapplet
<b>[   6.5575 ]</b> 
<b>[   6.5826 ]</b> tegradevflash_v2 --iscpubl
<b>[   6.5850 ]</b> CPU Bootloader is not running on device.
[   6.8467 ] 
[   8.6561 ] Retrieving storage infomation
[   8.6599 ] tegrarcm_v2 --oem platformdetails storage storage_info.bin
[   8.6627 ] Applet is not running on device. Continue with Bootloader
[   9.2239 ] 
[   9.2277 ] tegradevflash_v2 --oem platformdetails storage storage_info.bin
[   9.2304 ] Bootloader version 01.00.0000
[   9.4951 ] Saved platform info in storage_info.bin
[   9.5030 ] 
[   9.5031 ] Flashing the device
[   9.5057 ] tegraparser_v2 --storageinfo storage_info.bin --generategpt --pt flash.xml.bin

On yours it is like we are missing about 16 minutes or more of logs. That or I don’t have enough context to actually pin down where this occurs in comparison to a complete log. Perhaps that is how it actually went…but using tee would mean no possibility of losing output in mouse copy and paste.


I am facing a similar issue. Everytime I try to flash, I end up stuck in this. It’s a VM(ubuntu 16.04 x64) and USB 3.0(xHCI) controller

[   4.2212 ] tegrarcm_v2 --boot recovery
[   4.2219 ] Applet version 01.00.0000
[   4.2542 ] 
[   4.2548 ] tegrarcm_v2 --isapplet
[   4.9126 ] 
[   4.9250 ] tegradevflash_v2 --iscpubl
[   4.9269 ] CPU Bootloader is not running on device.
[   5.6666 ] 
[  37.0369 ] Retrieving storage infomation
[  37.0401 ] tegrarcm_v2 --oem platformdetails storage storage_info.bin
[  37.0438 ] Applet is not running on device. Continue with Bootloader
[  37.0945 ] 
[  37.0964 ] tegradevflash_v2 --oem platformdetails storage storage_info.bin
[  37.1015 ] CPU Bootloader is not running on device.
[  37.1180 ] 
Error: Return value 4
Command tegradevflash_v2 --oem platformdetails storage storage_info.bin
Failed flashing t186ref.

In this case, its trying to retrieve storage information but it fails with bootloader. Any input on this would help.


USB is a problem for a VM. There may be times during flash in which USB is re-enumerated, and each time the VM will lose the device. I don’t know what method was used for people who succeeded, but I think one of the keys was to somehow dedicate that device to the VM host in such a way that even if it disconnects and reconnects it will be found again (and each time there is enumeration this is essentially what is going to happen). In any case, this is a very very common problem when using a VM.

Stopped struggling with VM! Installed a native ubuntu which made my life easier with flashing tx2.
Thanks linuxdev for your prompt reply.