TX2 -- Boot/Reset hanging over bootconsole issue Confusion over UART labeling

I keep getting this error every time I reset or do a flash.sh load and boot to the TX2 :

                           bootconsole [uart0] disabled.

I have a serial connection from the host (Ubuntu 14.04) using J21 GPIO header pins 8, 10, 9, 10, 11, & 36. These are, respectively, UART0_TX, GND, UART0_RX, UART0_RTS, and UART0_CTS (according to the pinout chart). I’m confused about whether this is really UART0 or one of the other 6 UARTs (I’m not really sure how you select a specific UART.)

If it is UART0, that would seem to explain the hang error above because I’m using the same port (UART0) for concurrent serial comm and booting (bootconsole?) operations. Is there any way to specify which UART you want to use for booting?

Can I use the 8-pin serial connector (I think I read this is considered UART1) for either booting or serial comm? This would avoid whatever arbitration might have to occur in the above scenario. And, if so, how do I enable this?

Those are the correct pins. Although connecting CTS/RTS pins will not hurt when using software flow control (normally the pins are used with hardware flow control) do know that in a TX2 hardware flow control does not work correctly on this port.

The J17 header is a 6-pin, and is connected to the camera. After removing the camera it can be used for serial communications…but not serial console. The J21 serial console should work at 115200 8N1 software flow control if the flash was correct. Note that both U-Boot and the Linux kernel have been configured for this…changing this would involve changing both the kernel and U-Boot.

If your serial program is set to 115200 8N1, and this occurs, I’d be suspicious of the flash. What was your exact flash command line?

These are the command lines I tried :
sudo ./flash.sh -S 29318MiB jetson-tx2 mmcblk0p1


                 sudo ./flash.sh jetson-tx2 mmcblk0p1

Is the above pin configuration on J21 considered to be UART0? Is the 6-pin J17 header supposed to be UART1? How would I choose another UART?

No matter what I try, I still get the “bootconsole [uart0] disabled” message and then the boot just hangs (every time right after Bluetooth RFCOMM and HIDP socket layer initializations). I was thinking it might still be continuing with the boot and that I just couldn’t see it, but no display has come alive at all yet. (By the way, I’m using Kermit for the serial connect).

Also, maybe you can clear up some confusion for me – is the boot itself happening over the microUSB port or via the UART0 or UART1?

I’m not sure of the physical UART, it is ttyS0 logically. J17 is logically ttyTHS2. One means to test is to jumper the TX and RX together, then use a terminal program and see if typing in text echoes. If it does, then settings are correct and you know you have the right UART.

I am currently rebuilding a lost home directory so it is difficult to look up more detail, all of this is from memory, YMMV.

Boot is of course independent of any outside device. Serial console is occurring over the serial UART going to J21. micro-USB and full-sized USB, if functional during boot are normal host ports. The exception is that in recovery mode the micro-B USB port becomes a custom device which the flash software understands. Within U-Boot only drivers for USB2 mode exist, so if under Linux the port is set to USB3 any contact which was visible during U-Boot will be lost and the port will re-enumerate. Should U-Boot and Linux both function with a port in USB2 mode, then there will be a continuity of service when transitioning from U-Boot to Linux.

In the case of micro-B in recovery mode a pseudo operating system seems to be downloaded (fastboot) in combination with the built-in firmware. At that point any data for flash would occur over the micro-USB connector in USB2 mode.

If bootconsole is disabled from any point after Linux kernel load I’d start by seeing what is in “cat /proc/cmdline”. This would give a very good idea about what the port was told to do.

The host ports I’m using are backwards-compatible USB3.1 and I don’t see any obvious switching of USB modes anywhere. The flash to the board is always successful; it’s only when I do the reset to boot that’s requested afterwards that the bootmonitor message pops up. It goes through the boot script just fine until it hits the Bluetooth socket layer init; that’s when the serial disconnect occurs.

Maybe an important factor here is that I’ve substituted an “Image” from a different kernel-build into the /boot directory (replacing the Jetpack-built “Image” that was there), but I get no complaints until the boot stage mentioned above. I’m probably just naïve as to whether that will work or not.

The USB3 controller doesn’t support 3.1, just 3.0…so you’d have to be using a PCIe expansion for 3.1 on the Jetson side. Actual flash is over USB2 though, it’ll never be in USB3 mode on that port. Some of the flashes using a VM have been known to fail if the port is USB3 compatible…and then forcing it to USB2 mode allowed further success.

If for some reason your kernel does not have features required for the bluetooth stage which is locking up, and if bluetooth is something which must succeed for boot to continue, then this would account for everything. I’m not where I can check right now, but there is probably a command such as this to disable bluetooth:

sudo systemctl disable bluetooth.service

If you have the original kernel I’d test that to see if it helps. Odds are in favor of a custom kernel causing the issue due to configuration options.

If disabled then even if configuration wanted bluetooth under normal conditions it would no longer be mandatory for boot to continue. The trick is that if you are not able to boot how do you boot to run the command to disable? Possibly you could make a rescue SD card.

Enabled services are all part of systemd. The kernel should be able to boot into single-user mode even if systemd fails at the point of bluetooth.

Also, nothing else depends on bluetooth:

nvidia@tegra-ubuntu:~$ systemctl list-dependencies --reverse bluetooth.service

Personally, while I understand the problems systemd is trying to solve, I think they hammered themselves too deep into dbus and into non-essential problems (not to mention not using customary tools like, oh, “less” for browsing files) and Linux distros are hurting because of it. But that’s a different question :-)
(For embedded systems, a distribution based on devuan might be more appropriate, btw.)