Freeze before first stage bootloader when ttyTHS1 connected

Hi,

Setup:

  • Jetson Nano b00
  • Jetpack 4.5

I’ve encountered an issue when a UART with traffic is connected to the ttyTHS1 serial port interface. The Jetson freezes before any bootloader message is output.

Regards,
Clint

If this is the serial console port, then you need to either use a different port, or else disable serial console within the bootloader. Note that devices with group “tty” are consoles, and those with group by “dialout” are ok for general use. For example, see:
ls -l /dev/ttyS* /dev/ttyTHS*

Note that bootloaders are separate programs and exist prior to Linux loading, and so disabling there can be an additional step. You might find this URL of use:
https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3243/index.html#page/Tegra%2520Linux%2520Driver%2520Package%2520Development%2520Guide%2Fkernel_boot_time.html%23wwpID0E0YB0HA

Almost forgot…a ttyTHS# is the same hardware as a ttyS# if the “#” is the same. The device special file name depends on which driver is producing the file. If any of ttyS or ttyTHS are group tty, then that hardware should be avoided during boot stages (or else should be disabled in boot software).

The Jetson was freezing before the first stage bootloader, I don’t think we have control over that part of the firmware.

Is there a binary available to avoid this behaviour?

The bootloader source is included with the kernel source. You just cd to a different directory. Basically you have to recompile it and flash. There are some attributes you can control with just the device tree, but so far as I know there isn’t a simple answer (the official documentation though should provide bootloader compile information, either for CBoot or U-Boot or both…some platforms don’t use U-Boot, but use CBoot directly, though I think Nano uses U-Boot). This is complicated by different releases differing at times in the procedure, along with different Jetson models differing as well. You kind of need to use the official documention for your specific platform and release.

You can find your system’s L4T release via “head -n 1 /etc/nv_tegra_release”. You can then find the specific documentation here (through the L4T release):
https://developer.nvidia.com/linux-tegra

I see, CBoot also uses the device tree. I will check if this solves the issue.

Yes, CBoot does use device tree. In the early days it did not, but on even semi-recent releases it does. The part I don’t know about is whether serial console in CBoot can be disabled through device tree. Someone else probably knows, but for a long time in the past, one had to actually edit the source code to disable this (and I’m sure you can still do it this way, but if device tree can do this, then it is much simpler).