On Fri, Nov 22, 2013 at 2:10 PM, Ian Campbell <ijc@xxxxxxxxxxxxxx> 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@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... ;-) >> >> 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@xxxxxxxxxxxxxxxx. > For more options, visit https://groups.google.com/groups/opt_out. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
