Jetson TX2 not recognized installation inside docker error 8 Error: Return value 8 Command tegrarcm_v2 --chip 0x18 --rcm rcm_list_signed.xml --skipuid Reading board information failed.

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX2
1

Hi

TX2 is not recognized when installing from within a docker image. lsusb shows the TX2

Here is the error message:

./tegraflash.py --chip 0x18 --applet “/sharefolder/self-driving-car/jp3/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.0013 ] Generating RCM messages
[ 0.0023 ] tegrarcm_v2 --listrcm rcm_list.xml --chip 0x18 --download rcm /sharefolder/self-driving-car/jp3/64_TX2/Linux_for_Tegra_tx2/bootloader/mb1_recovery_prod.bin 0 0
[ 0.0030 ] RCM 0 is saved as rcm_0.rcm
[ 0.0037 ] RCM 1 is saved as rcm_1.rcm
[ 0.0037 ] List of rcm files are saved in rcm_list.xml
[ 0.0037 ]
[ 0.0038 ] Signing RCM messages
[ 0.0057 ] tegrasign_v2 --key None --list rcm_list.xml --pubkeyhash pub_key.key
[ 0.0065 ] Assuming zero filled SBK key
[ 0.0100 ]
[ 0.0100 ] Copying signature to RCM mesages
[ 0.0109 ] tegrarcm_v2 --chip 0x18 --updatesig rcm_list_signed.xml
[ 0.0121 ]
[ 0.0121 ] Boot Rom communication
[ 0.0130 ] tegrarcm_v2 --chip 0x18 --rcm rcm_list_signed.xml --skipuid
[ 0.0144 ]
Error: Return value 8
Command tegrarcm_v2 --chip 0x18 --rcm rcm_list_signed.xml --skipuid
Reading board information failed.

my docker host system is

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
Release: 14.04
Codename: trusty

lusb shows

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 138a:003f Validity Sensors, Inc. VFS495 Fingerprint Reader
Bus 001 Device 004: ID 05c8:0383 Cheng Uei Precision Industry Co., Ltd (Foxlink)
Bus 001 Device 016: ID 24ae:1801
Bus 001 Device 017: ID 0955:7c18 NVidia Corp.
Bus 001 Device 006: ID 8087:0a2b Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

lsusb -t shows

/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/16p, 480M
|__ Port 4: Dev 17, If 0, Class=Vendor Specific Class, Driver=, 480M
|__ Port 5: Dev 16, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 5: Dev 16, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 7: Dev 4, If 0, Class=Video, Driver=uvcvideo, 480M
|__ Port 7: Dev 4, If 1, Class=Video, Driver=uvcvideo, 480M
|__ Port 8: Dev 5, If 0, Class=Vendor Specific Class, Driver=, 12M
|__ Port 12: Dev 6, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 12: Dev 6, If 1, Class=Wireless, Driver=btusb, 12M

How can I fix this problem ?

Many Thanks

Rupert

2

I’m not sure how docker works, but the basic USB seems correct (it’s running at USB2 speeds), so it is probably some other detail about the environment (I realize that’s a very broad possibility, but I do not know the specifics of return value 8).

3

Is there maybe a way to try an install from 16.10 Ubuntu ? That’s the only other version I have…

Thanks

Rupert

4

The Ubuntu 14/16 requirements are for JetPack. The underlying flash itself can be done with just the driver package plus sample rootfs on command line with any x86_64 Linux host. Should this work you can still run JetPack later for package installs without flashing.

General command line flash info:

  1. Download the driver package plus sample rootfs. Most recent R27.1 is at: https://developer.nvidia.com/embedded/linux-tegra
  2. Unpack the driver package (goes to "Linux_for_Tegra" subdirectory). Within this is subdirectory "rootfs":: 
    Tegra_Linux_Sample-Root-Filesystem_R27.1.0_aarch64.tbz2
  3. cd into rootfs, use sudo to unpack the sample rootfs: 
    sudo tar xjvf ../wherever/it/is/Tegra_Linux_Sample-Root-Filesystem_R27.1.0_aarch64.tbz2
  4. cd back up one directory to the "Linux_for_Tegra" directory ("cd ..").
  5. Use sudo to apply_binaries.sh: 
    sudo ./apply_binaries.sh
  6. Verify you still have enough disk space of type ext4, perhaps 35GB: 
    df -H -T .
  7. Put the Jetson in recovery mode (hold the recovery button while powering on the Jetson or hitting reset for an already on Jetson, connect the micro-B USB cable to host). Verify host can see the Jetson...see output from this lsusb command: 
    lsusb -d 0955:7c18
  8. Flash with sudo: 
    sudo ./flash.sh -S 28GiB jetson-tx2 mmcblk0p1

EDIT: The maximum “-S” size is “-S 29318MiB”.

Note that after you are finished, if you choose to delete and not reuse the generated image, you can save disk space by deleting “bootloader/system.img” and “bootloader/system.img.raw”.

Before starting the actual flash you may also want to be sure loop0 is generated via:

sudo losetup --find
# ...this should have replied "/dev/loop0"...
5

Thank you. But I am a bit confused as your comment references both R27.1 and R24. Which one is the correct one for TX2 ? When I douwnload Tegra186_Linux_R27.1.0_aarch64.tbz2 I cannot extract Tegra_Linux_Sample-Root-Filesystem_R24.2.1_aarch64.tbz2 from it…

Maybe I need to download another zip file ?

Thank You

Rupert

6

Hooray! it works. Thank You!! What next is the TX2 ready now - or do I need to just boot it ? What do I need to install from the Jetpack ? Everything but the flashing of the TX2 ?

Thanks

Rupert

7

I edited the R24 error :) I had copied from another post on R24.2.1 for TX1 (which is nearly an exact match for flash instructions) and have corrected this for R27.1 on TX2 in the post above.

You just need to boot now. If you have a router watch for the DHCP request to see what address it assigns to the TX2 networking. Local login should also work, but sometimes people have video config issues.

You can run JetPack from a separate host now and tell it the network address for the Jetson and use it to install extra packages (such as CUDA). Just make sure it knows you are talking about a TX2 and don’t check flash…just check the packages you’re interested in. Note that JetPack can install packages to host as well, so double check that the packages you want are checked for the TX2.

8

one more question… upon completion I am asked to Reset the board to boot from internal eMMC.
which buttons do I need to push when booting ? power plus reset ? at teh same time ?

9

If the unit is already on, just the reset button (but try to not do that if the Jetson is already booted and running). If the unit is off, just the power button. Multi-button would only be for going to recovery mode.

10

Thanks. it accepts ping requests but no display … is there some way to telnet/ssh into the TX2
I have a DVI/HDMI connected LCD … that does not display anything (TK1 used to work in this mode) but apparently that has changed Do I need a straight HDMI connection ?

Thanks

Rupert

11

DVI should work so long as it passes through the DDC/EDID wire. Most DVI connectors do, it’s only some cheaper ones for adapting VGA to DVI that do not have this.

You can ssh to that address and log in as “ubuntu” (pass “ubuntu”) or as “nvidia” (pass “nvidia”).

If you can log in via ssh or serial console run this command to see if EDID is working:

sudo cat /sys/kernel/debug/tegradc.1/edid

…should this show data then you have EDID query working. This can be pasted here to see the actual monitor capabilities:
http://www.edidreader.com

12

sorry to be such a pain… so when it boots I get a ping. after a while it stops responding. no ssh to the TX2 is possible. the flash worked perfectly… am I missing anything. when I flashed I pushed the reset button afterwards. With or without pushing the reset button makes no diffference…

here is the output of the flash

[ 27.5811 ] Writing partition mb1 with mb1_prod.bin.encrypt
[ 27.5817 ] […] 100%
[ 27.5927 ] Writing partition spe-fw with spe_sigheader.bin.encrypt
[ 27.6165 ] […] 100%
[ 27.6265 ] Writing partition mb2 with nvtboot_sigheader.bin.encrypt
[ 27.6527 ] […] 100%
[ 27.6626 ] Writing partition mts-preboot with preboot_d15_prod_cr_sigheader.bin.encrypt
[ 27.6941 ] […] 100%
[ 27.7043 ] Writing partition master_boot_record with mbr_1_3.bin
[ 27.7406 ] […] 100%
[ 27.7485 ] Writing partition APP with system.img
[ 27.7526 ] […] 100%
[ 172.5150 ] Writing partition mts-bootpack with mce_mts_d15_prod_cr_sigheader.bin.encrypt
[ 172.5280 ] […] 100%
[ 172.6069 ] Writing partition cpu-bootloader with cboot_sigheader.bin.encrypt
[ 172.6242 ] […] 100%
[ 172.6379 ] Writing partition bootloader-dtb with tegra186-quill-p3310-1000-c03-00-base_sigheader.dtb.encrypt
[ 172.6455 ] […] 100%
[ 172.6599 ] Writing partition secure-os with tos_sigheader.img.encrypt
[ 172.6681 ] […] 100%
[ 172.6779 ] Writing partition eks with eks_sigheader.img.encrypt
[ 172.6832 ] […] 100%
[ 172.6914 ] Writing partition bpmp-fw with bpmp_sigheader.bin.encrypt
[ 172.6962 ] […] 100%
[ 172.7188 ] Writing partition bpmp-fw-dtb with tegra186-a02-bpmp-quill-p3310-1000-c01-00-te770d-ucm2_sigheader.dtb.encrypt
[ 172.7313 ] […] 100%
[ 172.7486 ] Writing partition sce-fw with camera-rtcpu-sce_sigheader.bin.encrypt
[ 172.7593 ] […] 100%
[ 172.7690 ] Writing partition sc7 with warmboot_wbheader.bin.encrypt
[ 172.7755 ] […] 100%
[ 172.7841 ] Writing partition kernel with boot.img
[ 172.7892 ] […] 100%
[ 173.0846 ] Writing partition kernel-dtb with tegra186-quill-p3310-1000-c03-00-base.dtb
[ 173.0947 ] […] 100%
[ 173.1198 ]
[ 173.1221 ] tegradevflash_v2 --write BCT br_bct_BR.bct
[ 173.1240 ] Bootloader version 01.00.0000
[ 173.1263 ] Writing partition BCT with br_bct_BR.bct
[ 173.1269 ] […] 100%
[ 173.1739 ]
[ 173.1806 ] tegradevflash_v2 --write MB1_BCT mb1_cold_boot_bct_MB1_sigheader.bct.encrypt
[ 173.1813 ] Bootloader version 01.00.0000
[ 173.1832 ] Writing partition MB1_BCT with mb1_cold_boot_bct_MB1_sigheader.bct.encrypt
[ 173.1837 ] […] 100%
[ 173.2310 ]
[ 173.2311 ] Flashing completed

[ 173.2312 ] Coldbooting the device
[ 173.2333 ] tegradevflash_v2 --reboot coldboot
[ 173.2354 ] Bootloader version 01.00.0000
[ 173.2418 ]
*** The target t186ref has been flashed successfully. ***
Reset the board to boot from internal eMMC.

thanks

Rupert

13

I have done above procedure at least 10 times now. I cannot access the TX2 via an HDMI connected monitor. I cannot ssh to the TX2 although for varying periods after boot it can be pinged. After some time it disappears from ping and cannot be reached. I am afraid there is a problem with the board ?

Any other suggestions ?

Thanks Rupert

14

I had the same problem with my brand-new board. I’ve started a topic https://devtalk.nvidia.com/default/topic/1002066/jetson-tx2/development-board-does-not-boot/.

15

This still sounds like a video configuration issue. Disconnecting/reconnecting the monitor is a good test.

There are several reasons why ssh might fail even if the system works, e.g., keys changing for that IP address (having used that account name at that IP before memorizes a key and ssh doesn’t like to see that change), router issues, or firewall issues.

By far the best way to gather more information now is a serial console. The TX2 has the same serial console as the TX1, but you’d only use software flow control (not CTS/DTS), which in turn means you only need the GND, TX, and RX wires. See:
[url]http://elinux.org/Jetson/TX1_Serial_Console[/url]
[url]http://www.jetsonhacks.com/2015/12/01/serial-console-nvidia-jetson-tx1/[/url]