johnicboom
Fresh as a buzzard
Some time back, Discord user jurop#88 posted this to the pyra-dev channel:
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:
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.
Here's what I did.
Install the necessary software (I'm not sure this is all really essential):
Clone the pyra-kernel repo:
Edit the dts file in your favorite editor. It's this one:
Add this at the bottom, then save and close:
Compile the dtbs:
Find your dtb files in your /boot/ directory. Mine are at (on my SD card, running Debian bookworm):
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.
It's a good idea to back up your current dtb file to simplify undoing any changes you've made:
Copy the updated dtb to the dtb directory found in the step above. For me, that command was:
Reboot.
Now if you check dmesg again, you should find no mention of TXS02612:
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:
I thought a simple solution would be to create a systemd service that restarts the pyrainput service automatically, and it seems to work:
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:
So it was only restarting the pyrainput service automatically once per boot, and I had to manually type
every time I woke the Pyra from suspend.
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:
This thread will be dedicated to my own experimental device tree tweaks in regards to voltage and frequency. It is based on the fantastic work that you can find here: 20*C Cooler, and now with water resistance!
I decided to make a new thread so that my files will not get lost in a huge pile of posts and I have a place where I can keep all my observations in one place.
CAUTION: Everything that is deemed as "stable" is the be treated as "stable enough" for me to run my Pyra, use it for web browsing and Discord.
@hns , this is a comprehension of all the things I figured out...
I decided to make a new thread so that my files will not get lost in a huge pile of posts and I have a place where I can keep all my observations in one place.
CAUTION: Everything that is deemed as "stable" is the be treated as "stable enough" for me to run my Pyra, use it for web browsing and Discord.
@hns , this is a comprehension of all the things I figured out...
- Askarus
- Replies: 27
- Forum: Pyra OS (Debian GNU/Linux)
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'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.
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.
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
Last edited: