-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AM43xx Suspend/Resume #1822
AM43xx Suspend/Resume #1822
Conversation
3a5422d
to
7c530ff
Compare
#include "api_monitor_index_a9.h" | ||
|
||
uint32_t suspend_regs[16]; | ||
void sm_pm_cpu_do_suspend(uint32_t *ptr); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove this line and #include <sm/pm.h>
instead.
core/arch/arm/plat-ti/sub.mk
Outdated
@@ -3,4 +3,4 @@ srcs-y += main.c | |||
srcs-$(CFG_PL310) += ti_pl310.c | |||
srcs-$(PLATFORM_FLAVOR_dra7xx) += sm_platform_handler_a15.c | |||
srcs-$(PLATFORM_FLAVOR_am57xx) += sm_platform_handler_a15.c | |||
srcs-$(PLATFORM_FLAVOR_am43xx) += sm_platform_handler_a9.c | |||
srcs-$(PLATFORM_FLAVOR_am43xx) += sm_platform_handler_a9.c a9_plat_init.S ../sm/pm_a32.S ../sm/pm.c |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are the sm
files necessary? I would think they are already added, as long as CFG_WITH_ARM_TRUSTED_FIRMARE=n
(see
Lines 57 to 59 in 59ac392
ifneq ($(CFG_WITH_ARM_TRUSTED_FW),y) | |
core-platform-subdirs += $(arch-dir)/sm | |
endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ignore my previous comment, I did not read the file names correctly.
If you need to use only ../sm/pm_a32.S
and ../sm/pm.c
, you need to split the following line in core/arch/arm/sm/sub.mk
and have them included by some CFG_
variable:
srcs-$(CFG_PSCI_ARM32) += std_smc.c psci.c pm.c psci-helper.S pm_a32.S
Indeed, it is not good practice to include files from an external directory.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't like doing that either, but I wasn't sure how to split up CFG_PSCI_ARM32, so was looking for guidance on that. Maybe:
srcs-$(CFG_PM_ARM32) += pm.c pm_a32.S
srcs-$(CFG_PSCI_ARM32) += std_smc.c psci.c psci-helper.S
But then how do we enforce the dependency from PSCI -> PM here without Kconfig, some kind of rule in a .mk file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be enough:
ifeq ($(CFG_PSCI_ARM32),y)
$(call force,CFG_PM_ARM32,y)
endif
Since this pattern appears in several places, we could as well write a function to declare dependencies, but I'm a bit worried we may end up writing something uselessly complex...
@glneo I have a common question, why not using psci in non-secure side? |
arm_cl2_cleaninvbypa(pl310_base(), | ||
virt_to_phys(suspend_regs), | ||
virt_to_phys(suspend_regs) + | ||
sizeof(suspend_regs)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
l1+pl310 flush requires clean inner + flush outer + flush inner.
(http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0246h/Beicdhde.html)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting, will fix.
By the way this was modeled after: core/arch/arm/sm/pm.c (lines 67-71), is this not correct then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pm.c cleans the cache, hence clean L1 + clean L2.
Your code seems to clean & invalidate the caches, hence clean L1/flush L2/flush 1.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we only need to clean the cache, would it be preferred then to only clean here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, i think so.
@MrVan This is a really good question that we have debated internally. We are attempting to leverage as much of the existing non-secure suspend/resume code as possible. If we went with a full PSCI path, we would have to duplicate a lot of code as it must still exist in-kernel for the non-secure devices. I do not believe anything in this patch prevents a regular PSCI path from being implemented for our platforms at a later time should we need. |
7c530ff
to
98871a1
Compare
@glneo The flow is ok, and could minimize changes to kernel which previous runs in secure world. Just wonder, could your implementation guarantee(could not be rooted by hacker) that when resumeing back, the entry will first runs into TEE, then tee back to linux? |
It is true that a compromised non-secure side can decide to not re-start OP-TEE, but this does not present a security issue as the old ROM based secure side will still be present. It is up to the non-secure side to start OP-TEE in the first place (in U-Boot), so nothing is really lost here. Also, OP-TEE is always in firewalled memory, even through suspend/resume, so before it is restarted we still have no risk of non-secure side tampering. |
For "core: arm: psci: Split PM config from PSCI": I will actually pick up that patch and merge it now, independent of this PR, because if fixes an issue with current master:
The issue was in fact triggered by 5402a9f ("qemu_virt: enable smp boot"), and that is the proper fix AFAICT. |
98871a1
to
dca661c
Compare
|
dca661c
to
a2f7011
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A late comment about flat mapping constraint.
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
core/arch/arm/plat-ti/a9_plat_init.S
Outdated
adr lr, after_resume | ||
push {r4 - r12, lr} | ||
|
||
ldr r0, =suspend_regs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This expects suspend_regs
is flat mapped: maybe add a comment about it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment added.
core/arch/arm/plat-ti/a9_plat_init.S
Outdated
* POSSIBILITY OF SUCH DAMAGE. | ||
*/ | ||
|
||
/* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
very minor: extra space.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
When the non-secure world is attempting to suspend it will call into the secure side using a platform service call. We implement this here in OP-TEE by saving the needed secure side registers. On resume the ROM will restore the secure side to its original configuration and OP-TEE will be re-entered from its boot reset vector. Add a check for the resume case and restore the secure registers if we are resuming. Signed-off-by: Andrew F. Davis <afd@ti.com> Acked-by: Jerome Forissier <jerome.forissier@linaro.org> Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
a2f7011
to
1ddafc1
Compare
Hello all,
This is the AM43xx suspend/resume patch based on the common code in: #1729
Thanks,
Andrew