* [PATCH v3 0/5] Versatile Express DT support
@ 2011-11-29 15:11 ` Pawel Moll
0 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-29 15:11 UTC (permalink / raw)
To: devicetree-discuss, linux-arm-kernel; +Cc: 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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 0/5] Versatile Express DT support
@ 2011-11-29 15:11 ` Pawel Moll
0 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-29 15:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 1/5] ARM: versatile: Add missing ENDPROC to headsmp.S
2011-11-29 15:11 ` Pawel Moll
@ 2011-11-29 15:11 ` Pawel Moll
-1 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-29 15:11 UTC (permalink / raw)
To: devicetree-discuss, linux-arm-kernel; +Cc: 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
^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH v3 1/5] ARM: versatile: Add missing ENDPROC to headsmp.S
@ 2011-11-29 15:11 ` Pawel Moll
0 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-29 15:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH v3 2/5] ARM: vexpress: Get rid of MMIO_P2V
2011-11-29 15:11 ` Pawel Moll
@ 2011-11-29 15:11 ` Pawel Moll
-1 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-29 15:11 UTC (permalink / raw)
To: devicetree-discuss, linux-arm-kernel; +Cc: 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
^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH v3 2/5] ARM: vexpress: Get rid of MMIO_P2V
@ 2011-11-29 15:11 ` Pawel Moll
0 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-29 15:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m
2011-11-29 15:11 ` Pawel Moll
@ 2011-11-29 15:11 ` Pawel Moll
-1 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-29 15:11 UTC (permalink / raw)
To: devicetree-discuss, linux-arm-kernel; +Cc: 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
^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m
@ 2011-11-29 15:11 ` Pawel Moll
0 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-29 15:11 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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 at 0,00000000 {
+ compatible = "arm,vexpress-flash", "cfi-flash";
+ reg = <0 0x00000000 0x04000000>,
+ <1 0x00000000 0x04000000>;
+ bank-width = <4>;
+ };
+
+ psram at 2,00000000 {
+ compatible = "mtd-ram";
+ reg = <2 0x00000000 0x02000000>;
+ bank-width = <4>;
+ };
+
+ ethernet at 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 at 3,03000000 {
+ compatible = "nxp,usb-isp1761";
+ reg = <3 0x03000000 0x20000>;
+ interrupts = <16>;
+ port1-otg;
+ };
+
+ iofpga at 7,00000000 {
+ compatible = "arm,amba-bus", "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 7 0 0x20000>;
+
+ sysreg at 00000 {
+ compatible = "arm,vexpress-sysreg";
+ reg = <0x00000 0x1000>;
+ };
+
+ sysctl at 01000 {
+ compatible = "arm,sp810", "arm,primecell";
+ reg = <0x01000 0x1000>;
+ };
+
+ /* PCI-E I2C bus */
+ v2m_i2c_pcie: i2c at 02000 {
+ compatible = "arm,versatile-i2c";
+ reg = <0x02000 0x1000>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pcie-switch at 60 {
+ compatible = "idt,89hpes32h8";
+ reg = <0x60>;
+ };
+ };
+
+ aaci at 04000 {
+ compatible = "arm,pl041", "arm,primecell";
+ reg = <0x04000 0x1000>;
+ interrupts = <11>;
+ };
+
+ mmci at 05000 {
+ compatible = "arm,pl180", "arm,primecell";
+ reg = <0x05000 0x1000>;
+ interrupts = <9 10>;
+ };
+
+ kmi at 06000 {
+ compatible = "arm,pl050", "arm,primecell";
+ reg = <0x06000 0x1000>;
+ interrupts = <12>;
+ };
+
+ kmi at 07000 {
+ compatible = "arm,pl050", "arm,primecell";
+ reg = <0x07000 0x1000>;
+ interrupts = <13>;
+ };
+
+ v2m_serial0: uart at 09000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x09000 0x1000>;
+ interrupts = <5>;
+ };
+
+ v2m_serial1: uart at 0a000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x0a000 0x1000>;
+ interrupts = <6>;
+ };
+
+ v2m_serial2: uart at 0b000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x0b000 0x1000>;
+ interrupts = <7>;
+ };
+
+ v2m_serial3: uart at 0c000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x0c000 0x1000>;
+ interrupts = <8>;
+ };
+
+ wdt at 0f000 {
+ compatible = "arm,sp805", "arm,primecell";
+ reg = <0x0f000 0x1000>;
+ interrupts = <0>;
+ };
+
+ v2m_timer01: timer at 11000 {
+ compatible = "arm,sp804", "arm,primecell";
+ reg = <0x11000 0x1000>;
+ interrupts = <2>;
+ };
+
+ v2m_timer23: timer at 12000 {
+ compatible = "arm,sp804", "arm,primecell";
+ reg = <0x12000 0x1000>;
+ };
+
+ /* DVI I2C bus */
+ v2m_i2c_dvi: i2c at 16000 {
+ compatible = "arm,versatile-i2c";
+ reg = <0x16000 0x1000>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dvi-transmitter at 39 {
+ compatible = "sil,sii9022-tpi", "sil,sii9022";
+ reg = <0x39>;
+ };
+
+ dvi-transmitter at 60 {
+ compatible = "sil,sii9022-cpi", "sil,sii9022";
+ reg = <0x60>;
+ };
+ };
+
+ rtc at 17000 {
+ compatible = "arm,pl031", "arm,primecell";
+ reg = <0x17000 0x1000>;
+ interrupts = <4>;
+ };
+
+ compact-flash at 1a000 {
+ compatible = "ata-generic";
+ reg = <0x1a000 0x100
+ 0x1a100 0xf00>;
+ reg-shift = <2>;
+ };
+
+ clcd at 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
^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
2011-11-29 15:11 ` Pawel Moll
@ 2011-11-29 15:11 ` Pawel Moll
-1 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-29 15:11 UTC (permalink / raw)
To: devicetree-discuss, linux-arm-kernel; +Cc: 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
^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
@ 2011-11-29 15:11 ` Pawel Moll
0 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-29 15:11 UTC (permalink / raw)
To: linux-arm-kernel
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 at 0,00000000 {
+ compatible = "arm,vexpress-flash", "cfi-flash";
+ reg = <0 0x00000000 0x04000000>,
+ <4 0x00000000 0x04000000>;
+ bank-width = <4>;
+ };
+
+ psram at 1,00000000 {
+ compatible = "mtd-ram";
+ reg = <1 0x00000000 0x02000000>;
+ bank-width = <4>;
+ };
+
+ ethernet at 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 at 2,03000000 {
+ compatible = "nxp,usb-isp1761";
+ reg = <2 0x03000000 0x20000>;
+ interrupts = <16>;
+ port1-otg;
+ };
+
+ iofpga at 3,00000000 {
+ compatible = "arm,amba-bus", "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 3 0 0x200000>;
+
+ sysreg at 010000 {
+ compatible = "arm,vexpress-sysreg";
+ reg = <0x010000 0x1000>;
+ };
+
+ sysctl at 020000 {
+ compatible = "arm,sp810", "arm,primecell";
+ reg = <0x020000 0x1000>;
+ };
+
+ /* PCI-E I2C bus */
+ v2m_i2c_pcie: i2c at 030000 {
+ compatible = "arm,versatile-i2c";
+ reg = <0x030000 0x1000>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pcie-switch at 60 {
+ compatible = "idt,89hpes32h8";
+ reg = <0x60>;
+ };
+ };
+
+ aaci at 040000 {
+ compatible = "arm,pl041", "arm,primecell";
+ reg = <0x040000 0x1000>;
+ interrupts = <11>;
+ };
+
+ mmci at 050000 {
+ compatible = "arm,pl180", "arm,primecell";
+ reg = <0x050000 0x1000>;
+ interrupts = <9 10>;
+ };
+
+ kmi at 060000 {
+ compatible = "arm,pl050", "arm,primecell";
+ reg = <0x060000 0x1000>;
+ interrupts = <12>;
+ };
+
+ kmi at 070000 {
+ compatible = "arm,pl050", "arm,primecell";
+ reg = <0x070000 0x1000>;
+ interrupts = <13>;
+ };
+
+ v2m_serial0: uart at 090000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x090000 0x1000>;
+ interrupts = <5>;
+ };
+
+ v2m_serial1: uart at 0a0000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x0a0000 0x1000>;
+ interrupts = <6>;
+ };
+
+ v2m_serial2: uart at 0b0000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x0b0000 0x1000>;
+ interrupts = <7>;
+ };
+
+ v2m_serial3: uart at 0c0000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x0c0000 0x1000>;
+ interrupts = <8>;
+ };
+
+ wdt at 0f0000 {
+ compatible = "arm,sp805", "arm,primecell";
+ reg = <0x0f0000 0x1000>;
+ interrupts = <0>;
+ };
+
+ v2m_timer01: timer at 110000 {
+ compatible = "arm,sp804", "arm,primecell";
+ reg = <0x110000 0x1000>;
+ interrupts = <2>;
+ };
+
+ v2m_timer23: timer at 120000 {
+ compatible = "arm,sp804", "arm,primecell";
+ reg = <0x120000 0x1000>;
+ };
+
+ /* DVI I2C bus */
+ v2m_i2c_dvi: i2c at 160000 {
+ compatible = "arm,versatile-i2c";
+ reg = <0x160000 0x1000>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dvi-transmitter at 39 {
+ compatible = "sil,sii9022-tpi", "sil,sii9022";
+ reg = <0x39>;
+ };
+
+ dvi-transmitter at 60 {
+ compatible = "sil,sii9022-cpi", "sil,sii9022";
+ reg = <0x60>;
+ };
+ };
+
+ rtc at 170000 {
+ compatible = "arm,pl031", "arm,primecell";
+ reg = <0x170000 0x1000>;
+ interrupts = <4>;
+ };
+
+ compact-flash at 1a0000 {
+ compatible = "ata-generic";
+ reg = <0x1a0000 0x100
+ 0x1a0100 0xf00>;
+ reg-shift = <2>;
+ };
+
+ clcd at 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
^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH v3 5/5] ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4
2011-11-29 15:11 ` Pawel Moll
@ 2011-11-29 15:11 ` Pawel Moll
-1 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-29 15:11 UTC (permalink / raw)
To: devicetree-discuss, linux-arm-kernel; +Cc: 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
^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH v3 5/5] ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4
@ 2011-11-29 15:11 ` Pawel Moll
0 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-29 15:11 UTC (permalink / raw)
To: linux-arm-kernel
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 at 80000000 {
+ device_type = "memory";
+ reg = <0x80000000 0x40000000>;
+ };
+
+ hdlcd at 2a110000 {
+ compatible = "arm,hdlcd";
+ reg = <0x2a110000 0x1000>;
+ interrupts = <0 85 4>;
+ };
+
+ memory-controller at 2a150000 {
+ compatible = "arm,pl341", "arm,primecell";
+ reg = <0x2a150000 0x1000>;
+ };
+
+ memory-controller at 2a190000 {
+ compatible = "arm,pl354", "arm,primecell";
+ reg = <0x2a190000 0x1000>;
+ interrupts = <0 86 4>,
+ <0 87 4>;
+ };
+
+ gic: interrupt-controller at 2c001000 {
+ compatible = "arm,cortex-a9-gic";
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0x2c001000 0x1000>,
+ <0x2c000100 0x100>;
+ };
+
+ L2: cache-controller at 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 at 60000000 {
+ device_type = "memory";
+ reg = <0x60000000 0x40000000>;
+ };
+
+ clcd at 10020000 {
+ compatible = "arm,pl111", "arm,primecell";
+ reg = <0x10020000 0x1000>;
+ interrupts = <0 44 4>;
+ };
+
+ memory-controller at 100e0000 {
+ compatible = "arm,pl341", "arm,primecell";
+ reg = <0x100e0000 0x1000>;
+ };
+
+ memory-controller at 100e1000 {
+ compatible = "arm,pl354", "arm,primecell";
+ reg = <0x100e1000 0x1000>;
+ interrupts = <0 45 4>,
+ <0 46 4>;
+ };
+
+ timer at 100e4000 {
+ compatible = "arm,sp804", "arm,primecell";
+ reg = <0x100e4000 0x1000>;
+ interrupts = <0 48 4>,
+ <0 49 4>;
+ };
+
+ watchdog at 100e5000 {
+ compatible = "arm,sp805", "arm,primecell";
+ reg = <0x100e5000 0x1000>;
+ interrupts = <0 51 4>;
+ };
+
+ gic: interrupt-controller at 1e001000 {
+ compatible = "arm,cortex-a9-gic";
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0x1e001000 0x1000>,
+ <0x1e000100 0x100>;
+ };
+
+ L2: cache-controller at 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
^ permalink raw reply related [flat|nested] 106+ messages in thread
* Re: [PATCH v3 5/5] ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4
2011-11-29 15:11 ` Pawel Moll
@ 2011-11-29 16:40 ` Dave Martin
-1 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-11-29 16:40 UTC (permalink / raw)
To: Pawel Moll
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 5/5] ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4
@ 2011-11-29 16:40 ` Dave Martin
0 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-11-29 16:40 UTC (permalink / raw)
To: linux-arm-kernel
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@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 at 80000000 {
> + device_type = "memory";
> + reg = <0x80000000 0x40000000>;
> + };
> +
> + hdlcd at 2a110000 {
> + compatible = "arm,hdlcd";
> + reg = <0x2a110000 0x1000>;
> + interrupts = <0 85 4>;
> + };
> +
> + memory-controller at 2a150000 {
> + compatible = "arm,pl341", "arm,primecell";
> + reg = <0x2a150000 0x1000>;
> + };
> +
> + memory-controller at 2a190000 {
> + compatible = "arm,pl354", "arm,primecell";
> + reg = <0x2a190000 0x1000>;
> + interrupts = <0 86 4>,
> + <0 87 4>;
> + };
> +
> + gic: interrupt-controller at 2c001000 {
> + compatible = "arm,cortex-a9-gic";
> + #interrupt-cells = <3>;
> + #address-cells = <0>;
> + interrupt-controller;
> + reg = <0x2c001000 0x1000>,
> + <0x2c000100 0x100>;
> + };
> +
> + L2: cache-controller at 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 at 60000000 {
> + device_type = "memory";
> + reg = <0x60000000 0x40000000>;
> + };
> +
> + clcd at 10020000 {
> + compatible = "arm,pl111", "arm,primecell";
> + reg = <0x10020000 0x1000>;
> + interrupts = <0 44 4>;
> + };
> +
> + memory-controller at 100e0000 {
> + compatible = "arm,pl341", "arm,primecell";
> + reg = <0x100e0000 0x1000>;
> + };
> +
> + memory-controller at 100e1000 {
> + compatible = "arm,pl354", "arm,primecell";
> + reg = <0x100e1000 0x1000>;
> + interrupts = <0 45 4>,
> + <0 46 4>;
> + };
> +
> + timer at 100e4000 {
> + compatible = "arm,sp804", "arm,primecell";
> + reg = <0x100e4000 0x1000>;
> + interrupts = <0 48 4>,
> + <0 49 4>;
> + };
> +
> + watchdog at 100e5000 {
> + compatible = "arm,sp805", "arm,primecell";
> + reg = <0x100e5000 0x1000>;
> + interrupts = <0 51 4>;
> + };
> +
> + gic: interrupt-controller at 1e001000 {
> + compatible = "arm,cortex-a9-gic";
> + #interrupt-cells = <3>;
> + #address-cells = <0>;
> + interrupt-controller;
> + reg = <0x1e001000 0x1000>,
> + <0x1e000100 0x100>;
> + };
> +
> + L2: cache-controller at 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
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 0/5] Versatile Express DT support
2011-11-29 15:11 ` Pawel Moll
@ 2011-11-29 17:00 ` Dave Martin
-1 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-11-29 17:00 UTC (permalink / raw)
To: Pawel Moll
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 0/5] Versatile Express DT support
@ 2011-11-29 17:00 ` Dave Martin
0 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-11-29 17:00 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 0/5] Versatile Express DT support
2011-11-29 17:00 ` Dave Martin
@ 2011-11-29 17:16 ` Pawel Moll
-1 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-29 17:16 UTC (permalink / raw)
To: Dave Martin; +Cc: devicetree-discuss, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 0/5] Versatile Express DT support
@ 2011-11-29 17:16 ` Pawel Moll
0 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-29 17:16 UTC (permalink / raw)
To: linux-arm-kernel
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?
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 2/5] ARM: vexpress: Get rid of MMIO_P2V
2011-11-29 15:11 ` Pawel Moll
@ 2011-11-29 21:15 ` Arnd Bergmann
-1 siblings, 0 replies; 106+ messages in thread
From: Arnd Bergmann @ 2011-11-29 21:15 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: devicetree-discuss, Pawel Moll
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 2/5] ARM: vexpress: Get rid of MMIO_P2V
@ 2011-11-29 21:15 ` Arnd Bergmann
0 siblings, 0 replies; 106+ messages in thread
From: Arnd Bergmann @ 2011-11-29 21:15 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m
2011-11-29 15:11 ` Pawel Moll
@ 2011-11-29 21:19 ` Arnd Bergmann
-1 siblings, 0 replies; 106+ messages in thread
From: Arnd Bergmann @ 2011-11-29 21:19 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: devicetree-discuss, Pawel Moll
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m
@ 2011-11-29 21:19 ` Arnd Bergmann
0 siblings, 0 replies; 106+ messages in thread
From: Arnd Bergmann @ 2011-11-29 21:19 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 29 November 2011, Pawel Moll wrote:
> + compact-flash at 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
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 0/5] Versatile Express DT support
2011-11-29 15:11 ` Pawel Moll
@ 2011-11-29 21:24 ` Arnd Bergmann
-1 siblings, 0 replies; 106+ messages in thread
From: Arnd Bergmann @ 2011-11-29 21:24 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Pawel Moll
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 0/5] Versatile Express DT support
@ 2011-11-29 21:24 ` Arnd Bergmann
0 siblings, 0 replies; 106+ messages in thread
From: Arnd Bergmann @ 2011-11-29 21:24 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 0/5] Versatile Express DT support
2011-11-29 17:16 ` Pawel Moll
@ 2011-11-30 10:48 ` Dave Martin
-1 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-11-30 10:48 UTC (permalink / raw)
To: Pawel Moll
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
[-- 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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 0/5] Versatile Express DT support
@ 2011-11-30 10:48 ` Dave Martin
0 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-11-30 10:48 UTC (permalink / raw)
To: linux-arm-kernel
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: defconfig.gz
Type: application/octet-stream
Size: 1072 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20111130/3b99608b/attachment-0001.obj>
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 0/5] Versatile Express DT support
2011-11-30 10:48 ` Dave Martin
@ 2011-11-30 11:14 ` Pawel Moll
-1 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-30 11:14 UTC (permalink / raw)
To: Dave Martin; +Cc: devicetree-discuss, linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH v3 0/5] Versatile Express DT support
@ 2011-11-30 11:14 ` Pawel Moll
0 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-30 11:14 UTC (permalink / raw)
To: linux-arm-kernel
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?
^ permalink raw reply related [flat|nested] 106+ messages in thread
* Re: [PATCH v3 2/5] ARM: vexpress: Get rid of MMIO_P2V
2011-11-29 21:15 ` Arnd Bergmann
@ 2011-11-30 11:34 ` Pawel Moll
-1 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-30 11:34 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: devicetree-discuss, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 2/5] ARM: vexpress: Get rid of MMIO_P2V
@ 2011-11-30 11:34 ` Pawel Moll
0 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-30 11:34 UTC (permalink / raw)
To: linux-arm-kernel
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?
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m
2011-11-29 21:19 ` Arnd Bergmann
@ 2011-11-30 11:46 ` Pawel Moll
-1 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-30 11:46 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: devicetree-discuss, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m
@ 2011-11-30 11:46 ` Pawel Moll
0 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-30 11:46 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 2011-11-29 at 21:19 +0000, Arnd Bergmann wrote:
> On Tuesday 29 November 2011, Pawel Moll wrote:
> > + compact-flash at 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?
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 0/5] Versatile Express DT support
2011-11-30 11:14 ` Pawel Moll
@ 2011-11-30 12:08 ` Dave Martin
-1 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-11-30 12:08 UTC (permalink / raw)
To: Pawel Moll
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH v3 0/5] Versatile Express DT support
@ 2011-11-30 12:08 ` Dave Martin
0 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-11-30 12:08 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 106+ messages in thread
* Re: [PATCH v3 0/5] Versatile Express DT support
2011-11-30 12:08 ` Dave Martin
@ 2011-11-30 12:15 ` Pawel Moll
-1 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-30 12:15 UTC (permalink / raw)
To: Dave Martin; +Cc: devicetree-discuss, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 0/5] Versatile Express DT support
@ 2011-11-30 12:15 ` Pawel Moll
0 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-30 12:15 UTC (permalink / raw)
To: linux-arm-kernel
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?
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m
2011-11-30 11:46 ` Pawel Moll
@ 2011-11-30 13:34 ` Arnd Bergmann
-1 siblings, 0 replies; 106+ messages in thread
From: Arnd Bergmann @ 2011-11-30 13:34 UTC (permalink / raw)
To: Pawel Moll; +Cc: devicetree-discuss, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m
@ 2011-11-30 13:34 ` Arnd Bergmann
0 siblings, 0 replies; 106+ messages in thread
From: Arnd Bergmann @ 2011-11-30 13:34 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m
2011-11-30 13:34 ` Arnd Bergmann
@ 2011-11-30 13:38 ` Pawel Moll
-1 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-30 13:38 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: devicetree-discuss, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m
@ 2011-11-30 13:38 ` Pawel Moll
0 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-30 13:38 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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?
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 2/5] ARM: vexpress: Get rid of MMIO_P2V
2011-11-30 11:34 ` Pawel Moll
@ 2011-11-30 13:48 ` Arnd Bergmann
-1 siblings, 0 replies; 106+ messages in thread
From: Arnd Bergmann @ 2011-11-30 13:48 UTC (permalink / raw)
To: Pawel Moll
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 2/5] ARM: vexpress: Get rid of MMIO_P2V
@ 2011-11-30 13:48 ` Arnd Bergmann
0 siblings, 0 replies; 106+ messages in thread
From: Arnd Bergmann @ 2011-11-30 13:48 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 2/5] ARM: vexpress: Get rid of MMIO_P2V
2011-11-30 13:48 ` Arnd Bergmann
@ 2011-11-30 13:52 ` Pawel Moll
-1 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-30 13:52 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: devicetree-discuss, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 2/5] ARM: vexpress: Get rid of MMIO_P2V
@ 2011-11-30 13:52 ` Pawel Moll
0 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-30 13:52 UTC (permalink / raw)
To: linux-arm-kernel
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?
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m
2011-11-30 13:38 ` Pawel Moll
@ 2011-11-30 15:10 ` Arnd Bergmann
-1 siblings, 0 replies; 106+ messages in thread
From: Arnd Bergmann @ 2011-11-30 15:10 UTC (permalink / raw)
To: Pawel Moll
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m
@ 2011-11-30 15:10 ` Arnd Bergmann
0 siblings, 0 replies; 106+ messages in thread
From: Arnd Bergmann @ 2011-11-30 15:10 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
2011-11-29 15:11 ` Pawel Moll
@ 2011-11-30 15:37 ` Dave Martin
-1 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-11-30 15:37 UTC (permalink / raw)
To: Pawel Moll
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Tixy,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
@ 2011-11-30 15:37 ` Dave Martin
0 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-11-30 15:37 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m
2011-11-29 15:11 ` Pawel Moll
@ 2011-11-30 15:58 ` Dave Martin
-1 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-11-30 15:58 UTC (permalink / raw)
To: Pawel Moll
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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)
^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m
@ 2011-11-30 15:58 ` Dave Martin
0 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-11-30 15:58 UTC (permalink / raw)
To: linux-arm-kernel
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)
^ permalink raw reply related [flat|nested] 106+ messages in thread
* Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
2011-11-30 15:37 ` Dave Martin
@ 2011-11-30 17:15 ` Pawel Moll
-1 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-30 17:15 UTC (permalink / raw)
To: Dave Martin; +Cc: devicetree-discuss, Tixy, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
@ 2011-11-30 17:15 ` Pawel Moll
0 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-30 17:15 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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?
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
2011-11-30 17:15 ` Pawel Moll
@ 2011-11-30 17:54 ` Dave Martin
-1 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-11-30 17:54 UTC (permalink / raw)
To: Pawel Moll, Tixy
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
@ 2011-11-30 17:54 ` Dave Martin
0 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-11-30 17:54 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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 at 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
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
2011-11-30 17:54 ` Dave Martin
@ 2011-11-30 18:31 ` Pawel Moll
-1 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-30 18:31 UTC (permalink / raw)
To: Dave Martin; +Cc: devicetree-discuss, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
@ 2011-11-30 18:31 ` Pawel Moll
0 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-30 18:31 UTC (permalink / raw)
To: linux-arm-kernel
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?
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 5/5] ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4
2011-11-29 16:40 ` Dave Martin
@ 2011-11-30 18:39 ` Pawel Moll
-1 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-30 18:39 UTC (permalink / raw)
To: Dave Martin; +Cc: devicetree-discuss, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 5/5] ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4
@ 2011-11-30 18:39 ` Pawel Moll
0 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-30 18:39 UTC (permalink / raw)
To: linux-arm-kernel
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@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
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m
2011-11-30 15:58 ` Dave Martin
@ 2011-11-30 18:46 ` Pawel Moll
-1 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-30 18:46 UTC (permalink / raw)
To: Dave Martin; +Cc: devicetree-discuss, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m
@ 2011-11-30 18:46 ` Pawel Moll
0 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-11-30 18:46 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
2011-11-30 17:54 ` Dave Martin
@ 2011-11-30 20:43 ` Nicolas Pitre
-1 siblings, 0 replies; 106+ messages in thread
From: Nicolas Pitre @ 2011-11-30 20:43 UTC (permalink / raw)
To: Dave Martin, Stephen Warren
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Tixy, Pawel Moll
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
@ 2011-11-30 20:43 ` Nicolas Pitre
0 siblings, 0 replies; 106+ messages in thread
From: Nicolas Pitre @ 2011-11-30 20:43 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
2011-11-30 20:43 ` Nicolas Pitre
@ 2011-11-30 20:48 ` Mark Brown
-1 siblings, 0 replies; 106+ messages in thread
From: Mark Brown @ 2011-11-30 20:48 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Pawel Moll, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Tixy,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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?
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
@ 2011-11-30 20:48 ` Mark Brown
0 siblings, 0 replies; 106+ messages in thread
From: Mark Brown @ 2011-11-30 20:48 UTC (permalink / raw)
To: linux-arm-kernel
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?
^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
2011-11-30 20:48 ` Mark Brown
@ 2011-11-30 21:21 ` Stephen Warren
-1 siblings, 0 replies; 106+ messages in thread
From: Stephen Warren @ 2011-11-30 21:21 UTC (permalink / raw)
To: Mark Brown, Nicolas Pitre
Cc: Pawel Moll, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Tixy
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
@ 2011-11-30 21:21 ` Stephen Warren
0 siblings, 0 replies; 106+ messages in thread
From: Stephen Warren @ 2011-11-30 21:21 UTC (permalink / raw)
To: linux-arm-kernel
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 at lists.denx.de/msg69105.html
Earlier versions are at:
http://www.mail-archive.com/u-boot at lists.denx.de/msg68907.html
http://www.mail-archive.com/u-boot at lists.denx.de/msg67647.html
http://www.mail-archive.com/u-boot at lists.denx.de/msg66537.html
http://www.mail-archive.com/u-boot at lists.denx.de/msg65837.html
http://www.mail-archive.com/u-boot at lists.denx.de/msg64721.html
http://www.mail-archive.com/u-boot at lists.denx.de/msg64237.html
--
nvpublic
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
2011-11-30 20:48 ` Mark Brown
@ 2011-11-30 21:38 ` Nicolas Pitre
-1 siblings, 0 replies; 106+ messages in thread
From: Nicolas Pitre @ 2011-11-30 21:38 UTC (permalink / raw)
To: Mark Brown
Cc: Pawel Moll, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Tixy,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
@ 2011-11-30 21:38 ` Nicolas Pitre
0 siblings, 0 replies; 106+ messages in thread
From: Nicolas Pitre @ 2011-11-30 21:38 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
2011-11-30 21:38 ` Nicolas Pitre
@ 2011-11-30 21:50 ` Russell King - ARM Linux
-1 siblings, 0 replies; 106+ messages in thread
From: Russell King - ARM Linux @ 2011-11-30 21:50 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Pawel Moll, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
Mark Brown, Tixy,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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?
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
@ 2011-11-30 21:50 ` Russell King - ARM Linux
0 siblings, 0 replies; 106+ messages in thread
From: Russell King - ARM Linux @ 2011-11-30 21:50 UTC (permalink / raw)
To: linux-arm-kernel
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?
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
2011-11-30 21:50 ` Russell King - ARM Linux
@ 2011-12-01 3:36 ` Nicolas Pitre
-1 siblings, 0 replies; 106+ messages in thread
From: Nicolas Pitre @ 2011-12-01 3:36 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Pawel Moll, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
Mark Brown, Tixy,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
@ 2011-12-01 3:36 ` Nicolas Pitre
0 siblings, 0 replies; 106+ messages in thread
From: Nicolas Pitre @ 2011-12-01 3:36 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m
2011-11-30 18:46 ` Pawel Moll
@ 2011-12-01 10:57 ` Dave Martin
-1 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-12-01 10:57 UTC (permalink / raw)
To: Pawel Moll
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m
@ 2011-12-01 10:57 ` Dave Martin
0 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-12-01 10:57 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
2011-11-30 21:38 ` Nicolas Pitre
@ 2011-12-01 11:10 ` Mark Brown
-1 siblings, 0 replies; 106+ messages in thread
From: Mark Brown @ 2011-12-01 11:10 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Pawel Moll, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Tixy,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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).
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
@ 2011-12-01 11:10 ` Mark Brown
0 siblings, 0 replies; 106+ messages in thread
From: Mark Brown @ 2011-12-01 11:10 UTC (permalink / raw)
To: linux-arm-kernel
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).
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
2011-12-01 11:10 ` Mark Brown
@ 2011-12-01 12:14 ` Dave Martin
-1 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-12-01 12:14 UTC (permalink / raw)
To: Mark Brown
Cc: Nicolas Pitre, Pawel Moll,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Tixy,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
@ 2011-12-01 12:14 ` Dave Martin
0 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-12-01 12:14 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 5/5] ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4
2011-11-30 18:39 ` Pawel Moll
@ 2011-12-01 12:21 ` Dave Martin
-1 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-12-01 12:21 UTC (permalink / raw)
To: Pawel Moll
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 5/5] ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4
@ 2011-12-01 12:21 ` Dave Martin
0 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-12-01 12:21 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
2011-12-01 12:14 ` Dave Martin
@ 2011-12-01 16:19 ` Stephen Warren
-1 siblings, 0 replies; 106+ messages in thread
From: Stephen Warren @ 2011-12-01 16:19 UTC (permalink / raw)
To: Dave Martin, Mark Brown
Cc: Nicolas Pitre, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
Pawel Moll, Tixy,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
@ 2011-12-01 16:19 ` Stephen Warren
0 siblings, 0 replies; 106+ messages in thread
From: Stephen Warren @ 2011-12-01 16:19 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
2011-12-01 11:10 ` Mark Brown
@ 2011-12-01 18:37 ` Russell King - ARM Linux
-1 siblings, 0 replies; 106+ messages in thread
From: Russell King - ARM Linux @ 2011-12-01 18:37 UTC (permalink / raw)
To: Mark Brown
Cc: Nicolas Pitre, Pawel Moll,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Tixy,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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.
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
@ 2011-12-01 18:37 ` Russell King - ARM Linux
0 siblings, 0 replies; 106+ messages in thread
From: Russell King - ARM Linux @ 2011-12-01 18:37 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
2011-12-01 16:19 ` Stephen Warren
@ 2011-12-02 17:41 ` Stephen Warren
-1 siblings, 0 replies; 106+ messages in thread
From: Stephen Warren @ 2011-12-02 17:41 UTC (permalink / raw)
To: Stephen Warren, Dave Martin, Mark Brown
Cc: Nicolas Pitre, Pawel Moll,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Tixy, Marek Vasut,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
@ 2011-12-02 17:41 ` Stephen Warren
0 siblings, 0 replies; 106+ messages in thread
From: Stephen Warren @ 2011-12-02 17:41 UTC (permalink / raw)
To: linux-arm-kernel
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 at lists.denx.de/msg69287.html
--
nvpublic
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
2011-12-02 17:41 ` Stephen Warren
@ 2011-12-02 19:06 ` Marek Vasut
-1 siblings, 0 replies; 106+ messages in thread
From: Marek Vasut @ 2011-12-02 19:06 UTC (permalink / raw)
To: Stephen Warren
Cc: Nicolas Pitre, Pawel Moll,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Mark Brown, Tixy,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
> 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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
@ 2011-12-02 19:06 ` Marek Vasut
0 siblings, 0 replies; 106+ messages in thread
From: Marek Vasut @ 2011-12-02 19:06 UTC (permalink / raw)
To: linux-arm-kernel
> 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 at lists.denx.de/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
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
2011-12-02 17:41 ` Stephen Warren
@ 2011-12-02 19:28 ` Dave Martin
-1 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-12-02 19:28 UTC (permalink / raw)
To: Stephen Warren
Cc: Nicolas Pitre, Pawel Moll,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Mark Brown, Tixy,
Marek Vasut, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
@ 2011-12-02 19:28 ` Dave Martin
0 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-12-02 19:28 UTC (permalink / raw)
To: linux-arm-kernel
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 at lists.denx.de/msg69287.html
Great, thanks for the alert.
Cheers
---Dave
^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
2011-12-02 17:41 ` Stephen Warren
@ 2011-12-02 22:52 ` Nicolas Pitre
-1 siblings, 0 replies; 106+ messages in thread
From: Nicolas Pitre @ 2011-12-02 22:52 UTC (permalink / raw)
To: Stephen Warren
Cc: Pawel Moll, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
Mark Brown, Tixy, Marek Vasut,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
@ 2011-12-02 22:52 ` Nicolas Pitre
0 siblings, 0 replies; 106+ messages in thread
From: Nicolas Pitre @ 2011-12-02 22:52 UTC (permalink / raw)
To: linux-arm-kernel
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 at lists.denx.de/msg69287.html
Excellent!
Nicolas
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
2011-12-02 22:52 ` Nicolas Pitre
@ 2011-12-02 23:03 ` Marek Vasut
-1 siblings, 0 replies; 106+ messages in thread
From: Marek Vasut @ 2011-12-02 23:03 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Pawel Moll, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
Mark Brown, Tixy,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
> 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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
@ 2011-12-02 23:03 ` Marek Vasut
0 siblings, 0 replies; 106+ messages in thread
From: Marek Vasut @ 2011-12-02 23:03 UTC (permalink / raw)
To: linux-arm-kernel
> 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 at lists.denx.de/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
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m
2011-11-29 15:11 ` Pawel Moll
@ 2011-12-05 16:25 ` Dave Martin
-1 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-12-05 16:25 UTC (permalink / raw)
To: Pawel Moll
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m
@ 2011-12-05 16:25 ` Dave Martin
0 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-12-05 16:25 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m
2011-12-05 16:25 ` Dave Martin
@ 2011-12-05 16:30 ` Pawel Moll
-1 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-12-05 16:30 UTC (permalink / raw)
To: Dave Martin; +Cc: devicetree-discuss, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m
@ 2011-12-05 16:30 ` Pawel Moll
0 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-12-05 16:30 UTC (permalink / raw)
To: linux-arm-kernel
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?
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 5/5] ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4
2011-12-01 12:21 ` Dave Martin
@ 2011-12-05 17:24 ` Pawel Moll
-1 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-12-05 17:24 UTC (permalink / raw)
To: Dave Martin; +Cc: devicetree-discuss, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 5/5] ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4
@ 2011-12-05 17:24 ` Pawel Moll
0 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-12-05 17:24 UTC (permalink / raw)
To: linux-arm-kernel
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?
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 5/5] ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4
2011-12-05 17:24 ` Pawel Moll
@ 2011-12-05 17:37 ` Dave Martin
-1 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-12-05 17:37 UTC (permalink / raw)
To: Pawel Moll
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 5/5] ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4
@ 2011-12-05 17:37 ` Dave Martin
0 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-12-05 17:37 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 5/5] ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4
2011-12-05 17:37 ` Dave Martin
@ 2011-12-05 17:47 ` Pawel Moll
-1 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-12-05 17:47 UTC (permalink / raw)
To: Dave Martin; +Cc: devicetree-discuss, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 5/5] ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4
@ 2011-12-05 17:47 ` Pawel Moll
0 siblings, 0 replies; 106+ messages in thread
From: Pawel Moll @ 2011-12-05 17:47 UTC (permalink / raw)
To: linux-arm-kernel
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?
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH v3 5/5] ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4
2011-12-05 17:47 ` Pawel Moll
@ 2011-12-05 18:06 ` Dave Martin
-1 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-12-05 18:06 UTC (permalink / raw)
To: Pawel Moll
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH v3 5/5] ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4
@ 2011-12-05 18:06 ` Dave Martin
0 siblings, 0 replies; 106+ messages in thread
From: Dave Martin @ 2011-12-05 18:06 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 106+ messages in thread
end of thread, other threads:[~2011-12-05 18:06 UTC | newest]
Thread overview: 106+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-11-29 15:11 [PATCH v3 0/5] Versatile Express DT support Pawel Moll
2011-11-29 15:11 ` Pawel Moll
2011-11-29 15:11 ` [PATCH v3 1/5] ARM: versatile: Add missing ENDPROC to headsmp.S Pawel Moll
2011-11-29 15:11 ` Pawel Moll
2011-11-29 15:11 ` [PATCH v3 2/5] ARM: vexpress: Get rid of MMIO_P2V Pawel Moll
2011-11-29 15:11 ` Pawel Moll
2011-11-29 21:15 ` Arnd Bergmann
2011-11-29 21:15 ` Arnd Bergmann
2011-11-30 11:34 ` Pawel Moll
2011-11-30 11:34 ` Pawel Moll
[not found] ` <1322652891.3164.144.camel-okZbbLrgpR/YkXV2EHHjLW3o5bpOHsLO@public.gmane.org>
2011-11-30 13:48 ` Arnd Bergmann
2011-11-30 13:48 ` Arnd Bergmann
2011-11-30 13:52 ` Pawel Moll
2011-11-30 13:52 ` Pawel Moll
2011-11-29 15:11 ` [PATCH v3 3/5] ARM: vexpress: Add DT support in v2m Pawel Moll
2011-11-29 15:11 ` Pawel Moll
2011-11-29 21:19 ` Arnd Bergmann
2011-11-29 21:19 ` Arnd Bergmann
2011-11-30 11:46 ` Pawel Moll
2011-11-30 11:46 ` Pawel Moll
2011-11-30 13:34 ` Arnd Bergmann
2011-11-30 13:34 ` Arnd Bergmann
2011-11-30 13:38 ` Pawel Moll
2011-11-30 13:38 ` Pawel Moll
[not found] ` <1322660291.10583.2.camel-okZbbLrgpR/YkXV2EHHjLW3o5bpOHsLO@public.gmane.org>
2011-11-30 15:10 ` Arnd Bergmann
2011-11-30 15:10 ` Arnd Bergmann
[not found] ` <1322579473-8804-4-git-send-email-pawel.moll-5wv7dgnIgG8@public.gmane.org>
2011-11-30 15:58 ` Dave Martin
2011-11-30 15:58 ` Dave Martin
2011-11-30 18:46 ` Pawel Moll
2011-11-30 18:46 ` Pawel Moll
[not found] ` <1322678779.3180.36.camel-okZbbLrgpR/YkXV2EHHjLW3o5bpOHsLO@public.gmane.org>
2011-12-01 10:57 ` Dave Martin
2011-12-01 10:57 ` Dave Martin
2011-12-05 16:25 ` Dave Martin
2011-12-05 16:25 ` Dave Martin
2011-12-05 16:30 ` Pawel Moll
2011-12-05 16:30 ` Pawel Moll
2011-11-29 15:11 ` [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support Pawel Moll
2011-11-29 15:11 ` Pawel Moll
[not found] ` <1322579473-8804-5-git-send-email-pawel.moll-5wv7dgnIgG8@public.gmane.org>
2011-11-30 15:37 ` Dave Martin
2011-11-30 15:37 ` Dave Martin
2011-11-30 17:15 ` Pawel Moll
2011-11-30 17:15 ` Pawel Moll
[not found] ` <1322673302.3180.25.camel-okZbbLrgpR/YkXV2EHHjLW3o5bpOHsLO@public.gmane.org>
2011-11-30 17:54 ` Dave Martin
2011-11-30 17:54 ` Dave Martin
2011-11-30 18:31 ` Pawel Moll
2011-11-30 18:31 ` Pawel Moll
[not found] ` <20111130175410.GJ2045-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2011-11-30 20:43 ` Nicolas Pitre
2011-11-30 20:43 ` Nicolas Pitre
[not found] ` <alpine.LFD.2.02.1111301522340.2357-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>
2011-11-30 20:48 ` Mark Brown
2011-11-30 20:48 ` Mark Brown
[not found] ` <20111130204805.GA5698-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2011-11-30 21:21 ` Stephen Warren
2011-11-30 21:21 ` Stephen Warren
2011-11-30 21:38 ` Nicolas Pitre
2011-11-30 21:38 ` Nicolas Pitre
[not found] ` <alpine.LFD.2.02.1111301604230.2357-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>
2011-11-30 21:50 ` Russell King - ARM Linux
2011-11-30 21:50 ` Russell King - ARM Linux
[not found] ` <20111130215000.GU9581-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2011-12-01 3:36 ` Nicolas Pitre
2011-12-01 3:36 ` Nicolas Pitre
2011-12-01 11:10 ` Mark Brown
2011-12-01 11:10 ` Mark Brown
[not found] ` <20111201111049.GB2915-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2011-12-01 12:14 ` Dave Martin
2011-12-01 12:14 ` Dave Martin
[not found] ` <20111201121403.GC2026-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2011-12-01 16:19 ` Stephen Warren
2011-12-01 16:19 ` Stephen Warren
[not found] ` <74CDBE0F657A3D45AFBB94109FB122FF174FDB01C6-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2011-12-02 17:41 ` Stephen Warren
2011-12-02 17:41 ` Stephen Warren
[not found] ` <74CDBE0F657A3D45AFBB94109FB122FF174FDB0539-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2011-12-02 19:06 ` Marek Vasut
2011-12-02 19:06 ` Marek Vasut
2011-12-02 19:28 ` Dave Martin
2011-12-02 19:28 ` Dave Martin
2011-12-02 22:52 ` Nicolas Pitre
2011-12-02 22:52 ` Nicolas Pitre
[not found] ` <alpine.LFD.2.02.1112021739420.2357-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>
2011-12-02 23:03 ` Marek Vasut
2011-12-02 23:03 ` Marek Vasut
2011-12-01 18:37 ` Russell King - ARM Linux
2011-12-01 18:37 ` Russell King - ARM Linux
2011-11-29 15:11 ` [PATCH v3 5/5] ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4 Pawel Moll
2011-11-29 15:11 ` Pawel Moll
[not found] ` <1322579473-8804-6-git-send-email-pawel.moll-5wv7dgnIgG8@public.gmane.org>
2011-11-29 16:40 ` Dave Martin
2011-11-29 16:40 ` Dave Martin
2011-11-30 18:39 ` Pawel Moll
2011-11-30 18:39 ` Pawel Moll
[not found] ` <1322678364.3180.34.camel-okZbbLrgpR/YkXV2EHHjLW3o5bpOHsLO@public.gmane.org>
2011-12-01 12:21 ` Dave Martin
2011-12-01 12:21 ` Dave Martin
2011-12-05 17:24 ` Pawel Moll
2011-12-05 17:24 ` Pawel Moll
[not found] ` <1323105880.3147.55.camel-okZbbLrgpR/YkXV2EHHjLW3o5bpOHsLO@public.gmane.org>
2011-12-05 17:37 ` Dave Martin
2011-12-05 17:37 ` Dave Martin
2011-12-05 17:47 ` Pawel Moll
2011-12-05 17:47 ` Pawel Moll
[not found] ` <1323107256.3147.63.camel-okZbbLrgpR/YkXV2EHHjLW3o5bpOHsLO@public.gmane.org>
2011-12-05 18:06 ` Dave Martin
2011-12-05 18:06 ` Dave Martin
[not found] ` <1322579473-8804-1-git-send-email-pawel.moll-5wv7dgnIgG8@public.gmane.org>
2011-11-29 17:00 ` [PATCH v3 0/5] Versatile Express DT support Dave Martin
2011-11-29 17:00 ` Dave Martin
2011-11-29 17:16 ` Pawel Moll
2011-11-29 17:16 ` Pawel Moll
[not found] ` <1322587019.3164.111.camel-okZbbLrgpR/YkXV2EHHjLW3o5bpOHsLO@public.gmane.org>
2011-11-30 10:48 ` Dave Martin
2011-11-30 10:48 ` Dave Martin
2011-11-30 11:14 ` Pawel Moll
2011-11-30 11:14 ` Pawel Moll
[not found] ` <1322651640.3164.135.camel-okZbbLrgpR/YkXV2EHHjLW3o5bpOHsLO@public.gmane.org>
2011-11-30 12:08 ` Dave Martin
2011-11-30 12:08 ` Dave Martin
2011-11-30 12:15 ` Pawel Moll
2011-11-30 12:15 ` Pawel Moll
2011-11-29 21:24 ` Arnd Bergmann
2011-11-29 21:24 ` Arnd Bergmann
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.