precondition：
ROM version R24.2.1
Customized carriy board
Operational：
- Insert ttyUSB devices and bring up the TX1
Problem:
There is no signal coming from Uart1.
Does your device tree enable the UART?
hi linuxdev:
There are singles before. It should be damaged for uart-phy on the SOM.
Do you know how to fix it or Could we use uart3 to output logs ?
Thanks.
I don’t know about your customized case, but logging is usually programmed to a particular UART in two places. First, in U-Boot…you’d have to reconfigure and rebuild U-Boot if you need modified logging destination during that stage.
After U-Boot terminates, the kernel config command line names the UART. There is an implicit assumption here that the UART has already been configured to 115200 8N1, but note the “APPEND” parameter in extlinux.conf. Regular console plus serial console is determined by:
fbcon=map:0 console=tty0 console=ttyS0,115200n8
In extlinux.conf you would replace “console=ttyS0,115200n8” with the new “ttyS0” replacement, e.g., if you were set up to now have ttyS1, then this is what you’d use. The trick is of course the serial UART device must be set up and functional (such as through device tree) or naming it won’t matter.
Hi linuxdev:
Do you mean we can modify the command line
from
fbcon=map:0 console=tty0 console=ttyS0,115200n8
to
fbcon=map:0 console=tty0 console=ttyS2,115200n8
We want uart1 to uart3,so I think it should be ttyS2. Am I right?
thanks.
I don’t know which ttyS# UART3 corresponds to (perhaps it is a ttyTHS#), but if ttyS2 is the case, then that would be correct.
Hi linuxdev:
Do you know the postion of u-boot command line on Jetson TX1?
Is it here ?
./u-boot/arch/arm/dts/tegra20-seaboard.dts:10:
bootargs = "vmalloc=192M video=tegrafb console=ttyS0,115200n8 root=/dev/mmcblk1p3 rw rootwait";
thanks.
hi linuxdev：
fbcon=map:0 console=tty<b>0</b> console=ttyS2,115200n8
It is not working.
How could we see which ttyS match the Uart3?
thanks.
I am unsure of where U-Boot would be edited to change the serial console setting. The APPEND parameter of the “/boot/extlinux/extlinux.conf” is where the edit would be once reaching Linux. I do not know which tty corresponds to your particular UART, but it would be necessary to have it configured in the “.dtb” device tree file for it to work (the UART needs to be set up before console ever tries to use it…ttyS0 happens to be set up).
To explore this and see how things are done I suggest you reverse compile the existing dtb file and explore it. In “/boot/extlinux/extlinux.conf” there is an FDT key/value pair…this tells you which dtb file is loaded. Extracting and manipulating the dtb goes something like this:
dtc -I dtb -O dts -o /tmp/extracted.dts /boot/the_firmware_in_extlinux.dtb
# Browse, maybe edit extracted.dts, then re-package:
dtc -I dts -O dtb -o /tmp/modified.dtb /tmp/extracted.dts
Hint: I see this in one extracted dtb file, and it is probably the ttyS0 setup:
serial@70006000 {
compatible = "nvidia,<b>tegra210-uart</b>", "nvidia,tegra114-hsuart";
reg = <0x0 0x70006000 0x0 0x40>;
reg-shift = <0x2>;
interrupts = <0x0 0x24 0x4>;
iommus = <0x46 0xe>;
nvidia,dma-request-selector = <0x5d 0x8>;
dmas = <0x5d 0x8 0x5d 0x8>;
dma-names = "rx", "tx";
status = "okay";
<b>console-port</b>;
sqa-automation-port;
enable-rx-poll-timer;
};
Be careful to note “compatible” uses “tegra210-uart”, whereas other UARTs might have only the “tegra114-hsuart”…this is related to whether the port shows up as ttyS# or ttyTHS#.
Basically the dtb will refer to controllers via their base address; you can use the Technical Reference Manual (TRM) to get an idea of which controllers there are, and the numbering of ports will often (not always) be in the same order as the numbering of the base address (initializing in different orders might break that). Find the entry you think belongs to serial console and test changing it. You can use an alternate boot entry in extlinux.conf and save the original in case of needing to revert.
Hi linuxdev:
There are Uarta/b/c/d defined strings in the target dtb.
But the status had been defined disabled. So it must have other configure at some where I don’t know…
./kernel/arch/arm64/boot/dts/.tegra210-jetson-cv-base-p2597-2180-a00.dtb.dts +598
uarta: serial@70006000 {
compatible = "nvidia,tegra114-hsuart";
reg = <0x0 0x70006000 0x0 0x40>;
reg-shift = <2>;
interrupts = <0 36 0x04>;
iommus = <&smmu 14>;
nvidia,dma-request-selector = <&apbdma 8>;
dmas = <&apbdma 8>, <&apbdma 8>;
dma-names = "rx", "tx";
status = "disabled";
};
uartb: serial@70006040 {
compatible = "nvidia,tegra114-hsuart";
reg = <0x0 0x70006040 0x0 0x40>;
reg-shift = <2>;
interrupts = <0 37 0x04>;
iommus = <&smmu 14>;
nvidia,dma-request-selector = <&apbdma 9>;
dmas = <&apbdma 9>, <&apbdma 9>;
dma-names = "rx", "tx";
status = "disabled";
};
uartc: serial@70006200 {
compatible = "nvidia,tegra114-hsuart";
reg = <0x0 0x70006200 0x0 0x40>;
reg-shift = <2>;
interrupts = <0 46 0x04>;
nvidia,dma-request-selector = <&apbdma 10>;
iommus = <&smmu 14>;
dmas = <&apbdma 10>, <&apbdma 10>;
dma-names = "rx", "tx";
status = "disabled";
};
uartd: serial@70006300 {
compatible = "nvidia,tegra114-hsuart";
reg = <0x0 0x70006300 0x0 0x40>;
reg-shift = <2>;
interrupts = <0 90 0x04>;
nvidia,dma-request-selector = <&apbdma 19>;
iommus = <&smmu 14>;
dmas = <&apbdma 19>, <&apbdma 19>;
dma-names = "rx", "tx";
status = "disabled";
};
Notice that “dma-names” is part of the tegra114-hsuart driver handling a UART, whereas this is slightly different and no dma is involved in tegra210-uart. Examine and compare what you posted with the earlier snippet of code I showed. The former produces a “/dev/ttyTHS#”, the latter a “/dev/ttyS#” (same hardware, different driver). You will want to experiment with enabling of the entry for the controller address you are interested in, or perhaps using the tegra210-uart instead (same controller address) if compatibility is needed with ttyS# (the ttyTHS# supports DMA, but I suspect U-Boot does not, so continuous operation from U-Boot to Linux stages might require enabling as ttyS# and not using dma…I doubt you’d ever care about dma performance on a serial port anyway).
Remember that you can make changes and repackage the file for testing.
Hi linuxdev:
We use the source code version is r24.2.1. We had download the source code through two way.
I have double checked the both side.
./source_sync.sh -k tegra-l4t-r24.2.1
And
http://developer.nvidia.com/embedded/dlc/l4t-24-2-sources
It should be defined like this in ./kernel/arch/arm64/boot/dts/tegra210-soc-base.dtsi +528
I don’t know if that would be correct or not. The reason I say so is because there are two possible drivers for the UARTs. One uses the traditional driver and produces a ttyS#. Such a driver is supported in both U-Boot and the Linux kernel. This is the default for console, ttyS0.
The hsuart is a different driver used only on a Tegra UART, and is intended for more efficient access using DMA. Most serial UARTs on the system map to this driver and thus a “/dev/ttyTHS#”. Think about why the serial console did not use ttyTHS0, instead it used ttyS0 (the driver here is a 16550A compatible UART driver). If you want the driver to function in U-Boot, and then again during the transition into Linux, you probably want to keep the hardware in continuous operation. Should you configure using hsuart, it is unlikely U-Boot will work with serial console; at which point the kernel starts working with serial console using a ttyTHS0 I don’t know…probably early…but you’d lose the ability to use serial console in the boot loader…or perhaps some other odd problem, I’m not really sure. Perhaps you don’t need the serial console until after Linux loads.
Your device tree can be used to set up either driver; parameters which are valid will change depending on tegra210-uart driver or tegra114-hsuart driver. The original device tree for serial console on ttyS0 is a good example of using tegra210-uart.
Hi linuxdev:
There is a uart defined in the .tegra210-jetson-cv-p2597-2180-a00.dtb.dts
The status is “okay”. I will take it try.
# 26 "arch/arm64/boot/dts/tegra210-common.dtsi" 2
/ {
nvidia,dtbbuildtime = "Apr 24 2017", "17:27:05";
serial@70006000 {
compatible = "nvidia,tegra210-uart", "nvidia,tegra114-hsuart";
console-port;
sqa-automation-port;
enable-rx-poll-timer;
status = "okay";
};
serial@70006200 {
compatible = "nvidia,tegra114-hsuart";
status = "okay";
};
serial@70006300 {
compatible = "nvidia,tegra114-hsuart";
status = "okay";
};
hi linuxdev:
It seams uart2 is working by software. But there is not any signal coming from uart3-phy.
[ 3.904085] tegradc tegradc.1: probed
[ 3.987152] tegradc tegradc.1: fb registered
[ 3.990218] tegra_camera_platform tegra-camera-platform.45: tegra_camera_probe:camera_platform_driver probe
[ 3.999501] misc tegra_camera_ctrl: tegra_camera_isomgr_register camera's max_iso_bw 3600000
[ 4.010056] tegra-apbdma tegra-apbdma: Tegra20 APB DMA driver register 32 channels
[ 4.017011] tegra-adma tegra210-adma: Tegra210 ADMA driver register 10 channels
[ 4.023251] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[ 4.030344] of_serial 70006000.serial: RX periodic polling enabled
[ 4.035643] 70006000.serial: ttyS0 at MMIO 0x70006000 (irq = 68) is a Tegra
[ 4.042687] of_serial 70006200.serial: RX periodic polling enabled
[ 4.048707] 70006200.serial: ttyS1 at MMIO 0x70006200 (irq = 78) is a Tegra
[ 4.055705] of_serial 70006300.serial: RX periodic polling enabled
[ 4.061784] 70006300.serial: ttyS2 at MMIO 0x70006300 (irq = 122) is a Tegra
<b>[ 4.068692] console [ttyS2] enabled, bootconsole disabled</b>
hi linuxdev:
TX1 default uart log.
[ 3.904103] tegradc tegradc.1: probed
[ 3.986998] tegradc tegradc.1: fb registered
[ 3.990061] tegra_camera_platform tegra-camera-platform.45: tegra_camera_probe:camera_platform_driver probe
[ 3.999356] misc tegra_camera_ctrl: tegra_camera_isomgr_register camera's max_iso_bw 3600000
[ 4.009912] tegra-apbdma tegra-apbdma: Tegra20 APB DMA driver register 32 channels
[ 4.016870] tegra-adma tegra210-adma: Tegra210 ADMA driver register 10 channels
[ 4.023115] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[ 4.030185] of_serial 70006000.serial: RX periodic polling enabled
[ 4.035495] 70006000.serial: ttyS0 at MMIO 0x70006000 (irq = 68) is a Tegra
[ 4.042326] console [ttyS0] enabled, bootconsole disabled
[ 4.042326] console [ttyS0] enabled, bootconsole disabled
[ 4.053155] 70006040.serial: ttyTHS1 at MMIO 0x70006040 (irq = 69) is a SERIAL_TEGRA
[ 4.062956] 70006200.serial: ttyTHS2 at MMIO 0x70006200 (irq = 78) is a SERIAL_TEGRA
[ 4.070995] serial-tegra 70006300.serial: RX in PIO mode
[ 4.076390] 70006300.serial: ttyTHS3 at MMIO 0x70006300 (irq = 122) is a SERIAL_TEGRA
[ 4.086277] (null): coherent DMA mask is unset
I see this:
console [ttyS0] enabled, bootconsole disabled
…I’m wondering if perhaps there is still other software trying to use the port. Sometimes it is just a case of mixing up which controller is really wired to where. In the case of a ttyUSB# there isn’t really any mix-up possible, but for the serial port attached to your device, physically, what are the details of how is it wired?
hi linuxdev:
This log show on the R24.2.1 default trace output.
[ 4.042326] console [ttyS0] enabled, bootconsole disabled
After modified ttyS2, the log show like this:
[ 4.068692] console [ttyS2] enabled, bootconsole disabled
How is the port physically wired (have you tried direct TX/RX loopback, is your USB serial device used for half the connection, so on)? Is the CTS/RTS available? Is it running 3.3V logic level (note there are places where 1.8V may be expected if not level shifted)? What is your method of sending data to the port (e.g., echo to the “/dev” file directly)? It sounds like you have an oscilloscope wired to the TX/RX, is that correct?
Hi zuoqiang,
Have you clarified the cause and resolved this issue?
Any further information can be shared?
Thanks