Hi,
Thanks for the response.
The pre-defined locations are needed because not every registers needs to be saved. For example in GIC, pending. Clear, Set sets of register are pretty much same with inverted logic and can be easily decoded without saving all of them but just one type of it. Hence the Save layout
Interesting. Why the optimization though - is the intent to save time or context space? Every cycle may count, but our investigations lead us to believe that the time for any shutdown is dominated by cache (L1) clean times.
Hence the Save layout is not linear on OMAP4 and restore is handled in by Secure CODE which is fixed for a SOC
Fair enough, but this is an OMAP4 implementation choice, not a general statement about SoCs. (Correct me if I'm wrong.)
Yes... Again I am not saying that you can't have generic code doing that.It's doable but it will end up with some SOC specific execeptions.
Understood.
-Bobby
-----Original Message----- From: Shilimkar, Santosh [mailto:santosh.shilimkar@ti.com] Sent: 18 October 2010 06:19 To: Bobby Batacharia; Jon Callan; linaro-dev@lists.linaro.org Subject: RE: Common ARM context save/restore code
Bobby,
-----Original Message----- From: Bobby Batacharia [mailto:Bobby.Batacharia@arm.com] Sent: Sunday, October 17, 2010 4:08 AM To: Shilimkar, Santosh; Jon Callan; linaro-dev@lists.linaro.org Subject: RE: Common ARM context save/restore code
Santosh,
Again - apologies for the tardy responses to this thread.
This is something very different from SOC point of view. Example OMAP4, the restore for GIC, SCU, L2 is handled by ROM code and it expect it to save in a particular pattern and pre-defined memory location. Generic code won't work here.
Understood, and Jon's code certainly doesn't preclude such
an approach.
Small point, but I'm not sure I buy the part about
pre-defined memory
locations: that will be a parameter into the generic code.
I do agree SoC
specific code provides the context pointer regardless of
where the restore
happens. The approach we're working on is also intended to respect multiple CPU and SoC level TrustZone scenarios: there will
clearly be SoC
and CPU state that can't be Saved/Restored by the OS. (The
bulk of that
non-OS code may or may not be in ROM, depends on the SoC.)
The pre-defined locations are needed because not every registers needs to be saved. For example in GIC, pending. Clear, Set sets of register are pretty much same with inverted logic and can be easily decoded without saving all of them but just one type of it. Hence the Save layout is not linear on OMAP4 and restore is handled in by Secure CODE which is fixed for a SOC
Out of interest, in the OMAP4 implementation, when a single core is powered down (but Fabric/DMC, cluster, and potentially
another CPU stays
up), does that core end up calling into non-OS code to save
and restore
its state?
Yes... Again I am not saying that you can't have generic code doing that. It's doable but it will end up with some SOC specific execeptions.
Having said that, would be good to see your patches.
Certainly interested in your comments when we make it
public. (I know, I
know .. soon!)
Ok
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.