Hi Marc, On Thu, 17 Apr 2014 09:58:19 +0100, Marc Zyngier <marc.zyng...@arm.com> wrote:
> On Thu, Apr 17 2014 at 9:34:24 am BST, Albert ARIBAUD > <albert.u.b...@aribaud.net> wrote: > > Hi Marc, > > > > On Wed, 16 Apr 2014 17:09:07 +0100, Marc Zyngier <marc.zyng...@arm.com> > > wrote: > > > >> On 16/04/14 15:45, Albert ARIBAUD wrote: > >> > Hi Marc, > >> > > >> > On Sat, 15 Feb 2014 13:36:24 +0000, Marc Zyngier > >> > <marc.zyngier-5wv7dgni...@public.gmane.org> 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 turn some of the existing u-boot code into a > >> >> separate section that can live in secure RAM (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. > >> >> > >> >> This patch series contains 4 parts: > >> >> - the first four patches are just bug fixes > >> >> - the next two refactor the HYP/non-secure code to allow relocation > >> >> in secure memory > >> >> - the next four contain the generic PSCI code and DT infrastructure > >> >> - the last three implement the CPU_ON method of the Allwinner A20 (aka > >> >> sun7i). > >> >> > >> >> I realize the A20 u-boot code is not upstream yet (BTW is anyone > >> >> actively working on that?), but hopefully that should give a good idea > >> >> of how things are structured so far. The patches are against the > >> >> mainline u-boot tree as of today, merged with the sunxi u-boot tree > >> >> of the day and the first 10 patches will directly apply to mainline > >> >> u-boot. > >> >> > >> >> As for using this code, it goes like this: > >> >> sun7i# ext2load mmc 0:1 0x40008000 zImage ; ext2load mmc 0:1 0x60000000 > >> >> sun7i-a20-cubietruck.dtb > >> >> 2270120 bytes read in 117 ms (18.5 MiB/s) > >> >> 9138 bytes read in 3 ms (2.9 MiB/s) > >> >> sun7i# fdt addr 0x60000000 ; fdt resize ; fdt set ethernet0 mac-address > >> >> "[5a fe b0 07 b0 07]" > >> >> sun7i# setenv bootargs console=ttyS0,115200 earlyprintk ip=dhcp > >> >> root=/dev/nfs nfsroot=/backup/a20_root,tcp > >> >> sun7i# bootz 0x40008000 - 0x60000000 > >> >> > >> >> The kernel now boots in HYP mode, finds its secondary CPU without any > >> >> SMP code present in the kernel, and runs KVM out of the box. > >> >> I've been told the Xen/ARM guys managed to do the same fairly easily. > >> >> > >> >> This code has also been tested on a VExpress TC2, running KVM with all > >> >> 5 CPUs, in order to make sure there was no obvious regression. > >> >> > >> >> I'm wildly cross-posting this patch series, including to lists I'm not > >> >> subscribed to. Please keep me on Cc for any comment you may have. > >> >> > >> >> The code is also available at: > >> >> git://git.kernel.org/pub/scm/linux/kernel/git/maz/u-boot.git wip/psci > >> >> > >> >> Cheers, > >> >> > >> >> M. > >> > > >> > Marc, I'm unclear what you want to do with this series. You mention > >> > that its first 10 patches will apply to U-Boot, but I am not sure > >> > whether you are just indicating that it is possible to apply them or > >> > asking for these 10 patches to go in U-Boot mainline. Or is it > >> > something else yet? > >> > >> Well, I rarely write code just for the sake of forking a critical > >> project ;-) > >> > >> So let's be 100% explicit: Yes, I'm hereby asking for these patches to > >> be merged. They offer a service that is required by the Linux kernel as > >> well as Xen. They are in active use on the Allwinner sun7i platform as > >> well as Versatile Express (though the later doesn't have a PSCI > >> implementation). > >> > >> Now, given that two months have gone past without much comment other > >> than the odd "hey, works great", I don't really know where to take that. > >> > >> Are you willing to review the patches? > > > > Well, I rarely ask about patches just for the sake of conversation. O:-) > > > > So yes, I am willing to review them -- and I suspect others are, as > > well. Nobody commented the V3 series on the U-Boot list -- save for > > Jon's comment about the series needing a rebase -- which could mean no > > one here is unhappy with them... or they were discussed and possibly > > acted upon on linux-sunxi, where the replies were redirected. I don't > > follow linux-sunx closely, so I couldn't tell. :) > > No, so far there hasn't been much discussion, and people seem happy with > it. I have a couple of fixes lined up, but nothing major. > > Also, a number of the patches are actually fixes that should really make > it into the U-Boot tree, no matter if the PSCI code is merged or > not. Some of them make the kernel go completely bonkers, other introduce > the risk of U-Boot falling over in style. > > > Still, I am trying to figure out the whole Allwinner nebula and see how > > things are supposed to work out between their various SoCs and make > > sure to avoid duplicate/incompatible effort (you're mentioning the A20, > > there seems to be A31 work underway too elsewhere). I am starting to > > wonder whether an ARM allwinner sub-repo might make sense. Tom, > > Wolfgang? > > Ian Campbell (cc-ed) is actively pushing out patches to support the A20 > in mainline U-Boot (I believe you've been on the receiving end of > these), and I plan to rebase my series on top of his. Still, the A20 > support is only a small part of the code, used as an example of how to > implement PSCI on a rather simple platform. This can easily be split out > and merged via different trees. I have seen Ian's patches, but didn't have time until now to look at them. OK, so, to me, the best course of actions is to: 1) isolate those patches in your series which are fixes unrelated to AllWinner SoCs and get them in. I'd prefer a separate series for this. 2) Get Ian's Allwinner-related patches (reviewed and) applied. 3) Get your Allwinner-related patches (reviewed and) applied. > Thanks, > > M. Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot