[ARM:PATCH v1 1/1] Add Odroid-XU (Exynos5410) support

[ARM:PATCH v1 1/1] Add Odroid-XU (Exynos5410) support

[Suriyan Ramasami]

   XEN/ARM: Add Odroid-XU support

   The Odroid-XU from hardkernel is an Exynos5410 based board.
   This patch adds support for the above said board.

Signed-off-by: Suriyan Ramasami <suriyan.r@gmail.com>
---
 xen/arch/arm/platforms/exynos5.c        | 52 +++++++++++++++++++++++++++++++++
 xen/include/asm-arm/platforms/exynos5.h |  7 +++++
 2 files changed, 59 insertions(+)

diff --git a/xen/arch/arm/platforms/exynos5.c b/xen/arch/arm/platforms/exynos5.c
index 65e584f..a210404 100644
--- a/xen/arch/arm/platforms/exynos5.c
+++ b/xen/arch/arm/platforms/exynos5.c
@@ -26,6 +26,7 @@
 #include <asm/platforms/exynos5.h>
 #include <asm/platform.h>
 #include <asm/io.h>
+#include <asm/delay.h>
 
 static int exynos5_init_time(void)
 {
@@ -85,6 +86,46 @@ static int __init exynos5_smp_init(void)
     return 0;
 }
 
+static int __init exynos5410_smp_init(void)
+{
+    void __iomem *sysram;
+    void __iomem *power;
+    char *c;
+    int i;
+
+    /* Power the secondary cores. */
+    for (i = 1; i < EXYNOS5410_NUM_CPUS; i++) {
+       power = ioremap_nocache(EXYNOS5410_POWER_CPU_BASE +
+                               i * EXYNOS5410_POWER_CPU_OFFSET, PAGE_SIZE);
+       c = (char *) power;
+       dprintk(XENLOG_INFO, "Power: %x status: %x\n", c[0], c[4]);
+       c[0] = EXYNOS5410_POWER_ENABLE;
+       dprintk(XENLOG_INFO, "Waiting for power status to change to %d\n",
+               EXYNOS5410_POWER_ENABLE);
+       while (c[4] != EXYNOS5410_POWER_ENABLE) {
+           udelay(1);
+       }
+       dprintk(XENLOG_INFO, "Power status changed to %d!\n",
+               EXYNOS5410_POWER_ENABLE);
+       iounmap(power);
+
+       sysram = ioremap_nocache(EXYNOS5410_PA_SYSRAM, PAGE_SIZE);
+       if ( !sysram )
+       {
+           dprintk(XENLOG_ERR, "Unable to map exynos5 MMIO\n");
+           return -EFAULT;
+       }
+
+       printk("Set SYSRAM to %"PRIpaddr" (%p)\n",
+              __pa(init_secondary), init_secondary);
+       writel(__pa(init_secondary), sysram);
+
+       iounmap(sysram);
+
+    }
+    return 0;
+}
+
 static void exynos5_reset(void)
 {
     void __iomem *pmu;
@@ -105,6 +146,7 @@ static void exynos5_reset(void)
 static const char * const exynos5_dt_compat[] __initconst =
 {
     "samsung,exynos5250",
+    "samsung,exynos5410",
     NULL
 };
 
@@ -128,6 +170,16 @@ PLATFORM_START(exynos5, "SAMSUNG EXYNOS5")
     .blacklist_dev = exynos5_blacklist_dev,
 PLATFORM_END
 
+PLATFORM_START(exynos5410, "SAMSUNG EXYNOS5410")
+    .compatible = exynos5_dt_compat,
+    .init_time = exynos5_init_time,
+    .specific_mapping = exynos5_specific_mapping,
+    .smp_init = exynos5410_smp_init,
+    .cpu_up = cpu_up_send_sgi,
+    .reset = exynos5_reset,
+    .blacklist_dev = exynos5_blacklist_dev,
+PLATFORM_END
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-arm/platforms/exynos5.h b/xen/include/asm-arm/platforms/exynos5.h
index ea941e7..8bc4884 100644
--- a/xen/include/asm-arm/platforms/exynos5.h
+++ b/xen/include/asm-arm/platforms/exynos5.h
@@ -14,6 +14,13 @@
 
 #define S5P_PA_SYSRAM   0x02020000
 
+/* Exynos5410 specific */
+#define EXYNOS5410_PA_SYSRAM        0x0207301c
+#define EXYNOS5410_NUM_CPUS         0x04
+#define EXYNOS5410_POWER_CPU_BASE   (0x10040000 + 0x2000)
+#define EXYNOS5410_POWER_CPU_OFFSET (0x80)
+#define EXYNOS5410_POWER_ENABLE     (0x03)
+
 #endif /* __ASM_ARM_PLATFORMS_EXYNOS5_H */
 /*
  * Local variables:
-- 
1.9.1

Re: [ARM:PATCH v1 1/1] Add Odroid-XU (Exynos5410) support

[Ian Campbell]

On Thu, 2014-07-24 at 15:47 -0700, Suriyan Ramasami wrote:
> static int __init exynos5410_smp_init(void)
> +{
> +    void __iomem *sysram;
> +    void __iomem *power;
> +    char *c;
> +    int i;
> +
> +    /* Power the secondary cores. */
> +    for (i = 1; i < EXYNOS5410_NUM_CPUS; i++) {
> +       power = ioremap_nocache(EXYNOS5410_POWER_CPU_BASE +
> +                               i * EXYNOS5410_POWER_CPU_OFFSET, PAGE_SIZE);
> +       c = (char *) power;
> +       dprintk(XENLOG_INFO, "Power: %x status: %x\n", c[0], c[4]);
> +       c[0] = EXYNOS5410_POWER_ENABLE;
> +       dprintk(XENLOG_INFO, "Waiting for power status to change to %d\n",
> +               EXYNOS5410_POWER_ENABLE);
> +       while (c[4] != EXYNOS5410_POWER_ENABLE) {
> +           udelay(1);
> +       }
> +       dprintk(XENLOG_INFO, "Power status changed to %d!\n",
> +               EXYNOS5410_POWER_ENABLE);
> +       iounmap(power);

Doesn't this turn on the core power before setting the strartup address (below)?

> +
> +       sysram = ioremap_nocache(EXYNOS5410_PA_SYSRAM, PAGE_SIZE);
> +       if ( !sysram )
> +       {
> +           dprintk(XENLOG_ERR, "Unable to map exynos5 MMIO\n");
> +           return -EFAULT;
> +       }
> +
> +       printk("Set SYSRAM to %"PRIpaddr" (%p)\n",
> +              __pa(init_secondary), init_secondary);
> +       writel(__pa(init_secondary), sysram);
> +
> +       iounmap(sysram);

You do this for every CPU even thought the address doesn't differ, is that right?

> +    }
> +    return 0;
> +}
> 
> @@ -105,6 +146,7 @@ static void exynos5_reset(void)
>  static const char * const exynos5_dt_compat[] __initconst =
>  {
>      "samsung,exynos5250",
> +    "samsung,exynos5410",
>      NULL
>  };
>  
> @@ -128,6 +170,16 @@ PLATFORM_START(exynos5, "SAMSUNG EXYNOS5")
>      .blacklist_dev = exynos5_blacklist_dev,
>  PLATFORM_END
>  
> +PLATFORM_START(exynos5410, "SAMSUNG EXYNOS5410")

Both of the PLATFORM_START's now refer to the same compatible list, so
both of them will match. I don't know which one will win. I suppose it
must be your new one or else you wouldn't have been able to test.


You need to either:

create two compatible lists, one for each PLATFORM block

or

create a single PLATFORM with an smp_init which dispatches to the
correct code based on the compatible ID of the platform.

Looking at your new smp_init can you do

        Write SYSRAM

        if (! cmpat 5410 ) 
                return
                
    for each cpu
                enable power.

?

If you do end up with two smp init functions please also rename the
existing exynos5_smp_init to be 5250 specific.

It's also possible that you should do the per-cpu power on in the cpu_up
hook rather than smp_init. In which case smp_init would stay as it is
and cpu_up would become:

        if ( 5410 ) 
                map and write power enable
                
        cpu_up_send_sgi

or something like that.

Ian.

Re: [ARM:PATCH v1 1/1] Add Odroid-XU (Exynos5410) support

[Julien Grall]

Hi Suriyan,

On 07/24/2014 11:47 PM, Suriyan Ramasami wrote:
>    XEN/ARM: Add Odroid-XU support
> 
>    The Odroid-XU from hardkernel is an Exynos5410 based board.
>    This patch adds support for the above said board.
> 
> Signed-off-by: Suriyan Ramasami <suriyan.r@gmail.com>
> ---
>  xen/arch/arm/platforms/exynos5.c        | 52 +++++++++++++++++++++++++++++++++
>  xen/include/asm-arm/platforms/exynos5.h |  7 +++++
>  2 files changed, 59 insertions(+)
> 
> diff --git a/xen/arch/arm/platforms/exynos5.c b/xen/arch/arm/platforms/exynos5.c
> index 65e584f..a210404 100644
> --- a/xen/arch/arm/platforms/exynos5.c
> +++ b/xen/arch/arm/platforms/exynos5.c
> @@ -26,6 +26,7 @@
>  #include <asm/platforms/exynos5.h>
>  #include <asm/platform.h>
>  #include <asm/io.h>
> +#include <asm/delay.h>
>  
>  static int exynos5_init_time(void)
>  {
> @@ -85,6 +86,46 @@ static int __init exynos5_smp_init(void)
>      return 0;
>  }
>  
> +static int __init exynos5410_smp_init(void)
> +{
> +    void __iomem *sysram;
> +    void __iomem *power;
> +    char *c;
> +    int i;
> +
> +    /* Power the secondary cores. */
> +    for (i = 1; i < EXYNOS5410_NUM_CPUS; i++) {

Can we avoid hardcoding the number of CPUs here and rely on the device tree?

> +       power = ioremap_nocache(EXYNOS5410_POWER_CPU_BASE +
> +                               i * EXYNOS5410_POWER_CPU_OFFSET, PAGE_SIZE);

You forgot to check the return of ioremap_nocache.

> +       c = (char *) power;
> +       dprintk(XENLOG_INFO, "Power: %x status: %x\n", c[0], c[4]);
> +       c[0] = EXYNOS5410_POWER_ENABLE;

You have to use read*, write* helpers when the MMIO is mapped via ioremap_*.

Otherwise the compiler may reorder the access to the region and the
behavior would be undefined.

The remark is the same everywhere in this function.

> +       dprintk(XENLOG_INFO, "Waiting for power status to change to %d\n",
> +               EXYNOS5410_POWER_ENABLE);
> +       while (c[4] != EXYNOS5410_POWER_ENABLE) {

The Xen coding style request the "{" to be on a newline.

> +           udelay(1);
> +       }
> +       dprintk(XENLOG_INFO, "Power status changed to %d!\n",
> +               EXYNOS5410_POWER_ENABLE);
> +       iounmap(power);
> +
> +       sysram = ioremap_nocache(EXYNOS5410_PA_SYSRAM, PAGE_SIZE);
> +       if ( !sysram )
> +       {
> +           dprintk(XENLOG_ERR, "Unable to map exynos5 MMIO\n");
> +           return -EFAULT;
> +       }
> +
> +       printk("Set SYSRAM to %"PRIpaddr" (%p)\n",
> +              __pa(init_secondary), init_secondary);
> +       writel(__pa(init_secondary), sysram);
> +
> +       iounmap(sysram);
> +
> +    }
> +    return 0;
> +}
> +

Regards,

-- 
Julien Grall

Re: [ARM:PATCH v1 1/1] Add Odroid-XU (Exynos5410) support

[Ian Campbell]

On Fri, 2014-07-25 at 13:19 +0100, Julien Grall wrote:

> > +       dprintk(XENLOG_INFO, "Waiting for power status to change to %d\n",
> > +               EXYNOS5410_POWER_ENABLE);
> > +       while (c[4] != EXYNOS5410_POWER_ENABLE) {
> 
> The Xen coding style request the "{" to be on a newline.

Oh and spaces inside the ()'s for whiles and the for which was above.
e.g.

        while ( c[4] != EXYNOS5410_POWER_ENABLE )
        {

Plus c[4] should as Julien mentioned be a read*().

Ian.

Re: [ARM:PATCH v1 1/1] Add Odroid-XU (Exynos5410) support

[Suriyan Ramasami]

Thanks Ian/Julien for the reviews and corrections. Much appreciated.

I shall rework the code based on all your suggestions.

Ian, as you pointed out, I will move the EXYNOS5410_PA_SYSRAM setting
in smp_init, moving the power up sequence to a cpu_up call. This way,
cpu_up will be called for each cpu as mentioned in the dtb, removing
the hardcoding that Julien referred to.

I shall also use the read*/write* helpers mentioned by Julien, and
shall abide by the XEN coding style.

Please await my Patch version 2.

Thanks as usual
- Suriyan

PS: I have noticed that there is no ARM port of XEN having more than 2
CPUs. Is that correct? I am mentioning this, cause with the XU, though
I can bring up all 4 processors in XEN and in dom0, domU fails to make
much boot progress when it is xl created. I am able to boot domU, if I
restrict the dtb for dom0 to 2 CPUs.


On Fri, Jul 25, 2014 at 5:39 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2014-07-25 at 13:19 +0100, Julien Grall wrote:
>
>> > +       dprintk(XENLOG_INFO, "Waiting for power status to change to %d\n",
>> > +               EXYNOS5410_POWER_ENABLE);
>> > +       while (c[4] != EXYNOS5410_POWER_ENABLE) {
>>
>> The Xen coding style request the "{" to be on a newline.
>
> Oh and spaces inside the ()'s for whiles and the for which was above.
> e.g.
>
>         while ( c[4] != EXYNOS5410_POWER_ENABLE )
>         {
>
> Plus c[4] should as Julien mentioned be a read*().
>
> Ian.
>

Re: [ARM:PATCH v1 1/1] Add Odroid-XU (Exynos5410) support

[Ian Campbell]

On Fri, 2014-07-25 at 10:45 -0700, Suriyan Ramasami wrote:
> PS: I have noticed that there is no ARM port of XEN having more than 2
> CPUs. Is that correct?

I don't think so. Midway has 4 and X-gene has 8.

>  I am mentioning this, cause with the XU, though
> I can bring up all 4 processors in XEN and in dom0, domU fails to make
> much boot progress when it is xl created. I am able to boot domU, if I
> restrict the dtb for dom0 to 2 CPUs.

How strange.

Are all 4 cores the same or is this a 2x2 big.LITTLE system? I suspect
we don't handle mixed systems at all well right now.

Ian.

Re: [ARM:PATCH v1 1/1] Add Odroid-XU (Exynos5410) support

[Suriyan Ramasami]

On Fri, Jul 25, 2014 at 1:05 PM, Ian Campbell <ian.campbell@citrix.com> wrote:
> On Fri, 2014-07-25 at 10:45 -0700, Suriyan Ramasami wrote:
>> PS: I have noticed that there is no ARM port of XEN having more than 2
>> CPUs. Is that correct?
>
> I don't think so. Midway has 4 and X-gene has 8.
>
>>  I am mentioning this, cause with the XU, though
>> I can bring up all 4 processors in XEN and in dom0, domU fails to make
>> much boot progress when it is xl created. I am able to boot domU, if I
>> restrict the dtb for dom0 to 2 CPUs.
>
> How strange.
>
> Are all 4 cores the same or is this a 2x2 big.LITTLE system? I suspect
> we don't handle mixed systems at all well right now.
The Odroid XU is a big.LITTLE system, but it has 4 big and 4 LITTLE
CPUs. So, it should handle the 4 CPUs. I must be doing something
wrong. I shall try to debug this ...

- Suriyan
>
> Ian.
>

Re: [ARM:PATCH v1 1/1] Add Odroid-XU (Exynos5410) support

[Suriyan Ramasami]

On Fri, Jul 25, 2014 at 1:05 PM, Ian Campbell <ian.campbell@citrix.com> wrote:
> On Fri, 2014-07-25 at 10:45 -0700, Suriyan Ramasami wrote:
>> PS: I have noticed that there is no ARM port of XEN having more than 2
>> CPUs. Is that correct?
>
> I don't think so. Midway has 4 and X-gene has 8.
>
>>  I am mentioning this, cause with the XU, though
>> I can bring up all 4 processors in XEN and in dom0, domU fails to make
>> much boot progress when it is xl created. I am able to boot domU, if I
>> restrict the dtb for dom0 to 2 CPUs.
>
> How strange.
One thing I noticed is that if I have 4 dom0 CPUs, and I have a domU
with vcpus=4, it starts the domU with 1 vcpu as seen in xl list. This
xl creation does not boot up. Doing a repeated xenctx on this domU
gives the below sequence:
root@dom0:~/Debug# ./domUtrace.sh 11
0xc026ba78 rb_erase
0xc000dc10 handle_IRQ
0xc0008434 gic_handle_irq
0xc0053abc rcu_irq_exit
0xc0008442 gic_handle_irq
0xc0055594 ktime_get
0xc0053ab8 rcu_irq_exit
0xc005a9d4 tick_periodic
0xc0053a92 rcu_irq_exit
0xc0053a9a rcu_irq_exit
0xc00491e0 do_raw_spin_lock
0xc0053a92 rcu_irq_exit
0xc003e92a task_tick_fair
0xc0008454 gic_handle_irq
0xc0008442 gic_handle_irq
0xc0008454 gic_handle_irq
0xc005a9f2 tick_periodic
0xc004938e do_raw_spin_unlock
0xc000dc16 handle_IRQ
0xc0053ab2 rcu_irq_exit
0xc0039ed0 idle_cpu

I also noticed that in some instances of "xl create" it does bring up
domU with 4 cpus as mentioned in the domU.cfg file, and in those
instances the domU boots up.

Is this some kind of bug?

>
> Are all 4 cores the same or is this a 2x2 big.LITTLE system? I suspect
> we don't handle mixed systems at all well right now.
>
> Ian.
>

Re: [ARM:PATCH v1 1/1] Add Odroid-XU (Exynos5410) support

[Julien Grall]

Hi Suriyan,

On 26/07/14 08:26, Suriyan Ramasami wrote:
> I also noticed that in some instances of "xl create" it does bring up
> domU with 4 cpus as mentioned in the domU.cfg file, and in those
> instances the domU boots up.
>
> Is this some kind of bug?

We use PSCI to boot secondary CPUs. You may want to check the the PSCI 
call has effectively been issued for those VCPUs.

Which Xen and Linux version are you using?

>>
>> Are all 4 cores the same or is this a 2x2 big.LITTLE system? I suspect
>> we don't handle mixed systems at all well right now.

Xen will be able to boot with different kind of CPUs. But the guest may 
have strange behavior as the VCPU can moved between the different core.

Regards,

-- 
Julien Grall

Re: [ARM:PATCH v1 1/1] Add Odroid-XU (Exynos5410) support

[Suriyan Ramasami]

Hi Julien,

On Sat, Jul 26, 2014 at 4:28 AM, Julien Grall <julien.grall@linaro.org> wrote:
> Hi Suriyan,
>
>
> On 26/07/14 08:26, Suriyan Ramasami wrote:
>>
>> I also noticed that in some instances of "xl create" it does bring up
>> domU with 4 cpus as mentioned in the domU.cfg file, and in those
>> instances the domU boots up.
>>
>> Is this some kind of bug?
>
>
> We use PSCI to boot secondary CPUs. You may want to check the the PSCI call
> has effectively been issued for those VCPUs.
>
I shall check on this!
> Which Xen and Linux version are you using?
Xen is 4.5 dev (git clone git://xenbits.xen.org/xen.git)
Linux is 3.14 from hardkernel linux repository, branch: odroid-3.14.y-linaro

>
>>>
>>> Are all 4 cores the same or is this a 2x2 big.LITTLE system? I suspect
>>> we don't handle mixed systems at all well right now.
>
>
> Xen will be able to boot with different kind of CPUs. But the guest may have
> strange behavior as the VCPU can moved between the different core.
>
> Regards,
>
> --
> Julien Grall

Re: [ARM:PATCH v1 1/1] Add Odroid-XU (Exynos5410) support

[Julien Grall]

On 26/07/14 17:02, Suriyan Ramasami wrote:
> Hi Julien,
>
> On Sat, Jul 26, 2014 at 4:28 AM, Julien Grall <julien.grall@linaro.org> wrote:
>> Hi Suriyan,
>>
>>
>> On 26/07/14 08:26, Suriyan Ramasami wrote:
>>>
>>> I also noticed that in some instances of "xl create" it does bring up
>>> domU with 4 cpus as mentioned in the domU.cfg file, and in those
>>> instances the domU boots up.
>>>
>>> Is this some kind of bug?
>>
>>
>> We use PSCI to boot secondary CPUs. You may want to check the the PSCI call
>> has effectively been issued for those VCPUs.
>>
> I shall check on this!
>> Which Xen and Linux version are you using?
> Xen is 4.5 dev (git clone git://xenbits.xen.org/xen.git)
> Linux is 3.14 from hardkernel linux repository, branch: odroid-3.14.y-linaro

Can you try a Linux upstream? The error may come from the hardkernel linux.

Regards,

-- 
Julien Grall

Re: [ARM:PATCH v1 1/1] Add Odroid-XU (Exynos5410) support

[Suriyan Ramasami]

On Sat, Jul 26, 2014 at 10:58 AM, Julien Grall <julien.grall@linaro.org> wrote:
>
>
> On 26/07/14 17:02, Suriyan Ramasami wrote:
>>
>> Hi Julien,
>>
>> On Sat, Jul 26, 2014 at 4:28 AM, Julien Grall <julien.grall@linaro.org>
>> wrote:
>>>
>>> Hi Suriyan,
>>>
>>>
>>> On 26/07/14 08:26, Suriyan Ramasami wrote:
>>>>
>>>>
>>>> I also noticed that in some instances of "xl create" it does bring up
>>>> domU with 4 cpus as mentioned in the domU.cfg file, and in those
>>>> instances the domU boots up.
>>>>
>>>> Is this some kind of bug?
>>>
>>>
>>>
>>> We use PSCI to boot secondary CPUs. You may want to check the the PSCI
>>> call
>>> has effectively been issued for those VCPUs.
>>>
>> I shall check on this!
>>>
>>> Which Xen and Linux version are you using?
>>
>> Xen is 4.5 dev (git clone git://xenbits.xen.org/xen.git)
>> Linux is 3.14 from hardkernel linux repository, branch:
>> odroid-3.14.y-linaro
>
>
> Can you try a Linux upstream? The error may come from the hardkernel linux.

Is this for domU?
For dom0, I do not have a working kernel for upstream for the XU. I
did try 3.16 samsung-next as well as mainline linux and the dts needs
to be worked upon (or so I think)

Using upstream for domU exhibits the same behavior.

One out of roughly 10 creates succeeds (I can get console output).
In the cases that succeed, I do see that do_psci_cpu_on() gets called.
In the cases that domU does not boot up, the call to do_psci_cpu_on()
does not happen.

>
> Regards,
>
> --
> Julien Grall

Re: [ARM:PATCH v1 1/1] Add Odroid-XU (Exynos5410) support

[Julien Grall]

On 26/07/14 21:26, Suriyan Ramasami wrote:
> On Sat, Jul 26, 2014 at 10:58 AM, Julien Grall <julien.grall@linaro.org> wrote:
>>
>>
>> On 26/07/14 17:02, Suriyan Ramasami wrote:
>>>
>>> Hi Julien,
>>>
>>> On Sat, Jul 26, 2014 at 4:28 AM, Julien Grall <julien.grall@linaro.org>
>>> wrote:
>>>>
>>>> Hi Suriyan,
>>>>
>>>>
>>>> On 26/07/14 08:26, Suriyan Ramasami wrote:
>>>>>
>>>>>
>>>>> I also noticed that in some instances of "xl create" it does bring up
>>>>> domU with 4 cpus as mentioned in the domU.cfg file, and in those
>>>>> instances the domU boots up.
>>>>>
>>>>> Is this some kind of bug?
>>>>
>>>>
>>>>
>>>> We use PSCI to boot secondary CPUs. You may want to check the the PSCI
>>>> call
>>>> has effectively been issued for those VCPUs.
>>>>
>>> I shall check on this!
>>>>
>>>> Which Xen and Linux version are you using?
>>>
>>> Xen is 4.5 dev (git clone git://xenbits.xen.org/xen.git)
>>> Linux is 3.14 from hardkernel linux repository, branch:
>>> odroid-3.14.y-linaro
>>
>>
>> Can you try a Linux upstream? The error may come from the hardkernel linux.
>
> Is this for domU?
> For dom0, I do not have a working kernel for upstream for the XU. I
> did try 3.16 samsung-next as well as mainline linux and the dts needs
> to be worked upon (or so I think)

I was talking about domU.

> Using upstream for domU exhibits the same behavior.
>
> One out of roughly 10 creates succeeds (I can get console output).
> In the cases that succeed, I do see that do_psci_cpu_on() gets called.
> In the cases that domU does not boot up, the call to do_psci_cpu_on()
> does not happen.

Reading back one of your previous mail:

"I have noticed that there is no ARM port of XEN having more than 2
CPUs. Is that correct? I am mentioning this, cause with the XU, though
I can bring up all 4 processors in XEN and in dom0, domU fails to make
much boot progress when it is xl created. I am able to boot domU, if I
restrict the dtb for dom0 to 2 CPUs."

By "I restrict the dtb for dom0 to 2 CPUs", did you mean removing some 
CPUs in the device tree or using dom0_max_vcpus=2 on Xen command line?

I was wondering if dom0 is touching the physical CPUs by mistake (mainly 
because we map some regions used to control them).
It might be worse to check that no cpufreq or power management is called 
on DOM0 at any time.

Regards,

-- 
Julien Grall

Re: [ARM:PATCH v1 1/1] Add Odroid-XU (Exynos5410) support

[Julien Grall]

On 26/07/14 22:24, Julien Grall wrote:
>
>
> On 26/07/14 21:26, Suriyan Ramasami wrote:
>> On Sat, Jul 26, 2014 at 10:58 AM, Julien Grall
>> <julien.grall@linaro.org> wrote:
>>>
>>>
>>> On 26/07/14 17:02, Suriyan Ramasami wrote:
>>>>
>>>> Hi Julien,
>>>>
>>>> On Sat, Jul 26, 2014 at 4:28 AM, Julien Grall <julien.grall@linaro.org>
>>>> wrote:
>>>>>
>>>>> Hi Suriyan,
>>>>>
>>>>>
>>>>> On 26/07/14 08:26, Suriyan Ramasami wrote:
>>>>>>
>>>>>>
>>>>>> I also noticed that in some instances of "xl create" it does bring up
>>>>>> domU with 4 cpus as mentioned in the domU.cfg file, and in those
>>>>>> instances the domU boots up.
>>>>>>
>>>>>> Is this some kind of bug?
>>>>>
>>>>>
>>>>>
>>>>> We use PSCI to boot secondary CPUs. You may want to check the the PSCI
>>>>> call
>>>>> has effectively been issued for those VCPUs.
>>>>>
>>>> I shall check on this!
>>>>>
>>>>> Which Xen and Linux version are you using?
>>>>
>>>> Xen is 4.5 dev (git clone git://xenbits.xen.org/xen.git)
>>>> Linux is 3.14 from hardkernel linux repository, branch:
>>>> odroid-3.14.y-linaro
>>>
>>>
>>> Can you try a Linux upstream? The error may come from the hardkernel
>>> linux.
>>
>> Is this for domU?
>> For dom0, I do not have a working kernel for upstream for the XU. I
>> did try 3.16 samsung-next as well as mainline linux and the dts needs
>> to be worked upon (or so I think)
>
> I was talking about domU.
>
>> Using upstream for domU exhibits the same behavior.
>>
>> One out of roughly 10 creates succeeds (I can get console output).
>> In the cases that succeed, I do see that do_psci_cpu_on() gets called.
>> In the cases that domU does not boot up, the call to do_psci_cpu_on()
>> does not happen.
>
> Reading back one of your previous mail:
>
> "I have noticed that there is no ARM port of XEN having more than 2
> CPUs. Is that correct? I am mentioning this, cause with the XU, though
> I can bring up all 4 processors in XEN and in dom0, domU fails to make
> much boot progress when it is xl created. I am able to boot domU, if I
> restrict the dtb for dom0 to 2 CPUs."
>
> By "I restrict the dtb for dom0 to 2 CPUs", did you mean removing some
> CPUs in the device tree or using dom0_max_vcpus=2 on Xen command line?

I forgot a question. Does a guest with 1 VCPU is working fine? I can't 
fine any clue on your mails.

> I was wondering if dom0 is touching the physical CPUs by mistake (mainly
> because we map some regions used to control them).
> It might be worse to check that no cpufreq or power management is called
> on DOM0 at any time.

-- 
Julien Grall

Re: [ARM:PATCH v1 1/1] Add Odroid-XU (Exynos5410) support

[Suriyan Ramasami]

On Sat, Jul 26, 2014 at 2:26 PM, Julien Grall <julien.grall@linaro.org> wrote:
>
>
> On 26/07/14 22:24, Julien Grall wrote:
>>
>>
>>
>> On 26/07/14 21:26, Suriyan Ramasami wrote:
>>>
>>> On Sat, Jul 26, 2014 at 10:58 AM, Julien Grall
>>> <julien.grall@linaro.org> wrote:
>>>>
>>>>
>>>>
>>>> On 26/07/14 17:02, Suriyan Ramasami wrote:
>>>>>
>>>>>
>>>>> Hi Julien,
>>>>>
>>>>> On Sat, Jul 26, 2014 at 4:28 AM, Julien Grall <julien.grall@linaro.org>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Hi Suriyan,
>>>>>>
>>>>>>
>>>>>> On 26/07/14 08:26, Suriyan Ramasami wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I also noticed that in some instances of "xl create" it does bring up
>>>>>>> domU with 4 cpus as mentioned in the domU.cfg file, and in those
>>>>>>> instances the domU boots up.
>>>>>>>
>>>>>>> Is this some kind of bug?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> We use PSCI to boot secondary CPUs. You may want to check the the PSCI
>>>>>> call
>>>>>> has effectively been issued for those VCPUs.
>>>>>>
>>>>> I shall check on this!
>>>>>>
>>>>>>
>>>>>> Which Xen and Linux version are you using?
>>>>>
>>>>>
>>>>> Xen is 4.5 dev (git clone git://xenbits.xen.org/xen.git)
>>>>> Linux is 3.14 from hardkernel linux repository, branch:
>>>>> odroid-3.14.y-linaro
>>>>
>>>>
>>>>
>>>> Can you try a Linux upstream? The error may come from the hardkernel
>>>> linux.
>>>
>>>
>>> Is this for domU?
>>> For dom0, I do not have a working kernel for upstream for the XU. I
>>> did try 3.16 samsung-next as well as mainline linux and the dts needs
>>> to be worked upon (or so I think)
>>
>>
>> I was talking about domU.
>>
>>> Using upstream for domU exhibits the same behavior.
>>>
>>> One out of roughly 10 creates succeeds (I can get console output).
>>> In the cases that succeed, I do see that do_psci_cpu_on() gets called.
>>> In the cases that domU does not boot up, the call to do_psci_cpu_on()
>>> does not happen.
>>
>>
>> Reading back one of your previous mail:
>>
>> "I have noticed that there is no ARM port of XEN having more than 2
>> CPUs. Is that correct? I am mentioning this, cause with the XU, though
>> I can bring up all 4 processors in XEN and in dom0, domU fails to make
>> much boot progress when it is xl created. I am able to boot domU, if I
>> restrict the dtb for dom0 to 2 CPUs."
>>
>> By "I restrict the dtb for dom0 to 2 CPUs", did you mean removing some
>> CPUs in the device tree or using dom0_max_vcpus=2 on Xen command line?
>
>
I remove CPUs from the device tree.

> I forgot a question. Does a guest with 1 VCPU is working fine? I can't fine
> any clue on your mails.
>
This will summarize it:
Case I: dom0 device tree has only CPU0 (CPU1, 2, 3 are commented out)
domU: vcpu = 1
domU boots all the time. No Issues.

Case 2: dom0 device tree has only CPU0 and CPU1 (CPU2, 3 are commented out)
domU: vcpu =1
domU boots sometimes.

>
>> I was wondering if dom0 is touching the physical CPUs by mistake (mainly
>> because we map some regions used to control them).
>> It might be worse to check that no cpufreq or power management is called
>> on DOM0 at any time.
>
I shall dig into this some more.
Thanks!
>
> --
> Julien Grall

Re: [ARM:PATCH v1 1/1] Add Odroid-XU (Exynos5410) support

[Julien Grall]

Hi Suriyan,

On 07/27/2014 07:12 PM, Suriyan Ramasami wrote:
>>
>>> I was wondering if dom0 is touching the physical CPUs by mistake (mainly
>>> because we map some regions used to control them).
>>> It might be worse to check that no cpufreq or power management is called
>>> on DOM0 at any time.
>>
> I shall dig into this some more.
> Thanks!

I would give a try with:
	- Xen: 2 CPUs
	- DOM0: 1 VCPU
	- Guest: 1 VCPU

You can restrict the number of DOM0 VCPUs with dom0_max_vcpus=n where n
is the number of VCPUs for DOM0.

If it's not failing then the error is in Linux.

Regards,

-- 
Julien Grall

Re: [ARM:PATCH v1 1/1] Add Odroid-XU (Exynos5410) support

[Suriyan Ramasami]

Hello Julien,

On Mon, Jul 28, 2014 at 5:53 AM, Julien Grall <julien.grall@linaro.org> wrote:
> Hi Suriyan,
>
> On 07/27/2014 07:12 PM, Suriyan Ramasami wrote:
>>>
>>>> I was wondering if dom0 is touching the physical CPUs by mistake (mainly
>>>> because we map some regions used to control them).
>>>> It might be worse to check that no cpufreq or power management is called
>>>> on DOM0 at any time.
>>>
>> I shall dig into this some more.
>> Thanks!
>
> I would give a try with:
>         - Xen: 2 CPUs
>         - DOM0: 1 VCPU
>         - Guest: 1 VCPU
>
> You can restrict the number of DOM0 VCPUs with dom0_max_vcpus=n where n
> is the number of VCPUs for DOM0.
>
> If it's not failing then the error is in Linux.
>
I did the above suggestion and I tried bringing up domU atleast 30
times. None of the attempts succeeded - domU gave no console output. I
also tried with a XEN compile with exynos5_specific_mapping not being
called for the Odroid-XU (don't know if this is of any relevance)

Does this imply the problem is with Xen 4.5 dev branch?

Relevant logs:
------------ 8< ------------
XEN:
...
(XEN) Command line: sync_console console=dtuart
dtuart=/serial@12C20000 earlyprintk=xen dom0_mem=512M dom0_max_vcpus=1
...
(XEN) Bringing up CPU1
(XEN) exynos5.c:126: Power: 0 status: 0
(XEN) exynos5.c:130: Waiting for power status to change to 3
(XEN) exynos5.c:138: Power status changed to 3!
(XEN) CPU 1 booted.
(XEN) Brought up 2 CPUs

DOM0:
...
[    0.000000] Kernel command line: console=hvc0 earlyprintk debug
clk_ignore_unused root=/dev/mmcblk0p2 rootwait rw
...
[    0.038352] Xen: initializing cpu0
[    0.038414] Setting up static identity map for 0x604940c8 - 0x60494114
[    0.039487] Brought up 1 CPUs
[    0.039496] SMP: Total of 1 processors activated.
[    0.039503] CPU: All CPU(s) started in SVC mode.

root@dom0:~/Debug# xl vcpu-list
Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
Domain-0                             0     0    0   r--     123.3  all
domU2                                2     0    1   r--     670.9  all

And domU2's sample function from xenctx 2 is as follows: (domU2 is
linux mainline)
root@dom0:~/Debug# ./domUtrace.sh 2
0xc0054c74 do_raw_spin_unlock
0xc00085d0 gic_handle_irq
0xc006c670 tick_periodic
0xc00085d0 gic_handle_irq
0xc006789c get_xtime_and_monotonic_and_sleep_offset
0xc00085d0 gic_handle_irq
0xc0054a90 do_raw_spin_lock
0xc0021934 irq_exit
0xc00085d0 gic_handle_irq
0xc0054c60 do_raw_spin_unlock
0xc00455e8 calc_global_load
0xc00085d0 gic_handle_irq
0xc006175c cpu_needs_another_gp
0xc00085d0 gic_handle_irq
0xc003b1b8 hrtimer_run_queues
0xc00085d0 gic_handle_irq
----------- 8< ----------------

Thanks for all the pointers so far!

> Regards,
>
> --
> Julien Grall

Re: [ARM:PATCH v1 1/1] Add Odroid-XU (Exynos5410) support

[Suriyan Ramasami]

Hello Ian/Julien,
    I did some more debugging and found this weirdness. It has me a
little baffled.

I added xen_raw_printk() as suggested by Ian in earlier posts as a
mechanism for debugging domU (xen to be compiled with debug=y), and I
have been slapping myself silly as to why I didn't try this before! It
definitely gave me output that I could then hone in on!

The times that domU was not booting up, it crashed with a "divide by
zero" in the linux kernel because of the arch_timer_rate being 0. I
would see the warning "Architected timer frequency not available" in
the kernel log (xen output)

This is indeed baffling! Especially as I am setting CNTFRQ to the the
right value, and I know it is not 0!

The times that domU boots up, it does read the CNTFRQ value correctly!

This is the call trace that happens in drivers/clocksource/arm_arch_timer.c

It comes into the function, and finds arch_timer_rate as 0.
It tries to read clock_frequency property in the device tree. It is not set.
It checks if cntbase is set. It is not set.
It then calls arch_timer_get_cntfrq() to issue the mrc call.
I have printed out the return value of arch_timer_get_cntfrq() and
sometimes I get a 0 and sometimes I get 24000000.

arch_timer_get_cntfrq is nothing but:
static inline u32 arch_timer_get_cntfrq(void)
{
        u32 val;
        asm volatile("mrc p15, 0, %0, c14, c0, 0" : "=r" (val));
        return val;
}

Are the mrc calls trapped by XEN?

Any pointers are appreciated!
- Suriyan


On Mon, Jul 28, 2014 at 11:06 AM, Suriyan Ramasami <suriyan.r@gmail.com> wrote:
> Hello Julien,
>
> On Mon, Jul 28, 2014 at 5:53 AM, Julien Grall <julien.grall@linaro.org> wrote:
>> Hi Suriyan,
>>
>> On 07/27/2014 07:12 PM, Suriyan Ramasami wrote:
>>>>
>>>>> I was wondering if dom0 is touching the physical CPUs by mistake (mainly
>>>>> because we map some regions used to control them).
>>>>> It might be worse to check that no cpufreq or power management is called
>>>>> on DOM0 at any time.
>>>>
>>> I shall dig into this some more.
>>> Thanks!
>>
>> I would give a try with:
>>         - Xen: 2 CPUs
>>         - DOM0: 1 VCPU
>>         - Guest: 1 VCPU
>>
>> You can restrict the number of DOM0 VCPUs with dom0_max_vcpus=n where n
>> is the number of VCPUs for DOM0.
>>
>> If it's not failing then the error is in Linux.
>>
> I did the above suggestion and I tried bringing up domU atleast 30
> times. None of the attempts succeeded - domU gave no console output. I
> also tried with a XEN compile with exynos5_specific_mapping not being
> called for the Odroid-XU (don't know if this is of any relevance)
>
> Does this imply the problem is with Xen 4.5 dev branch?
>
> Relevant logs:
> ------------ 8< ------------
> XEN:
> ...
> (XEN) Command line: sync_console console=dtuart
> dtuart=/serial@12C20000 earlyprintk=xen dom0_mem=512M dom0_max_vcpus=1
> ...
> (XEN) Bringing up CPU1
> (XEN) exynos5.c:126: Power: 0 status: 0
> (XEN) exynos5.c:130: Waiting for power status to change to 3
> (XEN) exynos5.c:138: Power status changed to 3!
> (XEN) CPU 1 booted.
> (XEN) Brought up 2 CPUs
>
> DOM0:
> ...
> [    0.000000] Kernel command line: console=hvc0 earlyprintk debug
> clk_ignore_unused root=/dev/mmcblk0p2 rootwait rw
> ...
> [    0.038352] Xen: initializing cpu0
> [    0.038414] Setting up static identity map for 0x604940c8 - 0x60494114
> [    0.039487] Brought up 1 CPUs
> [    0.039496] SMP: Total of 1 processors activated.
> [    0.039503] CPU: All CPU(s) started in SVC mode.
>
> root@dom0:~/Debug# xl vcpu-list
> Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
> Domain-0                             0     0    0   r--     123.3  all
> domU2                                2     0    1   r--     670.9  all
>
> And domU2's sample function from xenctx 2 is as follows: (domU2 is
> linux mainline)
> root@dom0:~/Debug# ./domUtrace.sh 2
> 0xc0054c74 do_raw_spin_unlock
> 0xc00085d0 gic_handle_irq
> 0xc006c670 tick_periodic
> 0xc00085d0 gic_handle_irq
> 0xc006789c get_xtime_and_monotonic_and_sleep_offset
> 0xc00085d0 gic_handle_irq
> 0xc0054a90 do_raw_spin_lock
> 0xc0021934 irq_exit
> 0xc00085d0 gic_handle_irq
> 0xc0054c60 do_raw_spin_unlock
> 0xc00455e8 calc_global_load
> 0xc00085d0 gic_handle_irq
> 0xc006175c cpu_needs_another_gp
> 0xc00085d0 gic_handle_irq
> 0xc003b1b8 hrtimer_run_queues
> 0xc00085d0 gic_handle_irq
> ----------- 8< ----------------
>
> Thanks for all the pointers so far!
>
>> Regards,
>>
>> --
>> Julien Grall

Re: [ARM:PATCH v1 1/1] Add Odroid-XU (Exynos5410) support

[Suriyan Ramasami]

Some more information ...
This time I started XEN with all the CPUs (4, all cpus uncommented in
the device tree).
dom0 started with no CPU restrictions => it is running with 4 VCPUs.
domU started with vcpus = 4.

root@dom0:~# xl vcpu-list
Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
Domain-0                             0     0    0   -b-      25.4  all
Domain-0                             0     1    2   -b-      22.6  all
Domain-0                             0     2    0   -b-      33.0  all
Domain-0                             0     3    1   r--      27.9  all
domU2                                3     0    3   r--     268.9  all
domU2                                3     1    -   --p       0.0  all
domU2                                3     2    -   --p       0.0  all
domU2                                3     3    -   --p       0.0  all

I have modified domU kernel so that it keeps looping and calling
arch_timer_get_cntfrq() till it returns a non zero value.
Note that domU VCPU 0 is on CPU 3. If I move it to run on CPU 0 (xl
vcpu-pin 3 0 0), then arch_timer_get_cntfrq() returns the correct
value and boot proceeds. Moving it to CPU 1, 2, or 3 does not get the
right value from arch_timer_get_cntfrq().

root@dom0:~# xl vcpu-pin 3 0 0
root@dom0:~# xl vcpu-list
Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
Domain-0                             0     0    2   -b-      28.6  all
Domain-0                             0     1    0   r--      24.5  all
Domain-0                             0     2    3   -b-      34.8  all
Domain-0                             0     3    1   -b-      29.7  all
domU2                                3     0    0   -b-     500.3  0
domU2                                3     1    2   -b-       3.2  all
domU2                                3     2    1   -b-       3.3  all
domU2                                3     3    2   -b-       3.1  all

This then boots up and I get domU console etc ...

So, why is any other CPU other than CPU0 not able to read the CNTFRQ
register? Is my CPU turn on code causing this issue, or is something
extra needed to be done to the other CPUs in the bring up code?

Thanks
- Suriyan



On Mon, Jul 28, 2014 at 1:19 PM, Suriyan Ramasami <suriyan.r@gmail.com> wrote:
> Hello Ian/Julien,
>     I did some more debugging and found this weirdness. It has me a
> little baffled.
>
> I added xen_raw_printk() as suggested by Ian in earlier posts as a
> mechanism for debugging domU (xen to be compiled with debug=y), and I
> have been slapping myself silly as to why I didn't try this before! It
> definitely gave me output that I could then hone in on!
>
> The times that domU was not booting up, it crashed with a "divide by
> zero" in the linux kernel because of the arch_timer_rate being 0. I
> would see the warning "Architected timer frequency not available" in
> the kernel log (xen output)
>
> This is indeed baffling! Especially as I am setting CNTFRQ to the the
> right value, and I know it is not 0!
>
> The times that domU boots up, it does read the CNTFRQ value correctly!
>
> This is the call trace that happens in drivers/clocksource/arm_arch_timer.c
>
> It comes into the function, and finds arch_timer_rate as 0.
> It tries to read clock_frequency property in the device tree. It is not set.
> It checks if cntbase is set. It is not set.
> It then calls arch_timer_get_cntfrq() to issue the mrc call.
> I have printed out the return value of arch_timer_get_cntfrq() and
> sometimes I get a 0 and sometimes I get 24000000.
>
> arch_timer_get_cntfrq is nothing but:
> static inline u32 arch_timer_get_cntfrq(void)
> {
>         u32 val;
>         asm volatile("mrc p15, 0, %0, c14, c0, 0" : "=r" (val));
>         return val;
> }
>
> Are the mrc calls trapped by XEN?
>
> Any pointers are appreciated!
> - Suriyan
>
>
> On Mon, Jul 28, 2014 at 11:06 AM, Suriyan Ramasami <suriyan.r@gmail.com> wrote:
>> Hello Julien,
>>
>> On Mon, Jul 28, 2014 at 5:53 AM, Julien Grall <julien.grall@linaro.org> wrote:
>>> Hi Suriyan,
>>>
>>> On 07/27/2014 07:12 PM, Suriyan Ramasami wrote:
>>>>>
>>>>>> I was wondering if dom0 is touching the physical CPUs by mistake (mainly
>>>>>> because we map some regions used to control them).
>>>>>> It might be worse to check that no cpufreq or power management is called
>>>>>> on DOM0 at any time.
>>>>>
>>>> I shall dig into this some more.
>>>> Thanks!
>>>
>>> I would give a try with:
>>>         - Xen: 2 CPUs
>>>         - DOM0: 1 VCPU
>>>         - Guest: 1 VCPU
>>>
>>> You can restrict the number of DOM0 VCPUs with dom0_max_vcpus=n where n
>>> is the number of VCPUs for DOM0.
>>>
>>> If it's not failing then the error is in Linux.
>>>
>> I did the above suggestion and I tried bringing up domU atleast 30
>> times. None of the attempts succeeded - domU gave no console output. I
>> also tried with a XEN compile with exynos5_specific_mapping not being
>> called for the Odroid-XU (don't know if this is of any relevance)
>>
>> Does this imply the problem is with Xen 4.5 dev branch?
>>
>> Relevant logs:
>> ------------ 8< ------------
>> XEN:
>> ...
>> (XEN) Command line: sync_console console=dtuart
>> dtuart=/serial@12C20000 earlyprintk=xen dom0_mem=512M dom0_max_vcpus=1
>> ...
>> (XEN) Bringing up CPU1
>> (XEN) exynos5.c:126: Power: 0 status: 0
>> (XEN) exynos5.c:130: Waiting for power status to change to 3
>> (XEN) exynos5.c:138: Power status changed to 3!
>> (XEN) CPU 1 booted.
>> (XEN) Brought up 2 CPUs
>>
>> DOM0:
>> ...
>> [    0.000000] Kernel command line: console=hvc0 earlyprintk debug
>> clk_ignore_unused root=/dev/mmcblk0p2 rootwait rw
>> ...
>> [    0.038352] Xen: initializing cpu0
>> [    0.038414] Setting up static identity map for 0x604940c8 - 0x60494114
>> [    0.039487] Brought up 1 CPUs
>> [    0.039496] SMP: Total of 1 processors activated.
>> [    0.039503] CPU: All CPU(s) started in SVC mode.
>>
>> root@dom0:~/Debug# xl vcpu-list
>> Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
>> Domain-0                             0     0    0   r--     123.3  all
>> domU2                                2     0    1   r--     670.9  all
>>
>> And domU2's sample function from xenctx 2 is as follows: (domU2 is
>> linux mainline)
>> root@dom0:~/Debug# ./domUtrace.sh 2
>> 0xc0054c74 do_raw_spin_unlock
>> 0xc00085d0 gic_handle_irq
>> 0xc006c670 tick_periodic
>> 0xc00085d0 gic_handle_irq
>> 0xc006789c get_xtime_and_monotonic_and_sleep_offset
>> 0xc00085d0 gic_handle_irq
>> 0xc0054a90 do_raw_spin_lock
>> 0xc0021934 irq_exit
>> 0xc00085d0 gic_handle_irq
>> 0xc0054c60 do_raw_spin_unlock
>> 0xc00455e8 calc_global_load
>> 0xc00085d0 gic_handle_irq
>> 0xc006175c cpu_needs_another_gp
>> 0xc00085d0 gic_handle_irq
>> 0xc003b1b8 hrtimer_run_queues
>> 0xc00085d0 gic_handle_irq
>> ----------- 8< ----------------
>>
>> Thanks for all the pointers so far!
>>
>>> Regards,
>>>
>>> --
>>> Julien Grall

Re: [ARM:PATCH v1 1/1] Add Odroid-XU (Exynos5410) support

[Ian Campbell]

On Mon, 2014-07-28 at 15:25 -0700, Suriyan Ramasami wrote:
> So, why is any other CPU other than CPU0 not able to read the CNTFRQ
> register? Is my CPU turn on code causing this issue, or is something
> extra needed to be done to the other CPUs in the bring up code?

Are you sure you are writing CNTFRQ on every pCPU? This is a processor
local register so it needs setting everywhere, not just once.

You symptoms are sounding very much like it is only set on the boot CPU.

Ian.

Re: [ARM:PATCH v1 1/1] Add Odroid-XU (Exynos5410) support

[Suriyan Ramasami]

On Tue, Jul 29, 2014 at 12:30 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2014-07-28 at 15:25 -0700, Suriyan Ramasami wrote:
>> So, why is any other CPU other than CPU0 not able to read the CNTFRQ
>> register? Is my CPU turn on code causing this issue, or is something
>> extra needed to be done to the other CPUs in the bring up code?
>
> Are you sure you are writing CNTFRQ on every pCPU? This is a processor
> local register so it needs setting everywhere, not just once.
>
Ah! I didn't know that. I was setting it only once on the booting CPU
in u-boot through am smc call.

> You symptoms are sounding very much like it is only set on the boot CPU.
>
Thanks for pointing this out. I am wondering if I should go the psci
route for the Exynos 5410 or add an smc call in the cpu bring up code.

> Ian.
>
>

Re: [ARM:PATCH v1 1/1] Add Odroid-XU (Exynos5410) support

[Ian Campbell]

On Tue, 2014-07-29 at 08:49 -0700, Suriyan Ramasami wrote:
> On Tue, Jul 29, 2014 at 12:30 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Mon, 2014-07-28 at 15:25 -0700, Suriyan Ramasami wrote:
> >> So, why is any other CPU other than CPU0 not able to read the CNTFRQ
> >> register? Is my CPU turn on code causing this issue, or is something
> >> extra needed to be done to the other CPUs in the bring up code?
> >
> > Are you sure you are writing CNTFRQ on every pCPU? This is a processor
> > local register so it needs setting everywhere, not just once.
> >
> Ah! I didn't know that. I was setting it only once on the booting CPU
> in u-boot through am smc call.

All cp registers are always local. At least I can't think of an
exception offhand.

> > You symptoms are sounding very much like it is only set on the boot CPU.
> >
> Thanks for pointing this out. I am wondering if I should go the psci
> route for the Exynos 5410 or add an smc call in the cpu bring up code.

PSCI would certainly be preferable if it is available for your platform.

A basic PSCI framework got added to u-boot mainline just this week, if
that is helpful.

Ian.

Re: [ARM:PATCH v1 1/1] Add Odroid-XU (Exynos5410) support

[Suriyan Ramasami]

On Tue, Jul 29, 2014 at 10:36 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2014-07-29 at 08:49 -0700, Suriyan Ramasami wrote:
>> On Tue, Jul 29, 2014 at 12:30 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Mon, 2014-07-28 at 15:25 -0700, Suriyan Ramasami wrote:
>> >> So, why is any other CPU other than CPU0 not able to read the CNTFRQ
>> >> register? Is my CPU turn on code causing this issue, or is something
>> >> extra needed to be done to the other CPUs in the bring up code?
>> >
>> > Are you sure you are writing CNTFRQ on every pCPU? This is a processor
>> > local register so it needs setting everywhere, not just once.
>> >
>> Ah! I didn't know that. I was setting it only once on the booting CPU
>> in u-boot through am smc call.
>
> All cp registers are always local. At least I can't think of an
> exception offhand.

I have finally gotten to set CNTFRQ on all the CPUs. I shall now work
on version 3 of the patch.

>> > You symptoms are sounding very much like it is only set on the boot CPU.
>> >
>> Thanks for pointing this out. I am wondering if I should go the psci
>> route for the Exynos 5410 or add an smc call in the cpu bring up code.
>
> PSCI would certainly be preferable if it is available for your platform.
>
> A basic PSCI framework got added to u-boot mainline just this week, if
> that is helpful.
>
Thanks, I shall check it out.
- Suriyan

> Ian.
>