All of lore.kernel.org
 help / color / mirror / Atom feed
* [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410)
@ 2014-09-04 22:57 Suriyan Ramasami
  2014-09-08 10:20 ` Ian Campbell
                   ` (2 more replies)
  0 siblings, 3 replies; 23+ messages in thread
From: Suriyan Ramasami @ 2014-09-04 22:57 UTC (permalink / raw)
  To: xen-devel
  Cc: keir, ian.campbell, Suriyan Ramasami, tim, jbeulich, ian.jackson,
	julien.grall

    XEN/ARM: Add support for the Odroid-XU board.

    The Odroid-XU from hardkernel is an Exynos 5410 based board.
    This patch adds support to the above said board.

Signed-off-by: Suriyan Ramasami <suriyan.r@gmail.com>
---

Changes between versions as follows:
   v6:
       a. Folded all *_smp_init() functions into exynos5_smp_init()
          Arndale now shall use exynos5_smp_init() as well getting rid
          of S5P_PA_SYSRAM
   v5:
       a. Get MCT base address from DT.
       b. Create function exynos5_get_pmu_base_addr() so it can be
          used by exynos5_reset() and exynos5_cpu_up() functions.

   v4:
       a. Lots of Xen coding style changes.
       b. Directly assign cpu_up_send_sgi for 5250.
       c. S5P_PA_SYSRAM renamed to EXYNOS5250_PA_SYSRAM so it is clear
          that newer platforms should use the device tree for information.
       d. Use __raw_readl and _raw_writel instead of readl and writel
       e. Leave function names consistent with what Linux uses so that it
          avoids confusion and is easier to backport in the future.
       f. Remove "samsung,exynos5422-pmu" as no such thing exists.
       g. Use XENLOG_DEBUG instead of XENLOG_INFO for power_base_address.
       h. iounmap(power) in the failure case.
       i. As its generic, call the new platform exynos5.
   v3:
       a. Separate commit message and change log.
       b. Define odroid-xu as a separate platform API.
       c. Use mainline linux's way of retrieving sysram from DT.
       d. Use mainline linux's way of bringing up secondary CPUs.
       e. Keep the #defines in the local C file.
       f. Bringing up newer Exynos platforms should be easier.

   v2:
       a. Set startup address in exynos5_smp_init() only once.
       b. Turn on power to each core in exynos5_cpu_up().
       c. Create single PLATFORM with smp_init, and cpu_up  which dispatches
          to correct code.
       d. Check return code of io_remap for power.
       e. Use read* write* calls for MMIO mapped addresses.
       f. Xen coding style changes.

    v1: Add Odroid-XU board support

---
 xen/arch/arm/platforms/exynos5.c        | 197 +++++++++++++++++++++++++++++---
 xen/include/asm-arm/platforms/exynos5.h |   3 -
 2 files changed, 184 insertions(+), 16 deletions(-)

diff --git a/xen/arch/arm/platforms/exynos5.c b/xen/arch/arm/platforms/exynos5.c
index b65c2c2..f3cbfce 100644
--- a/xen/arch/arm/platforms/exynos5.c
+++ b/xen/arch/arm/platforms/exynos5.c
@@ -23,18 +23,45 @@
 #include <xen/domain_page.h>
 #include <xen/mm.h>
 #include <xen/vmap.h>
+#include <xen/delay.h>
 #include <asm/platforms/exynos5.h>
 #include <asm/platform.h>
 #include <asm/io.h>
 
+#define EXYNOS_ARM_CORE0_CONFIG     0x2000
+#define EXYNOS_ARM_CORE_CONFIG(_nr) (0x80 * (_nr))
+#define EXYNOS_ARM_CORE_STATUS(_nr) (EXYNOS_ARM_CORE_CONFIG(_nr) + 0x4)
+#define S5P_CORE_LOCAL_PWR_EN       0x3
+
 static int exynos5_init_time(void)
 {
     uint32_t reg;
     void __iomem *mct;
+    int rc;
+    struct dt_device_node *node;
+    u64 mct_base_addr;
+    u64 size;
 
     BUILD_BUG_ON(EXYNOS5_MCT_G_TCON >= PAGE_SIZE);
 
-    mct = ioremap_attr(EXYNOS5_MCT_BASE, PAGE_SIZE, PAGE_HYPERVISOR_NOCACHE);
+    node = dt_find_compatible_node(NULL, NULL, "samsung,exynos4210-mct");
+    if ( !node )
+    {
+        dprintk(XENLOG_ERR, "samsung,exynos4210-mct missing in DT\n");
+        return -ENXIO;
+    }
+
+    rc = dt_device_get_address(node, 0, &mct_base_addr, &size);
+    if ( rc )
+    {
+        dprintk(XENLOG_ERR, "Error in \"samsung,exynos4210-mct\"\n");
+        return -ENXIO;
+    }
+
+    dprintk(XENLOG_INFO, "mct_base_addr: %016llx size: %016llx\n",
+            mct_base_addr, size);
+
+    mct = ioremap_attr(mct_base_addr, PAGE_SIZE, PAGE_HYPERVISOR_NOCACHE);
     if ( !mct )
     {
         dprintk(XENLOG_ERR, "Unable to map MCT\n");
@@ -51,7 +78,7 @@ static int exynos5_init_time(void)
 }
 
 /* Additional mappings for dom0 (Not in the DTS) */
-static int exynos5_specific_mapping(struct domain *d)
+static int exynos5250_specific_mapping(struct domain *d)
 {
     /* Map the chip ID */
     map_mmio_regions(d, paddr_to_pfn(EXYNOS5_PA_CHIPID), 1,
@@ -67,8 +94,29 @@ static int exynos5_specific_mapping(struct domain *d)
 static int __init exynos5_smp_init(void)
 {
     void __iomem *sysram;
+    struct dt_device_node *node;
+    u64 sysram_ns_base_addr;
+    u64 size;
+    int rc;
+
+    node = dt_find_compatible_node(NULL, NULL, "samsung,exynos4210-sysram-ns");
+    if ( !node )
+    {
+        dprintk(XENLOG_ERR, "samsung,exynos4210-sysram-ns missing in DT\n");
+        return -ENXIO;
+    }
 
-    sysram = ioremap_nocache(S5P_PA_SYSRAM, PAGE_SIZE);
+    rc = dt_device_get_address(node, 0, &sysram_ns_base_addr, &size);
+    if ( rc )
+    {
+        dprintk(XENLOG_ERR, "Error in \"samsung,exynos4210-sysram-ns\"\n");
+        return -ENXIO;
+    }
+
+    dprintk(XENLOG_INFO, "sysram_ns_base_addr: %016llx size: %016llx\n",
+            sysram_ns_base_addr, size);
+
+    sysram = ioremap_nocache(sysram_ns_base_addr, PAGE_SIZE);
     if ( !sysram )
     {
         dprintk(XENLOG_ERR, "Unable to map exynos5 MMIO\n");
@@ -77,20 +125,127 @@ static int __init exynos5_smp_init(void)
 
     printk("Set SYSRAM to %"PRIpaddr" (%p)\n",
            __pa(init_secondary), init_secondary);
-    writel(__pa(init_secondary), sysram);
+    writel(__pa(init_secondary), sysram + 0x1c);
 
     iounmap(sysram);
 
     return 0;
 }
 
+static int exynos_cpu_power_state(void __iomem *power, int cpu)
+{
+    return __raw_readl(power + EXYNOS_ARM_CORE_STATUS(cpu)) &
+                       S5P_CORE_LOCAL_PWR_EN;
+}
+
+static void exynos_cpu_power_up(void __iomem *power, int cpu)
+{
+    __raw_writel(S5P_CORE_LOCAL_PWR_EN,
+                 power + EXYNOS_ARM_CORE_CONFIG(cpu));
+}
+
+static int exynos5_cpu_power_up(void __iomem *power, int cpu)
+{
+    unsigned int timeout;
+
+    if ( !exynos_cpu_power_state(power, cpu) )
+    {
+        exynos_cpu_power_up(power, cpu);
+        timeout = 10;
+
+        /* wait max 10 ms until cpu is on */
+        while ( exynos_cpu_power_state(power, cpu) != S5P_CORE_LOCAL_PWR_EN )
+        {
+            if ( timeout-- == 0 )
+                break;
+
+            mdelay(1);
+        }
+
+        if ( timeout == 0 )
+        {
+            dprintk(XENLOG_ERR, "CPU%d power enable failed", cpu);
+            return -ETIMEDOUT;
+        }
+    }
+    return 0;
+}
+
+static int exynos5_get_pmu_base_addr(u64 *power_base_addr) {
+    u64 size;
+    struct dt_device_node *node;
+    int rc;
+    static const struct dt_device_match exynos_dt_pmu_matches[] __initconst =
+    {
+        DT_MATCH_COMPATIBLE("samsung,exynos5250-pmu"),
+        DT_MATCH_COMPATIBLE("samsung,exynos5410-pmu"),
+        DT_MATCH_COMPATIBLE("samsung,exynos5420-pmu"),
+        { /*sentinel*/ },
+    };
+
+    node = dt_find_matching_node(NULL, exynos_dt_pmu_matches);
+    if ( !node )
+    {
+        dprintk(XENLOG_ERR, "samsung,exynos5XXX-pmu missing in DT\n");
+        return -ENXIO;
+    }
+
+    rc = dt_device_get_address(node, 0, power_base_addr, &size);
+    if ( rc )
+    {
+        dprintk(XENLOG_ERR, "Error in \"samsung,exynos5XXXX-pmu\"\n");
+        return -ENXIO;
+    }
+
+    dprintk(XENLOG_DEBUG, "power_base_addr: %016llx size: %016llx\n",
+            *power_base_addr, size);
+
+    return 0;
+}
+
+static int exynos5_cpu_up(int cpu)
+{
+    u64 power_base_addr;
+    void __iomem *power;
+    int rc;
+
+    rc = exynos5_get_pmu_base_addr(&power_base_addr);
+    if ( rc )
+        return rc;
+
+    power = ioremap_nocache(power_base_addr +
+                            EXYNOS_ARM_CORE0_CONFIG, PAGE_SIZE);
+    if ( !power )
+    {
+        dprintk(XENLOG_ERR, "Unable to map power MMIO\n");
+        return -EFAULT;
+    }
+
+    rc = exynos5_cpu_power_up(power, cpu);
+    if ( rc )
+    {
+        iounmap(power);
+        return -ETIMEDOUT;
+    }
+
+    iounmap(power);
+
+    return cpu_up_send_sgi(cpu);
+}
+
 static void exynos5_reset(void)
 {
+    u64 power_base_addr;
     void __iomem *pmu;
+    int rc;
 
     BUILD_BUG_ON(EXYNOS5_SWRESET >= PAGE_SIZE);
 
-    pmu = ioremap_nocache(EXYNOS5_PA_PMU, PAGE_SIZE);
+    rc = exynos5_get_pmu_base_addr(&power_base_addr);
+    if ( rc )
+        return;
+
+    pmu = ioremap_nocache(power_base_addr, PAGE_SIZE);
     if ( !pmu )
     {
         dprintk(XENLOG_ERR, "Unable to map PMU\n");
@@ -98,15 +253,10 @@ static void exynos5_reset(void)
     }
 
     writel(1, pmu + EXYNOS5_SWRESET);
+
     iounmap(pmu);
 }
 
-static const char * const exynos5_dt_compat[] __initconst =
-{
-    "samsung,exynos5250",
-    NULL
-};
-
 static const struct dt_device_match exynos5_blacklist_dev[] __initconst =
 {
     /* Multi core Timer
@@ -117,12 +267,33 @@ static const struct dt_device_match exynos5_blacklist_dev[] __initconst =
     { /* sentinel */ },
 };
 
+static const char * const exynos5250_dt_compat[] __initconst =
+{
+    "samsung,exynos5250",
+    NULL
+};
+
+static const char * const exynos5_dt_compat[] __initconst =
+{
+    "samsung,exynos5410",
+    NULL
+};
+
+PLATFORM_START(exynos5250, "SAMSUNG EXYNOS5250")
+    .compatible = exynos5250_dt_compat,
+    .init_time = exynos5_init_time,
+    .specific_mapping = exynos5250_specific_mapping,
+    .smp_init = exynos5_smp_init,
+    .cpu_up = cpu_up_send_sgi,
+    .reset = exynos5_reset,
+    .blacklist_dev = exynos5_blacklist_dev,
+PLATFORM_END
+
 PLATFORM_START(exynos5, "SAMSUNG EXYNOS5")
     .compatible = exynos5_dt_compat,
     .init_time = exynos5_init_time,
-    .specific_mapping = exynos5_specific_mapping,
     .smp_init = exynos5_smp_init,
-    .cpu_up = cpu_up_send_sgi,
+    .cpu_up = exynos5_cpu_up,
     .reset = exynos5_reset,
     .blacklist_dev = exynos5_blacklist_dev,
 PLATFORM_END
diff --git a/xen/include/asm-arm/platforms/exynos5.h b/xen/include/asm-arm/platforms/exynos5.h
index ea941e7..c88455a 100644
--- a/xen/include/asm-arm/platforms/exynos5.h
+++ b/xen/include/asm-arm/platforms/exynos5.h
@@ -1,7 +1,6 @@
 #ifndef __ASM_ARM_PLATFORMS_EXYNOS5_H
 #define __ASM_ARM_PLATFORMS_EXYNOS5_H
 
-#define EXYNOS5_MCT_BASE            0x101c0000
 #define EXYNOS5_MCT_G_TCON          0x240       /* Relative to MCT_BASE */
 #define EXYNOS5_MCT_G_TCON_START    (1 << 8)
 
@@ -12,8 +11,6 @@
 
 #define EXYNOS5_SWRESET             0x0400      /* Relative to PA_PMU */
 
-#define S5P_PA_SYSRAM   0x02020000
-
 #endif /* __ASM_ARM_PLATFORMS_EXYNOS5_H */
 /*
  * Local variables:
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 23+ messages in thread

* Re: [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410)
  2014-09-04 22:57 [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410) Suriyan Ramasami
@ 2014-09-08 10:20 ` Ian Campbell
  2014-09-08 17:26   ` Suriyan Ramasami
  2014-09-10 14:07 ` Ian Campbell
  2014-09-10 21:08 ` Julien Grall
  2 siblings, 1 reply; 23+ messages in thread
From: Ian Campbell @ 2014-09-08 10:20 UTC (permalink / raw)
  To: Suriyan Ramasami
  Cc: keir, tim, xen-devel, jbeulich, ian.jackson, julien.grall

On Thu, 2014-09-04 at 15:57 -0700, Suriyan Ramasami wrote:
>     XEN/ARM: Add support for the Odroid-XU board.
> 
>     The Odroid-XU from hardkernel is an Exynos 5410 based board.
>     This patch adds support to the above said board.

Please could you describe a bit more fully the refactoring you've done
and the new platform you've introduced. e.g. that we now have a general
exynos5 (which currently includes only the 4210) and that the previous
5250 is a separate platform because of A, B, and C which differ from the
generic.

Assuming there are no other changes to the patch please feel free to
just reply here with the updated commit text and I'll fold it in as I
commit.

> @@ -77,20 +125,127 @@ static int __init exynos5_smp_init(void)
>  
>      printk("Set SYSRAM to %"PRIpaddr" (%p)\n",
>             __pa(init_secondary), init_secondary);
> -    writel(__pa(init_secondary), sysram);
> +    writel(__pa(init_secondary), sysram + 0x1c);

I think this 01c offset is new, where does it come from? Was the old
code wrong (again, if this just needs a few words in the commit log I
can fold them in as I commit).

> +    static const struct dt_device_match exynos_dt_pmu_matches[] __initconst =
> +    {
> +        DT_MATCH_COMPATIBLE("samsung,exynos5250-pmu"),
> +        DT_MATCH_COMPATIBLE("samsung,exynos5410-pmu"),
> +        DT_MATCH_COMPATIBLE("samsung,exynos5420-pmu"),

I suppose these are all similar enough for our purposes?

> +        { /*sentinel*/ },
> +    };
> +
> +    node = dt_find_matching_node(NULL, exynos_dt_pmu_matches);
> +    if ( !node )
> +    {
> +        dprintk(XENLOG_ERR, "samsung,exynos5XXX-pmu missing in DT\n");

We have some 4XXX in the list too. Make it exynosXXXX? (likewise the
next message which was below but I've trimmed it by mistake).

Ian.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410)
  2014-09-08 10:20 ` Ian Campbell
@ 2014-09-08 17:26   ` Suriyan Ramasami
  2014-09-09  9:15     ` Ian Campbell
  2014-09-10 22:21     ` Julien Grall
  0 siblings, 2 replies; 23+ messages in thread
From: Suriyan Ramasami @ 2014-09-08 17:26 UTC (permalink / raw)
  To: Ian Campbell
  Cc: keir, Tim Deegan, xen-devel, Jan Beulich, ian.jackson, Julien Grall

On Mon, Sep 8, 2014 at 3:20 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2014-09-04 at 15:57 -0700, Suriyan Ramasami wrote:
>>     XEN/ARM: Add support for the Odroid-XU board.
>>
>>     The Odroid-XU from hardkernel is an Exynos 5410 based board.
>>     This patch adds support to the above said board.
>
> Please could you describe a bit more fully the refactoring you've done
> and the new platform you've introduced. e.g. that we now have a general
> exynos5 (which currently includes only the 4210) and that the previous
> 5250 is a separate platform because of A, B, and C which differ from the
> generic.
>
> Assuming there are no other changes to the patch please feel free to
> just reply here with the updated commit text and I'll fold it in as I
> commit.
>
OK, and here it is ...

    Introduced a generic PLATFORM exynos5 which hopefully is
applicable to the majority of  exynos5 based SoCs. It currently has
only been tested on an exynos5410 based (OdroidXU) board and hence
that is the only board listed.

    Previously only the Arndale board, based on an exynos5250 was
supported. It was the only exynos based platform that was supported
and it was called exynos5. It has now been renamed to exynos5250. The
Arndale currently is a separate platform mostly cause I do not have
one to test and for the most part the code path for that board is
preserved. To be specific it varies from the generic implementation as
follows:
1. exynos5250 based specific DT mapping for CHIPID and PWM region. I
believe mainline kernel's DTS for the arndale has those mappings
already in place.
2. exynos5250 based cpu up code. It appears that exynos5250 already
has the secondary core powered up and in wfe and hence a
cpu_up_send_sgi suffices. Here too, I believe that the generic code
path might be acceptable.

Most of the code for the cpu bring up has been ported over from
mainline linux, and hence should be generic enough for future exynos
based SoCs. All reference to hardcoded memory locations have been
avoided. They are now gleaned from the device tree.

>> @@ -77,20 +125,127 @@ static int __init exynos5_smp_init(void)
>>
>>      printk("Set SYSRAM to %"PRIpaddr" (%p)\n",
>>             __pa(init_secondary), init_secondary);
>> -    writel(__pa(init_secondary), sysram);
>> +    writel(__pa(init_secondary), sysram + 0x1c);
>
> I think this 01c offset is new, where does it come from? Was the old
> code wrong (again, if this just needs a few words in the commit log I
> can fold them in as I commit).
>
This 0x1c comes from the Non Secure memory area that u-boot SPL moves
its code into. I believe this is the same for all exynos's (i believe
they have this same code pattern in lowlevel_init.S. This is what
u-boot copies over to start of IRAM_NS_BASE:
nscode_base:
        b       1f
        nop                             @ for backward compatibility

        .word   0x0                     @ REG0: RESUME_ADDR
        .word   0x0                     @ REG1: RESUME_FLAG
        .word   0x0                     @ REG2
        .word   0x0                     @ REG3
_switch_addr:
        .word   0x0                     @ REG4: SWITCH_ADDR
_hotplug_addr:
<------------------------------------------------------------- +0x1c
        .word   0x0                     @ REG5: CPU1_BOOT_REG
...
1: -> blah blah
        HYP entry ... blah blah

        adr     r0, _hotplug_addr
wait_for_addr:
        ldr     r1, [r0]
        cmp     r1, #0x0
        bxne    r1
        wfe
        b       wait_for_addr
...

As can be seen, the secondary CPUs check _hotplug_addr for a non zero
value on first being powered on, or after woken up from a wfe. This
_hotplug_addr happens to be at offset +0x1c from NS_RAM_BASE.
Linux mainline too has this hardcoded +0x1c.

>> +    static const struct dt_device_match exynos_dt_pmu_matches[] __initconst =
>> +    {
>> +        DT_MATCH_COMPATIBLE("samsung,exynos5250-pmu"),
>> +        DT_MATCH_COMPATIBLE("samsung,exynos5410-pmu"),
>> +        DT_MATCH_COMPATIBLE("samsung,exynos5420-pmu"),
>
> I suppose these are all similar enough for our purposes?
>
Yes, I could have just left it with the exynos5410-pmu and the
exynos5250-pmu, but then gathered the other compatible ones which
could be used for exynos5 generic boards in the future.

>> +        { /*sentinel*/ },
>> +    };
>> +
>> +    node = dt_find_matching_node(NULL, exynos_dt_pmu_matches);
>> +    if ( !node )
>> +    {
>> +        dprintk(XENLOG_ERR, "samsung,exynos5XXX-pmu missing in DT\n");
>
> We have some 4XXX in the list too. Make it exynosXXXX? (likewise the
> next message which was below but I've trimmed it by mistake).
>
I do not see any 4XXX in the pmu list that I have added. I think you
are referring the sysram compatible string which has exynos4 stuff in
it. And those dprintk the right string.

Same comment for the next message, but I see a typo where I have an
extra X in the exynos5XXXX instead of exynos5XXX

Please let me know if I should roll another patch with these comments
and the minor 'X' change.

Thanks!
> Ian.
>

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410)
  2014-09-08 17:26   ` Suriyan Ramasami
@ 2014-09-09  9:15     ` Ian Campbell
  2014-09-09 15:34       ` Suriyan Ramasami
  2014-09-10 22:21     ` Julien Grall
  1 sibling, 1 reply; 23+ messages in thread
From: Ian Campbell @ 2014-09-09  9:15 UTC (permalink / raw)
  To: Suriyan Ramasami
  Cc: keir, Tim Deegan, xen-devel, Jan Beulich, ian.jackson, Julien Grall

On Mon, 2014-09-08 at 10:26 -0700, Suriyan Ramasami wrote:
> On Mon, Sep 8, 2014 at 3:20 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2014-09-04 at 15:57 -0700, Suriyan Ramasami wrote:
> >>     XEN/ARM: Add support for the Odroid-XU board.
> >>
> >>     The Odroid-XU from hardkernel is an Exynos 5410 based board.
> >>     This patch adds support to the above said board.
> >
> > Please could you describe a bit more fully the refactoring you've done
> > and the new platform you've introduced. e.g. that we now have a general
> > exynos5 (which currently includes only the 4210) and that the previous
> > 5250 is a separate platform because of A, B, and C which differ from the
> > generic.
> >
> > Assuming there are no other changes to the patch please feel free to
> > just reply here with the updated commit text and I'll fold it in as I
> > commit.
> >
> OK, and here it is ...

[...]
Thanks.

> >> @@ -77,20 +125,127 @@ static int __init exynos5_smp_init(void)
> >>
> >>      printk("Set SYSRAM to %"PRIpaddr" (%p)\n",
> >>             __pa(init_secondary), init_secondary);
> >> -    writel(__pa(init_secondary), sysram);
> >> +    writel(__pa(init_secondary), sysram + 0x1c);
> >
> > I think this 01c offset is new, where does it come from? Was the old
> > code wrong (again, if this just needs a few words in the commit log I
> > can fold them in as I commit).
> >
> This 0x1c comes from the Non Secure memory area that u-boot SPL moves
> its code into. I believe this is the same for all exynos's (i believe
> they have this same code pattern in lowlevel_init.S. This is what
> u-boot copies over to start of IRAM_NS_BASE:
> [...]
> As can be seen, the secondary CPUs check _hotplug_addr for a non zero
> value on first being powered on, or after woken up from a wfe. This
> _hotplug_addr happens to be at offset +0x1c from NS_RAM_BASE.
> Linux mainline too has this hardcoded +0x1c.

So this is basically another difference between booting in S mode and NS
mode, which wasn't accounted for when we removed the
kicking/transitioning code from Xen's head.S?

I'm inclined to add something like this to the commit log:

        The existing SMP bringup code has been broken since 4557c2292854
        "xen: arm: rewrite start of day page table and cpu bring up"
        which moved the arndale CPU kick from secure world to non-secure
        world without updating it to match the new environment.
        Specifically the sysram address remained hardcoded to the S
        sysram address and not the NS sysram address, this is now
        correctly taken from DT. Secondly the offset within the sysram
        where the start address is written is 0x1c for NS bringup,
        rather than 0x0 as it is in S bringup.

Does that sound correct?

> >> +        { /*sentinel*/ },
> >> +    };
> >> +
> >> +    node = dt_find_matching_node(NULL, exynos_dt_pmu_matches);
> >> +    if ( !node )
> >> +    {
> >> +        dprintk(XENLOG_ERR, "samsung,exynos5XXX-pmu missing in DT\n");
> >
> > We have some 4XXX in the list too. Make it exynosXXXX? (likewise the
> > next message which was below but I've trimmed it by mistake).
> >
> I do not see any 4XXX in the pmu list that I have added.

I was being dumb and read exynos54xx as exynos4xxx, sorry.

> Please let me know if I should roll another patch with these comments
> and the minor 'X' change.

If you are happy with my proposed changelog additions then I can drop
the extra X and update the changelog as I commit, no need to resend.

Ian.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410)
  2014-09-09  9:15     ` Ian Campbell
@ 2014-09-09 15:34       ` Suriyan Ramasami
  0 siblings, 0 replies; 23+ messages in thread
From: Suriyan Ramasami @ 2014-09-09 15:34 UTC (permalink / raw)
  To: Ian Campbell
  Cc: keir, Tim Deegan, xen-devel, Jan Beulich, ian.jackson, Julien Grall

On Tue, Sep 9, 2014 at 2:15 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2014-09-08 at 10:26 -0700, Suriyan Ramasami wrote:
>> On Mon, Sep 8, 2014 at 3:20 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Thu, 2014-09-04 at 15:57 -0700, Suriyan Ramasami wrote:
>> >>     XEN/ARM: Add support for the Odroid-XU board.
>> >>
>> >>     The Odroid-XU from hardkernel is an Exynos 5410 based board.
>> >>     This patch adds support to the above said board.
>> >
>> > Please could you describe a bit more fully the refactoring you've done
>> > and the new platform you've introduced. e.g. that we now have a general
>> > exynos5 (which currently includes only the 4210) and that the previous
>> > 5250 is a separate platform because of A, B, and C which differ from the
>> > generic.
>> >
>> > Assuming there are no other changes to the patch please feel free to
>> > just reply here with the updated commit text and I'll fold it in as I
>> > commit.
>> >
>> OK, and here it is ...
>
> [...]
> Thanks.
>
>> >> @@ -77,20 +125,127 @@ static int __init exynos5_smp_init(void)
>> >>
>> >>      printk("Set SYSRAM to %"PRIpaddr" (%p)\n",
>> >>             __pa(init_secondary), init_secondary);
>> >> -    writel(__pa(init_secondary), sysram);
>> >> +    writel(__pa(init_secondary), sysram + 0x1c);
>> >
>> > I think this 01c offset is new, where does it come from? Was the old
>> > code wrong (again, if this just needs a few words in the commit log I
>> > can fold them in as I commit).
>> >
>> This 0x1c comes from the Non Secure memory area that u-boot SPL moves
>> its code into. I believe this is the same for all exynos's (i believe
>> they have this same code pattern in lowlevel_init.S. This is what
>> u-boot copies over to start of IRAM_NS_BASE:
>> [...]
>> As can be seen, the secondary CPUs check _hotplug_addr for a non zero
>> value on first being powered on, or after woken up from a wfe. This
>> _hotplug_addr happens to be at offset +0x1c from NS_RAM_BASE.
>> Linux mainline too has this hardcoded +0x1c.
>
> So this is basically another difference between booting in S mode and NS
> mode, which wasn't accounted for when we removed the
> kicking/transitioning code from Xen's head.S?
>
> I'm inclined to add something like this to the commit log:
>
>         The existing SMP bringup code has been broken since 4557c2292854
>         "xen: arm: rewrite start of day page table and cpu bring up"
>         which moved the arndale CPU kick from secure world to non-secure
>         world without updating it to match the new environment.
>         Specifically the sysram address remained hardcoded to the S
>         sysram address and not the NS sysram address, this is now
>         correctly taken from DT. Secondly the offset within the sysram
>         where the start address is written is 0x1c for NS bringup,
>         rather than 0x0 as it is in S bringup.
>
> Does that sound correct?
>
Sounds good to me!

>> >> +        { /*sentinel*/ },
>> >> +    };
>> >> +
>> >> +    node = dt_find_matching_node(NULL, exynos_dt_pmu_matches);
>> >> +    if ( !node )
>> >> +    {
>> >> +        dprintk(XENLOG_ERR, "samsung,exynos5XXX-pmu missing in DT\n");
>> >
>> > We have some 4XXX in the list too. Make it exynosXXXX? (likewise the
>> > next message which was below but I've trimmed it by mistake).
>> >
>> I do not see any 4XXX in the pmu list that I have added.
>
> I was being dumb and read exynos54xx as exynos4xxx, sorry.
>
>> Please let me know if I should roll another patch with these comments
>> and the minor 'X' change.
>
> If you are happy with my proposed changelog additions then I can drop
> the extra X and update the changelog as I commit, no need to resend.
>
That should be wonderful! Thank you so much, Ian.
> Ian.
>

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410)
  2014-09-04 22:57 [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410) Suriyan Ramasami
  2014-09-08 10:20 ` Ian Campbell
@ 2014-09-10 14:07 ` Ian Campbell
  2014-09-10 17:05   ` Suriyan Ramasami
  2014-09-10 21:08 ` Julien Grall
  2 siblings, 1 reply; 23+ messages in thread
From: Ian Campbell @ 2014-09-10 14:07 UTC (permalink / raw)
  To: Suriyan Ramasami
  Cc: keir, tim, xen-devel, jbeulich, ian.jackson, julien.grall

On Thu, 2014-09-04 at 15:57 -0700, Suriyan Ramasami wrote:

>      BUILD_BUG_ON(EXYNOS5_MCT_G_TCON >= PAGE_SIZE);
>  
> -    mct = ioremap_attr(EXYNOS5_MCT_BASE, PAGE_SIZE, PAGE_HYPERVISOR_NOCACHE);
> +    node = dt_find_compatible_node(NULL, NULL, "samsung,exynos4210-mct");
> +    if ( !node )
> +    {
> +        dprintk(XENLOG_ERR, "samsung,exynos4210-mct missing in DT\n");
> +        return -ENXIO;
> +    }
> +
> +    rc = dt_device_get_address(node, 0, &mct_base_addr, &size);
> +    if ( rc )
> +    {
> +        dprintk(XENLOG_ERR, "Error in \"samsung,exynos4210-mct\"\n");
> +        return -ENXIO;
> +    }
> +
> +    dprintk(XENLOG_INFO, "mct_base_addr: %016llx size: %016llx\n",
> +            mct_base_addr, size);
> +
> +    mct = ioremap_attr(mct_base_addr, PAGE_SIZE, PAGE_HYPERVISOR_NOCACHE);

I noticed this while applying, it wasn't enough to stop me but it would
be nice to fix:

We should drop that BUILD_BUG_ON and use the size retrieved from the DT
for the mapping instead.

Ian.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410)
  2014-09-10 14:07 ` Ian Campbell
@ 2014-09-10 17:05   ` Suriyan Ramasami
  2014-09-11  9:03     ` Ian Campbell
  0 siblings, 1 reply; 23+ messages in thread
From: Suriyan Ramasami @ 2014-09-10 17:05 UTC (permalink / raw)
  To: Ian Campbell
  Cc: keir, Tim Deegan, xen-devel, Jan Beulich, ian.jackson, Julien Grall

On Wed, Sep 10, 2014 at 7:07 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2014-09-04 at 15:57 -0700, Suriyan Ramasami wrote:
>
>>      BUILD_BUG_ON(EXYNOS5_MCT_G_TCON >= PAGE_SIZE);
>>
>> -    mct = ioremap_attr(EXYNOS5_MCT_BASE, PAGE_SIZE, PAGE_HYPERVISOR_NOCACHE);
>> +    node = dt_find_compatible_node(NULL, NULL, "samsung,exynos4210-mct");
>> +    if ( !node )
>> +    {
>> +        dprintk(XENLOG_ERR, "samsung,exynos4210-mct missing in DT\n");
>> +        return -ENXIO;
>> +    }
>> +
>> +    rc = dt_device_get_address(node, 0, &mct_base_addr, &size);
>> +    if ( rc )
>> +    {
>> +        dprintk(XENLOG_ERR, "Error in \"samsung,exynos4210-mct\"\n");
>> +        return -ENXIO;
>> +    }
>> +
>> +    dprintk(XENLOG_INFO, "mct_base_addr: %016llx size: %016llx\n",
>> +            mct_base_addr, size);
>> +
>> +    mct = ioremap_attr(mct_base_addr, PAGE_SIZE, PAGE_HYPERVISOR_NOCACHE);
>
> I noticed this while applying, it wasn't enough to stop me but it would
> be nice to fix:
>
> We should drop that BUILD_BUG_ON and use the size retrieved from the DT
> for the mapping instead.
>
This did occur to me, more so when mapping the power base address (as
I map from an offset rather than base so that I am within the
PAGE_SIZE that I map). From what you are suggesting, we should just
map the base address (mct or pmu) for the size that we retrieve. I see
that the mct is of size 0x800 and the pmu is of size 0x5000.
We can then add a check to see if the offsets that we are cooking up,
like EXYNOS5_MCT_G_TCON are within size that we have retrieved.
I hope this is what you were suggesting. Please let me know, and I
shall send a patch for this.
Thanks!
- Suriyan

> Ian.
>

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410)
  2014-09-04 22:57 [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410) Suriyan Ramasami
  2014-09-08 10:20 ` Ian Campbell
  2014-09-10 14:07 ` Ian Campbell
@ 2014-09-10 21:08 ` Julien Grall
  2014-09-11  8:53   ` Ian Campbell
  2 siblings, 1 reply; 23+ messages in thread
From: Julien Grall @ 2014-09-10 21:08 UTC (permalink / raw)
  To: Suriyan Ramasami, xen-devel, ian.campbell
  Cc: ian.jackson, julien.grall, keir, jbeulich, tim

Hi all,

This patch breaks Xen boot on the Arndale.

It would have been nice to test this patch on the Arndale before pushing 
it on master... I was unable to do it because I was away.

I would prefer to keep a separate smp_init function with hardcoded value 
as long as someone as time to check if we can effectively use the new value.

Regards,

On 04/09/14 15:57, Suriyan Ramasami wrote:
>      XEN/ARM: Add support for the Odroid-XU board.
>
>      The Odroid-XU from hardkernel is an Exynos 5410 based board.
>      This patch adds support to the above said board.
>
> Signed-off-by: Suriyan Ramasami <suriyan.r@gmail.com>
> ---
>
> Changes between versions as follows:
>     v6:
>         a. Folded all *_smp_init() functions into exynos5_smp_init()
>            Arndale now shall use exynos5_smp_init() as well getting rid
>            of S5P_PA_SYSRAM
>     v5:
>         a. Get MCT base address from DT.
>         b. Create function exynos5_get_pmu_base_addr() so it can be
>            used by exynos5_reset() and exynos5_cpu_up() functions.
>
>     v4:
>         a. Lots of Xen coding style changes.
>         b. Directly assign cpu_up_send_sgi for 5250.
>         c. S5P_PA_SYSRAM renamed to EXYNOS5250_PA_SYSRAM so it is clear
>            that newer platforms should use the device tree for information.
>         d. Use __raw_readl and _raw_writel instead of readl and writel
>         e. Leave function names consistent with what Linux uses so that it
>            avoids confusion and is easier to backport in the future.
>         f. Remove "samsung,exynos5422-pmu" as no such thing exists.
>         g. Use XENLOG_DEBUG instead of XENLOG_INFO for power_base_address.
>         h. iounmap(power) in the failure case.
>         i. As its generic, call the new platform exynos5.
>     v3:
>         a. Separate commit message and change log.
>         b. Define odroid-xu as a separate platform API.
>         c. Use mainline linux's way of retrieving sysram from DT.
>         d. Use mainline linux's way of bringing up secondary CPUs.
>         e. Keep the #defines in the local C file.
>         f. Bringing up newer Exynos platforms should be easier.
>
>     v2:
>         a. Set startup address in exynos5_smp_init() only once.
>         b. Turn on power to each core in exynos5_cpu_up().
>         c. Create single PLATFORM with smp_init, and cpu_up  which dispatches
>            to correct code.
>         d. Check return code of io_remap for power.
>         e. Use read* write* calls for MMIO mapped addresses.
>         f. Xen coding style changes.
>
>      v1: Add Odroid-XU board support
>
> ---
>   xen/arch/arm/platforms/exynos5.c        | 197 +++++++++++++++++++++++++++++---
>   xen/include/asm-arm/platforms/exynos5.h |   3 -
>   2 files changed, 184 insertions(+), 16 deletions(-)
>
> diff --git a/xen/arch/arm/platforms/exynos5.c b/xen/arch/arm/platforms/exynos5.c
> index b65c2c2..f3cbfce 100644
> --- a/xen/arch/arm/platforms/exynos5.c
> +++ b/xen/arch/arm/platforms/exynos5.c
> @@ -23,18 +23,45 @@
>   #include <xen/domain_page.h>
>   #include <xen/mm.h>
>   #include <xen/vmap.h>
> +#include <xen/delay.h>
>   #include <asm/platforms/exynos5.h>
>   #include <asm/platform.h>
>   #include <asm/io.h>
>
> +#define EXYNOS_ARM_CORE0_CONFIG     0x2000
> +#define EXYNOS_ARM_CORE_CONFIG(_nr) (0x80 * (_nr))
> +#define EXYNOS_ARM_CORE_STATUS(_nr) (EXYNOS_ARM_CORE_CONFIG(_nr) + 0x4)
> +#define S5P_CORE_LOCAL_PWR_EN       0x3
> +
>   static int exynos5_init_time(void)
>   {
>       uint32_t reg;
>       void __iomem *mct;
> +    int rc;
> +    struct dt_device_node *node;
> +    u64 mct_base_addr;
> +    u64 size;
>
>       BUILD_BUG_ON(EXYNOS5_MCT_G_TCON >= PAGE_SIZE);
>
> -    mct = ioremap_attr(EXYNOS5_MCT_BASE, PAGE_SIZE, PAGE_HYPERVISOR_NOCACHE);
> +    node = dt_find_compatible_node(NULL, NULL, "samsung,exynos4210-mct");
> +    if ( !node )
> +    {
> +        dprintk(XENLOG_ERR, "samsung,exynos4210-mct missing in DT\n");
> +        return -ENXIO;
> +    }
> +
> +    rc = dt_device_get_address(node, 0, &mct_base_addr, &size);
> +    if ( rc )
> +    {
> +        dprintk(XENLOG_ERR, "Error in \"samsung,exynos4210-mct\"\n");
> +        return -ENXIO;
> +    }
> +
> +    dprintk(XENLOG_INFO, "mct_base_addr: %016llx size: %016llx\n",
> +            mct_base_addr, size);
> +
> +    mct = ioremap_attr(mct_base_addr, PAGE_SIZE, PAGE_HYPERVISOR_NOCACHE);
>       if ( !mct )
>       {
>           dprintk(XENLOG_ERR, "Unable to map MCT\n");
> @@ -51,7 +78,7 @@ static int exynos5_init_time(void)
>   }
>
>   /* Additional mappings for dom0 (Not in the DTS) */
> -static int exynos5_specific_mapping(struct domain *d)
> +static int exynos5250_specific_mapping(struct domain *d)
>   {
>       /* Map the chip ID */
>       map_mmio_regions(d, paddr_to_pfn(EXYNOS5_PA_CHIPID), 1,
> @@ -67,8 +94,29 @@ static int exynos5_specific_mapping(struct domain *d)
>   static int __init exynos5_smp_init(void)
>   {
>       void __iomem *sysram;
> +    struct dt_device_node *node;
> +    u64 sysram_ns_base_addr;
> +    u64 size;
> +    int rc;
> +
> +    node = dt_find_compatible_node(NULL, NULL, "samsung,exynos4210-sysram-ns");
> +    if ( !node )
> +    {
> +        dprintk(XENLOG_ERR, "samsung,exynos4210-sysram-ns missing in DT\n");
> +        return -ENXIO;
> +    }
>
> -    sysram = ioremap_nocache(S5P_PA_SYSRAM, PAGE_SIZE);
> +    rc = dt_device_get_address(node, 0, &sysram_ns_base_addr, &size);
> +    if ( rc )
> +    {
> +        dprintk(XENLOG_ERR, "Error in \"samsung,exynos4210-sysram-ns\"\n");
> +        return -ENXIO;
> +    }
> +
> +    dprintk(XENLOG_INFO, "sysram_ns_base_addr: %016llx size: %016llx\n",
> +            sysram_ns_base_addr, size);
> +
> +    sysram = ioremap_nocache(sysram_ns_base_addr, PAGE_SIZE);
>       if ( !sysram )
>       {
>           dprintk(XENLOG_ERR, "Unable to map exynos5 MMIO\n");
> @@ -77,20 +125,127 @@ static int __init exynos5_smp_init(void)
>
>       printk("Set SYSRAM to %"PRIpaddr" (%p)\n",
>              __pa(init_secondary), init_secondary);
> -    writel(__pa(init_secondary), sysram);
> +    writel(__pa(init_secondary), sysram + 0x1c);
>
>       iounmap(sysram);
>
>       return 0;
>   }
>
> +static int exynos_cpu_power_state(void __iomem *power, int cpu)
> +{
> +    return __raw_readl(power + EXYNOS_ARM_CORE_STATUS(cpu)) &
> +                       S5P_CORE_LOCAL_PWR_EN;
> +}
> +
> +static void exynos_cpu_power_up(void __iomem *power, int cpu)
> +{
> +    __raw_writel(S5P_CORE_LOCAL_PWR_EN,
> +                 power + EXYNOS_ARM_CORE_CONFIG(cpu));
> +}
> +
> +static int exynos5_cpu_power_up(void __iomem *power, int cpu)
> +{
> +    unsigned int timeout;
> +
> +    if ( !exynos_cpu_power_state(power, cpu) )
> +    {
> +        exynos_cpu_power_up(power, cpu);
> +        timeout = 10;
> +
> +        /* wait max 10 ms until cpu is on */
> +        while ( exynos_cpu_power_state(power, cpu) != S5P_CORE_LOCAL_PWR_EN )
> +        {
> +            if ( timeout-- == 0 )
> +                break;
> +
> +            mdelay(1);
> +        }
> +
> +        if ( timeout == 0 )
> +        {
> +            dprintk(XENLOG_ERR, "CPU%d power enable failed", cpu);
> +            return -ETIMEDOUT;
> +        }
> +    }
> +    return 0;
> +}
> +
> +static int exynos5_get_pmu_base_addr(u64 *power_base_addr) {
> +    u64 size;
> +    struct dt_device_node *node;
> +    int rc;
> +    static const struct dt_device_match exynos_dt_pmu_matches[] __initconst =
> +    {
> +        DT_MATCH_COMPATIBLE("samsung,exynos5250-pmu"),
> +        DT_MATCH_COMPATIBLE("samsung,exynos5410-pmu"),
> +        DT_MATCH_COMPATIBLE("samsung,exynos5420-pmu"),
> +        { /*sentinel*/ },
> +    };
> +
> +    node = dt_find_matching_node(NULL, exynos_dt_pmu_matches);
> +    if ( !node )
> +    {
> +        dprintk(XENLOG_ERR, "samsung,exynos5XXX-pmu missing in DT\n");
> +        return -ENXIO;
> +    }
> +
> +    rc = dt_device_get_address(node, 0, power_base_addr, &size);
> +    if ( rc )
> +    {
> +        dprintk(XENLOG_ERR, "Error in \"samsung,exynos5XXXX-pmu\"\n");
> +        return -ENXIO;
> +    }
> +
> +    dprintk(XENLOG_DEBUG, "power_base_addr: %016llx size: %016llx\n",
> +            *power_base_addr, size);
> +
> +    return 0;
> +}
> +
> +static int exynos5_cpu_up(int cpu)
> +{
> +    u64 power_base_addr;
> +    void __iomem *power;
> +    int rc;
> +
> +    rc = exynos5_get_pmu_base_addr(&power_base_addr);
> +    if ( rc )
> +        return rc;
> +
> +    power = ioremap_nocache(power_base_addr +
> +                            EXYNOS_ARM_CORE0_CONFIG, PAGE_SIZE);
> +    if ( !power )
> +    {
> +        dprintk(XENLOG_ERR, "Unable to map power MMIO\n");
> +        return -EFAULT;
> +    }
> +
> +    rc = exynos5_cpu_power_up(power, cpu);
> +    if ( rc )
> +    {
> +        iounmap(power);
> +        return -ETIMEDOUT;
> +    }
> +
> +    iounmap(power);
> +
> +    return cpu_up_send_sgi(cpu);
> +}
> +
>   static void exynos5_reset(void)
>   {
> +    u64 power_base_addr;
>       void __iomem *pmu;
> +    int rc;
>
>       BUILD_BUG_ON(EXYNOS5_SWRESET >= PAGE_SIZE);
>
> -    pmu = ioremap_nocache(EXYNOS5_PA_PMU, PAGE_SIZE);
> +    rc = exynos5_get_pmu_base_addr(&power_base_addr);
> +    if ( rc )
> +        return;
> +
> +    pmu = ioremap_nocache(power_base_addr, PAGE_SIZE);
>       if ( !pmu )
>       {
>           dprintk(XENLOG_ERR, "Unable to map PMU\n");
> @@ -98,15 +253,10 @@ static void exynos5_reset(void)
>       }
>
>       writel(1, pmu + EXYNOS5_SWRESET);
> +
>       iounmap(pmu);
>   }
>
> -static const char * const exynos5_dt_compat[] __initconst =
> -{
> -    "samsung,exynos5250",
> -    NULL
> -};
> -
>   static const struct dt_device_match exynos5_blacklist_dev[] __initconst =
>   {
>       /* Multi core Timer
> @@ -117,12 +267,33 @@ static const struct dt_device_match exynos5_blacklist_dev[] __initconst =
>       { /* sentinel */ },
>   };
>
> +static const char * const exynos5250_dt_compat[] __initconst =
> +{
> +    "samsung,exynos5250",
> +    NULL
> +};
> +
> +static const char * const exynos5_dt_compat[] __initconst =
> +{
> +    "samsung,exynos5410",
> +    NULL
> +};
> +
> +PLATFORM_START(exynos5250, "SAMSUNG EXYNOS5250")
> +    .compatible = exynos5250_dt_compat,
> +    .init_time = exynos5_init_time,
> +    .specific_mapping = exynos5250_specific_mapping,
> +    .smp_init = exynos5_smp_init,
> +    .cpu_up = cpu_up_send_sgi,
> +    .reset = exynos5_reset,
> +    .blacklist_dev = exynos5_blacklist_dev,
> +PLATFORM_END
> +
>   PLATFORM_START(exynos5, "SAMSUNG EXYNOS5")
>       .compatible = exynos5_dt_compat,
>       .init_time = exynos5_init_time,
> -    .specific_mapping = exynos5_specific_mapping,
>       .smp_init = exynos5_smp_init,
> -    .cpu_up = cpu_up_send_sgi,
> +    .cpu_up = exynos5_cpu_up,
>       .reset = exynos5_reset,
>       .blacklist_dev = exynos5_blacklist_dev,
>   PLATFORM_END
> diff --git a/xen/include/asm-arm/platforms/exynos5.h b/xen/include/asm-arm/platforms/exynos5.h
> index ea941e7..c88455a 100644
> --- a/xen/include/asm-arm/platforms/exynos5.h
> +++ b/xen/include/asm-arm/platforms/exynos5.h
> @@ -1,7 +1,6 @@
>   #ifndef __ASM_ARM_PLATFORMS_EXYNOS5_H
>   #define __ASM_ARM_PLATFORMS_EXYNOS5_H
>
> -#define EXYNOS5_MCT_BASE            0x101c0000
>   #define EXYNOS5_MCT_G_TCON          0x240       /* Relative to MCT_BASE */
>   #define EXYNOS5_MCT_G_TCON_START    (1 << 8)
>
> @@ -12,8 +11,6 @@
>
>   #define EXYNOS5_SWRESET             0x0400      /* Relative to PA_PMU */
>
> -#define S5P_PA_SYSRAM   0x02020000
> -
>   #endif /* __ASM_ARM_PLATFORMS_EXYNOS5_H */
>   /*
>    * Local variables:
>

-- 
Julien Grall

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410)
  2014-09-08 17:26   ` Suriyan Ramasami
  2014-09-09  9:15     ` Ian Campbell
@ 2014-09-10 22:21     ` Julien Grall
  2014-09-11  0:51       ` Suriyan Ramasami
  1 sibling, 1 reply; 23+ messages in thread
From: Julien Grall @ 2014-09-10 22:21 UTC (permalink / raw)
  To: Suriyan Ramasami, Ian Campbell
  Cc: keir, Tim Deegan, xen-devel, Jan Beulich, ian.jackson, Julien Grall

Hi Suriyan,

On 08/09/14 10:26, Suriyan Ramasami wrote:
> As can be seen, the secondary CPUs check _hotplug_addr for a non zero
> value on first being powered on, or after woken up from a wfe. This
> _hotplug_addr happens to be at offset +0x1c from NS_RAM_BASE.
> Linux mainline too has this hardcoded +0x1c.

You half read the Linux code... This offset is only add when there is a 
secure firmware (detected by "samsung,secure-firmware" node in the 
device tree).

On the Arndale the node doesn't exist.

Regards,

-- 
Julien Grall

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410)
  2014-09-10 22:21     ` Julien Grall
@ 2014-09-11  0:51       ` Suriyan Ramasami
  2014-09-11  1:03         ` Julien Grall
  0 siblings, 1 reply; 23+ messages in thread
From: Suriyan Ramasami @ 2014-09-11  0:51 UTC (permalink / raw)
  To: Julien Grall
  Cc: keir, Ian Campbell, Tim Deegan, xen-devel, Jan Beulich,
	ian.jackson, Julien Grall

On Wed, Sep 10, 2014 at 3:21 PM, Julien Grall <julien.grall@linaro.org> wrote:
> Hi Suriyan,
>
> On 08/09/14 10:26, Suriyan Ramasami wrote:
>>
>> As can be seen, the secondary CPUs check _hotplug_addr for a non zero
>> value on first being powered on, or after woken up from a wfe. This
>> _hotplug_addr happens to be at offset +0x1c from NS_RAM_BASE.
>> Linux mainline too has this hardcoded +0x1c.
>
>
> You half read the Linux code... This offset is only add when there is a
> secure firmware (detected by "samsung,secure-firmware" node in the device
> tree).
>
> On the Arndale the node doesn't exist.
>
Thanks for digging there Julien. Previously, I must have gone through
the linux code with only exynos5410 in mind. Nonetheless, looks like I
have left out the code which handles the arndale and possibly 5420 and
the 5800 (if they do not have "samsung,secure-firmware" defined). But
on the other hand, I do see arndale-octa has the "secure-firmware"
entry which is a 5420 (so does the 5800). This adds to the confusion.
This is from looking at the linux-3.16.y source.

Nonetheless, I think to handle arndale for now, I should add the
"samsung,secure-firmware" logic in the code which will then use
sysram_base_addr instead without any offset.

So, how do I go about this? Should I roll out another patch with these
cumulative changes and also add the BUG_ON change?

Thanks!
- Suriyan
> Regards,
>
> --
> Julien Grall

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410)
  2014-09-11  0:51       ` Suriyan Ramasami
@ 2014-09-11  1:03         ` Julien Grall
  2014-09-11  3:35           ` Suriyan Ramasami
  0 siblings, 1 reply; 23+ messages in thread
From: Julien Grall @ 2014-09-11  1:03 UTC (permalink / raw)
  To: Suriyan Ramasami
  Cc: keir, Ian Campbell, Tim Deegan, xen-devel, Jan Beulich,
	ian.jackson, Julien Grall

Hi Suriyan,

On 10/09/14 17:51, Suriyan Ramasami wrote:
> On Wed, Sep 10, 2014 at 3:21 PM, Julien Grall <julien.grall@linaro.org> wrote:
>> On 08/09/14 10:26, Suriyan Ramasami wrote:
>>>
>>> As can be seen, the secondary CPUs check _hotplug_addr for a non zero
>>> value on first being powered on, or after woken up from a wfe. This
>>> _hotplug_addr happens to be at offset +0x1c from NS_RAM_BASE.
>>> Linux mainline too has this hardcoded +0x1c.
>>
>>
>> You half read the Linux code... This offset is only add when there is a
>> secure firmware (detected by "samsung,secure-firmware" node in the device
>> tree).
>>
>> On the Arndale the node doesn't exist.
>>
> Thanks for digging there Julien. Previously, I must have gone through
> the linux code with only exynos5410 in mind. Nonetheless, looks like I
> have left out the code which handles the arndale and possibly 5420 and
> the 5800 (if they do not have "samsung,secure-firmware" defined). But
> on the other hand, I do see arndale-octa has the "secure-firmware"
> entry which is a 5420 (so does the 5800). This adds to the confusion.
> This is from looking at the linux-3.16.y source.
>
> Nonetheless, I think to handle arndale for now, I should add the
> "samsung,secure-firmware" logic in the code which will then use
> sysram_base_addr instead without any offset.
>
> So, how do I go about this? Should I roll out another patch with these
> cumulative changes and also add the BUG_ON change?

I think you could avoid to check the "samsung,secure-firmware" logic by 
only replicate arch/arm/mach-exynos/platsmp.c to Xen.

I suspect it will also work on the odroid-xu.

Regards,

-- 
Julien Grall

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410)
  2014-09-11  1:03         ` Julien Grall
@ 2014-09-11  3:35           ` Suriyan Ramasami
  2014-09-11 12:58             ` Ian Campbell
  0 siblings, 1 reply; 23+ messages in thread
From: Suriyan Ramasami @ 2014-09-11  3:35 UTC (permalink / raw)
  To: Julien Grall
  Cc: keir, Ian Campbell, Tim Deegan, xen-devel, Jan Beulich,
	ian.jackson, Julien Grall

On Wed, Sep 10, 2014 at 6:03 PM, Julien Grall <julien.grall@linaro.org> wrote:
> Hi Suriyan,
>
> On 10/09/14 17:51, Suriyan Ramasami wrote:
>>
>> On Wed, Sep 10, 2014 at 3:21 PM, Julien Grall <julien.grall@linaro.org>
>> wrote:
>>>
>>> On 08/09/14 10:26, Suriyan Ramasami wrote:
>>>>
>>>>
>>>> As can be seen, the secondary CPUs check _hotplug_addr for a non zero
>>>> value on first being powered on, or after woken up from a wfe. This
>>>> _hotplug_addr happens to be at offset +0x1c from NS_RAM_BASE.
>>>> Linux mainline too has this hardcoded +0x1c.
>>>
>>>
>>>
>>> You half read the Linux code... This offset is only add when there is a
>>> secure firmware (detected by "samsung,secure-firmware" node in the device
>>> tree).
>>>
>>> On the Arndale the node doesn't exist.
>>>
>> Thanks for digging there Julien. Previously, I must have gone through
>> the linux code with only exynos5410 in mind. Nonetheless, looks like I
>> have left out the code which handles the arndale and possibly 5420 and
>> the 5800 (if they do not have "samsung,secure-firmware" defined). But
>> on the other hand, I do see arndale-octa has the "secure-firmware"
>> entry which is a 5420 (so does the 5800). This adds to the confusion.
>> This is from looking at the linux-3.16.y source.
>>
>> Nonetheless, I think to handle arndale for now, I should add the
>> "samsung,secure-firmware" logic in the code which will then use
>> sysram_base_addr instead without any offset.
>>
>> So, how do I go about this? Should I roll out another patch with these
>> cumulative changes and also add the BUG_ON change?
>
>
> I think you could avoid to check the "samsung,secure-firmware" logic by only
> replicate arch/arm/mach-exynos/platsmp.c to Xen.
>

Hi Julien,
   I think "samsung,secure-firmware" is what differentiates the code
path in platsmp.c, from what I can tell. Correct me if I am wrong,
please. This is from the smp_init's perspective in XEN.

The code in linux is:
                /*
                 * Try to set boot address using firmware first
                 * and fall back to boot register if it fails.
                 */
                ret = call_firmware_op(set_cpu_boot_addr, phys_cpu, boot_addr);
                if (ret && ret != -ENOSYS)
                        goto fail;
                if (ret == -ENOSYS) {
                        void __iomem *boot_reg = cpu_boot_reg(phys_cpu);

                        if (IS_ERR(boot_reg)) {
                                ret = PTR_ERR(boot_reg);
                                goto fail;
                        }
                        __raw_writel(boot_addr, cpu_boot_reg(phys_cpu));
                }

call_firmware_op(set_cpu_boot_addr, ...) will return -ENOSYS (which
then uses the alternative code path of using cpu_boot_reg(), which
uses sysram_base_addr), only if register_firmware_ops() is not called
with &exynos_firmware_ops, as per the code in mach-exynos/firmware.c.
Furthermore, it is not registered in exynos_firmware_init() only if
"samsung,secure-firmware" is not found in the DT.

I am just wondering, if you had something else in mind which can be
achieved without depending on "samsung,secure-firmware". Please let me
know the alternative.

Thanks a lot!
- Suriyan

> I suspect it will also work on the odroid-xu.
>
> Regards,
>
> --
> Julien Grall

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410)
  2014-09-10 21:08 ` Julien Grall
@ 2014-09-11  8:53   ` Ian Campbell
  2014-09-11 12:53     ` Ian Campbell
  0 siblings, 1 reply; 23+ messages in thread
From: Ian Campbell @ 2014-09-11  8:53 UTC (permalink / raw)
  To: Julien Grall
  Cc: keir, Suriyan Ramasami, tim, xen-devel, jbeulich, ian.jackson,
	julien.grall

On Wed, 2014-09-10 at 14:08 -0700, Julien Grall wrote:
> Hi all,
> 
> This patch breaks Xen boot on the Arndale.

It works for me using mainline u-boot v2014.10-rc2, so I suppose
something is different about the Linaro u-boot.

> It would have been nice to test this patch on the Arndale before pushing 
> it on master... I was unable to do it because I was away.

This is why we have automated regression tests, to catch these things.

Anyway, it seems like this subthread is converging on a solution which
will work for both/all platforms, so I'll await that.

Ian.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410)
  2014-09-10 17:05   ` Suriyan Ramasami
@ 2014-09-11  9:03     ` Ian Campbell
  0 siblings, 0 replies; 23+ messages in thread
From: Ian Campbell @ 2014-09-11  9:03 UTC (permalink / raw)
  To: Suriyan Ramasami
  Cc: keir, Tim Deegan, xen-devel, Jan Beulich, ian.jackson, Julien Grall

On Wed, 2014-09-10 at 10:05 -0700, Suriyan Ramasami wrote:
> On Wed, Sep 10, 2014 at 7:07 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2014-09-04 at 15:57 -0700, Suriyan Ramasami wrote:
> >
> >>      BUILD_BUG_ON(EXYNOS5_MCT_G_TCON >= PAGE_SIZE);
> >>
> >> -    mct = ioremap_attr(EXYNOS5_MCT_BASE, PAGE_SIZE, PAGE_HYPERVISOR_NOCACHE);
> >> +    node = dt_find_compatible_node(NULL, NULL, "samsung,exynos4210-mct");
> >> +    if ( !node )
> >> +    {
> >> +        dprintk(XENLOG_ERR, "samsung,exynos4210-mct missing in DT\n");
> >> +        return -ENXIO;
> >> +    }
> >> +
> >> +    rc = dt_device_get_address(node, 0, &mct_base_addr, &size);
> >> +    if ( rc )
> >> +    {
> >> +        dprintk(XENLOG_ERR, "Error in \"samsung,exynos4210-mct\"\n");
> >> +        return -ENXIO;
> >> +    }
> >> +
> >> +    dprintk(XENLOG_INFO, "mct_base_addr: %016llx size: %016llx\n",
> >> +            mct_base_addr, size);
> >> +
> >> +    mct = ioremap_attr(mct_base_addr, PAGE_SIZE, PAGE_HYPERVISOR_NOCACHE);
> >
> > I noticed this while applying, it wasn't enough to stop me but it would
> > be nice to fix:
> >
> > We should drop that BUILD_BUG_ON and use the size retrieved from the DT
> > for the mapping instead.
> >
> This did occur to me, more so when mapping the power base address (as
> I map from an offset rather than base so that I am within the
> PAGE_SIZE that I map). From what you are suggesting, we should just
> map the base address (mct or pmu) for the size that we retrieve. I see
> that the mct is of size 0x800 and the pmu is of size 0x5000.
> We can then add a check to see if the offsets that we are cooking up,
> like EXYNOS5_MCT_G_TCON are within size that we have retrieved.
> I hope this is what you were suggesting. Please let me know, and I
> shall send a patch for this.

Yes, I think the logic should be:
      * Retrieve address+size from DT
      * Check that size is large enough for the registers we need to
        touch, error if not
      * Map size bytes from address
      * Access the registers using appropriate offsets

IOW do the check before bothering to map, and map the returned address,
don't add the offset on map, add it on access instead.

Thanks,
Ian.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410)
  2014-09-11  8:53   ` Ian Campbell
@ 2014-09-11 12:53     ` Ian Campbell
  2014-09-11 18:27       ` Julien Grall
  0 siblings, 1 reply; 23+ messages in thread
From: Ian Campbell @ 2014-09-11 12:53 UTC (permalink / raw)
  To: Julien Grall
  Cc: keir, Suriyan Ramasami, tim, xen-devel, jbeulich, ian.jackson,
	julien.grall

On Thu, 2014-09-11 at 09:53 +0100, Ian Campbell wrote:
> On Wed, 2014-09-10 at 14:08 -0700, Julien Grall wrote:
> > Hi all,
> > 
> > This patch breaks Xen boot on the Arndale.
> 
> It works for me using mainline u-boot v2014.10-rc2, so I suppose
> something is different about the Linaro u-boot.

I take that back -- I was inadvertently testing master and not what I
thought I was testing.

Ian.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410)
  2014-09-11  3:35           ` Suriyan Ramasami
@ 2014-09-11 12:58             ` Ian Campbell
  2014-09-11 13:30               ` Suriyan Ramasami
  2014-09-11 18:36               ` Julien Grall
  0 siblings, 2 replies; 23+ messages in thread
From: Ian Campbell @ 2014-09-11 12:58 UTC (permalink / raw)
  To: Suriyan Ramasami
  Cc: keir, Julien Grall, Tim Deegan, xen-devel, Jan Beulich,
	ian.jackson, Julien Grall

On Wed, 2014-09-10 at 20:35 -0700, Suriyan Ramasami wrote:
> On Wed, Sep 10, 2014 at 6:03 PM, Julien Grall <julien.grall@linaro.org> wrote:
> > Hi Suriyan,
> >
> > On 10/09/14 17:51, Suriyan Ramasami wrote:
> >>
> >> On Wed, Sep 10, 2014 at 3:21 PM, Julien Grall <julien.grall@linaro.org>
> >> wrote:
> >>>
> >>> On 08/09/14 10:26, Suriyan Ramasami wrote:
> >>>>
> >>>>
> >>>> As can be seen, the secondary CPUs check _hotplug_addr for a non zero
> >>>> value on first being powered on, or after woken up from a wfe. This
> >>>> _hotplug_addr happens to be at offset +0x1c from NS_RAM_BASE.
> >>>> Linux mainline too has this hardcoded +0x1c.
> >>>
> >>>
> >>>
> >>> You half read the Linux code... This offset is only add when there is a
> >>> secure firmware (detected by "samsung,secure-firmware" node in the device
> >>> tree).
> >>>
> >>> On the Arndale the node doesn't exist.
> >>>
> >> Thanks for digging there Julien. Previously, I must have gone through
> >> the linux code with only exynos5410 in mind. Nonetheless, looks like I
> >> have left out the code which handles the arndale and possibly 5420 and
> >> the 5800 (if they do not have "samsung,secure-firmware" defined). But
> >> on the other hand, I do see arndale-octa has the "secure-firmware"
> >> entry which is a 5420 (so does the 5800). This adds to the confusion.
> >> This is from looking at the linux-3.16.y source.
> >>
> >> Nonetheless, I think to handle arndale for now, I should add the
> >> "samsung,secure-firmware" logic in the code which will then use
> >> sysram_base_addr instead without any offset.
> >>
> >> So, how do I go about this? Should I roll out another patch with these
> >> cumulative changes and also add the BUG_ON change?
> >
> >
> > I think you could avoid to check the "samsung,secure-firmware" logic by only
> > replicate arch/arm/mach-exynos/platsmp.c to Xen.
> >
> 
> Hi Julien,
>    I think "samsung,secure-firmware" is what differentiates the code
> path in platsmp.c, from what I can tell. Correct me if I am wrong,
> please. This is from the smp_init's perspective in XEN.
> 
> The code in linux is:
>                 /*
>                  * Try to set boot address using firmware first
>                  * and fall back to boot register if it fails.
>                  */
>                 ret = call_firmware_op(set_cpu_boot_addr, phys_cpu, boot_addr);
>                 if (ret && ret != -ENOSYS)
>                         goto fail;
>                 if (ret == -ENOSYS) {
>                         void __iomem *boot_reg = cpu_boot_reg(phys_cpu);
> 
>                         if (IS_ERR(boot_reg)) {
>                                 ret = PTR_ERR(boot_reg);
>                                 goto fail;
>                         }
>                         __raw_writel(boot_addr, cpu_boot_reg(phys_cpu));
>                 }
> 
> call_firmware_op(set_cpu_boot_addr, ...) will return -ENOSYS (which
> then uses the alternative code path of using cpu_boot_reg(), which
> uses sysram_base_addr), only if register_firmware_ops() is not called
> with &exynos_firmware_ops, as per the code in mach-exynos/firmware.c.
> Furthermore, it is not registered in exynos_firmware_init() only if
> "samsung,secure-firmware" is not found in the DT.
> 
> I am just wondering, if you had something else in mind which can be
> achieved without depending on "samsung,secure-firmware". Please let me
> know the alternative.

I think what you suggest sounds plausible. For me the following fixes
boot on my arndale (I mistakenly thought that it worked earlier but I
was testing the wrong thing). If the presence of samsung,secure-firmware
is the way to distinguish the two cases then lets go that way.

Since arndale is used in automated tests I'm inclined towards applying
this patch until a solution is found to detect the Odroid case.

Ian.

-----8<--------------

>From 24f74cbb981689b37d6bf83978c628a9fbabe246 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Thu, 11 Sep 2014 13:55:08 +0100
Subject: [PATCH] xen: arm: fix boot on arndale.

The differences between Arndale and the Odoid-XU are more interesting
than first though, which results in 0bf8ddecb4df "xen/arm: Add
support for the Odroid-XU board." breaking boot on arndale.

Revert back to arndale compatible behaviour while we sort this out.
Specifically we must (counterintuitively) use the regular (!ns)
sysram and the correct offset is 0x0 and 0x1c.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/platforms/exynos5.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/platforms/exynos5.c b/xen/arch/arm/platforms/exynos5.c
index bc9ae15..22a38f0 100644
--- a/xen/arch/arm/platforms/exynos5.c
+++ b/xen/arch/arm/platforms/exynos5.c
@@ -99,7 +99,7 @@ static int __init exynos5_smp_init(void)
     u64 size;
     int rc;
 
-    node = dt_find_compatible_node(NULL, NULL, "samsung,exynos4210-sysram-ns");
+    node = dt_find_compatible_node(NULL, NULL, "samsung,exynos4210-sysram");
     if ( !node )
     {
         dprintk(XENLOG_ERR, "samsung,exynos4210-sysram-ns missing in DT\n");
@@ -125,7 +125,7 @@ static int __init exynos5_smp_init(void)
 
     printk("Set SYSRAM to %"PRIpaddr" (%p)\n",
            __pa(init_secondary), init_secondary);
-    writel(__pa(init_secondary), sysram + 0x1c);
+    writel(__pa(init_secondary), sysram);
 
     iounmap(sysram);
 
-- 
1.7.10.4

^ permalink raw reply related	[flat|nested] 23+ messages in thread

* Re: [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410)
  2014-09-11 12:58             ` Ian Campbell
@ 2014-09-11 13:30               ` Suriyan Ramasami
  2014-09-11 13:35                 ` Ian Campbell
  2014-09-11 18:36               ` Julien Grall
  1 sibling, 1 reply; 23+ messages in thread
From: Suriyan Ramasami @ 2014-09-11 13:30 UTC (permalink / raw)
  To: Ian Campbell
  Cc: keir, Julien Grall, Tim Deegan, xen-devel, Jan Beulich,
	ian.jackson, Julien Grall

On Thu, Sep 11, 2014 at 5:58 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2014-09-10 at 20:35 -0700, Suriyan Ramasami wrote:
>> On Wed, Sep 10, 2014 at 6:03 PM, Julien Grall <julien.grall@linaro.org> wrote:
>> > Hi Suriyan,
>> >
>> > On 10/09/14 17:51, Suriyan Ramasami wrote:
>> >>
>> >> On Wed, Sep 10, 2014 at 3:21 PM, Julien Grall <julien.grall@linaro.org>
>> >> wrote:
>> >>>
>> >>> On 08/09/14 10:26, Suriyan Ramasami wrote:
>> >>>>
>> >>>>
>> >>>> As can be seen, the secondary CPUs check _hotplug_addr for a non zero
>> >>>> value on first being powered on, or after woken up from a wfe. This
>> >>>> _hotplug_addr happens to be at offset +0x1c from NS_RAM_BASE.
>> >>>> Linux mainline too has this hardcoded +0x1c.
>> >>>
>> >>>
>> >>>
>> >>> You half read the Linux code... This offset is only add when there is a
>> >>> secure firmware (detected by "samsung,secure-firmware" node in the device
>> >>> tree).
>> >>>
>> >>> On the Arndale the node doesn't exist.
>> >>>
>> >> Thanks for digging there Julien. Previously, I must have gone through
>> >> the linux code with only exynos5410 in mind. Nonetheless, looks like I
>> >> have left out the code which handles the arndale and possibly 5420 and
>> >> the 5800 (if they do not have "samsung,secure-firmware" defined). But
>> >> on the other hand, I do see arndale-octa has the "secure-firmware"
>> >> entry which is a 5420 (so does the 5800). This adds to the confusion.
>> >> This is from looking at the linux-3.16.y source.
>> >>
>> >> Nonetheless, I think to handle arndale for now, I should add the
>> >> "samsung,secure-firmware" logic in the code which will then use
>> >> sysram_base_addr instead without any offset.
>> >>
>> >> So, how do I go about this? Should I roll out another patch with these
>> >> cumulative changes and also add the BUG_ON change?
>> >
>> >
>> > I think you could avoid to check the "samsung,secure-firmware" logic by only
>> > replicate arch/arm/mach-exynos/platsmp.c to Xen.
>> >
>>
>> Hi Julien,
>>    I think "samsung,secure-firmware" is what differentiates the code
>> path in platsmp.c, from what I can tell. Correct me if I am wrong,
>> please. This is from the smp_init's perspective in XEN.
>>
>> The code in linux is:
>>                 /*
>>                  * Try to set boot address using firmware first
>>                  * and fall back to boot register if it fails.
>>                  */
>>                 ret = call_firmware_op(set_cpu_boot_addr, phys_cpu, boot_addr);
>>                 if (ret && ret != -ENOSYS)
>>                         goto fail;
>>                 if (ret == -ENOSYS) {
>>                         void __iomem *boot_reg = cpu_boot_reg(phys_cpu);
>>
>>                         if (IS_ERR(boot_reg)) {
>>                                 ret = PTR_ERR(boot_reg);
>>                                 goto fail;
>>                         }
>>                         __raw_writel(boot_addr, cpu_boot_reg(phys_cpu));
>>                 }
>>
>> call_firmware_op(set_cpu_boot_addr, ...) will return -ENOSYS (which
>> then uses the alternative code path of using cpu_boot_reg(), which
>> uses sysram_base_addr), only if register_firmware_ops() is not called
>> with &exynos_firmware_ops, as per the code in mach-exynos/firmware.c.
>> Furthermore, it is not registered in exynos_firmware_init() only if
>> "samsung,secure-firmware" is not found in the DT.
>>
>> I am just wondering, if you had something else in mind which can be
>> achieved without depending on "samsung,secure-firmware". Please let me
>> know the alternative.
>
> I think what you suggest sounds plausible. For me the following fixes
> boot on my arndale (I mistakenly thought that it worked earlier but I
> was testing the wrong thing). If the presence of samsung,secure-firmware
> is the way to distinguish the two cases then lets go that way.
>

Hi Ian,
   A silly question ... The next patch that I send which possibly
handles Arndale and Odroid-XU, should that be based on master or
staging?

Thanks!
> Since arndale is used in automated tests I'm inclined towards applying
> this patch until a solution is found to detect the Odroid case.
>
> Ian.
>
> -----8<--------------
>
> From 24f74cbb981689b37d6bf83978c628a9fbabe246 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Thu, 11 Sep 2014 13:55:08 +0100
> Subject: [PATCH] xen: arm: fix boot on arndale.
>
> The differences between Arndale and the Odoid-XU are more interesting
> than first though, which results in 0bf8ddecb4df "xen/arm: Add
> support for the Odroid-XU board." breaking boot on arndale.
>
> Revert back to arndale compatible behaviour while we sort this out.
> Specifically we must (counterintuitively) use the regular (!ns)
> sysram and the correct offset is 0x0 and 0x1c.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/platforms/exynos5.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/arm/platforms/exynos5.c b/xen/arch/arm/platforms/exynos5.c
> index bc9ae15..22a38f0 100644
> --- a/xen/arch/arm/platforms/exynos5.c
> +++ b/xen/arch/arm/platforms/exynos5.c
> @@ -99,7 +99,7 @@ static int __init exynos5_smp_init(void)
>      u64 size;
>      int rc;
>
> -    node = dt_find_compatible_node(NULL, NULL, "samsung,exynos4210-sysram-ns");
> +    node = dt_find_compatible_node(NULL, NULL, "samsung,exynos4210-sysram");
>      if ( !node )
>      {
>          dprintk(XENLOG_ERR, "samsung,exynos4210-sysram-ns missing in DT\n");
> @@ -125,7 +125,7 @@ static int __init exynos5_smp_init(void)
>
>      printk("Set SYSRAM to %"PRIpaddr" (%p)\n",
>             __pa(init_secondary), init_secondary);
> -    writel(__pa(init_secondary), sysram + 0x1c);
> +    writel(__pa(init_secondary), sysram);
>
>      iounmap(sysram);
>
> --
> 1.7.10.4
>
>
>

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410)
  2014-09-11 13:30               ` Suriyan Ramasami
@ 2014-09-11 13:35                 ` Ian Campbell
  0 siblings, 0 replies; 23+ messages in thread
From: Ian Campbell @ 2014-09-11 13:35 UTC (permalink / raw)
  To: Suriyan Ramasami
  Cc: keir, Julien Grall, Tim Deegan, xen-devel, Jan Beulich,
	ian.jackson, Julien Grall

On Thu, 2014-09-11 at 06:30 -0700, Suriyan Ramasami wrote:
> On Thu, Sep 11, 2014 at 5:58 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Wed, 2014-09-10 at 20:35 -0700, Suriyan Ramasami wrote:
> >> On Wed, Sep 10, 2014 at 6:03 PM, Julien Grall <julien.grall@linaro.org> wrote:
> >> > Hi Suriyan,
> >> >
> >> > On 10/09/14 17:51, Suriyan Ramasami wrote:
> >> >>
> >> >> On Wed, Sep 10, 2014 at 3:21 PM, Julien Grall <julien.grall@linaro.org>
> >> >> wrote:
> >> >>>
> >> >>> On 08/09/14 10:26, Suriyan Ramasami wrote:
> >> >>>>
> >> >>>>
> >> >>>> As can be seen, the secondary CPUs check _hotplug_addr for a non zero
> >> >>>> value on first being powered on, or after woken up from a wfe. This
> >> >>>> _hotplug_addr happens to be at offset +0x1c from NS_RAM_BASE.
> >> >>>> Linux mainline too has this hardcoded +0x1c.
> >> >>>
> >> >>>
> >> >>>
> >> >>> You half read the Linux code... This offset is only add when there is a
> >> >>> secure firmware (detected by "samsung,secure-firmware" node in the device
> >> >>> tree).
> >> >>>
> >> >>> On the Arndale the node doesn't exist.
> >> >>>
> >> >> Thanks for digging there Julien. Previously, I must have gone through
> >> >> the linux code with only exynos5410 in mind. Nonetheless, looks like I
> >> >> have left out the code which handles the arndale and possibly 5420 and
> >> >> the 5800 (if they do not have "samsung,secure-firmware" defined). But
> >> >> on the other hand, I do see arndale-octa has the "secure-firmware"
> >> >> entry which is a 5420 (so does the 5800). This adds to the confusion.
> >> >> This is from looking at the linux-3.16.y source.
> >> >>
> >> >> Nonetheless, I think to handle arndale for now, I should add the
> >> >> "samsung,secure-firmware" logic in the code which will then use
> >> >> sysram_base_addr instead without any offset.
> >> >>
> >> >> So, how do I go about this? Should I roll out another patch with these
> >> >> cumulative changes and also add the BUG_ON change?
> >> >
> >> >
> >> > I think you could avoid to check the "samsung,secure-firmware" logic by only
> >> > replicate arch/arm/mach-exynos/platsmp.c to Xen.
> >> >
> >>
> >> Hi Julien,
> >>    I think "samsung,secure-firmware" is what differentiates the code
> >> path in platsmp.c, from what I can tell. Correct me if I am wrong,
> >> please. This is from the smp_init's perspective in XEN.
> >>
> >> The code in linux is:
> >>                 /*
> >>                  * Try to set boot address using firmware first
> >>                  * and fall back to boot register if it fails.
> >>                  */
> >>                 ret = call_firmware_op(set_cpu_boot_addr, phys_cpu, boot_addr);
> >>                 if (ret && ret != -ENOSYS)
> >>                         goto fail;
> >>                 if (ret == -ENOSYS) {
> >>                         void __iomem *boot_reg = cpu_boot_reg(phys_cpu);
> >>
> >>                         if (IS_ERR(boot_reg)) {
> >>                                 ret = PTR_ERR(boot_reg);
> >>                                 goto fail;
> >>                         }
> >>                         __raw_writel(boot_addr, cpu_boot_reg(phys_cpu));
> >>                 }
> >>
> >> call_firmware_op(set_cpu_boot_addr, ...) will return -ENOSYS (which
> >> then uses the alternative code path of using cpu_boot_reg(), which
> >> uses sysram_base_addr), only if register_firmware_ops() is not called
> >> with &exynos_firmware_ops, as per the code in mach-exynos/firmware.c.
> >> Furthermore, it is not registered in exynos_firmware_init() only if
> >> "samsung,secure-firmware" is not found in the DT.
> >>
> >> I am just wondering, if you had something else in mind which can be
> >> achieved without depending on "samsung,secure-firmware". Please let me
> >> know the alternative.
> >
> > I think what you suggest sounds plausible. For me the following fixes
> > boot on my arndale (I mistakenly thought that it worked earlier but I
> > was testing the wrong thing). If the presence of samsung,secure-firmware
> > is the way to distinguish the two cases then lets go that way.
> >
> 
> Hi Ian,
>    A silly question ... The next patch that I send which possibly
> handles Arndale and Odroid-XU, should that be based on master or
> staging?

staging please, plus this patch I think.

(normally master is fine but in this case there are relevant changes in
the the master..staging range).

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410)
  2014-09-11 12:53     ` Ian Campbell
@ 2014-09-11 18:27       ` Julien Grall
  2014-09-12 10:21         ` Ian Campbell
  0 siblings, 1 reply; 23+ messages in thread
From: Julien Grall @ 2014-09-11 18:27 UTC (permalink / raw)
  To: Ian Campbell
  Cc: keir, Suriyan Ramasami, tim, xen-devel, jbeulich, ian.jackson,
	julien.grall



On 11/09/14 05:53, Ian Campbell wrote:
> On Thu, 2014-09-11 at 09:53 +0100, Ian Campbell wrote:
>> On Wed, 2014-09-10 at 14:08 -0700, Julien Grall wrote:
>>> Hi all,
>>>
>>> This patch breaks Xen boot on the Arndale.
>>
>> It works for me using mainline u-boot v2014.10-rc2, so I suppose
>> something is different about the Linaro u-boot.
>
> I take that back -- I was inadvertently testing master and not what I
> thought I was testing.

By any chance do you have a secure firmware provided by Samsung?

Regards,

-- 
Julien Grall

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410)
  2014-09-11 12:58             ` Ian Campbell
  2014-09-11 13:30               ` Suriyan Ramasami
@ 2014-09-11 18:36               ` Julien Grall
  2014-09-12 10:19                 ` Ian Campbell
  1 sibling, 1 reply; 23+ messages in thread
From: Julien Grall @ 2014-09-11 18:36 UTC (permalink / raw)
  To: Ian Campbell, Suriyan Ramasami
  Cc: keir, Tim Deegan, xen-devel, Jan Beulich, ian.jackson, Julien Grall

Hi Ian,

On 11/09/14 05:58, Ian Campbell wrote:
> I think what you suggest sounds plausible. For me the following fixes
> boot on my arndale (I mistakenly thought that it worked earlier but I
> was testing the wrong thing). If the presence of samsung,secure-firmware
> is the way to distinguish the two cases then lets go that way.
>
> Since arndale is used in automated tests I'm inclined towards applying
> this patch until a solution is found to detect the Odroid case.
> -----8<--------------
>
>  From 24f74cbb981689b37d6bf83978c628a9fbabe246 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Thu, 11 Sep 2014 13:55:08 +0100
> Subject: [PATCH] xen: arm: fix boot on arndale.
>
> The differences between Arndale and the Odoid-XU are more interesting
> than first though, which results in 0bf8ddecb4df "xen/arm: Add
> support for the Odroid-XU board." breaking boot on arndale.
>
> Revert back to arndale compatible behaviour while we sort this out.
> Specifically we must (counterintuitively) use the regular (!ns)
> sysram and the correct offset is 0x0 and 0x1c.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>

Also I will give a look to the fix up patch ("Unbreak Arndale XEN Boot") 
today.

Regards,
-- 
Julien Grall

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410)
  2014-09-11 18:36               ` Julien Grall
@ 2014-09-12 10:19                 ` Ian Campbell
  0 siblings, 0 replies; 23+ messages in thread
From: Ian Campbell @ 2014-09-12 10:19 UTC (permalink / raw)
  To: Julien Grall
  Cc: keir, Suriyan Ramasami, Tim Deegan, xen-devel, Jan Beulich,
	ian.jackson, Julien Grall


On Thu, 2014-09-11 at 11:36 -0700, Julien Grall wrote:
> Hi Ian,
> 
> On 11/09/14 05:58, Ian Campbell wrote:
> > I think what you suggest sounds plausible. For me the following fixes
> > boot on my arndale (I mistakenly thought that it worked earlier but I
> > was testing the wrong thing). If the presence of samsung,secure-firmware
> > is the way to distinguish the two cases then lets go that way.
> >
> > Since arndale is used in automated tests I'm inclined towards applying
> > this patch until a solution is found to detect the Odroid case.
> > -----8<--------------
> >
> >  From 24f74cbb981689b37d6bf83978c628a9fbabe246 Mon Sep 17 00:00:00 2001
> > From: Ian Campbell <ian.campbell@citrix.com>
> > Date: Thu, 11 Sep 2014 13:55:08 +0100
> > Subject: [PATCH] xen: arm: fix boot on arndale.
> >
> > The differences between Arndale and the Odoid-XU are more interesting
> > than first though, which results in 0bf8ddecb4df "xen/arm: Add
> > support for the Odroid-XU board." breaking boot on arndale.
> >
> > Revert back to arndale compatible behaviour while we sort this out.
> > Specifically we must (counterintuitively) use the regular (!ns)
> > sysram and the correct offset is 0x0 and 0x1c.
> >
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Reviewed-by: Julien Grall <julien.grall@linaro.org>
> 
> Also I will give a look to the fix up patch ("Unbreak Arndale XEN Boot") 
> today.

Thanks. In the meantime I have applied the fix to make arndale work
again.

Ian.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410)
  2014-09-11 18:27       ` Julien Grall
@ 2014-09-12 10:21         ` Ian Campbell
  2014-09-12 18:54           ` Julien Grall
  0 siblings, 1 reply; 23+ messages in thread
From: Ian Campbell @ 2014-09-12 10:21 UTC (permalink / raw)
  To: Julien Grall
  Cc: keir, Suriyan Ramasami, tim, xen-devel, jbeulich, ian.jackson,
	julien.grall

On Thu, 2014-09-11 at 11:27 -0700, Julien Grall wrote:
> 
> On 11/09/14 05:53, Ian Campbell wrote:
> > On Thu, 2014-09-11 at 09:53 +0100, Ian Campbell wrote:
> >> On Wed, 2014-09-10 at 14:08 -0700, Julien Grall wrote:
> >>> Hi all,
> >>>
> >>> This patch breaks Xen boot on the Arndale.
> >>
> >> It works for me using mainline u-boot v2014.10-rc2, so I suppose
> >> something is different about the Linaro u-boot.
> >
> > I take that back -- I was inadvertently testing master and not what I
> > thought I was testing.

BTW this means that I found that things were indeed broken on my arndale
too. (Your question made me wonder if that wasn't clear)

> By any chance do you have a secure firmware provided by Samsung?

I'm just using the arndale-bl1.bin from wherever I found it and the
mainline u-boot v2014.10-rc2. I don't think the arndale-bl1.bin is the
secure f/w you mean.

Ian.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410)
  2014-09-12 10:21         ` Ian Campbell
@ 2014-09-12 18:54           ` Julien Grall
  0 siblings, 0 replies; 23+ messages in thread
From: Julien Grall @ 2014-09-12 18:54 UTC (permalink / raw)
  To: Ian Campbell
  Cc: keir, Suriyan Ramasami, tim, xen-devel, jbeulich, ian.jackson,
	julien.grall

Hi Ian,

On 12/09/14 03:21, Ian Campbell wrote:
> On Thu, 2014-09-11 at 11:27 -0700, Julien Grall wrote:
>>
>> On 11/09/14 05:53, Ian Campbell wrote:
>>> On Thu, 2014-09-11 at 09:53 +0100, Ian Campbell wrote:
>>>> On Wed, 2014-09-10 at 14:08 -0700, Julien Grall wrote:
>>>>> Hi all,
>>>>>
>>>>> This patch breaks Xen boot on the Arndale.
>>>>
>>>> It works for me using mainline u-boot v2014.10-rc2, so I suppose
>>>> something is different about the Linaro u-boot.
>>>
>>> I take that back -- I was inadvertently testing master and not what I
>>> thought I was testing.
>
> BTW this means that I found that things were indeed broken on my arndale
> too. (Your question made me wonder if that wasn't clear)

I understood that. I was just wondering if we have an exynos board at 
the office where the Samsung secure firmware is working.

But it looks like the Arndale 5250 doesn't support it.

Regards,


-- 
Julien Grall

^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2014-09-12 18:54 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-04 22:57 [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410) Suriyan Ramasami
2014-09-08 10:20 ` Ian Campbell
2014-09-08 17:26   ` Suriyan Ramasami
2014-09-09  9:15     ` Ian Campbell
2014-09-09 15:34       ` Suriyan Ramasami
2014-09-10 22:21     ` Julien Grall
2014-09-11  0:51       ` Suriyan Ramasami
2014-09-11  1:03         ` Julien Grall
2014-09-11  3:35           ` Suriyan Ramasami
2014-09-11 12:58             ` Ian Campbell
2014-09-11 13:30               ` Suriyan Ramasami
2014-09-11 13:35                 ` Ian Campbell
2014-09-11 18:36               ` Julien Grall
2014-09-12 10:19                 ` Ian Campbell
2014-09-10 14:07 ` Ian Campbell
2014-09-10 17:05   ` Suriyan Ramasami
2014-09-11  9:03     ` Ian Campbell
2014-09-10 21:08 ` Julien Grall
2014-09-11  8:53   ` Ian Campbell
2014-09-11 12:53     ` Ian Campbell
2014-09-11 18:27       ` Julien Grall
2014-09-12 10:21         ` Ian Campbell
2014-09-12 18:54           ` Julien Grall

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.