Standby - Suspend to RAM (MNT Reform)

MNT Reform
66

I can confirm suspend (with ~100mA) works with pristine system-image-v3 built from Merge branch 'sysimage-v3' into 'main' (abaea71e) · Commits · Reform / reform-system-image · GitLab.

Now to find out what is causing my system to not suspend after installing a bunch of packages…

67

Looks like just an apt upgrade will cause suspend to stop functioning. It is updating a lot of packages including the kernel, so my guess would start there.

Is apt upgrade not recommended? I see it is pulling from “unstable” upstream Debian repo, so maybe not? But it is pulling from “Release” reform repo…

68

We suspect that kernel 5.18 breaks suspend. Sorry for the inconvenience. I’ll look into it soon.

1 Like
69

I’ve been poking at this, learning a lot along the way.
It seems resume is getting stuck on the hantro-vpu driver.
If you disable it before suspending, you can re-enable it after resuming (via rmmod and modprob). I can’t confirm it’s in a good state after this (in theory it provides video accel decoding for vp8, vp9, hevc, and h264), but it’s a temporary workaround.

5 Likes
70

I did a bit of testing and just unloading hantro_vpu with our default TFA and kernel does not make wakeup work for me. Can you tell us which TFA and kernel patches you pulled in?

Edit: not entirely true, I just set the UART wakeup sources manually before suspending and now I was able to wakeup. I think I’m missing the sleep/wake hooks from sysimage V3.

Edit 2: turns out I had reform-sleep.service disabled (and reform-hw-setup.service). After reenabling these and rmmod hantro_vpu, systemctl suspend and waking with Circle+Space works on kernel 5.18!

Edit 3: I tested it 10 times from within sway and had no wakeup failure so far.

3 Likes
71

I can confirm this works for me as well.
After disabling (rmmod) hantro_vpu I can suspend and resume without problems.

72

is everyone just disabling if via the reform suspend script?

73

I just ran rmmod hantro_vpu in the command line (as I am not using the driver).

You can put it in /usr/sbin/reform-standby (I think that gets triggered by systemctl suspend…).

74

and then calling the same command again upon resume turns it back on (in theory)?

75

To load the module back you should used mobprobe instead of rmmod.

Below is a modified script for /usr/sbin/reform-standby that removes the hantro_vpu module before suspend and loads it back after resume.

With this in place I can suspend with ‘systemctl suspend’ and resume with circle-space.

#!/bin/bash
#
# MNT Reform Standby Handler (For i.MX8MQ)
# Thanks to ruff for contributions
#
# Copyright 2022 MNT Research GmbH (https://mntre.com)
# License: GPLv2.0+
#

if [ "$EUID" -ne 0 ]
  then echo "reform-standby has to be run as root / using sudo."
  exit
fi

setup_wake() {
  # configure UARTs as wakeup sources
  echo enabled > /sys/devices/platform/soc@0/30800000.bus/30860000.serial/tty/ttymxc0/power/wakeup
  echo enabled > /sys/devices/platform/soc@0/30800000.bus/30890000.serial/tty/ttymxc1/power/wakeup
  echo enabled > /sys/devices/platform/soc@0/30800000.bus/30880000.serial/tty/ttymxc2/power/wakeup
}

wifi_off() {
  echo 1 > /sys/class/pci_bus/0000:01/device/remove
}

wifi_on() {
  echo 1 > /sys/class/pci_bus/0000:00/rescan
  sleep 1
}

kbd_backlight_off() {
  for d in /dev/hidraw*
    do echo -en "xLITE0" > $d
  done
}

kbd_backlight_on() {
  for d in /dev/hidraw*
    do echo -en "xLITE6" > $d
  done
}

hid_bind() {
  echo 0003:03EB:2041.0002 > /sys/bus/hid/drivers/hid-generic/bind
  echo 0003:03EB:2042.0001 > /sys/bus/hid/drivers/hid-generic/bind
}

hid_unbind() {
  echo 0003:03EB:2041.0002 > /sys/bus/hid/drivers/hid-generic/unbind
  echo 0003:03EB:2042.0001 > /sys/bus/hid/drivers/hid-generic/unbind
}

if [[ $1 = "suspend" ]]; then
  setup_wake
  wifi_off
  kbd_backlight_off
  rmmod hantro_vpu
  hid_unbind
fi

if [[ $1 = "resume" ]]; then
  modprobe hantro_vpu
  kbd_backlight_on
  wifi_on
  hid_bind
fi
2 Likes
76

as a note, this seems to only be working if your OS is on the SD card. seems like there is a separate issue where the pcie bus is not coming back up properly.

1 Like
77

Is there any chance that the likelihood of a hang has to do with the window manager in use? I’ve been playing around with GNOME and it automatically enters suspend after a period of time. Anecdotally it seems to wake far more reliably than when I use the suspend script in sway.

78

I am booting from the SD card but my root system is in the nvme drive. At least for now suspend is working after unloading the hantro_vpu driver.

1 Like
79

That would be my situation as well. Good to hear that it is successful. I would be interested if it always works. Right now suspend is about 90%. out of, say, 10 wakes, it will fail 1 time.

80

For completeness, here’s my workaround as a patch:

81

so basically do a apt upgrade (full-upgrade) and then make sure this patch is in place, and you should be golden?

82

The patch is not yet merged, but I can do it later today.

1 Like
83

I haven’t been able to test suspend at all due to a possible hardware or firmware issue that makes the circle+space command not work.
I’ve flashed the latest firmware on both the keyboard and LPC, but all I get when hitting circle+space is the following:

  1. Short (1-4s) message showing “Waking up LPC… 0%”
  2. Brief flash of the message “No response from LPC”
  3. Oled goes blank

At no point does the wake up sequence go abovee 0%, and the message doesn’t seem to make sense anyway, since the LPC is already on. I can view battery state just fine.

Anyone else running into this? Any diagnostic steps I could take?

84

I think I’m definitely seeing the 5.18 issue now after upgrading the other day. Suspend not working at all. How can I be sure I’m getting the latest reform-tools? I already uninstalled and reinstalled.

85

To check whether you have the suspend fix applied, check if your /usr/sbin/reform-standby has the hantro_off and hantro_on functions: sbin/reform-standby · main · Reform / MNT Reform Tools · GitLab

2 Likes