Hello, so i just installed the Jetpack on my computer, during the isntallation process once the post-installation window opens instruction to flash the jetson, i get an error that prompts me that it couldnt be flashed and to check the log. Here is what my log says
./tegraflash.py --chip 0x18 --applet "/home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/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.0051 ] Generating RCM messages
[ 0.0062 ] tegrarcm_v2 --listrcm rcm_list.xml --chip 0x18 --download rcm /home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/mb1_recovery_prod.bin 0 0
[ 0.0072 ] RCM 0 is saved as rcm_0.rcm
[ 0.0091 ] RCM 1 is saved as rcm_1.rcm
[ 0.0091 ] List of rcm files are saved in rcm_list.xml
[ 0.0091 ]
[ 0.0091 ] Signing RCM messages
[ 0.0106 ] tegrasign_v2 --key None --list rcm_list.xml --pubkeyhash pub_key.key
[ 0.0146 ] Assuming zero filled SBK key
[ 0.0190 ]
[ 0.0190 ] Copying signature to RCM mesages
[ 0.0198 ] tegrarcm_v2 --chip 0x18 --updatesig rcm_list_signed.xml
[ 0.0208 ]
[ 0.0208 ] Boot Rom communication
[ 0.0221 ] tegrarcm_v2 --chip 0x18 --rcm rcm_list_signed.xml --skipuid
[ 0.0230 ] RCM version 0X180001
[ 0.0238 ] Boot Rom communication completed
[ 1.0310 ]
[ 1.0353 ] tegrarcm_v2 --isapplet
[ 1.0382 ] Applet version 01.00.0000
[ 1.0412 ]
[ 1.0430 ] Retrieving EEPROM data
[ 1.0431 ] tegrarcm_v2 --oem platformdetails eeprom cvm /home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/cvm.bin
[ 1.0440 ] Applet version 01.00.0000
[ 1.0460 ] Saved platform info in /home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/cvm.bin
[ 1.1296 ]
Board ID(3310) version(B00)
copying bctfile(/home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/t186ref/BCT/P3310_A00_8GB_Samsung_8GB_lpddr4_204Mhz_A02_l4t.cfg)... done.
copying misc_config(/home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/t186ref/BCT/tegra186-mb1-bct-misc-si-l4t.cfg)... done.
copying pinmux_config(/home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/t186ref/BCT/tegra186-mb1-bct-pinmux-quill-p3310-1000-c03.cfg)... done.
copying pmic_config(/home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/t186ref/BCT/tegra186-mb1-bct-pmic-quill-p3310-1000-c03.cfg)... done.
copying pmc_config(/home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/t186ref/BCT/tegra186-mb1-bct-pad-quill-p3310-1000-c03.cfg)... done.
copying prod_config(/home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/t186ref/BCT/tegra186-mb1-bct-prod-quill-p3310-1000-c03.cfg)... done.
copying scr_config(/home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/t186ref/BCT/minimal_scr.cfg)... done.
copying scr_cold_boot_config(/home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/t186ref/BCT/mobile_scr.cfg)... done.
copying bootrom_config(/home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/t186ref/BCT/tegra186-mb1-bct-bootrom-quill-p3310-1000-c03.cfg)... done.
copying dev_params(/home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/t186ref/BCT/emmc.cfg)... done.
Existing bootloader(/home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/nvtboot_cpu.bin) reused.
populating kernel to rootfs... done.
populating initrd to rootfs... done.
populating extlinux.conf.emmc to rootfs... done.
populating /home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/kernel/dtb/tegra186-quill-p3310-1000-c03-00-base.dtb to rootfs... done.
done.
Making Boot image... done.
Existing sosfile(/home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/mb1_recovery_prod.bin) reused.
copying tegraboot(/home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/t186ref/nvtboot.bin)... done.
Existing mb2blfile(/home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/nvtboot_recovery.bin) reused.
Existing mtspreboot(/home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/preboot_d15_prod_cr.bin) reused.
Existing mts(/home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/mce_mts_d15_prod_cr.bin) reused.
Existing mb1file(/home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/mb1_prod.bin) reused.
Existing bpffile(/home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/bpmp.bin) reused.
copying bpfdtbfile(/home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/t186ref/tegra186-a02-bpmp-quill-p3310-1000-c01-00-te770d-ucm2.dtb)... done.
Existing scefile(/home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/camera-rtcpu-sce.bin) reused.
Existing spefile(/home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/spe.bin) reused.
copying wb0boot(/home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/t186ref/warmboot.bin)... done.
Existing tosfile(/home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/tos.img) reused.
Existing eksfile(/home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/eks.img) reused.
copying dtbfile(/home/karla/Downloads/64_TX2/Linux_for_Tegra_tx2/kernel/dtb/tegra186-quill-p3310-1000-c03-00-base.dtb)... done.
Making system.img...
rm: cannot remove 'mnt': Device or resource busy
clearing ext4 mount point failed.
You have something blocking a temporary directory from being reused. One possibility is that you have something mounted there already…probably this is located at the JetPack install location “Linux_for_Tegra/mnt/” (this is really the driver package install location, but JetPack is a front end to the driver package). Does this directory exist when you view it manually via ls? If so, what is in it, and what permissions does the directory have?
cd /where/ever/it/is/Linux_for_Tegra
ls -ld ./mnt
mount | egrep Linux_for_Tegra
FYI, if “Linux_for_Tegra/mnt/” does exist, and if you find nothing in there you need to save, then you can use sudo and rm -Rf that pesky directory…just be very careful that what this directory is and what is in it really is just something you can throw away. Normally this is a temporary working directory which is not kept after a flash completes.
In my case, I need to flash the TX2 hoping to get the original camera cache binary for the default sensor. Anyway, I first tried to do a quick run of
~/jetpack/64_TX2/Linux_for_Tegra_tx2/flash.sh
in order to wipe out the target TX2. But I’m not allowed of doing /dev/video0 by doing that.
Next, I tried to use the installation GUI. I ran
$ cd ~/jetpack/
$ ./JetPack-L4T-3.1-linux-x64.run
The process took about an hour to re-install everything for JetPack 3.1. It ran smoothly until "Making system.img… ", then the host promoted
rm: cannot remove ‘mnt’: Device or resource busy
clearing ext4 mount point failed.
I wonder what I should do to remove the ‘mnt’. It’s hard to imagine what had been mounted on the machine. I have an external USB-3 hard-drive. Could it be the culpit?
flash.sh without arguments won’t do anything. An example of command line would be:
sudo -s
cd /where/ever/it/is/Linux_for_Tegra/rootfs
tar xvfj /where/ever/sample/rootfs/is/Tegra186_Linux_R28.1.0_aarch64.tbz2
cd ..
./apply_binaries.sh
# Put Jetson in recovery mode with micro-B USB cable connected.
# Verify it's there via "lsusb -d 0955:7c18".
./flash.sh -S 29318MiB jetson-tx2 mmcblk0p1
exit
The error is very likely because there was already a loopback device on that mount point from an earlier operation. During a flash there will be a mnt directory created temporarily and used for loopback operations. When finished this is removed. If something did not complete normally in a prior operation removal won’t occur, and you will need to manually umount that point, e.g.:
Note that this also would tend to cause the expected loopback device “/dev/loop0” to be occupied. Because of a bug in the logic of flash.sh you’d also need to do this if you are “leaking” loop devices:
sudo losetup --detach /dev/loop0
# Then verify the device is ready as the next available loop device (without sudo "--find" does not create the device, and if flash.sh is run sudo, this won't matter...but I use sudo in this example because you will want to verify after the command "/dev/loop0" exists):
sudo losetup --find
@linuxdev, thanks for the instruction. I did a dumb way by running the installation GUI as
$ cd ~/jetpack
$ ./JetPack-L4T-3.1-linux-x64.run
Anyway, after I disable my USB-3 external hard drive, the “mnt” is gone from the folder
~/jetpack/64_TX2/Linux_for_Tegra_tx2/bootloader
And the installation runs fine and flash seems okay.
But the camera (build-in on the default board) fails to work after re-flash. If I run the command:
Setting pipeline to PAUSED ...
Socket read error. Camera Daemon stopped functioning.....
gst_nvcamera_open() failed ret=0
ERROR: Pipeline doesn't want to pause.
Got context from element 'eglglessink0': gst.egl.EGLDisplay=context, display=(GstEGLDisplay)NULL;
ERROR: from element /GstPipeline:pipeline0/GstNvCameraSrc:nvcamerasrc0: GStreamer error: state change failed and some element failed to post a proper error message with the reason for the failure.
Additional debug info:
gstbasesrc.c(3354): gst_base_src_start (): /GstPipeline:pipeline0/GstNvCameraSrc:nvcamerasrc0:
Failed to start
Setting pipeline to NULL ...
Caught SIGSEGV
#0 0x0000007f99723130 in pthread_join (threadid=547980579328,
#1 0x0000007f997d9eb0 in ?? () from /lib/aarch64-linux-gnu/libglib-2.0.so.0
#2 0x0000000000000011 in ?? ()
Spinning. Please run 'gdb gst-launch-1.0 2463' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.
Here is a section of related “dmseg”
[ 834.427871] nvcamera-daemon[2465]: unhandled level 2 translation fault (11) at 0x00000000, esr 0x92000006
[ 834.437453] pgd = ffffffc07b1b2000
[ 834.440871] [00000000] *pgd=0000000260127003, *pud=0000000260127003, *pmd=0000000000000000
[ 834.451035] CPU: 5 PID: 2465 Comm: nvcamera-daemon Not tainted 4.4.38-tegra #1
[ 834.458322] Hardware name: quill (DT)
[ 834.461994] task: ffffffc1e5bb6400 ti: ffffffc172afc000 task.ti: ffffffc172afc000
[ 834.469474] PC is at 0x402efc
[ 834.472444] LR is at 0x402ef8
[ 834.475449] pc : [<0000000000402efc>] lr : [<0000000000402ef8>] pstate: 60000000
[ 834.482844] sp : 0000007f8d1b02d0
Plus, there is no existence of “/dev/video0”
I wonder if the problem has anything to do with the compilation of new device-tree on the host prior to re-flashing the target TX2.
I’ve seen this happen when a loop device already has mounted the system.img file created by the flash.
This can happen if a previous flash fails, or or interrupted.
You can clear this up by checking which “loop” device is mounted to your image (use “df”) and “umount” it.
Or you can reboot your host machine, which will unmount all loops using the big hammer.
I have also not gotten eglglessink to work.
However, it does work with nvoverlaysink.
Try:
gst-launch-1.0 nvcamerasrc ! nvoverlaysink
Also, my camera is upside down when doing this, and needs a rotate command to go right side up. Yours probably will have the same problem.
Existence of “/dev/video#” entries would depend on a driver registering and assuming ownership of the camera. If this is USB, you might post the “sudo lsusb -vvv” (for just the one device) and “lsusb -t” output (for the whole tree). If this is a PCIe card you might add the “sudo lspci -vvv” for that device. Not sure what to use if it is something like CSI.
And yes, device tree would be high on the list for why a camera might not show up.
@snarky, it seems in my case the “mnt” issue is related to an external USB hard drive (a FAT drive, I believe). Actually, the H/D is for my Windows 10 operation, although the Ubuntu shares the 64-bit machine with Windows 10. Apparently, the H/D caused the failure of “ext4 mount point”.
Once I unplug the H/D, the problem of “ext4 mount point” is gone.
Now I’m working on the built-in camera problem after re-flash.
@linuxdev, after I wiped the jetpack directory clean and re-flashed the package to TX2, the problem was gone. It’s safe to guess that, in my case, the error was caused by the earlier work in builing the device tree for IMX219 sensor. The build and flash of DTB were successful, even though more works are still needed on the DTSi. I didn’t do anything else on the Ubuntu machine afterward.
I don’t know why the process of JetPack installation didn’t override the whatever DTB data in the flash area. Anyway, at least we know the problem and a way to get round.
the possible cause of this (in my case) was, Cancellation of Flashing process in the middle when it was apparently stuck at line: “populating rootfs”
well I got out of this after
removing following files/folders at installation directory of host: _installer local.manifest repository.json 64_TX2
removing 64_TX2 gave following error “rm: cannot remove ‘64_TX2/Linux_for_Tegra/bootloader/mnt’: Device or resource busy”, But once i Unplugged Usb connection with TX2 and Unmounted a ‘32GB volume’, it got removed