I'm using Linaro Release 15.12 LSK (without OP-TEE) + OpenEmbedded Minimal Filesystem on Juno-r1 Board.
I'm trying to put the Juno board into the Sleep-state referring to ARM Versatile Express Juno r1 Development Platform Technical Reference Manual.
But it seems to reboot and fall into the error state, even if I push the Soft Reset button briefly.
Does anyone know how to put the Juno board into the Sleep-state ?
Thank you for your help.
------------Moderator edit: As of release 16.05 you can follow the instructions here:https://community.arm.com/dev-platforms/w/docs/239/system-suspend-to-ram------------
What exactly do you mean by Sleep-state ?
It could be cpu, device or system level sleep state.
On juno, CPU sleep states are available and must be enabled by default in Linaro releases.
Can you check if you see the sysfs files:
/sys/devices/system/cpu/cpu*/cpuidle/state*/usage
/sys/devices/system/cpu/cpu*/cpuidle/state*/time
Reading them gives the residency count and time.
System state is supported but only rtc wakeup sources is tested.
You can try:
echo mem > /sys/power/state
Thank you for your response.
I mean that Sleep-state is System level sleep state.
For more information, please refer to the following link. ARM Information Center
When I pushed the Soft Reset button briefly, Juno did not sleep but rebooted.
So I contributed this question about it.
Might Linaro kernel not support System sleep state on Juno ?
I could check CPU sleep state is available by reading sysfs files.
But System sleep state is not going well.
# echo mem > /sys/power/state
-sh: echo: write error: Invalid argument
And, there was no sleep states though I tried the following command.
# cat /sys/power/state
Thank you.
Hi,
Since this feature was added in the mainline kernelquite recently, there's possibility that it's not supported
in LSK. However I think the 15.12 firmware should have the
necessary support.
Regards,
Sudeep
Thank you for your reply.
I added the system suspend support to 15.12 LSK by reference to mainline kernel.
Juno seemed to be into the suspend state after running "echo mem > /sys/power/state".
But Juno did not wake-up although I set the RTC alarm before entering the suspend state.
# date
Mon Jan 18 08:12:28 UTC 2016
# echo +10 > /sys/class/rtc/rtc0/wakealarm
[ 398.468280] PM: suspend entry 2016-01-18 08:12:28.253471540 UTC
[ 398.474147] PM: Syncing filesystems ... done.
[ 398.507730] Freezing user space processes ... (elapsed 0.004 seconds) done.
[ 398.515211] Freezing remaining freezable tasks ... (elapsed 0.007 seconds) done.
[ 398.515214] Suspending console(s) (use no_console_suspend to debug)
How can I wake-up Juno being in the suspend state ?
Could you tell me more if you know about this.
Thank you again for your help.
That's cool.
Can you confirm the RTC being used is not rtc-efi ?
$ cat /sys/class/rtc/rtc*/name
You must use the pl031 RTC. You can first check if it's working by:
$ echo +10 > /sys/class/rtc/rtc1/wakealarm && sleep 10 && cat /proc/interrupts | grep pl031
You must get interrupts. If not it can't work as wakeup source.
If you are getting interrupts then it could be firmware issue.
I have not tried this with v3.10/v3.18 kernel, I may be missing
some config in Linux kernel too.
Thanks for giving me a information.
Yes, I am using pl031 RTC.
And I could confirm getting a interrupt from pl031 RTC after running the command.
# echo +10 > /sys/class/rtc/rtc0/wakealarm && sleep 10
Does this mean it might be a firmware issue ?
What should I check about source code ?
Thank you for your time.
That's good that RTC is working.
Also you mentioned it's 15.12 release so I think it does support
system suspend though I have never tried that.
It could be Linux issue, but if you can run v4.4 just to check once
that will confirm firmware is fine and you can look at Linux suspend
path in detail to debug that.
Thanks for your reply.
But I am afraid I don't have a ARMv8 board on which v4.4 kernel is running on hand.
Though I tried the same thing on Juno with v4.3 kernel, it also did not wake up.
In this connection, there is something I am bothering about a little.
There is the following comments in the ARM Trusted Firmware source code.
===================================================================================
On Juno, when the system power domain is suspended, the GIC is also powered down. The SCP resumes the final core to be suspend when an external wake-up event is received. But the other cores cannot be woken up by a targeted interrupt, because GIC doesn't forward these interrupts to the SCP. Due to this hardware limitation, we down-grade PSCI CPU SUSPEND requests targeted to the system power domain level to cluster power domain level.
The system power domain suspend on Juno is only supported only via PSCI SYSTEM SUSPEND API.
Does not the above hardware limitation influence a wake-up from System Suspend ?
I'd be grateful if you could tell me what you think.
Running v4.4 on Juno is quite simple. Just build for defconfig.
Anyways as I mentioned earlier I have tested Juno wakeup on
RTC alarm atleast. There are other interrupts like GPIO keys
which can ideally be used but for reasons yet to root-caused
they are not working when GIC is powered-down which is the
case when the system suspend is executed.
Hope that helps.
Thank you for letting me know !
Thanks to your advice, I could run v4.4 kernel building for defconfig + CONFIG_RTC_DRV_PL031 on Juno.Also, I could confirm Juno resumes from System-Suspend by the RTC alarm though there were some warning messages.However, to succeed in resuming is only one out of several times. How about when you tested it ?
I'm using the following software on Juno R1 board.
Linux kernel + juno-r1.dtb : v4.4 kernel.org Others ( including u-boot ) : Linaro Release 15.12 Latest Filesystem : OpenEmbedded Minimal 15.10
Once again, thank you for your time.