UART not work when TX1 wakes up from suspend

I’m using R28.2, and the UART ttyS2 works well.
And I put the system into suspend mode via
sudo pm-suspend

Then I wake-up the system via “wake up on LAN”,
the system recovers, audio / video / network seems work well.
But the UART ttyS2 not work at all.

there’s no echo no response on the console port until reboot the TX1.

Can somebody help?

There are two drivers possible in each of the Tegra UARTs. One is traditional (e.g., like 16550A), the other is “high speed” (in device tree the “hs” variant). When using the traditional driver the naming convention is as you have mentioned, “/dev/ttyS#”. When using the high speed DMA-capable driver, then the device naming changes to “/dev/ttyTHS#” format.

The reason the serial console uses “ttyS0” instead of “ttyTHS0” is because the driver has to remain in service in both U-Boot and the Linux kernel, but U-Boot has only the traditional driver and has no understanding of the DMA-capable version. Part of the life of boot would be missed if the Linux kernel used the “ttyTHS0” version since the UART itself would be reloaded with a new driver and the transition time would be missing.

You would also never want to mix using the same UART with two drivers simultaneously (some undefined error or bad behavior). Normally all access to the UARTs, other than for serial console “ttyS0”, is via the “ttyTHS#” format.

Can you specify if “ttyS2” is being used for serial console? Knowing this could change the nature of the question.

Yes, ttyS2 is my serial console.
Just enable it in DTS and cmd-line arg.

Some releases have different procedures for adding a device tree. Also, you would probably have to modify both the “serial@” blocks of the device tree and the “chosen” command line (also the device tree). There is also likely a modification needed for U-Boot stage or early boot stages via one of the “.cfg” files, but I’m not positive of what that is on a TX1.

Would you please post the exact changes you made to device tree and any config files? Does the serial console work in the U-Boot stages prior to loading the kernel?

For routing to ttyS2, I did 2 modifications only.
And as you mentioned this is not work in U-boot stage or early boot stages.
(I’m also interested in how to rout ttyS2 in those stages)

In file

serial@70006200 {
compatible = “nvidia,tegra210-uart”, “nvidia,tegra114-hsuart”;
status = “okay”;


CMDLINE_ADD=“console=ttyS2,115200n8 console=tty0 OS=l4t fbcon=map:0 net.ifnames=0 no_console_suspend”;

Someone from NVIDIA will need to comment…basically this URL is an exact match, but it is for TX2 instead of TX1, and for R28.1 (much is different in boot stages between R28.1 and your R28.2, and also between TX1 and TX2):

It is also possible the device tree changes and command line changes are the same for the TX1 even with later releases, but the flash of device tree is different, and the specific “.cfg” file will also differ.

FYI, the “t186” implies a TX2, the TX1 is generally the “t210”.

Hi chrischang0921,

Check WOL function and UART are working on TX1/R28.2
List my steps for you reference:

sudo apt-get install powerwake
[Tegra device]
sudo apt-get install ethtool
sudo ethtool -s eth0 wol g
sudo ethtool eth0      # verified the eth0 settings
sudo pm-suspend
[WOL from host]
powerwake xxx.xx.x.x   # IP address

After wake up and check the UART, it’s working without problem.

Hi Carol:

I installed the ethtool on my TX1, and waked the TX1 via “mc-wol” on a Window PC.

CMDLINE_ADD="console=ttyS0 …
The log never stops via ttyS0 port.

CMDLINE_ADD="console=ttyS2 …

ttyS2 will not tell anything when TX1 wakes from SC7.


Sorry for I didn’t use “powerwake” due to
my Ubuntu PC shows

$ sudo apt-get install powerwake
Reading package lists… Done
Building dependency tree
Reading state information… Done
E: Unable to locate package powerwake

Can somebody help?

If you first run “sudo apt update”, what do you see from:

apt search powerwake

Also, I have extra repositories uncommented, not sure if it is one of those. For comparison, what do you see from:

egrep '^[^# ]' /etc/apt/sources.list /etc/apt/sources.list.d/*

Hi linuxdev:

Thanks for your reply.

Actually the problem (ttyS2 not work)not only happens to WOL
but also other wake-up events, such as CEC …

I have to wonder if something for wake is still tied to ttyS0 after moving console to ttyS2. However, I don’t know enough about wake to say. Would anyone know if there is a specific hook in serial console over ttyS0 which might not follow when changing to ttyS2, e.g., a power rail?

Anybody home?

Can somebody help?

I don’t personally know how the wake function deals with power rails, and how the rails may differ between the UART for ttyS0 and ttyS2. I suspect that this is the issue, but I don’t know how to test. There may be a location in “/sys” which can verify if a rail tied to ttyS0 or ttyS2 UARTs is up or down at the moment. This is long because I’m experimenting rather than going straight to a known answer, and more or less naming steps to examine in the hope of finding something.

Just as an experiment (this is actually on a TX2, but the L4T version and addresses of UARTs should be the same), first identify where that UART has its “/sys” exports:

sudo find /sys -name ttyS0

In this case one location, which mentions the serial itself, is “/sys/devices/3100000.serial/tty/ttyS0/”. Interestingly enough, I do see a “power/” subdirectory, and within that some “wakeup*” entries. I suspect that “wakeup” though is the reverse of what you are asking about, and perhaps only deals with activity on the UART causing wakeup. The “runtime*” might be of more interest, but I have no way of actually knowing, it’s all guesswork.

If I look at the same information for ttyS2 (or ttyTHS2), something changes. Take a look at this:
sudo find /sys -name ttyS2


Notice that it now says “serial8250” instead of an address.serial (e.g., “3100000.serial”). This is probably due to device tree, but again I’m just poking around and speculating. If I switch to the “/sys/class/tty/ttyS<change to 0 or 2 depending on ttyS0 or ttyS2>/power/” what I see seems to be more relevant.

So I’m going to propose an experiment. Before the tty goes away, save the output of this (you can ignore any error messages, it’s only the successful reads which matter), and then compare the output again after the port goes to unwakeable sleep:

sudo -s
egrep '.*' `find /sys -name ttyS2 | sed -e 's/ttyS2/ttyS2\/power\/\*/g'` | sort | tee /some/log/location/log.txt

What this will do is list all associated “/sys” files for ttyS2, grep for content in the “power” subdirectory, and thus name the file on the left and the content of the file on the right, and then sort it (sort is important for later on when doing a diff). The “tee” just lets you log what you see (it leaves the log file location up to you).

Assuming you have a “log_before_sleep.txt” and a “log_after_sleep.txt”, then you can see what changed via:

diff -c log_before_sleep.txt log_after_sleep.txt

If you find something suspicious which we can relate to a device tree entry, then we might be able to to figure it out just from the device tree. If not, then someone from NVIDIA will have to comment on what internally sets up, sleeps, and restarts a serial UART as console…and why ttyS0 works, but not ttyS2.

Can you post a copy of the before and after logs? If you hover your mouse over the “pencil” icon in the upper right corner of an existing post, then a paper clip icon will show up…you can attach a file to an existing post via the paper clip icon.

Thanks for your reply.
Sorry for my late reply.

I put my log in
ttyS0.txt (60 Bytes)
before-suspend.txt (1.42 KB)

ttyS2.txt (60 Bytes)

I don’t see anything changing in what “/sys” reports before/after suspend. Whatever changes from suspend/wake apparently isn’t shown in “/sys” exports. I think someone from NVIDIA is going to have to reproduce this move of console on ttyS0 to ttyS2 and see if something more obscure is going on.

THKS , linuxdev