On 22/11/13 03:58, Anup Patel wrote:
On 22 November 2013 07:24, Christoffer Dall christoffer.dall@linaro.org wrote:
On 21 November 2013 07:04, Marc Zyngier marc.zyngier@arm.com wrote:
Hi Rob,
On 21/11/13 14:28, Rob Herring wrote:
On Thu, Nov 21, 2013 at 2:59 AM, Marc Zyngier marc.zyngier@arm.com wrote:
PSCI is an ARM standard that provides a generic interface that supervisory software can use to manage power in the following situations:
- Core idle management
- CPU hotplug
- big.LITTLE migration models
- System shutdown and reset
It basically allows the kernel to offload these tasks to the firmware, and rely on common kernel side code.
More importantly, it gives a way to ensure that CPUs enter the kernel at the appropriate exception level (ie HYP mode, to allow the use of the virtualization extensions), even across events like CPUs being powered off/on or suspended.
The main idea here is to reuse some of the existing u-boot code to create a separate blob that can live in SRAM (or a reserved page of memory), containing a secure monitor that will implement the PSCI operations. This code will still be alive when u-boot is long gone, hence the need for a piece of memory that will not be touched by the OS.
Interesting. As a separate binary, I'm not sure this belongs or benefits from being in u-boot. I would like to see this as a more generic secure firmware loader or PSCI code be a part of u-boot code directly. With the latter, you could extend it beyond PSCI to things like env variable access (basically equivalent to UEFI runtime services). I'm not saying we should do that though.
So I started this by having something that was actually part of u-boot, and copying itself into SRAM, patching stuff as it went. The net result was that I was reinventing a runtime linker. Needless to say, I gave up quickly... ;-)
I'm curious; why did you need to reinvent a linker? This was all just assembly right? Could you not write it as position independent code and just copy a blob of code and be done with it?
We really cannot assume that all power related programming sequence for SOCs will simple and easy to fit in position independent code. I am not saying it is impossible but it will not be easy to translate complex C code to position independent assembly code.
An Independent binary of a secured firmware makes more sense here. Also, if secured firmware is an independent binary then it need not be open source.
If it is not open source, it has no purpose in u-boot, and I have strictly no intention to support such a thing. Quite the opposite, actually.
Eventually, I want to get completely rid of the "loading" bit, and just let u-boot relocate its secure monitor part into "secure memory" (irrespective of it being actually secure or not).
M.