All, this could be a good topic at lin...@uds... Dave Sent from yet another ARM powered mobile device
On 18 Oct 2010, at 06:18, "Shilimkar, Santosh" <santosh.shilim...@ti.com> wrote: > Bobby, >> -----Original Message----- >> From: Bobby Batacharia [mailto:bobby.batacha...@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 > > _______________________________________________ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
