Hi All,
I’m seeing something very strange with my tx2 on my dev board. When I put it to sleep using a ssh connection over ethernet, the uart console tttS0 is enabled, it wakes up ok using the rtc as a wake source.
When I disable the uart console however, & put it to sleep in the exact same way, it looks like the Tx2 wakes up but it no longer connects to the ethernet, no lights on the connector or the hub. The only signs of life are the other leds on the board, chiefly the green led by the “SOC” button.
Is there something to do with the tx2 wake process that relies on the debug console enabled on uart?
hello hannaBarbera,
may I have more details about how you disable the UART console. did you have kernel modification to disable that?
besides, may I know which JetPack release you’re working with.
thanks
I edit the cboot args so “console=ttyS0,115200” doesn’t appear as part of my system.img. Then whenever I want the console on or off I add/remove that string to /boot/extlinux/elinux.conf.
Will update jetpack version later.
Hi hannaBarbera,
What’s suspend command are you using?
Please try below pipeline:
$ sudo systemctl suspend
Yup! That the command I use.
Another UART/suspend issue.
I’m using the UART coming from D5/D8. I’ve editing the bpmp dtb so console=0xff as opposed to the original console=7. Whenever /dev/ttyTHS6 is open and the system is suspended, the whole System seems to crash! No further entries in syslog etc. So it doesn’t look like it goes into suspend & never wakes.
Any ideas? I know that port is SPE debug, is it possible there’s an internal quirk of the TX2?
update;
This is a device tree I’m using with only jetpack 4.2.1 installed
#include "tegra186-quill-p3310-1000-c03-00-base.dts"
#include "gpioexp.h"
/ {
nvidia,dtsfilename = "tegra186-quill-p3310-mySerialSleepBug.dts";
nvidia,dtbbuildtime = __DATE__, __TIME__;
nvidia,boardids = "3310:0000:C03";
nvidia,proc-boardid = "3310:0000:C03";
gpio-keys {
power {
/delete-property/ gpio-key,wakeup;
};
volume_up {
wakeup-source;
linux,code = <0x13>;
};
volume_down {
linux,code = <0x21>;
wakeup-source;
};
};
//Move debug comms off UART1_on_SOM (D9/10)
serial@3100000 {
/delete-property/ console-port;
};
/* Disable unused stuff inherited from nVidia base DTS included above */
/delete-node/ plugin-manager;
#if 0
serial@c280000 {
compatible = "nvidia,tegra20-uart", "nvidia,tegra186-hsuart";
status = "okay";
console-port;
};
#endif
chosen {
bootargs = "androidboot.presilicon=true firmware_class.path=/etc/firmware";
stdout-path = "/serial@c280000:115200n8";
};
};
When I use this the system goes to sleep ok with a systemctl suspend. I can see LEDs on the devkit come on when I press VOL as I’ve set it to be a wake source, but the system does not fully wake. It doesn’t re-establish a network link over ethernet, neither does it establish a link over USB OTG.
Can someone from Nvidia explain why the TX2 only seems to wake fully when the debug serial is enabled on ttyS0? (I’ve been able to successfully move the debug console to other serial ports yet the the problem remains).
It’s critical I achieve this, the serial port is exposed to an external connector on a custom carrier board & needs to be used for other purposes than debug.
FYI
nvidia@mySerialSleepBug-Host:~$ cat /proc/cmdline
root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 fbcon=map:0 net.ifnames=0 video=tegrafb no_console_su
spend=1 earlycon=none nvdumper_reserved=0x2772e0000 gpt usbcore.old_scheme_first=1 tegraid=18.1.2.0.0
maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.2031647.1 bl_prof_dataptr=0x10000@0x275840000 sdhci
_tegra.en_boot_part_access=1 quiet
For network not restarting, what happens if you then run this command:
sudo systemctl restart networking.service
don’t think that’s an option in this case:
can’t type that in over ssh, no network connection; can’t type it in over debug serial on ttyS0, it’s disabled on purpose; even if serial debug is moved to another serial port, it doesn’t come up post sleep, hence why it looks like a jetson fault; lastly I can’t even embed said instruction in a systemd wake script, already have one of those in operation & it’s not triggering.
any thoughts @carolyuu & @JerryChang?
That’s a tough problem, but you might test something simple to see if it really woke. When you enter more than one command on the command line separated by semicolons, each one will execute in series. I am wondering what would happen if you tell it to suspend, and then have a command to wait 30 seconds (or more, just making up a round figure), followed by the command for network reset. Like this:
sudo -s
systemctl suspend; sleep 30; systemctl restart networking.service
The idea here is that when suspend starts those other commands will be in queue. The sleep just says that if the system takes a moment to suspend you won’t accidentally already be executing the network restart. If the system truly wakes up, then it should complete the sleep for 30 seconds, followed by running the command to restart networking. If you suspend this way, and manually wake it up a few seconds later, and then ping and/or ssh begins to function in about 30 seconds, it will imply the system is truly up and running. Just an experiment, but if it works, it could provide a mechanism back in after suspend until the real cause is found.
Tried it, no change. Really looks to me like the TX2 crashes/hits a hardware fault.
I doubt it is a hardware issue, but it does seem that some of the hardware going into suspend never wakes, e.g., the serial console. It should of course wake, but I’m not sure what to do to force all hardware to wake when the outside world has no way to interact to do so.
Hello,
There is a 8-month (March/Novmeber) gap between your first post and the follow-up. Please file a new topic and describe latest status again.