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

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

On 22/11/13 01:54, Christoffer Dall 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?

There is more than just that. Some of the code is actually shared
between u-boot and PSCI, so in the process of copying to SRAM, you have
to patch some things there.

Some of it could be rewritten as being PIC, but there is more
fundamental issues about the current approach: the way the code is
structured, it expects to be able to switch directly from secure to
non-secure in the same memory space. With secure memory, that's a killer
(you're pulling the rug (and entire floor) from under your own feet).

So I'm now heading towards changing the "non-secure-switching" part of
u-boot to be able to return directly into the payload, instead of
carrying on within the same memory-space. This will then allow moving
that code to secure memory, and then we'll be able to share it between
u-boot and PSCI. Well, I think... ;-)

	M.
-- 
Jazz is not dead. It just smells funny...