I found serial-tegra erros as follow on Jetson AGX Xavier withthe jetpack4.4. Please help to analyse what went wrong. thanks a lot.
You’ll need to provide some details on:
- Is this a dev kit, or is it a custom board?
- Is there any modification of device tree?
- Is there any modification of kernel or kernel modules?
- Was this fully flashed, or was some special flash command ever used to flash only part of the system?
- Are any of the serial ports being monitored or used, e.g., serial console, or any serial port used?
- What else is connected to the system, e.g., monitor, keyboard/mouse?
hi linuxdev,
We use agx xavier core board without modification of device tree about serial. The ttyTHS4(uarte) is use to connect a inertial navigation equipment. No other console uses the ttyTHS4.
I’m not sure if “core board” means development kit or a module plus third party carrier board. No modification of device tree tends to mean this is a dev kit, which is the simplest case.
I am also curious what this command outputs:
sudo stty -F /dev/ttyTHS4 --all
Also, are you certain nothing is reading/writing to/from “/dev/ttyS4”? I ask because this is the same UART, but via a different driver. Two UART drivers used simultaneously won’t have defined results.
We use a nvidia agx xavier module and our baseboard。
No modification of device tree only refers that the device tree of the UART has not been modified.
sudo stty -F /dev/ttyTHS4 --all command results as follow
speed 460800 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q;
stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 0; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc
I am sure that we don’t read/write from “/dev/ttyS4”, because “/dev/ttyS4” doesn’t exist.
ls /dev/tty*
/dev/tty /dev/tty17 /dev/tty26 /dev/tty35 /dev/tty44 /dev/tty53 /dev/tty62 /dev/ttyp5 /dev/ttypf
/dev/tty0 /dev/tty18 /dev/tty27 /dev/tty36 /dev/tty45 /dev/tty54 /dev/tty63 /dev/ttyp6 /dev/ttyS0
/dev/tty1 /dev/tty19 /dev/tty28 /dev/tty37 /dev/tty46 /dev/tty55 /dev/tty7 /dev/ttyp7 /dev/ttyS1
/dev/tty10 /dev/tty2 /dev/tty29 /dev/tty38 /dev/tty47 /dev/tty56 /dev/tty8 /dev/ttyp8 /dev/ttyS2
/dev/tty11 /dev/tty20 /dev/tty3 /dev/tty39 /dev/tty48 /dev/tty57 /dev/tty9 /dev/ttyp9 /dev/ttyS3
/dev/tty12 /dev/tty21 /dev/tty30 /dev/tty4 /dev/tty49 /dev/tty58 /dev/ttyp0 /dev/ttypa /dev/ttyTCU0
/dev/tty13 /dev/tty22 /dev/tty31 /dev/tty40 /dev/tty5 /dev/tty59 /dev/ttyp1 /dev/ttypb /dev/ttyTHS1
/dev/tty14 /dev/tty23 /dev/tty32 /dev/tty41 /dev/tty50 /dev/tty6 /dev/ttyp2 /dev/ttypc /dev/ttyTHS4
/dev/tty15 /dev/tty24 /dev/tty33 /dev/tty42 /dev/tty51 /dev/tty60 /dev/ttyp3 /dev/ttypd
/dev/tty16 /dev/tty25 /dev/tty34 /dev/tty43 /dev/tty52 /dev/tty61 /dev/ttyp4 /dev/ttype
This is what I will call a “custom carrier board”. Note that unless your carrier board is an exact match to the design of the dev kit, then the device tree probably needs to be modified. If the UART port is not working as expected, does the design differ in any way from the dev kit? If so, then the PINMUX spreadsheet probably needs to be used to create a custom device tree.
Essentially any non-plug-n-play device (of which the integrated UARTs are) cannot self-report what it is or what settings to use. The device tree is used to pass the physical address to the driver and set up options. If this is partially set up correctly, then probably on command line you could change settings to what you want, but you might consider just setting up the device tree for that UART to your specific setting requires as a default. Then you wouldn’t need to worry about changing settings.
I will say that once UART speed goes above 115200, that the clock may not be accurate enough, and you might need to use two stop bits. This is true even if the UART is set up correctly. Speed 460800 might work without two stop bits, but some errors might be related to needing two stop bits. Still, it is very unlikely DMA would be related to this…if the clock is slightly off, then you’d merely experience data issues. The device tree tends to be the likely culprit for DMA issues.
UART is derived from the xavier core board and does not involve external circuits. Does the device tree need to be modified?
It’s an accident. There’s no way to recurring it
If 100% of all wiring for the UART is an exact match to the dev kit, then the device tree should be ok. If there is any difference in wire routing at all, then the device tree needs to be modified to tell the driver how to find and use that device with the different wiring. Is there an exact 1-to-1 correspondence in wiring between the dev kit carrier board and the custom carrier board (at least with respect to power delivery and serial port wiring)?
Our hardware colleagues confirm that there is an exact 1-to-1 correspondence in wiring between the dev kit carrier board and our custom carrier board.
Any suggestion about UART DMA?
If the UART in question is indeed the “serial@3140000” mentioned in the screenshot of the original post (the device tree), then I don’t know what the issue would be. The “dma-names” appears to be consistent. If for some reason this isn’t really the UART at physical address 0x3140000, then I suppose you’d need to look at a different location in the device tree.
Also, if power delivery to the UART has changed, then this would fail, but I suspect it would not be a DMA error.
One thing I would suggest is to put that UART in loopback mode with TX wired to RX, and see if a simple terminal program can echo to self without error. DMA error is unlikely related to any external device, but it is easy to check.
Hi,
Did you fixed your issue? We are seeing the exact same error on tegra serial dma.