i have try 21.5, 21.6,21.7,but all no output in display!
Please attach your full dmesg here.
i get a new board with L4T 14.1or14.4 ,i want to update system by reboot it with 21.7 L4T.i fellow the step by given.my ubuntu host display success! i reset the board then no sign in display.i used hdmi to VGA connect to my display! then i tried 21.6,21.5.all host display success,but reset board hdmi no output!What should can i do to solve it?dont want to angry my master!
HDMI has a wire which VGA does not have, the “DDC” wire. There is a way for the GPU to query this and get the “EDID” data, which is what tells the video card what the specs of the monitor are. This is the reason HDMI monitors don’t need a “driver disk” like the old VGA did. Without HDMI (or some of the other formats with a means of sending EDID data, e.g., DisplayPort or digital DVI) there is no way for the video to do anything but fall back to some preprogrammed value. Jetsons don’t even have a method to enter display values manually, they rely entirely on EDID. So…you probably need a monitor which provides EDID.
Not all EDID values work, only those from a selected pool (I’m not sure what the pool is, but there are a lot of values in it). The notable exception is that no interlaced modes work. If you monitor is not interlaced, then there is a possibility that if you were to get an active adapter which can be programmed with the EDID of your monitor, then the monitor could work through that adapter. It’s almost always the case that a different monitor is a better choice.
Forgot to mention: Some people hack the default fallback mode in the kernel, but this only works if you know a mode timing that the monitor supports and that timing is within the specs of the mode pool. For example, if the monitor has some odd timing or odd shape, then you couldn’t make it work by inventing modes which don’t exist in the driver pool.
Please try attach your full dmesg here.
I have get a HDMI monitor(LG),and reboot tk1 with L4T 21.7.it still donot work!(no output)other way can i try to solve this problem?
Please try to find out a uart debugger and dump the dmesg…
i do not known how to do it!can you give me some advice to use uart debugger to dump dmesg.my board no output so can i use a UART to usb adapter and a software in my host to dump the dmesg when the board cannot operator because no output in monitor!
Please refer to it.
if before i reboot my board i write this sudo apt-mark hold xserver-xorg-core!it will be the course of it?
FYI, some earlier releases ended up allowing Xorg to be updated with an invalid version for the GPU driver (this is the reason someone might use the apt-mark hold). I think newer releases got around this. The hold of xserver-xorg-core only matters if there is a pending Ubuntu update with a new ABI which would cause the NVIDIA-provided “/usr/lib/xorg/modules/extensions/libglx.so” to be overwritten. A duplicate of this file exists at “/usr/lib/arm-linux-gnueabihf/tegra/libglx.so”, and simply performing a copy (with sudo) from the tegra version into the Xorg location would fix this. Further updates would not impact or overwrite this. Example fix (if this is the case):
sudo /bin/cp -f /usr/lib/arm-linux-gnueabihf/tegra/libglx.so /usr/lib/xorg/modules/extensions/libglx.so
To find out if any NVIDIA-provided driver or library was overwritten:
sha1sum -c /etc/nv_tegra_release
(if the libglx.so does not show as failed checksum, then this was never a problem)
If ssh still works, or serial console, or if CTRL-ALT-F2 gets a console, then the example file copy would fix the video issue. That release of Ubuntu is no longer updated, so if you’ve been through the update break once and put the libglx.so back in, then it shouldn’t happen again and the mark hold would become irrelevant.
Serial console applications (I like gtkterm) can log on the host PC whatever goes on in the terminal connected to the TK1. Just enable logging and run the command “dmesg”. Then disable logging, and you have the file with the log of dmesg on your host.
U-Boot SPL 2014.10-rc2-g751c38c (May 29 2018 - 12:55:11)
U-Boot 2014.10-rc2-g751c38c (May 29 2018 - 12:55:11)
TEGRA124
Board: NVIDIA Jetson TK1
I2C: ready
DRAM: 2 GiB
MMC: Tegra SD/MMC: 0, Tegra SD/MMC: 1
*** Warning - bad CRC, using default environment
tegra-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
In: serial
Out: serial
Err: serial
Net: RTL8169#0
Warning: RTL8169#0 using MAC address from net device
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…
(Re)start USB…
USB0: USB EHCI 1.10
scanning bus 0 for devices… 1 USB Device(s) found
USB1: USB EHCI 1.10
scanning bus 1 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
Are you sure this is the full log?
this ia dmesg? and i am so sorry i donot know how to write your code into board i am a new man!sorry to linuxdev! i just begin to play it!no ssh!so if i can blind to write code it maybe can work? and how to using the serial console to write code into my board?
how to install a ftdi drive in linux! i just use a windows to accept the dmesg!
For clarification, a serial console works even if Linux doesn’t run. Even boot stages prior to Linux have output to serial console. If Linux doesn’t boot, then the serial console can tell us at which step during boot there was a failure.
“dmesg” is a command to run on a booted Linux system. Even if you don’t have a GUI it doesn’t mean Linux didn’t boot, and if it is just a GUI issue, then one can connect to a console and still run text-only mode (not unlike a DOS shell, but much more powerful). The serial console, if Linux boots, becomes command line login. SSH, if it runs, will also allow command line login even if the GUI is gone. Serial console is extremely useful and has no real drivers, and thus even when the rest of the world crashes and burns, serial console usually still works. SSH relies on networking, and although it is more reliable than a GUI, ssh may not function the way a serial console does under more harsh failures.
If you have an FTDI based serial USB UART (USB at one end, the other end matching your serial UART port…on a TK1 devel board it is the 9-pin D-sub), then the host computer (sounds like yours is Windows) will be able to use a serial console style program to see serial UART communications (your host PC may need an FTDI driver). In Windows usually PuTTY is used (as a text-based console), but other programs also work. Within your program you’ll have to be able to name the correct serial port within PuTTY (or other similar program), and use these settings:
115200 8N1
(speed 115200, 8-bit, no parity, 1 stop bit…technically I think you can enable CTS/RTS flow control, but probably don’t need to)
The hard part might be figuring out the name of the COM port…I’m not sure how to definitively check that on Windows.
Or, if Windows and the TK1 are on the same router, and you know the IP address of the Jetson, then you could see if you can ping the address from Windows in a DOS text-mode command line. For example, if you know the TK1 has address “192.168.1.3”, then “ping 192.168.1.3”. If ping works, then the same PuTTY can be told to use ssh to talk to account “ubuntu” at that address.
The earlier steps I mentioned regarding libglx.so (if and only if this was the actual GUI problem) can be performed with either PuTTY over serial console or PuTTY over ssh. You simply reach a text mode login and run those commands. For example, to run a command to list files in the current directory you just type “ls” and the enter key. To see your current (present) working directory, then you’d just type “pwd” and the enter key. The “cp” command from earlier is just a way to copy files (presumably to copy a good file over a bad file since libglx.so has two copies…only one copy can go bad).
Incidentally, PuTTY should have an option to log a session. I wouldn’t bother with this until you know you have the procedure down, but once you do, the text-mode command line “dmesg” and enter key will give you a log, and posting the log would be beneficial.
U-Boot SPL 2014.10-rc2-g751c38c (May 29 2018 - 12:55:11)
U-Boot 2014.10-rc2-g751c38c (May 29 2018 - 12:55:11)
TEGRA124
Board: NVIDIA Jetson TK1
I2C: ready
DRAM: 2 GiB
MMC: Tegra SD/MMC: 0, Tegra SD/MMC: 1
*** Warning - bad CRC, using default environment
tegra-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: 0
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0…
(Re)start USB…
USB0: USB EHCI 1.10
scanning bus 0 for devices… 1 USB Device(s) found
USB1: USB EHCI 1.10
scanning bus 1 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-tegra124
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.
Tegra124 (Jetson TK1) # dmesg
U-Boot SPL 2014.10-rc2-g751c38c (May 29 2018 - 12:55:11)
U-Boot 2014.10-rc2-g751c38c (May 29 2018 - 12:55:11)
TEGRA124
Board: NVIDIA Jetson TK1
I2C: ready
DRAM: 2 GiB
MMC: Tegra SD/MMC: 0, Tegra SD/MMC: 1
*** Warning - bad CRC, using default environment
tegra-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: 0
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0…
(Re)start USB…
USB0: USB EHCI 1.10
scanning bus 0 for devices… 1 USB Device(s) found
USB1: USB EHCI 1.10
scanning bus 1 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-tegra124
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
U-Boot SPL 2014.10-rc2-g751c38c (May 29 2018 - 12:55:11)
U-Boot 2014.10-rc2-g751c38c (May 29 2018 - 12:55:11)
TEGRA124
Board: NVIDIA Jetson TK1
I2C: ready
DRAM: 2 GiB
MMC: Tegra SD/MMC: 0, Tegra SD/MMC: 1
*** Warning - bad CRC, using default environment
tegra-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: 0
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0…
(Re)start USB…
USB0: USB EHCI 1.10
scanning bus 0 for devices… 1 USB Device(s) found
USB1: USB EHCI 1.10
scanning bus 1 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-tegra124
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.
is this can be useful?
What you have posted is correct. However, if that is as far as it got, then the bootloader never loaded Linux. This would be quite different than just HDMI failing. The doubt is caused by pasting the log into the forum thread, which can truncate. You would need to either attach it as a log file (just like the png image), or else paste into “code” tags (the “</>” icon during post will add scrollbars and preserve formatting of whatever is between the tags).
PuTTY should have an option to log. Maybe you already did this, and you pasted from the log. If the log is attached as a file, then we will know the forum itself didn’t cut off the log.
NOTE: If Linux is not running, then “dmesg” won’t be possible. “dmesg” is an extra command you can run to see logs once Linux itself is running. Some of that content would be the same as what you see scroll by on the serial console during boot, but adds other details.
this is login ! this ia all if i do not miss sth to do!
putty.log (4.33 KB)
it is a easy problem to a new to solve or maybe not?