On 22/11/13 03:58, Anup Patel wrote: > On 22 November 2013 07:24, Christoffer Dall <christoffer.dall@xxxxxxxxxx> wrote: >> On 21 November 2013 07:04, Marc Zyngier <marc.zyngier@xxxxxxx> 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@xxxxxxx> 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... _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
