Hi guys,
I am having issues with my TX1. I have followed all the steps in http://developer.download.nvidia.com/embedded/L4T/r28_Release_v2.0/GA/BSP/l4t_quick_start_guide.txt and tried to flash either to boot on sda1, mmcblk0p1 or mmcblk1p1 but the process got stuck as shown in the screenshot here ( Dropbox - IMG_1466.jpg - Simplify your life ). This process worked pretty well in the past, I hope this is not a hardware problem. Is there a way to check if the HW works? Or a way to force the flash?
Thanks!
Paolo
Do you have enough disk space on your host ? JetPack packages and image require several tens of GB.
In case it is the problem and you want to try on an external disk, be sure to run JetPack in an ext4 filesystem.
Hi! Thanks for the update! Yes, JetPack dimension is not a problem, I have it on the notebook and I am just trying to flash the TX1 to boot from sda1 or internal memory. The flash.sh correctly starts, it detects the TX1 in REC mode but it gets stuck when trying to flash the boot loader.
You may want to simplify and flash purely from command line. However, any “stuck” requires checking first if this is a VM or not. Is this host a regular install and not a VM? Is there anything unusual about the host?
I am flashing from command line, no VM, no Windows, just ubuntu and a sudo ./flash.sh etc.
I succeed in flashing other TX1s with the same host, this specific device has this weird issue of getting stuck in the flash processes at the point shown in the picture ( Dropbox - IMG_1466.jpg - Simplify your life ). Do you think there is a way to force the flash or to check if the memory got permanently damaged?
Thanks!
Paolo
From your picture it seems to me it is building the image (this may take some time) thus my question about disk space.
Did you use -r for flash command in order to reuse a previous image ?
This is either a case of needing to wait longer, or else host side. This step does take significant time. I’ll explain what is going on there.
The “rootfs/” subdirectory is a copy of files which will create the future root file system (this is slightly off because some “rootfs/boot/” files will be edited). “system.img” is a loopback file formatted as ext4 and behaving exactly like an independent partition on your host system while loopback mounted. The entire content of your rootfs is being copied into the loopback mounted system and so there is a lot of time required to read and write that much data. This is perhaps two or three GB of data moving around on the disk after creating a 15GB blank.
You might not actually be locking up or stalling there. I don’t remember how long it should actually take, but consider 30 minutes just for a test.
If it still fails, then it may be an issue with available loopback devices. There is a flaw in the flash.sh script which doesn’t correctly handle loopback other than if loop0 is the correct loop device. However, if this bug hits, then the copy to loopback mounted system will fail immediately without locking up or stalling.
Note what @Honey_Patouceul said…this is so much data that it can truncate…you won’t see an error if the file system fills up, it’ll happily fill up and continue without telling you part of it is missing.
Hi guys,
thanks for the detailed information. I was kinda confident that the host was not the problem as with the same host and the same command I am able to flash other TX1s (in ~30/40 mins). However, if you say that such a complex data transfer could be randomly corrupted I’ll try again with what you guys suggested.
I was just hoping for flash to have a “force” option to clean up the TX1 memory.
Thanks again
Paolo
If that fails be sure to mention your exact flash command. An example with logging would be:
sudo ./flash.sh -S 14580MiB jetson-tx1 mmcblk0p1 2>&1 | tee flash_log.txt
If you go to “reuse” the rootfs with the “-r” option then you’d want the rootfs being used to be from the same release the Jetson was originally flashed with. You might also want to know the “-S 14580MiB” matches the size from the original flash…I’m not sure how that’d work if the sizes didn’t match, but eMMC is more flexible with that than a regular hard drive so it might not matter.
I can’t flash a TX1 from an Ubuntu 16.04 host either.
When I run the regular installer using ./JetPack-L4T-3.2-linux-x64_b196.run or with running sudo ./flash.sh jetson-tx1 mmcblk0p1` I get the following error:
[ 2.3838 ] Sending bct
[ 2.3840 ] [................................................] 100%
[ 2.5431 ]
[ 2.5432 ] Sending bootloader and pre-requisite binaries
[ 2.5451 ] tegrarcm --download ebt cboot.bin 0 0 --download rp1 tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb 0
[ 2.5468 ] Applet version 00.01.0000
[ 2.8440 ] Sending ebt
[ 2.9327 ]
Error: Return value 1
Command tegrarcm --download ebt cboot.bin 0 0 --download rp1 tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb 0
Failed flashing t210ref.
And when trying to use the flash utility as described above I get this error:
sudo ./flash.sh -S 14580MiB jetson-tx1 mmcblk0p1 2>&1 | tee flash_log.txt
###############################################################################
# L4T BSP Information:
# R28 (release), REVISION: 2.0, GCID: 10567845, BOARD: t210ref, EABI: aarch64,
# DATE: Fri Mar 2 04:58:16 UTC 2018
###############################################################################
# Target Board Information:
# Name: jetson-tx1, Board Family: t210ref, SoC: Unknown,
# OpMode: production, Boot Authentication: ,
###############################################################################
Error: The Actual SoC ID(0x42) mismatches intended jetson-tx1 SoC ID(0x21).
lsusb returns
Bus 003 Device 029: ID 0955:7721 NVidia Corp.
df -h returns
/dev/sdc1 429G 55G 354G 14% /
Seems your Jetson is a TK1, not a TX1.
I agree it looks like a TX board and module.
No idea why your flash command reads TK1 id, though.
running tegrarcm --download ebt cboot.bin 0 0 --download rp1 tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb 0 manually I get
tegrarcm: unrecognized option '--download'
tegrarcm: unrecognized option '--download'
tegrarcm: Unknown command line argument: ebt
usage: tegrarcm [options] --bct=bctfile --bootloader=blfile --loadaddr=<loadaddr>
tegrarcm [options] --bct=bctfile readbct
Commands:
readbct
Read the BCT from the target device and write to bctfile
Default operation if no command is specified will download BCT and
bootloader to device and start execution of bootloader
Options:
--entryaddr=<entryaddr>
Specify the entry point for the bootloader, if this option is
not provided, it is assumed to be loadaddr
--help
Print this help information
--version
Print version information and exit
--miniloader=mlfile
Read the miniloader from file instead of using built-in
miniloader
--miniloader_entry=<mlentry>
Specify the entry point for the miniloader
tegrarcm --version returns
tegrarcm 1.6
I’m not sure how SoC ID is determined during a flash, but that does indeed rate high on the odd mystery list.
Has this board ever been flashed before? Was it running this entire time on the original file system it arrived with?
Has the module ever been used on a different carrier board?
Is there any other Jetson hardware connected at the same time?
You might want to completely remove your “Linux_for_Tegra/” directory and start fresh (just don’t lose any clones you might have), though I doubt this would change anything (on the other hand, this is probably something you would need to do if you are going to be certain it isn’t driver package corruption).