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

Anup Patel anup at brainfault.org
Fri Nov 22 09:56:23 CET 2013


On Fri, Nov 22, 2013 at 2:10 PM, Ian Campbell <ijc at hellion.org.uk> wrote:
> On Thu, 2013-11-21 at 15:04 +0000, Marc Zyngier 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... ;-)
>>
>> What could be done would be for u-boot to be at least partially linked
>> to run from some other region.
>
> Can't you just build and link it as you do now and then link it into
> the .rodata section of the final u-boot image as a blob to copy out to
> the defined address at runtime?

If you link secure firmware inside u-boot image then we will have to reflash
or update entire u-boot image whenever we want to update the secure
firmware.

--
Anup

>
>>  That would allow for the secure mode
>> services to be both part of u-boot, and stay resident.
>>
>> That'd probably be a good thing to have a look at.
>>
>> > BTW, you will need to mark this region reserved in the dtb if in system RAM.
>>
>> Yes. Eventually, I'd like the psci mode to be entirely generated from
>> u-boot, as well as the eventual RAM reserved.
>
> Did you mean "psci node" here? In which case yes please.
>
> Ian.
>
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.


More information about the U-Boot mailing list