[PATCH v3 0/5] Versatile Express DT support

[PATCH v3 0/5] Versatile Express DT support

[Pawel Moll]

Hi All,

Another, hopefully close to the final, version of the series...

Changes from v2:

* new patch adding ENDPROC at the end of arch/arm/plat-versatile/headsmp.S
  and removing use of BSYM() realview and vexpress platform SMP calls

* updated binding documentation according to Dave's comments

* changed motherboard labels prefix from mb_ to v2m_ (to be
  consistent across code and DT files)

* reworked v2m timer initialization (again) so no #ifdefs are required
  in non-DT code

* renamed (to vendor- and platform-specific "arm,v2m-timer") and moved
  (to vexpress-v2m*.dtsi files) timer DT alias, as it is actually
  motherboard specific and the tile DTS shouldn't have to care;
  documentation updated accordingly

Tested on V2P-CA9 with ATAGs and DT and on V2P-CA5s with DT.

Previous version has been also tested by Ryan Harkin and
provisionally acked by Rob Herring.

Thanks for all your help, especially to Dave for his continuous support!

Pawel Moll (5):
  ARM: versatile: Add missing ENDPROC to headsmp.S
  ARM: vexpress: Get rid of MMIO_P2V
  ARM: vexpress: Add DT support in v2m
  ARM: vexpress: Initial RS1 memory map support
  ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4

 Documentation/devicetree/bindings/arm/vexpress.txt |  108 +++++++++
 arch/arm/boot/dts/vexpress-v2m-rs1.dtsi            |  196 +++++++++++++++
 arch/arm/boot/dts/vexpress-v2m.dtsi                |  195 +++++++++++++++
 arch/arm/boot/dts/vexpress-v2p-ca5s.dts            |  131 ++++++++++
 arch/arm/boot/dts/vexpress-v2p-ca9.dts             |  145 +++++++++++
 arch/arm/include/asm/hardware/arm_timer.h          |    5 +
 arch/arm/mach-realview/platsmp.c                   |    3 +-
 arch/arm/mach-vexpress/Kconfig                     |   37 +++
 arch/arm/mach-vexpress/Makefile                    |    1 +
 arch/arm/mach-vexpress/Makefile.boot               |    6 +
 arch/arm/mach-vexpress/core.h                      |   21 ++-
 arch/arm/mach-vexpress/ct-ca9x4.c                  |   52 +---
 arch/arm/mach-vexpress/include/mach/ct-ca9x4.h     |   13 +-
 arch/arm/mach-vexpress/include/mach/debug-macro.S  |   37 +++-
 arch/arm/mach-vexpress/include/mach/motherboard.h  |   58 +++--
 arch/arm/mach-vexpress/include/mach/uncompress.h   |   13 +-
 arch/arm/mach-vexpress/platsmp.c                   |    7 +-
 arch/arm/mach-vexpress/v2m.c                       |  255 ++++++++++++++++++--
 arch/arm/mach-vexpress/v2p-ca5s_ca9.c              |  115 +++++++++
 arch/arm/plat-versatile/headsmp.S                  |    1 +
 20 files changed, 1286 insertions(+), 113 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/vexpress.txt
 create mode 100644 arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
 create mode 100644 arch/arm/boot/dts/vexpress-v2m.dtsi
 create mode 100644 arch/arm/boot/dts/vexpress-v2p-ca5s.dts
 create mode 100644 arch/arm/boot/dts/vexpress-v2p-ca9.dts
 create mode 100644 arch/arm/mach-vexpress/v2p-ca5s_ca9.c

[PATCH v3 1/5] ARM: versatile: Add missing ENDPROC to headsmp.S

[Pawel Moll]

Once the ENDPROC is in place, BSYM() in not longer necessary
to get correct pointer to versatile_secondary_startup().

Signed-off-by: Pawel Moll <pawel.moll@arm.com>
---
 arch/arm/mach-realview/platsmp.c  |    3 +--
 arch/arm/mach-vexpress/platsmp.c  |    4 +---
 arch/arm/plat-versatile/headsmp.S |    1 +
 3 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-realview/platsmp.c b/arch/arm/mach-realview/platsmp.c
index e83c654..17c878d 100644
--- a/arch/arm/mach-realview/platsmp.c
+++ b/arch/arm/mach-realview/platsmp.c
@@ -17,7 +17,6 @@
 #include <asm/hardware/gic.h>
 #include <asm/mach-types.h>
 #include <asm/smp_scu.h>
-#include <asm/unified.h>
 
 #include <mach/board-eb.h>
 #include <mach/board-pb11mp.h>
@@ -75,6 +74,6 @@ void __init platform_smp_prepare_cpus(unsigned int max_cpus)
 	 * until it receives a soft interrupt, and then the
 	 * secondary CPU branches to this address.
 	 */
-	__raw_writel(BSYM(virt_to_phys(versatile_secondary_startup)),
+	__raw_writel(virt_to_phys(versatile_secondary_startup),
 		     __io_address(REALVIEW_SYS_FLAGSSET));
 }
diff --git a/arch/arm/mach-vexpress/platsmp.c b/arch/arm/mach-vexpress/platsmp.c
index 2b5f7ac..124ffb1 100644
--- a/arch/arm/mach-vexpress/platsmp.c
+++ b/arch/arm/mach-vexpress/platsmp.c
@@ -13,8 +13,6 @@
 #include <linux/smp.h>
 #include <linux/io.h>
 
-#include <asm/unified.h>
-
 #include <mach/motherboard.h>
 #define V2M_PA_CS7 0x10000000
 
@@ -46,6 +44,6 @@ void __init platform_smp_prepare_cpus(unsigned int max_cpus)
 	 * secondary CPU branches to this address.
 	 */
 	writel(~0, MMIO_P2V(V2M_SYS_FLAGSCLR));
-	writel(BSYM(virt_to_phys(versatile_secondary_startup)),
+	writel(virt_to_phys(versatile_secondary_startup),
 		MMIO_P2V(V2M_SYS_FLAGSSET));
 }
diff --git a/arch/arm/plat-versatile/headsmp.S b/arch/arm/plat-versatile/headsmp.S
index d397a1f..dd703ef 100644
--- a/arch/arm/plat-versatile/headsmp.S
+++ b/arch/arm/plat-versatile/headsmp.S
@@ -38,3 +38,4 @@ pen:	ldr	r7, [r6]
 	.align
 1:	.long	.
 	.long	pen_release
+ENDPROC(versatile_secondary_startup)
-- 
1.6.3.3

[PATCH v3 2/5] ARM: vexpress: Get rid of MMIO_P2V

[Pawel Moll]

This patch gets rid of the MMIO_P2V and __MMPIO_P2V macros,
defining constant virtual base for motherboard and tile
peripherals instead.

Additionally, in preparation for the new motherboard memory
map, the motherboard peripherals are using base pointers
calculated in runtime, instead of compile-time calculated
values.

Signed-off-by: Pawel Moll <pawel.moll@arm.com>
---
 arch/arm/include/asm/hardware/arm_timer.h         |    5 ++
 arch/arm/mach-vexpress/core.h                     |   11 +++-
 arch/arm/mach-vexpress/ct-ca9x4.c                 |   52 ++++------------
 arch/arm/mach-vexpress/include/mach/ct-ca9x4.h    |   13 ++---
 arch/arm/mach-vexpress/include/mach/motherboard.h |   52 ++++++++--------
 arch/arm/mach-vexpress/platsmp.c                  |    5 +-
 arch/arm/mach-vexpress/v2m.c                      |   68 ++++++++++++++-------
 7 files changed, 102 insertions(+), 104 deletions(-)

diff --git a/arch/arm/include/asm/hardware/arm_timer.h b/arch/arm/include/asm/hardware/arm_timer.h
index c0f4e7b..d6030ff 100644
--- a/arch/arm/include/asm/hardware/arm_timer.h
+++ b/arch/arm/include/asm/hardware/arm_timer.h
@@ -9,7 +9,12 @@
  *
  * Integrator AP has 16-bit timers, Integrator CP, Versatile and Realview
  * can have 16-bit or 32-bit selectable via a bit in the control register.
+ *
+ * Every SP804 contains two identical timers.
  */
+#define TIMER_1_BASE	0x00
+#define TIMER_2_BASE	0x20
+
 #define TIMER_LOAD	0x00			/* ACVR rw */
 #define TIMER_VALUE	0x04			/* ACVR ro */
 #define TIMER_CTRL	0x08			/* ACVR rw */
diff --git a/arch/arm/mach-vexpress/core.h b/arch/arm/mach-vexpress/core.h
index f439715..d3dd491 100644
--- a/arch/arm/mach-vexpress/core.h
+++ b/arch/arm/mach-vexpress/core.h
@@ -1,6 +1,3 @@
-#define __MMIO_P2V(x)	(((x) & 0xfffff) | (((x) & 0x0f000000) >> 4) | 0xf8000000)
-#define MMIO_P2V(x)	((void __iomem *)__MMIO_P2V(x))
-
 #define AMBA_DEVICE(name,busid,base,plat)	\
 struct amba_device name##_device = {		\
 	.dev		= {			\
@@ -17,3 +14,11 @@ struct amba_device name##_device = {		\
 	.irq		= IRQ_##base,		\
 	/* .dma		= DMA_##base,*/		\
 }
+
+/* 2MB large area for motherboard's peripherals static mapping */
+#define V2M_PERIPH 0xf8000000
+#define V2M_PERIPH_P2V(offset) ((void __iomem *)(V2M_PERIPH | (offset)))
+
+/* Tile's peripherals static mappings should start here */
+#define V2T_PERIPH 0xf8200000
+#define V2T_PERIPH_P2V(offset) ((void __iomem *)(V2T_PERIPH | (offset)))
diff --git a/arch/arm/mach-vexpress/ct-ca9x4.c b/arch/arm/mach-vexpress/ct-ca9x4.c
index 2b1e836..bfd3919 100644
--- a/arch/arm/mach-vexpress/ct-ca9x4.c
+++ b/arch/arm/mach-vexpress/ct-ca9x4.c
@@ -30,57 +30,26 @@
 
 #include <plat/clcd.h>
 
-#define V2M_PA_CS7	0x10000000
-
 static struct map_desc ct_ca9x4_io_desc[] __initdata = {
 	{
-		.virtual	= __MMIO_P2V(CT_CA9X4_MPIC),
-		.pfn		= __phys_to_pfn(CT_CA9X4_MPIC),
-		.length		= SZ_16K,
-		.type		= MT_DEVICE,
-	}, {
-		.virtual	= __MMIO_P2V(CT_CA9X4_SP804_TIMER),
-		.pfn		= __phys_to_pfn(CT_CA9X4_SP804_TIMER),
-		.length		= SZ_4K,
-		.type		= MT_DEVICE,
-	}, {
-		.virtual	= __MMIO_P2V(CT_CA9X4_L2CC),
-		.pfn		= __phys_to_pfn(CT_CA9X4_L2CC),
-		.length		= SZ_4K,
-		.type		= MT_DEVICE,
+		.virtual        = V2T_PERIPH,
+		.pfn            = __phys_to_pfn(CT_CA9X4_MPIC),
+		.length         = SZ_8K,
+		.type           = MT_DEVICE,
 	},
 };
 
 static void __init ct_ca9x4_map_io(void)
 {
-#ifdef CONFIG_LOCAL_TIMERS
-	twd_base = MMIO_P2V(A9_MPCORE_TWD);
-#endif
 	iotable_init(ct_ca9x4_io_desc, ARRAY_SIZE(ct_ca9x4_io_desc));
 }
 
 static void __init ct_ca9x4_init_irq(void)
 {
-	gic_init(0, 29, MMIO_P2V(A9_MPCORE_GIC_DIST),
-		 MMIO_P2V(A9_MPCORE_GIC_CPU));
-}
-
-#if 0
-static void __init ct_ca9x4_timer_init(void)
-{
-	writel(0, MMIO_P2V(CT_CA9X4_TIMER0) + TIMER_CTRL);
-	writel(0, MMIO_P2V(CT_CA9X4_TIMER1) + TIMER_CTRL);
-
-	sp804_clocksource_init(MMIO_P2V(CT_CA9X4_TIMER1), "ct-timer1");
-	sp804_clockevents_init(MMIO_P2V(CT_CA9X4_TIMER0), IRQ_CT_CA9X4_TIMER0,
-		"ct-timer0");
+	gic_init(0, 29, V2T_PERIPH_P2V(A9_MPCORE_GIC_DIST),
+		 V2T_PERIPH_P2V(A9_MPCORE_GIC_CPU));
 }
 
-static struct sys_timer ct_ca9x4_timer = {
-	.init	= ct_ca9x4_timer_init,
-};
-#endif
-
 static void ct_ca9x4_clcd_enable(struct clcd_fb *fb)
 {
 	v2m_cfg_write(SYS_CFG_MUXFPGA | SYS_CFG_SITE_DB1, 0);
@@ -193,6 +162,9 @@ static struct platform_device pmu_device = {
 
 static void __init ct_ca9x4_init_early(void)
 {
+#ifdef CONFIG_LOCAL_TIMERS
+	twd_base = V2T_PERIPH_P2V(A9_MPCORE_TWD);
+#endif
 	clkdev_add_table(lookups, ARRAY_SIZE(lookups));
 }
 
@@ -201,7 +173,7 @@ static void __init ct_ca9x4_init(void)
 	int i;
 
 #ifdef CONFIG_CACHE_L2X0
-	void __iomem *l2x0_base = MMIO_P2V(CT_CA9X4_L2CC);
+	void __iomem *l2x0_base = ioremap(CT_CA9X4_L2CC, SZ_4K);
 
 	/* set RAM latencies to 1 cycle for this core tile. */
 	writel(0, l2x0_base + L2X0_TAG_LATENCY_CTRL);
@@ -219,7 +191,7 @@ static void __init ct_ca9x4_init(void)
 #ifdef CONFIG_SMP
 static void ct_ca9x4_init_cpu_map(void)
 {
-	int i, ncores = scu_get_core_count(MMIO_P2V(A9_MPCORE_SCU));
+	int i, ncores = scu_get_core_count(V2T_PERIPH_P2V(A9_MPCORE_SCU));
 
 	if (ncores > nr_cpu_ids) {
 		pr_warn("SMP: %u cores greater than maximum (%u), clipping\n",
@@ -235,7 +207,7 @@ static void ct_ca9x4_init_cpu_map(void)
 
 static void ct_ca9x4_smp_enable(unsigned int max_cpus)
 {
-	scu_enable(MMIO_P2V(A9_MPCORE_SCU));
+	scu_enable(V2T_PERIPH_P2V(A9_MPCORE_SCU));
 }
 #endif
 
diff --git a/arch/arm/mach-vexpress/include/mach/ct-ca9x4.h b/arch/arm/mach-vexpress/include/mach/ct-ca9x4.h
index a34d3d4..8f962fb 100644
--- a/arch/arm/mach-vexpress/include/mach/ct-ca9x4.h
+++ b/arch/arm/mach-vexpress/include/mach/ct-ca9x4.h
@@ -22,14 +22,11 @@
 #define CT_CA9X4_SYSWDT		(0x1e007000)
 #define CT_CA9X4_L2CC		(0x1e00a000)
 
-#define CT_CA9X4_TIMER0		(CT_CA9X4_SP804_TIMER + 0x000)
-#define CT_CA9X4_TIMER1		(CT_CA9X4_SP804_TIMER + 0x020)
-
-#define A9_MPCORE_SCU		(CT_CA9X4_MPIC + 0x0000)
-#define A9_MPCORE_GIC_CPU	(CT_CA9X4_MPIC + 0x0100)
-#define A9_MPCORE_GIT		(CT_CA9X4_MPIC + 0x0200)
-#define A9_MPCORE_TWD		(CT_CA9X4_MPIC + 0x0600)
-#define A9_MPCORE_GIC_DIST	(CT_CA9X4_MPIC + 0x1000)
+#define A9_MPCORE_SCU		0x0000
+#define A9_MPCORE_GIC_CPU	0x0100
+#define A9_MPCORE_GIT		0x0200
+#define A9_MPCORE_TWD		0x0600
+#define A9_MPCORE_GIC_DIST	0x1000
 
 /*
  * Interrupts.  Those in {} are for AMBA devices
diff --git a/arch/arm/mach-vexpress/include/mach/motherboard.h b/arch/arm/mach-vexpress/include/mach/motherboard.h
index 0a3a375..b4c498c 100644
--- a/arch/arm/mach-vexpress/include/mach/motherboard.h
+++ b/arch/arm/mach-vexpress/include/mach/motherboard.h
@@ -39,33 +39,30 @@
 #define V2M_CF			(V2M_PA_CS7 + 0x0001a000)
 #define V2M_CLCD		(V2M_PA_CS7 + 0x0001f000)
 
-#define V2M_SYS_ID		(V2M_SYSREGS + 0x000)
-#define V2M_SYS_SW		(V2M_SYSREGS + 0x004)
-#define V2M_SYS_LED		(V2M_SYSREGS + 0x008)
-#define V2M_SYS_100HZ		(V2M_SYSREGS + 0x024)
-#define V2M_SYS_FLAGS		(V2M_SYSREGS + 0x030)
-#define V2M_SYS_FLAGSSET	(V2M_SYSREGS + 0x030)
-#define V2M_SYS_FLAGSCLR	(V2M_SYSREGS + 0x034)
-#define V2M_SYS_NVFLAGS		(V2M_SYSREGS + 0x038)
-#define V2M_SYS_NVFLAGSSET	(V2M_SYSREGS + 0x038)
-#define V2M_SYS_NVFLAGSCLR	(V2M_SYSREGS + 0x03c)
-#define V2M_SYS_MCI		(V2M_SYSREGS + 0x048)
-#define V2M_SYS_FLASH		(V2M_SYSREGS + 0x03c)
-#define V2M_SYS_CFGSW		(V2M_SYSREGS + 0x058)
-#define V2M_SYS_24MHZ		(V2M_SYSREGS + 0x05c)
-#define V2M_SYS_MISC		(V2M_SYSREGS + 0x060)
-#define V2M_SYS_DMA		(V2M_SYSREGS + 0x064)
-#define V2M_SYS_PROCID0		(V2M_SYSREGS + 0x084)
-#define V2M_SYS_PROCID1		(V2M_SYSREGS + 0x088)
-#define V2M_SYS_CFGDATA		(V2M_SYSREGS + 0x0a0)
-#define V2M_SYS_CFGCTRL		(V2M_SYSREGS + 0x0a4)
-#define V2M_SYS_CFGSTAT		(V2M_SYSREGS + 0x0a8)
-
-#define V2M_TIMER0		(V2M_TIMER01 + 0x000)
-#define V2M_TIMER1		(V2M_TIMER01 + 0x020)
-
-#define V2M_TIMER2		(V2M_TIMER23 + 0x000)
-#define V2M_TIMER3		(V2M_TIMER23 + 0x020)
+/*
+ * Offsets from SYSREGS base
+ */
+#define V2M_SYS_ID		0x000
+#define V2M_SYS_SW		0x004
+#define V2M_SYS_LED		0x008
+#define V2M_SYS_100HZ		0x024
+#define V2M_SYS_FLAGS		0x030
+#define V2M_SYS_FLAGSSET	0x030
+#define V2M_SYS_FLAGSCLR	0x034
+#define V2M_SYS_NVFLAGS		0x038
+#define V2M_SYS_NVFLAGSSET	0x038
+#define V2M_SYS_NVFLAGSCLR	0x03c
+#define V2M_SYS_MCI		0x048
+#define V2M_SYS_FLASH		0x03c
+#define V2M_SYS_CFGSW		0x058
+#define V2M_SYS_24MHZ		0x05c
+#define V2M_SYS_MISC		0x060
+#define V2M_SYS_DMA		0x064
+#define V2M_SYS_PROCID0		0x084
+#define V2M_SYS_PROCID1		0x088
+#define V2M_SYS_CFGDATA		0x0a0
+#define V2M_SYS_CFGCTRL		0x0a4
+#define V2M_SYS_CFGSTAT		0x0a8
 
 
 /*
@@ -117,6 +114,7 @@
 
 int v2m_cfg_write(u32 devfn, u32 data);
 int v2m_cfg_read(u32 devfn, u32 *data);
+void v2m_flags_set(u32 data);
 
 /*
  * Core tile IDs
diff --git a/arch/arm/mach-vexpress/platsmp.c b/arch/arm/mach-vexpress/platsmp.c
index 124ffb1..a1ed6d6 100644
--- a/arch/arm/mach-vexpress/platsmp.c
+++ b/arch/arm/mach-vexpress/platsmp.c
@@ -14,7 +14,6 @@
 #include <linux/io.h>
 
 #include <mach/motherboard.h>
-#define V2M_PA_CS7 0x10000000
 
 #include "core.h"
 
@@ -43,7 +42,5 @@ void __init platform_smp_prepare_cpus(unsigned int max_cpus)
 	 * until it receives a soft interrupt, and then the
 	 * secondary CPU branches to this address.
 	 */
-	writel(~0, MMIO_P2V(V2M_SYS_FLAGSCLR));
-	writel(virt_to_phys(versatile_secondary_startup),
-		MMIO_P2V(V2M_SYS_FLAGSSET));
+	v2m_flags_set(virt_to_phys(versatile_secondary_startup));
 }
diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index 1fafc32..0aa254a 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -39,29 +39,45 @@
 
 static struct map_desc v2m_io_desc[] __initdata = {
 	{
-		.virtual	= __MMIO_P2V(V2M_PA_CS7),
+		.virtual	= V2M_PERIPH,
 		.pfn		= __phys_to_pfn(V2M_PA_CS7),
 		.length		= SZ_128K,
 		.type		= MT_DEVICE,
 	},
 };
 
-static void __init v2m_timer_init(void)
+static void __iomem *v2m_sysreg_base;
+
+static void __init v2m_sysctl_init(void __iomem *base)
 {
 	u32 scctrl;
 
+	if (WARN_ON(!base))
+		return;
+
 	/* Select 1MHz TIMCLK as the reference clock for SP804 timers */
-	scctrl = readl(MMIO_P2V(V2M_SYSCTL + SCCTRL));
+	scctrl = readl(base + SCCTRL);
 	scctrl |= SCCTRL_TIMEREN0SEL_TIMCLK;
 	scctrl |= SCCTRL_TIMEREN1SEL_TIMCLK;
-	writel(scctrl, MMIO_P2V(V2M_SYSCTL + SCCTRL));
+	writel(scctrl, base + SCCTRL);
+}
 
-	writel(0, MMIO_P2V(V2M_TIMER0) + TIMER_CTRL);
-	writel(0, MMIO_P2V(V2M_TIMER1) + TIMER_CTRL);
+static void __init v2m_sp804_init(void __iomem *base, unsigned int irq)
+{
+	if (WARN_ON(!base || irq == NO_IRQ))
+		return;
+
+	writel(0, base + TIMER_1_BASE + TIMER_CTRL);
+	writel(0, base + TIMER_2_BASE + TIMER_CTRL);
 
-	sp804_clocksource_init(MMIO_P2V(V2M_TIMER1), "v2m-timer1");
-	sp804_clockevents_init(MMIO_P2V(V2M_TIMER0), IRQ_V2M_TIMER0,
-		"v2m-timer0");
+	sp804_clocksource_init(base + TIMER_2_BASE, "v2m-timer1");
+	sp804_clockevents_init(base + TIMER_1_BASE, irq, "v2m-timer0");
+}
+
+static void __init v2m_timer_init(void)
+{
+	v2m_sysctl_init(ioremap(V2M_SYSCTL, SZ_4K));
+	v2m_sp804_init(ioremap(V2M_TIMER01, SZ_4K), IRQ_V2M_TIMER0);
 }
 
 static struct sys_timer v2m_timer = {
@@ -81,14 +97,14 @@ int v2m_cfg_write(u32 devfn, u32 data)
 	devfn |= SYS_CFG_START | SYS_CFG_WRITE;
 
 	spin_lock(&v2m_cfg_lock);
-	val = readl(MMIO_P2V(V2M_SYS_CFGSTAT));
-	writel(val & ~SYS_CFG_COMPLETE, MMIO_P2V(V2M_SYS_CFGSTAT));
+	val = readl(v2m_sysreg_base + V2M_SYS_CFGSTAT);
+	writel(val & ~SYS_CFG_COMPLETE, v2m_sysreg_base + V2M_SYS_CFGSTAT);
 
-	writel(data, MMIO_P2V(V2M_SYS_CFGDATA));
-	writel(devfn, MMIO_P2V(V2M_SYS_CFGCTRL));
+	writel(data, v2m_sysreg_base +  V2M_SYS_CFGDATA);
+	writel(devfn, v2m_sysreg_base + V2M_SYS_CFGCTRL);
 
 	do {
-		val = readl(MMIO_P2V(V2M_SYS_CFGSTAT));
+		val = readl(v2m_sysreg_base + V2M_SYS_CFGSTAT);
 	} while (val == 0);
 	spin_unlock(&v2m_cfg_lock);
 
@@ -102,22 +118,28 @@ int v2m_cfg_read(u32 devfn, u32 *data)
 	devfn |= SYS_CFG_START;
 
 	spin_lock(&v2m_cfg_lock);
-	writel(0, MMIO_P2V(V2M_SYS_CFGSTAT));
-	writel(devfn, MMIO_P2V(V2M_SYS_CFGCTRL));
+	writel(0, v2m_sysreg_base + V2M_SYS_CFGSTAT);
+	writel(devfn, v2m_sysreg_base + V2M_SYS_CFGCTRL);
 
 	mb();
 
 	do {
 		cpu_relax();
-		val = readl(MMIO_P2V(V2M_SYS_CFGSTAT));
+		val = readl(v2m_sysreg_base + V2M_SYS_CFGSTAT);
 	} while (val == 0);
 
-	*data = readl(MMIO_P2V(V2M_SYS_CFGDATA));
+	*data = readl(v2m_sysreg_base + V2M_SYS_CFGDATA);
 	spin_unlock(&v2m_cfg_lock);
 
 	return !!(val & SYS_CFG_ERR);
 }
 
+void __init v2m_flags_set(u32 data)
+{
+	writel(~0, v2m_sysreg_base + V2M_SYS_FLAGSCLR);
+	writel(data, v2m_sysreg_base + V2M_SYS_FLAGSSET);
+}
+
 
 static struct resource v2m_pcie_i2c_resource = {
 	.start	= V2M_SERIAL_BUS_PCI,
@@ -203,7 +225,7 @@ static struct platform_device v2m_usb_device = {
 
 static void v2m_flash_set_vpp(struct platform_device *pdev, int on)
 {
-	writel(on != 0, MMIO_P2V(V2M_SYS_FLASH));
+	writel(on != 0, v2m_sysreg_base + V2M_SYS_FLASH);
 }
 
 static struct physmap_flash_data v2m_flash_data = {
@@ -257,7 +279,7 @@ static struct platform_device v2m_cf_device = {
 
 static unsigned int v2m_mmci_status(struct device *dev)
 {
-	return readl(MMIO_P2V(V2M_SYS_MCI)) & (1 << 0);
+	return readl(v2m_sysreg_base + V2M_SYS_MCI) & (1 << 0);
 }
 
 static struct mmci_platform_data v2m_mmci_data = {
@@ -370,7 +392,7 @@ static void __init v2m_init_early(void)
 {
 	ct_desc->init_early();
 	clkdev_add_table(v2m_lookups, ARRAY_SIZE(v2m_lookups));
-	versatile_sched_clock_init(MMIO_P2V(V2M_SYS_24MHZ), 24000000);
+	versatile_sched_clock_init(v2m_sysreg_base + V2M_SYS_24MHZ, 24000000);
 }
 
 static void v2m_power_off(void)
@@ -399,7 +421,8 @@ static void __init v2m_populate_ct_desc(void)
 	u32 current_tile_id;
 
 	ct_desc = NULL;
-	current_tile_id = readl(MMIO_P2V(V2M_SYS_PROCID0)) & V2M_CT_ID_MASK;
+	current_tile_id = readl(v2m_sysreg_base + V2M_SYS_PROCID0)
+				& V2M_CT_ID_MASK;
 
 	for (i = 0; i < ARRAY_SIZE(ct_descs) && !ct_desc; ++i)
 		if (ct_descs[i]->id == current_tile_id)
@@ -413,6 +436,7 @@ static void __init v2m_populate_ct_desc(void)
 static void __init v2m_map_io(void)
 {
 	iotable_init(v2m_io_desc, ARRAY_SIZE(v2m_io_desc));
+	v2m_sysreg_base = V2M_PERIPH_P2V(V2M_SYSREGS);
 	v2m_populate_ct_desc();
 	ct_desc->map_io();
 }
-- 
1.6.3.3

Re: [PATCH v3 2/5] ARM: vexpress: Get rid of MMIO_P2V

[Arnd Bergmann]

On Tuesday 29 November 2011, Pawel Moll wrote:
> @@ -1,6 +1,3 @@
> -#define __MMIO_P2V(x)  (((x) & 0xfffff) | (((x) & 0x0f000000) >> 4) | 0xf8000000)
> -#define MMIO_P2V(x)    ((void __iomem *)__MMIO_P2V(x))
> -
...
> +
> +/* 2MB large area for motherboard's peripherals static mapping */
> +#define V2M_PERIPH 0xf8000000
> +#define V2M_PERIPH_P2V(offset) ((void __iomem *)(V2M_PERIPH | (offset)))
> +
> +/* Tile's peripherals static mappings should start here */
> +#define V2T_PERIPH 0xf8200000
> +#define V2T_PERIPH_P2V(offset) ((void __iomem *)(V2T_PERIPH | (offset)))

I think it would be even better if you could express the same with
pointer arithmetic instead of the macro, like:

#define V2M_PERIPH ((void __iomem *)0xf8000000)
#define V2T_PERIPH ((void __iomem *)0xf8200000)

and then instead of 

+       gic_init(0, 29, V2T_PERIPH_P2V(A9_MPCORE_GIC_DIST),
+                V2T_PERIPH_P2V(A9_MPCORE_GIC_CPU));

do 

+       gic_init(0, 29, V2T_PERIPH + A9_MPCORE_GIC_DIST,
+                V2T_PERIPH + A9_MPCORE_GIC_CPU);

and so on. This ends up being more readable IMHO because it
means you don't have to know what the macro does.

	Arnd

Re: [PATCH v3 2/5] ARM: vexpress: Get rid of MMIO_P2V

[Pawel Moll]

On Tue, 2011-11-29 at 21:15 +0000, Arnd Bergmann wrote:
> On Tuesday 29 November 2011, Pawel Moll wrote:
> > @@ -1,6 +1,3 @@
> > -#define __MMIO_P2V(x)  (((x) & 0xfffff) | (((x) & 0x0f000000) >> 4) | 0xf8000000)
> > -#define MMIO_P2V(x)    ((void __iomem *)__MMIO_P2V(x))
> > -
> ...
> > +
> > +/* 2MB large area for motherboard's peripherals static mapping */
> > +#define V2M_PERIPH 0xf8000000
> > +#define V2M_PERIPH_P2V(offset) ((void __iomem *)(V2M_PERIPH | (offset)))
> > +
> > +/* Tile's peripherals static mappings should start here */
> > +#define V2T_PERIPH 0xf8200000
> > +#define V2T_PERIPH_P2V(offset) ((void __iomem *)(V2T_PERIPH | (offset)))
> 
> I think it would be even better if you could express the same with
> pointer arithmetic instead of the macro, like:
> 
> #define V2M_PERIPH ((void __iomem *)0xf8000000)
> #define V2T_PERIPH ((void __iomem *)0xf8200000)
> 
> and then instead of 
> 
> +       gic_init(0, 29, V2T_PERIPH_P2V(A9_MPCORE_GIC_DIST),
> +                V2T_PERIPH_P2V(A9_MPCORE_GIC_CPU));
> 
> do 
> 
> +       gic_init(0, 29, V2T_PERIPH + A9_MPCORE_GIC_DIST,
> +                V2T_PERIPH + A9_MPCORE_GIC_CPU);
> 
> and so on. This ends up being more readable IMHO because it
> means you don't have to know what the macro does.

I wouldn't mind that, it's just that the V2M_PERIPH is also used in the
map_desc:

static struct map_desc v2m_io_desc[] __initdata = {
        {
                .virtual        = V2M_PERIPH,

and as the .virtual is unsigned long I'd need a cast in one place or the
other.

My best hope is that once Nico's "ioremap optimization" is pulled
(http://thread.gmane.org/gmane.linux.ports.arm.kernel/140974), I'll be
able to replace the _P2V macros with ioremap()s.

Cheers!

Paweł



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 2/5] ARM: vexpress: Get rid of MMIO_P2V

[Arnd Bergmann]

On Wednesday 30 November 2011, Pawel Moll wrote:
> > and so on. This ends up being more readable IMHO because it
> > means you don't have to know what the macro does.
> 
> I wouldn't mind that, it's just that the V2M_PERIPH is also used in the
> map_desc:
> 
> static struct map_desc v2m_io_desc[] __initdata = {
>         {
>                 .virtual        = V2M_PERIPH,
> 
> and as the .virtual is unsigned long I'd need a cast in one place or the
> other.

I have patches for other platforms to do the same conversion and
add the cast here, but also plan to change the way that I/O mappings
are done in the long run, you have to specify the virtual address
as __iomem* instead of an integer anyway.

> My best hope is that once Nico's "ioremap optimization" is pulled
> (http://thread.gmane.org/gmane.linux.ports.arm.kernel/140974), I'll be
> able to replace the _P2V macros with ioremap()s.

Yes.

	Arnd

Re: [PATCH v3 2/5] ARM: vexpress: Get rid of MMIO_P2V

[Pawel Moll]

On Wed, 2011-11-30 at 13:48 +0000, Arnd Bergmann wrote:
> On Wednesday 30 November 2011, Pawel Moll wrote:
> > > and so on. This ends up being more readable IMHO because it
> > > means you don't have to know what the macro does.
> > 
> > I wouldn't mind that, it's just that the V2M_PERIPH is also used in the
> > map_desc:
> > 
> > static struct map_desc v2m_io_desc[] __initdata = {
> >         {
> >                 .virtual        = V2M_PERIPH,
> > 
> > and as the .virtual is unsigned long I'd need a cast in one place or the
> > other.
> 
> I have patches for other platforms to do the same conversion and
> add the cast here, but also plan to change the way that I/O mappings
> are done in the long run, you have to specify the virtual address
> as __iomem* instead of an integer anyway.

Fine, in this case I'll do the same.

Cheers!

Paweł



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3 3/5] ARM: vexpress: Add DT support in v2m

[Pawel Moll]

This patch provides hooks for DT-based tile machine implementations
and adds Device Tree description for the motherboard.

Signed-off-by: Pawel Moll <pawel.moll@arm.com>
---
 Documentation/devicetree/bindings/arm/vexpress.txt |  108 +++++++++++
 arch/arm/boot/dts/vexpress-v2m.dtsi                |  195 ++++++++++++++++++++
 arch/arm/mach-vexpress/Kconfig                     |    6 +
 arch/arm/mach-vexpress/core.h                      |   10 +
 arch/arm/mach-vexpress/include/mach/motherboard.h  |    6 +
 arch/arm/mach-vexpress/v2m.c                       |  125 +++++++++++++
 6 files changed, 450 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/vexpress.txt
 create mode 100644 arch/arm/boot/dts/vexpress-v2m.dtsi

diff --git a/Documentation/devicetree/bindings/arm/vexpress.txt b/Documentation/devicetree/bindings/arm/vexpress.txt
new file mode 100644
index 0000000..1c57844
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/vexpress.txt
@@ -0,0 +1,108 @@
+ARM Versatile Express boards family
+-----------------------------------
+
+ARM's Versatile Express platform consists of a motherboard and one
+or more daughterboards (tiles). The motherboard provides a set of
+peripherals. Processor and RAM "live" on the tiles.
+
+The motherboard and each core tile should be described by a separate
+Device Tree source file, with the tile's description including
+the motherboard file using a /include/ directive. As the motherboard
+can be initialized in one of two different configurations ("memory
+maps"), care must be taken to include the correct one.
+
+Required properties in the root node:
+- compatible value:
+	compatible = "arm,vexpress-<model>";
+  where <model> is the full tile model name (as used in the tiles's
+  Technical Reference Manual):
+  - for Coretile Express A5x2 (V2P-CA5s):
+	compatible = "arm,vexpress-v2p-ca5s";
+  - Coretile Express A9x4 (V2P-CA9):
+	compatible = "arm,vexpress-v2p-ca9";
+
+Optional properties in the root node:
+- tile model name (use the same names as in the tile's Technical
+  Reference Manuals, eg. "V2P-CA5s")
+	model = "<model>";
+- tile's HBI number (unique ARM's board model ID, visible on the
+  PCB's silkscreen) in hexadecimal transcription:
+	arm,hbi = <0xhbi>
+  eg:
+  - for Coretile Express A5x2 (V2P-CA5s) HBI-0191:
+	arm,hbi = <0x191>;
+  - Coretile Express A9x4 (V2P-CA9) HBI-0225:
+	arm,hbi = <0x225>;
+
+The motherboard description file provides a single "motherboard" node
+using 2 address cells corresponding to the Static Memory Bus used
+between the motherboard and the tile. The first cell defines the Chip
+Select (CS) line number, the second cell address offset within the CS.
+All interrupt lines between the motherboard and the tile are active
+high and are described using single cell.
+
+Optional properties of the "motherboard" node:
+- motherboard's memory map variant:
+	arm,v2m-memory-map = "<name>";
+  where name is one of:
+  - "rs1" - for RS1 map (i.a. peripherals on CS3); this map is also
+            referred to as "ARM Cortex-A Series memory map":
+	arm,v2m-memory-map = "rs1";
+  When this property is missing, the motherboard is using the original
+  memory map (also known as the "Legacy memory map", primarily used
+  with the original CoreTile Express A9x4) with peripherals on CS7.
+
+Motherboard .dtsi files provide a set of labelled peripherals that
+can be used to obtain required phandle in the tile's "aliases" node:
+- UARTs, note that the numbers correspond to the physical connectors
+  on the motherboard's back panel:
+	v2m_serial0, v2m_serial1, v2m_serial2 and v2m_serial3
+- I2C controllers:
+	v2m_i2c_dvi and v2m_i2c_pcie
+- SP804 timers:
+	v2m_timer01 and v2m_timer23
+
+Current Linux implementation requires a "arm,v2m_timer" alias
+pointing at one of the motherboard's SP804 timers, if it is to be
+used as the system timer. This alias should be defined in the
+motherboard files.
+
+The tile description must define "ranges", "interrupt-map-mask" and
+"interrupt-map" properties to translate the motherboard's address
+and interrupt space into one used by the tile's processor.
+
+Abbreviated example:
+
+/dts-v1/;
+
+/include/ "skeleton.dtsi"
+
+/ {
+	model = "V2P-CA5s";
+	arm,hbi = <0x225>;
+	compatible = "arm,vexpress-v2p-ca5s";
+	interrupt-parent = <&gic>;
+
+	aliases {
+		serial0 = &v2m_serial0;
+	};
+
+	gic: interrupt-controller@2c001000 {
+		compatible = "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		#address-cells = <0>;
+		interrupt-controller;
+		reg = <0x2c001000 0x1000>,
+		      <0x2c000100 0x100>;
+	};
+
+	motherboard {
+		/* CS0 is visible at 0x08000000 */
+		ranges = <0 0 0x08000000 0x04000000>;
+		interrupt-map-mask = <0 0 63>;
+		/* Active high IRQ 0 is connected to GIC's SPI0 */
+		interrupt-map = <0 0 0 &gic 0 0 4>;
+	};
+};
+
+/include/ "vexpress-v2m-rs1.dtsi"
diff --git a/arch/arm/boot/dts/vexpress-v2m.dtsi b/arch/arm/boot/dts/vexpress-v2m.dtsi
new file mode 100644
index 0000000..0c3752b
--- /dev/null
+++ b/arch/arm/boot/dts/vexpress-v2m.dtsi
@@ -0,0 +1,195 @@
+/*
+ * ARM Ltd. Versatile Express
+ *
+ * Motherboard Express uATX
+ * V2M-P1
+ *
+ * HBI-0190D
+ *
+ * Original memory map ("Legacy memory map" in the board's
+ * Technical Reference Manual)
+ *
+ * WARNING! The hardware described in this file is independent from the
+ * RS1 variant (vexpress-v2m-rs1.dtsi), but there is a strong
+ * correspondence between the two configurations.
+ *
+ * TAKE CARE WHEN MAINTAINING THIS FILE TO PROPAGATE ANY RELEVANT
+ * CHANGES TO vexpress-v2m-rs1.dtsi!
+ */
+
+/ {
+	aliases {
+		arm,v2m_timer = &v2m_timer01;
+	};
+
+	motherboard {
+		compatible = "simple-bus";
+		#address-cells = <2>; /* SMB chipselect number and offset */
+		#size-cells = <1>;
+		#interrupt-cells = <1>;
+
+		flash@0,00000000 {
+			compatible = "arm,vexpress-flash", "cfi-flash";
+			reg = <0 0x00000000 0x04000000>,
+			      <1 0x00000000 0x04000000>;
+			bank-width = <4>;
+		};
+
+		psram@2,00000000 {
+			compatible = "mtd-ram";
+			reg = <2 0x00000000 0x02000000>;
+			bank-width = <4>;
+		};
+
+		ethernet@3,02000000 {
+			compatible = "smsc,lan9118", "smsc,lan9115";
+			reg = <3 0x02000000 0x10000>;
+			interrupts = <15>;
+			phy-mode = "mii";
+			reg-io-width = <4>;
+			smsc,irq-active-high;
+			smsc,irq-push-pull;
+		};
+
+		usb@3,03000000 {
+			compatible = "nxp,usb-isp1761";
+			reg = <3 0x03000000 0x20000>;
+			interrupts = <16>;
+			port1-otg;
+		};
+
+		iofpga@7,00000000 {
+			compatible = "arm,amba-bus", "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0 7 0 0x20000>;
+
+			sysreg@00000 {
+				compatible = "arm,vexpress-sysreg";
+				reg = <0x00000 0x1000>;
+			};
+
+			sysctl@01000 {
+				compatible = "arm,sp810", "arm,primecell";
+				reg = <0x01000 0x1000>;
+			};
+
+			/* PCI-E I2C bus */
+			v2m_i2c_pcie: i2c@02000 {
+				compatible = "arm,versatile-i2c";
+				reg = <0x02000 0x1000>;
+
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				pcie-switch@60 {
+					compatible = "idt,89hpes32h8";
+					reg = <0x60>;
+				};
+			};
+
+			aaci@04000 {
+				compatible = "arm,pl041", "arm,primecell";
+				reg = <0x04000 0x1000>;
+				interrupts = <11>;
+			};
+
+			mmci@05000 {
+				compatible = "arm,pl180", "arm,primecell";
+				reg = <0x05000 0x1000>;
+				interrupts = <9 10>;
+			};
+
+			kmi@06000 {
+				compatible = "arm,pl050", "arm,primecell";
+				reg = <0x06000 0x1000>;
+				interrupts = <12>;
+			};
+
+			kmi@07000 {
+				compatible = "arm,pl050", "arm,primecell";
+				reg = <0x07000 0x1000>;
+				interrupts = <13>;
+			};
+
+			v2m_serial0: uart@09000 {
+				compatible = "arm,pl011", "arm,primecell";
+				reg = <0x09000 0x1000>;
+				interrupts = <5>;
+			};
+
+			v2m_serial1: uart@0a000 {
+				compatible = "arm,pl011", "arm,primecell";
+				reg = <0x0a000 0x1000>;
+				interrupts = <6>;
+			};
+
+			v2m_serial2: uart@0b000 {
+				compatible = "arm,pl011", "arm,primecell";
+				reg = <0x0b000 0x1000>;
+				interrupts = <7>;
+			};
+
+			v2m_serial3: uart@0c000 {
+				compatible = "arm,pl011", "arm,primecell";
+				reg = <0x0c000 0x1000>;
+				interrupts = <8>;
+			};
+
+			wdt@0f000 {
+				compatible = "arm,sp805", "arm,primecell";
+				reg = <0x0f000 0x1000>;
+				interrupts = <0>;
+			};
+
+			v2m_timer01: timer@11000 {
+				compatible = "arm,sp804", "arm,primecell";
+				reg = <0x11000 0x1000>;
+				interrupts = <2>;
+			};
+
+			v2m_timer23: timer@12000 {
+				compatible = "arm,sp804", "arm,primecell";
+				reg = <0x12000 0x1000>;
+			};
+
+			/* DVI I2C bus */
+			v2m_i2c_dvi: i2c@16000 {
+				compatible = "arm,versatile-i2c";
+				reg = <0x16000 0x1000>;
+
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				dvi-transmitter@39 {
+					compatible = "sil,sii9022-tpi", "sil,sii9022";
+					reg = <0x39>;
+				};
+
+				dvi-transmitter@60 {
+					compatible = "sil,sii9022-cpi", "sil,sii9022";
+					reg = <0x60>;
+				};
+			};
+
+			rtc@17000 {
+				compatible = "arm,pl031", "arm,primecell";
+				reg = <0x17000 0x1000>;
+				interrupts = <4>;
+			};
+
+			compact-flash@1a000 {
+				compatible = "ata-generic";
+				reg = <0x1a000 0x100
+				       0x1a100 0xf00>;
+				reg-shift = <2>;
+			};
+
+			clcd@1f000 {
+				compatible = "arm,pl111", "arm,primecell";
+				reg = <0x1f000 0x1000>;
+				interrupts = <14>;
+			};
+		};
+	};
+};
diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
index 9311484..6a6fa22 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig
@@ -9,4 +9,10 @@ config ARCH_VEXPRESS_CA9X4
 	select ARM_ERRATA_751472
 	select ARM_ERRATA_753970
 
+config ARCH_VEXPRESS_DT
+	bool
+	select OF
+	help
+	  VE platform *requiring* Flattened Device Tree to boot.
+
 endmenu
diff --git a/arch/arm/mach-vexpress/core.h b/arch/arm/mach-vexpress/core.h
index d3dd491..1e329e0 100644
--- a/arch/arm/mach-vexpress/core.h
+++ b/arch/arm/mach-vexpress/core.h
@@ -22,3 +22,13 @@ struct amba_device name##_device = {		\
 /* Tile's peripherals static mappings should start here */
 #define V2T_PERIPH 0xf8200000
 #define V2T_PERIPH_P2V(offset) ((void __iomem *)(V2T_PERIPH | (offset)))
+
+#if defined(CONFIG_ARCH_VEXPRESS_DT)
+
+extern struct sys_timer v2m_dt_timer;
+
+void __init v2m_dt_map_io(void);
+void __init v2m_dt_init_early(void);
+struct of_dev_auxdata * __init v2m_dt_get_auxdata(void);
+
+#endif
diff --git a/arch/arm/mach-vexpress/include/mach/motherboard.h b/arch/arm/mach-vexpress/include/mach/motherboard.h
index b4c498c..31a9289 100644
--- a/arch/arm/mach-vexpress/include/mach/motherboard.h
+++ b/arch/arm/mach-vexpress/include/mach/motherboard.h
@@ -117,6 +117,12 @@ int v2m_cfg_read(u32 devfn, u32 *data);
 void v2m_flags_set(u32 data);
 
 /*
+ * Miscellaneous
+ */
+#define SYS_MISC_MASTERSITE	(1 << 14)
+#define SYS_PROCIDx_HBI_MASK	0xfff
+
+/*
  * Core tile IDs
  */
 #define V2M_CT_ID_CA9		0x0c000191
diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index 0aa254a..a8ea95a 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -6,6 +6,10 @@
 #include <linux/amba/mmci.h>
 #include <linux/io.h>
 #include <linux/init.h>
+#include <linux/of_address.h>
+#include <linux/of_fdt.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
 #include <linux/platform_device.h>
 #include <linux/ata_platform.h>
 #include <linux/smsc911x.h>
@@ -17,6 +21,7 @@
 
 #include <asm/mach-types.h>
 #include <asm/sizes.h>
+#include <asm/system.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
 #include <asm/mach/time.h>
@@ -474,3 +479,123 @@ MACHINE_START(VEXPRESS, "ARM-Versatile Express")
 	.timer		= &v2m_timer,
 	.init_machine	= v2m_init,
 MACHINE_END
+
+/*
+ * Notice that machine descriptions for the Device Tree "powered" tiles
+ * (DT_MACHINE_START macros) live in the corresponding *.c files.
+ */
+
+#if defined(CONFIG_ARCH_VEXPRESS_DT)
+
+static void __init v2m_dt_timer_init(void)
+{
+	struct device_node *node;
+	const char *path;
+	int err;
+
+	node = of_find_compatible_node(NULL, NULL, "arm,sp810");
+	v2m_sysctl_init(of_iomap(node, 0));
+
+	err = of_property_read_string(of_aliases, "arm,v2m_timer", &path);
+	if (WARN_ON(err))
+		return;
+	node = of_find_node_by_path(path);
+	v2m_sp804_init(of_iomap(node, 0), irq_of_parse_and_map(node, 0));
+}
+
+struct sys_timer v2m_dt_timer = {
+	.init	= v2m_dt_timer_init,
+};
+
+void __init v2m_dt_map_io(void)
+{
+	iotable_init(v2m_io_desc, ARRAY_SIZE(v2m_io_desc));
+}
+
+static struct clk_lookup v2m_dt_lookups[] = {
+	{	/* AMBA bus clock */
+		.con_id		= "apb_pclk",
+		.clk		= &dummy_apb_pclk,
+	}, {	/* SP804 timers */
+		.dev_id		= "sp804",
+		.con_id		= "v2m-timer0",
+		.clk		= &v2m_sp804_clk,
+	}, {	/* SP804 timers */
+		.dev_id		= "sp804",
+		.con_id		= "v2m-timer1",
+		.clk		= &v2m_sp804_clk,
+	}, {	/* PL180 MMCI */
+		.dev_id		= "mb:mmci", /* 10005000.mmci */
+		.clk		= &osc2_clk,
+	}, {	/* PL050 KMI0 */
+		.dev_id		= "10006000.kmi",
+		.clk		= &osc2_clk,
+	}, {	/* PL050 KMI1 */
+		.dev_id		= "10007000.kmi",
+		.clk		= &osc2_clk,
+	}, {	/* PL011 UART0 */
+		.dev_id		= "10009000.uart",
+		.clk		= &osc2_clk,
+	}, {	/* PL011 UART1 */
+		.dev_id		= "1000a000.uart",
+		.clk		= &osc2_clk,
+	}, {	/* PL011 UART2 */
+		.dev_id		= "1000b000.uart",
+		.clk		= &osc2_clk,
+	}, {	/* PL011 UART3 */
+		.dev_id		= "1000c000.uart",
+		.clk		= &osc2_clk,
+	}, {	/* SP805 WDT */
+		.dev_id		= "1000f000.wdt",
+		.clk		= &v2m_ref_clk,
+	}, {	/* PL111 CLCD */
+		.dev_id		= "1001f000.clcd",
+		.clk		= &osc1_clk,
+	},
+};
+
+void __init v2m_dt_init_early(void)
+{
+	struct device_node *node;
+	const __be32 *reg;
+	u32 dt_hbi;
+
+	node = of_find_compatible_node(NULL, NULL, "arm,vexpress-sysreg");
+	reg = of_get_property(node, "reg", NULL);
+	if (WARN_ON(!reg))
+		return;
+
+	v2m_sysreg_base = V2M_PERIPH_P2V(be32_to_cpup(reg));
+
+	/* Confirm board type against DT property, if available */
+	if (of_property_read_u32(allnodes, "arm,hbi", &dt_hbi) == 0) {
+		u32 misc = readl(v2m_sysreg_base + V2M_SYS_MISC);
+		u32 id = readl(v2m_sysreg_base + (misc & SYS_MISC_MASTERSITE ?
+				V2M_SYS_PROCID1 : V2M_SYS_PROCID0));
+		u32 hbi = id & SYS_PROCIDx_HBI_MASK;
+
+		if (WARN_ON(dt_hbi != hbi))
+			pr_warning("vexpress: DT HBI (%x) is not matching "
+					"hardware (%x)!\n", dt_hbi, hbi);
+	}
+
+	clkdev_add_table(v2m_dt_lookups, ARRAY_SIZE(v2m_dt_lookups));
+	versatile_sched_clock_init(v2m_sysreg_base + V2M_SYS_24MHZ, 24000000);
+
+	pm_power_off = v2m_power_off;
+	arm_pm_restart = v2m_restart;
+}
+
+static struct of_dev_auxdata v2m_dt_auxdata_lookup[] __initdata = {
+	OF_DEV_AUXDATA("arm,vexpress-flash", V2M_NOR0, "physmap-flash",
+			&v2m_flash_data),
+	OF_DEV_AUXDATA("arm,primecell", V2M_MMCI, "mb:mmci", &v2m_mmci_data),
+	{}
+};
+
+struct of_dev_auxdata * __init v2m_dt_get_auxdata(void)
+{
+	return v2m_dt_auxdata_lookup;
+}
+
+#endif
-- 
1.6.3.3

Re: [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m

[Arnd Bergmann]

On Tuesday 29 November 2011, Pawel Moll wrote:
> +                       compact-flash@1a000 {
> +                               compatible = "ata-generic";
> +                               reg = <0x1a000 0x100
> +                                      0x1a100 0xf00>;
> +                               reg-shift = <2>;
> +                       };

Shouldn't there also be a more specific "compatible" value, in case we have
to detect this CF slot for some reason?

Is there actually no interrupt?

	Arnd

Re: [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m

[Pawel Moll]

On Tue, 2011-11-29 at 21:19 +0000, Arnd Bergmann wrote:
> On Tuesday 29 November 2011, Pawel Moll wrote:
> > +                       compact-flash@1a000 {
> > +                               compatible = "ata-generic";
> > +                               reg = <0x1a000 0x100
> > +                                      0x1a100 0xf00>;
> > +                               reg-shift = <2>;
> > +                       };
> 
> Shouldn't there also be a more specific "compatible" value, in case we have
> to detect this CF slot for some reason?

It was the compatible-value-of-choice in
"drivers/ata/pata_of_platform.c", unfortunately undocumented - as I have
just realized - in the "Documentation/devicetree/bindings"...

> Is there actually no interrupt?

No, polling mode only. And yes, it works ;-)

Cheers!

Paweł



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m

[Arnd Bergmann]

On Wednesday 30 November 2011, Pawel Moll wrote:
> 
> On Tue, 2011-11-29 at 21:19 +0000, Arnd Bergmann wrote:
> > On Tuesday 29 November 2011, Pawel Moll wrote:
> > > +                       compact-flash@1a000 {
> > > +                               compatible = "ata-generic";
> > > +                               reg = <0x1a000 0x100
> > > +                                      0x1a100 0xf00>;
> > > +                               reg-shift = <2>;
> > > +                       };
> > 
> > Shouldn't there also be a more specific "compatible" value, in case we have
> > to detect this CF slot for some reason?
> 
> It was the compatible-value-of-choice in
> "drivers/ata/pata_of_platform.c", unfortunately undocumented - as I have
> just realized - in the "Documentation/devicetree/bindings"...

You should certainly *also* have "ata-generic" in there as the value
that is used by the existing driver, but it usually makes sense to have
a more specific value in addition, just as a precaution for the future,
in case that the specific hardware is not entirely identical to all others
and we have to do a separate workaround.

> > Is there actually no interrupt?
> 
> No, polling mode only. And yes, it works ;-)

Fascinating

	Arnd

Re: [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m

[Pawel Moll]

On Wed, 2011-11-30 at 13:34 +0000, Arnd Bergmann wrote:
> On Wednesday 30 November 2011, Pawel Moll wrote:
> > 
> > On Tue, 2011-11-29 at 21:19 +0000, Arnd Bergmann wrote:
> > > On Tuesday 29 November 2011, Pawel Moll wrote:
> > > > +                       compact-flash@1a000 {
> > > > +                               compatible = "ata-generic";
> > > > +                               reg = <0x1a000 0x100
> > > > +                                      0x1a100 0xf00>;
> > > > +                               reg-shift = <2>;
> > > > +                       };
> > > 
> > > Shouldn't there also be a more specific "compatible" value, in case we have
> > > to detect this CF slot for some reason?
> > 
> > It was the compatible-value-of-choice in
> > "drivers/ata/pata_of_platform.c", unfortunately undocumented - as I have
> > just realized - in the "Documentation/devicetree/bindings"...
> 
> You should certainly *also* have "ata-generic" in there as the value
> that is used by the existing driver, but it usually makes sense to have
> a more specific value in addition, just as a precaution for the future,
> in case that the specific hardware is not entirely identical to all others
> and we have to do a separate workaround.

Ok, as the actual "interface hardware" is a custom design for VE, I'll
make it:

	compatible = "arm,vexpress-cf", "ata-generic";

Does it make sense?

Cheers!

Paweł



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m

[Arnd Bergmann]

On Wednesday 30 November 2011, Pawel Moll wrote:
> Ok, as the actual "interface hardware" is a custom design for VE, I'll
> make it:
> 
>         compatible = "arm,vexpress-cf", "ata-generic";
> 
> Does it make sense?
> 

Yes, very good.

	Arnd

Re: [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m

[Dave Martin]

On Tue, Nov 29, 2011 at 03:11:11PM +0000, Pawel Moll wrote:
> This patch provides hooks for DT-based tile machine implementations
> and adds Device Tree description for the motherboard.

[...]

> +config ARCH_VEXPRESS_DT
> +	bool
> +	select OF
> +	help
> +	  VE platform *requiring* Flattened Device Tree to boot.
> +

Now that a person may fail to boot on a supported board simply due to
failing to supply a device tree, it may be a good idea to have a more
helpful panic message for that situation, perhaps something like the
following.

If you don't think this fits in this series, I can always follow up 
later.

Cheers
---Dave


diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index 6965f64..9dda482 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -434,8 +434,11 @@ static void __init v2m_populate_ct_desc(void)
 			ct_desc = ct_descs[i];
 
 	if (!ct_desc)
-		panic("vexpress: failed to populate core tile description "
-		      "for tile ID 0x%8x\n", current_tile_id);
+		panic("vexpress: this kernel does not support core tile ID "
+		      "0x%08x when booting via ATAGs.\n"
+		      "You may need a device tree blob or a different kernel "
+		      "to boot on this board.\n",
+		      current_tile_id);
 }
 
 static void __init v2m_map_io(void)

Re: [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m

[Pawel Moll]

On Wed, 2011-11-30 at 15:58 +0000, Dave Martin wrote:
> Now that a person may fail to boot on a supported board simply due to
> failing to supply a device tree, it may be a good idea to have a more
> helpful panic message for that situation, perhaps something like the
> following.
> 
> If you don't think this fits in this series, I can always follow up 
> later.
> 
> diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
> index 6965f64..9dda482 100644
> --- a/arch/arm/mach-vexpress/v2m.c
> +++ b/arch/arm/mach-vexpress/v2m.c
> @@ -434,8 +434,11 @@ static void __init v2m_populate_ct_desc(void)
>  			ct_desc = ct_descs[i];
>  
>  	if (!ct_desc)
> -		panic("vexpress: failed to populate core tile description "
> -		      "for tile ID 0x%8x\n", current_tile_id);
> +		panic("vexpress: this kernel does not support core tile ID "
> +		      "0x%08x when booting via ATAGs.\n"
> +		      "You may need a device tree blob or a different kernel "
> +		      "to boot on this board.\n",
> +		      current_tile_id);
>  }
>  
>  static void __init v2m_map_io(void)
> 

No, that's cool with me, will add that. Thanks!

Pawel

Re: [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m

[Dave Martin]

On Wed, Nov 30, 2011 at 06:46:19PM +0000, Pawel Moll wrote:
> On Wed, 2011-11-30 at 15:58 +0000, Dave Martin wrote:
> > Now that a person may fail to boot on a supported board simply due to
> > failing to supply a device tree, it may be a good idea to have a more
> > helpful panic message for that situation, perhaps something like the
> > following.
> > 
> > If you don't think this fits in this series, I can always follow up 
> > later.
> > 
> > diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
> > index 6965f64..9dda482 100644
> > --- a/arch/arm/mach-vexpress/v2m.c
> > +++ b/arch/arm/mach-vexpress/v2m.c
> > @@ -434,8 +434,11 @@ static void __init v2m_populate_ct_desc(void)
> >  			ct_desc = ct_descs[i];
> >  
> >  	if (!ct_desc)
> > -		panic("vexpress: failed to populate core tile description "
> > -		      "for tile ID 0x%8x\n", current_tile_id);
> > +		panic("vexpress: this kernel does not support core tile ID "
> > +		      "0x%08x when booting via ATAGs.\n"
> > +		      "You may need a device tree blob or a different kernel "
> > +		      "to boot on this board.\n",
> > +		      current_tile_id);
> >  }
> >  
> >  static void __init v2m_map_io(void)
> > 
> 
> No, that's cool with me, will add that. Thanks!

I just discovered that Documentation/CodingStyle recommends not to split printk
strings onto multiple lines, for easier grepping.  Sounds like sensible advice,
so maybe just split at "\n":

> > +		panic("vexpress: this kernel does not support core tile ID 0x%08x when booting via ATAGs.\n" 
> > +		      "You may need a device tree blob or a different kernel to boot on this board.\n",
> > +		      current_tile_id);

Cheers
---Dave

Re: [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m

[Dave Martin]

On Tue, Nov 29, 2011 at 03:11:11PM +0000, Pawel Moll wrote:
> This patch provides hooks for DT-based tile machine implementations
> and adds Device Tree description for the motherboard.

[...]

> +static struct of_dev_auxdata v2m_dt_auxdata_lookup[] __initdata = {
> +	OF_DEV_AUXDATA("arm,vexpress-flash", V2M_NOR0, "physmap-flash",
> +			&v2m_flash_data),
> +	OF_DEV_AUXDATA("arm,primecell", V2M_MMCI, "mb:mmci", &v2m_mmci_data),
> +	{}

Are we missing some AUXDATA here?  I thought we had a lot more drivers
which are not converted to OF, such as ambakmi and many more.

I notice some things explicitly failing, e.g.:

clcd-pl11x: probe of 10020000.clcd failed with error -22
clcd-pl11x: probe of 1001f000.clcd failed with error -22

...I haven't tracked down exactly what is going on here, yet.

Cheers
---Dave

Re: [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m

[Pawel Moll]

On Mon, 2011-12-05 at 16:25 +0000, Dave Martin wrote:
> On Tue, Nov 29, 2011 at 03:11:11PM +0000, Pawel Moll wrote:
> > This patch provides hooks for DT-based tile machine implementations
> > and adds Device Tree description for the motherboard.
> 
> [...]
> 
> > +static struct of_dev_auxdata v2m_dt_auxdata_lookup[] __initdata = {
> > +	OF_DEV_AUXDATA("arm,vexpress-flash", V2M_NOR0, "physmap-flash",
> > +			&v2m_flash_data),
> > +	OF_DEV_AUXDATA("arm,primecell", V2M_MMCI, "mb:mmci", &v2m_mmci_data),
> > +	{}
> 
> Are we missing some AUXDATA here?  I thought we had a lot more drivers
> which are not converted to OF, such as ambakmi and many more.

No, as Rob suggested I removed all the devices that don't need platform
data and were there only for the clocks sake and created explicit lookup
tables for them. The ambakmi you have mentioned doesn't take any
platform data, just the resources and clock, so it works fine.

> I notice some things explicitly failing, e.g.:
> 
> clcd-pl11x: probe of 10020000.clcd failed with error -22
> clcd-pl11x: probe of 1001f000.clcd failed with error -22
> 
> ...I haven't tracked down exactly what is going on here, yet.

CLCD is the only device that doesn't work right now. I've skipped it
intentionally as it was configured in a non-trivial way on a per-tile
basis (and passing two separate sets of auxdata is tricky) and the work
on bindings for the driver is ongoing.

Probably this should be mentioned in the patch description. Will do.

Cheers!

Paweł



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support

[Pawel Moll]

This patch adds support for RS1 memory map based Versatile Express
motherboard.

Signed-off-by: Pawel Moll <pawel.moll@arm.com>
---
 arch/arm/boot/dts/vexpress-v2m-rs1.dtsi           |  196 +++++++++++++++++++++
 arch/arm/mach-vexpress/Kconfig                    |    8 +
 arch/arm/mach-vexpress/Makefile.boot              |    6 +
 arch/arm/mach-vexpress/include/mach/debug-macro.S |   37 ++++-
 arch/arm/mach-vexpress/include/mach/uncompress.h  |   13 ++-
 arch/arm/mach-vexpress/v2m.c                      |   64 +++++++-
 6 files changed, 318 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/boot/dts/vexpress-v2m-rs1.dtsi

diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
new file mode 100644
index 0000000..a75ebc3
--- /dev/null
+++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
@@ -0,0 +1,196 @@
+/*
+ * ARM Ltd. Versatile Express
+ *
+ * Motherboard Express uATX
+ * V2M-P1
+ *
+ * HBI-0190D
+ *
+ * RS1 memory map ("ARM Cortex-A Series memory map" in the board's
+ * Technical Reference Manual)
+ *
+ * WARNING! The hardware described in this file is independent from the
+ * original variant (vexpress-v2m.dtsi), but there is a strong
+ * correspondence between the two configurations.
+ *
+ * TAKE CARE WHEN MAINTAINING THIS FILE TO PROPAGATE ANY RELEVANT
+ * CHANGES TO vexpress-v2m.dtsi!
+ */
+
+/ {
+	aliases {
+		arm,v2m_timer = &v2m_timer01;
+	};
+
+	motherboard {
+		compatible = "simple-bus";
+		arm,v2m-memory-map = "rs1";
+		#address-cells = <2>; /* SMB chipselect number and offset */
+		#size-cells = <1>;
+		#interrupt-cells = <1>;
+
+		flash@0,00000000 {
+			compatible = "arm,vexpress-flash", "cfi-flash";
+			reg = <0 0x00000000 0x04000000>,
+			      <4 0x00000000 0x04000000>;
+			bank-width = <4>;
+		};
+
+		psram@1,00000000 {
+			compatible = "mtd-ram";
+			reg = <1 0x00000000 0x02000000>;
+			bank-width = <4>;
+		};
+
+		ethernet@2,02000000 {
+			compatible = "smsc,lan9118", "smsc,lan9115";
+			reg = <2 0x02000000 0x10000>;
+			interrupts = <15>;
+			phy-mode = "mii";
+			reg-io-width = <4>;
+			smsc,irq-active-high;
+			smsc,irq-push-pull;
+		};
+
+		usb@2,03000000 {
+			compatible = "nxp,usb-isp1761";
+			reg = <2 0x03000000 0x20000>;
+			interrupts = <16>;
+			port1-otg;
+		};
+
+		iofpga@3,00000000 {
+			compatible = "arm,amba-bus", "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0 3 0 0x200000>;
+
+			sysreg@010000 {
+				compatible = "arm,vexpress-sysreg";
+				reg = <0x010000 0x1000>;
+			};
+
+			sysctl@020000 {
+				compatible = "arm,sp810", "arm,primecell";
+				reg = <0x020000 0x1000>;
+			};
+
+			/* PCI-E I2C bus */
+			v2m_i2c_pcie: i2c@030000 {
+				compatible = "arm,versatile-i2c";
+				reg = <0x030000 0x1000>;
+
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				pcie-switch@60 {
+					compatible = "idt,89hpes32h8";
+					reg = <0x60>;
+				};
+			};
+
+			aaci@040000 {
+				compatible = "arm,pl041", "arm,primecell";
+				reg = <0x040000 0x1000>;
+				interrupts = <11>;
+			};
+
+			mmci@050000 {
+				compatible = "arm,pl180", "arm,primecell";
+				reg = <0x050000 0x1000>;
+				interrupts = <9 10>;
+			};
+
+			kmi@060000 {
+				compatible = "arm,pl050", "arm,primecell";
+				reg = <0x060000 0x1000>;
+				interrupts = <12>;
+			};
+
+			kmi@070000 {
+				compatible = "arm,pl050", "arm,primecell";
+				reg = <0x070000 0x1000>;
+				interrupts = <13>;
+			};
+
+			v2m_serial0: uart@090000 {
+				compatible = "arm,pl011", "arm,primecell";
+				reg = <0x090000 0x1000>;
+				interrupts = <5>;
+			};
+
+			v2m_serial1: uart@0a0000 {
+				compatible = "arm,pl011", "arm,primecell";
+				reg = <0x0a0000 0x1000>;
+				interrupts = <6>;
+			};
+
+			v2m_serial2: uart@0b0000 {
+				compatible = "arm,pl011", "arm,primecell";
+				reg = <0x0b0000 0x1000>;
+				interrupts = <7>;
+			};
+
+			v2m_serial3: uart@0c0000 {
+				compatible = "arm,pl011", "arm,primecell";
+				reg = <0x0c0000 0x1000>;
+				interrupts = <8>;
+			};
+
+			wdt@0f0000 {
+				compatible = "arm,sp805", "arm,primecell";
+				reg = <0x0f0000 0x1000>;
+				interrupts = <0>;
+			};
+
+			v2m_timer01: timer@110000 {
+				compatible = "arm,sp804", "arm,primecell";
+				reg = <0x110000 0x1000>;
+				interrupts = <2>;
+			};
+
+			v2m_timer23: timer@120000 {
+				compatible = "arm,sp804", "arm,primecell";
+				reg = <0x120000 0x1000>;
+			};
+
+			/* DVI I2C bus */
+			v2m_i2c_dvi: i2c@160000 {
+				compatible = "arm,versatile-i2c";
+				reg = <0x160000 0x1000>;
+
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				dvi-transmitter@39 {
+					compatible = "sil,sii9022-tpi", "sil,sii9022";
+					reg = <0x39>;
+				};
+
+				dvi-transmitter@60 {
+					compatible = "sil,sii9022-cpi", "sil,sii9022";
+					reg = <0x60>;
+				};
+			};
+
+			rtc@170000 {
+				compatible = "arm,pl031", "arm,primecell";
+				reg = <0x170000 0x1000>;
+				interrupts = <4>;
+			};
+
+			compact-flash@1a0000 {
+				compatible = "ata-generic";
+				reg = <0x1a0000 0x100
+				       0x1a0100 0xf00>;
+				reg-shift = <2>;
+			};
+
+			clcd@1f0000 {
+				compatible = "arm,pl111", "arm,primecell";
+				reg = <0x1f0000 0x1000>;
+				interrupts = <14>;
+			};
+		};
+	};
+};
diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
index 6a6fa22..2180888 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig
@@ -15,4 +15,12 @@ config ARCH_VEXPRESS_DT
 	help
 	  VE platform *requiring* Flattened Device Tree to boot.
 
+config ARCH_VEXPRESS_RS1
+	bool
+	select AUTO_ZRELADDR
+	select ARM_PATCH_PHYS_VIRT
+	help
+	  RS1 VE memory map (i.a. motherboard peripherals at
+	  0x1c000000, RAM at 0x80000000).
+
 endmenu
diff --git a/arch/arm/mach-vexpress/Makefile.boot b/arch/arm/mach-vexpress/Makefile.boot
index 8630b3d..05b77a5 100644
--- a/arch/arm/mach-vexpress/Makefile.boot
+++ b/arch/arm/mach-vexpress/Makefile.boot
@@ -1,3 +1,9 @@
+ifeq ($(CONFIG_ARCH_VEXPRESS_RS1),y)
+   zreladdr-y	+= 0x80008000
+params_phys-y	:= 0x80000100
+initrd_phys-y	:= 0x80800000
+else
    zreladdr-y	+= 0x60008000
 params_phys-y	:= 0x60000100
 initrd_phys-y	:= 0x60800000
+endif
diff --git a/arch/arm/mach-vexpress/include/mach/debug-macro.S b/arch/arm/mach-vexpress/include/mach/debug-macro.S
index fd9e6c7..8010ff9 100644
--- a/arch/arm/mach-vexpress/include/mach/debug-macro.S
+++ b/arch/arm/mach-vexpress/include/mach/debug-macro.S
@@ -10,12 +10,41 @@
  * published by the Free Software Foundation.
  */
 
-#define DEBUG_LL_UART_OFFSET	0x00009000
+#define DEBUG_LL_PHYS_BASE		0x10000000
+#define DEBUG_LL_UART_OFFSET		0x00009000
+
+#define DEBUG_LL_PHYS_BASE_RS1		0x1c000000
+#define DEBUG_LL_UART_OFFSET_RS1	0x00090000
+
+#define DEBUG_LL_VIRT_BASE		0xf8000000
 
 		.macro	addruart,rp,rv,tmp
-		mov	\rp, #DEBUG_LL_UART_OFFSET
-		orr	\rv, \rp, #0xf8000000	@ virtual base
-		orr	\rp, \rp, #0x10000000	@ physical base
+
+		@ Check the MMU state
+#if defined(CONFIG_MMU)
+		mrc	p15, 0, \tmp, c1, c0	@ SCTRL
+		tst	\tmp, #1		@ MMU enabled?
+		moveq	\tmp, #DEBUG_LL_PHYS_BASE
+		movne	\tmp, #DEBUG_LL_VIRT_BASE
+#else
+		mov	\tmp, #DEBUG_LL_PHYS_BASE
+#endif
+
+		@ PL011 present in "original" place?
+		orr	\tmp, \tmp, #DEBUG_LL_UART_OFFSET
+		ldr	\tmp, [\tmp, #0xfe0]	@ PeriphID0
+		teq	\tmp, #0x11		@ PL011
+
+		@ Original memory map
+		moveq	\rp, #DEBUG_LL_UART_OFFSET
+		orreq	\rv, \rp, #DEBUG_LL_VIRT_BASE
+		orreq	\rp, \rp, #DEBUG_LL_PHYS_BASE
+
+		@ RS1 memory map
+		movne	\rp, #DEBUG_LL_UART_OFFSET_RS1
+		orrne	\rv, \rp, #DEBUG_LL_VIRT_BASE
+		orrne	\rp, \rp, #DEBUG_LL_PHYS_BASE_RS1
+
 		.endm
 
 #include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/mach-vexpress/include/mach/uncompress.h b/arch/arm/mach-vexpress/include/mach/uncompress.h
index 7972c57..c491565 100644
--- a/arch/arm/mach-vexpress/include/mach/uncompress.h
+++ b/arch/arm/mach-vexpress/include/mach/uncompress.h
@@ -22,7 +22,18 @@
 #define AMBA_UART_CR(base)	(*(volatile unsigned char *)((base) + 0x30))
 #define AMBA_UART_FR(base)	(*(volatile unsigned char *)((base) + 0x18))
 
-#define get_uart_base()	(0x10000000 + 0x00009000)
+#define AMBA_PERIPH_ID0(base)	(*(volatile unsigned char *)((base) + 0xfe0))
+
+#define UART_BASE	0x10009000
+#define UART_BASE_RS1	0x1c090000
+
+static unsigned long get_uart_base(void)
+{
+	if (AMBA_PERIPH_ID0(UART_BASE) == 0x11)
+		return UART_BASE;
+	else
+		return UART_BASE_RS1;
+}
 
 /*
  * This does not append a newline
diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index a8ea95a..6965f64 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -507,9 +507,38 @@ struct sys_timer v2m_dt_timer = {
 	.init	= v2m_dt_timer_init,
 };
 
+static struct map_desc v2m_rs1_io_desc[] __initdata = {
+	{
+		.virtual	= V2M_PERIPH,
+		.pfn		= __phys_to_pfn(0x1c000000),
+		.length		= SZ_2M,
+		.type		= MT_DEVICE,
+	},
+};
+
+static int __init v2m_dt_scan_memory_map(unsigned long node, const char *uname,
+		int depth, void *data)
+{
+	const char **map = data;
+
+	if (strcmp(uname, "motherboard") != 0)
+		return 0;
+
+	*map = of_get_flat_dt_prop(node, "arm,v2m-memory-map", NULL);
+
+	return 1;
+}
+
 void __init v2m_dt_map_io(void)
 {
-	iotable_init(v2m_io_desc, ARRAY_SIZE(v2m_io_desc));
+	const char *map = NULL;
+
+	of_scan_flat_dt(v2m_dt_scan_memory_map, &map);
+
+	if (map && strcmp(map, "rs1") == 0)
+		iotable_init(v2m_rs1_io_desc, ARRAY_SIZE(v2m_rs1_io_desc));
+	else
+		iotable_init(v2m_io_desc, ARRAY_SIZE(v2m_io_desc));
 }
 
 static struct clk_lookup v2m_dt_lookups[] = {
@@ -552,6 +581,35 @@ static struct clk_lookup v2m_dt_lookups[] = {
 		.dev_id		= "1001f000.clcd",
 		.clk		= &osc1_clk,
 	},
+	/* RS1 memory map */
+	{	/* PL180 MMCI */
+		.dev_id		= "mb:mmci", /* 1c050000.mmci */
+		.clk		= &osc2_clk,
+	}, {	/* PL050 KMI0 */
+		.dev_id		= "1c060000.kmi",
+		.clk		= &osc2_clk,
+	}, {	/* PL050 KMI1 */
+		.dev_id		= "1c070000.kmi",
+		.clk		= &osc2_clk,
+	}, {	/* PL011 UART0 */
+		.dev_id		= "1c090000.uart",
+		.clk		= &osc2_clk,
+	}, {	/* PL011 UART1 */
+		.dev_id		= "1c0a0000.uart",
+		.clk		= &osc2_clk,
+	}, {	/* PL011 UART2 */
+		.dev_id		= "1c0b0000.uart",
+		.clk		= &osc2_clk,
+	}, {	/* PL011 UART3 */
+		.dev_id		= "1c0c0000.uart",
+		.clk		= &osc2_clk,
+	}, {	/* SP805 WDT */
+		.dev_id		= "1c0f0000.wdt",
+		.clk		= &v2m_ref_clk,
+	}, {	/* PL111 CLCD */
+		.dev_id		= "1c1f0000.clcd",
+		.clk		= &osc1_clk,
+	},
 };
 
 void __init v2m_dt_init_early(void)
@@ -590,6 +648,10 @@ static struct of_dev_auxdata v2m_dt_auxdata_lookup[] __initdata = {
 	OF_DEV_AUXDATA("arm,vexpress-flash", V2M_NOR0, "physmap-flash",
 			&v2m_flash_data),
 	OF_DEV_AUXDATA("arm,primecell", V2M_MMCI, "mb:mmci", &v2m_mmci_data),
+	/* RS1 memory map */
+	OF_DEV_AUXDATA("arm,vexpress-flash", 0x08000000, "physmap-flash",
+			&v2m_flash_data),
+	OF_DEV_AUXDATA("arm,primecell", 0x1c050000, "mb:mmci", &v2m_mmci_data),
 	{}
 };
 
-- 
1.6.3.3

Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support

[Dave Martin]

On Tue, Nov 29, 2011 at 03:11:12PM +0000, Pawel Moll wrote:
> This patch adds support for RS1 memory map based Versatile Express
> motherboard.

[...]

> +config ARCH_VEXPRESS_RS1
> +	bool
> +	select AUTO_ZRELADDR
> +	select ARM_PATCH_PHYS_VIRT
> +	help
> +	  RS1 VE memory map (i.a. motherboard peripherals at
> +	  0x1c000000, RAM at 0x80000000).
> +
>  endmenu
> diff --git a/arch/arm/mach-vexpress/Makefile.boot b/arch/arm/mach-vexpress/Makefile.boot
> index 8630b3d..05b77a5 100644
> --- a/arch/arm/mach-vexpress/Makefile.boot
> +++ b/arch/arm/mach-vexpress/Makefile.boot
> @@ -1,3 +1,9 @@
> +ifeq ($(CONFIG_ARCH_VEXPRESS_RS1),y)
> +   zreladdr-y	+= 0x80008000
> +params_phys-y	:= 0x80000100
> +initrd_phys-y	:= 0x80800000

This results in a uImage which is a bit broken if using a normal u-Boot
configured for vexpress-v2p-ca9, because the bootloader makes some
memory map assumptions, and anyway we don't expect the kernel to work
unless it's loaded at the start of RAM:


## Booting kernel from Legacy Image at 62000400 ...
   Image Name:   Linux-3.2.0-rc3+
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2464984 Bytes = 2.4 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 80ffffc0 ...
   Image Name:
   Image Type:   ARM Linux RAMDisk Image (uncompressed)
   Data Size:    2216523 Bytes = 2.1 MiB
   Load Address: 81000000
   Entry Point:  81000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 80ffc000
   Booting using the fdt blob at 0x80ffc000
   Loading Kernel Image ... OK
OK
   Loading Ramdisk to 7fcd3000, end 7fef024b ... OK
   Loading Device Tree to 7fcce000, end 7fcd2779 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0
Initializing cgroup subsys cpuset
Linux version 3.2.0-rc3+ (davem@e103592) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu3) ) #12 SMP Wed Nov 30 15:10:19 GMT 2011
CPU: ARMv7 Processor [410fc091] revision 1 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: ARM Versatile Express, model: V2P-CA9
bootconsole [earlycon0] enabled
Ignoring RAM at 60000000-7fffffff (vmalloc region overlap).
Ignoring RAM at 60000000-9fffffff (vmalloc region overlap).
INITRD: 0x7fcd3000+0x0021d24b is not a memory region - disabling initrd
Memory policy: ECC disabled, Data cache writealloc

<HANG>


If I strip the uImage and rebuild it with -a 0x60008000 -e 0x60008000
and no other changes, that's sufficient to give me a fully booting
kernel.  I can also boot a single image on v2p-ca9 both with and without
a dtb in this configuration.

I'm using a Linaro u-Boot from a couple of releses ago; it's possible
things have changed since.


Do you know of any specific u-Boot version which shouldn't have these
problems?

Was the hard-coded uImage load address/entry point problem ever fixed?
(It totally defeats loading a single uImage on multiple board variants.)

Cheers
---Dave

Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support

[Pawel Moll]

On Wed, 2011-11-30 at 15:37 +0000, Dave Martin wrote:
>
> This results in a uImage which is a bit broken if using a normal u-Boot
> configured for vexpress-v2p-ca9, because the bootloader makes some
> memory map assumptions, and anyway we don't expect the kernel to work
> unless it's loaded at the start of RAM:
> 
> 
> ## Booting kernel from Legacy Image at 62000400 ...
>    Image Name:   Linux-3.2.0-rc3+
>    Image Type:   ARM Linux Kernel Image (uncompressed)
>    Data Size:    2464984 Bytes = 2.4 MiB
>    Load Address: 80008000
>    Entry Point:  80008000
>    Verifying Checksum ... OK
> ## Loading init Ramdisk from Legacy Image at 80ffffc0 ...
>    Image Name:
>    Image Type:   ARM Linux RAMDisk Image (uncompressed)
>    Data Size:    2216523 Bytes = 2.1 MiB
>    Load Address: 81000000
>    Entry Point:  81000000
>    Verifying Checksum ... OK
> ## Flattened Device Tree blob at 80ffc000
>    Booting using the fdt blob at 0x80ffc000
>    Loading Kernel Image ... OK
> OK
>    Loading Ramdisk to 7fcd3000, end 7fef024b ... OK
>    Loading Device Tree to 7fcce000, end 7fcd2779 ... OK
> 
> Starting kernel ...
> 
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0
> Initializing cgroup subsys cpuset
> Linux version 3.2.0-rc3+ (davem@e103592) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu3) ) #12 SMP Wed Nov 30 15:10:19 GMT 2011
> CPU: ARMv7 Processor [410fc091] revision 1 (ARMv7), cr=10c53c7d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine: ARM Versatile Express, model: V2P-CA9
> bootconsole [earlycon0] enabled
> Ignoring RAM at 60000000-7fffffff (vmalloc region overlap).
> Ignoring RAM at 60000000-9fffffff (vmalloc region overlap).
> INITRD: 0x7fcd3000+0x0021d24b is not a memory region - disabling initrd
> Memory policy: ECC disabled, Data cache writeall
> Cheers
> ---Dave
> 
> 
> oc
> 
> <HANG>

Yes, this is known problem with U-boot. Could you try again with
"mem=512M" parameter?

> If I strip the uImage and rebuild it with -a 0x60008000 -e 0x60008000
> and no other changes, that's sufficient to give me a fully booting
> kernel.  I can also boot a single image on v2p-ca9 both with and without
> a dtb in this configuration.
> 
> I'm using a Linaro u-Boot from a couple of releses ago; it's possible
> things have changed since.
> 
> Do you know of any specific u-Boot version which shouldn't have these
> problems?
> 
> Was the hard-coded uImage load address/entry point problem ever fixed?
> (It totally defeats loading a single uImage on multiple board variants.)

I simply don't use U-boot at all, what solves the problem
"systematically" ;-) I wonder if it was possible to override the
load/entry address in the runtime?

Cheers!

Paweł



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support

[Dave Martin]

On Wed, Nov 30, 2011 at 05:15:02PM +0000, Pawel Moll wrote:
> On Wed, 2011-11-30 at 15:37 +0000, Dave Martin wrote:
> >
> > This results in a uImage which is a bit broken if using a normal u-Boot
> > configured for vexpress-v2p-ca9, because the bootloader makes some
> > memory map assumptions, and anyway we don't expect the kernel to work
> > unless it's loaded at the start of RAM:
> > 
> > 
> > ## Booting kernel from Legacy Image at 62000400 ...
> >    Image Name:   Linux-3.2.0-rc3+
> >    Image Type:   ARM Linux Kernel Image (uncompressed)
> >    Data Size:    2464984 Bytes = 2.4 MiB
> >    Load Address: 80008000
> >    Entry Point:  80008000
> >    Verifying Checksum ... OK
> > ## Loading init Ramdisk from Legacy Image at 80ffffc0 ...
> >    Image Name:
> >    Image Type:   ARM Linux RAMDisk Image (uncompressed)
> >    Data Size:    2216523 Bytes = 2.1 MiB
> >    Load Address: 81000000
> >    Entry Point:  81000000
> >    Verifying Checksum ... OK
> > ## Flattened Device Tree blob at 80ffc000
> >    Booting using the fdt blob at 0x80ffc000
> >    Loading Kernel Image ... OK
> > OK
> >    Loading Ramdisk to 7fcd3000, end 7fef024b ... OK
> >    Loading Device Tree to 7fcce000, end 7fcd2779 ... OK
> > 
> > Starting kernel ...
> > 
> > Uncompressing Linux... done, booting the kernel.
> > Booting Linux on physical CPU 0
> > Initializing cgroup subsys cpuset
> > Linux version 3.2.0-rc3+ (davem@e103592) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu3) ) #12 SMP Wed Nov 30 15:10:19 GMT 2011
> > CPU: ARMv7 Processor [410fc091] revision 1 (ARMv7), cr=10c53c7d
> > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> > Machine: ARM Versatile Express, model: V2P-CA9
> > bootconsole [earlycon0] enabled
> > Ignoring RAM at 60000000-7fffffff (vmalloc region overlap).
> > Ignoring RAM at 60000000-9fffffff (vmalloc region overlap).
> > INITRD: 0x7fcd3000+0x0021d24b is not a memory region - disabling initrd
> > Memory policy: ECC disabled, Data cache writeall
> > Cheers
> > ---Dave
> > 
> > 
> > oc
> > 
> > <HANG>
> 
> Yes, this is known problem with U-boot. Could you try again with
> "mem=512M" parameter?

The "ignoring RAM" messages go away...

## Booting kernel from Legacy Image at 62000400 ...
   Image Name:   Linux-3.2.0-rc3+
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2307920 Bytes = 2.2 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 80ffffc0 ...
   Image Name:
   Image Type:   ARM Linux RAMDisk Image (uncompressed)
   Data Size:    2216523 Bytes = 2.1 MiB
   Load Address: 81000000
   Entry Point:  81000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 80ffc000
   Booting using the fdt blob at 0x80ffc000
   Loading Kernel Image ... OK
OK
   Loading Ramdisk to 7fcd3000, end 7fef024b ... OK
   Loading Device Tree to 7fcce000, end 7fcd2779 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Initializing cgroup subsys cpuset
Linux version 3.2.0-rc3+ (davem@e103592) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu3) ) #18 Wed Nov 30 15:54:02 GMT 2011
CPU: ARMv7 Processor [410fc091] revision 1 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: ARM Versatile Express, model: V2P-CA9
bootconsole [earlycon0] enabled
INITRD: 0x7fcd3000+0x0021d24b is not a memory region - disabling initrd
Memory policy: ECC disabled, Data cache writeback


... but the kernel still hangs.

U-Boot's built-in assumption about using addresses around 0x7f000000 to
relocate the dtb and initrd are clearly a problem here, though if that
was the only problem, the kernel would have booted further than this...

It would be nice to know what's going on here, but I'm reasonably
convinced that we're just booting the kernel in a silly way here, and
U-Boot really needs to be fixed to avoid the fixed-load-address
limitation.

 
> > If I strip the uImage and rebuild it with -a 0x60008000 -e 0x60008000
> > and no other changes, that's sufficient to give me a fully booting
> > kernel.  I can also boot a single image on v2p-ca9 both with and without
> > a dtb in this configuration.
> > 
> > I'm using a Linaro u-Boot from a couple of releses ago; it's possible
> > things have changed since.
> > 
> > Do you know of any specific u-Boot version which shouldn't have these
> > problems?
> > 
> > Was the hard-coded uImage load address/entry point problem ever fixed?
> > (It totally defeats loading a single uImage on multiple board variants.)
> 
> I simply don't use U-boot at all, what solves the problem
> "systematically" ;-) I wonder if it was possible to override the
> load/entry address in the runtime?

I believe not, but there have been some discussions about loading to a
default "start of RAM" location if the uImage's load address/entry point
are zero, or having some header flag to indicate this.

I don't know about the implementation status of this, though.


Tixy, do you know anything about the current status of this issue in
U-Boot?  Do you have a workaround for it?

Cheers
---Dave

Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support

[Pawel Moll]

On Wed, 2011-11-30 at 17:54 +0000, Dave Martin wrote:
> It would be nice to know what's going on here, but I'm reasonably
> convinced that we're just booting the kernel in a silly way here, and
> U-Boot really needs to be fixed to avoid the fixed-load-address
> limitation.

If you send me (privately, probably) your U-boot binary I will have a
look tomorrow. I'd like to be sure I understand what is going wrong...

Cheers

Paweł



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support

[Nicolas Pitre]

On Wed, 30 Nov 2011, Dave Martin wrote:

> On Wed, Nov 30, 2011 at 05:15:02PM +0000, Pawel Moll wrote:
> > On Wed, 2011-11-30 at 15:37 +0000, Dave Martin wrote:
> > >
> > > This results in a uImage which is a bit broken if using a normal u-Boot
> > > configured for vexpress-v2p-ca9, because the bootloader makes some
> > > memory map assumptions, and anyway we don't expect the kernel to work
> > > unless it's loaded at the start of RAM:

> > Yes, this is known problem with U-boot. Could you try again with
> > "mem=512M" parameter?
> 
> U-Boot's built-in assumption about using addresses around 0x7f000000 to
> relocate the dtb and initrd are clearly a problem here, though if that
> was the only problem, the kernel would have booted further than this...
> 
> It would be nice to know what's going on here, but I'm reasonably
> convinced that we're just booting the kernel in a silly way here, and
> U-Boot really needs to be fixed to avoid the fixed-load-address
> limitation.
> 
> > > Was the hard-coded uImage load address/entry point problem ever fixed?
> > > (It totally defeats loading a single uImage on multiple board variants.)
> > 
> > I simply don't use U-boot at all, what solves the problem
> > "systematically" ;-) I wonder if it was possible to override the
> > load/entry address in the runtime?
> 
> I believe not, but there have been some discussions about loading to a
> default "start of RAM" location if the uImage's load address/entry point
> are zero, or having some header flag to indicate this.
> 
> I don't know about the implementation status of this, though.

Stephen Warren posted some patches to fix this.  The u-Boot maintainer 
was having some "issues" with them.  I don't know if this has been 
resolved at this point.

Of course this would help if more people other than Stephen and myself 
were putting some pressure on the maintainer for this problem to get 
fixed satisfactorily.

I have changes to the kernel which are pending some resolution on the 
u-Boot side for this very issue at the moment which is getting rather 
annoying.  If nothing moves I might just go ahead with those changes and 
simply rip the uImage make target out of the kernel as well.  Maybe the 
inconvenience will be a sufficient incentive for people to lobby proper 
u-Boot support.  And it is not like if the u-Boot patches didn't exist 
already.


Nicolas

Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support

[Mark Brown]

On Wed, Nov 30, 2011 at 03:43:50PM -0500, Nicolas Pitre wrote:

> annoying.  If nothing moves I might just go ahead with those changes and 
> simply rip the uImage make target out of the kernel as well.  Maybe the 
> inconvenience will be a sufficient incentive for people to lobby proper 
> u-Boot support.  And it is not like if the u-Boot patches didn't exist 

Oh, dear.  Any pointers to the discussions on the u-boot side?

RE: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support

[Stephen Warren]

Mark Brown wrote at Wednesday, November 30, 2011 1:48 PM:
> On Wed, Nov 30, 2011 at 03:43:50PM -0500, Nicolas Pitre wrote:
> 
> > annoying.  If nothing moves I might just go ahead with those changes and
> > simply rip the uImage make target out of the kernel as well.  Maybe the
> > inconvenience will be a sufficient incentive for people to lobby proper
> > u-Boot support.  And it is not like if the u-Boot patches didn't exist
> 
> Oh, dear.  Any pointers to the discussions on the u-boot side?

The most recent patch is at:

http://www.mail-archive.com/u-boot-0aAXYlwwYIKGBzrmiIFOJg@public.gmane.org/msg69105.html

Earlier versions are at:

http://www.mail-archive.com/u-boot-0aAXYlwwYIKGBzrmiIFOJg@public.gmane.org/msg68907.html
http://www.mail-archive.com/u-boot-0aAXYlwwYIKGBzrmiIFOJg@public.gmane.org/msg67647.html
http://www.mail-archive.com/u-boot-0aAXYlwwYIKGBzrmiIFOJg@public.gmane.org/msg66537.html
http://www.mail-archive.com/u-boot-0aAXYlwwYIKGBzrmiIFOJg@public.gmane.org/msg65837.html
http://www.mail-archive.com/u-boot-0aAXYlwwYIKGBzrmiIFOJg@public.gmane.org/msg64721.html
http://www.mail-archive.com/u-boot-0aAXYlwwYIKGBzrmiIFOJg@public.gmane.org/msg64237.html

-- 
nvpublic

Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support

[Nicolas Pitre]

On Wed, 30 Nov 2011, Mark Brown wrote:

> On Wed, Nov 30, 2011 at 03:43:50PM -0500, Nicolas Pitre wrote:
> 
> > annoying.  If nothing moves I might just go ahead with those changes and 
> > simply rip the uImage make target out of the kernel as well.  Maybe the 
> > inconvenience will be a sufficient incentive for people to lobby proper 
> > u-Boot support.  And it is not like if the u-Boot patches didn't exist 
> 
> Oh, dear.  Any pointers to the discussions on the u-boot side?

Certainly.  Many different threads actually.  Here's a few:

http://news.gmane.org/group/gmane.comp.boot-loaders.u-boot/thread=114981

http://news.gmane.org/group/gmane.comp.boot-loaders.u-boot/thread=115774

And this is not the first time this issue has come up:

http://news.gmane.org/group/gmane.comp.boot-loaders.u-boot/thread=83824

http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=81546/force_load=t/focus=84138

Yet more u-Boot woes:

http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=53973

I'm sure there are others, but that's what I've quickly dug out.


Nicolas

Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support

[Russell King - ARM Linux]

On Wed, Nov 30, 2011 at 04:38:26PM -0500, Nicolas Pitre wrote:
> On Wed, 30 Nov 2011, Mark Brown wrote:
> 
> > On Wed, Nov 30, 2011 at 03:43:50PM -0500, Nicolas Pitre wrote:
> > 
> > > annoying.  If nothing moves I might just go ahead with those changes and 
> > > simply rip the uImage make target out of the kernel as well.  Maybe the 
> > > inconvenience will be a sufficient incentive for people to lobby proper 
> > > u-Boot support.  And it is not like if the u-Boot patches didn't exist 
> > 
> > Oh, dear.  Any pointers to the discussions on the u-boot side?
> 
> Certainly.  Many different threads actually.  Here's a few:
> 
> http://news.gmane.org/group/gmane.comp.boot-loaders.u-boot/thread=114981
> 
> http://news.gmane.org/group/gmane.comp.boot-loaders.u-boot/thread=115774
> 
> And this is not the first time this issue has come up:
> 
> http://news.gmane.org/group/gmane.comp.boot-loaders.u-boot/thread=83824
> 
> http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=81546/force_load=t/focus=84138
> 
> Yet more u-Boot woes:
> 
> http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=53973
> 
> I'm sure there are others, but that's what I've quickly dug out.

So why are we still supporting uboot in the mainline kernel on ARM?

Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support

[Nicolas Pitre]

On Wed, 30 Nov 2011, Russell King - ARM Linux wrote:

> On Wed, Nov 30, 2011 at 04:38:26PM -0500, Nicolas Pitre wrote:
> > On Wed, 30 Nov 2011, Mark Brown wrote:
> > 
> > > On Wed, Nov 30, 2011 at 03:43:50PM -0500, Nicolas Pitre wrote:
> > > 
> > > > annoying.  If nothing moves I might just go ahead with those changes and 
> > > > simply rip the uImage make target out of the kernel as well.  Maybe the 
> > > > inconvenience will be a sufficient incentive for people to lobby proper 
> > > > u-Boot support.  And it is not like if the u-Boot patches didn't exist 
> > > 
> > > Oh, dear.  Any pointers to the discussions on the u-boot side?
> > 
> > Certainly.  Many different threads actually.  Here's a few:
> > 
> > http://news.gmane.org/group/gmane.comp.boot-loaders.u-boot/thread=114981
> > 
> > http://news.gmane.org/group/gmane.comp.boot-loaders.u-boot/thread=115774
> > 
> > And this is not the first time this issue has come up:
> > 
> > http://news.gmane.org/group/gmane.comp.boot-loaders.u-boot/thread=83824
> > 
> > http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=81546/force_load=t/focus=84138
> > 
> > Yet more u-Boot woes:
> > 
> > http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=53973
> > 
> > I'm sure there are others, but that's what I've quickly dug out.
> 
> So why are we still supporting uboot in the mainline kernel on ARM?

As a demonstration of good will I'd say.

I still believe that the uImage wrapping is _not_ ARM specific, and that 
someone should step up to be the maintainer of a generic u-Boot Kconfig 
menu and makefile target(s) common to all architectures.

But until Stephen's u-Boot patches are merged, and the corresponding 
mkimage and u-Boot binaries are deployed, there is little point keeping 
a uImage makefile target for a kernel which is meant to be run on 
multiple SOCs.

This is already affecting i.MX which could already have a single kernel 
image for the whole SOC family despite different RAM addresses if this 
wasn't for this uImage format limitation.  So at the moment the mkimage 
step makes sense only at kernel install time when you know the exact 
machine where the installation will take place, not at kernel build 
time.



Nicolas

Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support

[Mark Brown]

On Wed, Nov 30, 2011 at 04:38:26PM -0500, Nicolas Pitre wrote:
> On Wed, 30 Nov 2011, Mark Brown wrote:

> > Oh, dear.  Any pointers to the discussions on the u-boot side?

> Certainly.  Many different threads actually.  Here's a few:

OK, thanks - I see Stephen just followed up and Wolfgang seems
moderately happy so hopefully there will be some progress.  It also
occurs to me that there's at least Qi also using uImages, hopefully
other bootloaders are going to be easier to deal with (or already cope).

Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support

[Dave Martin]

On Thu, Dec 01, 2011 at 11:10:50AM +0000, Mark Brown wrote:
> On Wed, Nov 30, 2011 at 04:38:26PM -0500, Nicolas Pitre wrote:
> > On Wed, 30 Nov 2011, Mark Brown wrote:
> 
> > > Oh, dear.  Any pointers to the discussions on the u-boot side?
> 
> > Certainly.  Many different threads actually.  Here's a few:
> 
> OK, thanks - I see Stephen just followed up and Wolfgang seems
> moderately happy so hopefully there will be some progress.  It also
> occurs to me that there's at least Qi also using uImages, hopefully
> other bootloaders are going to be easier to deal with (or already cope).

If Stephen's patches are heading for merge, that's great.

If this feature remains blocked though, could we support Wolfgang's
preference for start-of-RAM-relative load and entry address?


This provides everything we need, and also works for Image as well as
zImage.  The one thing it doesn't allow is to tell u-Boot that
relocating a zImage to another location in memory is not usually
necessary.  But we already have that redundant copy during boot, so
this particular aspect of the situation at least won't get any worse.

Whether or not we consider this an ideal solution, it will work (which
is more than we have right now)


A final alternative would be to propose a more expressive descripition
of an image's load address constraints, so that we really can describe
things like "must be loaded to a word-aligned range within the first
128MB of RAM" and "must be loaded to start of RAM + 0x8000".  This
would give U-Boot the flexibility to choose an appropriate location
for the image, and the knowledge to make a correct choice.  It would
also give U-Boot the opportunity not to copy the image payload if
it meets the address constraints already.  However, such a solution
would come at the expense of a bit of added complexity.

Cheers
---Dave

RE: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support

[Stephen Warren]

Dave Martin wrote at Thursday, December 01, 2011 5:14 AM:
> On Thu, Dec 01, 2011 at 11:10:50AM +0000, Mark Brown wrote:
> > On Wed, Nov 30, 2011 at 04:38:26PM -0500, Nicolas Pitre wrote:
> > > On Wed, 30 Nov 2011, Mark Brown wrote:
> >
> > > > Oh, dear.  Any pointers to the discussions on the u-boot side?
> >
> > > Certainly.  Many different threads actually.  Here's a few:
> >
> > OK, thanks - I see Stephen just followed up and Wolfgang seems
> > moderately happy so hopefully there will be some progress.  It also
> > occurs to me that there's at least Qi also using uImages, hopefully
> > other bootloaders are going to be easier to deal with (or already cope).
> 
> If Stephen's patches are heading for merge, that's great.
> 
> If this feature remains blocked though, could we support Wolfgang's
> preference for start-of-RAM-relative load and entry address?

It looks like my change is progressing to being checked in:

http://lists.denx.de/pipermail/u-boot/2011-December/111865.html

As background though, I don't think an "SDRAM-relative" approach would
be any more or less likely to get checked in; the size of the patch
would end up being just the same as my final "don't copy the kernel to
any load address" patch. Incidentally, the very first patch I posted
was for an "SDRAM-relative" load address, although it ended up being
far more complex than my final patch due to the way I implemented it;
a rewrite would come out much smaller.

-- 
nvpublic

RE: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support

[Stephen Warren]

Stephen Warren wrote at Thursday, December 01, 2011 9:20 AM:
> Dave Martin wrote at Thursday, December 01, 2011 5:14 AM:
> > On Thu, Dec 01, 2011 at 11:10:50AM +0000, Mark Brown wrote:
> > > On Wed, Nov 30, 2011 at 04:38:26PM -0500, Nicolas Pitre wrote:
> > > > On Wed, 30 Nov 2011, Mark Brown wrote:
> > >
> > > > > Oh, dear.  Any pointers to the discussions on the u-boot side?
> > >
> > > > Certainly.  Many different threads actually.  Here's a few:
> > >
> > > OK, thanks - I see Stephen just followed up and Wolfgang seems
> > > moderately happy so hopefully there will be some progress.  It also
> > > occurs to me that there's at least Qi also using uImages, hopefully
> > > other bootloaders are going to be easier to deal with (or already cope).
> >
> > If Stephen's patches are heading for merge, that's great.
> >
> > If this feature remains blocked though, could we support Wolfgang's
> > preference for start-of-RAM-relative load and entry address?
> 
> It looks like my change is progressing to being checked in:
> 
> http://lists.denx.de/pipermail/u-boot/2011-December/111865.html

For the record, the changes are now in U-Boot master:

d510859 image: Don't detect XIP images as overlapping.
b9b50e8 image: Implement IH_TYPE_KERNEL_NOLOAD

I should also note that Marek Vasut posted some patches to implement a
bootz command in U-Boot. This turned out to be much less invasive than
I originally thought, so once those patches are finalized, uImage might
be irrelevant except for initrds (U-Boot already accepts a raw FDT
without uImage wrapping for bootm and hence bootz).

http://www.mail-archive.com/u-boot-0aAXYlwwYIKGBzrmiIFOJg@public.gmane.org/msg69287.html

-- 
nvpublic

Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support

[Marek Vasut]

> Stephen Warren wrote at Thursday, December 01, 2011 9:20 AM:
> > Dave Martin wrote at Thursday, December 01, 2011 5:14 AM:
> > > On Thu, Dec 01, 2011 at 11:10:50AM +0000, Mark Brown wrote:
> > > > On Wed, Nov 30, 2011 at 04:38:26PM -0500, Nicolas Pitre wrote:
> > > > > On Wed, 30 Nov 2011, Mark Brown wrote:
> > > > > > Oh, dear.  Any pointers to the discussions on the u-boot side?
> > > > > 
> > > > > Certainly.  Many different threads actually.  Here's a few:
> > > > OK, thanks - I see Stephen just followed up and Wolfgang seems
> > > > moderately happy so hopefully there will be some progress.  It also
> > > > occurs to me that there's at least Qi also using uImages, hopefully
> > > > other bootloaders are going to be easier to deal with (or already
> > > > cope).
> > > 
> > > If Stephen's patches are heading for merge, that's great.
> > > 
> > > If this feature remains blocked though, could we support Wolfgang's
> > > preference for start-of-RAM-relative load and entry address?
> > 
> > It looks like my change is progressing to being checked in:
> > 
> > http://lists.denx.de/pipermail/u-boot/2011-December/111865.html
> 
> For the record, the changes are now in U-Boot master:
> 
> d510859 image: Don't detect XIP images as overlapping.
> b9b50e8 image: Implement IH_TYPE_KERNEL_NOLOAD
> 
> I should also note that Marek Vasut posted some patches to implement a
> bootz command in U-Boot. This turned out to be much less invasive than
> I originally thought, so once those patches are finalized, uImage might
> be irrelevant except for initrds (U-Boot already accepts a raw FDT
> without uImage wrapping for bootm and hence bootz).
> 
> http://www.mail-archive.com/u-boot-0aAXYlwwYIKGBzrmiIFOJg@public.gmane.org/msg69287.html

Hi guys,

I'm now cleaning up the PXA support in U-Boot and there's also a lot of 
university load. It's unlikely bootz will make it to .12, but 2012.03 seems 
real. Any help is welcome though.

M

Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support

[Dave Martin]

On Fri, Dec 02, 2011 at 09:41:12AM -0800, Stephen Warren wrote:
> Stephen Warren wrote at Thursday, December 01, 2011 9:20 AM:
> > Dave Martin wrote at Thursday, December 01, 2011 5:14 AM:
> > > On Thu, Dec 01, 2011 at 11:10:50AM +0000, Mark Brown wrote:
> > > > On Wed, Nov 30, 2011 at 04:38:26PM -0500, Nicolas Pitre wrote:
> > > > > On Wed, 30 Nov 2011, Mark Brown wrote:
> > > >
> > > > > > Oh, dear.  Any pointers to the discussions on the u-boot side?
> > > >
> > > > > Certainly.  Many different threads actually.  Here's a few:
> > > >
> > > > OK, thanks - I see Stephen just followed up and Wolfgang seems
> > > > moderately happy so hopefully there will be some progress.  It also
> > > > occurs to me that there's at least Qi also using uImages, hopefully
> > > > other bootloaders are going to be easier to deal with (or already cope).
> > >
> > > If Stephen's patches are heading for merge, that's great.
> > >
> > > If this feature remains blocked though, could we support Wolfgang's
> > > preference for start-of-RAM-relative load and entry address?
> > 
> > It looks like my change is progressing to being checked in:
> > 
> > http://lists.denx.de/pipermail/u-boot/2011-December/111865.html
> 
> For the record, the changes are now in U-Boot master:
> 
> d510859 image: Don't detect XIP images as overlapping.
> b9b50e8 image: Implement IH_TYPE_KERNEL_NOLOAD
> 
> I should also note that Marek Vasut posted some patches to implement a
> bootz command in U-Boot. This turned out to be much less invasive than
> I originally thought, so once those patches are finalized, uImage might
> be irrelevant except for initrds (U-Boot already accepts a raw FDT
> without uImage wrapping for bootm and hence bootz).
> 
> http://www.mail-archive.com/u-boot-0aAXYlwwYIKGBzrmiIFOJg@public.gmane.org/msg69287.html

Great, thanks for the alert.

Cheers
---Dave

RE: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support

[Nicolas Pitre]

On Fri, 2 Dec 2011, Stephen Warren wrote:

> For the record, the changes are now in U-Boot master:
> 
> d510859 image: Don't detect XIP images as overlapping.
> b9b50e8 image: Implement IH_TYPE_KERNEL_NOLOAD

Yay!  Thank you Stephen for driving this to a successful resolution.

Of course, boards won't be updated to the latest u-boot right away, nor 
will the enhanced mkimage tool be commonly available.

> I should also note that Marek Vasut posted some patches to implement a
> bootz command in U-Boot. This turned out to be much less invasive than
> I originally thought, so once those patches are finalized, uImage might
> be irrelevant except for initrds (U-Boot already accepts a raw FDT
> without uImage wrapping for bootm and hence bootz).
> 
> http://www.mail-archive.com/u-boot-0aAXYlwwYIKGBzrmiIFOJg@public.gmane.org/msg69287.html

Excellent!


Nicolas

Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support

[Marek Vasut]

> On Fri, 2 Dec 2011, Stephen Warren wrote:
> > For the record, the changes are now in U-Boot master:
> > 
> > d510859 image: Don't detect XIP images as overlapping.
> > b9b50e8 image: Implement IH_TYPE_KERNEL_NOLOAD
> 
> Yay!  Thank you Stephen for driving this to a successful resolution.
> 
> Of course, boards won't be updated to the latest u-boot right away

Though we should demand it on the new boards at least.

> , nor
> will the enhanced mkimage tool be commonly available.

Why not, just tell people to use up-to-date tools, otherwise you can't support 
them. It's really easy.

> 
> > I should also note that Marek Vasut posted some patches to implement a
> > bootz command in U-Boot. This turned out to be much less invasive than
> > I originally thought, so once those patches are finalized, uImage might
> > be irrelevant except for initrds (U-Boot already accepts a raw FDT
> > without uImage wrapping for bootm and hence bootz).
> > 
> > http://www.mail-archive.com/u-boot-0aAXYlwwYIKGBzrmiIFOJg@public.gmane.org/msg69287.html
> 
> Excellent!
> 
Nico, please see my other mail. This is really going to 2012.03 release 
earliest. 2011.12 release is definitelly missed, sorry.

> 
> Nicolas

M

Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support

[Russell King - ARM Linux]

On Thu, Dec 01, 2011 at 11:10:50AM +0000, Mark Brown wrote:
> On Wed, Nov 30, 2011 at 04:38:26PM -0500, Nicolas Pitre wrote:
> > On Wed, 30 Nov 2011, Mark Brown wrote:
> 
> > > Oh, dear.  Any pointers to the discussions on the u-boot side?
> 
> > Certainly.  Many different threads actually.  Here's a few:
> 
> OK, thanks - I see Stephen just followed up and Wolfgang seems
> moderately happy so hopefully there will be some progress.  It also
> occurs to me that there's at least Qi also using uImages, hopefully
> other bootloaders are going to be easier to deal with (or already cope).

Most boot loaders on ARM prior to uboot either allow the load address
to be specified via the command script, or they already load the kernel
to a fixed address into system RAM - using the kernels native zImage
binary format.

So these other boot loaders shouldn't be any problem what so ever.  In
fact they've already been working well with relocatable zImages for
many many years.

[PATCH v3 5/5] ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4

[Pawel Moll]

This patch adds Device Trees for ARM Ltd. CoreTile Express A5x2
and CoreTile Express A9x4 used with V2M motherboard and an initial
implementation of the DT machine support (this code is separate
from the current core tile code).

Signed-off-by: Pawel Moll <pawel.moll@arm.com>
---
 arch/arm/boot/dts/vexpress-v2p-ca5s.dts |  131 ++++++++++++++++++++++++++++
 arch/arm/boot/dts/vexpress-v2p-ca9.dts  |  145 +++++++++++++++++++++++++++++++
 arch/arm/mach-vexpress/Kconfig          |   23 +++++
 arch/arm/mach-vexpress/Makefile         |    1 +
 arch/arm/mach-vexpress/v2p-ca5s_ca9.c   |  115 ++++++++++++++++++++++++
 5 files changed, 415 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/vexpress-v2p-ca5s.dts
 create mode 100644 arch/arm/boot/dts/vexpress-v2p-ca9.dts
 create mode 100644 arch/arm/mach-vexpress/v2p-ca5s_ca9.c

diff --git a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
new file mode 100644
index 0000000..e63c251
--- /dev/null
+++ b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
@@ -0,0 +1,131 @@
+/*
+ * ARM Ltd. Versatile Express
+ *
+ * CoreTile Express A5x2
+ * Cortex-A5 MPCore (V2P-CA5s)
+ *
+ * HBI-0225B
+ */
+
+/dts-v1/;
+
+/include/ "skeleton.dtsi"
+
+/ {
+	model = "V2P-CA5s";
+	arm,hbi = <0x225>;
+	compatible = "arm,vexpress-v2p-ca5s";
+	interrupt-parent = <&gic>;
+
+	aliases {
+		serial0 = &v2m_serial0;
+		serial1 = &v2m_serial1;
+		serial2 = &v2m_serial2;
+		serial3 = &v2m_serial3;
+		i2c0 = &v2m_i2c_dvi;
+		i2c1 = &v2m_i2c_pcie;
+	};
+
+	memory@80000000 {
+		device_type = "memory";
+		reg = <0x80000000 0x40000000>;
+	};
+
+	hdlcd@2a110000 {
+		compatible = "arm,hdlcd";
+		reg = <0x2a110000 0x1000>;
+		interrupts = <0 85 4>;
+	};
+
+	memory-controller@2a150000 {
+		compatible = "arm,pl341", "arm,primecell";
+		reg = <0x2a150000 0x1000>;
+	};
+
+	memory-controller@2a190000 {
+		compatible = "arm,pl354", "arm,primecell";
+		reg = <0x2a190000 0x1000>;
+		interrupts = <0 86 4>,
+			     <0 87 4>;
+	};
+
+	gic: interrupt-controller@2c001000 {
+		compatible = "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		#address-cells = <0>;
+		interrupt-controller;
+		reg = <0x2c001000 0x1000>,
+		      <0x2c000100 0x100>;
+	};
+
+	L2: cache-controller@2c0f0000 {
+		compatible = "arm,pl310-cache";
+		reg = <0x2c0f0000 0x1000>;
+		interrupts = <0 84 4>;
+		cache-level = <2>;
+		arm,data-latency = <0>;
+		arm,tag-latency = <0>;
+	};
+
+	pmu {
+		compatible = "arm,cortex-a9-pmu";
+		interrupts = <0 68 4>,
+			     <0 69 4>;
+	};
+
+	motherboard {
+		ranges = <0 0 0x08000000 0x04000000>,
+			 <1 0 0x14000000 0x04000000>,
+			 <2 0 0x18000000 0x04000000>,
+			 <3 0 0x1c000000 0x04000000>,
+			 <4 0 0x0c000000 0x04000000>,
+			 <5 0 0x10000000 0x04000000>;
+
+		interrupt-map-mask = <0 0 63>;
+		interrupt-map = <0 0  0 &gic 0  0 4>,
+				<0 0  1 &gic 0  1 4>,
+				<0 0  2 &gic 0  2 4>,
+				<0 0  3 &gic 0  3 4>,
+				<0 0  4 &gic 0  4 4>,
+				<0 0  5 &gic 0  5 4>,
+				<0 0  6 &gic 0  6 4>,
+				<0 0  7 &gic 0  7 4>,
+				<0 0  8 &gic 0  8 4>,
+				<0 0  9 &gic 0  9 4>,
+				<0 0 10 &gic 0 10 4>,
+				<0 0 11 &gic 0 11 4>,
+				<0 0 12 &gic 0 12 4>,
+				<0 0 13 &gic 0 13 4>,
+				<0 0 14 &gic 0 14 4>,
+				<0 0 15 &gic 0 15 4>,
+				<0 0 16 &gic 0 16 4>,
+				<0 0 17 &gic 0 17 4>,
+				<0 0 18 &gic 0 18 4>,
+				<0 0 19 &gic 0 19 4>,
+				<0 0 20 &gic 0 20 4>,
+				<0 0 21 &gic 0 21 4>,
+				<0 0 22 &gic 0 22 4>,
+				<0 0 23 &gic 0 23 4>,
+				<0 0 24 &gic 0 24 4>,
+				<0 0 25 &gic 0 25 4>,
+				<0 0 26 &gic 0 26 4>,
+				<0 0 27 &gic 0 27 4>,
+				<0 0 28 &gic 0 28 4>,
+				<0 0 29 &gic 0 29 4>,
+				<0 0 30 &gic 0 30 4>,
+				<0 0 31 &gic 0 31 4>,
+				<0 0 32 &gic 0 32 4>,
+				<0 0 33 &gic 0 33 4>,
+				<0 0 34 &gic 0 34 4>,
+				<0 0 35 &gic 0 35 4>,
+				<0 0 36 &gic 0 36 4>,
+				<0 0 37 &gic 0 37 4>,
+				<0 0 38 &gic 0 38 4>,
+				<0 0 39 &gic 0 39 4>,
+				<0 0 40 &gic 0 40 4>,
+				<0 0 41 &gic 0 41 4>,
+				<0 0 42 &gic 0 42 4>;
+	};
+};
+
+/include/ "vexpress-v2m-rs1.dtsi"
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca9.dts b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
new file mode 100644
index 0000000..c51fe09
--- /dev/null
+++ b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
@@ -0,0 +1,145 @@
+/*
+ * ARM Ltd. Versatile Express
+ *
+ * CoreTile Express A9x4
+ * Cortex-A9 MPCore (V2P-CA9)
+ *
+ * HBI-0191B
+ */
+
+/dts-v1/;
+
+/include/ "skeleton.dtsi"
+
+/ {
+	model = "V2P-CA9";
+	arm,hbi = <0x191>;
+	compatible = "arm,vexpress-v2p-ca9";
+	interrupt-parent = <&gic>;
+
+	aliases {
+		serial0 = &v2m_serial0;
+		serial1 = &v2m_serial1;
+		serial2 = &v2m_serial2;
+		serial3 = &v2m_serial3;
+		i2c0 = &v2m_i2c_dvi;
+		i2c1 = &v2m_i2c_pcie;
+	};
+
+	memory@60000000 {
+		device_type = "memory";
+		reg = <0x60000000 0x40000000>;
+	};
+
+	clcd@10020000 {
+		compatible = "arm,pl111", "arm,primecell";
+		reg = <0x10020000 0x1000>;
+		interrupts = <0 44 4>;
+	};
+
+	memory-controller@100e0000 {
+		compatible = "arm,pl341", "arm,primecell";
+		reg = <0x100e0000 0x1000>;
+	};
+
+	memory-controller@100e1000 {
+		compatible = "arm,pl354", "arm,primecell";
+		reg = <0x100e1000 0x1000>;
+		interrupts = <0 45 4>,
+			     <0 46 4>;
+	};
+
+	timer@100e4000 {
+		compatible = "arm,sp804", "arm,primecell";
+		reg = <0x100e4000 0x1000>;
+		interrupts = <0 48 4>,
+			     <0 49 4>;
+	};
+
+	watchdog@100e5000 {
+		compatible = "arm,sp805", "arm,primecell";
+		reg = <0x100e5000 0x1000>;
+		interrupts = <0 51 4>;
+	};
+
+	gic: interrupt-controller@1e001000 {
+		compatible = "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		#address-cells = <0>;
+		interrupt-controller;
+		reg = <0x1e001000 0x1000>,
+		      <0x1e000100 0x100>;
+	};
+
+	L2: cache-controller@1e00a000 {
+		compatible = "arm,pl310-cache";
+		reg = <0x1e00a000 0x1000>;
+		interrupts = <0 43 4>;
+		cache-level = <2>;
+		arm,data-latency = <0>;
+		arm,tag-latency = <0>;
+	};
+
+	pmu {
+		compatible = "arm,cortex-a9-pmu";
+		interrupts = <0 60 4>,
+			     <0 61 4>,
+			     <0 62 4>,
+			     <0 63 4>;
+	};
+
+	motherboard {
+		ranges = <0 0 0x40000000 0x04000000>,
+			 <1 0 0x44000000 0x04000000>,
+			 <2 0 0x48000000 0x04000000>,
+			 <3 0 0x4c000000 0x04000000>,
+			 <7 0 0x10000000 0x00020000>;
+
+		interrupt-map-mask = <0 0 63>;
+		interrupt-map = <0 0  0 &gic 0  0 4>,
+				<0 0  1 &gic 0  1 4>,
+				<0 0  2 &gic 0  2 4>,
+				<0 0  3 &gic 0  3 4>,
+				<0 0  4 &gic 0  4 4>,
+				<0 0  5 &gic 0  5 4>,
+				<0 0  6 &gic 0  6 4>,
+				<0 0  7 &gic 0  7 4>,
+				<0 0  8 &gic 0  8 4>,
+				<0 0  9 &gic 0  9 4>,
+				<0 0 10 &gic 0 10 4>,
+				<0 0 11 &gic 0 11 4>,
+				<0 0 12 &gic 0 12 4>,
+				<0 0 13 &gic 0 13 4>,
+				<0 0 14 &gic 0 14 4>,
+				<0 0 15 &gic 0 15 4>,
+				<0 0 16 &gic 0 16 4>,
+				<0 0 17 &gic 0 17 4>,
+				<0 0 18 &gic 0 18 4>,
+				<0 0 19 &gic 0 19 4>,
+				<0 0 20 &gic 0 20 4>,
+				<0 0 21 &gic 0 21 4>,
+				<0 0 22 &gic 0 22 4>,
+				<0 0 23 &gic 0 23 4>,
+				<0 0 24 &gic 0 24 4>,
+				<0 0 25 &gic 0 25 4>,
+				<0 0 26 &gic 0 26 4>,
+				<0 0 27 &gic 0 27 4>,
+				<0 0 28 &gic 0 28 4>,
+				<0 0 29 &gic 0 29 4>,
+				<0 0 30 &gic 0 30 4>,
+				<0 0 31 &gic 0 31 4>,
+				<0 0 32 &gic 0 32 4>,
+				<0 0 33 &gic 0 33 4>,
+				<0 0 34 &gic 0 34 4>,
+				<0 0 35 &gic 0 35 4>,
+				<0 0 36 &gic 0 36 4>,
+				<0 0 37 &gic 0 37 4>,
+				<0 0 38 &gic 0 38 4>,
+				<0 0 39 &gic 0 39 4>,
+				<0 0 40 &gic 0 40 4>,
+				<0 0 41 &gic 0 41 4>,
+				<0 0 42 &gic 0 42 4>;
+	};
+};
+
+/include/ "vexpress-v2m.dtsi"
diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
index 2180888..9eb8161 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig
@@ -23,4 +23,27 @@ config ARCH_VEXPRESS_RS1
 	  RS1 VE memory map (i.a. motherboard peripherals at
 	  0x1c000000, RAM at 0x80000000).
 
+config ARCH_VEXPRESS_V2P_CA5S_CA9
+	bool "CoreTile Express A5x2 and A9x4 based platform support"
+	select CPU_V7
+	select ARM_GIC
+	select ARCH_VEXPRESS_RS1
+	select ARCH_VEXPRESS_DT
+	select ARM_ERRATA_720789
+	select ARM_ERRATA_751472
+	select PL310_ERRATA_753970 if CACHE_PL310
+	help
+	  This option enables support for systems using any of the following
+	  ARM core tiles on the Versatile Express motherboard:
+
+	  - CoreTile Express A5x2 (V2P-CA5s)
+	  - CoreTile Express A9x4 (V2P-CA9)
+
+	  You must boot using a Flattened Device Tree in order to use these
+	  platforms.  The traditional (ATAGs) boot method is not usable on
+	  these boards with this option.
+
+	  If you want your kernel to run on one of these platforms and your
+	  bootloader supports Flattened Device Tree based booting, say Y.
+
 endmenu
diff --git a/arch/arm/mach-vexpress/Makefile b/arch/arm/mach-vexpress/Makefile
index 90551b9..06e3687 100644
--- a/arch/arm/mach-vexpress/Makefile
+++ b/arch/arm/mach-vexpress/Makefile
@@ -4,5 +4,6 @@
 
 obj-y					:= v2m.o
 obj-$(CONFIG_ARCH_VEXPRESS_CA9X4)	+= ct-ca9x4.o
+obj-$(CONFIG_ARCH_VEXPRESS_V2P_CA5S_CA9) += v2p-ca5s_ca9.o
 obj-$(CONFIG_SMP)			+= platsmp.o
 obj-$(CONFIG_HOTPLUG_CPU)		+= hotplug.o
diff --git a/arch/arm/mach-vexpress/v2p-ca5s_ca9.c b/arch/arm/mach-vexpress/v2p-ca5s_ca9.c
new file mode 100644
index 0000000..e2a7acd
--- /dev/null
+++ b/arch/arm/mach-vexpress/v2p-ca5s_ca9.c
@@ -0,0 +1,115 @@
+/*
+ * Device Tree based support for ARM Versatile Express platform using:
+ * - CoreTile Express A5x2 (V2P-CA5s)
+ * - CoreTile Express A9x4 (V2P-CA9)
+ */
+
+#include <linux/init.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+
+#include <asm/smp_scu.h>
+#include <asm/smp_twd.h>
+#include <asm/hardware/cache-l2x0.h>
+#include <asm/hardware/gic.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+
+#include <mach/motherboard.h>
+
+#include "core.h"
+
+#define A5_A9_MPCORE_SCU	0x0000
+#define A5_A9_MPCORE_TWD	0x0600
+
+static struct map_desc v2p_ca5s_ca9_io_desc[] __initdata = {
+	{
+		.virtual	= V2T_PERIPH,
+		/* .pfn	set in v2p_ca5s_ca9_map_io() */
+		.length		= SZ_8K,
+		.type		= MT_DEVICE,
+	},
+};
+
+#ifdef CONFIG_SMP
+static void __init v2p_ca5s_ca9_init_cpu_map(void)
+{
+	int i, ncores = scu_get_core_count(V2T_PERIPH_P2V(A5_A9_MPCORE_SCU));
+
+	if (ncores > nr_cpu_ids) {
+		pr_warn("SMP: %u cores greater than maximum (%u), clipping\n",
+				ncores, nr_cpu_ids);
+		ncores = nr_cpu_ids;
+	}
+
+	for (i = 0; i < ncores; ++i)
+		set_cpu_possible(i, true);
+
+	set_smp_cross_call(gic_raise_softirq);
+}
+
+static void __init v2p_ca5s_ca9_smp_enable(unsigned int max_cpus)
+{
+	scu_enable(V2T_PERIPH_P2V(A5_A9_MPCORE_SCU));
+}
+
+static struct ct_desc v2p_ca5s_ca9_smp_callbacks __initdata = {
+	.init_cpu_map = v2p_ca5s_ca9_init_cpu_map,
+	.smp_enable = v2p_ca5s_ca9_smp_enable,
+};
+#endif
+
+static void __init v2p_ca5s_ca9_map_io(void)
+{
+	u32 mpcore_periph;
+
+	asm("mrc p15, 4, %0, c15, c0, 0" : "=r" (mpcore_periph));
+	v2p_ca5s_ca9_io_desc[0].pfn = __phys_to_pfn(mpcore_periph);
+	iotable_init(v2p_ca5s_ca9_io_desc, ARRAY_SIZE(v2p_ca5s_ca9_io_desc));
+
+	v2m_dt_map_io();
+
+#ifdef CONFIG_SMP
+	ct_desc = &v2p_ca5s_ca9_smp_callbacks;
+#endif
+}
+
+static void __init v2p_ca5s_ca9_init_early(void)
+{
+#ifdef CONFIG_LOCAL_TIMERS
+	twd_base = V2T_PERIPH_P2V(A5_A9_MPCORE_TWD);
+#endif
+	v2m_dt_init_early();
+}
+
+static  struct of_device_id v2p_ca5s_ca9_irq_match[] __initdata = {
+	{ .compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
+	{}
+};
+
+static void __init v2p_ca5s_ca9_init_irq(void)
+{
+	of_irq_init(v2p_ca5s_ca9_irq_match);
+}
+
+static void __init v2p_ca5s_ca9_init(void)
+{
+	l2x0_of_init(0x00400000, 0xfe0fffff);
+	of_platform_populate(NULL, of_default_bus_match_table,
+			v2m_dt_get_auxdata(), NULL);
+}
+
+static const char *v2p_ca5s_ca9_dt_match[] __initdata = {
+	"arm,vexpress-v2p-ca5s",
+	"arm,vexpress-v2p-ca9",
+	NULL,
+};
+
+DT_MACHINE_START(VEXPRESS_V2P_CA5S_CA9, "ARM Versatile Express")
+	.map_io		= v2p_ca5s_ca9_map_io,
+	.init_early	= v2p_ca5s_ca9_init_early,
+	.init_irq	= v2p_ca5s_ca9_init_irq,
+	.timer		= &v2m_dt_timer,
+	.init_machine	= v2p_ca5s_ca9_init,
+	.dt_compat	= v2p_ca5s_ca9_dt_match,
+MACHINE_END
-- 
1.6.3.3

Re: [PATCH v3 5/5] ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4

[Dave Martin]

On Tue, Nov 29, 2011 at 03:11:13PM +0000, Pawel Moll wrote:
> This patch adds Device Trees for ARM Ltd. CoreTile Express A5x2
> and CoreTile Express A9x4 used with V2M motherboard and an initial
> implementation of the DT machine support (this code is separate
> from the current core tile code).
> 
> Signed-off-by: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> ---
>  arch/arm/boot/dts/vexpress-v2p-ca5s.dts |  131 ++++++++++++++++++++++++++++
>  arch/arm/boot/dts/vexpress-v2p-ca9.dts  |  145 +++++++++++++++++++++++++++++++
>  arch/arm/mach-vexpress/Kconfig          |   23 +++++
>  arch/arm/mach-vexpress/Makefile         |    1 +
>  arch/arm/mach-vexpress/v2p-ca5s_ca9.c   |  115 ++++++++++++++++++++++++
>  5 files changed, 415 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/boot/dts/vexpress-v2p-ca5s.dts
>  create mode 100644 arch/arm/boot/dts/vexpress-v2p-ca9.dts
>  create mode 100644 arch/arm/mach-vexpress/v2p-ca5s_ca9.c
> 
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
> new file mode 100644
> index 0000000..e63c251
> --- /dev/null
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
> @@ -0,0 +1,131 @@
> +/*
> + * ARM Ltd. Versatile Express
> + *
> + * CoreTile Express A5x2
> + * Cortex-A5 MPCore (V2P-CA5s)
> + *
> + * HBI-0225B
> + */
> +
> +/dts-v1/;
> +
> +/include/ "skeleton.dtsi"
> +
> +/ {
> +	model = "V2P-CA5s";
> +	arm,hbi = <0x225>;
> +	compatible = "arm,vexpress-v2p-ca5s";
> +	interrupt-parent = <&gic>;
> +
> +	aliases {
> +		serial0 = &v2m_serial0;
> +		serial1 = &v2m_serial1;
> +		serial2 = &v2m_serial2;
> +		serial3 = &v2m_serial3;
> +		i2c0 = &v2m_i2c_dvi;
> +		i2c1 = &v2m_i2c_pcie;
> +	};
> +
> +	memory@80000000 {
> +		device_type = "memory";
> +		reg = <0x80000000 0x40000000>;
> +	};
> +
> +	hdlcd@2a110000 {
> +		compatible = "arm,hdlcd";
> +		reg = <0x2a110000 0x1000>;
> +		interrupts = <0 85 4>;
> +	};
> +
> +	memory-controller@2a150000 {
> +		compatible = "arm,pl341", "arm,primecell";
> +		reg = <0x2a150000 0x1000>;
> +	};
> +
> +	memory-controller@2a190000 {
> +		compatible = "arm,pl354", "arm,primecell";
> +		reg = <0x2a190000 0x1000>;
> +		interrupts = <0 86 4>,
> +			     <0 87 4>;
> +	};
> +
> +	gic: interrupt-controller@2c001000 {
> +		compatible = "arm,cortex-a9-gic";
> +		#interrupt-cells = <3>;
> +		#address-cells = <0>;
> +		interrupt-controller;
> +		reg = <0x2c001000 0x1000>,
> +		      <0x2c000100 0x100>;
> +	};
> +
> +	L2: cache-controller@2c0f0000 {
> +		compatible = "arm,pl310-cache";
> +		reg = <0x2c0f0000 0x1000>;
> +		interrupts = <0 84 4>;
> +		cache-level = <2>;
> +		arm,data-latency = <0>;
> +		arm,tag-latency = <0>;
> +	};
> +
> +	pmu {
> +		compatible = "arm,cortex-a9-pmu";
> +		interrupts = <0 68 4>,
> +			     <0 69 4>;
> +	};
> +
> +	motherboard {
> +		ranges = <0 0 0x08000000 0x04000000>,
> +			 <1 0 0x14000000 0x04000000>,
> +			 <2 0 0x18000000 0x04000000>,
> +			 <3 0 0x1c000000 0x04000000>,
> +			 <4 0 0x0c000000 0x04000000>,
> +			 <5 0 0x10000000 0x04000000>;
> +
> +		interrupt-map-mask = <0 0 63>;
> +		interrupt-map = <0 0  0 &gic 0  0 4>,
> +				<0 0  1 &gic 0  1 4>,
> +				<0 0  2 &gic 0  2 4>,
> +				<0 0  3 &gic 0  3 4>,
> +				<0 0  4 &gic 0  4 4>,
> +				<0 0  5 &gic 0  5 4>,
> +				<0 0  6 &gic 0  6 4>,
> +				<0 0  7 &gic 0  7 4>,
> +				<0 0  8 &gic 0  8 4>,
> +				<0 0  9 &gic 0  9 4>,
> +				<0 0 10 &gic 0 10 4>,
> +				<0 0 11 &gic 0 11 4>,
> +				<0 0 12 &gic 0 12 4>,
> +				<0 0 13 &gic 0 13 4>,
> +				<0 0 14 &gic 0 14 4>,
> +				<0 0 15 &gic 0 15 4>,
> +				<0 0 16 &gic 0 16 4>,
> +				<0 0 17 &gic 0 17 4>,
> +				<0 0 18 &gic 0 18 4>,
> +				<0 0 19 &gic 0 19 4>,
> +				<0 0 20 &gic 0 20 4>,
> +				<0 0 21 &gic 0 21 4>,
> +				<0 0 22 &gic 0 22 4>,
> +				<0 0 23 &gic 0 23 4>,
> +				<0 0 24 &gic 0 24 4>,
> +				<0 0 25 &gic 0 25 4>,
> +				<0 0 26 &gic 0 26 4>,
> +				<0 0 27 &gic 0 27 4>,
> +				<0 0 28 &gic 0 28 4>,
> +				<0 0 29 &gic 0 29 4>,
> +				<0 0 30 &gic 0 30 4>,
> +				<0 0 31 &gic 0 31 4>,
> +				<0 0 32 &gic 0 32 4>,
> +				<0 0 33 &gic 0 33 4>,
> +				<0 0 34 &gic 0 34 4>,
> +				<0 0 35 &gic 0 35 4>,
> +				<0 0 36 &gic 0 36 4>,
> +				<0 0 37 &gic 0 37 4>,
> +				<0 0 38 &gic 0 38 4>,
> +				<0 0 39 &gic 0 39 4>,
> +				<0 0 40 &gic 0 40 4>,
> +				<0 0 41 &gic 0 41 4>,
> +				<0 0 42 &gic 0 42 4>;
> +	};
> +};
> +
> +/include/ "vexpress-v2m-rs1.dtsi"
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca9.dts b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
> new file mode 100644
> index 0000000..c51fe09
> --- /dev/null
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
> @@ -0,0 +1,145 @@
> +/*
> + * ARM Ltd. Versatile Express
> + *
> + * CoreTile Express A9x4
> + * Cortex-A9 MPCore (V2P-CA9)
> + *
> + * HBI-0191B
> + */
> +
> +/dts-v1/;
> +
> +/include/ "skeleton.dtsi"
> +
> +/ {
> +	model = "V2P-CA9";
> +	arm,hbi = <0x191>;
> +	compatible = "arm,vexpress-v2p-ca9";
> +	interrupt-parent = <&gic>;
> +
> +	aliases {
> +		serial0 = &v2m_serial0;
> +		serial1 = &v2m_serial1;
> +		serial2 = &v2m_serial2;
> +		serial3 = &v2m_serial3;
> +		i2c0 = &v2m_i2c_dvi;
> +		i2c1 = &v2m_i2c_pcie;
> +	};
> +
> +	memory@60000000 {
> +		device_type = "memory";
> +		reg = <0x60000000 0x40000000>;
> +	};
> +
> +	clcd@10020000 {
> +		compatible = "arm,pl111", "arm,primecell";
> +		reg = <0x10020000 0x1000>;
> +		interrupts = <0 44 4>;
> +	};
> +
> +	memory-controller@100e0000 {
> +		compatible = "arm,pl341", "arm,primecell";
> +		reg = <0x100e0000 0x1000>;
> +	};
> +
> +	memory-controller@100e1000 {
> +		compatible = "arm,pl354", "arm,primecell";
> +		reg = <0x100e1000 0x1000>;
> +		interrupts = <0 45 4>,
> +			     <0 46 4>;
> +	};
> +
> +	timer@100e4000 {
> +		compatible = "arm,sp804", "arm,primecell";
> +		reg = <0x100e4000 0x1000>;
> +		interrupts = <0 48 4>,
> +			     <0 49 4>;
> +	};
> +
> +	watchdog@100e5000 {
> +		compatible = "arm,sp805", "arm,primecell";
> +		reg = <0x100e5000 0x1000>;
> +		interrupts = <0 51 4>;
> +	};
> +
> +	gic: interrupt-controller@1e001000 {
> +		compatible = "arm,cortex-a9-gic";
> +		#interrupt-cells = <3>;
> +		#address-cells = <0>;
> +		interrupt-controller;
> +		reg = <0x1e001000 0x1000>,
> +		      <0x1e000100 0x100>;
> +	};
> +
> +	L2: cache-controller@1e00a000 {
> +		compatible = "arm,pl310-cache";
> +		reg = <0x1e00a000 0x1000>;
> +		interrupts = <0 43 4>;
> +		cache-level = <2>;
> +		arm,data-latency = <0>;
> +		arm,tag-latency = <0>;
> +	};
> +
> +	pmu {
> +		compatible = "arm,cortex-a9-pmu";
> +		interrupts = <0 60 4>,
> +			     <0 61 4>,
> +			     <0 62 4>,
> +			     <0 63 4>;
> +	};
> +
> +	motherboard {
> +		ranges = <0 0 0x40000000 0x04000000>,
> +			 <1 0 0x44000000 0x04000000>,
> +			 <2 0 0x48000000 0x04000000>,
> +			 <3 0 0x4c000000 0x04000000>,
> +			 <7 0 0x10000000 0x00020000>;
> +
> +		interrupt-map-mask = <0 0 63>;
> +		interrupt-map = <0 0  0 &gic 0  0 4>,
> +				<0 0  1 &gic 0  1 4>,
> +				<0 0  2 &gic 0  2 4>,
> +				<0 0  3 &gic 0  3 4>,
> +				<0 0  4 &gic 0  4 4>,
> +				<0 0  5 &gic 0  5 4>,
> +				<0 0  6 &gic 0  6 4>,
> +				<0 0  7 &gic 0  7 4>,
> +				<0 0  8 &gic 0  8 4>,
> +				<0 0  9 &gic 0  9 4>,
> +				<0 0 10 &gic 0 10 4>,
> +				<0 0 11 &gic 0 11 4>,
> +				<0 0 12 &gic 0 12 4>,
> +				<0 0 13 &gic 0 13 4>,
> +				<0 0 14 &gic 0 14 4>,
> +				<0 0 15 &gic 0 15 4>,
> +				<0 0 16 &gic 0 16 4>,
> +				<0 0 17 &gic 0 17 4>,
> +				<0 0 18 &gic 0 18 4>,
> +				<0 0 19 &gic 0 19 4>,
> +				<0 0 20 &gic 0 20 4>,
> +				<0 0 21 &gic 0 21 4>,
> +				<0 0 22 &gic 0 22 4>,
> +				<0 0 23 &gic 0 23 4>,
> +				<0 0 24 &gic 0 24 4>,
> +				<0 0 25 &gic 0 25 4>,
> +				<0 0 26 &gic 0 26 4>,
> +				<0 0 27 &gic 0 27 4>,
> +				<0 0 28 &gic 0 28 4>,
> +				<0 0 29 &gic 0 29 4>,
> +				<0 0 30 &gic 0 30 4>,
> +				<0 0 31 &gic 0 31 4>,
> +				<0 0 32 &gic 0 32 4>,
> +				<0 0 33 &gic 0 33 4>,
> +				<0 0 34 &gic 0 34 4>,
> +				<0 0 35 &gic 0 35 4>,
> +				<0 0 36 &gic 0 36 4>,
> +				<0 0 37 &gic 0 37 4>,
> +				<0 0 38 &gic 0 38 4>,
> +				<0 0 39 &gic 0 39 4>,
> +				<0 0 40 &gic 0 40 4>,
> +				<0 0 41 &gic 0 41 4>,
> +				<0 0 42 &gic 0 42 4>;
> +	};
> +};
> +
> +/include/ "vexpress-v2m.dtsi"
> diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
> index 2180888..9eb8161 100644
> --- a/arch/arm/mach-vexpress/Kconfig
> +++ b/arch/arm/mach-vexpress/Kconfig
> @@ -23,4 +23,27 @@ config ARCH_VEXPRESS_RS1
>  	  RS1 VE memory map (i.a. motherboard peripherals at
>  	  0x1c000000, RAM at 0x80000000).
>  
> +config ARCH_VEXPRESS_V2P_CA5S_CA9
> +	bool "CoreTile Express A5x2 and A9x4 based platform support"
> +	select CPU_V7
> +	select ARM_GIC
> +	select ARCH_VEXPRESS_RS1
> +	select ARCH_VEXPRESS_DT
> +	select ARM_ERRATA_720789
> +	select ARM_ERRATA_751472
> +	select PL310_ERRATA_753970 if CACHE_PL310

The config option for L2x0/PL310 doesn't get selected for this platform.
Rather than bloat the list in arch/arm/mm/Kconfig each time we add a
coretile (and get a merge conflict with anyone else adding a platform
with an L2CC) I've posted a patch to attempt to factorise that:

ARM: pl2x0/pl310: Refactor Kconfig to be more maintainable

If this looks OK and nobody objects, I suggest to build on top of that.


Note that select PL310_ERRATA_753970 if CACHE_PL310 also needs to be
propagated to ARCH_VEXPRESS_CA9X4.  Maybe we should have a common symbol
which selects/depends on the common stuff instead of duplicating it for
every coretile -- they will tend to get out of sync.

Cheers
---Dave

Re: [PATCH v3 5/5] ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4

[Pawel Moll]

On Tue, 2011-11-29 at 16:40 +0000, Dave Martin wrote:
> Note that select PL310_ERRATA_753970 if CACHE_PL310 also needs to be
> propagated to ARCH_VEXPRESS_CA9X4.  Maybe we should have a common symbol
> which selects/depends on the common stuff instead of duplicating it for
> every coretile -- they will tend to get out of sync.

How about that?

8<--------------------------------------------------------------
menu "Versatile Express platform type"
	depends on ARCH_VEXPRESS

config ARCH_VEXPRESS_CORTEX_A5_A9
	bool
	select ARM_ERRATA_720789
	select ARM_ERRATA_751472
	select ARM_GIC
	select CPU_V7
	select HAVE_L2X0_L2CC
	select PL310_ERRATA_753970 if CACHE_PL310
	help
	  VE platforms based on Cortex-A5 or Cortex-A9 processors.

config ARCH_VEXPRESS_CA9X4
	bool "Versatile Express Cortex-A9x4 tile"
	select ARCH_VEXPRESS_CORTEX_A5_A9
	help
	  This option enabled support for VE system using original
	  CoreTile Express A9x4 (V2P-CA9) initialized with ATAGs.

config ARCH_VEXPRESS_RS1
	bool
	select ARM_PATCH_PHYS_VIRT
	select AUTO_ZRELADDR
	help
	  RS1 VE memory map (i.a. motherboard peripherals at
	  0x1c000000, RAM at 0x80000000).

config ARCH_VEXPRESS_DT
	bool
	select USE_OF
	help
	  VE platforms *requiring* Flattened Device Tree to boot.

config ARCH_VEXPRESS_V2P_CA5S_CA9
	bool "CoreTile Express A5x2 and A9x4 based platform support"
	select ARCH_VEXPRESS_CORTEX_A5_A9
	select ARCH_VEXPRESS_DT
	select ARCH_VEXPRESS_RS1
	help
	  This option enables support for systems using any of the following
	  ARM core tiles on the Versatile Express motherboard:

	  - CoreTile Express A5x2 (V2P-CA5s)
	  - CoreTile Express A9x4 (V2P-CA9)

	  You must boot using a Flattened Device Tree in order to use these
	  platforms.  The traditional (ATAGs) boot method is not usable on
	  these boards with this option.

	  If you want your kernel to run on one of these platforms and your
	  bootloader supports Flattened Device Tree based booting, say Y.

endmenu
8<-------------------------------------------------------------- 

Cheers!

Pawel

Re: [PATCH v3 5/5] ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4

[Dave Martin]

On Wed, Nov 30, 2011 at 06:39:24PM +0000, Pawel Moll wrote:
> On Tue, 2011-11-29 at 16:40 +0000, Dave Martin wrote:
> > Note that select PL310_ERRATA_753970 if CACHE_PL310 also needs to be
> > propagated to ARCH_VEXPRESS_CA9X4.  Maybe we should have a common symbol
> > which selects/depends on the common stuff instead of duplicating it for
> > every coretile -- they will tend to get out of sync.
> 
> How about that?
> 
> 8<--------------------------------------------------------------
> menu "Versatile Express platform type"
> 	depends on ARCH_VEXPRESS
> 
> config ARCH_VEXPRESS_CORTEX_A5_A9
> 	bool
> 	select ARM_ERRATA_720789
> 	select ARM_ERRATA_751472
> 	select ARM_GIC
> 	select CPU_V7
> 	select HAVE_L2X0_L2CC
> 	select PL310_ERRATA_753970 if CACHE_PL310
> 	help
> 	  VE platforms based on Cortex-A5 or Cortex-A9 processors.

That will work, but we should make it clear that this option does not
provide board support all by itself, maybe:

"Provides common dependencies for VE platforms based on Cortex-A5 or
Cortex-A9 processors.  In order to build a working kernel, you must also
enable one or more core tile support options."

Cheers
---Dave

Re: [PATCH v3 5/5] ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4

[Pawel Moll]

On Thu, 2011-12-01 at 12:21 +0000, Dave Martin wrote:
> That will work, but we should make it clear that this option does not
> provide board support all by itself, maybe:
> 
> "Provides common dependencies for VE platforms based on Cortex-A5 or
> Cortex-A9 processors.  In order to build a working kernel, you must also
> enable one or more core tile support options."

Actually, the longer I think about it the more it seems that this code
doesn't support a particular tile, but rather a particular processor...
After all _exactly_ the same code will work with any SMM based on FPGA
Logic Tile (V2F-2XV6), even if it was very different from the coretile,
eg. A9 with RS1 memory map. In such case making it compatible with
V2P-CA9 would be logically wrong...

I have an idea of spinning the compatible values again to get something
like that:

compatible = "arm,vexpress-v2p-ca5s", "arm,vexpress-cortex_a5";
compatible = "arm,vexpress-v2p-ca9", "arm,vexpress-cortex_a9";
compatible = "arm,vexpress-v2p-ca15", "arm,vexpress-cortex_a15";

and the board code would simply have:

static const char *dt_ca5_ca9_dt_match[] __initdata = {
	"arm,vexpress-cortex_a5",
	"arm,vexpress-cortex_a9",
	NULL,
};

I've already tried that (adding tree for A15 tile as well) and it
actually simplifies a lot of things. I'll clean the patches, test them
and post tomorrow. Of course if anyone thinks it's a bad idea I'm happy
to get back to where we were last week.

Cheers!

Paweł



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 5/5] ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4

[Dave Martin]

On Mon, Dec 05, 2011 at 05:24:40PM +0000, Pawel Moll wrote:
> On Thu, 2011-12-01 at 12:21 +0000, Dave Martin wrote:
> > That will work, but we should make it clear that this option does not
> > provide board support all by itself, maybe:
> > 
> > "Provides common dependencies for VE platforms based on Cortex-A5 or
> > Cortex-A9 processors.  In order to build a working kernel, you must also
> > enable one or more core tile support options."
> 
> Actually, the longer I think about it the more it seems that this code
> doesn't support a particular tile, but rather a particular processor...
> After all _exactly_ the same code will work with any SMM based on FPGA
> Logic Tile (V2F-2XV6), even if it was very different from the coretile,
> eg. A9 with RS1 memory map. In such case making it compatible with
> V2P-CA9 would be logically wrong...
> 
> I have an idea of spinning the compatible values again to get something
> like that:
> 
> compatible = "arm,vexpress-v2p-ca5s", "arm,vexpress-cortex_a5";
> compatible = "arm,vexpress-v2p-ca9", "arm,vexpress-cortex_a9";
> compatible = "arm,vexpress-v2p-ca15", "arm,vexpress-cortex_a15";

The trouble is, node { compatible = x } means "node is an x", not "node
has an x".

So, we should be careful do document what e.g. arm,vexpress-cortex_a5
actually means.  It doesn't mean Cortex-A5, but instead it represents
a whole jumble of characteristics which we expect to be common to all
vexpress-based A5 platforms.

It feels that in practice arm,vexpress-cortex_a5 actually means 
exactly the same thing as arm,vexpress-v2p-ca5s.  Are you sure these
two are really independent?  (In other words, do we expect multiple
different vexpress variants based on A5, and so on?)

Cheers
---Dave

Re: [PATCH v3 5/5] ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4

[Pawel Moll]

On Mon, 2011-12-05 at 17:37 +0000, Dave Martin wrote:
> > I have an idea of spinning the compatible values again to get something
> > like that:
> > 
> > compatible = "arm,vexpress-v2p-ca5s", "arm,vexpress-cortex_a5";
> > compatible = "arm,vexpress-v2p-ca9", "arm,vexpress-cortex_a9";
> > compatible = "arm,vexpress-v2p-ca15", "arm,vexpress-cortex_a15";
> 
> The trouble is, node { compatible = x } means "node is an x", not "node
> has an x".

Yes...

> So, we should be careful do document what e.g. arm,vexpress-cortex_a5
> actually means.  It doesn't mean Cortex-A5, but instead it represents
> a whole jumble of characteristics which we expect to be common to all
> vexpress-based A5 platforms.

... so I'd translate it as "is a Versatile Express platform based on
Cortex-A5 processor" and document it as such. As I said - patches
tomorrow.

> It feels that in practice arm,vexpress-cortex_a5 actually means 
> exactly the same thing as arm,vexpress-v2p-ca5s.  Are you sure these
> two are really independent?  (In other words, do we expect multiple
> different vexpress variants based on A5, and so on?)

The examples for A5 I can quota are two different SMMs I used (one on a
"small", second one on a "large" FPGA board), but they were very similar
to the A5 core tile - so similar that you could (probably) use the core
tile DTB to drive them. The A9 SMM with RS1 memory map I've mentioned is
much more interesting case - A9 platform but nothing like original A9
core tile... Also the A15 looks interesting as we will most likely get
the same tiles (as in: PCB) with different processors (as in: different
silicon). This will be fun :-)

Cheers!

Paweł



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 5/5] ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4

[Dave Martin]

On Mon, Dec 05, 2011 at 05:47:36PM +0000, Pawel Moll wrote:
> On Mon, 2011-12-05 at 17:37 +0000, Dave Martin wrote:
> > > I have an idea of spinning the compatible values again to get something
> > > like that:
> > > 
> > > compatible = "arm,vexpress-v2p-ca5s", "arm,vexpress-cortex_a5";
> > > compatible = "arm,vexpress-v2p-ca9", "arm,vexpress-cortex_a9";
> > > compatible = "arm,vexpress-v2p-ca15", "arm,vexpress-cortex_a15";
> > 
> > The trouble is, node { compatible = x } means "node is an x", not "node
> > has an x".
> 
> Yes...
> 
> > So, we should be careful do document what e.g. arm,vexpress-cortex_a5
> > actually means.  It doesn't mean Cortex-A5, but instead it represents
> > a whole jumble of characteristics which we expect to be common to all
> > vexpress-based A5 platforms.
> 
> ... so I'd translate it as "is a Versatile Express platform based on
> Cortex-A5 processor" and document it as such. As I said - patches
> tomorrow.
> 
> > It feels that in practice arm,vexpress-cortex_a5 actually means 
> > exactly the same thing as arm,vexpress-v2p-ca5s.  Are you sure these
> > two are really independent?  (In other words, do we expect multiple
> > different vexpress variants based on A5, and so on?)
> 
> The examples for A5 I can quota are two different SMMs I used (one on a
> "small", second one on a "large" FPGA board), but they were very similar
> to the A5 core tile - so similar that you could (probably) use the core
> tile DTB to drive them. The A9 SMM with RS1 memory map I've mentioned is
> much more interesting case - A9 platform but nothing like original A9
> core tile... Also the A15 looks interesting as we will most likely get
> the same tiles (as in: PCB) with different processors (as in: different
> silicon). This will be fun :-)

OK -- your knowledge of what's going on in hardware-land is better than
mine, so I'm happy to go along with this.

So long as those compatible strings are carefully documented to that
their meanings don't get blurred over time, your proposal seems to make
sense.

Cheers
---Dave

Re: [PATCH v3 0/5] Versatile Express DT support

[Dave Martin]

On Tue, Nov 29, 2011 at 03:11:08PM +0000, Pawel Moll wrote:
> Hi All,
> 
> Another, hopefully close to the final, version of the series...
> 
> Changes from v2:
> 
> * new patch adding ENDPROC at the end of arch/arm/plat-versatile/headsmp.S
>   and removing use of BSYM() realview and vexpress platform SMP calls
> 
> * updated binding documentation according to Dave's comments
> 
> * changed motherboard labels prefix from mb_ to v2m_ (to be
>   consistent across code and DT files)
> 
> * reworked v2m timer initialization (again) so no #ifdefs are required
>   in non-DT code
> 
> * renamed (to vendor- and platform-specific "arm,v2m-timer") and moved
>   (to vexpress-v2m*.dtsi files) timer DT alias, as it is actually
>   motherboard specific and the tile DTS shouldn't have to care;
>   documentation updated accordingly
> 
> Tested on V2P-CA9 with ATAGs and DT and on V2P-CA5s with DT.
> 
> Previous version has been also tested by Ryan Harkin and
> provisionally acked by Rob Herring.
> 
> Thanks for all your help, especially to Dave for his continuous support!

I'm trying to build... what tree are you basing on?

With v3.2-rc3 or next, I get OF header failures like the following:

arch/arm/kernel/devtree.c: In function ‘arm_dt_memblock_reserve’:
arch/arm/kernel/devtree.c:41:7: error: ‘initial_boot_params’ undeclared (first use in this function)
arch/arm/kernel/devtree.c:41:7: note: each undeclared identifier is reported only once for each function it appears in

[...]

arch/arm/mach-vexpress/v2m.c: In function ‘v2m_dt_scan_memory_map’:
arch/arm/mach-vexpress/v2m.c:529:2: error: implicit declaration of function ‘of_get_flat_dt_prop’
arch/arm/mach-vexpress/v2m.c:529:7: warning: assignment makes pointer from integer without a cast

arch/arm/mach-vexpress/v2m.c: In function ‘v2m_dt_map_io’:
arch/arm/mach-vexpress/v2m.c:538:2: error: implicit declaration of function ‘of_scan_flat_dt’

Cheers
---Dave
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v3 0/5] Versatile Express DT support

[Pawel Moll]

On Tue, 2011-11-29 at 17:00 +0000, Dave Martin wrote:
> I'm trying to build... what tree are you basing on?

v3.2-rc3:

$ git log --oneline HEAD...v3.2-rc3~
3b9df1e ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4
5a1c565 ARM: vexpress: Initial RS1 memory map support
9355e8a ARM: vexpress: Add DT support in v2m
0529bd6 ARM: vexpress: Get rid of MMIO_P2V
68118cc ARM: versatile: Add missing ENDPROC to headsmp.S
caca6a0 Linux 3.2-rc3

> With v3.2-rc3 or next, I get OF header failures like the following:
> 
> arch/arm/kernel/devtree.c: In function ‘arm_dt_memblock_reserve’:
> arch/arm/kernel/devtree.c:41:7: error: ‘initial_boot_params’ undeclared (first use in this function)
> arch/arm/kernel/devtree.c:41:7: note: each undeclared identifier is reported only once for each function it appears in
[...]

Can you send me your config, please?

Also, I forgot to mention that you need Rob's "of/irq: of_irq_init: add
check for parent equal to child
node" (http://article.gmane.org/gmane.linux.kernel/1221051) to get this
working.

Cheers!

Paweł



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 0/5] Versatile Express DT support

[Dave Martin]

[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]

On Tue, Nov 29, 2011 at 05:16:59PM +0000, Pawel Moll wrote:
> On Tue, 2011-11-29 at 17:00 +0000, Dave Martin wrote:
> > I'm trying to build... what tree are you basing on?
> 
> v3.2-rc3:
> 
> $ git log --oneline HEAD...v3.2-rc3~
> 3b9df1e ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4
> 5a1c565 ARM: vexpress: Initial RS1 memory map support
> 9355e8a ARM: vexpress: Add DT support in v2m
> 0529bd6 ARM: vexpress: Get rid of MMIO_P2V
> 68118cc ARM: versatile: Add missing ENDPROC to headsmp.S
> caca6a0 Linux 3.2-rc3
> 
> > With v3.2-rc3 or next, I get OF header failures like the following:
> > 
> > arch/arm/kernel/devtree.c: In function ‘arm_dt_memblock_reserve’:
> > arch/arm/kernel/devtree.c:41:7: error: ‘initial_boot_params’ undeclared (first use in this function)
> > arch/arm/kernel/devtree.c:41:7: note: each undeclared identifier is reported only once for each function it appears in
> [...]
> 
> Can you send me your config, please?

Attached.  It's just vexpress_defconfig, plus ARCH_VEXPRESS_V2P_CA5S_CA9=y

OK, I'll pull that in too.

Cheers
---Dave

[-- Attachment #2: defconfig.gz --]
[-- Type: application/octet-stream, Size: 1072 bytes --]

[-- Attachment #3: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v3 0/5] Versatile Express DT support

[Pawel Moll]

On Wed, 2011-11-30 at 10:48 +0000, Dave Martin wrote:
> Attached.  It's just vexpress_defconfig, plus ARCH_VEXPRESS_V2P_CA5S_CA9=y

Could you try that?

8<----------------------------------------------
diff --git a/arch/arm/mach-vexpress/Kconfig
b/arch/arm/mach-vexpress/Kconfig
index 9eb8161..ded66d0 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig
@@ -11,7 +11,7 @@ config ARCH_VEXPRESS_CA9X4
 
 config ARCH_VEXPRESS_DT
        bool
-       select OF
+       select USE_OF
        help
          VE platform *requiring* Flattened Device Tree to boot.
8<----------------------------------------------

The OF is an effect of the USE_OF, not the other way round, sorry about
the mistake.

Of course I could go the "classic way" and make the
ARCH_VEXPRESS_V2P_CA5S_CA9 dependant on the OF, but this means that the
DT-powered tile would be invisible till one enables USE_OF. Any
opinions?

Cheers!

Paweł



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 0/5] Versatile Express DT support

[Dave Martin]

On Wed, Nov 30, 2011 at 11:14:00AM +0000, Pawel Moll wrote:
> On Wed, 2011-11-30 at 10:48 +0000, Dave Martin wrote:
> > Attached.  It's just vexpress_defconfig, plus ARCH_VEXPRESS_V2P_CA5S_CA9=y
> 
> Could you try that?
> 
> 8<----------------------------------------------
> diff --git a/arch/arm/mach-vexpress/Kconfig
> b/arch/arm/mach-vexpress/Kconfig
> index 9eb8161..ded66d0 100644
> --- a/arch/arm/mach-vexpress/Kconfig
> +++ b/arch/arm/mach-vexpress/Kconfig
> @@ -11,7 +11,7 @@ config ARCH_VEXPRESS_CA9X4
>  
>  config ARCH_VEXPRESS_DT
>         bool
> -       select OF
> +       select USE_OF
>         help
>           VE platform *requiring* Flattened Device Tree to boot.
> 8<----------------------------------------------
> 
> The OF is an effect of the USE_OF, not the other way round, sorry about
> the mistake.
> 
> Of course I could go the "classic way" and make the
> ARCH_VEXPRESS_V2P_CA5S_CA9 dependant on the OF, but this means that the
> DT-powered tile would be invisible till one enables USE_OF. Any
> opinions?

Your suggestion fixes it -- I suggest we keep the config this way round;
this means that OF gets turned on when enabling a coretile which requires
it, and those coretiles are offered as choices even before OF is turned
on.  That feels like a sensible behaviour for the config.


While we're about this, building of the applicable dtbs is not currently
enabled.

Can we add this, so that "make dtbs" works?

diff --git a/arch/arm/mach-vexpress/Makefile.boot b/arch/arm/mach-vexpress/Makefile.boot
index 05b77a5..b89ffde 100644
--- a/arch/arm/mach-vexpress/Makefile.boot
+++ b/arch/arm/mach-vexpress/Makefile.boot
@@ -7,3 +7,7 @@ else
 params_phys-y	:= 0x60000100
 initrd_phys-y	:= 0x60800000
 endif
+
+dtb-$(CONFIG_ARCH_VEXPRESS_V2P_CA5S_CA9) += \
+					vexpress-v2p-ca5s.dtb \
+					vexpress-v2p-ca9.dtb

Cheers
---Dave

Re: [PATCH v3 0/5] Versatile Express DT support

[Pawel Moll]

On Wed, 2011-11-30 at 12:08 +0000, Dave Martin wrote:
> Your suggestion fixes it -- I suggest we keep the config this way round;
> this means that OF gets turned on when enabling a coretile which requires
> it, and those coretiles are offered as choices even before OF is turned
> on.  That feels like a sensible behaviour for the config.

Ok.

> While we're about this, building of the applicable dtbs is not currently
> enabled.
> 
> Can we add this, so that "make dtbs" works?
> 
> diff --git a/arch/arm/mach-vexpress/Makefile.boot b/arch/arm/mach-vexpress/Makefile.boot
> index 05b77a5..b89ffde 100644
> --- a/arch/arm/mach-vexpress/Makefile.boot
> +++ b/arch/arm/mach-vexpress/Makefile.boot
> @@ -7,3 +7,7 @@ else
>  params_phys-y	:= 0x60000100
>  initrd_phys-y	:= 0x60800000
>  endif
> +
> +dtb-$(CONFIG_ARCH_VEXPRESS_V2P_CA5S_CA9) += \
> +					vexpress-v2p-ca5s.dtb \
> +					vexpress-v2p-ca9.dtb

Yes, I already have more-or-less the same thing.

Cheers!

Paweł




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 0/5] Versatile Express DT support

[Arnd Bergmann]

On Tuesday 29 November 2011, Pawel Moll wrote:
> Hi All,
> 
> Another, hopefully close to the final, version of the series...
> 

Yes, looks pretty good now. I've commented on two details, but I couldn't find
any show-stoppers.

	Arnd