Hi Dakow,
Can you try @business14 #19 comments?
Install python 2.7 on host. Thanks!
Hi,
I have already Python on my host :
dev@dev-robot-2:~$ aptitude show python2.7
Package: python2.7
State: installed
Automatically installed: no
Multi-Arch: allowed
Version: 2.7.12-1ubuntu0~16.04.4
Priority: optional
Section: python
Maintainer: Ubuntu Core Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Architecture: amd64
Uncompressed Size: 358 k
Depends: python2.7-minimal (= 2.7.12-1ubuntu0~16.04.4), libpython2.7-stdlib (= 2.7.12-1ubuntu0~16.04.4), mime-support
Suggests: python2.7-doc, binutils
Conflicts: python-profiler (<= 2.7.1-2), python-profiler:i386 (<= 2.7.1-2), python2.7:i386
Breaks: python-virtualenv (< 1.7.1.2-2~), vim-athena (< 2:7.3.547-4), vim-athena:i386 (< 2:7.3.547-4), vim-gnome (< 2:7.3.547-4), vim-gnome:i386 (< 2:7.3.547-4), vim-gtk (< 2:7.3.547-4), vim-gtk:i386 (< 2:7.3.547-4), vim-nox (<
2:7.3.547-4), vim-nox:i386 (< 2:7.3.547-4), python-virtualenv:i386 (< 1.7.1.2-2~), python-virtualenv:arm64 (< 1.7.1.2-2~)
Replaces: python-profiler (<= 2.7.1-2), python-profiler:i386 (<= 2.7.1-2), python2.7-minimal (< 2.7.3-7~), python2.7-minimal:i386 (< 2.7.3-7~)
Provides: python2.7:any (= 2.7.12-1ubuntu0~16.04.4)
Description: Interactive high-level object-oriented language (version 2.7)
Python is a high-level, interactive, object-oriented language. Its 2.7 version includes an extensive class library with lots of goodies for network programming, system administration, sounds and graphics.
dev@dev-robot-2:~$ python -V
Python 2.7.12
I can confirm that my device is in recovery mode properly (I check with lsusb and the
TX2-connected display doesn’t show Linux boot).
lsusb isn’t enough to check whether the Jetson system is correctly in recovery mode, although it is a pre-requisite for lsusb to show the Jetson device.
The reason is that when Tegra enters recovery mode, the first communication with the host is for Tegra to send some specific piece of data, without even waiting for the host to request it. Our tegrarcm tool expects waits this data to be sent when it first connects to Tegra. If Tegra doesn’t sent the data, tegrarcm times out. Once Tegra has sent the data the first time, it never sends it again, and there’s no way for the host to request it again. The only way for Tegra to send it again is to reset (or power off/on) Tegra. Thus, tegrarcm will always fail unless you reset Tegra (and entered recovery mode again) between invocations.
(Will take a look at your log file in detail in a minute…)
Looking at the log file in comment 20, it does seem like the very first read from the Tegra USB device timed out. The most likely cause is that something had previously communicated with Tegra between when it first entered recovery mode and when tegrarcm_v2 was run. Please try resetting or power cycling Tegra and re-entering recovery mode, then see if tegrarcm_v2 works as expected or not. If resetting Tegra and re-entering recovery mode doesn’t help, then something else is going on which I don’t understand.
hi, Dakow/carolyuu
sorry for late reply,
Looks you boot into recovery mode success!
At this time to flash image via sdkmanager, you got “SDK Manager - Could not detect target hardware” error message on SDK manager?
Please print screen and attache the logs, we can check issue first. Thanks!
In my case, there is no “SDK Manager - Could not detect target hardware” dialog
SDKM_logs_JetPack_4.2_Linux_for_Jetson_TX2_03292019_1448.zip (376 KB)
Hi s_ajisaka,
Are you completed initial setup process and select username/password for the Jetson system?
(Please plug-in HDMI cable to completed initial setup process)
After Jetson system boots to Linux desktop, try to install SDK components again.
Hi StephenWarren,
So now with resetting multiple times I get the UUID :
dev@dev-robot-2:~/nvidia/nvidia_sdk/JetPack_4.2_Linux_P3310/Linux_for_Tegra$ sudo ./bootloader/tegrarcm_v2 --uid
BR_CID: 0x81801001645102811c00000017fb0280
But, with resetting again and launching the flash command, I have a “never ending loop” during the command tegrarcm_v2 --isapplet and tegradevflash_v2 --iscpubl.
http://data.aidactif.fr/note/1118/raw/
Searching for this error, I found the usuals answers: don’t use a vm, check the host disk space, use another usb port, use ubuntu 16.04. None of them worked.
Thanks for your help!
Dakow,
I am not sure what’s happening in your case. Your log is identical to mine (except for timestamps and paths) right up to the invocation of “tegrarcm_v2 --isapplet”. For some reason, that is failing to communicate with Jetson even though the previous communication to download the board ID EEPROM worked perfectly.
Things to try:
- Disconnect absolutely all HW from Jetson; leave nothing but the power cable and USB flashing cable installed.
- Make sure you only press the recovery button when entering recovery mode (i.e. when resetting or power cycling Jetson); don’t leave it pressed after that.
- Download a fresh copy of the the L4T SW from Jetson Download Center | NVIDIA Developer, re-extract it, and try flashing from that. Just maybe your current copy got corrupted on disk somehow?
If those don’t help, I don’t currently know what’s going on.
Hi Dakow,
Have you tried our suggestion at previous comments?
Any result can be shared?
Thanks
Hi kayccc,
I’ve tried and it didn’t work. So, I’ve filled a RMA with my supplier.
Hi everyone,
I have a similar problem.
Got a college project and somehow one of the TX1 we have crashed while installing some packages (pytorch). Now the TX1 wont boot, gets stuck while displaying the boot message logs with some “FAILED” indicators.
Im trying to flash it with the SDK Manager but I get the message:
“Could not detech Nvidia Jetson device connected to USB”
Tried the lsusb cmd in my host ubuntu pc but the “0955:7721” Nvidia Corp. doesnt show up.
Any help please? I suspect the cable I’m using isnt the correct one
Hi carolyuu,
Thanks for the help
Im at …/nvidia_sdk/ and have 3 folders:
-JetPack_3.3.1_Linux_GA_P2180
-JetPack_4.2.2_Linux_GA
-GetPack_4.2.2_Linux_GA_P2180
I dont want to flash TX2 but TX1
Hi psmosquera,
The P2180 is for TX1, you can try the latest JetPack-4.2.2 version.
Do you happen to have the modemmanager package installed? I know that does probe some devices when they appear, but I wouldn’t expect it to probe Jetson due to the type of USB device it is. However, perhaps that is happening after all. Try uninstalling modemmanager and rebooting.
The following steps might help find out what process, if any, is opening the USB device prior to the NV flashing scripts:
- Install audit utilities, if not already installed:
sudo apt install auditd
-
Turn off the Jetson device, or unplug it from the host.
-
Run the following commands to set up system call auditing:
sudo auditctl -a exit,always -F arch=b64 -S open -F dir=/dev/bus/usb
sudo auditctl -a exit,always -F arch=b32 -S open -F dir=/dev/bus/usb
-
Power on the Jetson device or plug it into the host. Place it into recovery mode.
-
Wait for a few seconds; long enough for the time window mentioned in comment 35 to expire.
-
Disable system call auditing to avoid filling up your system logs:
sudo auditctl -d exit,always -F arch=b32 -S open -F dir=/dev/bus/usb
sudo auditctl -d exit,always -F arch=b64 -S open -F dir=/dev/bus/usb
- View the system call audit log:
sudo aureport -s --interpret | grep open
Note: These instructions were generated on Ubuntu 16.04, but I expect them to work on 18.04 too.
This is unlikely to have any effect on flash. The last time I ran into a colord-sane issue was when being warned that the settings in my home directory did not have default SElinux labels (the printer color profile was installed separately via some Xerox software on a different Linux distribution, but the SElinux was also not enforcing for that label…nor will it be an issue in Ubuntu).
Printing/scanning color profiles won’t have any effect on the flash software (and this is what colord-sane is).
It is worth noting that the actual rootfs being flashed to the Jetson also does not have SElinux labels and the Jetson itself is not set up to be SElinux enforcing and is very unlikely to have any effect on flash unless a very large number of SElinux errors start flooding the logs.
I don’t know enough about the system calls for SDKM to be able to say. Certainly an “open” to tegrarcm_v2 is not an issue, this is a fairly standard system call and is not an error. Typically an error might be something like a service or file being denied due to permission. The udev events are likely involved in finding the USB device, but I have no idea if the unset is a problem or not…in normal operation set and unset would occur a lot, but only if you knew what was running inside of SDKM would it be possible to say that this is good/bad/indifferent. My gut feeling is that this is not an error, but normal operation.
Re: comment 42:
I don’t see anything in the log to explain the problem. The open/tegrarcm_v2 log entries are all from the flashing process itself, so should not be an issue. None of the other system calls should have caused a problem.
I assume that you:
a) Stopped colord before plugging the Jetson into the host or before forcing it intro recovery mode.
b) Started the audictl capture before plugging the Jetson into the host or before forcing it intro recovery mode.
I can’t reproduce this problem on a freshly installed “Ubuntu 18.04.2 amd64 desktop” system, before or after installing all updates.
Perhaps you’ve installed some non-default software that causes this issue. Could you please run the following commands and attach the output (or use pastebin). Thanks.
apt-mark showmanual
dpkg -l
Also, have you installed any software manually (i.e. not using Ubuntu’s standard package sources and tools)? Often, commercial software, or the latest builds of OSS software, will have you download a package or tar file and manually install it; any software might potentially include udev rules that might be related to this issue.