[ 5.697043] 70006040.serial: ttyTHS1 at MMIO 0x70006040 (irq = 69) is a SERIAL_TEGRA
[ 5.710142] <b><i>70006200.serial</i>: ttyTHS2 at MMIO 0x70006200 (irq = 78) is a SERIAL_TEGRA</b>
[ 5.723181] serial-tegra <b><i>70006300.serial</i></b>: RX in PIO mode
[ 5.731059] 70006300.serial: ttyTHS3 at MMIO 0x70006300 (irq = 122) is a SERIAL_TEGRA
Basically it seems to hang between setting up UART ttyTHS2 and ttyTHS3. I would expect that if hardware access failed via lack of nVidia files, then none of the serial UARTS would work. Can you verify that the ttyTH1 completed just prior to starting the ttyTH2? If so, the likelihood of a hardware issue goes up (it could still be related to software for the specific serial UART, or to whatever is connected to it).
I meet the exactly problem @innovT. When I start TX1 it stops at ttyTHS2 at MMIO 0x70006200 (irq = 78) is a SERIAL_TEGRA. The ttyTH1 completed just prior to starting the ttyTH2. I also tried to reflash it, but it remained the same.
The hardware connected is a USB hub for USB keyboard and USB mouse; and the HDMI Monitor.
nothing connected to UART.
I tried connecting only the USB keyboard ; no USB hub.
The same problem.
Keyboard and USB HUB work well with my Jetson TK1.
I notice the power led indicator on the USB hub is not turning on like it does with the TK1.
Could it be the USB not working?
Or should that not it prevent from booting?
Do you have a serial console available? If the text you see during boot stops there via a monitor, it may be that the system is still actually running (but video not working). Without more clues it might end up as RMA, but having two people with exactly the same issue tends to make me believe odds now point to a software issue.
Thank you for your reports of the behavior. We are currently investigating your issue. On the off chance it’s related to the display, can you try disconnecting HDMI, plug the RJ45 ethernet into your DHCP router, and see if you get link lights and can ping tegra-ubuntu (if you have a previous JTK1 which also has tegra-ubuntu hostname, verify the assigned IP).
In the meantime, since you have swapped out and debugged the peripherals and the issue persists, you might want to look into RMA. See https://developer.nvidia.com/embedded/support to get the process started. They do advance replacement. Please PM me if you have any concerns.
I could disconnect HDMI and connect RJ45 Ethernet to router to check for lights ; but how do I ping without the HDMI monitor?
The monitor shows the Linux penguin logo and text OK.
But it stops booting like I mentioned.
I will RMA but I will wait a bit in case others report the same problem.
There are two of us with the same problem already.
The monitor, keyboard and mouse I am using work well with the Jetson TK1…
It does make me think it’s the TX1 dev board; but then two reports of the same problem makes me wonder…
Thank you for your replies and help with this.
I can hardly wait to get it working!
Sorry! I understand what you meant about the ping…
Ping the TX1 board IP from host or other computer in the network to see if it replies which it would mean Ubuntu has booted up.
I will try that.
Just a note on USB…USB has the option to supply a small amount of power from the host, or else a bit more power if the HUB is externally powered. Circuitry and software is in place to enforce this. The HUB in the Jetson is a “root” HUB, the other is an external HUB. Each HUB has to initialize before it will be willing to provide power…whether a light goes out because of drawing too much power and having the HUB cut power I do not know, this is probably implementation defined.
In the case of no L.E.D. on an unpowered external HUB which otherwise works, this likely indicates the root HUB of the Jetson was not providing power. This in turn could be either hardware malfunction or the root HUB has not initialized. The root HUB would initially cycle and power up during the boot loader stage (u-boot should initialize USB even before handing off to the kernel).
So here is the big question for the HUB which works normally on a different computer but fails on the TX1…if you closely watch the power light on the HUB from the moment power is applied to the TX1 (including plugging in power and at the moment the power switch is pressed), does this light ever cycle or blink? U-boot at minimum should cause this, and then when the kernel takes over the light could go away as the xusb driver takes over. If it blinks, I suspect hardware is ok, along with USB initializing in u-boot…if it never even blinks, I’d suspect hardware since both u-boot and xusb never had even a moment of power.
I connected TX1 HDMI to Monitor HDMI and had the same problem. booting stopped.
I connected TX1 HDMI to monitor input DVI-D and it works!
linuxdev: the USB hub power LED lights on too! keyboard and mouse work well.
I think one of the reliability issues may be related to handling for newer monitors which go beyond normal “hi def” (e.g., 1920x1080 increased to 2560x1080). The original data query was the DDC data. This had to be updated and expanded to use newer monitors, and EDID was born. Now with ultra-high-def coming in, new extensions had to be added to the EDID. Theory was that each new standard had an extension and if that extension was not understood (presumably because the software reading it did not know the extension existed when it was written), then the newer higher resolution settings would not be known, but the original standard settings would still work. Unfortunately, sometimes software doing the reading finds a data extension it doesn’t understand, and instead of using what it still understands, it falls on its face and breaks. Cables themselves can influence the EDID as well…cables can sometimes need to be upgraded as well for reading data (e.g., cables have numbered standards for HDMI or DisplayPort).
Some combination of cable and data format on one monitor is working for you, but failing on the other. The fact is that the monitor worked on the TK1, but not the TX1. TX1 has new knowledge about extensions that the TK1 did not have, as TK1 does not handle the ultra-hi-def. I suspect the software from TX1 reading EDID data broke something from older data formats without realizing it. EDID is binary data, it could be something really simple like data alignment boundaries related to 32/64-bit changes.
Thanks for reporting the additional behavior, we’ll update the case with your info about the HDMI. As linuxdev indicated, it’s probably confused between HDMI 2.0 and 1.4 modes, and ttyTHS2 at MMIO is the last thing that gets printed before the (unsuccessful) modeswitch.