v3.10 - big endian core support

v3.10 - big endian core support

[Ben Dooks]

The latest big-endian changes, now on:

	git://git.baserock.org/delta/linux baserock/311/be/core

This has a minor fix from the last version where a rebase missed a change
in the smp_scu code.

[PATCH 01/10] ARM: fix ARCH_IXP4xx usage of ARCH_SUPPORTS_BIG_ENDIAN

[Ben Dooks]

The Kconfig for arch/arm/mach-ixp4xx has a local definition
of ARCH_SUPPORTS_BIG_ENDIAN which could be used elsewhere.
This means that if IXP4xx is selected and this symbol is
selected eleswhere then an warning is produced.

Clean the following error up by making the symbol be
selected by the main ARCH_IXP4XX definition and have a
common definition in arch/arm/mm/Kconfig

warning: (ARCH_xxx) selects ARCH_SUPPORTS_BIG_ENDIAN which has unmet direct dependencies (ARCH_IXP4XX)
warning: (ARCH_xxx) selects ARCH_SUPPORTS_BIG_ENDIAN which has unmet direct dependencies (ARCH_IXP4XX)

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
 arch/arm/Kconfig             |    1 +
 arch/arm/mach-ixp4xx/Kconfig |    4 ----
 arch/arm/mm/Kconfig          |    6 ++++++
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 136f263..0e60b0e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -474,6 +474,7 @@ config ARCH_IXP4XX
 	bool "IXP4xx-based"
 	depends on MMU
 	select ARCH_HAS_DMA_SET_COHERENT_MASK
+	select ARCH_SUPPORTS_BIG_ENDIAN
 	select ARCH_REQUIRE_GPIOLIB
 	select CLKSRC_MMIO
 	select CPU_XSCALE
diff --git a/arch/arm/mach-ixp4xx/Kconfig b/arch/arm/mach-ixp4xx/Kconfig
index 73a2d90..72de05f 100644
--- a/arch/arm/mach-ixp4xx/Kconfig
+++ b/arch/arm/mach-ixp4xx/Kconfig
@@ -1,9 +1,5 @@
 if ARCH_IXP4XX
 
-config ARCH_SUPPORTS_BIG_ENDIAN
-	bool
-	default y
-
 menu "Intel IXP4xx Implementation Options"
 
 comment "IXP4xx Platforms"
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 35955b5..b83782e 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -895,3 +895,9 @@ config ARCH_HAS_BARRIERS
 	help
 	  This option allows the use of custom mandatory barriers
 	  included via the mach/barriers.h file.
+
+config ARCH_SUPPORTS_BIG_ENDIAN
+	bool
+	help
+	  This option specifies the architecture can support big endian
+	  operation.
-- 
1.7.10.4

[PATCH 02/10] ARM: asm: Add ARM_BE8() assembly helper

[Ben Dooks]

Add ARM_BE8() helper to wrap any code conditional on being
compile when CONFIG_ARM_ENDIAN_BE8 is selected and convert
existing places where this is to use it.

Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
 arch/arm/boot/compressed/head.S  |    8 ++------
 arch/arm/include/asm/assembler.h |    7 +++++++
 arch/arm/kernel/entry-armv.S     |    5 ++---
 arch/arm/kernel/entry-common.S   |    4 +---
 arch/arm/mm/abort-ev6.S          |    5 ++---
 arch/arm/mm/proc-v6.S            |    4 +---
 arch/arm/mm/proc-v7.S            |    4 +---
 7 files changed, 16 insertions(+), 21 deletions(-)

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 032a8d9..4eb8364 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -679,9 +679,7 @@ __armv4_mmu_cache_on:
 		mrc	p15, 0, r0, c1, c0, 0	@ read control reg
 		orr	r0, r0, #0x5000		@ I-cache enable, RR cache replacement
 		orr	r0, r0, #0x0030
-#ifdef CONFIG_CPU_ENDIAN_BE8
-		orr	r0, r0, #1 << 25	@ big-endian page tables
-#endif
+ ARM_BE8(	orr	r0, r0, #1 << 25 )	@ big-endian page tables
 		bl	__common_mmu_cache_on
 		mov	r0, #0
 		mcr	p15, 0, r0, c8, c7, 0	@ flush I,D TLBs
@@ -708,9 +706,7 @@ __armv7_mmu_cache_on:
 		orr	r0, r0, #1 << 22	@ U (v6 unaligned access model)
 						@ (needed for ARM1176)
 #ifdef CONFIG_MMU
-#ifdef CONFIG_CPU_ENDIAN_BE8
-		orr	r0, r0, #1 << 25	@ big-endian page tables
-#endif
+ ARM_BE8(	orr	r0, r0, #1 << 25 )	@ big-endian page tables
 		mrcne   p15, 0, r6, c2, c0, 2   @ read ttb control reg
 		orrne	r0, r0, #1		@ MMU enabled
 		movne	r1, #0xfffffffd		@ domain 0 = client
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index 05ee9ee..e780afb 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -53,6 +53,13 @@
 #define put_byte_3      lsl #0
 #endif
 
+/* Select code for any configuration running in BE8 mode */
+#ifdef CONFIG_CPU_ENDIAN_BE8
+#define ARM_BE8(code...) code
+#else
+#define ARM_BE8(code...)
+#endif
+
 /*
  * Data preload for architectures that support it
  */
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 582b405..09130e2 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -415,9 +415,8 @@ __und_usr:
 	bne	__und_usr_thumb
 	sub	r4, r2, #4			@ ARM instr@LR - 4
 1:	ldrt	r0, [r4]
-#ifdef CONFIG_CPU_ENDIAN_BE8
-	rev	r0, r0				@ little endian instruction
-#endif
+ ARM_BE8(rev	r0, r0)				@ little endian instruction
+
 	@ r0 = 32-bit ARM instruction which caused the exception
 	@ r2 = PC value for the following instruction (:= regs->ARM_pc)
 	@ r4 = PC value for the faulting instruction
diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index bc5bc0a..8c79344 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -379,9 +379,7 @@ ENTRY(vector_swi)
 #else
 	ldr	r10, [lr, #-4]			@ get SWI instruction
 #endif
-#ifdef CONFIG_CPU_ENDIAN_BE8
-	rev	r10, r10			@ little endian instruction
-#endif
+ ARM_BE8(rev	r10, r10)			@ little endian instruction
 
 #elif defined(CONFIG_AEABI)
 
diff --git a/arch/arm/mm/abort-ev6.S b/arch/arm/mm/abort-ev6.S
index 8074199..3815a82 100644
--- a/arch/arm/mm/abort-ev6.S
+++ b/arch/arm/mm/abort-ev6.S
@@ -38,9 +38,8 @@ ENTRY(v6_early_abort)
 	bne	do_DataAbort
 	bic	r1, r1, #1 << 11		@ clear bit 11 of FSR
 	ldr	r3, [r4]			@ read aborted ARM instruction
-#ifdef CONFIG_CPU_ENDIAN_BE8
-	rev	r3, r3
-#endif
+ ARM_BE8(rev	r3, r3)
+
 	do_ldrd_abort tmp=ip, insn=r3
 	tst	r3, #1 << 20			@ L = 0 -> write
 	orreq	r1, r1, #1 << 11		@ yes.
diff --git a/arch/arm/mm/proc-v6.S b/arch/arm/mm/proc-v6.S
index 919405e..f2e43e8 100644
--- a/arch/arm/mm/proc-v6.S
+++ b/arch/arm/mm/proc-v6.S
@@ -218,9 +218,7 @@ __v6_setup:
 #endif /* CONFIG_MMU */
 	adr	r5, v6_crval
 	ldmia	r5, {r5, r6}
-#ifdef CONFIG_CPU_ENDIAN_BE8
-	orr	r6, r6, #1 << 25		@ big-endian page tables
-#endif
+ ARM_BE8(orr	r6, r6, #1 << 25)		@ big-endian page tables
 	mrc	p15, 0, r0, c1, c0, 0		@ read control register
 	bic	r0, r0, r5			@ clear bits them
 	orr	r0, r0, r6			@ set them
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index e35fec3..8338ba4 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -351,9 +351,7 @@ __v7_setup:
 #endif
 	adr	r5, v7_crval
 	ldmia	r5, {r5, r6}
-#ifdef CONFIG_CPU_ENDIAN_BE8
-	orr	r6, r6, #1 << 25		@ big-endian page tables
-#endif
+ ARM_BE8(orr	r6, r6, #1 << 25)		@ big-endian page tables
 #ifdef CONFIG_SWP_EMULATE
 	orr     r5, r5, #(1 << 10)              @ set SW bit in "clear"
 	bic     r6, r6, #(1 << 10)              @ clear it in "mmuset"
-- 
1.7.10.4

[PATCH 03/10] ARM: fixup_pv_table bug when CPU_ENDIAN_BE8

[Ben Dooks]

The fixup_pv_table assumes that the instructions are in the same
endian configuration as the data, but when the CPU is running in
BE8 the instructions stay in little-endian format.

Make sure if CONFIG_CPU_ENDIAN_BE8 is set that we do all the
alterations to the instructions taking in to account the LDR/STR
will be swapping the data endian-ness.

Since the code is only modifying a byte, we avoid dual-swapping
the data, and just change the bits we clear and ORR in.

Note, not tested against an actual bug, it looked wrong.

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
 arch/arm/kernel/head.S |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 8bac553..56ddd47 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -594,8 +594,14 @@ __fixup_a_pv_table:
 #else
 	b	2f
 1:	ldr	ip, [r7, r3]
+#ifdef CONFIG_CPU_ENDIAN_BE8
+	@ in BE8, we load data in BE, but instructions still in LE
+	bic	ip, ip, #0xff000000
+	orr	ip, ip, r6, lsl#24
+#else
 	bic	ip, ip, #0x000000ff
 	orr	ip, ip, r6	@ mask in offset bits 31-24
+#endif
 	str	ip, [r7, r3]
 2:	cmp	r4, r5
 	ldrcc	r7, [r4], #4	@ use branch for delay slot
-- 
1.7.10.4

[PATCH 04/10] ARM: set BE8 if LE in head code

[Ben Dooks]

If we are booting in LE and compiled for BE8, then add code to
set the state to bE8. Since the instruction stream is always LE,
we do not need to do anything special to the instruction.

Also ensure that the secondary processors are started in the same mode.

Note, we do add about 20 bytes to the kernel image, but it seems easier
to do this than adding another configuration to change.

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
 arch/arm/boot/compressed/head.S |    1 +
 arch/arm/kernel/head.S          |    4 ++++
 arch/arm/kernel/sleep.S         |    1 +
 3 files changed, 6 insertions(+)

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 4eb8364..4d83bfd 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -135,6 +135,7 @@ start:
 		.word	_edata			@ zImage end address
  THUMB(		.thumb			)
 1:
+ ARM_BE8(	setend	be )			@ go BE8 if LE, no-op if BE8
 		mrs	r9, cpsr
 #ifdef CONFIG_ARM_VIRT_EXT
 		bl	__hyp_stub_install	@ get into SVC mode, reversibly
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 56ddd47..da09dc0 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -77,6 +77,7 @@
 
 	__HEAD
 ENTRY(stext)
+ ARM_BE8(setend	be )			@ ensure we are in BE8 mode
 
  THUMB(	adr	r9, BSYM(1f)	)	@ Kernel is always entered in ARM.
  THUMB(	bx	r9		)	@ If this is a Thumb-2 kernel,
@@ -351,6 +352,9 @@ ENTRY(secondary_startup)
 	 * the processor type - there is no need to check the machine type
 	 * as it has already been validated by the primary processor.
 	 */
+
+ ARM_BE8(setend	be)				@ if system starts LE, go BE8
+
 #ifdef CONFIG_ARM_VIRT_EXT
 	bl	__hyp_stub_install_secondary
 #endif
diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
index 987dcf3..954c28a 100644
--- a/arch/arm/kernel/sleep.S
+++ b/arch/arm/kernel/sleep.S
@@ -81,6 +81,7 @@ ENDPROC(cpu_resume_after_mmu)
 	.data
 	.align
 ENTRY(cpu_resume)
+ARM_BE8(setend be)			@ ensure we are in BE mode
 #ifdef CONFIG_SMP
 	adr	r0, sleep_save_sp
 	ALT_SMP(mrc p15, 0, r1, c0, c0, 5)
-- 
1.7.10.4

[PATCH 05/10] ARM: pl01x debug code endian fix

[Ben Dooks]

The PL01X debug code needs to take into account which endian mode the
processor is running in. If it is big-endian, ensure the data is swapped
appropriately.

Note, we could do this slightly more efficiently if we have an macro to
do the necessary swap for the bits used by test.

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
 arch/arm/include/asm/hardware/debug-pl01x.S |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/include/asm/hardware/debug-pl01x.S b/arch/arm/include/asm/hardware/debug-pl01x.S
index f9fd083..6489d1f 100644
--- a/arch/arm/include/asm/hardware/debug-pl01x.S
+++ b/arch/arm/include/asm/hardware/debug-pl01x.S
@@ -18,12 +18,14 @@
 
 		.macro	waituart,rd,rx
 1001:		ldr	\rd, [\rx, #UART01x_FR]
+ ARM_BE8(	rev	\rd, \rd )
 		tst	\rd, #UART01x_FR_TXFF
 		bne	1001b
 		.endm
 
 		.macro	busyuart,rd,rx
 1001:		ldr	\rd, [\rx, #UART01x_FR]
+ ARM_BE8(	rev	\rd, \rd )
 		tst	\rd, #UART01x_FR_BUSY
 		bne	1001b
 		.endm
-- 
1.7.10.4

[PATCH 06/10] ARM: twd: data endian fix

[Ben Dooks]

Ensure the twd driver uses the correct calls to access the hardware
to ensure that we do not end up with data in the wrong endian format.

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
 arch/arm/kernel/smp_twd.c |   24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index 90525d9..804d3f8 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -45,7 +45,7 @@ static void twd_set_mode(enum clock_event_mode mode,
 	case CLOCK_EVT_MODE_PERIODIC:
 		ctrl = TWD_TIMER_CONTROL_ENABLE | TWD_TIMER_CONTROL_IT_ENABLE
 			| TWD_TIMER_CONTROL_PERIODIC;
-		__raw_writel(DIV_ROUND_CLOSEST(twd_timer_rate, HZ),
+		writel_relaxed(DIV_ROUND_CLOSEST(twd_timer_rate, HZ),
 			twd_base + TWD_TIMER_LOAD);
 		break;
 	case CLOCK_EVT_MODE_ONESHOT:
@@ -58,18 +58,18 @@ static void twd_set_mode(enum clock_event_mode mode,
 		ctrl = 0;
 	}
 
-	__raw_writel(ctrl, twd_base + TWD_TIMER_CONTROL);
+	writel_relaxed(ctrl, twd_base + TWD_TIMER_CONTROL);
 }
 
 static int twd_set_next_event(unsigned long evt,
 			struct clock_event_device *unused)
 {
-	unsigned long ctrl = __raw_readl(twd_base + TWD_TIMER_CONTROL);
+	unsigned long ctrl = readl_relaxed(twd_base + TWD_TIMER_CONTROL);
 
 	ctrl |= TWD_TIMER_CONTROL_ENABLE;
 
-	__raw_writel(evt, twd_base + TWD_TIMER_COUNTER);
-	__raw_writel(ctrl, twd_base + TWD_TIMER_CONTROL);
+	writel_relaxed(evt, twd_base + TWD_TIMER_COUNTER);
+	writel_relaxed(ctrl, twd_base + TWD_TIMER_CONTROL);
 
 	return 0;
 }
@@ -82,8 +82,8 @@ static int twd_set_next_event(unsigned long evt,
  */
 static int twd_timer_ack(void)
 {
-	if (__raw_readl(twd_base + TWD_TIMER_INTSTAT)) {
-		__raw_writel(1, twd_base + TWD_TIMER_INTSTAT);
+	if (readl_relaxed(twd_base + TWD_TIMER_INTSTAT)) {
+		writel_relaxed(1, twd_base + TWD_TIMER_INTSTAT);
 		return 1;
 	}
 
@@ -209,15 +209,15 @@ static void __cpuinit twd_calibrate_rate(void)
 		waitjiffies += 5;
 
 				 /* enable, no interrupt or reload */
-		__raw_writel(0x1, twd_base + TWD_TIMER_CONTROL);
+		writel_relaxed(0x1, twd_base + TWD_TIMER_CONTROL);
 
 				 /* maximum value */
-		__raw_writel(0xFFFFFFFFU, twd_base + TWD_TIMER_COUNTER);
+		writel_relaxed(0xFFFFFFFFU, twd_base + TWD_TIMER_COUNTER);
 
 		while (get_jiffies_64() < waitjiffies)
 			udelay(10);
 
-		count = __raw_readl(twd_base + TWD_TIMER_COUNTER);
+		count = readl_relaxed(twd_base + TWD_TIMER_COUNTER);
 
 		twd_timer_rate = (0xFFFFFFFFU - count) * (HZ / 5);
 
@@ -275,7 +275,7 @@ static int __cpuinit twd_timer_setup(struct clock_event_device *clk)
 	 * bother with the below.
 	 */
 	if (per_cpu(percpu_setup_called, cpu)) {
-		__raw_writel(0, twd_base + TWD_TIMER_CONTROL);
+		writel_relaxed(0, twd_base + TWD_TIMER_CONTROL);
 		clockevents_register_device(*__this_cpu_ptr(twd_evt));
 		enable_percpu_irq(clk->irq, 0);
 		return 0;
@@ -288,7 +288,7 @@ static int __cpuinit twd_timer_setup(struct clock_event_device *clk)
 	 * The following is done once per CPU the first time .setup() is
 	 * called.
 	 */
-	__raw_writel(0, twd_base + TWD_TIMER_CONTROL);
+	writel_relaxed(0, twd_base + TWD_TIMER_CONTROL);
 
 	clk->name = "local_timer";
 	clk->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT |
-- 
1.7.10.4

[PATCH 07/10] ARM: smp_scu: data endian fixes

[Ben Dooks]

The smp_scu driver needs to use the relaxed readl/write accessors
to avoid any issues with the endian mode the processor core is in.

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
 arch/arm/kernel/smp_scu.c |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/kernel/smp_scu.c b/arch/arm/kernel/smp_scu.c
index 5bc1a63..1aafa0d 100644
--- a/arch/arm/kernel/smp_scu.c
+++ b/arch/arm/kernel/smp_scu.c
@@ -28,7 +28,7 @@
  */
 unsigned int __init scu_get_core_count(void __iomem *scu_base)
 {
-	unsigned int ncores = __raw_readl(scu_base + SCU_CONFIG);
+	unsigned int ncores = readl_relaxed(scu_base + SCU_CONFIG);
 	return (ncores & 0x03) + 1;
 }
 
@@ -42,19 +42,19 @@ void scu_enable(void __iomem *scu_base)
 #ifdef CONFIG_ARM_ERRATA_764369
 	/* Cortex-A9 only */
 	if ((read_cpuid_id() & 0xff0ffff0) == 0x410fc090) {
-		scu_ctrl = __raw_readl(scu_base + 0x30);
+		scu_ctrl = readl_relaxed(scu_base + 0x30);
 		if (!(scu_ctrl & 1))
-			__raw_writel(scu_ctrl | 0x1, scu_base + 0x30);
+			writel_relaxed(scu_ctrl | 0x1, scu_base + 0x30);
 	}
 #endif
 
-	scu_ctrl = __raw_readl(scu_base + SCU_CTRL);
+	scu_ctrl = readl_relaxed(scu_base + SCU_CTRL);
 	/* already enabled? */
 	if (scu_ctrl & 1)
 		return;
 
 	scu_ctrl |= 1;
-	__raw_writel(scu_ctrl, scu_base + SCU_CTRL);
+	writel_relaxed(scu_ctrl, scu_base + SCU_CTRL);
 
 	/*
 	 * Ensure that the data accessed by CPU0 before the SCU was
@@ -80,9 +80,9 @@ int scu_power_mode(void __iomem *scu_base, unsigned int mode)
 	if (mode > 3 || mode == 1 || cpu > 3)
 		return -EINVAL;
 
-	val = __raw_readb(scu_base + SCU_CPU_STATUS + cpu) & ~0x03;
+	val = readb_relaxed(scu_base + SCU_CPU_STATUS + cpu) & ~0x03;
 	val |= mode;
-	__raw_writeb(val, scu_base + SCU_CPU_STATUS + cpu);
+	writeb_relaxed(val, scu_base + SCU_CPU_STATUS + cpu);
 
 	return 0;
 }
-- 
1.7.10.4

[PATCH 08/10] highbank: enable big-endian

[Ben Dooks]

Apart from a xgmac driver issue, the highbank seems to work correctly in
big-endian mode. Allow the selection of big-endian in the system.

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
 arch/arm/mach-highbank/Kconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-highbank/Kconfig b/arch/arm/mach-highbank/Kconfig
index cd9fcb1..4f57554 100644
--- a/arch/arm/mach-highbank/Kconfig
+++ b/arch/arm/mach-highbank/Kconfig
@@ -18,3 +18,4 @@ config ARCH_HIGHBANK
 	select PL320_MBOX
 	select SPARSE_IRQ
 	select USE_OF
+	select ARCH_SUPPORTS_BIG_ENDIAN
-- 
1.7.10.4

[PATCH 09/10] mvebu: support running big-endian

[Ben Dooks]

Add indication we can run these cores in BE mode, and ensure that the
secondary CPU is set to big-endian mode in the initialisation code as
the initial code runs little-endian.

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
 arch/arm/mach-mvebu/Kconfig        |    1 +
 arch/arm/mach-mvebu/coherency_ll.S |    3 +++
 arch/arm/mach-mvebu/headsmp.S      |    4 ++++
 3 files changed, 8 insertions(+)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 80a8bca..317cdb8 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -1,5 +1,6 @@
 config ARCH_MVEBU
 	bool "Marvell SOCs with Device Tree support" if ARCH_MULTI_V7
+	select ARCH_SUPPORTS_BIG_ENDIAN
 	select CLKSRC_MMIO
 	select COMMON_CLK
 	select GENERIC_CLOCKEVENTS
diff --git a/arch/arm/mach-mvebu/coherency_ll.S b/arch/arm/mach-mvebu/coherency_ll.S
index 5476669..ee7598f 100644
--- a/arch/arm/mach-mvebu/coherency_ll.S
+++ b/arch/arm/mach-mvebu/coherency_ll.S
@@ -20,6 +20,8 @@
 #define ARMADA_XP_CFB_CTL_REG_OFFSET 0x0
 #define ARMADA_XP_CFB_CFG_REG_OFFSET 0x4
 
+#include <asm/assembler.h>
+
 	.text
 /*
  * r0: Coherency fabric base register address
@@ -29,6 +31,7 @@ ENTRY(ll_set_cpu_coherent)
 	/* Create bit by cpu index */
 	mov	r3, #(1 << 24)
 	lsl	r1, r3, r1
+ARM_BE8(rev	r1, r1)
 
 	/* Add CPU to SMP group - Atomic */
 	add	r3, r0, #ARMADA_XP_CFB_CTL_REG_OFFSET
diff --git a/arch/arm/mach-mvebu/headsmp.S b/arch/arm/mach-mvebu/headsmp.S
index a06e0ed..a4f995d 100644
--- a/arch/arm/mach-mvebu/headsmp.S
+++ b/arch/arm/mach-mvebu/headsmp.S
@@ -21,6 +21,8 @@
 #include <linux/linkage.h>
 #include <linux/init.h>
 
+#include <asm/assembler.h>
+
 /*
  * At this stage the secondary CPUs don't have acces yet to the MMU, so
  * we have to provide physical addresses
@@ -36,6 +38,8 @@
  */
 ENTRY(armada_xp_secondary_startup)
 
+ ARM_BE8(setend	be )			@ go BE8 if booted LE
+
 	/* Read CPU id */
 	mrc     p15, 0, r1, c0, c0, 5
 	and     r1, r1, #0xF
-- 
1.7.10.4

[PATCH 10/10] vexpress: add big endian support

[Ben Dooks]

Add support for the versatile express systems to boot big-endian.

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
 arch/arm/mach-vexpress/Kconfig    |    1 +
 arch/arm/plat-versatile/headsmp.S |    2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
index 5907e10..fa69d4e 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig
@@ -1,6 +1,7 @@
 config ARCH_VEXPRESS
 	bool "ARM Ltd. Versatile Express family" if ARCH_MULTI_V7
 	select ARCH_REQUIRE_GPIOLIB
+	select ARCH_SUPPORTS_BIG_ENDIAN
 	select ARM_AMBA
 	select ARM_GIC
 	select ARM_TIMER_SP804
diff --git a/arch/arm/plat-versatile/headsmp.S b/arch/arm/plat-versatile/headsmp.S
index b178d44..4c5c8ca 100644
--- a/arch/arm/plat-versatile/headsmp.S
+++ b/arch/arm/plat-versatile/headsmp.S
@@ -10,6 +10,7 @@
  */
 #include <linux/linkage.h>
 #include <linux/init.h>
+#include <asm/assembler.h>
 
 	__INIT
 
@@ -19,6 +20,7 @@
  * until we're ready for them to initialise.
  */
 ENTRY(versatile_secondary_startup)
+ ARM_BE8(setend	be)
 	mrc	p15, 0, r0, c0, c0, 5
 	bic	r0, #0xff000000
 	adr	r4, 1f
-- 
1.7.10.4

v3.10 - big endian core support

[Thomas Petazzoni]

Dear Ben Dooks,

On Mon,  1 Jul 2013 12:03:58 +0100, Ben Dooks wrote:
> The latest big-endian changes, now on:
> 
> 	git://git.baserock.org/delta/linux baserock/311/be/core
> 
> This has a minor fix from the last version where a rebase missed a change
> in the smp_scu code.

Patches 1, 2, 3, 4 and 9:

Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

on an Armada XP GP board. The other patches are not exercised by this
particular testing.

I'm interested in seeing this series merged.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

v3.10 - big endian core support

[Ben Dooks]

On 01/07/13 15:33, Thomas Petazzoni wrote:
> Dear Ben Dooks,
>
> On Mon,  1 Jul 2013 12:03:58 +0100, Ben Dooks wrote:
>> The latest big-endian changes, now on:
>>
>> 	git://git.baserock.org/delta/linux baserock/311/be/core
>>
>> This has a minor fix from the last version where a rebase missed a change
>> in the smp_scu code.
>
> Patches 1, 2, 3, 4 and 9:
>
> Tested-by: Thomas Petazzoni<thomas.petazzoni@free-electrons.com>

Thanks.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

v3.10 - big endian core support

[jgq516 at gmail.com]

On 07/01/2013 07:03 PM, Ben Dooks wrote:
> The latest big-endian changes, now on:
>
> 	git://git.baserock.org/delta/linux baserock/311/be/core
>
> This has a minor fix from the last version where a rebase missed a change
> in the smp_scu code.
>
Hello Ben,

Thanks for you patches at first. I can boot BE kernel on vexpress a15 tc2
board with LPAE disabled.

However if enable LPAE, kernel seems hang after turn on mmu on since
printascii can't output any character in __mmap_switched.
Did you happen to try BE kernel with LPAE enabled before? or am I missed
something?

Thanks,
Xiao

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

v3.10 - big endian core support

[Will Deacon]

On Mon, Jul 08, 2013 at 06:39:21AM +0100, jgq516 at gmail.com wrote:
> On 07/01/2013 07:03 PM, Ben Dooks wrote:
> > The latest big-endian changes, now on:
> >
> > 	git://git.baserock.org/delta/linux baserock/311/be/core
> >
> > This has a minor fix from the last version where a rebase missed a change
> > in the smp_scu code.
> >
> Hello Ben,
> 
> Thanks for you patches at first. I can boot BE kernel on vexpress a15 tc2
> board with LPAE disabled.
> 
> However if enable LPAE, kernel seems hang after turn on mmu on since
> printascii can't output any character in __mmap_switched.
> Did you happen to try BE kernel with LPAE enabled before? or am I missed
> something?

Well, I hacked head.S recently to fix booting with LPAE and BE8, but I was
unable to test early console since I was using virtio-console. It could be
that the page table entries mapping the uart aren't quite right, but no
obvious issues jump out from looking at the code.

How much visibility do you have on your platform? Can you take a look at the
page table entries and check they look ok please?

Cheers,

Will

v3.10 - big endian core support

[jgq516 at gmail.com]

On 07/08/2013 04:49 PM, Will Deacon wrote:
> On Mon, Jul 08, 2013 at 06:39:21AM +0100, jgq516 at gmail.com wrote:
>> On 07/01/2013 07:03 PM, Ben Dooks wrote:
>>> The latest big-endian changes, now on:
>>>
>>> 	git://git.baserock.org/delta/linux baserock/311/be/core
>>>
>>> This has a minor fix from the last version where a rebase missed a change
>>> in the smp_scu code.
>>>
>> Hello Ben,
>>
>> Thanks for you patches at first. I can boot BE kernel on vexpress a15 tc2
>> board with LPAE disabled.
>>
>> However if enable LPAE, kernel seems hang after turn on mmu on since
>> printascii can't output any character in __mmap_switched.
>> Did you happen to try BE kernel with LPAE enabled before? or am I missed
>> something?
> Well, I hacked head.S recently to fix booting with LPAE and BE8, but I was
> unable to test early console since I was using virtio-console. It could be
> that the page table entries mapping the uart aren't quite right, but no
> obvious issues jump out from looking at the code.
Good to know you tried LPAE and BE8, and I can test the hack code if you 
wish.
> How much visibility do you have on your platform?
The printascii can output before "b __enable_mmu", after move it to
__mmap_switched, nothing can be printed. But if disable LPAE, printascii
works again in __mmap_switched.
>   Can you take a look at the page table entries and check they look ok please?
Sorry, do you mean the section of __create_page_tables? could you please 
elaborate it?

Thanks,
Xiao

> Cheers,
>
> Will
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>

v3.10 - big endian core support

[Will Deacon]

On Mon, Jul 08, 2013 at 10:51:59AM +0100, jgq516 at gmail.com wrote:
> On 07/08/2013 04:49 PM, Will Deacon wrote:
> > Well, I hacked head.S recently to fix booting with LPAE and BE8, but I was
> > unable to test early console since I was using virtio-console. It could be
> > that the page table entries mapping the uart aren't quite right, but no
> > obvious issues jump out from looking at the code.
> Good to know you tried LPAE and BE8, and I can test the hack code if you 
> wish.

The hack got merged, since it fixed booting (which I managed to test), I
just couldn't test earlyprintk. Maybe I can try and get something up and
running on the model.

> > How much visibility do you have on your platform?
> The printascii can output before "b __enable_mmu", after move it to
> __mmap_switched, nothing can be printed. But if disable LPAE, printascii
> works again in __mmap_switched.

Ok, so the page tables are broken. The code is there to swap the two words,
but perhaps something ends up being off-by-4 or the like. I'll try and take
a look.

Will

v3.10 - big endian core support

[Will Deacon]

On Mon, Jul 08, 2013 at 12:02:02PM +0100, Will Deacon wrote:
> On Mon, Jul 08, 2013 at 10:51:59AM +0100, jgq516 at gmail.com wrote:
> > The printascii can output before "b __enable_mmu", after move it to
> > __mmap_switched, nothing can be printed. But if disable LPAE, printascii
> > works again in __mmap_switched.
> 
> Ok, so the page tables are broken. The code is there to swap the two words,
> but perhaps something ends up being off-by-4 or the like. I'll try and take
> a look.

Right, I managed to have a quick play with a 3.10 kernel and the good news
is that the page tables are fine. The bad part is that using
CONFIG_ARM_ATAG_DTB_COMPAT to get my command-line from ATAGs into the FDT
results in a NULL command line, so I don't see any output. If I hardcode the
command line in the kernel image, things work fine.

What kernel are you using, and how are you passing your command line?

Will

v3.10 - big endian core support

[jgq516 at gmail.com]

On 07/09/2013 01:03 AM, Will Deacon wrote:
> On Mon, Jul 08, 2013 at 12:02:02PM +0100, Will Deacon wrote:
>> On Mon, Jul 08, 2013 at 10:51:59AM +0100, jgq516 at gmail.com wrote:
>>> The printascii can output before "b __enable_mmu", after move it to
>>> __mmap_switched, nothing can be printed. But if disable LPAE, printascii
>>> works again in __mmap_switched.
>> Ok, so the page tables are broken. The code is there to swap the two words,
>> but perhaps something ends up being off-by-4 or the like. I'll try and take
>> a look.
> Right, I managed to have a quick play with a 3.10 kernel and the good news
> is that the page tables are fine. The bad part is that using
> CONFIG_ARM_ATAG_DTB_COMPAT to get my command-line from ATAGs into the FDT
> results in a NULL command line, so I don't see any output. If I hardcode the
> command line in the kernel image, things work fine.
>
> What kernel are you using, and how are you passing your command line?
3.4 kernel and command line is passed from uboot, I will try 3.10 
kernel, then cherry pick
some related patches from 3.10 if 3.10 works.

Thanks,
Xiao
> Will

v3.10 - big endian core support

[jgq516 at gmail.com]

On 07/09/2013 09:18 AM, jgq516 at gmail.com wrote:
> On 07/09/2013 01:03 AM, Will Deacon wrote:
>> On Mon, Jul 08, 2013 at 12:02:02PM +0100, Will Deacon wrote:
>>> On Mon, Jul 08, 2013 at 10:51:59AM +0100, jgq516 at gmail.com wrote:
>>>> The printascii can output before "b __enable_mmu", after move it to
>>>> __mmap_switched, nothing can be printed. But if disable LPAE, 
>>>> printascii
>>>> works again in __mmap_switched.
>>> Ok, so the page tables are broken. The code is there to swap the two 
>>> words,
>>> but perhaps something ends up being off-by-4 or the like. I'll try 
>>> and take
>>> a look.
>> Right, I managed to have a quick play with a 3.10 kernel and the good 
>> news
>> is that the page tables are fine. The bad part is that using
>> CONFIG_ARM_ATAG_DTB_COMPAT to get my command-line from ATAGs into the 
>> FDT
>> results in a NULL command line, so I don't see any output. If I 
>> hardcode the
>> command line in the kernel image, things work fine.
>>
Hi Will,

Which kernel tree are you used? I tried latest mainline kernel (used 
vexpress_defconfig
and vexpress-v2p-ca15_a7.dtb) without any modification, but it hangs as 
follows.

## Booting kernel from Legacy Image at 80000000 ...
    Image Name:   Linux-3.10.0+
    Image Type:   ARM Linux Kernel Image (uncompressed)
    Data Size:    2857168 Bytes = 2.7 MiB
    Load Address: 60008000
    Entry Point:  60008000
    Verifying Checksum ... OK
## Flattened Device Tree blob at 81f00000
    Booting using the fdt blob at 0x81f00000
    Loading Kernel Image ... OK
OK
    reserving fdt memory region: addr=ff000000 size=1000000
    Loading Device Tree to 9fee9000, end 9feee0a9 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Initializing cgroup subsys cpuset
Linux version 3.10.0+ (gjiang at gjiang-desktop) (gcc version 4.6.3 
(Sourcery CodeBench Lite 2012.03-57) ) #1 SMP Tue Jul 9 11:18:52 CST 2013
CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
Machine: ARM-Versatile Express, model: V2P-CA15_CA7
bootconsole [earlycon0] enabled
Memory policy: ECC disabled, Data cache writealloc
------------[ cut here ]------------
WARNING: at arch/arm/kernel/devtree.c:147 arm_dt_init_cpu_maps+0x134/0x1bc()
DT /cpu 5 nodes greater than max cores 4, capping them
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.0+ #1
[<80015b0c>] (unwind_backtrace+0x0/0xf8) from [<80011f20>] 
(show_stack+0x10/0x14)
[<80011f20>] (show_stack+0x10/0x14) from [<803a9c08>] (dump_stack+0x70/0x88)
[<803a9c08>] (dump_stack+0x70/0x88) from [<80021c10>] 
(warn_slowpath_common+0x54/0x68)
[<80021c10>] (warn_slowpath_common+0x54/0x68) from [<80021cb8>] 
(warn_slowpath_fmt+0x30/0x40)
[<80021cb8>] (warn_slowpath_fmt+0x30/0x40) from [<804d0cac>] 
(arm_dt_init_cpu_maps+0x134/0x1bc)
[<804d0cac>] (arm_dt_init_cpu_maps+0x134/0x1bc) from [<804cfd1c>] 
(setup_arch+0x680/0x898)
[<804cfd1c>] (setup_arch+0x680/0x898) from [<804cd640>] 
(start_kernel+0x90/0x310)
[<804cd640>] (start_kernel+0x90/0x310) from [<80008074>] (0x80008074)
---[ end trace 1b75b31a2719ed1c ]---
SMP: 5 cores greater than maximum (4), clipping
PERCPU: Embedded 7 pages/cpu @80d56000 s7296 r8192 d13184 u32768
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
Kernel command line: root=/dev/nfs console=ttyAMA0,38400n8 rw 
init=/linuxrc nfsroot=128.224.163.23:/home/gjiang/work/a15fs ip=dhcp 
earlyprintk
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1033984K/1048576K available (3867K kernel code, 166K rwdata, 
1012K rodata, 199K init, 137K bss, 14592K reserved)
Virtual kernel memory layout:
     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
     vmalloc : 0xc0800000 - 0xff000000   (1000 MB)
     lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
     modules : 0x7f000000 - 0x80000000   (  16 MB)
       .text : 0x80008000 - 0x804cc208   (4881 kB)
       .init : 0x804cd000 - 0x804fec80   ( 200 kB)
       .data : 0x80500000 - 0x80529a60   ( 167 kB)
        .bss : 0x80529a60 - 0x8054c0bc   ( 138 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
Hierarchical RCU implementation.
NR_IRQS:16 nr_irqs:16 16
Failed to obtain parent clocks for SP810!
sp804: arm,sp804 clock not found: -2
sp804: clock not found: -2
sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
Console: colour dummy device 80x30
Calibrating delay loop...

Thanks,
Xiao
>> What kernel are you using, and how are you passing your command line?
> 3.4 kernel and command line is passed from uboot, I will try 3.10 
> kernel, then cherry pick
> some related patches from 3.10 if 3.10 works.
>
> Thanks,
> Xiao
>> Will
>

v3.10 - big endian core support

[Will Deacon]

On Tue, Jul 09, 2013 at 04:34:45AM +0100, jgq516 at gmail.com wrote:
> On 07/09/2013 09:18 AM, jgq516 at gmail.com wrote:
> > On 07/09/2013 01:03 AM, Will Deacon wrote:
> >> On Mon, Jul 08, 2013 at 12:02:02PM +0100, Will Deacon wrote:
> >>> On Mon, Jul 08, 2013 at 10:51:59AM +0100, jgq516 at gmail.com wrote:
> >>>> The printascii can output before "b __enable_mmu", after move it to
> >>>> __mmap_switched, nothing can be printed. But if disable LPAE, 
> >>>> printascii
> >>>> works again in __mmap_switched.
> >>> Ok, so the page tables are broken. The code is there to swap the two 
> >>> words,
> >>> but perhaps something ends up being off-by-4 or the like. I'll try 
> >>> and take
> >>> a look.
> >> Right, I managed to have a quick play with a 3.10 kernel and the good 
> >> news
> >> is that the page tables are fine. The bad part is that using
> >> CONFIG_ARM_ATAG_DTB_COMPAT to get my command-line from ATAGs into the 
> >> FDT
> >> results in a NULL command line, so I don't see any output. If I 
> >> hardcode the
> >> command line in the kernel image, things work fine.
> >>
> Hi Will,
> 
> Which kernel tree are you used? I tried latest mainline kernel (used 
> vexpress_defconfig
> and vexpress-v2p-ca15_a7.dtb) without any modification, but it hangs as 
> follows.

Just try 3.10 at the moment -- we're currently in the middle of the merge
window and I know that there is some timer breakage that people have been
talking about.

Will

v3.10 - big endian core support

[jgq516 at gmail.com]

On 07/09/2013 03:45 PM, Will Deacon wrote:
> On Tue, Jul 09, 2013 at 04:34:45AM +0100, jgq516 at gmail.com wrote:
>> On 07/09/2013 09:18 AM, jgq516 at gmail.com wrote:
>>> On 07/09/2013 01:03 AM, Will Deacon wrote:
>>>> On Mon, Jul 08, 2013 at 12:02:02PM +0100, Will Deacon wrote:
>>>>> On Mon, Jul 08, 2013 at 10:51:59AM +0100, jgq516 at gmail.com wrote:
>>>>>> The printascii can output before "b __enable_mmu", after move it to
>>>>>> __mmap_switched, nothing can be printed. But if disable LPAE,
>>>>>> printascii
>>>>>> works again in __mmap_switched.
>>>>> Ok, so the page tables are broken. The code is there to swap the two
>>>>> words,
>>>>> but perhaps something ends up being off-by-4 or the like. I'll try
>>>>> and take
>>>>> a look.
>>>> Right, I managed to have a quick play with a 3.10 kernel and the good
>>>> news
>>>> is that the page tables are fine. The bad part is that using
>>>> CONFIG_ARM_ATAG_DTB_COMPAT to get my command-line from ATAGs into the
>>>> FDT
>>>> results in a NULL command line, so I don't see any output. If I
>>>> hardcode the
>>>> command line in the kernel image, things work fine.
>>>>
>> Hi Will,
>>
>> Which kernel tree are you used? I tried latest mainline kernel (used
>> vexpress_defconfig
>> and vexpress-v2p-ca15_a7.dtb) without any modification, but it hangs as
>> follows.
> Just try 3.10 at the moment -- we're currently in the middle of the merge
> window and I know that there is some timer breakage that people have been
> talking about.
Thanks a lot, it works after cherry pick patches from 3.10 kernel.

Thanks,
Xiao
> Will

v3.10 - big endian core support

[jgq516 at gmail.com]

On 07/09/2013 05:55 PM, jgq516 at gmail.com wrote:
> On 07/09/2013 03:45 PM, Will Deacon wrote:
>> On Tue, Jul 09, 2013 at 04:34:45AM +0100, jgq516 at gmail.com wrote:
>>> On 07/09/2013 09:18 AM, jgq516 at gmail.com wrote:
>>>> On 07/09/2013 01:03 AM, Will Deacon wrote:
>>>>> On Mon, Jul 08, 2013 at 12:02:02PM +0100, Will Deacon wrote:
>>>>>> On Mon, Jul 08, 2013 at 10:51:59AM +0100, jgq516 at gmail.com wrote:
>>>>>>> The printascii can output before "b __enable_mmu", after move it to
>>>>>>> __mmap_switched, nothing can be printed. But if disable LPAE,
>>>>>>> printascii
>>>>>>> works again in __mmap_switched.
>>>>>> Ok, so the page tables are broken. The code is there to swap the two
>>>>>> words,
>>>>>> but perhaps something ends up being off-by-4 or the like. I'll try
>>>>>> and take
>>>>>> a look.
>>>>> Right, I managed to have a quick play with a 3.10 kernel and the good
>>>>> news
>>>>> is that the page tables are fine. The bad part is that using
>>>>> CONFIG_ARM_ATAG_DTB_COMPAT to get my command-line from ATAGs into the
>>>>> FDT
>>>>> results in a NULL command line, so I don't see any output. If I
>>>>> hardcode the
>>>>> command line in the kernel image, things work fine.
>>>>>
>>> Hi Will,
>>>
>>> Which kernel tree are you used? I tried latest mainline kernel (used
>>> vexpress_defconfig
>>> and vexpress-v2p-ca15_a7.dtb) without any modification, but it hangs as
>>> follows.
>> Just try 3.10 at the moment -- we're currently in the middle of the 
>> merge
>> window and I know that there is some timer breakage that people have 
>> been
>> talking about.
Forget to say, 3.10 kernel (vexpress_defconfig + 
vexpress-v2p-ca15_a7.dtb) still has
the same problem as the newest mainline kernel.

## Booting kernel from Legacy Image at 80000000 ...
    Image Name:   Linux-3.10.0
    Image Type:   ARM Linux Kernel Image (uncompressed)
    Data Size:    2843016 Bytes = 2.7 MiB
    Load Address: 60008000
    Entry Point:  60008000
    Verifying Checksum ... OK
## Flattened Device Tree blob at 81f00000
    Booting using the fdt blob at 0x81f00000
    Loading Kernel Image ... OK
OK
    reserving fdt memory region: addr=ff000000 size=1000000
    Loading Device Tree to 9fee9000, end 9feee0a9 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Initializing cgroup subsys cpuset
Linux version 3.10.0 (gjiang at gjiang-desktop) (gcc version 4.6.3 
(Sourcery CodeBench Lite 2012.03-57) ) #2 SMP Tue Jul 9 17:56:53 CST 2013
CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
Machine: ARM-Versatile Express, model: V2P-CA15_CA7
bootconsole [earlycon0] enabled
Memory policy: ECC disabled, Data cache writealloc
------------[ cut here ]------------
WARNING: at arch/arm/kernel/devtree.c:147 arm_dt_init_cpu_maps+0x134/0x1bc()
DT /cpu 5 nodes greater than max cores 4, capping them
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.0 #2
[<80014e5c>] (unwind_backtrace+0x0/0xf8) from [<80011e94>] 
(show_stack+0x10/0x14)
[<80011e94>] (show_stack+0x10/0x14) from [<800209a8>] 
(warn_slowpath_common+0x54/0x68)
[<800209a8>] (warn_slowpath_common+0x54/0x68) from [<80020a50>] 
(warn_slowpath_fmt+0x30/0x40)
[<80020a50>] (warn_slowpath_fmt+0x30/0x40) from [<804cac80>] 
(arm_dt_init_cpu_maps+0x134/0x1bc)
[<804cac80>] (arm_dt_init_cpu_maps+0x134/0x1bc) from [<804ca190>] 
(setup_arch+0x658/0x6e4)
[<804ca190>] (setup_arch+0x658/0x6e4) from [<804c759c>] 
(start_kernel+0x90/0x30c)
[<804c759c>] (start_kernel+0x90/0x30c) from [<80008074>] (0x80008074)
---[ end trace 1b75b31a2719ed1c ]---
SMP: 5 cores greater than maximum (4), clipping
PERCPU: Embedded 7 pages/cpu @80d4f000 s7040 r8192 d13440 u32768
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
Kernel command line: root=/dev/nfs console=ttyAMA0,38400n8 rw 
init=/linuxrc nfsroot=128.224.163.23:/home/gjiang/work/a15fs ip=dhcp 
earlyprintk
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1024MB = 1024MB total
Memory: 1034012k/1034012k available, 14564k reserved, 0K highmem
Virtual kernel memory layout:
     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
     vmalloc : 0xc0800000 - 0xff000000   (1000 MB)
     lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
     modules : 0x7f000000 - 0x80000000   (  16 MB)
       .text : 0x80008000 - 0x804c6fe0   (4860 kB)
       .init : 0x804c7000 - 0x804f8b80   ( 199 kB)
       .data : 0x804fa000 - 0x80523780   ( 166 kB)
        .bss : 0x80523780 - 0x80545b7c   ( 137 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
Hierarchical RCU implementation.
NR_IRQS:16 nr_irqs:16 16
Failed to obtain parent clocks for SP810!
sp804: arm,sp804 clock not found: -2
sp804: clock not found: -2
sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
Console: colour dummy device 80x30
Calibrating delay loop...

Thanks,
Xiao

v3.10 - big endian core support

[Thomas Petazzoni]

Dear Will Deacon,

On Mon, 8 Jul 2013 18:03:53 +0100, Will Deacon wrote:
> On Mon, Jul 08, 2013 at 12:02:02PM +0100, Will Deacon wrote:
> > On Mon, Jul 08, 2013 at 10:51:59AM +0100, jgq516 at gmail.com wrote:
> > > The printascii can output before "b __enable_mmu", after move it to
> > > __mmap_switched, nothing can be printed. But if disable LPAE, printascii
> > > works again in __mmap_switched.
> > 
> > Ok, so the page tables are broken. The code is there to swap the two words,
> > but perhaps something ends up being off-by-4 or the like. I'll try and take
> > a look.
> 
> Right, I managed to have a quick play with a 3.10 kernel and the good news
> is that the page tables are fine. The bad part is that using
> CONFIG_ARM_ATAG_DTB_COMPAT to get my command-line from ATAGs into the FDT
> results in a NULL command line, so I don't see any output. If I hardcode the
> command line in the kernel image, things work fine.

Ben Dooks has a separate branch on top of this base branch for
big-endian support, that adds atags compat code to convert the ATAGs
data from LE to BE. See the baserock/311/be/atags branch in
git://git.baserock.org/delta/linux. Or
http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/311/be/atags.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

v3.10 - big endian core support

[Ben Dooks]

On 08/07/13 06:39, jgq516 at gmail.com wrote:
> On 07/01/2013 07:03 PM, Ben Dooks wrote:
>> The latest big-endian changes, now on:
>>
>> git://git.baserock.org/delta/linux baserock/311/be/core
>>
>> This has a minor fix from the last version where a rebase missed a change
>> in the smp_scu code.
>>
> Hello Ben,
>
> Thanks for you patches at first. I can boot BE kernel on vexpress a15 tc2
> board with LPAE disabled.
>
> However if enable LPAE, kernel seems hang after turn on mmu on since
> printascii can't output any character in __mmap_switched.
> Did you happen to try BE kernel with LPAE enabled before? or am I missed
> something?

I thought I did try the vexpress with LPAE, however it may have been
with a previous revision of the patches.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

v3.10 - big endian core support

[jgq516 at gmail.com]

On 07/08/2013 05:58 PM, Ben Dooks wrote:
> On 08/07/13 06:39, jgq516 at gmail.com wrote:
>> On 07/01/2013 07:03 PM, Ben Dooks wrote:
>>> The latest big-endian changes, now on:
>>>
>>> git://git.baserock.org/delta/linux baserock/311/be/core
>>>
>>> This has a minor fix from the last version where a rebase missed a 
>>> change
>>> in the smp_scu code.
>>>
>> Hello Ben,
>>
>> Thanks for you patches at first. I can boot BE kernel on vexpress a15 
>> tc2
>> board with LPAE disabled.
>>
>> However if enable LPAE, kernel seems hang after turn on mmu on since
>> printascii can't output any character in __mmap_switched.
>> Did you happen to try BE kernel with LPAE enabled before? or am I missed
>> something?
>
> I thought I did try the vexpress with LPAE, however it may have been
> with a previous revision of the patches.
>
Which revision? does it also existed in your tree? I want to give it a 
try :)

Thanks,
Xiao

v3.10 - big endian core support

[Ben Dooks]

On 08/07/13 11:03, jgq516 at gmail.com wrote:
> On 07/08/2013 05:58 PM, Ben Dooks wrote:
>> On 08/07/13 06:39, jgq516 at gmail.com wrote:
>>> On 07/01/2013 07:03 PM, Ben Dooks wrote:
>>>> The latest big-endian changes, now on:
>>>>
>>>> git://git.baserock.org/delta/linux baserock/311/be/core
>>>>
>>>> This has a minor fix from the last version where a rebase missed a
>>>> change
>>>> in the smp_scu code.
>>>>
>>> Hello Ben,
>>>
>>> Thanks for you patches at first. I can boot BE kernel on vexpress a15
>>> tc2
>>> board with LPAE disabled.
>>>
>>> However if enable LPAE, kernel seems hang after turn on mmu on since
>>> printascii can't output any character in __mmap_switched.
>>> Did you happen to try BE kernel with LPAE enabled before? or am I missed
>>> something?
>>
>> I thought I did try the vexpress with LPAE, however it may have been
>> with a previous revision of the patches.
>>
> Which revision? does it also existed in your tree? I want to give it a
> try :)

My notes show I did a custom 3.5 backport for a customer's kernel
so was not testing with the latest. I think I tried 3.9 with LPAE
but cannot find confirmation in my notes that this actually happened.


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

v3.10 - big endian core support

[jgq516 at gmail.com]

> My notes show I did a custom 3.5 backport for a customer's kernel
> so was not testing with the latest. I think I tried 3.9 with LPAE
> but cannot find confirmation in my notes that this actually happened.
>
>
Thanks for your feedback, it give me more confidence to make it work with
3.4 kernel, actually it works now :)

Xiao

v3.10 - big endian core support

[Ben Dooks]

On 09/07/13 10:53, jgq516 at gmail.com wrote:
>
>> My notes show I did a custom 3.5 backport for a customer's kernel
>> so was not testing with the latest. I think I tried 3.9 with LPAE
>> but cannot find confirmation in my notes that this actually happened.
>>
>>
> Thanks for your feedback, it give me more confidence to make it work with
> 3.4 kernel, actually it works now :)

There where several fixes done pre v3.10 which sorted out some kernel
bugs where endian-ness was assumed.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

v3.10 - big endian core support

[Thomas Petazzoni]

Dear Vijay Kilari,

On Fri, 12 Jul 2013 17:09:12 +0530, Vijay Kilari wrote:

> > Ben Dooks has a separate branch on top of this base branch for
> > big-endian support, that adds atags compat code to convert the ATAGs
> > data from LE to BE. See the baserock/311/be/atags branch in
> > git://git.baserock.org/delta/linux. Or
> > http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/311/be/atags.
> 
>  ARM VE TC2 board, enabling CONFIG_THUMB2_KERNEL failed to boot in BE mode
> It hangs at very early stage of boot

Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
of the TODO-list. I think Ben said he would probably not have much time
to work on this. I might be able to spare some time on this, so just
let me know if I should start working on this. If I remember correctly,
it's mainly the fixup_pv_table code that needed some Thumb2/BE love.

Will, is getting Thumb2 working a requirement to get the BE support
merged, or can we for now make the BE option depends on !THUMB2_KERNEL ?

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

v3.10 - big endian core support

[Vijay Kilari]

On Fri, Jul 12, 2013 at 5:17 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Vijay Kilari,
>
> On Fri, 12 Jul 2013 17:09:12 +0530, Vijay Kilari wrote:
>
>> > Ben Dooks has a separate branch on top of this base branch for
>> > big-endian support, that adds atags compat code to convert the ATAGs
>> > data from LE to BE. See the baserock/311/be/atags branch in
>> > git://git.baserock.org/delta/linux. Or
>> > http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/311/be/atags.
>>
>>  ARM VE TC2 board, enabling CONFIG_THUMB2_KERNEL failed to boot in BE mode
>> It hangs at very early stage of boot
>
> Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
> of the TODO-list. I think Ben said he would probably not have much time
> to work on this. I might be able to spare some time on this, so just
> let me know if I should start working on this. If I remember correctly,
> it's mainly the fixup_pv_table code that needed some Thumb2/BE love.

In fact, I tried with below changes.. still it fails

diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 2de1114..7df64c7 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -592,8 +592,14 @@ __fixup_a_pv_table:
        b       2f
 1:     add     r7, r3
        ldrh    ip, [r7, #2]
+#ifdef CONFIG_CPU_ENDIAN_BE8
+       rev     ip, ip
+#endif
        and     ip, 0x8f00
        orr     ip, r6  @ mask in offset bits 31-24
+#ifdef CONFIG_CPU_ENDIAN_BE8
+       rev     ip, ip
+#endif
        strh    ip, [r7, #2]
 2:     cmp     r4, r5
        ldrcc   r7, [r4], #4    @ use branch for delay slot

>
> Will, is getting Thumb2 working a requirement to get the BE support
> merged, or can we for now make the BE option depends on !THUMB2_KERNEL ?
>
> Thanks!
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com

v3.10 - big endian core support

[Ben Dooks]

On 12/07/13 12:56, Vijay Kilari wrote:
> On Fri, Jul 12, 2013 at 5:17 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com>  wrote:
>> Dear Vijay Kilari,
>>
>> On Fri, 12 Jul 2013 17:09:12 +0530, Vijay Kilari wrote:
>>
>>>> Ben Dooks has a separate branch on top of this base branch for
>>>> big-endian support, that adds atags compat code to convert the ATAGs
>>>> data from LE to BE. See the baserock/311/be/atags branch in
>>>> git://git.baserock.org/delta/linux. Or
>>>> http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/311/be/atags.
>>>
>>>   ARM VE TC2 board, enabling CONFIG_THUMB2_KERNEL failed to boot in BE mode
>>> It hangs at very early stage of boot
>>
>> Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
>> of the TODO-list. I think Ben said he would probably not have much time
>> to work on this. I might be able to spare some time on this, so just
>> let me know if I should start working on this. If I remember correctly,
>> it's mainly the fixup_pv_table code that needed some Thumb2/BE love.
>
> In fact, I tried with below changes.. still it fails
>
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index 2de1114..7df64c7 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -592,8 +592,14 @@ __fixup_a_pv_table:
>          b       2f
>   1:     add     r7, r3
>          ldrh    ip, [r7, #2]
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +       rev     ip, ip
> +#endif

Do you need a rev16 here? I think you may have tried
reversing the full 32 bits here instead of just the
16bits of instruction that was loaded.

>          and     ip, 0x8f00
>          orr     ip, r6  @ mask in offset bits 31-24
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +       rev     ip, ip
> +#endif
>          strh    ip, [r7, #2]
>   2:     cmp     r4, r5
>          ldrcc   r7, [r4], #4    @ use branch for delay slot
>
>>
>> Will, is getting Thumb2 working a requirement to get the BE support
>> merged, or can we for now make the BE option depends on !THUMB2_KERNEL ?
>>
>> Thanks!
>>
>> Thomas
>> --
>> Thomas Petazzoni, Free Electrons
>> Kernel, drivers, real-time and embedded Linux
>> development, consulting, training and support.
>> http://free-electrons.com


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

v3.10 - big endian core support

[jgq516 at gmail.com]

On 07/12/2013 08:00 PM, Ben Dooks wrote:
> On 12/07/13 12:56, Vijay Kilari wrote:
>> On Fri, Jul 12, 2013 at 5:17 PM, Thomas Petazzoni
>> <thomas.petazzoni@free-electrons.com>  wrote:
>>> Dear Vijay Kilari,
>>>
>>> On Fri, 12 Jul 2013 17:09:12 +0530, Vijay Kilari wrote:
>>>
>>>>> Ben Dooks has a separate branch on top of this base branch for
>>>>> big-endian support, that adds atags compat code to convert the ATAGs
>>>>> data from LE to BE. See the baserock/311/be/atags branch in
>>>>> git://git.baserock.org/delta/linux. Or
>>>>> http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/311/be/atags. 
>>>>>
>>>>
>>>>   ARM VE TC2 board, enabling CONFIG_THUMB2_KERNEL failed to boot in 
>>>> BE mode
>>>> It hangs at very early stage of boot
>>>
>>> Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
>>> of the TODO-list. I think Ben said he would probably not have much time
>>> to work on this. I might be able to spare some time on this, so just
>>> let me know if I should start working on this. If I remember correctly,
>>> it's mainly the fixup_pv_table code that needed some Thumb2/BE love.
>>
>> In fact, I tried with below changes.. still it fails
>>
>> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
>> index 2de1114..7df64c7 100644
>> --- a/arch/arm/kernel/head.S
>> +++ b/arch/arm/kernel/head.S
>> @@ -592,8 +592,14 @@ __fixup_a_pv_table:
>>          b       2f
>>   1:     add     r7, r3
>>          ldrh    ip, [r7, #2]
>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>> +       rev     ip, ip
>> +#endif
>
> Do you need a rev16 here? I think you may have tried
> reversing the full 32 bits here instead of just the
> 16bits of instruction that was loaded.
>
Thanks Ben, 3.4 kernel booted ok with your suggested modifications.

gjiang at gjiang-desktop:~/work/be-a15$ git diff
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 0ad3af8..1a0196c 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -600,8 +600,10 @@ __fixup_a_pv_table:
         b       2f
  1:     add     r7, r3
         ldrh    ip, [r7, #2]
+       rev16   ip, ip @be8
         and     ip, 0x8f00
         orr     ip, r6  @ mask in offset bits 31-24
+       rev16   ip, ip @be8
         strh    ip, [r7, #2]
  2:     cmp     r4, r5
         ldrcc   r7, [r4], #4    @ use branch for delay slot

root at localhost:~# zcat /proc/config.gz |grep BE8
CONFIG_CPU_ENDIAN_BE8=y
CONFIG_CPU_BE8_BOOT_LE=y
root at localhost:~# zcat /proc/config.gz |grep THUMB
CONFIG_ARM_THUMB=y
# CONFIG_ARM_THUMBEE is not set
CONFIG_THUMB2_KERNEL=y
CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11=y


Regards,
Xiao
>>          and     ip, 0x8f00
>>          orr     ip, r6  @ mask in offset bits 31-24
>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>> +       rev     ip, ip
>> +#endif
>>          strh    ip, [r7, #2]
>>   2:     cmp     r4, r5
>>          ldrcc   r7, [r4], #4    @ use branch for delay slot
>>
>>>
>>> Will, is getting Thumb2 working a requirement to get the BE support
>>> merged, or can we for now make the BE option depends on 
>>> !THUMB2_KERNEL ?
>>>
>>> Thanks!
>>>
>>> Thomas
>>> -- 
>>> Thomas Petazzoni, Free Electrons
>>> Kernel, drivers, real-time and embedded Linux
>>> development, consulting, training and support.
>>> http://free-electrons.com
>
>

v3.10 - big endian core support

[Vijay Kilari]

Yes, It works now after using rev16

Regards
Vijay

On Mon, Jul 15, 2013 at 8:20 AM,  <jgq516@gmail.com> wrote:
> On 07/12/2013 08:00 PM, Ben Dooks wrote:
>>
>> On 12/07/13 12:56, Vijay Kilari wrote:
>>>
>>> On Fri, Jul 12, 2013 at 5:17 PM, Thomas Petazzoni
>>> <thomas.petazzoni@free-electrons.com>  wrote:
>>>>
>>>> Dear Vijay Kilari,
>>>>
>>>> On Fri, 12 Jul 2013 17:09:12 +0530, Vijay Kilari wrote:
>>>>
>>>>>> Ben Dooks has a separate branch on top of this base branch for
>>>>>> big-endian support, that adds atags compat code to convert the ATAGs
>>>>>> data from LE to BE. See the baserock/311/be/atags branch in
>>>>>> git://git.baserock.org/delta/linux. Or
>>>>>>
>>>>>> http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/311/be/atags.
>>>>>
>>>>>
>>>>>   ARM VE TC2 board, enabling CONFIG_THUMB2_KERNEL failed to boot in BE
>>>>> mode
>>>>> It hangs at very early stage of boot
>>>>
>>>>
>>>> Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
>>>> of the TODO-list. I think Ben said he would probably not have much time
>>>> to work on this. I might be able to spare some time on this, so just
>>>> let me know if I should start working on this. If I remember correctly,
>>>> it's mainly the fixup_pv_table code that needed some Thumb2/BE love.
>>>
>>>
>>> In fact, I tried with below changes.. still it fails
>>>
>>> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
>>> index 2de1114..7df64c7 100644
>>> --- a/arch/arm/kernel/head.S
>>> +++ b/arch/arm/kernel/head.S
>>> @@ -592,8 +592,14 @@ __fixup_a_pv_table:
>>>          b       2f
>>>   1:     add     r7, r3
>>>          ldrh    ip, [r7, #2]
>>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>>> +       rev     ip, ip
>>> +#endif
>>
>>
>> Do you need a rev16 here? I think you may have tried
>> reversing the full 32 bits here instead of just the
>> 16bits of instruction that was loaded.
>>
> Thanks Ben, 3.4 kernel booted ok with your suggested modifications.
>
> gjiang at gjiang-desktop:~/work/be-a15$ git diff
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index 0ad3af8..1a0196c 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -600,8 +600,10 @@ __fixup_a_pv_table:
>
>         b       2f
>  1:     add     r7, r3
>         ldrh    ip, [r7, #2]
> +       rev16   ip, ip @be8
>
>         and     ip, 0x8f00
>         orr     ip, r6  @ mask in offset bits 31-24
> +       rev16   ip, ip @be8
>
>         strh    ip, [r7, #2]
>  2:     cmp     r4, r5
>         ldrcc   r7, [r4], #4    @ use branch for delay slot
>
> root at localhost:~# zcat /proc/config.gz |grep BE8
> CONFIG_CPU_ENDIAN_BE8=y
> CONFIG_CPU_BE8_BOOT_LE=y
> root at localhost:~# zcat /proc/config.gz |grep THUMB
> CONFIG_ARM_THUMB=y
> # CONFIG_ARM_THUMBEE is not set
> CONFIG_THUMB2_KERNEL=y
> CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11=y
>
>
> Regards,
> Xiao
>
>>>          and     ip, 0x8f00
>>>          orr     ip, r6  @ mask in offset bits 31-24
>>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>>> +       rev     ip, ip
>>> +#endif
>>>          strh    ip, [r7, #2]
>>>   2:     cmp     r4, r5
>>>          ldrcc   r7, [r4], #4    @ use branch for delay slot
>>>
>>>>
>>>> Will, is getting Thumb2 working a requirement to get the BE support
>>>> merged, or can we for now make the BE option depends on !THUMB2_KERNEL ?
>>>>
>>>> Thanks!
>>>>
>>>> Thomas
>>>> --
>>>> Thomas Petazzoni, Free Electrons
>>>> Kernel, drivers, real-time and embedded Linux
>>>> development, consulting, training and support.
>>>> http://free-electrons.com
>>
>>
>>
>

v3.10 - big endian core support

[Ben Dooks]

On 12/07/13 12:47, Thomas Petazzoni wrote:
> Dear Vijay Kilari,
>
> On Fri, 12 Jul 2013 17:09:12 +0530, Vijay Kilari wrote:
>
>>> Ben Dooks has a separate branch on top of this base branch for
>>> big-endian support, that adds atags compat code to convert the ATAGs
>>> data from LE to BE. See the baserock/311/be/atags branch in
>>> git://git.baserock.org/delta/linux. Or
>>> http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/311/be/atags.
>>
>>   ARM VE TC2 board, enabling CONFIG_THUMB2_KERNEL failed to boot in BE mode
>> It hangs at very early stage of boot
>
> Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
> of the TODO-list. I think Ben said he would probably not have much time
> to work on this. I might be able to spare some time on this, so just
> let me know if I should start working on this. If I remember correctly,
> it's mainly the fixup_pv_table code that needed some Thumb2/BE love.
>
> Will, is getting Thumb2 working a requirement to get the BE support
> merged, or can we for now make the BE option depends on !THUMB2_KERNEL ?

I would like to sort out getting this code merged as it seems to have
been tested by several people now outside Codethink.

I could try doing the THUMB2 support, but I do not have a lot of
experience with building THUMB2 kernels.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

v3.10 - big endian core support

[Thomas Petazzoni]

Dear Ben Dooks,

On Fri, 12 Jul 2013 12:58:45 +0100, Ben Dooks wrote:

> > Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
> > of the TODO-list. I think Ben said he would probably not have much time
> > to work on this. I might be able to spare some time on this, so just
> > let me know if I should start working on this. If I remember correctly,
> > it's mainly the fixup_pv_table code that needed some Thumb2/BE love.
> >
> > Will, is getting Thumb2 working a requirement to get the BE support
> > merged, or can we for now make the BE option depends on !THUMB2_KERNEL ?
> 
> I would like to sort out getting this code merged as it seems to have
> been tested by several people now outside Codethink.

I briefly talked with Will this week at LCE, and apparently he was
generally ok with the patches. He only mentioned that the series should
be split between core ARM stuff (that goes through Russell's tree), and
the platform-specific changes, that go through the different
maintainers tree.

> I could try doing the THUMB2 support, but I do not have a lot of
> experience with building THUMB2 kernels.

Ok. Let me know if you need some help. I'd really like to see this BE
work make it into 3.12.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

v3.10 - big endian core support

[Ben Dooks]

On 12/07/13 13:06, Thomas Petazzoni wrote:
> Dear Ben Dooks,
>
> On Fri, 12 Jul 2013 12:58:45 +0100, Ben Dooks wrote:
>
>>> Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
>>> of the TODO-list. I think Ben said he would probably not have much time
>>> to work on this. I might be able to spare some time on this, so just
>>> let me know if I should start working on this. If I remember correctly,
>>> it's mainly the fixup_pv_table code that needed some Thumb2/BE love.
>>>
>>> Will, is getting Thumb2 working a requirement to get the BE support
>>> merged, or can we for now make the BE option depends on !THUMB2_KERNEL ?
>>
>> I would like to sort out getting this code merged as it seems to have
>> been tested by several people now outside Codethink.
>
> I briefly talked with Will this week at LCE, and apparently he was
> generally ok with the patches. He only mentioned that the series should
> be split between core ARM stuff (that goes through Russell's tree), and
> the platform-specific changes, that go through the different
> maintainers tree.

The 311/be/core series which was the first posted has a few machine
specific bits in it (vexpress, highbank and mvebu) but is mainly the
ARM core code and bits of peripheral specific support which still live
under arch/arm.

I left there there as they're fairly small patches and would tend to get
lost. I can remove these before asking RMK to pull the core support and
possibly the atag/boot-endian patches.

>> I could try doing the THUMB2 support, but I do not have a lot of
>> experience with building THUMB2 kernels.
>
> Ok. Let me know if you need some help. I'd really like to see this BE
> work make it into 3.12.

Thanks for the testing. I'll see if I can get some time in early next
week to re-test and send against 3.11-rc series.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

v3.10 - big endian core support

[Will Deacon]

On Fri, Jul 12, 2013 at 12:58:45PM +0100, Ben Dooks wrote:
> On 12/07/13 12:47, Thomas Petazzoni wrote:
> > Dear Vijay Kilari,
> >
> > On Fri, 12 Jul 2013 17:09:12 +0530, Vijay Kilari wrote:
> >
> >>> Ben Dooks has a separate branch on top of this base branch for
> >>> big-endian support, that adds atags compat code to convert the ATAGs
> >>> data from LE to BE. See the baserock/311/be/atags branch in
> >>> git://git.baserock.org/delta/linux. Or
> >>> http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/311/be/atags.
> >>
> >>   ARM VE TC2 board, enabling CONFIG_THUMB2_KERNEL failed to boot in BE mode
> >> It hangs at very early stage of boot
> >
> > Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
> > of the TODO-list. I think Ben said he would probably not have much time
> > to work on this. I might be able to spare some time on this, so just
> > let me know if I should start working on this. If I remember correctly,
> > it's mainly the fixup_pv_table code that needed some Thumb2/BE love.
> >
> > Will, is getting Thumb2 working a requirement to get the BE support
> > merged, or can we for now make the BE option depends on !THUMB2_KERNEL ?
> 
> I would like to sort out getting this code merged as it seems to have
> been tested by several people now outside Codethink.
> 
> I could try doing the THUMB2 support, but I do not have a lot of
> experience with building THUMB2 kernels.

I think we should try and get Thumb-2 supported before merging this as there
isn't any real reason why the instruction set should cause endianness
issues. We're also only almost at -rc1, so there's still time to fix this
properly for 3.12 instead of adding a fake Kconfig dependency.

As for building a Thumb-2 kernel; just enable the option in menuconfig and
you're done. The compiler should "do the right thing".

Will

v3.10 - big endian core support

[Ben Dooks]

On 14/07/13 22:53, Will Deacon wrote:
> On Fri, Jul 12, 2013 at 12:58:45PM +0100, Ben Dooks wrote:
>> On 12/07/13 12:47, Thomas Petazzoni wrote:
>>> Dear Vijay Kilari,
>>>
>>> On Fri, 12 Jul 2013 17:09:12 +0530, Vijay Kilari wrote:
>>>
>>>>> Ben Dooks has a separate branch on top of this base branch for
>>>>> big-endian support, that adds atags compat code to convert the ATAGs
>>>>> data from LE to BE. See the baserock/311/be/atags branch in
>>>>> git://git.baserock.org/delta/linux. Or
>>>>> http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/311/be/atags.
>>>>
>>>>    ARM VE TC2 board, enabling CONFIG_THUMB2_KERNEL failed to boot in BE mode
>>>> It hangs at very early stage of boot
>>>
>>> Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
>>> of the TODO-list. I think Ben said he would probably not have much time
>>> to work on this. I might be able to spare some time on this, so just
>>> let me know if I should start working on this. If I remember correctly,
>>> it's mainly the fixup_pv_table code that needed some Thumb2/BE love.
>>>
>>> Will, is getting Thumb2 working a requirement to get the BE support
>>> merged, or can we for now make the BE option depends on !THUMB2_KERNEL ?
>>
>> I would like to sort out getting this code merged as it seems to have
>> been tested by several people now outside Codethink.
>>
>> I could try doing the THUMB2 support, but I do not have a lot of
>> experience with building THUMB2 kernels.
>
> I think we should try and get Thumb-2 supported before merging this as there
> isn't any real reason why the instruction set should cause endianness
> issues. We're also only almost at -rc1, so there's still time to fix this
> properly for 3.12 instead of adding a fake Kconfig dependency.
>
> As for building a Thumb-2 kernel; just enable the option in menuconfig and
> you're done. The compiler should "do the right thing".

I can build it, I just don't have the time and hardware to give it a
test at the moment. However it seems that changing to using 'rev16'
instead of 'rev'. I will make the necessary changes and get this ready
to go.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

v3.10 - big endian core support

[Thomas Petazzoni]

Dear Ben Dooks,

On Mon, 15 Jul 2013 09:03:28 +0100, Ben Dooks wrote:

> > As for building a Thumb-2 kernel; just enable the option in menuconfig and
> > you're done. The compiler should "do the right thing".
> 
> I can build it, I just don't have the time and hardware to give it a
> test at the moment. However it seems that changing to using 'rev16'
> instead of 'rev'. I will make the necessary changes and get this ready
> to go.

I am willing to give some testing to early patches, if needed. Do not
hesitate to send me things to test.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

v3.10 - big endian core support

[jgq516 at gmail.com]

On 07/15/2013 04:36 PM, Thomas Petazzoni wrote:
> Dear Ben Dooks,
>
> On Mon, 15 Jul 2013 09:03:28 +0100, Ben Dooks wrote:
>
>>> As for building a Thumb-2 kernel; just enable the option in menuconfig and
>>> you're done. The compiler should "do the right thing".
>> I can build it, I just don't have the time and hardware to give it a
>> test at the moment. However it seems that changing to using 'rev16'
>> instead of 'rev'. I will make the necessary changes and get this ready
>> to go.
> I am willing to give some testing to early patches, if needed. Do not
> hesitate to send me things to test.
I can test it too if needed :).

Thanks,
Xiao
> Thanks!
>
> Thomas

v3.10 - big endian core support

[Ben Dooks]

On 15/07/13 09:36, Thomas Petazzoni wrote:
> Dear Ben Dooks,
>
> On Mon, 15 Jul 2013 09:03:28 +0100, Ben Dooks wrote:
>
>>> As for building a Thumb-2 kernel; just enable the option in menuconfig and
>>> you're done. The compiler should "do the right thing".
>>
>> I can build it, I just don't have the time and hardware to give it a
>> test at the moment. However it seems that changing to using 'rev16'
>> instead of 'rev'. I will make the necessary changes and get this ready
>> to go.
>
> I am willing to give some testing to early patches, if needed. Do not
> hesitate to send me things to test.

I've pushed out two new branches on git.baserock.org/delta/linux.git
as:
	baserock/311/be/core-v2
	baserock/311/be/atags-v2

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

v3.10 - big endian core support

[Thomas Petazzoni]

Dear Ben Dooks,

On Mon, 15 Jul 2013 11:26:09 +0100, Ben Dooks wrote:

> I've pushed out two new branches on git.baserock.org/delta/linux.git
> as:
> 	baserock/311/be/core-v2
> 	baserock/311/be/atags-v2

I've tested baserock/311/be/core-v2, after rebasing it on top of
3.11-rc1. I've tested the following combination on an Armada XP board:
little endian ARM, big endian ARM, little endian Thumb2 and big endian
Thumb2. They all worked fine.

There were minor conflicts in arch/arm/kernel/sleep.S and
arch/arm/mach-mvebu/headsmp.S when doing the rebase on top of 3.11-rc1,
but nothing major.

Ben, do you have the time to rebase on 3.11-rc1 and post the patches
for merging?

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

v3.10 - big endian core support

[jgq516 at gmail.com]

On 07/15/2013 06:26 PM, Ben Dooks wrote:
> On 15/07/13 09:36, Thomas Petazzoni wrote:
>> Dear Ben Dooks,
>>
>> On Mon, 15 Jul 2013 09:03:28 +0100, Ben Dooks wrote:
>>
>>>> As for building a Thumb-2 kernel; just enable the option in 
>>>> menuconfig and
>>>> you're done. The compiler should "do the right thing".
>>>
>>> I can build it, I just don't have the time and hardware to give it a
>>> test at the moment. However it seems that changing to using 'rev16'
>>> instead of 'rev'. I will make the necessary changes and get this ready
>>> to go.
>>
>> I am willing to give some testing to early patches, if needed. Do not
>> hesitate to send me things to test.
>
> I've pushed out two new branches on git.baserock.org/delta/linux.git
> as:
>     baserock/311/be/core-v2
I have tested the 10 patches on this branch with latest mainline kernel 
(commit 47188d).
Vexpress a15 tc2 boards works with the combos: BE+LPAE on/off, 
BE+THUMB2+LPAE on and LE.

There are some conflicts existed between your patch set and latest kernel.

Thanks,
Xiao
>     baserock/311/be/atags-v2
>

v3.10 - big endian core support

[Ben Dooks]

On 16/07/13 09:00, jgq516 at gmail.com wrote:
> On 07/15/2013 06:26 PM, Ben Dooks wrote:
>> On 15/07/13 09:36, Thomas Petazzoni wrote:
>>> Dear Ben Dooks,
>>>
>>> On Mon, 15 Jul 2013 09:03:28 +0100, Ben Dooks wrote:
>>>
>>>>> As for building a Thumb-2 kernel; just enable the option in
>>>>> menuconfig and
>>>>> you're done. The compiler should "do the right thing".
>>>>
>>>> I can build it, I just don't have the time and hardware to give it a
>>>> test at the moment. However it seems that changing to using 'rev16'
>>>> instead of 'rev'. I will make the necessary changes and get this ready
>>>> to go.
>>>
>>> I am willing to give some testing to early patches, if needed. Do not
>>> hesitate to send me things to test.
>>
>> I've pushed out two new branches on git.baserock.org/delta/linux.git
>> as:
>> baserock/311/be/core-v2
> I have tested the 10 patches on this branch with latest mainline kernel
> (commit 47188d).
> Vexpress a15 tc2 boards works with the combos: BE+LPAE on/off,
> BE+THUMB2+LPAE on and LE.
>
> There are some conflicts existed between your patch set and latest kernel.

I will do a rebase onto HEAD in the next few days and then see if it
can be prepared for merging in the next merge window.


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius