I am working with the Jetson TX1. I have tried flashing the device multiple times with jetpack and with
sudo ./flash jetson-tx1 mmcblk0p1
When it goes to reboot it gets caught in the bootloader.
Probably not related, but maybe? [url]https://devtalk.nvidia.com/default/topic/935734/jetson-tx1-won-t-flash-not-entering-recovery-mode-won-t-boot-brick/[/url]
In the end changing USB ports / cable during flash MAY have been the culprit… but to this day still not sure.
Are you using serial console to know it is caught in boot loader? What’s the last few lines of output before it stops?
I am using serial console.
This is the output I get during the boot process.
I found other threads with a similar output, but none of those solutions worked.
U-Boot 2015.07-rc2-geea3f71 (Feb 08 2016 - 17:37:49 -0800)
TEGRA210
Model: NVIDIA P2371-2180
DRAM: 4 GiB
MMC: Tegra SD/MMC: 0, Tegra SD/MMC: 1
*** Warning - bad CRC, using default environment
tegra-pcie: PCI regions:
tegra-pcie: I/O: 0x0000000012000000-0x0000000012010000
tegra-pcie: non-prefetchable memory: 0x0000000013000000-0x0000000020000000
tegra-pcie: prefetchable memory: 0x0000000020000000-0x0000000040000000
tegra-pcie: 4x1, 1x1 configuration
tegra-pcie: probing port 0, using 4 lanes
tegra-pcie: link 0 down, retrying
tegra-pcie: link 0 down, retrying
tegra-pcie: link 0 down, retrying
tegra-pcie: link 0 down, ignoring
tegra-pcie: probing port 1, using 1 lanes
tegra-pcie: link 1 down, retrying
tegra-pcie: link 1 down, retrying
tegra-pcie: link 1 down, retrying
tegra-pcie: link 1 down, ignoring
In: serial
Out: serial
Err: serial
Net: No ethernet found.
Hit any key to stop autoboot: 0
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
starting USB...
USB0: USB EHCI 1.10
scanning bus 0 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
scanning usb for ethernet devices... 0 Ethernet Device(s) found
USB device 0: unknown device
No ethernet found.
missing environment variable: pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm-tegra210
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default
No ethernet found.
Config file not found
No ethernet found.
I have an NVIDIA Jetson TX1 laying on my desk for already a week; there’s no way I can make it to work.
It was supposed to be preloaded with an OS. It doesn’t simply starts up. No signs of life even in the keyboard.
I installed all the software in my linux distribution, tried to flash the TX1. I managed to recognise the device as a storage (15GB) device. I connect it to my network and I actually managed to find the IP, but when I try to log in, it says the credentials are not correct (aren’t they supposed to be ubuntu ubuntu?).
Besides, I just received one wifi antenna.
Is there any chance to have a summary of the booting issues and a sort of guide to resolve it?
@falcoj: The serial console output indicates it cannot read the “/boot/extlinux/extlinux.conf” file. The flash process may have failed, but because Jetson is searching for boot information, this is likely from the flash host side being an issue. Manually running “flash.sh” requires doing so as root, otherwise loopback devices can’t be created and files being copied can’t have root permissions, so on. Did you run flash.sh with root authority, e.g., via sudo? Is the flash host a VM or real machine? Flash would be something like this:
sudo ./flash.sh -S 14580MiB jetson-tx1 mmcblk0p1
@maykef: lsusb will recognize a Jetson as a flashable device, but it should never show as storage, the Jetson itself is incapable of doing so without significant modification (recovery mode turns Jetson into a custom USB device understood only by the flash software). The ping indicates that the device is in fact running. There are known video issues dependent upon monitors, so I wouldn’t assume lack of video means it isn’t running.
Regarding network login, there are two areas of weakness. The first is that if ssh connected once, then the keys are memorized and trying to use a different key causes connection to be refused. Flashing something can in fact change an ssh key at one end, requiring removal of the other end’s idea of the memorized key.
Credentials not being correct, if referring to login name/pass, might be a security issue. Jetson is a full computer, and ubuntu/ubuntu is a known standard password which would get hacked quite fast if you expose the Jetson to a public network without some sort of protection. If you have your own router, this should be sufficient…if you are connected to a public router, e.g., from dorm rooms at a university where students can see each others computers, then you have to either firewall or change the password immediately (it would get especially interesting if more than one student had a Jetson identifying itself as “tegra-ubuntu”…which Jetson would respond?). You could flash Jetson again if password is the cause, you could remove memorized keys from “~/.ssh/known_hosts” if keys are mismatched.
In terms of video what is the exact cabling type, including any adapters? The old 15-pin VGA is guaranteed to fail (in any form, including adapters), as it does not include any ability of the video to query the monitor. Other issues may go away once the full hardware acceleration file set is installed (monitor compatibiility seems to improve), but to do that you either need to flash or access the Jetson as is and run the “sudo ~/NVIDIA-INSTALLER/installer.sh”. If you have a serial console available, this is by far the easiest way to finish install without flash when video fails…if you plan to develop on JTX1 you’ll want one eventually anyway…see:
http://elinux.org/Jetson/TX1_Serial_Console
@linuxdev: I am using a real machine. I have used the following flash commands:
sudo ./flash.sh jetson-tx1 mmcblk0p1
sudo ./flash.sh -S 14580MiB jetson-tx1 mmcblk0p1
sudo ./flash.sh -S 14GiB jetson-tx1 mmcblk0p1
That should work unless the rootfs image generated for the flash had something wrong with it. How much space do you have left on your host, e.g., run “df -H”…I’m wondering if the image was truncated.
This is my output for df -H
Filesystem Size Used Avail Use% Mounted on
udev 8.4G 4.1k 8.4G 1% /dev
tmpfs 1.7G 1.5M 1.7G 1% /run
/dev/sda7 137G 29G 102G 23% /
none 4.1k 0 4.1k 0% /sys/fs/cgroup
none 5.3M 4.1k 5.3M 1% /run/lock
none 8.4G 192M 8.2G 3% /run/shm
none 105M 46k 105M 1% /run/user
/dev/sda6 2.0G 51M 1.8G 3% /boot
@falcoj: 102GB should be significantly more than required. Seeing as the JTX1 can’t read extlinux.conf, it still seems that something went wrong from the host side of the flash. I’m going to suggest you delete the host side Linux_for_Tegra directory and re-download this again. It just seems like something didn’t make its way to the JTX1, but the JTX1 hardware is obviously functioning up until u-boot wants to load something other than itself.
I removed all files related to the TX1 boot process, reinstalled them and flashed again.
I am getting the same error as before.
There is probably some non-obvious detail missing, as what you’ve done so far seems like it should work, and the Jetson serial console output tends to make me believe the hardware itself is functional. So I will ask some details…
What is connected to the Jetson during flash, and after flash completes?
Are you downloading driver and sample rootfs packages individually, or is this part of JetPack?
If flashing without JetPack, have you used root or sudo during unpack of the sample rootfs and the apply_binaries.sh step?
After flash, do you have files (relative to Linux_for_Tegra directory) “bootloader/system.img” and “system.img.raw”? If you have “system.img.raw”, which is the exact byte size of the file?
@falcoj I tend to have to agree with linuxdev on this one. Have you tried a different host machine? I use VirtualBox with ubuntu 14.04 64b with no troubles. This would allow you to maybe eliminate another potential cause. I could pack the VM and send it to you, but it is vanilla ubuntu trust 14.04:
$ uname -a
Linux rex-dev 4.2.0-27-generic #32~14.04.1-Ubuntu SMP Fri Jan 22 15:32:26 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
With the jetpack 2.2 downloaded and installed. Worked fine. Short USB Cable to a USB port and then forwarded that port via the VM to the client OS. Try various ports.
To help verify this:
bootloader$ ls -l system.img*
-rwxr-xr-x 1 root root 2606638772 Jun 20 15:54 system.img
-rw-r--r-- 1 root root 15032385536 Jun 20 15:54 system.img.raw
Also:
bootloader$ md5sum system.img.raw 8e234a080fe98fbcbd02b49ee3c57f74 system.img.raw
bootloader$ md5sum system.img
ff728d1570c0e71c769d908635c985f5 system.img
EDIT: I just remembered that these may differ, as I have recompiled the kernel myself with a base patch applied. I’ll get the stock images and run those for you later!
Just a heads up on why I asked for system.img.raw size…this has to be evenly divisible by 1024. For example, 15032385536 is divisible by 1024 three times in a row, meaning the original image was built with option “-S 14GiB”. The non-raw image is a “sparse” (essentially compressed) image based on the raw image…the 2.6GB is an approximately reasonable sanity check size, but this will vary. Having a valid system.img.raw size means the basics of creating the image was correct.
2534246044 is the size of system.img
15032385536 is the size of system.img.raw
I am downloading the driver and rootfs seperately.
I am following the instructions for flashing here: http://developer.download.nvidia.com/embedded/L4T/r23_Release_v2.0/l4t_quick_start_guide.txt?autho=1466598706_cbe90337b89da3c50826a8a04e254ba8&file=l4t_quick_start_guide.txt
The 15032385536 is a match for “-S 14GiB”, so image size is valid. I would set maximum use of eMMC during flash via:
sudo ./flash.sh -S 14580MiB jetson-tx1 mmcblk0p1
At the location where sample rootfs is installed, be sure it is Linux native file system type, e.g., cd to the sample rootfs unpack location use “df -H -T .”…look for something like ext3 or ext4.
Seems like there was an issue with my host machine. I was able to flash it on a different computer.
I had an issue with the same symptom - the bootloader was unable to read extlinux.conf and the kernel image (or anything else) from the filesystem. The ext4ls command would return garbage. The cause of this was a recent change in e2fsprogs to enable the 64bit feature in /etc/mke2fs.conf by default; the Nvidia flashing toolchain invokes mkfs.ext4 without specifying features, and 64bit ext4 filesystems are not supported by U-Boot.
That’s an interesting catch…the flash.sh script always uses mkfs with whatever defaults the host has. My Fedora has 64-bit set to auto, so I guess that means it uses this option only if a partition exceeds a certain number of blocks for the file system (I can’t verify what size this occurs at for “auto”). I’m uncertain as to how one would force 32-bit, but if there are fewer blocks (larger block size or smaller partition) this might do the trick. Once past the boot loader it wouldn’t matter.