Hi there,
On the Jetson AGX Orin with L4T 36.5, what steps are required to enable UART4? I’d like to communicate via UART to a MCU onboard. I have configured my device tree as follows for uartd (i assume that is uart4), although I may be wrong). Pinmux has also been configured for uart4 on pins l5 and l48.
tegra234-p3737-0000+p3701.txt (67 Bytes)
tegra234.txt (368 Bytes)
After making these changes, the system is not booting:
error.txt (86.2 KB)
Please advise if anything is missing. Also, I only have the Tx and Rx lines of UART4 connected to the MCU. Since TX is a boot strapping pin, i was worried it was being affected by the MCU through a level shifter. However, I havent had any issues in the past booting, i only have issues now that I made these changes to the device tree files and recompiled.
*** Please note that this reply is generated by LLM automatically ***
To enable UART4 on the Jetson AGX Orin with L4T 35, you need to make several changes to the device tree files and pinmux configuration. Based on your description, it seems like you have already made some changes, but there might be a few more steps required to get UART4 working correctly.
Firstly, let’s confirm that uartd is indeed UART4. According to the Jetson AGX Orin documentation, uartd is the device tree node for UART4.
To enable UART4, you need to make the following changes:
- Device Tree Configuration: You have already modified the device tree files (tegra234p37370000p3701.txt and tegra234.txt) to enable uartd. However, please double-check that you have correctly configured the uartd node with the correct pin assignments and other settings.
- Pinmux Configuration: You have also configured the pinmux for uart4 on pins L5 and L48. This is correct, as UART4 uses these pins on the Jetson AGX Orin.
- UART4 Enable: In addition to configuring the device tree and pinmux, you need to enable UART4 in the kernel. You can do this by adding the following line to the kernel command line:
console=ttyS4,115200n8. This will enable UART4 and set the baud rate to 115200.
- UART4 Pin Configuration: Since you are using a level shifter to connect the MCU to the Jetson AGX Orin, you need to ensure that the pin configuration is correct. Make sure that the level shifter is configured to match the voltage levels of the Jetson AGX Orin and the MCU.
- Bootloader Configuration: If you are using a custom bootloader, you may need to modify the bootloader configuration to enable UART4.
Regarding the boot issue, it’s possible that the changes you made to the device tree files are causing the system to fail to boot. Here are a few things you can try:
- Revert Changes: Try reverting the changes you made to the device tree files and see if the system boots correctly. This will help you determine if the changes you made are causing the issue.
- Check Error Messages: Look at the error messages in the errortxt file (862 KB) to see if there are any clues about what’s causing the boot issue.
- Serial Console: Try connecting a serial console to the Jetson AGX Orin and see if you can get any output during boot. This may help you diagnose the issue.
Comparison with other Jetson modules:
- On the Jetson Orin NX and Nano series, UART4 is also available, but the pin assignments may be different. Make sure to check the documentation for your specific module to ensure that you are using the correct pin assignments.
- On the Jetson AGX Xavier series, UART4 is not available. Instead, you can use UART3 or UART5.
In summary, to enable UART4 on the Jetson AGX Orin with L4T 35, you need to make changes to the device tree files, pinmux configuration, and kernel command line. You also need to ensure that the pin configuration is correct and that the bootloader is configured to enable UART4. If you are experiencing boot issues, try reverting changes, checking error messages, and using a serial console to diagnose the issue.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
Hi matthew196,
Are you using the devkit or custom board for AGX Orin?
serial@3140000 is the node for UART-E.
Could you configure it as following instead?
uartd: serial@3130000 {
compatible = "nvidia,tegra194-hsuart";
reg = <0x0 0x03130000 0x0 0x10000>;
interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&bpmp TEGRA234_CLK_UARTD>;
resets = <&bpmp TEGRA234_RESET_UARTD>;
reset-names = "serial";
status = "okay";
};
Please short TX/RX of UART4 to verify loopback test before connecting to MCU.
Hi Kevin,
Thanks for the fast reply,
I am using a custom carrier board.
I have implemented the changes and am able to successfully boot. However, I’m not sure which THS port I am expecting for UART4. Based on the latest flash, I can only find THS1 and THS2 - both failing the loopback test when I short UART 4’s pins.
I have made the changes to serial@3130000 for my board (it was my mistake to use 3140000 as I dont use that anywhere).
Attached are the logs if it may help.
bootlogs.txt (121.1 KB)
I also read the LLMs response and see the following kernel command needed:
UART4 Enable: In addition to configuring the device tree and pinmux, you need to enable UART4 in the kernel. You can do this by adding the following line to the kernel command line: console=ttyS4,115200n8. This will enable UART4 and set the baud rate to 115200.
I am yet to implement this, and am unsure where to implement it. Some assistance would be greatly appreciated - as im not sure where/how to access the kernel command line.
I don’t see serial@3130000 is probed from this log.
What’s your use case for this UART?
If you don’t use it for console, then I think this modification is not required.
If the alias is not specified, it should be assigned dynamically.
Could you share the full dmesg and device tree in runtime for further check?
You can simply run the following command and share extracted_proc.dts with us to check.
$ sudo dtc -I fs -O dts -o extracted_proc.dts /proc/device-tree
Full dmesg:
dmesg.txt (72.9 KB)
extracted-proc:
output.txt (333.3 KB)
I’ll remove the alias addition now. Just to be clear, here is the UART-related parts of my current dtsi files:
tegra234-p3737-0000+p3701.txt (708 Bytes)
tegra234.txt (1.2 KB)
The uart isnt for console, purely just information comms. The MCU is a slave in this instance.
@KevinFFF I’d also like to setup UART1, 2 and 5. What ports will these be on?
Hi @KevinFFF , please advise if there are any configuration parameters which I am missing
serial@3130000 {
compatible = "nvidia,tegra194-uart";
It is not the expected compatible property to me.
Please configure compatible = "nvidia,tegra194-hsuart"; instead.
The serial@3130000 is still not probed correctly.
Please check UART4 and enable it first.
@KevinFFF
My apologies, reflashing now
If i dont use the rts and cts pins, can i unassign them in pinmux?
Also, what THS line am i expecting UART 4 on
Here is the new dts and also a the dmesg error I got:
dmesg.txt (660 Bytes)
extracted_proc.txt (397.9 KB)
Hi @KevinFFF , please let me know if there are any issues in my dtc file. Do i need an alias? What more configuration is required.
Please also advise where instructions for this configuration can be found. I’ve checked the design guide but didnt find UART config.
Sure.
You have to check the dmesg.
[ 2.472166] serial-tegra 3130000.serial: failed to get alias id, errno -19
Okay, it fails to get a valid alias id.
Please try to add the following line in device tree.
aliases {
i2c3 = "/bus@0/i2c@3190000";
nvdla1 = "/bus@0/host1x@13e00000/nvdla1@158c0000";
i2c1 = "/bus@0/i2c@c240000";
mmc1 = "/bus@0/mmc@3400000";
i2c8 = "/bus@0/i2c@31e0000";
i2c6 = "/bus@0/i2c@31c0000";
serial1 = "/bus@0/serial@3100000";
+ serial3 = "/bus@0/serial@3130000";
tegra-camera-rtcpu = "/rtcpu@bc00000";
..
UART4 should be assigned to /dev/ttyTHS3 if it can be probed correctly.
Hi @KevinFFF
UART4 still not working. Please see attached:
root@ubuntudev:/home/devdev# cat /sys/kernel/debug/gpio | grep PH
gpio-391 (PH.00 )
gpio-392 (PH.01 )
gpio-393 (PH.02 )
gpio-394 (PH.03 |camera-control-outpu) out lo
gpio-395 (PH.04 |regulator-vdd-3v3-pc) out lo
gpio-396 (PH.05 )
gpio-397 (PH.06 |camera-control-outpu) out lo
gpio-398 (PH.07 )
I am concerned with just editing device trees randomly. I have found the regulator-vdd-3v3-pc in my device tree p3737-0000+p3701.dtsi in source code - can i just remove the field for regulator-vdd-3v3-pcie?
Rgearding the camera-control-output, that isnt in the device tree p3737-0000+p3701.dtsi. Here are the files i can find in source code which include this file, please advise which one i can/should delete this entry from.
dev@dev:~/Documents/Linux_for_Tegra/source$ grep -rl “camera-control-outpu”
hardware/nvidia/t23x/nv-public/overlay/tegra234-p3737-camera-eCAM130A-overlay.dts
hardware/nvidia/t23x/nv-public/overlay/tegra234-p3767-camera-p3768-imx477-imx219.dts
hardware/nvidia/t23x/nv-public/overlay/tegra234-p3767-camera-p3768-imx477-A.dts
hardware/nvidia/t23x/nv-public/overlay/tegra234-p3737-camera-modules.dtsi
hardware/nvidia/t23x/nv-public/overlay/tegra234-p3737-camera-p3762-a00.dtsi
hardware/nvidia/t23x/nv-public/overlay/tegra234-p3737-camera-e3333-overlay.dts
hardware/nvidia/t23x/nv-public/overlay/tegra234-p3767-camera-p3768-imx219-imx477.dts
hardware/nvidia/t23x/nv-public/overlay/tegra234-p3767-camera-p3768-imx219-dual.dts
hardware/nvidia/t23x/nv-public/overlay/tegra234-p3971-0000+p3701-0008-camera-p3762-a00-overlay.dts
hardware/nvidia/t23x/nv-public/overlay/tegra234-p3767-camera-p3768-imx219-A.dts
hardware/nvidia/t23x/nv-public/overlay/tegra234-p3737-camera-e3331-overlay.dts
hardware/nvidia/t23x/nv-public/overlay/tegra234-p3767-camera-p3768-imx477-dual.dts
hardware/nvidia/t23x/nv-public/overlay/tegra234-p3737-0000-camera-imx274-dual.dtsi
hardware/nvidia/t23x/nv-public/overlay/tegra234-p3971-0000-camera-imx274-dual.dtsi
hardware/nvidia/t23x/nv-public/overlay/tegra234-p3767-camera-p3768-imx219-C.dts
hardware/nvidia/t23x/nv-public/overlay/tegra234-p3767-camera-p3768-imx477-C.dts
hardware/nvidia/t23x/nv-public/overlay/tegra234-p3740-camera-p3783-a00-overlay.dts
hardware/nvidia/t23x/nv-public/overlay/tegra234-p3737-0000-camera-imx185-a00.dtsi
hardware/nvidia/t23x/nv-public/nv-platform/tegra234-camera-p3785.dtsi
kernel-devicetree/generic-dts/dtbs/tegra234-p3767-camera-p3768-imx219-C.dtbo
kernel-devicetree/generic-dts/dtbs/tegra234-p3737-camera-e3333-overlay.dtbo
kernel-devicetree/generic-dts/dtbs/tegra234-p3737-camera-p3762-a00-4Hawk-overlay.dtbo
kernel-devicetree/generic-dts/dtbs/tegra234-p3767-camera-p3768-imx477-C.dtbo
kernel-devicetree/generic-dts/dtbs/tegra234-p3737-camera-eCAM130A-overlay.dtbo
kernel-devicetree/generic-dts/dtbs/tegra234-p3737-camera-p3762-a00-1Hawk-overlay.dtbo
kernel-devicetree/generic-dts/dtbs/tegra234-p3740-camera-p3783-a00-overlay.dtbo
kernel-devicetree/generic-dts/dtbs/tegra234-p3767-camera-p3768-imx477-imx219.dtbo
kernel-devicetree/generic-dts/dtbs/tegra234-p3767-camera-p3768-imx219-A.dtbo
kernel-devicetree/generic-dts/dtbs/tegra234-p3737-camera-p3762-a00-2Hawk-overlay.dtbo
kernel-devicetree/generic-dts/dtbs/tegra234-p3767-camera-p3768-imx219-imx477.dtbo
kernel-devicetree/generic-dts/dtbs/tegra234-p3737-camera-p3762-a00-overlay.dtbo
kernel-devicetree/generic-dts/dtbs/tegra234-p3767-camera-p3768-imx477-A.dtbo
kernel-devicetree/generic-dts/dtbs/tegra234-p3767-camera-p3768-imx477-dual.dtbo
kernel-devicetree/generic-dts/dtbs/tegra234-p3971-0000+p3701-0008-camera-p3762-a00-overlay.dtbo
kernel-devicetree/generic-dts/dtbs/tegra234-p3737-0000+p3701-0000-dynamic.dtbo
kernel-devicetree/generic-dts/dtbs/tegra234-p3737-camera-p3762-a00-4Owl-overlay.dtbo
kernel-devicetree/generic-dts/dtbs/tegra234-p3971-0000+p3701-0008-camera-dual-imx274-overlay.dtbo
kernel-devicetree/generic-dts/dtbs/tegra234-p3737-camera-e3331-overlay.dtbo
kernel-devicetree/generic-dts/dtbs/tegra234-p3767-camera-p3768-imx219-dual.dtbo
kernel-devicetree/generic-dts/dtbs/tegra234-p3740-0002+p3701-0008-nv-safety.dtb
kernel-devicetree/generic-dts/dtbs/tegra234-p3737-camera-p3762-a00-3Hawk-3Owl-overlay.dtbo
kernel-devicetree/generic-dts/dtbs/tegra234-p3740-0002+p3701-0008-nv.dtb
I disabled all those gpio uses and ended up with this:
root@ubuntudev:/home/devdev# cat /sys/kernel/debug/gpio | grep PH
gpio-391 (PH.00 )
gpio-392 (PH.01 )
gpio-393 (PH.02 )
gpio-394 (PH.03 )
gpio-395 (PH.04 )
gpio-396 (PH.05 )
gpio-397 (PH.06 )
gpio-398 (PH.07 )
Setup the UART but still not seing any toggling on the uart4 lines. This is the dmesg
root@ubuntudev:/home/devdev# dmesg | grep serial
[ 0.153014] 31d0000.serial: ttyAMA0 at MMIO 0x31d0000 (irq = 118, base_baud = 0) is a SBSA
[ 0.300199] msm_serial: driver initialized
[ 2.400178] 3100000.serial: ttyTHS1 at MMIO 0x3100000 (irq = 112, base_baud = 0) is a TEGRA_UART
[ 2.400675] serial-tegra 3130000.serial: RX in PIO mode
[ 2.400678] serial-tegra 3130000.serial: TX in PIO mode
[ 2.400707] 3130000.serial: ttyTHS3 at MMIO 0x3130000 (irq = 206, base_baud = 0) is a TEGRA_UART
[ 2.400992] serial-tegra 3110000.serial: RX in PIO mode
[ 2.400996] serial-tegra 3110000.serial: TX in PIO mode
[ 2.401027] 3110000.serial: ttyTHS2 at MMIO 0x3110000 (irq = 207, base_baud = 0) is a TEGRA_UART
[ 83.027556] Please complete system configuration setup on the serial port provided by Jetson’s USB device mode connection. e.g. /dev/ttyUSBx where x can 0, 1, 2 etc.\
and the setup:
root@ubuntudev:/home/devdev# stty -F /dev/ttyTHS3 115200 raw -echo
root@ubuntudev:/home/devdev# cat /dev/ttyTHS3 & echo “test” > /dev/ttyTHS3
[1] 7559
Hi @KevinFFF
Just an update, we’ve tried to probe the lines coming straight out of the Jetson after performing a echo test, but the Tx lines arent toggling when measured from an oscilloscope. We’ve verified the echo test with the other UART lines (UART 5,2,1) and theyre working fine. Heres the current pinmux, although compared to other forums it seems correct. Please advise if you can see any discrepancies.
It seems these 2 pins are used by other drivers.
Is the driver probed for this interface successfully at this moment?
Have you checked their pinmux register value?
Please advise how to check register values…
We have removed all other uses of the pins from the camera and regulator device tree configurations. What we also tried to do was set the TX and RX lines as GPIOs and toggled them, and were successfully able to toggle them. But it appears that UART fuinctionality is not being linked/enabled/set for those pins
