Jetpack 5.1 and 5.1.1's UEFIManager read and write to the uart in addition to the debug port

[mark-goodall]

When a device is attached to the /dev/ttyTHS0 uart port, if it streams data it interrupts the boot process. This behavior isn't expected, as it is the only portion of the boot process which outputs or reads from this serial port.

[awong-gh]

Can you please provide the chip/platform description I.e., Jetson AGX Xavier?
Can you please mention what connector/pins you're using? I.e., connecto Jxx pins xx
Can you please clarify when you're sending data to the UART? Is it during UEFI booting?

[mark-goodall]

This is the AGX Xavier on 5.1 and 5.1.1, using the serial port on the gpio pins.
Most of the boot process only outputs on the debug port but the UEFI also outputs and reads from other serial port on the board. However, when it reads from other serial port it seems to go into a loop of reading spurious keypresses

[awong-gh]

If UART1 is enabled via Device Tree then UEFI will use it for stdin/stdout/stderr, by design.
An external device which writes to Jetson AGX Xavier UART1 during boot could be interacting with the UEFI Boot Manager, which will check for keypresses to support interactive user configuration of settings. Writes to UART1 later in the boot process could be interacting with the kernel/OS.

Regarding the info about "going into a loop of reading spurious keypresses": the Jetson AGX Xavier could be reacting to whatever input is being provided by the external device. Another possibility may be a UART config issue; the typical setup is 115200 8N1.

[mark-goodall]

Yes, we've run it with a test rig with those settings, sending a single character whilst the Boot Manager is waiting for a keypress causes it to get stuck in a loop. Internally, we recompiled the bootloader to avoid reading from any UART to work around this.

Input doesn't interfere with the OS when loaded, this only uses the debug UART port (as does the boot process before UEFI).

[awong-gh]

This is the AGX Xavier ... using the serial port on the gpio pins.

Does "gpio pins" refer to AGX Xavier's J30 40-pin dual row header pins?
If so, then it seems like you're using J30 pins 8,10, for UART1_TX, UART1_RX, respectively.

One AGX Xavier debug setup would use an Ubuntu PC running minicom, attached to J30 pins 8,10 with a TTL 3.3v to USB cable with a PL2303.
In minicom, HW and SW flow control are off, and the config is 115200 8N1.
Pressing ESC in minicom during UEFI boot will bring up the UEFI Boot Menu.

Please confirm that the "single character" sent to UART1 from the external device is identical in protocol/format to such a minicom setup.

[mark-goodall]

Yes, it listens on any uart

[awong-gh]

Just to be sure, does "it listens on any uart" mean that your AGX Xavier based platform is monitoring more than just ttyTHS0?
If so, can you please describe the configuration / location / name of those other UART(s)?
Or does this issue only happen on ttyTHS0?

Please note that if your hw platform has any customizations, then it's possible you will need UEFI customizations (beyond our reference UEFI implementation) to support that.

Regarding "sending a single character whilst the Boot Manager is waiting for a keypress", the reference UEFI Boot Manager behaviour has been tested with the Minicom terminal client (VT102, 115200 8N1, no flow control) sending input to AGX Xavier /dev/ttyTHS0 without issues.

If there is some other serial protocol being sent to the Boot Manager other than that supported Minicom, then that is untested/unsupported by our reference UEFI implementation.

[matanj83]

Hi, I think I have a similar problem also in Xavier NX, L4T 35.3.1.