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.
 
I cleaned up the script a bit, and un-commented the fix for Buster installs. I haven't tested it there, but as long as you're booting from SD, it should work. Please let me know if you test it!

I have the beginnings of a plan to fix eMMC booting without the TXS02612 using gpio-hogging. I'll play around with that and see if I can get it working. That may open up the possibility of using the uSD slot instead of eMMC, but one step at a time. That would likely require different dtbs depending on if one wanted eMMC or uSD functionality. A man can dream...
 

Attachments

Farox or any other willing test subjects, if you're willing to try again, the dtb attached here should make suspend work on eMMC. It does for me.

Reboot still fails somehow, oddly. I haven't had time to see what's so different yet.

The script just above this message will do everything you need, if it and the .dtb.gz are in the same directory.

My dts changes are now:
Code:
/* Disable the txs02612 to make Suspend and Reboot work
*  also select the emmc port manually */
&gpio3 {
    emmc_sel_hog {
        gpio-hog;
        gpios = <18 0>; /* Pin 18, flags 0 for active-high */
        output-low;
        line-name = "emmc_sel_perm_on"; /* For clarity in sysfs */
    };
};


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



/* Stop the shoulder buttons from waking from suspend */
&{/pyra-game-buttons/left_shoulder_bottom} {
    /delete-property/ gpio-key,wakeup;
};

&{/pyra-game-buttons/left_shoulder_top} {
    /delete-property/ gpio-key,wakeup;
};

&{/pyra-game-buttons/right_shoulder_bottom} {
    /delete-property/ gpio-key,wakeup;
};

&{/pyra-game-buttons/right_shoulder_top} {
    /delete-property/ gpio-key,wakeup;
};
 

Attachments

I realized I'm being a little cavalier here, asking people to test the dtb on their eMMC install without detailing how to revert the change if it goes wrong. Sorry for that. I'm lucky Farox had an SD install that he could boot to in order to rescue his eMMC install. I don't want anyone to lose data or anything.

I'll get something written up for how to un-break your OS before I work more on cleaning up/improving anything with the fix.

The simplest way to ensure you're not stuck is to have that SD OS ready to go before trying anything that could jeopardize your only OS install. This has a link to the images, and shows how to set up your SD card. It's really easy to do it all on the Pyra.
https://pyra-handheld.com/wiki/index.php/Manual#Pyra_images
 
asking people to test the dtb on their eMMC install without detailing how to revert the change if it goes wrong.
Justdoit.jpeg
 
Back
Top