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

[Anup Patel]

On 22 November 2013 07:24, Christoffer Dall <christoffer.dall at linaro.org> wrote:
> On 21 November 2013 07:04, Marc Zyngier <marc.zyngier at 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 at 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.

--
Anup

>
> (I'm sure it's not that simple, but I'm curious to know why).
>
> -Christoffer
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm