Re: [Xen-devel] Odroid XU3 support
Hello Julien, Thank you for the advice. I do have a follow up question. On Thu, Apr 28, 2016 at 2:50 AM, Julien Grall wrote: > Hello, > > On 27/04/16 23:53, Suriyan Ramasami wrote: > > How can I check which core is currently active? >> Judging by this link on big.LITTLE architecture: >> http://forum.odroid.com/viewtopic.php?f=65&t=2580 >> >> result of: cat /proc/cpuinfo | grep "CPU part" is >> CPU part: 0xc07 >> >> which stands for A7. >> >> If you do this in dom0, it will show all of them to be 0xc07. They are >> vCPUs after all. >> > > Which is not a good idea. This means that Linux is not able to detect > potential errata for the underlying cores (in this case the cortex-A15). > Also some userspace may do some runtime optimization based on the kind of > CPUs available in the guest. > > Xen is not ready for big.LITTLE, so I would highly recommend you to > disable either all the Cortex-A15 or Cortex-A7. > > Ian did recommend that if they were in their own cpu pools it would avoid mixing them in a guest. I was researching that angle. What is your take on that? If Linux is not recognizing it, that is a dom0/domU issue, is it not? Nonetheless, to start with, to add support, I think there would be less resistance if the boot cluster (a7) cpus are enabled and the other cluster disabled (a15) For your information, I am planning to send a patch to park any CPUs whose > MIDR is not matching the boot CPU one. > > Regards, > > -- > Julien Grall > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Odroid XU3 support
On Tue, Apr 26, 2016 at 3:31 AM, Julien Grall wrote: > (CC the author of the Odroid support in Xen) > > On 25/04/2016 11:01, Ivan Pavić2 wrote: > >> Hello, >> > > Hello, > > I have CCed Suriyan who added the support of Odroid in Xen. He might be > able to help you here. > > >> i'm trying to boot dom0 linux on exynos5422 platform on A15 (big cpu >> cluster). >> From the past mailing lists on this link: >> http://lists.xen.org/archives/html/xen-devel/2016-02/msg02275.html) >> I'm not sure that is well defined how to change A7's for A15's. >> Should change be in DTS or should one change cpu power up routines in >> linux? >> So far every time it boots from A7's. >> > The Odroid XU3/XU4 afaict has a hardware pin which dictates if a A7 or an A15 core should boot up. It is currently set to boot up from the A7s. > Additionally, I found this in xen boot.ini file: >> >> # use the A7s for dom0 and pin them to it >> setenv xen_bootargs sync_console console=dtuart dtuart=/serial@12C2 \ >> dom0_mem=800M dom0_max_vcpus=4 dom0_vcpus_pin >> >> How this defines A7s for dom0? >> >> As mentioned above, the hardware by design boots up from the A7 cluster. Hence, the first 4 cpus are A7s and the next 4 are the A15s. > How can I check which core is currently active? >> Judging by this link on big.LITTLE architecture: >> http://forum.odroid.com/viewtopic.php?f=65&t=2580 >> >> result of: cat /proc/cpuinfo | grep "CPU part" is >> CPU part: 0xc07 >> >> which stands for A7. >> >> If you do this in dom0, it will show all of them to be 0xc07. They are vCPUs after all. I am not sure if I answered your question. Please feel free to probe more. Thanks! -Suriyan > Regards, >> > > Regards, > > -- > Julien Grall > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/1] XEN/ARM: Add Odroid-XU3/XU4 support
On Tue, Feb 16, 2016 at 2:03 AM, Ian Campbell wrote: > On Sun, 2016-02-14 at 22:32 -0800, Suriyan Ramasami wrote: > > > > > > On Thu, Feb 11, 2016 at 1:40 AM, Ian Campbell < > > ian.campb...@citrix.com> wrote: > > > On Wed, 2016-02-10 at 17:47 -0800, Suriyan Ramasami wrote: > > > > > > > > > > > > On Wed, Feb 10, 2016 at 2:03 AM, Ian Campbell < > > > ian.campb...@citrix.com> > > > > wrote: > > > > > On Tue, 2016-02-09 at 10:20 -0800, Suriyan Ramasami wrote: > > > > > > I agree on the first two paragraphs. > > > > > > > > For the third paragraph, the rebuttal is that the > > > exynos5800 and > > > > > > > > exynos5422 based SoCs can have both clusters on at the > > > same time. > > > > > Hence, > > > > > > > > the third paragrapah comment will have to be tweaked > > > further. > > > > > Possibly > > > > > > > > reading: > > > > > > > > The exynos5800 and exynos5422 can have both clusters on > > > at the > > > > > same time. > > > > > > > > The exynos5800 boots up with cpu0 on cluster0 (A15). The > > > > > exynos5422 can > > > > > > > > boot up on either clusters as its pin controlled. In this > > > case > > > > > the DTS > > > > > > > > should properly reflect the cpu order. > > > > > > > > > > > > > > Does the OS need to be aware of all these combinations > > > though? Is > > > > > it not > > > > > > > sufficient to know how to bring up an A15 core and how to > > > bring up > > > > > an A7 > > > > > > > core and then just do so based on the information in the > > > DTS, > > > > > without > > > > > > > needing to worry about which sort of core we happened to > > > have > > > > > booted on? > > > > > > > > > > > > > > > > > > > > Unfortunately, at least looking at the boot up code for the > > > > > Exynos5422, > > > > > > the OS needs to be aware of it. This is what I see in the > > > linux > > > > > source > > > > > > code. If it boots up on an A7, then a special reset is needed > > > which > > > > > is > > > > > > not needed when booted up otherwise. I do not have much more > > > details > > > > > on > > > > > > that other than the Linux code. > > > > > > Without that reset sequence, I have also verified that the > > > powered on > > > > > CPU > > > > > > does not come up. > > > > > > > > > > Are we able to say that if we are booted on cluster 1 (always > > > the A7s) > > > > > then > > > > > we always need this magic reset? i.e. is true for all SoCs > > > which have > > > > > an A7 > > > > > cluster and can boot from it? (it's tautologically true for > > > SocS which > > > > > either have no A7's or cannot boot from them). > > > > > > > > > I do not have the information to answer the question. I am > > > limited to > > > > what I know (albeit a little bit) wrt the hardkernel related > > > boards - > > > > Exynos 5410 (odroid-XU) and the Exynos 5422 (Odoird XU3/XU4). > > > With my > > > > limited knowledge, I am only aware of Exynos 5410 which is > > > capable of > > > > booting off of an A7 or an A15. > > > > > > > > > Maybe I'm looking for similarities between different exynos > > > variants > > > > > which > > > > > doesn't exist though. If we are going to talk about specific > > > SoCs in > > > > > the > > > > > comments then I would rather that the code was also explicit > > > rather > > > > > than > > > > > assuming cluster 1 will only be found on the 5800, that might > > > be as > > > > > simple > > > > > as mapping the compatible string to a max_cluster (default 0 > > > for > > > > > unknown > > > > > SoC) and warning if pcluster > max_cluster. > > > > Can you please elaborate on the mapping
Re: [Xen-devel] [PATCH v2 1/1] XEN/ARM: Add Odroid-XU3/XU4 support
On Thu, Feb 11, 2016 at 1:40 AM, Ian Campbell wrote: > On Wed, 2016-02-10 at 17:47 -0800, Suriyan Ramasami wrote: > > > > > > On Wed, Feb 10, 2016 at 2:03 AM, Ian Campbell > > wrote: > > > On Tue, 2016-02-09 at 10:20 -0800, Suriyan Ramasami wrote: > > > > I agree on the first two paragraphs. > > > > > > For the third paragraph, the rebuttal is that the exynos5800 and > > > > > > exynos5422 based SoCs can have both clusters on at the same time. > > > Hence, > > > > > > the third paragrapah comment will have to be tweaked further. > > > Possibly > > > > > > reading: > > > > > > The exynos5800 and exynos5422 can have both clusters on at the > > > same time. > > > > > > The exynos5800 boots up with cpu0 on cluster0 (A15). The > > > exynos5422 can > > > > > > boot up on either clusters as its pin controlled. In this case > > > the DTS > > > > > > should properly reflect the cpu order. > > > > > > > > > > Does the OS need to be aware of all these combinations though? Is > > > it not > > > > > sufficient to know how to bring up an A15 core and how to bring up > > > an A7 > > > > > core and then just do so based on the information in the DTS, > > > without > > > > > needing to worry about which sort of core we happened to have > > > booted on? > > > > > > > > > > > > > > Unfortunately, at least looking at the boot up code for the > > > Exynos5422, > > > > the OS needs to be aware of it. This is what I see in the linux > > > source > > > > code. If it boots up on an A7, then a special reset is needed which > > > is > > > > not needed when booted up otherwise. I do not have much more details > > > on > > > > that other than the Linux code. > > > > Without that reset sequence, I have also verified that the powered on > > > CPU > > > > does not come up. > > > > > > Are we able to say that if we are booted on cluster 1 (always the A7s) > > > then > > > we always need this magic reset? i.e. is true for all SoCs which have > > > an A7 > > > cluster and can boot from it? (it's tautologically true for SocS which > > > either have no A7's or cannot boot from them). > > > > > I do not have the information to answer the question. I am limited to > > what I know (albeit a little bit) wrt the hardkernel related boards - > > Exynos 5410 (odroid-XU) and the Exynos 5422 (Odoird XU3/XU4). With my > > limited knowledge, I am only aware of Exynos 5410 which is capable of > > booting off of an A7 or an A15. > > > > > Maybe I'm looking for similarities between different exynos variants > > > which > > > doesn't exist though. If we are going to talk about specific SoCs in > > > the > > > comments then I would rather that the code was also explicit rather > > > than > > > assuming cluster 1 will only be found on the 5800, that might be as > > > simple > > > as mapping the compatible string to a max_cluster (default 0 for > > > unknown > > > SoC) and warning if pcluster > max_cluster. > > Can you please elaborate on the mapping that you talk about above. I am > > lost here :-( > > What I mean is can we say: > exynos 1234 => Two clusters (max_cluster == 1) > exynos 5678 => One cluster (max_cluster == 0) > exynos ABCD => Two clusters (max_cluster == 1) > Unknown => Assume one cluster > > and can we also assume that cluster 0 always consists of A15s and cluster 1 > (if it exists) always consists of A7s? > > If so then we can say: > > max_cluster = look_up_by_compat(compat) > pcluster = figure out from midr > pcpu = figure it out > > if (pcluster >= max_cluster) > error > > do bringup > > if (pluster == 1) > do special handling for cluster 1 == a7 > > The difference compared with what you have is that it adds a check that we > expect a second cluster for the SoC before it goes poking at stuff. > > What I'm trying to avoid is coming across some other SoC variant which has > 2 clusters but has something different to the A7s or which requires some > different handling. > > If we were confident that all exynos SoCs always require the same > special handling for cluster 1 then we wouldn't really need this, but I > don't think we
Re: [Xen-devel] [PATCH v2 1/1] XEN/ARM: Add Odroid-XU3/XU4 support
On Wed, Feb 10, 2016 at 2:03 AM, Ian Campbell wrote: > On Tue, 2016-02-09 at 10:20 -0800, Suriyan Ramasami wrote: > > I agree on the first two paragraphs. > > > > For the third paragraph, the rebuttal is that the exynos5800 and > > > > exynos5422 based SoCs can have both clusters on at the same time. > Hence, > > > > the third paragrapah comment will have to be tweaked further. > Possibly > > > > reading: > > > > The exynos5800 and exynos5422 can have both clusters on at the same > time. > > > > The exynos5800 boots up with cpu0 on cluster0 (A15). The exynos5422 > can > > > > boot up on either clusters as its pin controlled. In this case the > DTS > > > > should properly reflect the cpu order. > > > > > > Does the OS need to be aware of all these combinations though? Is it > not > > > sufficient to know how to bring up an A15 core and how to bring up an > A7 > > > core and then just do so based on the information in the DTS, without > > > needing to worry about which sort of core we happened to have booted > on? > > > > > > > > Unfortunately, at least looking at the boot up code for the Exynos5422, > > the OS needs to be aware of it. This is what I see in the linux source > > code. If it boots up on an A7, then a special reset is needed which is > > not needed when booted up otherwise. I do not have much more details on > > that other than the Linux code. > > Without that reset sequence, I have also verified that the powered on CPU > > does not come up. > > Are we able to say that if we are booted on cluster 1 (always the A7s) then > we always need this magic reset? i.e. is true for all SoCs which have an A7 > cluster and can boot from it? (it's tautologically true for SocS which > either have no A7's or cannot boot from them). > > I do not have the information to answer the question. I am limited to what I know (albeit a little bit) wrt the hardkernel related boards - Exynos 5410 (odroid-XU) and the Exynos 5422 (Odoird XU3/XU4). With my limited knowledge, I am only aware of Exynos 5410 which is capable of booting off of an A7 or an A15. > Maybe I'm looking for similarities between different exynos variants which > doesn't exist though. If we are going to talk about specific SoCs in the > comments then I would rather that the code was also explicit rather than > assuming cluster 1 will only be found on the 5800, that might be as simple > as mapping the compatible string to a max_cluster (default 0 for unknown > SoC) and warning if pcluster > max_cluster. > Can you please elaborate on the mapping that you talk about above. I am lost here :-( > > > > > > > The exynos5410 can have only one cluster on at a time, and it boots > > > up > > > > with pcluster == 0. > > > > Any tweaks and comments on the above is appreciated. > > > > > > How much of this is down to physical h/w limitations and how much of it > > > is > > > down to firmware or software limitations? Can you flip the to the other > > > cluster somehow? > > > > > The 5410 boots up on an A15, and only those 4 A15 CPUs in cluster 0 are > > brought up. Hence, no flipping is required. > > What I meant was, given that the 5410 has a cluster of A15 and a cluster of > A7s (right?) and you can only have one on at a time, how does an OS make > use of the A7s if it wants to? As you say it boots from the A15, so how can > the A7s be used? > > The Linux OS has a bL (big - little) switcher module/code which handles that. It maps one big core to one little core, and when the load is not high, it switches off the big cluster, and turns on the small cluster - AFAICT. Also, are we still on wrt the two cpu pool suggestion and to have 4 cores from cluster 0 in cpupool0 and 4 cores from cluster 1 in cpupool1. It would be great if you can point me to some code as well. I have been looking at cpupool.c and also on the system call interface that it provides. > Ian. > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/1] XEN/ARM: Add Odroid-XU3/XU4 support
On Tue, Feb 9, 2016 at 6:19 AM, Ian Campbell
wrote:
> On Tue, 2016-02-09 at 04:50 -0800, Suriyan Ramasami wrote:
> >
> >
> > On Tue, Feb 9, 2016 at 1:53 AM, Ian Campbell
> > wrote:
> > > On Mon, 2016-02-08 at 21:48 -0800, Suriyan Ramasami wrote:
> > > > The Odroid-XU3/XU4 from hardkernel is an Exynos 5422 based board.
> > > > Code from mcpm-exynos.c and mcpm-platsmp.c from the Linux kernel
> > > > has been used to get all the 8 cores from the 2 clusters powered
> > > > on.
> > > > The Linux DTS for these odroid uses "samsung,exynos5800" as
> > > > the machine compatible string. Hence, the same is used herein.
> > > >
> > > > This change has been tested on the Odroid-XU/XU3/XU4.
> > > >
> > > > Signed-off-by: Suriyan Ramasami
> > >
> > > Thanks, this now looks good to me, with one question about a comment
> > > which
> > > I could resolve upon commit if we agree a wording.
> > >
> > > > ---
> > > > Changes between versions as follows:
> > > >
> > > > v2:
> > > > Try to use common code as much as possible
> > > >
> > > > v1:
> > > > Initial code submission
> > > > ---
> > > > xen/arch/arm/platforms/exynos5.c | 61
> > > > ++--
> > > > 1 file changed, 58 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/xen/arch/arm/platforms/exynos5.c
> > > > b/xen/arch/arm/platforms/exynos5.c
> > > > index bf4964d..12aea31 100644
> > > > --- a/xen/arch/arm/platforms/exynos5.c
> > > > +++ b/xen/arch/arm/platforms/exynos5.c
> > > > @@ -34,9 +34,18 @@ static bool_t secure_firmware;
> > > > #define EXYNOS_ARM_CORE_CONFIG(_nr) (EXYNOS_ARM_CORE0_CONFIG + (0x80
> > > *
> > > > (_nr)))
> > > > #define EXYNOS_ARM_CORE_STATUS(_nr) (EXYNOS_ARM_CORE_CONFIG(_nr) +
> > > 0x4)
> > > > #define S5P_CORE_LOCAL_PWR_EN 0x3
> > > > +#define S5P_PMU_SPARE2 0x908
> > > >
> > > > #define SMC_CMD_CPU1BOOT(-4)
> > > >
> > > > +#define EXYNOS5800_CPUS_PER_CLUSTER 4
> > > > +
> > > > +#define EXYNOS5420_KFC_CORE_RESET0 BIT(8)
> > > > +#define EXYNOS5420_KFC_ETM_RESET0 BIT(20)
> > > > +
> > > > +#define EXYNOS5420_KFC_CORE_RESET(_nr) \
> > > > +((EXYNOS5420_KFC_CORE_RESET0 | EXYNOS5420_KFC_ETM_RESET0) <<
> > > > (_nr))
> > > > +
> > > > static int exynos5_init_time(void)
> > > > {
> > > > uint32_t reg;
> > > > @@ -166,14 +175,23 @@ static void exynos_cpu_power_up(void __iomem
> > > > *power, int cpu)
> > > > static int exynos5_cpu_power_up(void __iomem *power, int cpu)
> > > > {
> > > > unsigned int timeout;
> > > > +unsigned int mpidr, pcpu, pcluster, cpunr;
> > > > +
> > > > +mpidr = cpu_logical_map(cpu);
> > > > +pcpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> > > > +pcluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> > > >
> > > > -if ( !exynos_cpu_power_state(power, cpu) )
> > > > +cpunr = pcpu + (pcluster * EXYNOS5800_CPUS_PER_CLUSTER);
> > > > +dprintk(XENLOG_DEBUG, "cpu: %d pcpu: %d, cluster: %d cpunr:
> > > %d\n",
> > > > +cpu, pcpu, pcluster, cpunr);
> > > > +
> > > > +if ( !exynos_cpu_power_state(power, cpunr) )
> > > > {
> > > > -exynos_cpu_power_up(power, cpu);
> > > > +exynos_cpu_power_up(power, cpunr);
> > > > timeout = 10;
> > > >
> > > > /* wait max 10 ms until cpu is on */
> > > > -while ( exynos_cpu_power_state(power, cpu) !=
> > > > S5P_CORE_LOCAL_PWR_EN )
> > > > +while ( exynos_cpu_power_state(power, cpunr) !=
> > > > S5P_CORE_LOCAL_PWR_EN )
> > > > {
> > > > if ( timeout-- == 0 )
> > > > break;
> > > > @@ -186,6 +204,42 @@ static int exynos5_cpu_power_up(void __iomem
> > > *power,
> > > > int cpu)
> > > > dprintk(XENLOG_ERR, "CPU%d power enable failed\n", cpu);
> > > > return -ETIMEDOUT;
> > > > }
> > > > +
>
Re: [Xen-devel] [PATCH v2 1/1] XEN/ARM: Add Odroid-XU3/XU4 support
On Tue, Feb 9, 2016 at 1:53 AM, Ian Campbell
wrote:
> On Mon, 2016-02-08 at 21:48 -0800, Suriyan Ramasami wrote:
> > The Odroid-XU3/XU4 from hardkernel is an Exynos 5422 based board.
> > Code from mcpm-exynos.c and mcpm-platsmp.c from the Linux kernel
> > has been used to get all the 8 cores from the 2 clusters powered
> > on.
> > The Linux DTS for these odroid uses "samsung,exynos5800" as
> > the machine compatible string. Hence, the same is used herein.
> >
> > This change has been tested on the Odroid-XU/XU3/XU4.
> >
> > Signed-off-by: Suriyan Ramasami
>
> Thanks, this now looks good to me, with one question about a comment which
> I could resolve upon commit if we agree a wording.
>
> > ---
> > Changes between versions as follows:
> >
> > v2:
> > Try to use common code as much as possible
> >
> > v1:
> > Initial code submission
> > ---
> > xen/arch/arm/platforms/exynos5.c | 61
> > ++--
> > 1 file changed, 58 insertions(+), 3 deletions(-)
> >
> > diff --git a/xen/arch/arm/platforms/exynos5.c
> > b/xen/arch/arm/platforms/exynos5.c
> > index bf4964d..12aea31 100644
> > --- a/xen/arch/arm/platforms/exynos5.c
> > +++ b/xen/arch/arm/platforms/exynos5.c
> > @@ -34,9 +34,18 @@ static bool_t secure_firmware;
> > #define EXYNOS_ARM_CORE_CONFIG(_nr) (EXYNOS_ARM_CORE0_CONFIG + (0x80 *
> > (_nr)))
> > #define EXYNOS_ARM_CORE_STATUS(_nr) (EXYNOS_ARM_CORE_CONFIG(_nr) + 0x4)
> > #define S5P_CORE_LOCAL_PWR_EN 0x3
> > +#define S5P_PMU_SPARE2 0x908
> >
> > #define SMC_CMD_CPU1BOOT(-4)
> >
> > +#define EXYNOS5800_CPUS_PER_CLUSTER 4
> > +
> > +#define EXYNOS5420_KFC_CORE_RESET0 BIT(8)
> > +#define EXYNOS5420_KFC_ETM_RESET0 BIT(20)
> > +
> > +#define EXYNOS5420_KFC_CORE_RESET(_nr) \
> > +((EXYNOS5420_KFC_CORE_RESET0 | EXYNOS5420_KFC_ETM_RESET0) <<
> > (_nr))
> > +
> > static int exynos5_init_time(void)
> > {
> > uint32_t reg;
> > @@ -166,14 +175,23 @@ static void exynos_cpu_power_up(void __iomem
> > *power, int cpu)
> > static int exynos5_cpu_power_up(void __iomem *power, int cpu)
> > {
> > unsigned int timeout;
> > +unsigned int mpidr, pcpu, pcluster, cpunr;
> > +
> > +mpidr = cpu_logical_map(cpu);
> > +pcpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> > +pcluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> >
> > -if ( !exynos_cpu_power_state(power, cpu) )
> > +cpunr = pcpu + (pcluster * EXYNOS5800_CPUS_PER_CLUSTER);
> > +dprintk(XENLOG_DEBUG, "cpu: %d pcpu: %d, cluster: %d cpunr: %d\n",
> > +cpu, pcpu, pcluster, cpunr);
> > +
> > +if ( !exynos_cpu_power_state(power, cpunr) )
> > {
> > -exynos_cpu_power_up(power, cpu);
> > +exynos_cpu_power_up(power, cpunr);
> > timeout = 10;
> >
> > /* wait max 10 ms until cpu is on */
> > -while ( exynos_cpu_power_state(power, cpu) !=
> > S5P_CORE_LOCAL_PWR_EN )
> > +while ( exynos_cpu_power_state(power, cpunr) !=
> > S5P_CORE_LOCAL_PWR_EN )
> > {
> > if ( timeout-- == 0 )
> > break;
> > @@ -186,6 +204,42 @@ static int exynos5_cpu_power_up(void __iomem *power,
> > int cpu)
> > dprintk(XENLOG_ERR, "CPU%d power enable failed\n", cpu);
> > return -ETIMEDOUT;
> > }
> > +
> > +/*
> > + * This assumes the cluster number of the big cores(Cortex A15)
> > + * is 0 and the Little cores(Cortex A7) is 1.
> > + * When the system was booted from the Little core,
> > + * they should be reset during power up cpu.
> > + * Note that the below condition is true for Odroid XU3/XU4, and
> > + * false for the XU and the Exynos5800 based boards.
>
> I think the SoC is more relevant/useful in this context than specific
> boards. So I think what it is trying to say here is that for systems
> matching samsung,exynos5410 pcluster will always be zero, where as for ones
> matching samsung,exynos5800 it can be non-zero, and for non-zero clusters
> we need to do some extra bringup.
>
>
I believe for some SoCs its board based (5422 = pin controlled) and for
others its purely SoC based (5420 = A7 boot, 5800 = A15 boot). For example,
please look at this post: https://lkml.org/lkml/2015/12/11/107 which
mentions something along those lines.
I think the comment should therefore focus on the SoC (may
[Xen-devel] [PATCH v2 1/1] XEN/ARM: Add Odroid-XU3/XU4 support
The Odroid-XU3/XU4 from hardkernel is an Exynos 5422 based board.
Code from mcpm-exynos.c and mcpm-platsmp.c from the Linux kernel
has been used to get all the 8 cores from the 2 clusters powered
on.
The Linux DTS for these odroid uses "samsung,exynos5800" as
the machine compatible string. Hence, the same is used herein.
This change has been tested on the Odroid-XU/XU3/XU4.
Signed-off-by: Suriyan Ramasami
---
Changes between versions as follows:
v2:
Try to use common code as much as possible
v1:
Initial code submission
---
xen/arch/arm/platforms/exynos5.c | 61 ++--
1 file changed, 58 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/platforms/exynos5.c b/xen/arch/arm/platforms/exynos5.c
index bf4964d..12aea31 100644
--- a/xen/arch/arm/platforms/exynos5.c
+++ b/xen/arch/arm/platforms/exynos5.c
@@ -34,9 +34,18 @@ static bool_t secure_firmware;
#define EXYNOS_ARM_CORE_CONFIG(_nr) (EXYNOS_ARM_CORE0_CONFIG + (0x80 * (_nr)))
#define EXYNOS_ARM_CORE_STATUS(_nr) (EXYNOS_ARM_CORE_CONFIG(_nr) + 0x4)
#define S5P_CORE_LOCAL_PWR_EN 0x3
+#define S5P_PMU_SPARE2 0x908
#define SMC_CMD_CPU1BOOT(-4)
+#define EXYNOS5800_CPUS_PER_CLUSTER 4
+
+#define EXYNOS5420_KFC_CORE_RESET0 BIT(8)
+#define EXYNOS5420_KFC_ETM_RESET0 BIT(20)
+
+#define EXYNOS5420_KFC_CORE_RESET(_nr) \
+((EXYNOS5420_KFC_CORE_RESET0 | EXYNOS5420_KFC_ETM_RESET0) << (_nr))
+
static int exynos5_init_time(void)
{
uint32_t reg;
@@ -166,14 +175,23 @@ static void exynos_cpu_power_up(void __iomem *power, int
cpu)
static int exynos5_cpu_power_up(void __iomem *power, int cpu)
{
unsigned int timeout;
+unsigned int mpidr, pcpu, pcluster, cpunr;
+
+mpidr = cpu_logical_map(cpu);
+pcpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+pcluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
-if ( !exynos_cpu_power_state(power, cpu) )
+cpunr = pcpu + (pcluster * EXYNOS5800_CPUS_PER_CLUSTER);
+dprintk(XENLOG_DEBUG, "cpu: %d pcpu: %d, cluster: %d cpunr: %d\n",
+cpu, pcpu, pcluster, cpunr);
+
+if ( !exynos_cpu_power_state(power, cpunr) )
{
-exynos_cpu_power_up(power, cpu);
+exynos_cpu_power_up(power, cpunr);
timeout = 10;
/* wait max 10 ms until cpu is on */
-while ( exynos_cpu_power_state(power, cpu) != S5P_CORE_LOCAL_PWR_EN )
+while ( exynos_cpu_power_state(power, cpunr) != S5P_CORE_LOCAL_PWR_EN )
{
if ( timeout-- == 0 )
break;
@@ -186,6 +204,42 @@ static int exynos5_cpu_power_up(void __iomem *power, int
cpu)
dprintk(XENLOG_ERR, "CPU%d power enable failed\n", cpu);
return -ETIMEDOUT;
}
+
+/*
+ * This assumes the cluster number of the big cores(Cortex A15)
+ * is 0 and the Little cores(Cortex A7) is 1.
+ * When the system was booted from the Little core,
+ * they should be reset during power up cpu.
+ * Note that the below condition is true for Odroid XU3/XU4, and
+ * false for the XU and the Exynos5800 based boards.
+ */
+if ( pcluster &&
+ pcluster == MPIDR_AFFINITY_LEVEL(cpu_logical_map(0), 1) ) {
+/*
+ * Before we reset the Little cores, we should wait
+ * the SPARE2 register is set to 1 because the init
+ * codes of the iROM will set the register after
+ * initialization.
+*/
+
+/* wait max 10ms for the spare register to be set to 1 */
+timeout = 10;
+while ( !__raw_readl(power + S5P_PMU_SPARE2) )
+{
+if ( timeout-- == 0 )
+break;
+
+mdelay(1);
+}
+
+if ( timeout == 0 )
+{
+dprintk(XENLOG_ERR, "CPU%d SPARE2 register wait failed\n",
cpu);
+return -ETIMEDOUT;
+}
+__raw_writel(EXYNOS5420_KFC_CORE_RESET(cpu),
+ power + EXYNOS5_SWRESET);
+}
}
return 0;
}
@@ -298,6 +352,7 @@ static const char * const exynos5250_dt_compat[]
__initconst =
static const char * const exynos5_dt_compat[] __initconst =
{
"samsung,exynos5410",
+"samsung,exynos5800",
NULL
};
--
2.5.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 1/1] XEN/ARM: Add Odroid-XU3/XU4 support
On Mon, Feb 8, 2016 at 7:27 AM, Ian Campbell
wrote:
> On Sun, 2016-02-07 at 09:44 -0800, Suriyan Ramasami wrote:
> > The Odroid-XU3/XU4 from hardkernel is an Exynos 5422 based board.
> > Code from mcpm-exynos.c and mcpm-platsmp.c from the Linux kernel
> > has been used to get all the 8 cores from the 2 clusters powered
> > on.
> > The Linux DTS for these odroid uses "samsung,exynos5800" as
> > the machine compatible string. Hence, the same is used herein.
> >
> > Signed-off-by: Suriyan Ramasami
> > ---
> > xen/arch/arm/platforms/exynos5.c | 94
> > +++-
> > 1 file changed, 93 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/arm/platforms/exynos5.c
> > b/xen/arch/arm/platforms/exynos5.c
> > index bf4964d..60ceb2b 100644
> > --- a/xen/arch/arm/platforms/exynos5.c
> > +++ b/xen/arch/arm/platforms/exynos5.c
> > @@ -37,6 +37,15 @@ static bool_t secure_firmware;
> >
> > #define SMC_CMD_CPU1BOOT(-4)
> >
> > +#define EXYNOS5800_CPUS_PER_CLUSTER 4
> > +#define EXYNOS5800_NR_CLUSTERS 2
> > +
> > +#define EXYNOS5420_KFC_CORE_RESET0 BIT(8)
> > +#define EXYNOS5420_KFC_ETM_RESET0 BIT(20)
> > +
> > +#define EXYNOS5420_KFC_CORE_RESET(_nr) \
> > +((EXYNOS5420_KFC_CORE_RESET0 | EXYNOS5420_KFC_ETM_RESET0) <<
> > (_nr))
> > +
> > static int exynos5_init_time(void)
> > {
> > uint32_t reg;
> > @@ -163,6 +172,84 @@ static void exynos_cpu_power_up(void __iomem *power,
> > int cpu)
> > power + EXYNOS_ARM_CORE_CONFIG(cpu));
> > }
> >
> > +static void cpu_to_pcpu(int cpu, int *pcpu, int *pcluster)
> > +{
> > + int mpidr;
> > +
> > + mpidr = cpu_logical_map(cpu);
> > + *pcpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> > + *pcluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> > +}
> > +
> > +static int exynos5800_cpu_power_up(void __iomem *power, int cpu)
> > +{
> > +int timeout;
> > +int pcpu, pcluster;
> > +unsigned int cpunr;
> > +
> > +cpu_to_pcpu(cpu, &pcpu, &pcluster);
> > +cpunr = pcpu + (pcluster * EXYNOS5800_CPUS_PER_CLUSTER);
> > +dprintk(XENLOG_DEBUG, "cpu: %d pcpu: %d, cluster: %d cpunr: %d\n",
> > +cpu, pcpu, pcluster, cpunr);
> > +
> > +
> > +if ( !exynos_cpu_power_state(power, cpunr) )
> > +{
> > +exynos_cpu_power_up(power, cpunr);
> > +timeout = 10;
> > +
> > +/* wait max 10 ms until cpu is on */
> > +while ( exynos_cpu_power_state(power, cpunr) !=
> > S5P_CORE_LOCAL_PWR_EN )
> > +{
> > +if ( timeout-- == 0 )
> > +break;
> > +
> > +mdelay(1);
> > +}
> > +
> > +if ( timeout == 0 )
> > +{
> > +dprintk(XENLOG_ERR, "CPU%d power enable failed\n", cpu);
> > +return -ETIMEDOUT;
> > +}
>
> Up to here this is the same as exynos5_cpu_power_up.
>
> I think either of these two approaches would be acceptable to reduce the
> duplication either:
>
> move the above into a common helper called from both here and
> exynos5_cpu_power_up
>
> or
>
> move the remainder of this function into a exynos5800_cluster_reset (or
> would it be better await_reset?) function and call that from exynos5_cpu_up
> after the call to exynos5_cpu_power_up when the compat string matches.
>
> I think I have a light preference for the second option.
>
>
Thanks for the review. I shall adopt the second option in my next version
of the patch.
>
> > +
> > +/*
> > + * This assumes the cluster number of the big cores(Cortex A15)
> > + * is 0 and the Little cores(Cortex A7) is 1.
> > + * When the system was booted from the Little core,
> > + * they should be reset during power up cpu.
> > + */
> > +if (pcluster &&
> > +pcluster == MPIDR_AFFINITY_LEVEL(cpu_logical_map(0), 1)) {
> > +/*
> > + * Before we reset the Little cores, we should wait
> > + * the SPARE2 register is set to 1 because the init
> > + * codes of the iROM will set the register after
> > + * initialization.
>
> If you have a reference (e.g. a URL) for this that would be useful to
> include (but don't worry if there isn't one).
>
>
Unfortunately, the only reference is the linux ker
[Xen-devel] [PATCH v1 1/1] XEN/ARM: Add Odroid-XU3/XU4 support
The Odroid-XU3/XU4 from hardkernel is an Exynos 5422 based board.
Code from mcpm-exynos.c and mcpm-platsmp.c from the Linux kernel
has been used to get all the 8 cores from the 2 clusters powered
on.
The Linux DTS for these odroid uses "samsung,exynos5800" as
the machine compatible string. Hence, the same is used herein.
Signed-off-by: Suriyan Ramasami
---
xen/arch/arm/platforms/exynos5.c | 94 +++-
1 file changed, 93 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/platforms/exynos5.c b/xen/arch/arm/platforms/exynos5.c
index bf4964d..60ceb2b 100644
--- a/xen/arch/arm/platforms/exynos5.c
+++ b/xen/arch/arm/platforms/exynos5.c
@@ -37,6 +37,15 @@ static bool_t secure_firmware;
#define SMC_CMD_CPU1BOOT(-4)
+#define EXYNOS5800_CPUS_PER_CLUSTER 4
+#define EXYNOS5800_NR_CLUSTERS 2
+
+#define EXYNOS5420_KFC_CORE_RESET0 BIT(8)
+#define EXYNOS5420_KFC_ETM_RESET0 BIT(20)
+
+#define EXYNOS5420_KFC_CORE_RESET(_nr) \
+((EXYNOS5420_KFC_CORE_RESET0 | EXYNOS5420_KFC_ETM_RESET0) << (_nr))
+
static int exynos5_init_time(void)
{
uint32_t reg;
@@ -163,6 +172,84 @@ static void exynos_cpu_power_up(void __iomem *power, int
cpu)
power + EXYNOS_ARM_CORE_CONFIG(cpu));
}
+static void cpu_to_pcpu(int cpu, int *pcpu, int *pcluster)
+{
+ int mpidr;
+
+ mpidr = cpu_logical_map(cpu);
+ *pcpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+ *pcluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+}
+
+static int exynos5800_cpu_power_up(void __iomem *power, int cpu)
+{
+int timeout;
+int pcpu, pcluster;
+unsigned int cpunr;
+
+cpu_to_pcpu(cpu, &pcpu, &pcluster);
+cpunr = pcpu + (pcluster * EXYNOS5800_CPUS_PER_CLUSTER);
+dprintk(XENLOG_DEBUG, "cpu: %d pcpu: %d, cluster: %d cpunr: %d\n",
+cpu, pcpu, pcluster, cpunr);
+
+
+if ( !exynos_cpu_power_state(power, cpunr) )
+{
+exynos_cpu_power_up(power, cpunr);
+timeout = 10;
+
+/* wait max 10 ms until cpu is on */
+while ( exynos_cpu_power_state(power, cpunr) != S5P_CORE_LOCAL_PWR_EN )
+{
+if ( timeout-- == 0 )
+break;
+
+mdelay(1);
+}
+
+if ( timeout == 0 )
+{
+dprintk(XENLOG_ERR, "CPU%d power enable failed\n", cpu);
+return -ETIMEDOUT;
+}
+
+/*
+ * This assumes the cluster number of the big cores(Cortex A15)
+ * is 0 and the Little cores(Cortex A7) is 1.
+ * When the system was booted from the Little core,
+ * they should be reset during power up cpu.
+ */
+if (pcluster &&
+pcluster == MPIDR_AFFINITY_LEVEL(cpu_logical_map(0), 1)) {
+/*
+ * Before we reset the Little cores, we should wait
+ * the SPARE2 register is set to 1 because the init
+ * codes of the iROM will set the register after
+ * initialization.
+*/
+
+/* wait max 10ms for the spare register to be set to 1 */
+timeout = 10;
+while ( !__raw_readl(power + S5P_PMU_SPARE2) )
+{
+if ( timeout-- == 0 )
+break;
+
+mdelay(1);
+}
+
+if ( timeout == 0 )
+{
+dprintk(XENLOG_ERR, "CPU%d SPARE2 register wait failed\n",
cpu);
+return -ETIMEDOUT;
+}
+__raw_writel(EXYNOS5420_KFC_CORE_RESET(cpu), power +
EXYNOS5_SWRESET);
+}
+}
+
+return 0;
+}
+
static int exynos5_cpu_power_up(void __iomem *power, int cpu)
{
unsigned int timeout;
@@ -240,7 +327,10 @@ static int exynos5_cpu_up(int cpu)
return -EFAULT;
}
-rc = exynos5_cpu_power_up(power, cpu);
+if ( dt_machine_is_compatible("samsung,exynos5800") )
+rc = exynos5800_cpu_power_up(power, cpu);
+else
+rc = exynos5_cpu_power_up(power, cpu);
if ( rc )
{
iounmap(power);
@@ -298,6 +388,7 @@ static const char * const exynos5250_dt_compat[]
__initconst =
static const char * const exynos5_dt_compat[] __initconst =
{
"samsung,exynos5410",
+"samsung,exynos5800",
NULL
};
@@ -318,6 +409,7 @@ PLATFORM_START(exynos5, "SAMSUNG EXYNOS5")
.cpu_up = exynos5_cpu_up,
.reset = exynos5_reset,
.blacklist_dev = exynos5_blacklist_dev,
+
PLATFORM_END
/*
--
2.5.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.5 Development Update (GA slip by a week)
On Tue, Jan 6, 2015 at 10:54 AM, Suriyan Ramasami wrote: > On Tue, Jan 6, 2015 at 10:51 AM, Lars Kurth wrote: >> >> On 6 Jan 2015, at 18:08, Suriyan Ramasami wrote: >> >>> >>> I shall try my hand at updating the information again. If this needs >>> to be done (yesterday), then as a temporary solution we could just >>> delete this information for now, and I shall work on it soon. >> >> Ideally it needs to be done by next Wed. If you have the content, you could >> send it to me and I can fix the page > > Thanks Lars for the offer. I just started editing the page, and looks > simple enough to get some content out there. I should have updated the > relevant information in a few hours from now. Please do help me in > fixing the page once its done (if it needs fixing) > > Thanks! > - Suriyan Hello Lars/Ian, I have updated the wiki somewhat to an OK level of information. Lars, I think there might be other links that need to be set to point to this OdroidXU wiki? Any help in polishing this would be appreciated! Thanks - Suriyan > >> Lars ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.5 Development Update (GA slip by a week)
On Tue, Jan 6, 2015 at 10:51 AM, Lars Kurth wrote: > > On 6 Jan 2015, at 18:08, Suriyan Ramasami wrote: > >> >> I shall try my hand at updating the information again. If this needs >> to be done (yesterday), then as a temporary solution we could just >> delete this information for now, and I shall work on it soon. > > Ideally it needs to be done by next Wed. If you have the content, you could > send it to me and I can fix the page Thanks Lars for the offer. I just started editing the page, and looks simple enough to get some content out there. I should have updated the relevant information in a few hours from now. Please do help me in fixing the page once its done (if it needs fixing) Thanks! - Suriyan > Lars ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.5 Development Update (GA slip by a week)
Hello Ian, On Tue, Jan 6, 2015 at 7:28 AM, Ian Campbell wrote: > (culling CCs) > > On Tue, 2015-01-06 at 15:11 +, Lars Kurth wrote: >> * >> http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/OdroidXU >> - missing > > The link to this from [Xen_ARM_with_Virtualization_Extensions] seems to > have been added by[0] the user Suriyan, who I presume to is the same > Suriyan as is now CCd. > > Suriyan, > > Do you have any content for this page? Since the Odroid's are also > Exynos based perhaps it should just link to the Arndale page, which > could become a more generic Exynos page? > > If not then we should remove the link and add to the hardware section > instead. (Or perhaps we should nuke this "Platform specific" section and > inline the links into the list of supported hardware, since having what > is effectively two lists of supported hardware seems a bit pointless). > I had zealously started to edit the page a while back (a couple of months ago), but then couldn't figure out how (I guess I didn't spend too much time on it). I did have specific content for this wiki page, as the Arndale XEN information is Linaro centric and hence not applicable to the OdroidXU - especially the boot loader part and the linux dom0 part. The rest of the information is quite similar. I shall try my hand at updating the information again. If this needs to be done (yesterday), then as a temporary solution we could just delete this information for now, and I shall work on it soon. Regards - Suriyan > Ian. > > [0] Does media wiki really lack a "git blame" analogue? It was very > tedious to work this out by hand... > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
