> 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.
So, I think PSCI 0.2 calls for function numbers in the 0x8400xxxx range.
Seems like we'll have to fix this in one of your patches:
/* PSCI interface */
#define ARM_PSCI_FN_BASE 0x95c1ba5e
to be:
#define ARM_PSCI_FN_BASE 0x84000000
Just thought I'd toss that out there, you know, if you were collecting
fixes for a repost of your patches... :-)
jdl
On Thu, Apr 17, 2014 at 3:58 AM, 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.
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny.
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
