Suspend Investigation with a Reboot Bonus


I figured out why my Pyra was draining the battery like crazy and getting super hot in my case sometimes. It was waking when the shoulder buttons were pressed! I added some more Device Tree edits to unset those buttons as wake triggers, and it works. I added that to the first post, and finished explaining how to create the service, in case that helps. I also updated the attached dtb so it includes the button changes.

Please test, I'd love to know if this works well for others. Also feel free to ask ANY questions.
 
This is awesome thanks Johnic. My question is: is there eg an apt command I can run to pull in these enhancements?
 
Well, I know how pleasurable scripting can be, so I say go for it. In general I'm interested in incrementally updating my pyra. Re-flashing has been a bit of a PITA (so far)
 
I'm working out the script now. The script seems to do everything I need, but I found the fix DOES NOT work on Debian 10 buster on the EMMC. I get the same issue Farox did. I'm not sure why it seemed to work initially but fails now. I can fix it, then apply the DTB, and it reliably breaks booting on buster. I need to find a spare SD card to see if it breaks buster there, too, or maybe I should install bookworm on my emmc and see if that works.

Nobody said this was going to be easy. One step at a time...
 
I found that I didn't need the lines in the DTS that disable &mmcmux. Keeping just the &{/txs02612} lines works, so I removed that part from the first post, and updated the pre-compiled dtb attached there.

Here's the script. Only run it if you boot from an SD card and run bookworm, for now. I commented out some logic that tests for the buster boot folder, since it has a different name. Just rename it to suspendFix.sh, then run
Code:
chmod +x suspendFix.sh

You need the gzipped dtb file from the first post in the same directory as the script. You'll be able to run it once those conditions are met. Once you shut down and power back on, you should be able to suspend and reboot.

Any feedback on the script is helpful. Again, I don't know what I'm doing, and am learning as I go.
 

Attachments

Does anyone use Buster still? Haven't we migrated to Bookworm fully yet?
Not sure. I definitely had Buster on my eMMC, still. Turns out the Debian version doesn't matter, anyway. After some more investigation, it seems that this just doesn't work with eMMC installs. :(

I installed bookworm on my eMMC, and had the same issue, where it doesn't boot. It can't find the eMMC:
Code:
Gave up waiting for root filesystem device. Common problems:
- boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait long enough?)
- missing modules (cat /proc/modules; ls /dev)
ALERT! PARTUUID=84dod9b1-02 does not exist. Dropping to a shell!

I'm looking into other options for the TXS02612 in the device tree that will work. In the meantime, at least SD users can have working suspend and reboot, if anyone is willing to test it out.
 
Last edited:
I have also Buster on my eMMC as other OS releases didn't work better than this old IMHO, but i must admit that i've not tested very deeply.
I installed bookworm on my eMMC, and had the same issue, where it doesn't boot. It can't find the eMMC:
Gave up waiting for root filesystem device. Common problems: - boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - missing modules (cat /proc/modules; ls /dev) ALERT! PARTUUID=84dod9b1-02 does not exist. Dropping to a shell!

Yeah the same issue i had, fortunately is possible to revert back.
 
Maybe a stupid question, but is there a real advantage of having the OS on the eMMC? Obviously the eMMC is much faster, but I have the latest OS on the SD and an old one on eMMC. I assume people put their applications on an SD-card, so impact on loading would only be when turning on the Pyra, right? And I'm not really worried about the current boot time.
 
Maybe a stupid question, but is there a real advantage of having the OS on the eMMC? Obviously the eMMC is much faster, but I have the latest OS on the SD and an old one on eMMC. I assume people put their applications on an SD-card, so impact on loading would only be when turning on the Pyra, right? And I'm not really worried about the current boot time.
You don't block one SD card slot. That is an advantage for me...
 
On the Pandora the main limit of the NAND was the small size, so it was a no brainer to use SD for almost everything needed by the OS, but with the Pyra there are gigabytes of space that can be used at least for libraries and applications that doesn't fit well on external supports.

This way the SD can really be an interchangeable support filled with only DBPs.
 
Back
Top