the instance from the serial@c280000 exists in the JetPack 5 sources. However, I did not see any serial@c280000 instance in the JetPack 6 sources.
Furthermore, I got the serial debug log (find attached at the of the post) from an AGX Orin board flashed with JetPack 5 and I noticed the serials ports that I saw in the log are:
[ 0.136363] 31d0000.serial: ttyAMA0 at MMIO 0x31d0000 (irq = 118, base_baud = 0) is a SBSA
[ 2.031917] serial-tegra 3100000.serial: RX in PIO mode
[ 2.031922] serial-tegra 3100000.serial: TX in PIO mode
[ 2.032043] 3100000.serial: ttyTHS1 at MMIO 0x3100000 (irq = 112, base_baud = 0) is a TEGRA_UART
[ 2.033370] serial-tegra 3110000.serial: RX in PIO mode
[ 2.033373] serial-tegra 3110000.serial: TX in PIO mode
[ 2.035692] 3110000.serial: ttyTHS2 at MMIO 0x3110000 (irq = 207, base_baud = 0) is a TEGRA_UART
I understood that the serial ports 3100000 and 3110000 are associated with the UART1(uarta) and UART2(uartb). However, there is no reference to the c280000 port, the UART3(uartc) port, which is confusing.
In the JetPack 6 sources, I found that the 3100000 and 3110000 instances are in the following files:
For 3100000 UART1(uarta) port → hardware/nvidia/t23x/nv-public/tegra234.dtsi and hardware/nvidia/t23x/nv-public/tegra234-p3737-0000+p3701-0000.dts
For 3110000 UART2(uartb) port → hardware/nvidia/t23x/nv-public/nv-platform/tegra234-p3737-0000+p3701-xxxx-nv-common.dtsi and hardware/nvidia/t23x/nv-public/nv-soc/tegra234-soc-overlay.dtsi
but, as I already mentioned, I did not find any instance of the serial@c280000 UART3 port.
Questions for the NVIDIA team
Could you please clarify the instance loss of the serial@c280000 UART 3 port in the JetPack 6 sources?
Could I use the serial@c280000 instance in the soc/t19x/kernel-dts/tegra194-soc/tegra194-soc-uart.dtsi JetPack 5 sources file to enable the UART 3 port in JetPack 6?
Jetpack 5 and 6 have different stacks for device tree and we also modify few nodes for serial devices.
Actually, serial@c280000 is used for serial device rather than TCU(Tegra Combined Uart) for debug console.
We don’t want customer use this interface for other use case so that we remove it from device tree.
As I mentioned above, we don’t suggest user using this interface for the purpose other than debug console. Please just keep as it is. In addition, I think you should refer to the t23x for your AGX Orin. (rather than t19x)
I understood the UART3/C is only for debugging purposes.
In fact, that port is what we are using for. However, we are exploring customizing the debug UART interface at the hardware level from the development kit design found in the NVIDIA Jetson AGX Orin Developer Kit Carrier Board Specification:
We already tested the Planned Design, but we got output messages very different from the devkit UART debug port output. That is the reason why we wanted to check the UART3 port instance in the JetPack 6 sources device tree.
Please, check the following debug files so you can see the differences:
According to the planned design, could we see the same output as when we use the devkit serial port?
I understand that the UART3 device tree instance should not be changed in the device tree, but according to the planned design, should we keep the instance as is too?
Are the Debug MCU and Level Shifters needed? Or could we replace them with the USB to UART FT232RNQ chip and get the same results?
Maybe you should share the schematic for our HW team to review if they are good to use.
As I stated before, we don’t suggest customer modify the architecture or any configurations in device tree for UART3. Just keep it working as debug UART with default configurations.
Same as above, please share the schematic for our HW team to review.
From your Custom_AGX_SerialCOM_20240603_163014.rtf, it seems boot failed in MB2 with above errors so that it reset the board.
Do you have EEPROM on your custom board?
However, even if the connection should be fine, we do see weird symbols from the custom AGX board that I shared at Lost instance of UART3 in JetPack 6 for the AGX Orin board - #5 by EduardoSalazar96. So when comparing the devkit UART port debug message with the custom AGX board UART messages what we can read is not the same from what we read from the devkit board. We were reading the UART messages at 115200 bps from the terminal.
Questions for the NVIDIA team
With this connection should we get the same messages that we do read in the Orin devkit board?
Or are the weird symbols and messages that differ from the Orin devkit board expected with this connection?
The logs show that the custom board tries to boot a couple of times after reaching Jetson UEFI firmware. The kernel messages do not show up and there are no error messages.
Questions for the NVIDIA team
Is there a possibility that the board is booting propertly but the UART does not show the kernel messages? The DisplayPort is not currently connected to this custom board.
Could you provide any comments on the steps that we followed and the log messages?
In my last reply, I briefly explained how we got the previous log I shared. So we solved the
ERROR: camera-ip/isp5/isp5.c:2031 [isp5_pm_init] "ERROR: Failed to turn isp1 power on"
BUG: core/init/init.c:86 [init_all] "*** FIRMWARE INIT FAILED AT LEVEL 95
message by applying the change for the ODMDATA.
No, it is not. The log is after we apply the change for ODMDATA.
Not right now, the board has a micro-HDMI instead of the DisplayPort.
I updated the debug UEFI binary by following the instructions in Build with docker · NVIDIA/edk2-nvidia Wiki · GitHub. I replaced the <Custom BSP package>/bootloader/uefi_jetson.bin with the /build/nvidia-uefi/images/uefi_Jetson_DEBUG.bin binary and reflash the board. Just to give more information about the UEFI build, I cloned the edkrepo as:
edk2_docker edkrepo clone nvidia-uefi NVIDIA-Platforms main
Hi @KevinFFF
Here are some hardware details that the Hardware team shared with us to debug if any hardware components may be affecting the boot process.
Feature
Orin Eval Kit Description
Custom AGX Description
Orin Eval Kit
Custom AGX
Orin Pins affected
Button MCU
PushButton switches, much of this feeds into the DEBUG MCU
FPGA handles the PB switch functionality
Si Labs 8-bit MCU controlled
FPGA
POWER_BTN(L61), MODULE_POWER_ON(L54)
DEBUG MCU, USB Type C port controller, USB PD controller
DEBUG port USB connector connects to MCU
UART2, UART7, MCU_I2C, NVJTAG_SEL, NVDBG_SEL not supported, SYS_RESET_N, FORCE_RECOVERY_N handled by FPGA
Microchip 32-bit MCU
No DEBUG port, No USB PD support, No USB 3.0, FPGA
