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 ./flash.sh 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.
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 apply_binaries.sh 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.
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
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...
Retrieving file: /boot/extlinux/extlinux.conf
462 bytes read in 87 ms (4.9 KiB/s)
p2771-0000 eMMC boot options
1: primary kernel
And then tons of booting output.
It’s not a VM.
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:
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?
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):
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?
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.
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.