Hey,
I tried to enable UART comm via this manual:
but i can’t find
tegra186-quill-p3310-1000-c03-00-base.dtc
i just have this file:
tegra186-quill-p3310-1000-c03-00-base.dtb
but in this file the parameter “serial@c28000” is (status = “okay”).
ls /dev/ttyTHS*
returns [ /dev/ttyTHS1, /dev/ttyTHS2, /dev/ttyTHS3 ]
I looped pins 9-10.
in opened gtkterm via:
sudo gtkterm -p /dev/ttyTHS2
but i can’t see echo.
where did i wrong?
thank you
This is a typographic error:
tegra186-quill-p3310-1000-c03-00-base.dt<b>c</b>
Device tree source files are “.dts”. Device tree include files within the kernel are “.dtsi”. Binary files are “.dtb”. The tool which does the compiling and reverse compiling is “dtc”. There is no device tree with suffix “.dtc”.
If you build a device tree with the dtb provided in the driver package (and that is what the URL is doing), then you can install “tegra186-quill-p3310-1000-c03-00-base.dtb”.
FYI, to decompile “tegra186-quill-p3310-1000-c03-00-base.dtb”:
dtc -I dtb -O dts -o reverse_compiled.dts tegra186-quill-p3310-1000-c03-00-base.dtb
If you edited “reverse_compiled.dts” and want to put it back into binary format with a new name:
dtc -I dts -O dtb -o edited.dtb reverse_compiled.dts
If you want to extract the device tree of a running Jetson:
dtc -I fs -O dts -o extracted.dts /proc/device-tree
I decompile “tegra186-quill-p3310-1000-c03-00-base.dtb”
serial@3100000 {
compatible = "nvidia,tegra20-uart", "nvidia,tegra186-hsuart";
#stream-id-cells = <0x1>;
reg = <0x0 0x3100000 0x0 0x40>;
reg-shift = <0x2>;
interrupts = <0x0 0x70 0x4>;
nvidia,memory-clients = <0xe>;
dmas = <0x19 0x8 0x19 0x8>;
dma-names = "rx", "tx";
clocks = <0xd 0x37 0xd 0x10d>;
clock-names = "serial", "parent";
resets = <0xd 0x2f>;
reset-names = "serial";
status = "okay";
nvidia,adjust-baud-rates = <0x1c200 0x1c200 0x64>;
console-port;
sqa-automation-port;
linux,phandle = <0x80>;
phandle = <0x80>;
};
serial@3110000 {
compatible = "nvidia,tegra186-hsuart";
#stream-id-cells = <0x1>;
reg = <0x0 0x3110000 0x0 0x40>;
reg-shift = <0x2>;
interrupts = <0x0 0x71 0x4>;
nvidia,memory-clients = <0xe>;
dmas = <0x19 0x9 0x19 0x9>;
dma-names = "rx", "tx";
clocks = <0xd 0x38 0xd 0x10d>;
clock-names = "serial", "parent";
resets = <0xd 0x30>;
reset-names = "serial";
status = "okay";
nvidia,adjust-baud-rates = <0x1c200 0x1c200 0x64>;
linux,phandle = <0x81>;
phandle = <0x81>;
};
serial@c280000 {
compatible = "nvidia,tegra186-hsuart";
#stream-id-cells = <0x1>;
reg = <0x0 0xc280000 0x0 0x40>;
reg-shift = <0x2>;
interrupts = <0x0 0x72 0x4>;
nvidia,memory-clients = <0xe>;
dmas = <0x19 0x3 0x19 0x3>;
dma-names = "rx", "tx";
clocks = <0xd 0xd7 0xd 0x10d>;
clock-names = "serial", "parent";
resets = <0xd 0x31>;
reset-names = "serial";
status = "okay";
nvidia,adjust-baud-rates = <0x1c200 0x1c200 0x64>;
linux,phandle = <0x82>;
phandle = <0x82>;
};
serial@3130000 {
compatible = "nvidia,tegra186-hsuart";
#stream-id-cells = <0x1>;
reg = <0x0 0x3130000 0x0 0x40>;
reg-shift = <0x2>;
interrupts = <0x0 0x73 0x4>;
nvidia,memory-clients = <0xe>;
dmas = <0x19 0x13 0x19 0x13>;
dma-names = "tx";
clocks = <0xd 0x4d 0xd 0x10d>;
clock-names = "serial", "parent";
resets = <0xd 0x32>;
reset-names = "serial";
status = "okay";
nvidia,adjust-baud-rates = <0x1c200 0x1c200 0x64>;
linux,phandle = <0x83>;
phandle = <0x83>;
};
serial@3140000 {
compatible = "nvidia,tegra186-hsuart";
#stream-id-cells = <0x1>;
reg = <0x0 0x3140000 0x0 0x40>;
reg-shift = <0x2>;
interrupts = <0x0 0x74 0x4>;
nvidia,memory-clients = <0xe>;
dmas = <0x19 0x14 0x19 0x14>;
dma-names = "rx", "tx";
clocks = <0xd 0xc2 0xd 0x10d>;
clock-names = "serial", "parent";
resets = <0xd 0x84>;
reset-names = "serial";
status = "disabled";
nvidia,adjust-baud-rates = <0x1c200 0x1c200 0x64>;
linux,phandle = <0x84>;
phandle = <0x84>;
};
serial@3150000 {
compatible = "nvidia,tegra186-hsuart";
#stream-id-cells = <0x1>;
reg = <0x0 0x3150000 0x0 0x40>;
reg-shift = <0x2>;
interrupts = <0x0 0x75 0x4>;
nvidia,memory-clients = <0xe>;
dmas = <0x19 0xc 0x19 0xc>;
dma-names = "rx", "tx";
clocks = <0xd 0xc3 0xd 0x10d>;
clock-names = "serial", "parent";
resets = <0xd 0x6f>;
reset-names = "serial";
status = "disabled";
nvidia,adjust-baud-rates = <0x1c200 0x1c200 0x64>;
linux,phandle = <0x85>;
phandle = <0x85>;
};
serial@c290000 {
compatible = "nvidia,tegra186-hsuart";
#stream-id-cells = <0x1>;
reg = <0x0 0xc290000 0x0 0x40>;
reg-shift = <0x2>;
interrupts = <0x0 0x76 0x4>;
nvidia,memory-clients = <0xe>;
dmas = <0x19 0x2 0x19 0x2>;
dma-names = "rx", "tx";
clocks = <0xd 0xd8 0xd 0x10d>;
clock-names = "serial", "parent";
resets = <0xd 0x70>;
reset-names = "serial";
status = "disabled";
nvidia,adjust-baud-rates = <0x1c200 0x1c200 0x64>;
linux,phandle = <0x86>;
phandle = <0x86>;
};
but i can’t find the UART ports (/dev/ttyTHS2)
Be aware that the device tree knows a controller base address, and options for that controller. Each port within a controller has offsets, and so there is a combination of base address and other hex values in the device tree. No specific “tty” label, as this is part of the Linux kernel and udev (which occurs only after device tree is loaded). A given controller can be ttyTHS2 or ttyS0 without the device tree ever showing it.
The “compatible” line lists all drivers the controller can be driven by, but does not select the specific driver which will actually be used…this is again up to the Linux kernel. The ones without “hs” are not DMA-capable, and use the traditional naming of “/dev/ttyS”, while the “hs” (“high speed” DMA) will use a “/dev/ttyTHS”. You don’t want to use both at the same time, but both can be listed as possible.
See “ls /dev/ttyTHS*”.
Most serial port applications I know of are absolutely ancient and simply don’t look for entries with any other name format than “/dev/ttyS”. USB serial ports are usually “/dev/ttyUSB”, and these too are usually not supported due to outdated serial applications. For example, I use gtkTerm a lot, and I cannot name either “ttyUSB” or “ttyTHS”. However, most of these applications have an init file, e.g., the gtkTerm application has “~/.gtktermrc”, and I save this, then manually edit the file. I replace a default entry (such as “/dev/ttyS2”) to instead be what I want (such as “/dev/ttyTHS2”). Other than this or entering the serial device on the command line argument while manually starting an antiquated application is the only way I know to do this.
I believe whatever software you are using is capable of working with ttyTHS2, but probably isn’t smart enough to think about that file name being a serial port. If it has an init file or config file, then you could edit this and put it in that way.
I haven’t tried, but it may be possible to put a symbolic link in to mimic the older name. For example, if your system does not have “/dev/ttyS12”, then you might do something like this (I have not tested):
sudo ln -s /dev/ttyTHS2 /dev/ttyS12
Hey,
thank you for your patience,
When i run
ls /dev/ttyTHS*
i see all the 3 ports:
/dev/ttyTHS1
/dev/ttyTHS2
/dev/ttyTHS3
i opened gtkterm via:
sudo gtkterm -p /dev/ttyTHS2
and now it connected to UART port (i guess)
i looped pins 9-10 and expected to get an ECHO,
why i not receiving ECHO?
ttyTHS2 goes to connector J17, not J21. The one on J21 is a serial console, which means you had a terminal talking to itself (a logged in session was talking to itself, not gtkterm…though if set up correctly you would have seen it sending error messages as commands…probably resulting in more error messages). Normally J21’s serial UART uses 115200 8N1 with no flow control as a live session by user nvidia.
You can connect TX and RX on J17, and use ttyTHS2, and it should work as expected. Example, assuming permissions won’t get in the way (you can either use root or your user can be a member of group “dialout” to get permissions):
gtkterm -p /dev/ttyTHS2 -s 115200
Note that default speed of gtkterm is 9600, so “-s 115200” is needed.
Do be aware that if you use an external UART cable that this uses 3.3V TTL logic levels. At best, other levels won’t work; at worst, there could be damage. In the case of looping back TX to RX you are guaranteed levels will always be correct.
Hey,
I looped J17 as you say and now i can see the echo.
now i am trying to do the same on AUVIdia J120 board.
I looped J7.2-J7.3 & J7.4-J7.5 and i can’t see echo there.
For different carrier boards the device tree will require changes. Unless the two boards are basically exact matches on involved components you can expect a failure until flashing with their board support package. Have you flashed with their BSP?
hey,
i burn auvidea’s firmware version 1.6 via JetPack
i download the firmware from here:
https://auvidea.com/firmware/
and downloaded the first one (J9x/J10x/J120/J130-NV (55.5 MB)).
i have to do something else except burn the correct version?
I have not worked on the Auvidea board before, so I don’t know what their instructions are. I suspect it is a customization of the regular install, but I couldn’t tell you what specific change there is. It is a safe bet to assume that if everything needed is not complete, then at least some parts of the hardware will not function (UART is one example of many which might need device tree or firmware changes).
Hey almog123,
Were you able to run it on the J120 board?