Hello. I have a Jetson TK1 Development Kit board.
I use it well without any problems.
But when I was trying to upgrade TK1, I pushed ‘FORCE RECOVERY’ and ‘RESET’ buttons.
After then, if I connect power, a light and a fan is operating but no response with monitor…
Just ‘No signal’ message on the monitor…
Has anyone come across the same issues?
You may read this thread: [url]https://devtalk.nvidia.com/default/topic/923782/?comment=4956178[/url]
The Jetson is probably running ok, but video not configured (the above URL is a detailed reference into explaining that). If you have ssh access or serial console (the 9-Pin D-Sub connector at 115200 8N1 settings) you’ll be able to verify.
@ I have a RS232 serial cable.
If I connect it to borad and lauch the serial monitoring program, than some message which indicate my borad staus will show up?
I very begginer of this kind of system…
Yes, think of serial console as a driver that has no requirements…it’s only a series of characters, there isn’t much needed for it to work even when all else is crashed and burning. During boot there are log messages to console…regular console would get that too, but it isn’t started fast enough…and then it can be used as a login shell.
Your terminal program would need to be set to speed 115200, 8 bits, No parity, 1 stop bit. This is fairly standard, or “115200 8N1”. You can use “software flow control”, which ignores the CTS/RTS lines, but using CTS/RTS flow control setting may be more reliable under some circumstances. Programs like minicom (or my favorite, “gtkterm”) let you set those. Once it works, you should just see output as the Jetson turns on (even if the Jetson never really finishes booting, it should say something useful). Plus, the serial console program can usually be told to log (and this is to your working host).
linuxdev Thank you for your reply!!
I connected serial port only 2,3,5 pin(rx,tx,gnd) and I got a result from serial program.
U-Boot SPL 2014.10-rc2-g3127911 (Jun 07 2016 - 21:00:01)
U-Boot 2014.10-rc2-g3127911 (Jun 07 2016 - 21:00:01)
TEGRA124
Board: NVIDIA Jetson TK1
I2C: ready
DRAM: 2 GiB
MMC: Tegra SD/MMC: 0, Tegra SD/MMC: 1
*** Warning - bad CRC, using default environmenttegra-pcie: PCI regions:
tegra-pcie: I/O: 0x12000000-0x12010000
tegra-pcie: non-prefetchable memory: 0x13000000-0x20000000
tegra-pcie: prefetchable memory: 0x20000000-0x40000000
tegra-pcie: 2x1, 1x1 configuration
tegra-pcie: probing port 0, using 2 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: 2 1 0
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0…
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
827 bytes read in 169 ms (3.9 KiB/s)
Jetson-TK1 eMMC boot options
1: primary kernel
Enter choice: 1: primary kernel
Retrieving file: /boot/zImage
6133680 bytes read in 190 ms (30.8 MiB/s)
append: console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt
Retrieving file: /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb
59661 bytes read in 73 ms (797.9 KiB/s)
Kernel image @ 0x81000000 [ 0x000000 - 0x5d97b0 ]Flattened Device Tree blob at 82000000
Booting using the fdt blob at 0x82000000
Using Device Tree in place at 82000000, end 8201190cStarting kernel …
I wait a hour but nothing going to change…External Media
Ok, so the hardware itself is working and the boot loader (U-boot) did what was needed. The place it fails at is loading the kernel (when the kernel loads the bootloader is overwritten…looks like there was nothing to load bytes from). Whatever kernel it is trying to load, nothing is happening. This could be a bad configuration, or something corrupt in the kernel image…the flash was not entirely correct, but your Jetson is otherwise ok.
So I’d start by looking at what data your flash was trying to use to create the rootfs partition. The background is that when you flash you have a rootfs directory, and the content of that plus some boot edits are what make up the root partition. If sample rootfs was unpacked incorrectly there, then you would expect this failure. If the apply_binaries.sh step was done wrong, then the failure would have been later on, not here. In the case of using JetPack those steps are performed by JetPack instead of command line, but really, there is no difference.
If you did not have enough disk space, then things would go bad and perhaps something like this could happen. Was your flash via JetPack, or by command line? When you go to the install area and cd into the rootfs subdirectory, what is the output of “df -H -T .”?
You will also have subdirectory “bootloader” on your host. Within that, what is the output of “ls -l system.img*”?
linuxdev
Using micro usb, I conneted it with my labtop.
And then, I did restart as nvidia docs mention.
So everything OKAY now. Thanks a lot.
But I have a simple question about your commnets.
Why “fails at is loading the kernel” is happen?
The filesystem automatically change when hit the RECOVERY button??
Thank you.
Normally the USB connector on the Jetson is “host” mode…you can plug in USB “devices”, e.g., mouse or keyboard. In recovery mode the Jetson instead becomes a “device”…suddenly other computers can see the Jetson the same way as a keyboard or mouse, rather than the Jetson being a host. Keyboard and mouse are standardized device classes, so any host knows how to use them; a recovery mode Jetson is a custom USB device…the driver is the flash software running on the host. Recovery mode does nothing to alter the Jetson in any permanent way (being in recovery mode does not change or flash the Jetson)…but it does make the Jetson visible to flash software which can and does alter the Jetson (unless you flash recovery mode won’t ever change the Jetson).
When you go to flash there are roughly speaking two things which are updated: One is the boot loader and infrastructure to start an operating system…the other is the root partition via the sample rootfs and apply_binaries.sh step…this latter is the part you know as Ubuntu or the operating system. The former is by default standardized, the latter is customizable. Boot loader starts things up which are critical to the system having a possibility of software running, e.g., it starts power regulators in the correct order, sets up clocks, and primes the memory controller. Once the boot loader does this, it jumps to the address of the Linux kernel file and overwrites itself with that file. In your case the file system could be accessed, but whatever was in your named kernel was not really a kernel, or perhaps there was nothing there at all (a missing file or an invalid file could be considered the same thing).
Since boot loader is more or less standardized, and because the root file system with the kernel image requres the user to set this up (the user might include the JetPack software, or manual commands on command line if not using JetPack…see apply_binaries.sh and unpacking sample rootfs), it is highly likely that you flashed the Jetson with the rootfs having not been put in place. Did you flash using command line? Before flash, did you unpack sample rootfs into the rootfs directory, then run apply_binaries.sh (all using sudo)? If flashing manually, what was your actual flash command (and did you use sudo)? Does your host have the “rootfs/boot/Image” file?
Actually, things happened before I has downloaded file system and driver package for updating latest L4T.
It means I have any single chance to apply apply_binaries.sh or unpacking sample rootfs… so strange.
As I told you first time it just happened when I hit the recovery button and reset button same time.
Thanks to your help, now everything works well. HDMI okay, file system okay.
If hitting recovery and reset fails to put the Jetson in recovery mode there is a problem. If putting a Jetson in recovery mode ever has an effect after resetting power, then this too is a problem…simply going to recovery mode (or hitting the buttons) should never change the Jetson’s future operation. You could of course shut down a Jetson or any Linux system improperly from normal run state and corrupt the eMMC, but that’s a different topic.
You can flash a second time without repeating several of the steps…once you’ve unpacked sample rootfs and hit apply_binaries.sh once you don’t need to do it again. It doesn’t hurt to run apply_binaries.sh again if you are not sure it was correct (just make sure you use sudo).
Hi.
I have the same problem. How did you solve it? How did you restart as nvidia docs mention? I could not find any solution. Thank you.
Hello,
I have same problem as. How should I restart and solve the issue? Thank you
You have to make sure that the TK1 can reach recovery mode. If this can’t be achieved, then some very basic functionality is missing. Really a serial console log is mandatory to know what is going on during a boot, and if only video fails, then nothing can be concluded. Are you able to use a serial console?
Also, is the monitor purely HDMI without any adapters?
What were your actual steps to go to recovery mode and to see that this was or wasn’t working?
Thank you for your reply linuxdev. Now I am using purely HDMI ( before I was using hdmi to vga), now my jetson-tk1 open up but the problem is that I can not access my ubuntu and the monitor is shown in the attachment image file.
This appears to be a software issue, as the kernel is giving errors. You can use serial console and get a full log…the content prior to the error is more important than the long error list.
If you have an RS232-to-USB cable it is fairly simple. The settings would be 115200 8N1, with or without CTS/RTS flow control. If for example you have an FTDI based USB-to-RS232 cable, then your host should have the driver by default, and plugging in the USB side to the host would give you something like “/dev/ttyUSB0” (a different number if you have another serial USB cable). Then, with something like “gtkterm”, you can run:
gtkterm -b 8 -t 1 -s 115200 -p /dev/ttyUSB0
Some people use minicom. Any such application will be able to log whatever scrolls by, and logging will begin even before the Linux kernel loads.
In the case of a software error like this it is very likely the answer will be to flash the Jetson to get a clean install. If you do not have the serial cable, then this is about the only possibility if you can’t use ssh to log in (can you ping the TK1 over the network?). The serial console functions even when much of the rest of the system is long dead. If there is something like a simple file issue, then serial console (or ssh if it works) could lead to a very simple solution.
Questions: