Continuing the discussion from TX2 NX uartc Some data was lost during reception:
We have made some new discoveries regarding this issue, which appears to have been introduced after version 32.7.3, as we did not observe this issue in the system image for version 32.7.3.
Hi huangliedouble,
Did you try porting the serial driver from R32.7.3 to R32.7.6 just to see if the driver is the problem?
I’m sorry, I was just testing this and realised that my earlier finding was due to an error on my part; in fact, the same issue occurs in version 32.7.3 as well.
I’ve made a new discovery: I found a core board whose serial port was actually working properly. I then backed up the system using the command sudo ./flash.sh -r -k APP -G ../backup.img jetson-xavier-nx-devkit-tx2-nx mmcblk0p1, and flashed it onto the new core board, but the new core board isn’t working properly.
Just to clarify further, I’ve managed to find some more A03 boards, but restoring the image from a working board onto these A03s hasn’t resolved the issue; the same problem persists.
I’d also like to apologise for the correction: it seems this has nothing to do with the version. I’ve checked all the historical versions we’ve used and found that they all have the same issue. I still don’t know why one board was unaffected, given that we used the exact same programming environment.
Could you compare the dmesg and device tree for both working and failed modules?
And also, check the following result:
$ cat /etc/nv_tegra_release
$ cat /etc/nv_boot_control.conf
Normal output is as follows:
mr123@mr123-desktop:~$ cat /etc/nv_tegra_release
mr123@mr123-desktop:~$ cat /etc/nv_boot_control.conf
TNSPEC 3636-301-0001-H.0-1-0-jetson-xavier-nx-devkit-tx2-nx-mmcblk0p1
COMPATIBLE_SPEC 3636–0001–1–jetson-xavier-nx-devkit-tx2-nx-
TEGRA_CHIPID 0x18
TEGRA_OTA_BOOT_DEVICE /dev/mmcblk0boot0
TEGRA_OTA_GPT_DEVICE /dev/mmcblk0boot1
Abnormal output is as follows:
mr123@mr123-desktop:~$ cat /etc/nv_tegra_release
mr123@mr123-desktop:~$ cat /etc/nv_boot_control.conf
TNSPEC 3636-300-0001-J.0-1-0-jetson-xavier-nx-devkit-tx2-nx-mmcblk0p1
COMPATIBLE_SPEC 3636–0001–1–jetson-xavier-nx-devkit-tx2-nx-
TEGRA_CHIPID 0x18
TEGRA_OTA_BOOT_DEVICE /dev/mmcblk0boot0
TEGRA_OTA_GPT_DEVICE /dev/mmcblk0boot1
The device tree and kernel have been verified and are consistent.
I noticed a discrepancy in the line TNSPEC 3636-300-0001-J.0-1-0-jetson-xavier-nx-devkit-tx2-nx-mmcblk0p1. What does this mean?
As a follow-up, the core board listed below also doesn’t work: root@mr123-desktop:/tmp# cat /etc/nv_boot_control.conf
TNSPEC 3636-302-0001-C.0-1-0-jetson-xavier-nx-devkit-tx2-nx-mmcblk0p1
COMPATIBLE_SPEC 3636–0001–1–jetson-xavier-nx-devkit-tx2-nx-
TEGRA_CHIPID 0x18
TEGRA_OTA_BOOT_DEVICE /dev/mmcblk0boot0
TEGRA_OTA_GPT_DEVICE /dev/mmcblk0boot1
300 is the FAB, J.0 is the REV.
They may use the component from different manufacturers.
Basically, they should not affect the behavior of serial.
Have you also compared the dmesg and device tree in both cases?
Are you using serial@c280000(uartc) for custom use case?
The DMESG and device tree are consistent.
The serial port is /dev/ttyTHS2 (uartc), serial@c280000
It’s worth noting that I cloned the partition directly from a standard core board. I believe that, at least from a software perspective, the two core boards are essentially identical. Is that a fair assumption?
It seems the UART interface used for combined UART to output the logs from several firmwares.
Are you using it for custom serial use case?
If so, could you try use other UART interface instead?
Yes, they should be identical if it is cloned from another working board.
Actually, I am using another serial port, /dev/ttyTHS1, which works fine. The problem is that I sometimes have to use both serial ports at the same time, so this issue cannot be avoided.
We don’t suggest using UART-C for custom use case as it will output logs from several firmwares.
There should be other UART interfaces available as following captured from your dmesg.
[ 5.868547] 3100000.serial: ttyS0 at MMIO 0x3100000 (irq = 32, base_baud = 25500000) is a Tegra
[ 5.960933] 3110000.serial: ttyTHS1 at MMIO 0x3110000 (irq = 33, base_baud = 0) is a TEGRA_UART
[ 5.961711] c280000.serial: ttyTHS2 at MMIO 0xc280000 (irq = 34, base_baud = 0) is a TEGRA_UART
[ 5.962540] 3130000.serial: ttyTHS3 at MMIO 0x3130000 (irq = 35, base_baud = 0) is a TEGRA_UART
We should have already checked the documentation and disabled other print jobs; currently, there is no print output other than the U-Boot printout at startup.
I also noticed that there are a total of four serial ports: one is a debug port, two are the ones we’re using, and the remaining one, ttyTHS3, isn’t mentioned in our hardware documentation. I’ll look into it.
This serial interface is virtual, please disable it in the kernel device tree.