probing the target board failed

Hi,

I am getting an error when I try to flush the JetPack drivers to the Jetson TX2 board. I manage to flush the tools to the board if I don’t choose any kernel related options. Such as there is no problem with flushing the openCV and VisionWork stuff to the board.

If I choose to flush the kernel then it asks me the connections and I chose the one which the board is connected to the host computer with an ethernet cable, and the host is connected to the internet with wifi, before I also tried to connect the host computer to the router with a cable.

The last screen for flushing the data asks me to put the board in FLASH mode, after doing it (as following the given instructions) I checked if the board is seen by the host with “lsusb”, and I see the board as “Bus 001 Device 015: ID 0955:7c18 NVidia Corp.”

After I hit Enter, I get a message as:

###############################################################################

L4T BSP Information:

R28 (release), REVISION: 2.0, GCID: 10567845, BOARD: t186ref, EABI: aarch64,

DATE: Fri Mar 2 04:57:01 UTC 2018

###############################################################################
Error: probing the target board failed.
Make sure the target board is connected through
micro-B USB port and is in recovery mode.

Any idea about what would be the reason? I think that there shouldn’t be any problem with the micro-B cable since I see the board as connected to the host with lsusb command.

Thanks in advance.

Is this a VM? VMs don’t correctly pass USB through.

I am not using a VM, by linux version is Ubuntu 16.04.

Package additions use wired ethernet, anything asking for recovery mode (flash mode) implies flashing. All flash operations proceed prior to package operations.

To simplify I suggest purposely disconnecting the wired ethernet and checking that you only want to flash…no packages should be installed. Then with that micro-B USB cable connected check with lsusb again. Does this still fail?

Is the cable you are using the one provided with the Jetson? I expect failures from cables which were designed as charger cords, but the one supplied with the Jetson is good quality and also works for data.

Hi again,

we tried it again as you suggested it didn’t work out, we got the same error. After this we tried to flush it from a virtual machine which has a Ubuntu 16.04 version, this try also didn’t work.

Using the same USB cable and virtual machine we manage to flush the kernel and selected tools to Jetson TX1 board. It is strange that we get this error on TX2 board and not on TX1 board.

Thanks for your help

When JetPack is extracting the packages we get tar error. tar is installed on our machines. The output of JetPack/_installer/logs/64_TX2/filesystem_tx2.log as follows:

Using rootfs directory of: /home/sinan/tools/JetPack/64_TX2/Linux_for_Tegra/rootfs
Extracting the NVIDIA user space components to /home/sinan/tools/JetPack/64_TX2/Linux_for_Tegra/rootfs
Extracting the BSP test tools to /home/sinan/tools/JetPack/64_TX2/Linux_for_Tegra/rootfs
Extracting the NVIDIA gst test applications to /home/sinan/tools/JetPack/64_TX2/Linux_for_Tegra/rootfs
Extracting the configuration files for the supplied root filesystem to /home/sinan/tools/JetPack/64_TX2/Linux_for_Tegra/rootfs
Creating a symbolic link nvgstplayer pointing to nvgstplayer-1.0
Creating a symbolic link nvgstcapture pointing to nvgstcapture-1.0
Extracting Weston to /home/sinan/tools/JetPack/64_TX2/Linux_for_Tegra/rootfs
Adding symlink libcuda.so --> libcuda.so.1.1 in target rootfs
Adding symlink libGL.so --> libGL.so.1 in target rootfs
Adding symlink libnvbuf_utils.so --> libnvbuf_utils.so.1.0.0 in target rootfs
Adding symlink libnvid_mapper.so --> libnvid_mapper.so.1.0.0 in target rootfs
Adding symlink libcuda.so --> tegra/libcuda.so in target rootfs
Adding symlink libEGL.so --> libEGL.so.1 in target rootfs
Adding symlink libGLESv2.so --> libGLESv2.so.2 in target rootfs
Adding symlink /home/sinan/tools/JetPack/64_TX2/Linux_for_Tegra/rootfs/usr/lib/aarch64-linux-gnu/libdrm_nvdc.so --> /home/sinan/tools/JetPack/64_TX2/Linux_for_Tegra/rootfs/usr/lib/aarch64-linux-gnu/tegra/libdrm.so.2
Adding symlink nvidia_icd.json --> /etc/vulkan/icd.d/nvidia_icd.json in target rootfs
Creating symlinks for weston, wayland-demos, libinput and wayland-ivi-extention modules
Adding symlinks for NVIDIA systemd services
Copying USB device mode filesystem image to /home/sinan/tools/JetPack/64_TX2/Linux_for_Tegra/rootfs
Disabling NetworkManager-wait-online.service
Disable the ondemand service by changing the runlevels to ‘K’
Extracting the firmwares and kernel modules to /home/sinan/tools/JetPack/64_TX2/Linux_for_Tegra/rootfs
Extracting the kernel headers to /home/sinan/tools/JetPack/64_TX2/Linux_for_Tegra/rootfs/usr/src
tar: write error
Adding symlink /home/sinan/tools/JetPack/64_TX2/Linux_for_Tegra/rootfs/lib/modules/4.4.38-tegra/build --> /usr/src/linux-headers-4.4.38-tegra
Installing Image into /boot in target rootfs
Installing the board *.dtb files into /boot in target rootfs
Success!

VMs are highly unreliable. One issue is how USB enumerates and gets recaptured in a running session (something not an issue on a real host). You really should try a real install for the PC (many people dual boot).

NOTE: One possible tar write error not related to a VM is if you ran out of disk space.