L4T 35.2 UEFI Boot Manager causing boot delays up to 10 minutes


We are seeing very long boot times (5 to 10 minutes) at random after upgrading to 35.2 on Xavier NX with NVMe SSD.

I attached a normal boot and a slow boot debug logs, from same system over 2 consecutive resets.

How do I prevent these random booting delays

normal-boot.log (82.9 KB)
slow-boot-fail-to-boot.log (29.9 KB)

regards, rapidproto

Hi rapidproto,

It seems there’s an assertion from UEFI causing reset.

ASSERT [TerminalDxe] /out/nvidia/bootloader/uefi/Jetson_RELEASE/edk2/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c(2078): ((BOOLEAN)(0==1))

Are you using the devkit or custom board?

Does this issue happen randomly on the same board? What’s the rate of this issue?

Hi Kevin,

This is a custom board, the two log files are from same board, consecutive reboots, one worked, and one failed.

We are finding this issue across a batch of boards occurring about 25% of the time.

Do you have any modification(comparing to the devkit) for UART on your custom board?

Hi Kevin,

We hardwired UART0 to GPS, UART1 to RS422/485 and UART2 to debug connector, all via level shifters and buffers.

Are they all working as expected?

Could you help to disconnect them one by one to narrow down which peripheral might cause this assertion?
The assertion of UEFI is under Universal/Console.

Hi Kevin,

Could it be USB2 port that causes this assertion or is it only caused by UARTS. We have GPS directly connected to USB2 pins on SOM, via buffers.

Hi Kevin,

If it boots, then all ports work normally.

It appears that UART0 is causing the assertion since booting is normal with UART0 disconnected. Is there a way to ignore UART0 until booting is complete

regards, rapidproto

Could you help to disable UART0 in UEFI dtb?

You could just refer to the following thread to do this.
5.0.2 uefi uart1 - #2 by WayneWWW

Thanks Kevin,

I have setup the environment to recompile UEFI now, can you tell me specifically which edits are required to disable UART0. The link you provided is not clear.

@rapidproto ,

You don’t need to build UEFI. The device tree is in the link shared by Kevin.

I don’t know which part is unclear to you. Please tell more about what you want to ask. For example, do you know how the device tree works here or not.

In brief, kernel dtb and uefi dtb by default is using same file. But we want you to create a new one and make them read from different dtb.

Thanks Wayne,

I assumed we needed to modify UEFI to change behavior of UART0 at OS level.

I have modified the dtb, disabled UART0 via 3110000.serial and reflashed. I do not have the booting problem anymore with UART0 disabled. We also dont see /dev/ttyTHS1 and so UART0 no longer exists.

How do we enable UART0 ( SOM pins 99/101) to talk to our GPS without interference from UEFI


It sounds like you still not get the point.

First, I would like to address again. The boot process is UEFI->kernel. Most of use case should be done in kernel, not UEFI. Your case is this kind too.

What you got stuck is “UEFI does not let you pass”. The solution Kevin shared is we disable the UART0 in “UEFI” and still keep UART0 enabled in “Kernel”.

The reason we showed you there is a field called ““TBCDTB_FILE” in your board config is because this is where the UEFI reads the dtb.

UEFI has its own location to load dtb file and kernel has another location to read its dtb file. By default, these two are using same content. But now we want you to change it.

Your problem is you are still changing the content of both sides…

Could you understand what we try to say here? If you still not get it, I can share more examples…

Thanks for additional info Wayne. It is clear now what you are trying to say.

So far, no success with this method.

Here is my procedure…

Original dtb file: Linux_for_Tegra/kernel/dtb/tegra194-p3668-all-p3509-0000.dtb

Edited dtb file with UART0 disabled (status = “disable”;)


Copied tegra194-p3668-all-p3509-0000-uart0-disabled.dtb to Linux_for_Tegra/bootloader

The result is that both files are in both directories

Then Edit the board file


change TBCDTB_FILE path to match the new dtb file created with UART0 disabled



The flash the image to a device.


  1. do I need the full file path in TBCDTB_FILE. From Kevins post, I am guessing that it already looks in /bootloader/ directory for anything specified in TBCDTB_FILE

  2. should I delete the existing tegra194-p3668-all-p3509-0000.dtb file from /bootloader directory

  3. am I editing the correct board file. My initrd flash command is referencing p3509-0000+p3668-0001-qspi-emmc


You can also check your flash log (those log printed on your host machine) and see which dtb is getting in use.

Sorry, forgot to mention, your TBCDTB_FILE needs to give “bootloader” as prefix in path.


And put file to Linux_for_Tegra/bootloader

Thank Wayne, the missing link was the bootloader path in the TBCDTB_FILE. I can confirm that this works, slow boot is now fixed.

regards, rapidproto

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.