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? (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
