Common ARM context save/restore code

[David Rusling]

All,
   this could be a good topic at Linaro at UDS...
Dave

Sent from yet another ARM powered mobile device

On 18 Oct 2010, at 06:18, "Shilimkar, Santosh" <santosh.shilimkar at ti.com> wrote:

> Bobby,
>> -----Original Message-----
>> From: Bobby Batacharia [mailto:Bobby.Batacharia at arm.com]
>> Sent: Sunday, October 17, 2010 4:08 AM
>> To: Shilimkar, Santosh; Jon Callan; linaro-dev at 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
> 
> _______________________________________________
> linaro-dev mailing list
> linaro-dev at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev