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. -- Anup > > (I'm sure it's not that simple, but I'm curious to know why). > > -Christoffer > _______________________________________________ > kvmarm mailing list > kvmarm@xxxxxxxxxxxxxxxxxxxxx > https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
