[U-Boot] [PATCH 0/9] ARMv7: add PSCI support to u-boot

[Marc Zyngier <marc.zyngier@arm.com>]

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.
-- 
Jazz is not dead. It just smells funny...