Waking up from suspend mode (4SE)

[José Guilherme]

Hello There!

 

I'm currently using a Rock 4SE, tagged it as 4B because armbian says I should use the version for the board.

 

I'm using a manually built image of armbian, though without any changes. I'm currently trying to figure out how to get faster boot times on SDDMC. So far:

1 - I've disabled some systemd services. Bluetooth related services have made a big difference.

2 - I've tried to disable USB and network support on U-Boot, though unsuccessful, in order to make U-Boot spend less time before booting the kernel. By applying some patches to U-Boot I got to the point where it either compiles and doesn't start the system because of some runtime error about drivers, or doesn't compile at all.

 

Now I'm currently trying to use suspend mode in order to get faster startup times... The problem is that I'm able to enter suspend mode, but I've got no idea on how to wake the system up. I've searched a lot but couldn't find any definitive answer, so I wanted to at least look for directions here. Here, on the armbian forums, I've seen people talking about modifying the devicetree... Though I have absolutely no idea about what changes should be made in that case. On radxa's forums, all I've seen is people asking but having no answers about how that would work... I'm still awaiting a reply of an e-mail I sent to dev@radxa.com.

 

Does the fact that the system supports going into suspend mode implies it has a way to wakeup? If so, is the devicetree the only thing that needs to be modified in order for it to wakeup? Can any GPIO be used for wakeup functionality? Or does it need to be a specific pin? Did anyone get a rockpi board to wakeup from suspend mode??

[Igor]

20 minutes ago, José Guilherme said:

I'm currently trying to figure out how to get faster boot times on SDDMC

This will spare you some: https://www.armbian.com/newsflash/code-freeze-and-moving-to-new-framework/

 

20 minutes ago, José Guilherme said:

Now I'm currently trying to use suspend mode

Many supports it on paper, but on very few SoCs actually works well. On each kernel upgrade, functions breaks down and all users care is complaining about, while we are loosing thousands of hours for keeping devices operational.

 

20 minutes ago, José Guilherme said:

I'm still awaiting a reply of an e-mail I sent to dev@radxa.com

 

If they are unable to answer on cheapest possible way to all at once, in public, (community forums are here to provide this support as any other is not possible), do you think they will answer on a lot more expensive private ways?  We could easily lost daily 10 hours if we would respond to our users emails / PM. Since we have no option to hire technical support staff, questions are replied with canned message / deleted. I assume vendors receive about 10 - 20 x our quantity and IMO they also can't cover.

 

Welcome!

[José Guilherme]

Thank you for you attention Igor, didn't think you were this fast!!

 

That's exactly what I was expecting to be honest... I didn't really think it was a feature that worked on an acceptable level...

 

I agree on what  you are saying... their support is horrible, thankfully we have people from this community or I'd be stuck with a very old linux distro with an old kernel and no support. I'd love to spend some time learning more about this kind of thing such as SoCs and etc, but I'm sure it would take a good amount of time and my employers unfortunately won't accept that as a priority + I don't have kernel hacking experience... Either way, if they answer my e-mail with anything useful I can relay the message here, not that I expect it will happen... Even in private my communications with chinese companies have mostly been unsuccessful...

 

I'd also like you to know that I'm thankful for your work. Being able to build a full flashable image with two lines in a terminal is awesome, the way the scripts are prepared for patches and other changes is also incredible, so nice work there.

 

Also, thank you for the information about the freeze... I tried to build it manually to check if I could disable anything in the kernel or bootloader and make the boot faster, but it didn't quite work as expected.