After an exhausting number of iterations changing USB minicables etc, version of the Host OS 14.04 and 16.04
(non-VM) I gave up trying to flash the jetson from the host and decided to backup the jetson SSD on an SD card.
I made a complete copy of the jetson-tx2 internal ssd on an 64GB SD card and successfully booted multiple times from it.
I tried to erase and reformat the internal SSD but during the process there was a power outage that left the drive in an unrecoverabele state. Here is the boot log from the serial device.
[0000.262] I> Welcome to MB2(TBoot-BPMP)(version: 01.00.160913-t186-M-00.00-mob)
[0000.271] I> Default Heap @ [0xd486400 - 0xd488400]
[0000.275] I> DMA Heap @ [0x84900000 - 0x85300000]
[0000.280] I> bit @ 0xd480000
[0000.283] I> BR-BCT relocated to 0xf7f20000
[0000.287] I> Boot-device: eMMC
[0000.291] I> pmic: reset reason (nverc) : 0x44
[0000.295] I> Reading GPT from 512 for device 00000003
[0000.301] I> Reading GPT from 8388096 for device 00000003
[0000.308] I> Found 6 partitions in 00000003 device
[0000.313] I> Reading GPT from 512 for device 00010003
[0000.319] I> Reading GPT from 31268535808 for device 00010003
[0000.326] W> Cannot find any partition table for 00010003
[0000.331] E> tegrabl_partition_publish: exit error = 6834001
[0000.337] W> No valid slot number is found in scratch register
[0000.343] W> Return default slot: _a
[0000.346] I> A/B: bin_type (16) slot 0
[0000.350] I> Select partition: bpmp-fw
[0000.353] I> Loading partition bpmp-fw at 0xf7600000
[0000.358] W> Partition bpmp-fw not found
[0000.362] E> Failed to load binary(16)
[0000.365] C> ERROR: Highest Layer Module = 0x1d, Lowest Layer Module = 0xd,
Aux Info = 0x0, Reason = 0xd
[0�[0000.240] I> Welcome to MB2(TBoot-BPMP)(version: 01.00.160913-t186-M-00.00-)
Right now the jetson is bricked. I tried reflashing it through the miniusb with multiple cables and it fails. It could be booted from the backup sd card except the boot record on the internal ssd has been erased. Is there a way to restore or rebuild the internal ssd or force the jetson to boot from the SD card? perhaps using some variation of flash.sh ? Help would be greatly appreciated.
After an exhausting number of iterations changing USB minicables etc, version of the Host OS 14.04 and 16.04
(non-VM) I gave up trying to flash the jetson from the host and decided to backup the jetson SSD on an SD card.
developer2@superquantan:~$ uname -ar
Linux superquantan 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
developer2@superquantan:~$ lsusb
Bus 001 Device 004: ID 0955:7c18 NVidia Corp.
Bus 001 Device 007: ID 046d:082d Logitech, Inc. HD Pro Webcam C920
Bus 001 Device 005: ID 05ac:921c Apple, Inc. A1082 [Cinema HD Display 23"]
Bus 001 Device 003: ID 05ac:911c Apple, Inc. Hub in A1082 [Cinema HD Display 23"]
Bus 001 Device 002: ID 148f:5372 Ralink Technology, Corp. RT5372 Wireless Adapter
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
developer2@superquantan:~$ lsusb -d 0955:7c18
Bus 001 Device 004: ID 0955:7c18 NVidia Corp.
developer2@superquantan:~$ cd jetson-downloads
developer2@superquantan:~/jetson-downloads$ ./JetPack-L4T-3.2-linux-x64_b196.runCreating directory _installer
Verifying archive integrity… All good.
Uncompressing JetPack 100%
###############################################################################
Error: probing the target board failed.
Make sure the target board is connected through
micro-B USB port and is in recovery mode.
developer2@superquantan:~/jetson-downloads$
On your host try monitoring “dmesg --follow”. Look for anything which might relate to USB device enumeration or configuration…see if there is some evidence of change during the flash.
FYI, the lsusb should validate having the device connected correctly, but some third party cables of this type were intended only for charging and have rather low quality. You’re always better off using the supplied cable, or at least being suspicious of alternate cables if flash fails despite having seen lsusb. In every case of a VM one would have to know 99% of those issues are caused by the VM. Unusual installs with a non-VM might also be an issue, e.g., running on a live DVD.
If this still fails and there is no clue I’d recommend attempting a command line flash. Does the dmesg information show any clues?
I am using the nvidia supplied cable that came with the jetson-tx2 (i also have tried other cables). I am using a machine based Ubuntu 16.04 version (t is not running under a VM or from a live DVD)
Here is the tail of the dmesg output:
[ 131.708717] ISO 9660 Extensions: RRIP_1991A
[ 185.828016] usb 1-6: new high-speed USB device number 7 using ehci-pci
[ 185.960767] usb 1-6: New USB device found, idVendor=0955, idProduct=7c18
[ 185.960771] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 185.960775] usb 1-6: Product: APX
[ 185.960778] usb 1-6: Manufacturer: NVIDIA Corp.
[ 186.560377] [UFW BLOCK] IN=eth2 OUT= MAC= SRC=fdd8:2d95:156e:0000:021b:21ff:fe6b:51f0 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=64 TC=0 HOPLIMIT=1 FLOWLBL=101738 PROTO=UDP SPT=8612 DPT=8612 LEN=24
[ 186.560415] [UFW BLOCK] IN=eth2 OUT= MAC= SRC=fdd8:2d95:156e:0000:021b:21ff:fe6b:51f0 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=64 TC=0 HOPLIMIT=1 FLOWLBL=304492 PROTO=UDP SPT=8612 DPT=8610 LEN=24
[ 186.560437] [UFW BLOCK] IN=eth2 OUT= MAC= SRC=2600:1700:8f20:23b8:021b:21ff:fe6b:51f0 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=64 TC=0 HOPLIMIT=1 FLOWLBL=1014684 PROTO=UDP SPT=8612 DPT=8612 LEN=24
[ 186.560458] [UFW BLOCK] IN=eth2 OUT= MAC= SRC=2600:1700:8f20:23b8:021b:21ff:fe6b:51f0 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=64 TC=0 HOPLIMIT=1 FLOWLBL=449423 PROTO=UDP SPT=8612 DPT=8610 LEN=24
[ 186.560479] [UFW BLOCK] IN=eth2 OUT= MAC= SRC=fe80:0000:0000:0000:021b:21ff:fe6b:51f0 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=64 TC=0 HOPLIMIT=1 FLOWLBL=926078 PROTO=UDP SPT=8612 DPT=8612 LEN=24
[ 352.669661] nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.
[ 356.006705] audit: type=1400 audit(1521066538.495:40): apparmor=“DENIED” operation=“open” profile=“/usr/sbin/mysqld” name=“/proc/6306/status” pid=6306 comm=“mysqld” requested_mask=“r” denied_mask=“r” fsuid=117 ouid=117
[ 356.006751] audit: type=1400 audit(1521066538.495:41): apparmor=“DENIED” operation=“open” profile=“/usr/sbin/mysqld” name=“/sys/devices/system/node/” pid=6306 comm=“mysqld” requested_mask=“r” denied_mask=“r” fsuid=117 ouid=0
[ 356.006812] audit: type=1400 audit(1521066538.495:42): apparmor=“DENIED” operation=“open” profile=“/usr/sbin/mysqld” name=“/proc/6306/status” pid=6306 comm=“mysqld” requested_mask=“r” denied_mask=“r” fsuid=117 ouid=117
[ 369.276212] Ebtables v2.0 registered
There does not appear to be anything out of the ordinary.
I have already attempted a command line flash (numerous times) and get the same result. I have tried other cables. The ssd on the jetson TX2 cannot boot. Is there any way I can boot from the sd card that has the backup image? A s there is no access to the ssd I cannot edit the extlinux.conf file on the ssd nor does the jetson tx2 have an IP address. can I reflash the ssd in some other way? I am open to creative solutions.
This is indeed as expected and without error so far as detection goes. So far as USB is concerned this flash should work if not on a VM (you’ve said before it isn’t a VM…I tend to reiterate this because of other people with flash problems).
An SD card could boot if there is no failure in the boot code. The way it works is that during U-Boot there are some variables which by default try looking for various bootable devices. One is the SD card slot where it looks for a rootfs on the first GPT partition (“/dev/mmcblk1p1”). If you have a rescue set up on the SD card it might work. However, the “/boot” will still be from the eMMC, and so if that boot partition is gone it won’t help.
Do you still have from a previous flash the “Linux_for_Tegra/bootloader/system.img.raw” file? If so, then this would be an excellent rescue system.
Unfortunately, as stated above, I cannot access the /boot or any other directory on the SSD. I don’t care about rescuing the old system, just getting the system to boot. I do have the system.img.raw form the L4T3.2 18.2 build that I was trying to flash on the SSD. The problem is that when I try to flash there is no recognition from my 16.04 non-vm host of the USB connection even though NVIDIA shows up with on the lsusb command. I am using the nvidia supplied cable.
Questions:
Are the ant diagnostic utilities that I can run from the 16.04 host that can provide debugging information for the USB connection problem?
Is there a way to flash a new image from the serial port?
How does NVIDIA create the SSD? There must be a NVIDIA utility way to do this progammatically (I can write code in any language)?
3.My host PC has usb 2.0, the board has us b3.0. I am aware the usb 3.0 is backwards compatible with 2.0. Are their bugs in the L4T 3.2 18.2 USB device driver that can cause a compatibility problem?
Clone does not require writing, it only reads. How this behaves can be a clue. Beware you’ll need over 30GB of space to clone if it works. You could log a clone attempt:
During flash the eMMC is written from the driver package on the host PC when the Jetson is in recovery mode. During recovery mode the Jetson becomes a custom USB device instead of being a host. fastboot is loaded into RAM on the recovery mode Jetson, and this has the ability to write to eMMC via use of USB as a serial data line. flash.sh is the front end to the actual flash program and I know of no other way to do this. On R28.1 “bootloader/tegraflash.py” seems to be what is used…you might want to explore this to see what it does (in some previous releases this was an x86_64 binary executable).
Only the full-size type-A port is wired for USB3. The micro-OTG port is wired for USB2. USB3 cannot be used to flash (unless the host port reverts to USB2…and it should…if it doesn’t, then this would account for failure).
The USB3 mode will be unrelated to flash or clone. U-Boot has its own USB2 driver separate from Linux. When Linux runs this port as USB3 all devices on that port must re-enumerate during the transition from U-Boot USB2 to Linux USB3. Since flash uses the micro-OTG port it isn’t possible for USB3 to be of any consequence during flash or clone.
###############################################################################
Error: probing the target board failed.
Make sure the target board is connected through
micro-B USB port and is in recovery mode.
Thanks for the analysis. Before the system crashed it was on 27.1. I will try to go back to that release and recreate the drive with the 27.1 utilities and provide an update when I’m done.
Here is the ouput of the 27.1 install . It hangs after the last message with no i/o or signifcant CPU actvity on the host:
./tegraflash.py --chip 0x18 --applet “/home/developer2/jetson-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.0023 ] Generating RCM messages
[ 0.0259 ] tegrarcm_v2 --listrcm rcm_list.xml --chip 0x18 --download rcm /home/developer2/jetson-downloads/64_TX2/Linux_for_Tegra_tx2/bootloader/mb1_recovery_prod.bin 0 0
[ 0.0272 ] RCM 0 is saved as rcm_0.rcm
[ 0.0525 ] RCM 1 is saved as rcm_1.rcm
[ 0.0525 ] List of rcm files are saved in rcm_list.xml
[ 0.0525 ]
[ 0.0529 ] Signing RCM messages
[ 0.0548 ] tegrasign_v2 --key None --list rcm_list.xml --pubkeyhash pub_key.key
[ 0.0563 ] Assuming zero filled SBK key
[ 0.0616 ]
[ 0.0616 ] Copying signature to RCM mesages
[ 0.0630 ] tegrarcm_v2 --chip 0x18 --updatesig rcm_list_signed.xml
I can’t guarantee it, but it seems likely at this point there was damage from the power out. Given that your host is a regular install and nothing special is going on, and with the various tests, odds are in favor of hardware failure. It seems USB is talking to the Jetson, but other than the Jetson having a USB pipe, it isn’t talking back. If interested in RMA, the information is near the top of this:
[url]https://devtalk.nvidia.com/default/topic/793798/embedded-systems/some-jetson-web-links/[/url]
Without recovery mode I see no way to re-install the necessary software.
I have exactly the same problem - Jetson TX2 is in recovery mode, shows up on lsusb; LINUX MATE 16.04 on Macbook air; no VM. Jetpack LT4 3.2 Message as stated - will not flash device!!!
@zilles, do you have a log of the flash? Note that a clone could be used as a test of ability to read, which is probably more basic than flashing. You would not need to complete the clone (it can take hours and many many gigabytes of disk space), but if cloning could run (or not) for a few minutes then you’d have good data.
One thing to verify: Is the file system type on the host ext4? You can cd to where the flash is, and run “df -H -T .” and see what shows up (the “.” means “current directory”).