I believe UART Device Tree is incomplete and inaccurate for UART in Jetpack 6.2

Robotics & Edge Computing Jetson & Embedded Systems Jetson AGX Orin
1

In previous JetPacks, developers provided the underlying device tree information for the UARTS here:
~\Linux_for_Tegra\source\public\hardware\soc\t23x\kernel-dts\tegra234-soc\tegra234-soc-uart.dts

After the reorganization that occurred in Jetpack 6.2, the underlying device information for all UARTS should have been included at the module level (p3701) however I was unable to find it. What is there in the tegra234.dtsi file is the device tree segment for the uart I am most interested in, which is “uarte.” However this entry does not include what I presume is memory allocation for the DMA. This missing piece of information causes system faults when rapidly sending (cut and paste into minicom) any more than 5 characters. (The error code and a detailed explanation can be found here:

By adding the missing line, uarte is now functional:
iommus = <&smmu_niso0 TEGRA234_SID_GPCDMA>;

I believe that this should be patched and in the next release the entire device tree should be included as it is in 35.3.1 (I presume this Jetpack 6.1)

Caveat: I didn’t know anything about device trees when I started this and I might be missing something. If so please enlighten me.

3

Hi don.harrison1,

Thanks for pointing this out.

This is from Jetpack 5.1.1(L4T r35.3.1).

Please note that we use different kernel for JP5.x(K5.10) and JP6.x(K5.15) and also different inclusion for device tree. e.g. We included and listed all uart interfaces in JP5.x even if some of them are disabled, but we just include available interfaces in JP6.x. Device tree can be configured according to your use case.
As a result, you have to configure the device tree manually to enable UART-E in JP6.x.

Basically, you can refer to Communicating with /dev/ttyTHS1 (UARTE) is causing a fault - #21 by KevinFFF to enable uarte in device tree. I’ve verified it(Or using “nvidia,tegra194-hsuart”) working on the devkit with JP6.2.
I don’t get any error after configuring them and can’t find the errors showing in the dmesg you shared in previous topic.

If you have the requirement for DMA, you should have dmas, dma-names, iommus properties included.

4

I just want to know the steps you took to test JP6. As I pointed out a couple of times, just “typing” from monitor to monitor does not cause the fault/failure. You have to send more characters than the hardware can buffer without going to the DMA (i.e. cut and paste several characters). I find it hard to believe your example in my other post will pass that test without adding the MMU statement.

Also, the proper structure for this device tree would be to have a complete set of tested and “disabled” entries in tegra234.dtsi or earlier. The structure in JP5 is much cleaner. Bad choice to change it.

5

Thanks for your suggestion, I will check with internal if iommus property is necessary for this node.

6

Hi @don.harrison1,

It seems iommus is included in gpcdma: dma-controller@2600000 node by default.

Do you hit the issue after using serial-tegra.c by updating compatible = "nvidia,tegra194-hsuart"; for uart-e?

Do you hit the issue if you just refer to my steps shared in Communicating with /dev/ttyTHS1 (UARTE) is causing a fault - #21 by KevinFFF to enable default 8250_tegra.c driver?

7

All I know is when I added the line, everything started working and I moved on.

8

We would like to know if it would also work if you just update the status for serial@3140000 and keep using default compatible = "nvidia,tegra234-uart\0nvidia,tegra20-uart";.

Please help running the following command on your board(with working state) and share extracted_proc.dts for further check.

$ sudo dtc -I fs -O dts -o extracted_proc.dts /proc/device-tree

Your previous result seems using nvidia,tegra194-hsuart.