Serial port less reliable after upgrade to 35.1

[alban.deruaz]

Hello, we currently have a Jetson NX which is having degraded serial port performance after flashing L4T 35.1 using Jetpack 5.0.2.
On this NX, a sensor is connected to one of the serial ports (ttyTHS1, serial@3100000) at baudrate 460800. We are able to read this sensor with an excellent reliability on L4T 32.7.2 (each packet provided by the sensor contains a crc, and we had ~1 crc error every two hours or so.)

Now, after a fresh stock flash to L4T 35.1, the serial driver did not accept this baud rate because of rate tolerance issues (so a dmesg message said), so we had to change the device tree by changing the following line on the serial port block:

nvidia,adjust-baud-rates = <0 1000000 100>;

This permitted the baudrate 460800 to be accepted by the driver, however we now have several crc errors per second.
We are using the same reading code, same wiring and hardware.
There is error related to the serial port in dmesg.

We tried to change the final “100” tolerance value in the device tree (we tried 60, 100, 150, 200, 250) , without any noticeable impact on crc errors.
We tried different baudrates (921600, 230400), to no avail.
We reverted the device tree change above, those alternative baudrates were accepted by the driver, but no performance improvement.

Is there someting we can do to investigate further? I tried looking into the driver differences between those two L4T versions but many changes were made.

Thanks a lot for your help!

[linuxdev]

I think the clock is slightly off spec, and leads to more errors as speed goes up. Is it possible for you to check how well this works if you use two stop bits instead of the default one? Two stop bits will have an ability to survive with the clock being a bit more out of spec. None of this applies of course if you are using speeds below 115200 (I think this is the maximum reliable speed due to clock tolerances).

[alban.deruaz]

Thanks for your answer!
Unfortunately our sensor does not provide the option to change the amount of stop bits, we are stuck with 1, unless you meant to only switch to 2 stop bits on the jetson side?

Since that configuration worked well in 32.7.2, the hardware is capable of handling this situation, I don’t really understand this regression, unless some clock configuration / source changed in the device tree for that serial port?

[JerryChang]

hello alban.deruaz,

please check you’ve update device tree correctly.
it’s now loading dtb binary via FDT entry of /boot/extlinux/extlinux.conf.

[alban.deruaz]

Hello JerryChang,
I am indeed directly changing the device tree pointed by the FDT entry. I know it works as I tried removing entirely the nvidia,adjust-baud-rate line, and the driver complained in dmesg right after reboot.

[linuxdev]

There are cases where UART timing will not be close to required spec if the speed is above 115200. When you use two stop bits the timing requirement is relaxed. I’m suggesting that if you can use two stop bits it would be a good test when using speeds significantly above 115200.