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