Suspend Investigation with a Reboot Bonus


johnicboom

Fresh as a buzzard
Joined
May 3, 2016
Messages
86
Age
42
Location
Chicago, IL, USA
Some time back, Discord user jurop#88 posted this to the pyra-dev channel:
It does not work due to issues with TXS02612 driver. Since muxing of internal uSD and uMMC is not working anyway, it is enough to disable the component in the DT to have a functional (albeit not optimized) suspend. The AS5013 driver (nubs) has no configuration for power management. The simplest workaround is just to restart the pyrainput service when exiting suspend.

I finally have a chance to check it out. I don't really know what I'm doing, but Askarus showed me how to edit the Device Tree on this thread:
...so let's jump in!

Basically, it seems that jurop#88 was right! I disabled muxing using the device tree, and Suspend seems to work now, and Restart seems to have come along for the ride. I haven't been able to automatically get the nubs to work again, so hopefully someone can lend a hand there. Or maybe I'll get it eventually. (Edit - I got it!)

I'm running Debian 12 bookworm on my SD card, but as luck would have it, I mistakenly copied my modified dtb file to the emmc's boot partition while bumbling my way through this process, so I can confirm that I can still boot from emmc, too, though I haven't tested anything else on that install.

The only reliable way I found to tell if I really disabled the TXS02612 device was by checking:
Code:
sudo dmesg | grep mmc

Before making the changes in this post, at about 1.5 seconds, there is an error referencing that device. After replacing the dtb file and rebooting, that error is gone. There may be a better way to check.

I attached the dtb file I compiled if you'd like to skip that part.

Here's what I did.

Install the necessary software (I'm not sure this is all really essential):
Code:
sudo apt install git build-essential flex bison libyaml-dev

Clone the pyra-kernel repo:
Code:
git clone --depth 1 https://dev.pyra-handheld.com/packages/pyra-kernel

Edit the dts file in your favorite editor. It's this one:
Code:
~/pyra-kernel/arch/arm/boot/dts/omap5-letux-cortex15-v5.3+pyra-v5.3.dts

Add this at the bottom, then save and close:
Code:
&mmcmux {
    status = "disabled";
};

&{/txs02612} {
    status = "disabled";
};

Compile the dtbs:
Code:
cd ~/pyra-kernel/
make pyra_defconfig dtbs

Find your dtb files in your /boot/ directory. Mine are at (on my SD card, running Debian bookworm):
Code:
/boot/dtb/linux-image-5.6.19-pyradef

The compiled dtb files get dumped in the same location as the dts files (~/pyra-kernel/arch/arm/boot/dts). The compile step created lots of dtb files, but we only need to replace the one we updated.

*** Start here if you are using the attached dtb. If you compiled your own, you can skip this. You'll need to run this to get the dtb:
Code:
gunzip omap5-letux-cortex15-v5.3+pyra-v5.3.dtb.gz

It's a good idea to back up your current dtb file to simplify undoing any changes you've made:
Code:
sudo cp /boot/dtb/linux-image-5.6.19-pyradef/omap5-letux-cortex15-v5.3+pyra-v5.3.dtb /boot/dtb/linux-image-5.6.19-pyradef/omap5-letux-cortex15-v5.3+pyra-v5.3.dtb.bak

Copy the updated dtb to the dtb directory found in the step above. For me, that command was:
Code:
sudo cp ~/pyra-kernel/arch/arm/boot/dts/omap5-letux-cortex15-v5.3+pyra-v5.3.dtb /boot/dtb/linux-image-5.6.19-pyradef/omap5-letux-cortex15-v5.3+pyra-v5.3.dtb

Reboot.

Now if you check dmesg again, you should find no mention of TXS02612:
Code:
sudo dmesg | grep mmc

At this point, you should be able use Restart from the Pyra's power button menu and have it function normally. Suspend will work, but as jurop#88 mentioned, the nubs won't work when you resume.

What works for me, is to manually restart the pyrainput service using the terminal:
Code:
sudo systemctl restart pyrainput

I thought a simple solution would be to create a systemd service that restarts the pyrainput service automatically, and it seems to work:
Code:
[Unit]
Description=Restart pyrainput service after suspend
After=suspend.target

[Service]
Type=oneshot
Environment="DISPLAY=:0"
Environment="HOME=/home/john"
Environment="USER=john"
ExecStart=/bin/systemctl restart pyrainput


[Install]
WantedBy=suspend.target

Can some Pyra owners please see if this also works for you?

I haven't done much testing so far, but suspend power usage seems to depend on what was open when I suspend. When I only had the terminal open, I saw between 2-3% battery drain in an hour. With Vivaldi also open, I saw 5% in an hour. These were NOT good tests, I still need to do some better testing in the next few days.

Also, if you suspend and then close the lid, the lid closing event wakes the device. I also haven't tested suspend automatically when the lid closes enough to say anything about it.



Update: It looks like I caused my service to only work once per boot with my RemainAfterExit=yes line...

I edited the content above with the correct service contents, removing that line and removing a commented out sleep line, since it wasn't necessary. I initially had this as my service:

Code:
[Unit]
Description=Restart pyrainput service after suspend
After=suspend.target

[Service]
Type=oneshot
Environment="DISPLAY=:0"
Environment="HOME=/home/john"
Environment="USER=john"
#ExecStartPre=/bin/sleep 1
ExecStart=/bin/systemctl restart pyrainput
RemainAfterExit=yes

[Install]
WantedBy=suspend.target

So it was only restarting the pyrainput service automatically once per boot, and I had to manually type
Code:
sudo systemctl restart pyrainputservice
every time I woke the Pyra from suspend.
 

Attachments

Last edited:
I'll try this when I find more time, I'm really interested.

Did you noticed also the device to be less hot ?
Yes, when it's suspended, I'm pretty sure it cools down. My USB ports are usually warm/hot to the touch, and while testing yesterday, I noticed they were cool after it was suspended for a while.

My tests so far this afternoon, using auto-suspend when I close the lid (set in Mate's GUI Power Manager), showed a consistent 3% battery drain per hour (3 tests) with only the terminal open. I should have closed everything, but I was still also making sure the nubs come back every time. So far so good on that front - it looks like the systemd service works great.

Right now, I'm spending an hour testing charging while suspended, since I was curious (and wanted to have ample battery for my train ride home, which will be a good test of actively using suspend while the Pyra is doing things). Tomorrow, I'll have it charged up in the morning and see what a full work-day of suspend does for the battery level.
 
I only tested suspend charging a little bit, but it does work. That was with the normal micro-USB port (debug), not the micro-USB 3.0 (wide cable) port. That does slower charging. I'll test charging with the wide port tomorrow.

For the these tests, I had Syncthing running in the background, but it was only syncing my text file with the below info, and Pluma, where I was recording the measurements. Wifi is on (it disconnects on suspend, reconnects on wake), BlueTooth is off, Conservative CPU governor.

A full 8 am to 5 pm workday of suspend, and I have 55% left. That's a HUGE improvement over no suspend. My Pyra would have normally died by now, for sure.

Code:
Battery Percent | 24-hour time | charging state from that measurement to the next
53% 1625
50% 1643 sleep charging
77% 2050 sleep charging
87% 0800
83% 0900
79% 1000
76% 1100
72% 1200
69% 1300
65% 1400
62% 1500
58% 1600
55% 1700
 
A full 8 am to 5 pm workday of suspend, and I have 55% left. That's a HUGE improvement over no suspend. My Pyra would have normally died by now, for sure.

This is awesome work! Thanks a lot for taking the time to sort this issue. It's a pretty big one.
 
First thanks @johnicboom for your work.

I'm in trouble now...i wanted to test this new dtb on the system NAND (and made a backup .bak of the dtb ) but now i'm stuck at boot.
see attached pic...

Now how i could replace my working dtb?
i try with a SD-Card with bookworm image but it didn't see the nand partition.
Do i need to re-install everything?

Thanks for your help
IMG_20250810_161219053.jpg
 
From there you should be able to run some commands to check what is the actual hardware situation, for example "df -h".

Try also to run manually the commands listed in the error messages, like "cat /proc/cmdline" and "cat /proc/modules".

Have a look at the structure of the /dev tree, etc...

To at least see if there's something visibly wrong, or if it's just a timing issue
 
also, in the "/proc/cmdline" right now there should be an argument like this:
"root=PARTUUID=84d0d9b1-02"

try to change it to "root=/dev/sda<NUMBER>" (I don't remember the number of the NAND ...)
 
thanks @PowerGod

but i can't seems to type all the keys that use Fn (orange key) so no - and no / for example
regarding the modules it isn't loaded because the dtb is for a different linux image and did not find the correct modules (i think).
Regarding the root partition how can i access it ?
 
but i can't seems to type all the keys that use Fn (orange key) so no - and no / for example
have a look at this
 
sorry don't work CTRL+SHIFT+U did do nothing if i type something and press the combo it erase the line
Post automatically merged:

@hns maybe could help? thanks
 
try to mount it (pressing TAB it automatically add /)
mount /dev/mmcblk0p2
but tell..
mount: can't find /dev/mmcblk0p2 in /etc/fstab
Post automatically merged:

an
ls etc/fstab
say
etc/fstab
 
First of all, "mount" without additional parameters is not able to determine how to mount a partition without some existent configuration files, those maybe are not still accessible from initramfs, so that error could be normal.

For now you should try this commands to see if it magically can fix things:

Code:
fsck /dev/mmcblk0p2
reboot

WARNING !! Most probably the reboot will not work and will just turn off everything visible but will not shuts off the device, so just wait a bit and then keep pressed the power button for some (maybe a lot of) seconds, to force shut down. Then turn it on again and see what happens.
 
Also I'm curious to see the result of this command, it should return the UUID of all the devices you have.

Code:
sudo blkid

there should be at least one that corresponds to the one that it's trying to load
 
Oh, no! I'm so sorry Farox! :'( My Pyra boots fine with that dtb file on the buster image, so I wonder what's going on.

If you have an SD card that you can flash a bootable image on, as long as you have the standard dtb file, you will see the emmc /boot/ in /media/. This is where you can see the files you're looking for (replacing /john/ with your own username):
/media/john/boot/dtb/linux-image-5.6.19-daveiii-pyradef-aufs/

I can even see that location in my file browser, under devices on the left:
1754874968041.png


It'll just ask for your password to view the files (where you can also see that it's /dev/mmcblk0p1 on my system):
1754875101732.png
 
Back
Top