I am bringing up a new Orin AGX carrier with 36.4.3. I am trying to configure my serial ports, but running into an issue with /dev/ttyTHS1. I can connect minicom to this port, but when I send it data, I get this error:
My serial device is connected to C56 and C58.
These are the relevant parts of my device tree
aliases {
serial0 = &uarta;
serial1 = &uarte;
serial2 = &uartb;
serial3 = &uartd;
serial4 = &tcu;
};
…
/* UARTE UART5 UART2 0x03140000 0x0314ffff SYSTEM C56 C58 */
uarte: serial@3140000 {
compatible = “nvidia,tegra194-hsuart”;
reset-names = “serial”;
status = “okay”;
};
Uncompiled version from kernel_tegra234-p3737-0000+p3701-0004-nv.dts:
serial@3140000 {
compatible = “nvidia,tegra194-hsuart”;
reg = <0x00 0x3140000 0x00 0x10000>;
interrupts = <0x00 0x74 0x04>;
clocks = <0x03 0x9f>;
resets = <0x03 0x68>;
dmas = <0xee 0x14 0xee 0x14>;
dma-names = “rx\0tx”;
status = “okay”;
reset-names = “serial”;
phandle = <0x232>;
};
Pinmux:
uart5_tx_py5 {
nvidia,pins = “uart5_tx_py5”;
nvidia,function = “uarte”;
nvidia,pull = <TEGRA_PIN_PULL_NONE>;
nvidia,tristate = <TEGRA_PIN_DISABLE>;
nvidia,enable-input = <TEGRA_PIN_DISABLE>;
nvidia,lpdr = <TEGRA_PIN_DISABLE>;
};
uart5_rx_py6 {
nvidia,pins = "uart5_rx_py6";
nvidia,function = "uarte";
nvidia,pull = <TEGRA_PIN_PULL_NONE>;
nvidia,tristate = <TEGRA_PIN_ENABLE>;
nvidia,enable-input = <TEGRA_PIN_ENABLE>;
nvidia,lpdr = <TEGRA_PIN_DISABLE>;
};
“tty” grep’ed dmesg:
All files that I have changed from the initial release are attached.
What am I missing?
Hi,
On Jetson platforms, we support using peripherals like CAN, SPI, I2C, UART… etc. for the user.
For CAN usage:
For the connection of peripheral on the devkit, please refer to expansion-headers guide and carrier board specification:
For pin configuration, please refer to pinmux spreadsheet:
https://developer.nvidia.com/embedded/secure/jetson/agx_orin/jetson_agx_orin_pinmux_config_template.xlsm
By default, the configuration is used for the devkit. If you are using the custom carrier board, please configure it according to your custom board design.
There are also several examples which have been verified from us, please check
Please share the full dmesg and device tree for us to check your status in detail.
Thanks!
ChangedFiles.zip (59.5 KB)
dmesg.txt (69.8 KB)
I’m very sorry, I thought I attached the files.
Hi don.harrison1,
Are you using the devkit or custom board for AGX Orin?
It seems you want to use PY05, PY06, PY07, PZ00 for uarte (serial@3140000).
I’ve seen you’ve configured serial1 = &uarte; so that it is mapping to /dev/ttyTHS1 as shown in your dmesg.
[ 2.488074] 3140000.serial: ttyTHS1 at MMIO 0x3140000 (irq = 113, base_baud = 0) is a TEGRA_UART
It should work as expected.
Please share the exact command you run to reproduce the issue.
sudo minicom -b 921600 -D /dev/ttyTHS1
When I send characters to the port, I get this fault.
UART A and UART B work as expected. UARTD for some reason does not receive anything (transmit is okay). This could be hardware, but I have traced the signal right to the via that connects to the pad.
Also, the string I send ends with “Waiting for host…” and at one point, I saw “ost…” come out on the terminal.
Additional information:
I moved my module to a different 3rd party carrier and the problem with UARTE followed. I also discovered that when I only sent ~6 characters, I did not get the fault. This would seem to indicate that this might be an interrupt problem where the FIFO is large enough to handle small amounts of data without requiring interrupts. That assumes that interrupts are being used for this. Other than setting interrupt priority, I can’t see anything in the configuration that would cause something like that.
Could you try running the following command to disble nvgetty service and check if it could help?
$ sudo systemctl stop nvgetty.service
$ sudo systemctl disable nvgetty.service
It does not make a difference.
Tried starting the build from scratch to make sure I had not accidentally affected some other device tree file. Same result.
Installed and ran “strace”
sudo strace -e signal,read,write -p 28709
This is the result of the 5 character receive (no faults):
sudo strace -e signal,read,write -p 28709
strace: Process 28709 attached
read(0, “c”, 32) = 1
write(3, “c”, 1) = 1
read(3, “12345\r\n”, 127) = 7
write(1, “12345\r\n”, 7) = 7
And the 6 character receive (with fault):
sudo strace -e signal,read,write -p 28709
strace: Process 28709 attached
read(0, “c”, 32) = 1
write(3, “c”, 1) = 1
read(3, “\0\0\0\0\0\0\0\0”, 127) = 8
Update: Swapped around the alias values to make the failing channel THS3. Same result.
Please run the following command on your board.
$ sudo dtc -I fs -O dts -o extracted_proc.dts /proc/device-tree
$ sudo dmesg > dmesg.log
And share extracted_proc.dts and dmesg.log for further check.
As instructed, also there is an updated copy of the changed files that I used to create a fresh build. I might have missed a file or two with the previously provided upload. Also included the dtc messages that came up. Note that uarte is /dev/ttyTHS3 in this particular build.
dmesg.log (59.8 KB)
extracted_proc.dts.txt (319.5 KB)
ChangedFiles.zip (533.5 KB)
dts messages.txt (170.4 KB)
[ 3.109022] 3140000.serial: ttyTHS3 at MMIO 0x3140000 (irq = 113, base_baud = 0) is a TEGRA_UART
It seems uarte(3140000.serial) has been configured and recognized correctly on your board.
Your dmesg and device tree are both good to me for configuring this serial interface.
Could you use /dev/ttyTHS3 as expected now?
I have now tested this on 100% not-my-hardware-or-software and found the same error. I do not have an Nvidia DevKit to try.
My suspicion is that this is an un-found anomaly in 36.4.3. I’m attempting to drop back to 35.4.1.
I could really use some help on this.
Dropped back to 35.3.1. It does not appear to have the issue with my 3rd party board’s configuration. Attempting to adapt 35.3.1.
There is a bug in 36.4.3, do I need to report it somewhere?
Do you mean the issue is specific to JP6.2(r36.4.3)?
If so, have you tried to compare the device tree and full dmesg between r35.3.1 and r36.4.3?
Or you can provide them here for us to check.
3140000.serial UART interface does not pinout from the devkit so that we may need some time to verify it locally.
Hi @don.harrison1,
I’ve just verified uarte(3140000.serial) working on the devkit with both JP5.1.4 and JP6.2
Please refer to the following configurations in JP6.2.
@ pinmux
//UART5_TX
$ sudo busybox devmem 0x0243d070
0x00000400
//UART5_RX
$ sudo busybox devmem 0x0243d078
0x00000450
@ device tree
serial@3140000 {
compatible = "nvidia,tegra234-uart\0nvidia,tegra20-uart";
reg = <0x00 0x3140000 0x00 0x10000>;
interrupts = <0x00 0x74 0x04>;
clocks = <0x03 0x9f>;
resets = <0x03 0x68>;
dmas = <0xee 0x14 0xee 0x14>;
dma-names = "rx\0tx";
- status = "disabled";
+ status = "okay";
phandle = <0x231>;
};
@ dmesg
[ 3.904840] 3140000.serial: ttyS0 at MMIO 0x3140000 (irq = 113, base_baud = 4250000) is a Tegra
@ test
$ sudo su
# stty -F /dev/ttyS0 115200 raw -echo
# cat /dev/ttyS0 &
# echo "test" > /dev/ttyS0
test
Please check the following configurations in your case:
- the pinmux register is the same as mine
- use the legacy uart driver by configuring compatible for serial@3140000 as
nvidia,tegra234-uart\0nvidia,tegra20-uart
- it would be enumerated as ttyS0 by default, (i.e. you don’t need to configure aliases)
I will try this. Will the legacy driver run at a megabit (921600 Baud)? I’m wondering what the issue is because the 35.X.X release runs the HS driver. Could you elaborate?
