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------------
Hi Sudeep,
Sorry that I didn't write the conclusion.Yes, the problem was solved.
Thank you so much for all your help.
Regards
Hi Taken,
I am confused. Is the problem solved for you now ?
Regards,
Sudeep
Hi,
I reported that the issue surfaces when I try to suspend & resume twice continuously with Linaro 16.05 latest above.At that time I used prebuilt binaries (snapshots.linaro.org/.../ : Now not found),but the binaries that built from a source code (fetched by the following commands) does not surface the issue.
# repo init -u https://git.linaro.org/landing-teams/working/arm/manifest -b 16.05 -m pinned-latest.xml # repo sync
Thank you.
Thanks for your prompt reply.
I tried with defconfig on Linaro 16.05 latest and the issue did not happen as well as v4.7-rc4.
There is much difference between defconfig and linaro config, so I am trying to check them.
Hi taken,
Thanks for taking time to explain the details.
I understand you are using Linaro 16.05 release now, but I want to make know which
kernel are you trying ? Is it Linaro release or the mainline.
One possible reason could be the some driver is taking long to complete it's suspend
and rtc expires before entering suspend.
I tried with defconfig on v4.7-rc4 and I don't see any issue.
I need more information on the kernel configuration to check this.
Thank you for your reply.
First, the previous message meant the issue surfaces when I try to suspend & resume twice continuously.
The steps to reproduce this issue are as follows:
0. I am using Juno-R1 with Linaro 16.05 latest.
1. [Set rtc] # echo +5 > /sys/class/rtc/rtc0/wakealarm
2. [Suspend] # echo mem > /sys/power/state
(after 5 seconds) Resume
3. wait about 10seconds
4. [Set rtc] # echo +5 > /sys/class/rtc/rtc0/wakealarm
5. [Suspend] # echo mem > /sys/power/state
(Juno does not resume)
And I understood it was the cause of this issue that there was no trigger of Resume, because the Suspend process took more than 5 seconds and it was into the Suspend State after RTC interrupt occurred.
Actually, the issue did not happen when I changed alarm of RTC 10 seconds.
So I have a question.
Why does 2nd Suspend process take more than 5 seconds ?
1st Suspend process does not take 1 second.
And 2nd Suspend process does not take 1 second if the above steps.3 is "wait a second".
I would appreciate it if you could answer my question.
Sorry for late reply, I couldn't check the message here for a week.
Do you mean the issue surfaces only when you try to suspend
resume multiple times continuously ? Can you describe in simple
words how to reproduce this issue ?
Great!
With Linaro 16.05 lateset, Juno could resume from the Suspend State.
But, I tried continuously to suspend Juno, and could not resume.
The following is log about PCIe in the first Resume.
[ 18.191690] ata2: SATA link down (SStatus 0 SControl 0)
[ 18.196921] ata1: SATA link down (SStatus 0 SControl 0)
Can you try with the latest juno firmware release [1] ?
I appreciate your reply.
I am glad I could clarify the cause of the issue.
I would be grateful if you could share anything about the issue with me.
Right, since you mentioned PCIe, I now look your original query
and I missed the fact that it's R1 board. I always assumed it was
R0 board, sorry for that.
Yes I have R2 board and it has issue with PCIe resume path
especially if you are using sky2 ethernet port. However if you
remove that module, you will just see warning in the resume path.
It's issue with PCIe power management, I will follow up on this
once I have more info.
Regarding that Juno does not always resume, it could be PCIe driver issue. Since it always resumes if I delete "pcie-controller" from DTB.
Isn't the board you tested Juno-r0 which does not support PCIe ?
Hello.
Thank you for the information.
I wonder if any firmware are different from the firmware you tested.
First I will try to debug kernel with "no_console_suspend".
Thank you very much.
It always resumes on my Juno board.
Also you can ignore the warnings. One of them is from GPIO which is
fixed now in v4.5-rc1 and another is CPUFreq which I need to look at
but postponing it as it's not harmful.
You can add "no_console_suspend" to see if you get any more logs in
failure case so that it helps to debug.
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.
View all questions in Arm Development Platforms forum