ARM big-endian on current kernels for linux-3.8

ARM big-endian on current kernels for linux-3.8

[Ben Dooks]

I have been working on getting big-endian kernels working, mainly from
little-endian boot envrionments. The following patch series is what I
have been working on, mainly on the highbank and axp systems.

Feedback and testing is welcome.

I have published these on git.baserock.org

	git://git.baserock.org/delta/linux baserock/arm/bjdooks/be8_v1
	git://git.baserock.org/delta/linux baserock/arm/bjdooks/linux37-be8-1

The second is a backport of the v3.8-rc6 work due to problems with
booting on the highbank which Rob is resolving at the moment.

[PATCH 01/17] ARM: add CPU_BE8_BOOT_LE configuration

[Ben Dooks]

Add configuration for booting a BE8 system from a LE boot environment.

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

diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 3fd629d..70e2ad9 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -688,6 +688,13 @@ config CPU_ENDIAN_BE8
 	help
 	  Support for the BE-8 (big-endian) mode on ARMv6 and ARMv7 processors.
 
+config CPU_BE8_BOOT_LE
+	bool "Boot BE system from LE loader"
+	depends on CPU_ENDIAN_BE8
+	help
+	  Support for running BE-8 (big-endian) from a boot environment that is
+	  running in LE mode.
+
 config CPU_ENDIAN_BE32
 	bool
 	depends on CPU_BIG_ENDIAN
-- 
1.7.10.4

[PATCH 01/17] ARM: add CPU_BE8_BOOT_LE configuration

[Nicolas Pitre]

On Fri, 8 Feb 2013, Ben Dooks wrote:

> Add configuration for booting a BE8 system from a LE boot environment.
> 
> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
> ---
>  arch/arm/mm/Kconfig |    7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index 3fd629d..70e2ad9 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -688,6 +688,13 @@ config CPU_ENDIAN_BE8
>  	help
>  	  Support for the BE-8 (big-endian) mode on ARMv6 and ARMv7 processors.
>  
> +config CPU_BE8_BOOT_LE
> +	bool "Boot BE system from LE loader"
> +	depends on CPU_ENDIAN_BE8
> +	help
> +	  Support for running BE-8 (big-endian) from a boot environment that is
> +	  running in LE mode.
> +

This looks strange to have a patch that only adds a config symbol with 
no user.  Could you move it later in the series, or fold it with, say, 
patch #4?






>  config CPU_ENDIAN_BE32
>  	bool
>  	depends on CPU_BIG_ENDIAN
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

[PATCH 01/17] ARM: add CPU_BE8_BOOT_LE configuration

[Ben Dooks]

On 09/02/2013 04:10, Nicolas Pitre wrote:
> On Fri, 8 Feb 2013, Ben Dooks wrote:
>
>> Add configuration for booting a BE8 system from a LE boot 
>> environment.
>>
>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>> ---
>>  arch/arm/mm/Kconfig |    7 +++++++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
>> index 3fd629d..70e2ad9 100644
>> --- a/arch/arm/mm/Kconfig
>> +++ b/arch/arm/mm/Kconfig
>> @@ -688,6 +688,13 @@ config CPU_ENDIAN_BE8
>>  	help
>>  	  Support for the BE-8 (big-endian) mode on ARMv6 and ARMv7 
>> processors.
>>
>> +config CPU_BE8_BOOT_LE
>> +	bool "Boot BE system from LE loader"
>> +	depends on CPU_ENDIAN_BE8
>> +	help
>> +	  Support for running BE-8 (big-endian) from a boot environment 
>> that is
>> +	  running in LE mode.
>> +
>
> This looks strange to have a patch that only adds a config symbol 
> with
> no user.  Could you move it later in the series, or fold it with, 
> say,
> patch #4?

Yes, will look at folding it in.

-- 
Ben

[PATCH 02/17] ARM: set BE8 if LE in head code

[Ben Dooks]

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

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

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

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index fe4d9c3..39940a7 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -134,6 +134,9 @@ start:
 		.word	_edata			@ zImage end address
  THUMB(		.thumb			)
 1:
+#ifdef CONFIG_CPU_BE8_BOOT_LE
+		setend	be			@ go BE-8 if we booted LE / no-op if already BE-8
+#endif
 		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 486a15a..f1ab279 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -333,6 +333,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.
 	 */
+#ifdef CONFIG_CPU_BE8_BOOT_LE
+	setend	be				@ if system starts LE, go to BE-8
+#endif
 #ifdef CONFIG_ARM_VIRT_EXT
 	bl	__hyp_stub_install_secondary
 #endif
-- 
1.7.10.4

[PATCH 02/17] ARM: set BE8 if LE in head code

[Nicolas Pitre]

On Fri, 8 Feb 2013, Ben Dooks wrote:

> If we are booting in LE and compiled for BE8, then change the processor
> state in the head code. Since the instruction stream is always LE, we
> do not need to do anything special.
> 
> Also ensure that the secondary processors are started in the same mode.
> 
> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
> ---
>  arch/arm/boot/compressed/head.S |    3 +++
>  arch/arm/kernel/head.S          |    3 +++
>  2 files changed, 6 insertions(+)
> 
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index fe4d9c3..39940a7 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -134,6 +134,9 @@ start:
>  		.word	_edata			@ zImage end address
>   THUMB(		.thumb			)
>  1:
> +#ifdef CONFIG_CPU_BE8_BOOT_LE
> +		setend	be			@ go BE-8 if we booted LE / no-op if already BE-8
> +#endif
>  		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 486a15a..f1ab279 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -333,6 +333,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.
>  	 */
> +#ifdef CONFIG_CPU_BE8_BOOT_LE
> +	setend	be				@ if system starts LE, go to BE-8
> +#endif
>  #ifdef CONFIG_ARM_VIRT_EXT
>  	bl	__hyp_stub_install_secondary
>  #endif

For consistency, you should add a setend on the primary CPU entry path 
in kernel/head.S and not rely on the decompressor.  Some people don't 
use the compressed image.


Nicolas

[PATCH 02/17] ARM: set BE8 if LE in head code

[Ben Dooks]

On 09/02/2013 03:33, Nicolas Pitre wrote:
> On Fri, 8 Feb 2013, Ben Dooks wrote:
>
>> If we are booting in LE and compiled for BE8, then change the 
>> processor
>> state in the head code. Since the instruction stream is always LE, 
>> we
>> do not need to do anything special.
>>
>> Also ensure that the secondary processors are started in the same 
>> mode.
>>
>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>> ---
>>  arch/arm/boot/compressed/head.S |    3 +++
>>  arch/arm/kernel/head.S          |    3 +++
>>  2 files changed, 6 insertions(+)
>>
>> diff --git a/arch/arm/boot/compressed/head.S 
>> b/arch/arm/boot/compressed/head.S
>> index fe4d9c3..39940a7 100644
>> --- a/arch/arm/boot/compressed/head.S
>> +++ b/arch/arm/boot/compressed/head.S
>> @@ -134,6 +134,9 @@ start:
>>  		.word	_edata			@ zImage end address
>>   THUMB(		.thumb			)
>>  1:
>> +#ifdef CONFIG_CPU_BE8_BOOT_LE
>> +		setend	be			@ go BE-8 if we booted LE / no-op if already BE-8
>> +#endif
>>  		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 486a15a..f1ab279 100644
>> --- a/arch/arm/kernel/head.S
>> +++ b/arch/arm/kernel/head.S
>> @@ -333,6 +333,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.
>>  	 */
>> +#ifdef CONFIG_CPU_BE8_BOOT_LE
>> +	setend	be				@ if system starts LE, go to BE-8
>> +#endif
>>  #ifdef CONFIG_ARM_VIRT_EXT
>>  	bl	__hyp_stub_install_secondary
>>  #endif
>
> For consistency, you should add a setend on the primary CPU entry 
> path
> in kernel/head.S and not rely on the decompressor.  Some people don't
> use the compressed image.

Thank you for spotting this, will sort it out for the next round.

-- 
Ben

[PATCH 02/17] ARM: set BE8 if LE in head code

[Rob Herring]

On 02/08/2013 05:17 PM, Ben Dooks wrote:
> If we are booting in LE and compiled for BE8, then change the processor
> state in the head code. Since the instruction stream is always LE, we
> do not need to do anything special.
> 
> Also ensure that the secondary processors are started in the same mode.
> 
> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
> ---
>  arch/arm/boot/compressed/head.S |    3 +++
>  arch/arm/kernel/head.S          |    3 +++
>  2 files changed, 6 insertions(+)
> 
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index fe4d9c3..39940a7 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -134,6 +134,9 @@ start:
>  		.word	_edata			@ zImage end address
>   THUMB(		.thumb			)
>  1:
> +#ifdef CONFIG_CPU_BE8_BOOT_LE

Can't you use CONFIG_CPU_BIG_ENDIAN here rather than a new config option?

> +		setend	be			@ go BE-8 if we booted LE / no-op if already BE-8
> +#endif
>  		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 486a15a..f1ab279 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -333,6 +333,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.
>  	 */
> +#ifdef CONFIG_CPU_BE8_BOOT_LE
> +	setend	be				@ if system starts LE, go to BE-8
> +#endif
>  #ifdef CONFIG_ARM_VIRT_EXT
>  	bl	__hyp_stub_install_secondary
>  #endif
> 

[PATCH 02/17] ARM: set BE8 if LE in head code

[Ben Dooks]

On 09/02/2013 21:38, Rob Herring wrote:
> On 02/08/2013 05:17 PM, Ben Dooks wrote:
>> If we are booting in LE and compiled for BE8, then change the 
>> processor
>> state in the head code. Since the instruction stream is always LE, 
>> we
>> do not need to do anything special.
>>
>> Also ensure that the secondary processors are started in the same 
>> mode.
>>
>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>> ---
>>  arch/arm/boot/compressed/head.S |    3 +++
>>  arch/arm/kernel/head.S          |    3 +++
>>  2 files changed, 6 insertions(+)
>>
>> diff --git a/arch/arm/boot/compressed/head.S 
>> b/arch/arm/boot/compressed/head.S
>> index fe4d9c3..39940a7 100644
>> --- a/arch/arm/boot/compressed/head.S
>> +++ b/arch/arm/boot/compressed/head.S
>> @@ -134,6 +134,9 @@ start:
>>  		.word	_edata			@ zImage end address
>>   THUMB(		.thumb			)
>>  1:
>> +#ifdef CONFIG_CPU_BE8_BOOT_LE
>
> Can't you use CONFIG_CPU_BIG_ENDIAN here rather than a new config 
> option?

For this, we can probably do this as it is a no-op, however other parts
of the patch series do need this to allow it to boot from a little 
endian
booting environment.

-- 
Ben

[PATCH 02/17] ARM: set BE8 if LE in head code

[Ben Dooks]

On 09/02/13 21:38, Rob Herring wrote:
> On 02/08/2013 05:17 PM, Ben Dooks wrote:
>> If we are booting in LE and compiled for BE8, then change the processor
>> state in the head code. Since the instruction stream is always LE, we
>> do not need to do anything special.
>>
>> Also ensure that the secondary processors are started in the same mode.
>>
>> Signed-off-by: Ben Dooks<ben.dooks@codethink.co.uk>
>> ---
>>   arch/arm/boot/compressed/head.S |    3 +++
>>   arch/arm/kernel/head.S          |    3 +++
>>   2 files changed, 6 insertions(+)
>>
>> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
>> index fe4d9c3..39940a7 100644
>> --- a/arch/arm/boot/compressed/head.S
>> +++ b/arch/arm/boot/compressed/head.S
>> @@ -134,6 +134,9 @@ start:
>>   		.word	_edata			@ zImage end address
>>    THUMB(		.thumb			)
>>   1:
>> +#ifdef CONFIG_CPU_BE8_BOOT_LE
>
> Can't you use CONFIG_CPU_BIG_ENDIAN here rather than a new config option?

Actually, no as not all big endian CPUs will be BE8 (which should
guarnatee us the 'setend be' to be available) as we could still
build for BE32 systems where we would not want this.

I was considering doing the following:

ARM_BE8(	setend	be )

What do people think? It is a waste of 16 bytes if our system is already
in BE8 mode, but is going to look cleaner than

ARM_BE8_LEBOOT( setend be )

Any thoughts?

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

[PATCH 03/17] ARM: fix ARCH_IXP4xx usage of ARCH_SUPPORTS_BIG_ENDIAN

[Ben Dooks]

The Kconfig for arch/arm/mach-ixp4xx has a copy of the
definition of ARCH_SUPPORTS_BIG_ENDIAN which defaults
to yes. This means that if IXP4xx is selected and this
symbol is selected elswhere then an warning is produced.

Clean the following error up by making the symbol be
selected by the main ARCH_IXP4XX definition.

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)
---
 arch/arm/Kconfig             |    1 +
 arch/arm/mach-ixp4xx/Kconfig |    4 ----
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 67874b8..d3f6c4f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -517,6 +517,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"
-- 
1.7.10.4

[PATCH 04/17] ARM: Add ARCH_SUPPORTS_BIG_ENDIAN

[Ben Dooks]

Add ARCH_SUPPORTS_BIG_ENDIAN define to arch/arm/Kconfig. Since it used
to live in arch/arm/mach-ixp4xx/Kconfig we move it up to the ARM one
as the next best place for it.

It may be that it could be moved to a more generic location, with the
other ARCH_SUPPORT functions.

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

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d3f6c4f..8dfa634 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -152,6 +152,12 @@ config ARCH_HAS_CPUFREQ
 	  and that the relevant menu configurations are displayed for
 	  it.
 
+config ARCH_SUPPORTS_BIG_ENDIAN
+	bool
+	help
+	  Internal node to specify the architecture can run in Big Endian
+	  mode.
+
 config GENERIC_HWEIGHT
 	bool
 	default y
-- 
1.7.10.4

[PATCH 04/17] ARM: Add ARCH_SUPPORTS_BIG_ENDIAN

[Russell King - ARM Linux]

On Fri, Feb 08, 2013 at 11:17:34PM +0000, Ben Dooks wrote:
> Add ARCH_SUPPORTS_BIG_ENDIAN define to arch/arm/Kconfig. Since it used
> to live in arch/arm/mach-ixp4xx/Kconfig we move it up to the ARM one
> as the next best place for it.
> 
> It may be that it could be moved to a more generic location, with the
> other ARCH_SUPPORT functions.
> 
> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>

So in patch 3, you remove this option (which removes it from the generated
configs) and add it back in in the following patch.  This makes this series
non-bisectable.  Please roll this into patch 3 and update the patch
description accordingly.

I'd also suggest moving it to arch/arm/mm/Kconfig rather than
arch/arm/Kconfig, just before its only user, CPU_BIG_ENDIAN.

[PATCH 04/17] ARM: Add ARCH_SUPPORTS_BIG_ENDIAN

[Ben Dooks]

On 09/02/2013 11:55, Russell King - ARM Linux wrote:
> On Fri, Feb 08, 2013 at 11:17:34PM +0000, Ben Dooks wrote:
>> Add ARCH_SUPPORTS_BIG_ENDIAN define to arch/arm/Kconfig. Since it 
>> used
>> to live in arch/arm/mach-ixp4xx/Kconfig we move it up to the ARM one
>> as the next best place for it.
>>
>> It may be that it could be moved to a more generic location, with 
>> the
>> other ARCH_SUPPORT functions.
>>
>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>
> So in patch 3, you remove this option (which removes it from the 
> generated
> configs) and add it back in in the following patch.  This makes this 
> series
> non-bisectable.  Please roll this into patch 3 and update the patch
> description accordingly.
>
> I'd also suggest moving it to arch/arm/mm/Kconfig rather than
> arch/arm/Kconfig, just before its only user, CPU_BIG_ENDIAN.

I was wondering if it should go elsewhere for other archs to use,
but arch/arm/mmk/Kconfig seems reasonable. We always move it later.

-- 
Ben

[PATCH 05/17] 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 f1ab279..aafb151 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -579,8 +579,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 05/17] ARM: fixup_pv_table bug when CPU_ENDIAN_BE8

[Nicolas Pitre]

On Fri, 8 Feb 2013, Ben Dooks wrote:

> 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.

You are missing the CONFIG_THUMB2_KERNEL counterpart.

> 
> 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 f1ab279..aafb151 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -579,8 +579,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
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

[PATCH 05/17] ARM: fixup_pv_table bug when CPU_ENDIAN_BE8

[Ben Dooks]

On 09/02/13 03:40, Nicolas Pitre wrote:
> On Fri, 8 Feb 2013, Ben Dooks wrote:
>
>> 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.
>
> You are missing the CONFIG_THUMB2_KERNEL counterpart.

Sorry, I will have a look into that, although I may need
some help on that as I don't have any experience with
CONFIG_THUMB2_KERNEL or a userland to test with.

>> 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 f1ab279..aafb151 100644
>> --- a/arch/arm/kernel/head.S
>> +++ b/arch/arm/kernel/head.S
>> @@ -579,8 +579,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
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


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

[PATCH 05/17] ARM: fixup_pv_table bug when CPU_ENDIAN_BE8

[Nicolas Pitre]

On Mon, 11 Feb 2013, Ben Dooks wrote:

> On 09/02/13 03:40, Nicolas Pitre wrote:
> > On Fri, 8 Feb 2013, Ben Dooks wrote:
> > 
> > > 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.
> > 
> > You are missing the CONFIG_THUMB2_KERNEL counterpart.
> 
> Sorry, I will have a look into that, although I may need
> some help on that as I don't have any experience with
> CONFIG_THUMB2_KERNEL or a userland to test with.

You don't need to change your userland.  The kernel may be compiled 
using the Thumb2 instruction set even if userland is traditional ARM 
mode.


Nicolas

[PATCH 06/17] ARM: fixup head for atag verification

[Ben Dooks]

If we booted LE but running BE8, ensure we read ATAGs data from head code
in the correct mode.

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

diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S
index 854bd22..4eb53b2 100644
--- a/arch/arm/kernel/head-common.S
+++ b/arch/arm/kernel/head-common.S
@@ -21,6 +21,12 @@
 #define OF_DT_MAGIC 0xedfe0dd0 /* 0xd00dfeed in big-endian */
 #endif
 
+#ifdef CONFIG_CPU_BE8_BOOT_LE
+#define BE8_LE(x...)	x
+#else
+#define BE8_LE(x...)
+#endif
+
 /*
  * Exception handling.  Something went wrong and we can't proceed.  We
  * ought to tell the user, but since we don't have any guarantee that
@@ -53,10 +59,12 @@ __vet_atags:
 	cmp	r5, r6
 	beq	2f
 #endif
+BE8_LE(	rev	r5, r5 )
 	cmp	r5, #ATAG_CORE_SIZE		@ is first tag ATAG_CORE?
 	cmpne	r5, #ATAG_CORE_SIZE_EMPTY
 	bne	1f
 	ldr	r5, [r2, #4]
+BE8_LE(	rev	r5, r5 )
 	ldr	r6, =ATAG_CORE
 	cmp	r5, r6
 	bne	1f
-- 
1.7.10.4

[PATCH 06/17] ARM: fixup head for atag verification

[Nicolas Pitre]

On Fri, 8 Feb 2013, Ben Dooks wrote:

> If we booted LE but running BE8, ensure we read ATAGs data from head code
> in the correct mode.
> 
> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>

You must be working on some recent platform, right?  Your cover letter 
mention highbank.  Strange that you don't address the DT pointer 
validation as well.

> ---
>  arch/arm/kernel/head-common.S |    8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S
> index 854bd22..4eb53b2 100644
> --- a/arch/arm/kernel/head-common.S
> +++ b/arch/arm/kernel/head-common.S
> @@ -21,6 +21,12 @@
>  #define OF_DT_MAGIC 0xedfe0dd0 /* 0xd00dfeed in big-endian */
>  #endif
>  
> +#ifdef CONFIG_CPU_BE8_BOOT_LE
> +#define BE8_LE(x...)	x
> +#else
> +#define BE8_LE(x...)
> +#endif
> +
>  /*
>   * Exception handling.  Something went wrong and we can't proceed.  We
>   * ought to tell the user, but since we don't have any guarantee that
> @@ -53,10 +59,12 @@ __vet_atags:
>  	cmp	r5, r6
>  	beq	2f
>  #endif
> +BE8_LE(	rev	r5, r5 )
>  	cmp	r5, #ATAG_CORE_SIZE		@ is first tag ATAG_CORE?
>  	cmpne	r5, #ATAG_CORE_SIZE_EMPTY
>  	bne	1f
>  	ldr	r5, [r2, #4]
> +BE8_LE(	rev	r5, r5 )
>  	ldr	r6, =ATAG_CORE
>  	cmp	r5, r6
>  	bne	1f
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

[PATCH 06/17] ARM: fixup head for atag verification

[Ben Dooks]

On 09/02/2013 03:51, Nicolas Pitre wrote:
> On Fri, 8 Feb 2013, Ben Dooks wrote:
>
>> If we booted LE but running BE8, ensure we read ATAGs data from head 
>> code
>> in the correct mode.
>>
>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>
> You must be working on some recent platform, right?  Your cover 
> letter
> mention highbank.  Strange that you don't address the DT pointer
> validation as well.

I am using highbank for my main tests, I believe the DT pointer is
correct as the data is always guaranteed to be BE and the kernel
is doing the correct thing to test for it.

I will re-check this, but it all looked fine when I went through it.

-- 
Ben

[PATCH 07/17] 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 49f335d..3756f42 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -46,7 +46,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:
@@ -59,18 +59,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;
 }
@@ -83,8 +83,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;
 	}
 
@@ -210,15 +210,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);
 
@@ -273,7 +273,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;
@@ -305,7 +305,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 08/17] 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 45eac87..0fcd0ce 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(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 09/17] ARM: add atag32_to_cpu() function

[Ben Dooks]

Add atag32_to_cpu() function to allow code manipulating ATAGs to deal
with the case where the boot-loader was in little-endian and Linux is
running big-endian.

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
 arch/arm/include/uapi/asm/setup.h |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/uapi/asm/setup.h b/arch/arm/include/uapi/asm/setup.h
index 979ff40..d74a417 100644
--- a/arch/arm/include/uapi/asm/setup.h
+++ b/arch/arm/include/uapi/asm/setup.h
@@ -175,13 +175,18 @@ struct tagtable {
 
 #define tag_member_present(tag,member)				\
 	((unsigned long)(&((struct tag *)0L)->member + 1)	\
-		<= (tag)->hdr.size * 4)
+		<= atag32_to_cpu((tag)->hdr.size) * 4)
 
-#define tag_next(t)	((struct tag *)((__u32 *)(t) + (t)->hdr.size))
+#define tag_next(t)	((struct tag *)((__u32 *)(t) + atag32_to_cpu((t)->hdr.size)))
 #define tag_size(type)	((sizeof(struct tag_header) + sizeof(struct type)) >> 2)
 
 #define for_each_tag(t,base)		\
 	for (t = base; t->hdr.size; t = tag_next(t))
 
+#ifdef CONFIG_CPU_BE8_BOOT_LE
+#define atag32_to_cpu(x)	le32_to_cpu(x)
+#else
+#define atag32_to_cpu(x)	x
+#endif
 
 #endif /* _UAPI__ASMARM_SETUP_H */
-- 
1.7.10.4

[PATCH 09/17] ARM: add atag32_to_cpu() function

[Nicolas Pitre]

On Fri, 8 Feb 2013, Ben Dooks wrote:

> Add atag32_to_cpu() function to allow code manipulating ATAGs to deal
> with the case where the boot-loader was in little-endian and Linux is
> running big-endian.
> 
> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>

Acked-by: Nicolas Pitre <nico@linaro.org>

> ---
>  arch/arm/include/uapi/asm/setup.h |    9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/include/uapi/asm/setup.h b/arch/arm/include/uapi/asm/setup.h
> index 979ff40..d74a417 100644
> --- a/arch/arm/include/uapi/asm/setup.h
> +++ b/arch/arm/include/uapi/asm/setup.h
> @@ -175,13 +175,18 @@ struct tagtable {
>  
>  #define tag_member_present(tag,member)				\
>  	((unsigned long)(&((struct tag *)0L)->member + 1)	\
> -		<= (tag)->hdr.size * 4)
> +		<= atag32_to_cpu((tag)->hdr.size) * 4)
>  
> -#define tag_next(t)	((struct tag *)((__u32 *)(t) + (t)->hdr.size))
> +#define tag_next(t)	((struct tag *)((__u32 *)(t) + atag32_to_cpu((t)->hdr.size)))
>  #define tag_size(type)	((sizeof(struct tag_header) + sizeof(struct type)) >> 2)
>  
>  #define for_each_tag(t,base)		\
>  	for (t = base; t->hdr.size; t = tag_next(t))
>  
> +#ifdef CONFIG_CPU_BE8_BOOT_LE
> +#define atag32_to_cpu(x)	le32_to_cpu(x)
> +#else
> +#define atag32_to_cpu(x)	x
> +#endif
>  
>  #endif /* _UAPI__ASMARM_SETUP_H */
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

[PATCH 09/17] ARM: add atag32_to_cpu() function

[Russell King - ARM Linux]

On Fri, Feb 08, 2013 at 11:17:39PM +0000, Ben Dooks wrote:
> Add atag32_to_cpu() function to allow code manipulating ATAGs to deal
> with the case where the boot-loader was in little-endian and Linux is
> running big-endian.
...
> +#ifdef CONFIG_CPU_BE8_BOOT_LE
> +#define atag32_to_cpu(x)	le32_to_cpu(x)
> +#else
> +#define atag32_to_cpu(x)	x
> +#endif

Actually, with a LE kernel, le32_to_cpu() ends up being a no-op too.  So
I'm wondering if we should do this a different way...

Also, this will cause sparse to complain - le32_to_cpu() takes a le32
type not a u32 type.

This brings up a whole load of difficulties though: what format are the
ATAGs on older BE hardware - I bet it's CPU-endian format there.  So,
I'm wondering if we should do this:

1. define all tags using a new __atagXX, etc types.
2. always use atagXX_to_cpu() to read these.
3. Implement:

#if defined(CONFIG_ATAG_LE)
typedef __le32 __atag32;
...
#define atag32_to_cpu(x) le32_to_cpu(x)
...
#elif defined(CONFIG_ATAG_BE)
typedef __be32 __atag32;
...
#define atag32_to_cpu(x) be32_to_cpu(x)
...
#elif defined(CONFIG_ATAG_NE)
typedef __u32 __atag32;
...
#define atag32_to_cpu(x) x
...
#endif

and select the appropriate definition.  Obviously, this is a fundamental
configuration just like the overall BE/LE configuration of the kernel.

[PATCH 09/17] ARM: add atag32_to_cpu() function

[Ben Dooks]

On 09/02/13 12:03, Russell King - ARM Linux wrote:
> On Fri, Feb 08, 2013 at 11:17:39PM +0000, Ben Dooks wrote:
>> Add atag32_to_cpu() function to allow code manipulating ATAGs to deal
>> with the case where the boot-loader was in little-endian and Linux is
>> running big-endian.
> ...
>> +#ifdef CONFIG_CPU_BE8_BOOT_LE
>> +#define atag32_to_cpu(x)	le32_to_cpu(x)
>> +#else
>> +#define atag32_to_cpu(x)	x
>> +#endif
>
> Actually, with a LE kernel, le32_to_cpu() ends up being a no-op too.  So
> I'm wondering if we should do this a different way...
>
> Also, this will cause sparse to complain - le32_to_cpu() takes a le32
> type not a u32 type.

Yes, you're right on that.

> This brings up a whole load of difficulties though: what format are the
> ATAGs on older BE hardware - I bet it's CPU-endian format there.  So,
> I'm wondering if we should do this:

It isn't defined, and I have failed to find any information on
it online. I have no idea if the IXP devices ran their boot-loader
in big-endian or little-endian format?

Input welcome from anyone who can remember.

> 1. define all tags using a new __atagXX, etc types.
> 2. always use atagXX_to_cpu() to read these.
> 3. Implement:
>
> #if defined(CONFIG_ATAG_LE)
> typedef __le32 __atag32;
> ...
> #define atag32_to_cpu(x) le32_to_cpu(x)
> ...
> #elif defined(CONFIG_ATAG_BE)
> typedef __be32 __atag32;
> ...
> #define atag32_to_cpu(x) be32_to_cpu(x)
> ...
> #elif defined(CONFIG_ATAG_NE)
> typedef __u32 __atag32;
> ...
> #define atag32_to_cpu(x) x
> ...
> #endif
>
> and select the appropriate definition.  Obviously, this is a fundamental
> configuration just like the overall BE/LE configuration of the kernel.

Ok, should I sort out doing that for the next round of patches?

Should the ATAG_xx configurations go into arch/arm/Kconfig or
is there somewhere better for them to go?

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

[PATCH 09/17] ARM: add atag32_to_cpu() function

[Russell King - ARM Linux]

On Mon, Feb 11, 2013 at 07:15:19PM +0000, Ben Dooks wrote:
> It isn't defined, and I have failed to find any information on
> it online. I have no idea if the IXP devices ran their boot-loader
> in big-endian or little-endian format?

It will be native endian, because that's the format which we've supported
up to now.

>> 1. define all tags using a new __atagXX, etc types.
>> 2. always use atagXX_to_cpu() to read these.
>> 3. Implement:
>>
>> #if defined(CONFIG_ATAG_LE)
>> typedef __le32 __atag32;
>> ...
>> #define atag32_to_cpu(x) le32_to_cpu(x)
>> ...
>> #elif defined(CONFIG_ATAG_BE)
>> typedef __be32 __atag32;
>> ...
>> #define atag32_to_cpu(x) be32_to_cpu(x)
>> ...
>> #elif defined(CONFIG_ATAG_NE)
>> typedef __u32 __atag32;
>> ...
>> #define atag32_to_cpu(x) x
>> ...
>> #endif
>>
>> and select the appropriate definition.  Obviously, this is a fundamental
>> configuration just like the overall BE/LE configuration of the kernel.
>
> Ok, should I sort out doing that for the next round of patches?

Yes please.

> Should the ATAG_xx configurations go into arch/arm/Kconfig or
> is there somewhere better for them to go?

arch/arm/Kconfig for the time being.  I've debated about moving some
config options to arch/arm/boot/Kconfig

[PATCH 09/17] ARM: add atag32_to_cpu() function

[Jean-Christophe PLAGNIOL-VILLARD]

On 19:15 Mon 11 Feb     , Ben Dooks wrote:
> On 09/02/13 12:03, Russell King - ARM Linux wrote:
> >On Fri, Feb 08, 2013 at 11:17:39PM +0000, Ben Dooks wrote:
> >>Add atag32_to_cpu() function to allow code manipulating ATAGs to deal
> >>with the case where the boot-loader was in little-endian and Linux is
> >>running big-endian.
> >...
> >>+#ifdef CONFIG_CPU_BE8_BOOT_LE
> >>+#define atag32_to_cpu(x)	le32_to_cpu(x)
> >>+#else
> >>+#define atag32_to_cpu(x)	x
> >>+#endif
> >
> >Actually, with a LE kernel, le32_to_cpu() ends up being a no-op too.  So
> >I'm wondering if we should do this a different way...
> >
> >Also, this will cause sparse to complain - le32_to_cpu() takes a le32
> >type not a u32 type.
> 
> Yes, you're right on that.
> 
> >This brings up a whole load of difficulties though: what format are the
> >ATAGs on older BE hardware - I bet it's CPU-endian format there.  So,
> >I'm wondering if we should do this:
> 
> It isn't defined, and I have failed to find any information on
> it online. I have no idea if the IXP devices ran their boot-loader
> in big-endian or little-endian format?
> 
> Input welcome from anyone who can remember.
I run the ixp in be

and pass the atag in be

Best Regards,
J.
> 
> >1. define all tags using a new __atagXX, etc types.
> >2. always use atagXX_to_cpu() to read these.
> >3. Implement:
> >
> >#if defined(CONFIG_ATAG_LE)
> >typedef __le32 __atag32;
> >...
> >#define atag32_to_cpu(x) le32_to_cpu(x)
> >...
> >#elif defined(CONFIG_ATAG_BE)
> >typedef __be32 __atag32;
> >...
> >#define atag32_to_cpu(x) be32_to_cpu(x)
> >...
> >#elif defined(CONFIG_ATAG_NE)
> >typedef __u32 __atag32;
> >...
> >#define atag32_to_cpu(x) x
> >...
> >#endif
> >
> >and select the appropriate definition.  Obviously, this is a fundamental
> >configuration just like the overall BE/LE configuration of the kernel.
> 
> Ok, should I sort out doing that for the next round of patches?
> 
> Should the ATAG_xx configurations go into arch/arm/Kconfig or
> is there somewhere better for them to go?
> 
> -- 
> Ben Dooks				http://www.codethink.co.uk/
> Senior Engineer				Codethink - Providing Genius
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 09/17] ARM: add atag32_to_cpu() function

[Russell King - ARM Linux]

On Tue, Feb 12, 2013 at 07:46:36PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> I run the ixp in be
> 
> and pass the atag in be

So that would be "native endian" then.

[PATCH 10/17] ARM: update atag-to-fdt code to be endian agnostic

[Ben Dooks]

The atag-to-fdt code can now use the conversion function we introduced
previously to avoid it having to know about the endian-ness of the
environment which booted the processor.

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
 arch/arm/boot/compressed/atags_to_fdt.c |   20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c
index aabc02a..a64ec71 100644
--- a/arch/arm/boot/compressed/atags_to_fdt.c
+++ b/arch/arm/boot/compressed/atags_to_fdt.c
@@ -108,9 +108,9 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)
 	       return 0;
 
 	/* validate the ATAG */
-	if (atag->hdr.tag != ATAG_CORE ||
-	    (atag->hdr.size != tag_size(tag_core) &&
-	     atag->hdr.size != 2))
+	if (atag->hdr.tag != atag32_to_cpu(ATAG_CORE) ||
+	    (atag->hdr.size != atag32_to_cpu(tag_size(tag_core)) &&
+	     atag->hdr.size != atag32_to_cpu(2)))
 		return 1;
 
 	/* let's give it all the room it could need */
@@ -132,17 +132,17 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)
 			else
 				setprop_string(fdt, "/chosen", "bootargs",
 					       atag->u.cmdline.cmdline);
-		} else if (atag->hdr.tag == ATAG_MEM) {
+		} else if (atag->hdr.tag == atag32_to_cpu(ATAG_MEM)) {
 			if (memcount >= sizeof(mem_reg_property)/4)
 				continue;
-			if (!atag->u.mem.size)
+			if (!atag32_to_cpu(atag->u.mem.size))
 				continue;
-			mem_reg_property[memcount++] = cpu_to_fdt32(atag->u.mem.start);
-			mem_reg_property[memcount++] = cpu_to_fdt32(atag->u.mem.size);
-		} else if (atag->hdr.tag == ATAG_INITRD2) {
+			mem_reg_property[memcount++] = cpu_to_fdt32(atag32_to_cpu(atag->u.mem.start));
+			mem_reg_property[memcount++] = cpu_to_fdt32(atag32_to_cpu(atag->u.mem.size));
+		} else if (atag->hdr.tag == atag32_to_cpu(ATAG_INITRD2)) {
 			uint32_t initrd_start, initrd_size;
-			initrd_start = atag->u.initrd.start;
-			initrd_size = atag->u.initrd.size;
+			initrd_start = atag32_to_cpu(atag->u.initrd.start);
+			initrd_size = atag32_to_cpu(____atag->u.initrd.size);
 			setprop_cell(fdt, "/chosen", "linux,initrd-start",
 					initrd_start);
 			setprop_cell(fdt, "/chosen", "linux,initrd-end",
-- 
1.7.10.4

[PATCH 10/17] ARM: update atag-to-fdt code to be endian agnostic

[Nicolas Pitre]

On Fri, 8 Feb 2013, Ben Dooks wrote:

> The atag-to-fdt code can now use the conversion function we introduced
> previously to avoid it having to know about the endian-ness of the
> environment which booted the processor.
> 
> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>

Acked-by: Nicolas Pitre <nico@linaro.org>


> ---
>  arch/arm/boot/compressed/atags_to_fdt.c |   20 ++++++++++----------
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c
> index aabc02a..a64ec71 100644
> --- a/arch/arm/boot/compressed/atags_to_fdt.c
> +++ b/arch/arm/boot/compressed/atags_to_fdt.c
> @@ -108,9 +108,9 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)
>  	       return 0;
>  
>  	/* validate the ATAG */
> -	if (atag->hdr.tag != ATAG_CORE ||
> -	    (atag->hdr.size != tag_size(tag_core) &&
> -	     atag->hdr.size != 2))
> +	if (atag->hdr.tag != atag32_to_cpu(ATAG_CORE) ||
> +	    (atag->hdr.size != atag32_to_cpu(tag_size(tag_core)) &&
> +	     atag->hdr.size != atag32_to_cpu(2)))
>  		return 1;
>  
>  	/* let's give it all the room it could need */
> @@ -132,17 +132,17 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)
>  			else
>  				setprop_string(fdt, "/chosen", "bootargs",
>  					       atag->u.cmdline.cmdline);
> -		} else if (atag->hdr.tag == ATAG_MEM) {
> +		} else if (atag->hdr.tag == atag32_to_cpu(ATAG_MEM)) {
>  			if (memcount >= sizeof(mem_reg_property)/4)
>  				continue;
> -			if (!atag->u.mem.size)
> +			if (!atag32_to_cpu(atag->u.mem.size))
>  				continue;
> -			mem_reg_property[memcount++] = cpu_to_fdt32(atag->u.mem.start);
> -			mem_reg_property[memcount++] = cpu_to_fdt32(atag->u.mem.size);
> -		} else if (atag->hdr.tag == ATAG_INITRD2) {
> +			mem_reg_property[memcount++] = cpu_to_fdt32(atag32_to_cpu(atag->u.mem.start));
> +			mem_reg_property[memcount++] = cpu_to_fdt32(atag32_to_cpu(atag->u.mem.size));
> +		} else if (atag->hdr.tag == atag32_to_cpu(ATAG_INITRD2)) {
>  			uint32_t initrd_start, initrd_size;
> -			initrd_start = atag->u.initrd.start;
> -			initrd_size = atag->u.initrd.size;
> +			initrd_start = atag32_to_cpu(atag->u.initrd.start);
> +			initrd_size = atag32_to_cpu(____atag->u.initrd.size);
>  			setprop_cell(fdt, "/chosen", "linux,initrd-start",
>  					initrd_start);
>  			setprop_cell(fdt, "/chosen", "linux,initrd-end",
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

[PATCH 10/17] ARM: update atag-to-fdt code to be endian agnostic

[Russell King - ARM Linux]

On Fri, Feb 08, 2013 at 11:17:40PM +0000, Ben Dooks wrote:
> -	if (atag->hdr.tag != ATAG_CORE ||
> -	    (atag->hdr.size != tag_size(tag_core) &&
> -	     atag->hdr.size != 2))
> +	if (atag->hdr.tag != atag32_to_cpu(ATAG_CORE) ||
> +	    (atag->hdr.size != atag32_to_cpu(tag_size(tag_core)) &&
> +	     atag->hdr.size != atag32_to_cpu(2)))

This is wrong.  You're saying that "ATAG_CORE" is in LE32 format.  It
isn't.  It's in CPU endian format.  If you want to do this kind of thing,
you also need to define cpu_to_atag32() macros as well, otherwise this
will cause sparse warnings.

> -			initrd_start = atag->u.initrd.start;
> -			initrd_size = atag->u.initrd.size;
> +			initrd_start = atag32_to_cpu(atag->u.initrd.start);
> +			initrd_size = atag32_to_cpu(____atag->u.initrd.size);

Where did those four underscores come from?  Has this been built?

[PATCH 10/17] ARM: update atag-to-fdt code to be endian agnostic

[Ben Dooks]

On 09/02/13 12:05, Russell King - ARM Linux wrote:
> On Fri, Feb 08, 2013 at 11:17:40PM +0000, Ben Dooks wrote:
>> -	if (atag->hdr.tag != ATAG_CORE ||
>> -	    (atag->hdr.size != tag_size(tag_core)&&
>> -	     atag->hdr.size != 2))
>> +	if (atag->hdr.tag != atag32_to_cpu(ATAG_CORE) ||
>> +	    (atag->hdr.size != atag32_to_cpu(tag_size(tag_core))&&
>> +	     atag->hdr.size != atag32_to_cpu(2)))
>
> This is wrong.  You're saying that "ATAG_CORE" is in LE32 format.  It
> isn't.  It's in CPU endian format.  If you want to do this kind of thing,
> you also need to define cpu_to_atag32() macros as well, otherwise this
> will cause sparse warnings.
>
>> -			initrd_start = atag->u.initrd.start;
>> -			initrd_size = atag->u.initrd.size;
>> +			initrd_start = atag32_to_cpu(atag->u.initrd.start);
>> +			initrd_size = atag32_to_cpu(____atag->u.initrd.size);
>
> Where did those four underscores come from?  Has this been built?

I probably missed building this one. I've been mostly testing with DT
based systems.

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

[PATCH 10/17] ARM: update atag-to-fdt code to be endian agnostic

[Nicolas Pitre]

On Mon, 11 Feb 2013, Ben Dooks wrote:

> On 09/02/13 12:05, Russell King - ARM Linux wrote:
> > On Fri, Feb 08, 2013 at 11:17:40PM +0000, Ben Dooks wrote:
> > > -	if (atag->hdr.tag != ATAG_CORE ||
> > > -	    (atag->hdr.size != tag_size(tag_core)&&
> > > -	     atag->hdr.size != 2))
> > > +	if (atag->hdr.tag != atag32_to_cpu(ATAG_CORE) ||
> > > +	    (atag->hdr.size != atag32_to_cpu(tag_size(tag_core))&&
> > > +	     atag->hdr.size != atag32_to_cpu(2)))
> > 
> > This is wrong.  You're saying that "ATAG_CORE" is in LE32 format.  It
> > isn't.  It's in CPU endian format.  If you want to do this kind of thing,
> > you also need to define cpu_to_atag32() macros as well, otherwise this
> > will cause sparse warnings.
> > 
> > > -			initrd_start = atag->u.initrd.start;
> > > -			initrd_size = atag->u.initrd.size;
> > > +			initrd_start = atag32_to_cpu(atag->u.initrd.start);
> > > +			initrd_size = atag32_to_cpu(____atag->u.initrd.size);
> > 
> > Where did those four underscores come from?  Has this been built?
> 
> I probably missed building this one. I've been mostly testing with DT
> based systems.

Is this BE8 mode available on old systems?  Or, will those BE8 
capable old systems have BE userland compiled for them?

Where I want to get to is: do we need to support BE8 mode for ATAG based 
systems at all, given that most if not all the modern ones should be DT 
based now?  Making the ATAG code BE8 aware is looking to be quite 
invasive for potentially no users at all.


Nicolas

[PATCH 10/17] ARM: update atag-to-fdt code to be endian agnostic

[Ben Dooks]

On 12/02/13 21:53, Nicolas Pitre wrote:
> On Mon, 11 Feb 2013, Ben Dooks wrote:
>
>> On 09/02/13 12:05, Russell King - ARM Linux wrote:
>>> On Fri, Feb 08, 2013 at 11:17:40PM +0000, Ben Dooks wrote:
>>>> -	if (atag->hdr.tag != ATAG_CORE ||
>>>> -	    (atag->hdr.size != tag_size(tag_core)&&
>>>> -	     atag->hdr.size != 2))
>>>> +	if (atag->hdr.tag != atag32_to_cpu(ATAG_CORE) ||
>>>> +	    (atag->hdr.size != atag32_to_cpu(tag_size(tag_core))&&
>>>> +	     atag->hdr.size != atag32_to_cpu(2)))
>>>
>>> This is wrong.  You're saying that "ATAG_CORE" is in LE32 format.  It
>>> isn't.  It's in CPU endian format.  If you want to do this kind of thing,
>>> you also need to define cpu_to_atag32() macros as well, otherwise this
>>> will cause sparse warnings.
>>>
>>>> -			initrd_start = atag->u.initrd.start;
>>>> -			initrd_size = atag->u.initrd.size;
>>>> +			initrd_start = atag32_to_cpu(atag->u.initrd.start);
>>>> +			initrd_size = atag32_to_cpu(____atag->u.initrd.size);
>>>
>>> Where did those four underscores come from?  Has this been built?
>>
>> I probably missed building this one. I've been mostly testing with DT
>> based systems.
>
> Is this BE8 mode available on old systems?  Or, will those BE8
> capable old systems have BE userland compiled for them?

BE8 is for ARMv6 and ARMv7 form of big endian. ARMv5 is BE32.

> Where I want to get to is: do we need to support BE8 mode for ATAG based
> systems at all, given that most if not all the modern ones should be DT
> based now?  Making the ATAG code BE8 aware is looking to be quite
> invasive for potentially no users at all.

The change is only useful when using a BE8 compiled kernel with a
boot loader environment that is LE. Even if the ATAGs do not need
fixing up, then we have a issue with uboot checking the zImage magic.

I have pushed the ATAGs issues to a new series as it is not necessary
for the current work we are doing with highbank primarily.

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

[PATCH 10/17] ARM: update atag-to-fdt code to be endian agnostic

[Nicolas Pitre]

On Wed, 13 Feb 2013, Ben Dooks wrote:

> On 12/02/13 21:53, Nicolas Pitre wrote:
> > On Mon, 11 Feb 2013, Ben Dooks wrote:
> > 
> > > On 09/02/13 12:05, Russell King - ARM Linux wrote:
> > > > On Fri, Feb 08, 2013 at 11:17:40PM +0000, Ben Dooks wrote:
> > > > > -	if (atag->hdr.tag != ATAG_CORE ||
> > > > > -	    (atag->hdr.size != tag_size(tag_core)&&
> > > > > -	     atag->hdr.size != 2))
> > > > > +	if (atag->hdr.tag != atag32_to_cpu(ATAG_CORE) ||
> > > > > +	    (atag->hdr.size != atag32_to_cpu(tag_size(tag_core))&&
> > > > > +	     atag->hdr.size != atag32_to_cpu(2)))
> > > > 
> > > > This is wrong.  You're saying that "ATAG_CORE" is in LE32 format.  It
> > > > isn't.  It's in CPU endian format.  If you want to do this kind of
> > > > thing,
> > > > you also need to define cpu_to_atag32() macros as well, otherwise this
> > > > will cause sparse warnings.
> > > > 
> > > > > -			initrd_start = atag->u.initrd.start;
> > > > > -			initrd_size = atag->u.initrd.size;
> > > > > +			initrd_start =
> > > > > atag32_to_cpu(atag->u.initrd.start);
> > > > > +			initrd_size =
> > > > > atag32_to_cpu(____atag->u.initrd.size);
> > > > 
> > > > Where did those four underscores come from?  Has this been built?
> > > 
> > > I probably missed building this one. I've been mostly testing with DT
> > > based systems.
> > 
> > Is this BE8 mode available on old systems?  Or, will those BE8
> > capable old systems have BE userland compiled for them?
> 
> BE8 is for ARMv6 and ARMv7 form of big endian. ARMv5 is BE32.

I think that by now all ARMv6+ targets should be DT enabled.  So you 
shouldn't have to care about ATAGs at all.

> > Where I want to get to is: do we need to support BE8 mode for ATAG based
> > systems at all, given that most if not all the modern ones should be DT
> > based now?  Making the ATAG code BE8 aware is looking to be quite
> > invasive for potentially no users at all.
> 
> The change is only useful when using a BE8 compiled kernel with a
> boot loader environment that is LE.

That's what CONFIG_ARM_ATAG_DTB_COMPAT is for.  So only that code would 
need to swap the ATAG data.

> Even if the ATAGs do not need
> fixing up, then we have a issue with uboot checking the zImage magic.

I gave you a patch for that.

> I have pushed the ATAGs issues to a new series as it is not necessary
> for the current work we are doing with highbank primarily.

I don't think it is needed at all given that BE8 is available mainly on 
targets supporting DT, and is likely to be used on targets that do 
support only DT.


Nicolas

[PATCH 10/17] ARM: update atag-to-fdt code to be endian agnostic

[Ben Dooks]

On 14/02/13 04:43, Nicolas Pitre wrote:
> On Wed, 13 Feb 2013, Ben Dooks wrote:
>
>> On 12/02/13 21:53, Nicolas Pitre wrote:
>>> On Mon, 11 Feb 2013, Ben Dooks wrote:
>>>
>>>> On 09/02/13 12:05, Russell King - ARM Linux wrote:
>>>>> On Fri, Feb 08, 2013 at 11:17:40PM +0000, Ben Dooks wrote:
>>>>>> -	if (atag->hdr.tag != ATAG_CORE ||
>>>>>> -	    (atag->hdr.size != tag_size(tag_core)&&
>>>>>> -	     atag->hdr.size != 2))
>>>>>> +	if (atag->hdr.tag != atag32_to_cpu(ATAG_CORE) ||
>>>>>> +	    (atag->hdr.size != atag32_to_cpu(tag_size(tag_core))&&
>>>>>> +	     atag->hdr.size != atag32_to_cpu(2)))
>>>>>
>>>>> This is wrong.  You're saying that "ATAG_CORE" is in LE32 format.  It
>>>>> isn't.  It's in CPU endian format.  If you want to do this kind of
>>>>> thing,
>>>>> you also need to define cpu_to_atag32() macros as well, otherwise this
>>>>> will cause sparse warnings.
>>>>>
>>>>>> -			initrd_start = atag->u.initrd.start;
>>>>>> -			initrd_size = atag->u.initrd.size;
>>>>>> +			initrd_start =
>>>>>> atag32_to_cpu(atag->u.initrd.start);
>>>>>> +			initrd_size =
>>>>>> atag32_to_cpu(____atag->u.initrd.size);
>>>>>
>>>>> Where did those four underscores come from?  Has this been built?
>>>>
>>>> I probably missed building this one. I've been mostly testing with DT
>>>> based systems.
>>>
>>> Is this BE8 mode available on old systems?  Or, will those BE8
>>> capable old systems have BE userland compiled for them?
>>
>> BE8 is for ARMv6 and ARMv7 form of big endian. ARMv5 is BE32.
>
> I think that by now all ARMv6+ targets should be DT enabled.  So you
> shouldn't have to care about ATAGs at all.
>
>>> Where I want to get to is: do we need to support BE8 mode for ATAG based
>>> systems at all, given that most if not all the modern ones should be DT
>>> based now?  Making the ATAG code BE8 aware is looking to be quite
>>> invasive for potentially no users at all.
>>
>> The change is only useful when using a BE8 compiled kernel with a
>> boot loader environment that is LE.
>
> That's what CONFIG_ARM_ATAG_DTB_COMPAT is for.  So only that code would
> need to swap the ATAG data.
>
>> Even if the ATAGs do not need
>> fixing up, then we have a issue with uboot checking the zImage magic.
>
> I gave you a patch for that.
>
>> I have pushed the ATAGs issues to a new series as it is not necessary
>> for the current work we are doing with highbank primarily.
>
> I don't think it is needed at all given that BE8 is available mainly on
> targets supporting DT, and is likely to be used on targets that do
> support only DT.

Some devices we have still only have ATAG booting in u-boot, so it i
possible that it may have to stick around to allow the fdt to be updated
with any extra command line stuff...


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

[PATCH 11/17] ARM: fixup atags to be endian agnostic

[Ben Dooks]

Use the atag32_to_cpu() function to allow the main atag handling code
to be agnostic of any endian configuration.

Signed-of-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
 arch/arm/kernel/atags_parse.c |   51 +++++++++++++++++++++--------------------
 arch/arm/kernel/atags_proc.c  |    6 ++---
 2 files changed, 29 insertions(+), 28 deletions(-)

diff --git a/arch/arm/kernel/atags_parse.c b/arch/arm/kernel/atags_parse.c
index 14512e6..cffcbc2 100644
--- a/arch/arm/kernel/atags_parse.c
+++ b/arch/arm/kernel/atags_parse.c
@@ -43,19 +43,19 @@ static struct {
 	struct tag_mem32  mem;
 	struct tag_header hdr3;
 } default_tags __initdata = {
-	{ tag_size(tag_core), ATAG_CORE },
-	{ 1, PAGE_SIZE, 0xff },
-	{ tag_size(tag_mem32), ATAG_MEM },
-	{ MEM_SIZE },
-	{ 0, ATAG_NONE }
+	{ atag32_to_cpu(tag_size(tag_core)), atag32_to_cpu(ATAG_CORE) },
+	{ atag32_to_cpu(1), atag32_to_cpu(PAGE_SIZE), atag32_to_cpu(0xff) },
+	{ atag32_to_cpu(tag_size(tag_mem32)), atag32_to_cpu(ATAG_MEM) },
+	{ atag32_to_cpu(MEM_SIZE) },
+	{ atag32_to_cpu(0), atag32_to_cpu(ATAG_NONE) }
 };
 
 static int __init parse_tag_core(const struct tag *tag)
 {
-	if (tag->hdr.size > 2) {
-		if ((tag->u.core.flags & 1) == 0)
+	if (atag32_to_cpu(tag->hdr.size) > 2) {
+		if ((atag32_to_cpu(tag->u.core.flags) & 1) == 0)
 			root_mountflags &= ~MS_RDONLY;
-		ROOT_DEV = old_decode_dev(tag->u.core.rootdev);
+		ROOT_DEV = old_decode_dev(atag32_to_cpu(tag->u.core.rootdev));
 	}
 	return 0;
 }
@@ -64,7 +64,7 @@ __tagtable(ATAG_CORE, parse_tag_core);
 
 static int __init parse_tag_mem32(const struct tag *tag)
 {
-	return arm_add_memory(tag->u.mem.start, tag->u.mem.size);
+	return arm_add_memory(atag32_to_cpu(tag->u.mem.start), atag32_to_cpu(tag->u.mem.size));
 }
 
 __tagtable(ATAG_MEM, parse_tag_mem32);
@@ -91,13 +91,14 @@ __tagtable(ATAG_VIDEOTEXT, parse_tag_videotext);
 static int __init parse_tag_ramdisk(const struct tag *tag)
 {
 	extern int rd_size, rd_image_start, rd_prompt, rd_doload;
+	unsigned int flags = atag32_to_cpu(tag->u.ramdisk.flags);
 
-	rd_image_start = tag->u.ramdisk.start;
-	rd_doload = (tag->u.ramdisk.flags & 1) == 0;
-	rd_prompt = (tag->u.ramdisk.flags & 2) == 0;
+	rd_image_start = atag32_to_cpu(tag->u.ramdisk.start);
+	rd_doload = (flags & 1) == 0;
+	rd_prompt = (flags & 2) == 0;
 
-	if (tag->u.ramdisk.size)
-		rd_size = tag->u.ramdisk.size;
+	if (atag32_to_cpu(tag->u.ramdisk.size))
+		rd_size = atag32_to_cpu(tag->u.ramdisk.size);
 
 	return 0;
 }
@@ -107,8 +108,8 @@ __tagtable(ATAG_RAMDISK, parse_tag_ramdisk);
 
 static int __init parse_tag_serialnr(const struct tag *tag)
 {
-	system_serial_low = tag->u.serialnr.low;
-	system_serial_high = tag->u.serialnr.high;
+	system_serial_low = atag32_to_cpu(tag->u.serialnr.low);
+	system_serial_high = atag32_to_cpu(tag->u.serialnr.high);
 	return 0;
 }
 
@@ -116,7 +117,7 @@ __tagtable(ATAG_SERIAL, parse_tag_serialnr);
 
 static int __init parse_tag_revision(const struct tag *tag)
 {
-	system_rev = tag->u.revision.rev;
+	system_rev = atag32_to_cpu(tag->u.revision.rev);
 	return 0;
 }
 
@@ -150,7 +151,7 @@ static int __init parse_tag(const struct tag *tag)
 	struct tagtable *t;
 
 	for (t = &__tagtable_begin; t < &__tagtable_end; t++)
-		if (tag->hdr.tag == t->tag) {
+		if (atag32_to_cpu(tag->hdr.tag) == t->tag) {
 			t->parse(tag);
 			break;
 		}
@@ -164,17 +165,17 @@ static int __init parse_tag(const struct tag *tag)
  */
 static void __init parse_tags(const struct tag *t)
 {
-	for (; t->hdr.size; t = tag_next(t))
+	for_each_tag(t, t)
 		if (!parse_tag(t))
 			printk(KERN_WARNING
 				"Ignoring unrecognised tag 0x%08x\n",
-				t->hdr.tag);
+				atag32_to_cpu(t->hdr.tag));
 }
 
 static void __init squash_mem_tags(struct tag *tag)
 {
-	for (; tag->hdr.size; tag = tag_next(tag))
-		if (tag->hdr.tag == ATAG_MEM)
+	for_each_tag(tag, tag)
+		if (tag->hdr.tag == atag32_to_cpu(ATAG_MEM))
 			tag->hdr.tag = ATAG_NONE;
 }
 
@@ -213,10 +214,10 @@ struct machine_desc * __init setup_machine_tags(phys_addr_t __atags_pointer,
 	 * If we have the old style parameters, convert them to
 	 * a tag list.
 	 */
-	if (tags->hdr.tag != ATAG_CORE)
+	if (tags->hdr.tag != atag32_to_cpu(ATAG_CORE))
 		convert_to_tag_list(tags);
 #endif
-	if (tags->hdr.tag != ATAG_CORE) {
+	if (tags->hdr.tag != atag32_to_cpu(ATAG_CORE)) {
 		early_print("Warning: Neither atags nor dtb found\n");
 		tags = (struct tag *)&default_tags;
 	}
@@ -224,7 +225,7 @@ struct machine_desc * __init setup_machine_tags(phys_addr_t __atags_pointer,
 	if (mdesc->fixup)
 		mdesc->fixup(tags, &from, &meminfo);
 
-	if (tags->hdr.tag == ATAG_CORE) {
+	if (tags->hdr.tag == atag32_to_cpu(ATAG_CORE)) {
 		if (meminfo.nr_banks != 0)
 			squash_mem_tags(tags);
 		save_atags(tags);
diff --git a/arch/arm/kernel/atags_proc.c b/arch/arm/kernel/atags_proc.c
index 42a1a14..50e7e9c 100644
--- a/arch/arm/kernel/atags_proc.c
+++ b/arch/arm/kernel/atags_proc.c
@@ -46,18 +46,18 @@ static int __init init_atags_procfs(void)
 	struct buffer *b;
 	size_t size;
 
-	if (tag->hdr.tag != ATAG_CORE) {
+	if (tag->hdr.tag != atag32_to_cpu(ATAG_CORE)) {
 		printk(KERN_INFO "No ATAGs?");
 		return -EINVAL;
 	}
 
-	for (; tag->hdr.size; tag = tag_next(tag))
+	for_each_tag(tag, tag)
 		;
 
 	/* include the terminating ATAG_NONE */
 	size = (char *)tag - atags_copy + sizeof(struct tag_header);
 
-	WARN_ON(tag->hdr.tag != ATAG_NONE);
+	WARN_ON(tag->hdr.tag != atag32_to_cpu(ATAG_NONE));
 
 	b = kmalloc(sizeof(*b) + size, GFP_KERNEL);
 	if (!b)
-- 
1.7.10.4

[PATCH 11/17] ARM: fixup atags to be endian agnostic

[Nicolas Pitre]

On Fri, 8 Feb 2013, Ben Dooks wrote:

> Use the atag32_to_cpu() function to allow the main atag handling code
> to be agnostic of any endian configuration.
> 
> Signed-of-by: Ben Dooks <ben.dooks@codethink.co.uk>

This is looking rather error prone, especially since there is no sparse 
attribute to flag dereferences without the proper accessor.

Wouldn't it be simpler if you just determined the actual size of the 
ATAG block and byte swapped it all?





> ---
>  arch/arm/kernel/atags_parse.c |   51 +++++++++++++++++++++--------------------
>  arch/arm/kernel/atags_proc.c  |    6 ++---
>  2 files changed, 29 insertions(+), 28 deletions(-)
> 
> diff --git a/arch/arm/kernel/atags_parse.c b/arch/arm/kernel/atags_parse.c
> index 14512e6..cffcbc2 100644
> --- a/arch/arm/kernel/atags_parse.c
> +++ b/arch/arm/kernel/atags_parse.c
> @@ -43,19 +43,19 @@ static struct {
>  	struct tag_mem32  mem;
>  	struct tag_header hdr3;
>  } default_tags __initdata = {
> -	{ tag_size(tag_core), ATAG_CORE },
> -	{ 1, PAGE_SIZE, 0xff },
> -	{ tag_size(tag_mem32), ATAG_MEM },
> -	{ MEM_SIZE },
> -	{ 0, ATAG_NONE }
> +	{ atag32_to_cpu(tag_size(tag_core)), atag32_to_cpu(ATAG_CORE) },
> +	{ atag32_to_cpu(1), atag32_to_cpu(PAGE_SIZE), atag32_to_cpu(0xff) },
> +	{ atag32_to_cpu(tag_size(tag_mem32)), atag32_to_cpu(ATAG_MEM) },
> +	{ atag32_to_cpu(MEM_SIZE) },
> +	{ atag32_to_cpu(0), atag32_to_cpu(ATAG_NONE) }
>  };
>  
>  static int __init parse_tag_core(const struct tag *tag)
>  {
> -	if (tag->hdr.size > 2) {
> -		if ((tag->u.core.flags & 1) == 0)
> +	if (atag32_to_cpu(tag->hdr.size) > 2) {
> +		if ((atag32_to_cpu(tag->u.core.flags) & 1) == 0)
>  			root_mountflags &= ~MS_RDONLY;
> -		ROOT_DEV = old_decode_dev(tag->u.core.rootdev);
> +		ROOT_DEV = old_decode_dev(atag32_to_cpu(tag->u.core.rootdev));
>  	}
>  	return 0;
>  }
> @@ -64,7 +64,7 @@ __tagtable(ATAG_CORE, parse_tag_core);
>  
>  static int __init parse_tag_mem32(const struct tag *tag)
>  {
> -	return arm_add_memory(tag->u.mem.start, tag->u.mem.size);
> +	return arm_add_memory(atag32_to_cpu(tag->u.mem.start), atag32_to_cpu(tag->u.mem.size));
>  }
>  
>  __tagtable(ATAG_MEM, parse_tag_mem32);
> @@ -91,13 +91,14 @@ __tagtable(ATAG_VIDEOTEXT, parse_tag_videotext);
>  static int __init parse_tag_ramdisk(const struct tag *tag)
>  {
>  	extern int rd_size, rd_image_start, rd_prompt, rd_doload;
> +	unsigned int flags = atag32_to_cpu(tag->u.ramdisk.flags);
>  
> -	rd_image_start = tag->u.ramdisk.start;
> -	rd_doload = (tag->u.ramdisk.flags & 1) == 0;
> -	rd_prompt = (tag->u.ramdisk.flags & 2) == 0;
> +	rd_image_start = atag32_to_cpu(tag->u.ramdisk.start);
> +	rd_doload = (flags & 1) == 0;
> +	rd_prompt = (flags & 2) == 0;
>  
> -	if (tag->u.ramdisk.size)
> -		rd_size = tag->u.ramdisk.size;
> +	if (atag32_to_cpu(tag->u.ramdisk.size))
> +		rd_size = atag32_to_cpu(tag->u.ramdisk.size);
>  
>  	return 0;
>  }
> @@ -107,8 +108,8 @@ __tagtable(ATAG_RAMDISK, parse_tag_ramdisk);
>  
>  static int __init parse_tag_serialnr(const struct tag *tag)
>  {
> -	system_serial_low = tag->u.serialnr.low;
> -	system_serial_high = tag->u.serialnr.high;
> +	system_serial_low = atag32_to_cpu(tag->u.serialnr.low);
> +	system_serial_high = atag32_to_cpu(tag->u.serialnr.high);
>  	return 0;
>  }
>  
> @@ -116,7 +117,7 @@ __tagtable(ATAG_SERIAL, parse_tag_serialnr);
>  
>  static int __init parse_tag_revision(const struct tag *tag)
>  {
> -	system_rev = tag->u.revision.rev;
> +	system_rev = atag32_to_cpu(tag->u.revision.rev);
>  	return 0;
>  }
>  
> @@ -150,7 +151,7 @@ static int __init parse_tag(const struct tag *tag)
>  	struct tagtable *t;
>  
>  	for (t = &__tagtable_begin; t < &__tagtable_end; t++)
> -		if (tag->hdr.tag == t->tag) {
> +		if (atag32_to_cpu(tag->hdr.tag) == t->tag) {
>  			t->parse(tag);
>  			break;
>  		}
> @@ -164,17 +165,17 @@ static int __init parse_tag(const struct tag *tag)
>   */
>  static void __init parse_tags(const struct tag *t)
>  {
> -	for (; t->hdr.size; t = tag_next(t))
> +	for_each_tag(t, t)
>  		if (!parse_tag(t))
>  			printk(KERN_WARNING
>  				"Ignoring unrecognised tag 0x%08x\n",
> -				t->hdr.tag);
> +				atag32_to_cpu(t->hdr.tag));
>  }
>  
>  static void __init squash_mem_tags(struct tag *tag)
>  {
> -	for (; tag->hdr.size; tag = tag_next(tag))
> -		if (tag->hdr.tag == ATAG_MEM)
> +	for_each_tag(tag, tag)
> +		if (tag->hdr.tag == atag32_to_cpu(ATAG_MEM))
>  			tag->hdr.tag = ATAG_NONE;
>  }
>  
> @@ -213,10 +214,10 @@ struct machine_desc * __init setup_machine_tags(phys_addr_t __atags_pointer,
>  	 * If we have the old style parameters, convert them to
>  	 * a tag list.
>  	 */
> -	if (tags->hdr.tag != ATAG_CORE)
> +	if (tags->hdr.tag != atag32_to_cpu(ATAG_CORE))
>  		convert_to_tag_list(tags);
>  #endif
> -	if (tags->hdr.tag != ATAG_CORE) {
> +	if (tags->hdr.tag != atag32_to_cpu(ATAG_CORE)) {
>  		early_print("Warning: Neither atags nor dtb found\n");
>  		tags = (struct tag *)&default_tags;
>  	}
> @@ -224,7 +225,7 @@ struct machine_desc * __init setup_machine_tags(phys_addr_t __atags_pointer,
>  	if (mdesc->fixup)
>  		mdesc->fixup(tags, &from, &meminfo);
>  
> -	if (tags->hdr.tag == ATAG_CORE) {
> +	if (tags->hdr.tag == atag32_to_cpu(ATAG_CORE)) {
>  		if (meminfo.nr_banks != 0)
>  			squash_mem_tags(tags);
>  		save_atags(tags);
> diff --git a/arch/arm/kernel/atags_proc.c b/arch/arm/kernel/atags_proc.c
> index 42a1a14..50e7e9c 100644
> --- a/arch/arm/kernel/atags_proc.c
> +++ b/arch/arm/kernel/atags_proc.c
> @@ -46,18 +46,18 @@ static int __init init_atags_procfs(void)
>  	struct buffer *b;
>  	size_t size;
>  
> -	if (tag->hdr.tag != ATAG_CORE) {
> +	if (tag->hdr.tag != atag32_to_cpu(ATAG_CORE)) {
>  		printk(KERN_INFO "No ATAGs?");
>  		return -EINVAL;
>  	}
>  
> -	for (; tag->hdr.size; tag = tag_next(tag))
> +	for_each_tag(tag, tag)
>  		;
>  
>  	/* include the terminating ATAG_NONE */
>  	size = (char *)tag - atags_copy + sizeof(struct tag_header);
>  
> -	WARN_ON(tag->hdr.tag != ATAG_NONE);
> +	WARN_ON(tag->hdr.tag != atag32_to_cpu(ATAG_NONE));
>  
>  	b = kmalloc(sizeof(*b) + size, GFP_KERNEL);
>  	if (!b)
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

[PATCH 11/17] ARM: fixup atags to be endian agnostic

[Russell King - ARM Linux]

On Fri, Feb 08, 2013 at 11:17:41PM +0000, Ben Dooks wrote:
> +	{ atag32_to_cpu(tag_size(tag_core)), atag32_to_cpu(ATAG_CORE) },
> +	{ atag32_to_cpu(1), atag32_to_cpu(PAGE_SIZE), atag32_to_cpu(0xff) },
> +	{ atag32_to_cpu(tag_size(tag_mem32)), atag32_to_cpu(ATAG_MEM) },
> +	{ atag32_to_cpu(MEM_SIZE) },
> +	{ atag32_to_cpu(0), atag32_to_cpu(ATAG_NONE) }

Again, this needs to be cpu_to_atag32().

Pay attention to what you're converting from and to.  Consider them
totally separate types that just happen to be integers, and ensure
that you match the types in your functions.

[PATCH 12/17] ARM: fix magic for bootloader in BE8

[Ben Dooks]

If the boot-loader is running little endian and the kernel is compiled
big endian then it will not verify the magic number of the front of the
kernel.

Note, do we need to also reverse the two values after the magic, or are
they used later on in the kernel decompressor?

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

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 39940a7..b6c7ec8 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -129,7 +129,11 @@ start:
  THUMB(		adr	r12, BSYM(1f)	)
  THUMB(		bx	r12		)
 
+#ifdef CONFIG_CPU_BE8_BOOT_LE
+		.word	0x18286f01
+#else
 		.word	0x016f2818		@ Magic numbers to help the loader
+#endif
 		.word	start			@ absolute load/run zImage address
 		.word	_edata			@ zImage end address
  THUMB(		.thumb			)
-- 
1.7.10.4

[PATCH 12/17] ARM: fix magic for bootloader in BE8

[Nicolas Pitre]

On Fri, 8 Feb 2013, Ben Dooks wrote:

> If the boot-loader is running little endian and the kernel is compiled
> big endian then it will not verify the magic number of the front of the
> kernel.
> 
> Note, do we need to also reverse the two values after the magic, or are
> they used later on in the kernel decompressor?

Those value instances are not used by the code.  So for consistency they 
would have to be reversed, yes.  Given those are variable and determined 
by the linker, I don't know how you could manage it.

> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
> ---
>  arch/arm/boot/compressed/head.S |    4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index 39940a7..b6c7ec8 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -129,7 +129,11 @@ start:
>   THUMB(		adr	r12, BSYM(1f)	)
>   THUMB(		bx	r12		)
>  
> +#ifdef CONFIG_CPU_BE8_BOOT_LE
> +		.word	0x18286f01
> +#else
>  		.word	0x016f2818		@ Magic numbers to help the loader
> +#endif
>  		.word	start			@ absolute load/run zImage address
>  		.word	_edata			@ zImage end address
>   THUMB(		.thumb			)
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

[PATCH 12/17] ARM: fix magic for bootloader in BE8

[Russell King - ARM Linux]

On Fri, Feb 08, 2013 at 11:06:55PM -0500, Nicolas Pitre wrote:
> On Fri, 8 Feb 2013, Ben Dooks wrote:
> 
> > If the boot-loader is running little endian and the kernel is compiled
> > big endian then it will not verify the magic number of the front of the
> > kernel.
> > 
> > Note, do we need to also reverse the two values after the magic, or are
> > they used later on in the kernel decompressor?
> 
> Those value instances are not used by the code.  So for consistency they 
> would have to be reversed, yes.  Given those are variable and determined 
> by the linker, I don't know how you could manage it.

Which is why I wish we never had them, they've got in the way before
and they'll continue to do so.  I've seen boot loaders which do
precisely the wrong thing with these too, and had to fight them for
doing so.

[PATCH 12/17] ARM: fix magic for bootloader in BE8

[Jean-Christophe PLAGNIOL-VILLARD]

On 12:08 Sat 09 Feb     , Russell King - ARM Linux wrote:
> On Fri, Feb 08, 2013 at 11:06:55PM -0500, Nicolas Pitre wrote:
> > On Fri, 8 Feb 2013, Ben Dooks wrote:
> > 
> > > If the boot-loader is running little endian and the kernel is compiled
> > > big endian then it will not verify the magic number of the front of the
> > > kernel.
> > > 
> > > Note, do we need to also reverse the two values after the magic, or are
> > > they used later on in the kernel decompressor?
> > 
> > Those value instances are not used by the code.  So for consistency they 
> > would have to be reversed, yes.  Given those are variable and determined 
> > by the linker, I don't know how you could manage it.
> 
> Which is why I wish we never had them, they've got in the way before
> and they'll continue to do so.  I've seen boot loaders which do
> precisely the wrong thing with these too, and had to fight them for
> doing so.
in barebox we detect the type of file and detect we boot a zImage so be able
to detect we need to boot a be zImage is really appreciate

so we do not ask user how to boot but handle it automaticly

Best Regards,
J.

[PATCH 12/17] ARM: fix magic for bootloader in BE8

[Ben Dooks]

On 12/02/13 18:50, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 12:08 Sat 09 Feb     , Russell King - ARM Linux wrote:
>> On Fri, Feb 08, 2013 at 11:06:55PM -0500, Nicolas Pitre wrote:
>>> On Fri, 8 Feb 2013, Ben Dooks wrote:
>>>
>>>> If the boot-loader is running little endian and the kernel is compiled
>>>> big endian then it will not verify the magic number of the front of the
>>>> kernel.
>>>>
>>>> Note, do we need to also reverse the two values after the magic, or are
>>>> they used later on in the kernel decompressor?
>>>
>>> Those value instances are not used by the code.  So for consistency they
>>> would have to be reversed, yes.  Given those are variable and determined
>>> by the linker, I don't know how you could manage it.
>>
>> Which is why I wish we never had them, they've got in the way before
>> and they'll continue to do so.  I've seen boot loaders which do
>> precisely the wrong thing with these too, and had to fight them for
>> doing so.
> in barebox we detect the type of file and detect we boot a zImage so be able
> to detect we need to boot a be zImage is really appreciate
>
> so we do not ask user how to boot but handle it automaticly
>
> Best Regards,
> J.

IIRC, IXP is BE32, not BE8 so this shouldn't affect it.

I'm removing this from the base patch-set anyway and considering
making it conditional on the ATAGS endian-ness.

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

[PATCH 12/17] ARM: fix magic for bootloader in BE8

[Jean-Christophe PLAGNIOL-VILLARD]

On 18:54 Tue 12 Feb     , Ben Dooks wrote:
> On 12/02/13 18:50, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >On 12:08 Sat 09 Feb     , Russell King - ARM Linux wrote:
> >>On Fri, Feb 08, 2013 at 11:06:55PM -0500, Nicolas Pitre wrote:
> >>>On Fri, 8 Feb 2013, Ben Dooks wrote:
> >>>
> >>>>If the boot-loader is running little endian and the kernel is compiled
> >>>>big endian then it will not verify the magic number of the front of the
> >>>>kernel.
> >>>>
> >>>>Note, do we need to also reverse the two values after the magic, or are
> >>>>they used later on in the kernel decompressor?
> >>>
> >>>Those value instances are not used by the code.  So for consistency they
> >>>would have to be reversed, yes.  Given those are variable and determined
> >>>by the linker, I don't know how you could manage it.
> >>
> >>Which is why I wish we never had them, they've got in the way before
> >>and they'll continue to do so.  I've seen boot loaders which do
> >>precisely the wrong thing with these too, and had to fight them for
> >>doing so.
> >in barebox we detect the type of file and detect we boot a zImage so be able
> >to detect we need to boot a be zImage is really appreciate
> >
> >so we do not ask user how to boot but handle it automaticly
> >
> >Best Regards,
> >J.
> 
> IIRC, IXP is BE32, not BE8 so this shouldn't affect it.
yes IXP is BE32
> 
> I'm removing this from the base patch-set anyway and considering
> making it conditional on the ATAGS endian-ness.
we need to be able to detect it that's all

Best Regards,
J.
> 
> -- 
> Ben Dooks				http://www.codethink.co.uk/
> Senior Engineer				Codethink - Providing Genius

[PATCH 12/17] ARM: fix magic for bootloader in BE8

[Ben Dooks]

On 09/02/13 04:06, Nicolas Pitre wrote:
> On Fri, 8 Feb 2013, Ben Dooks wrote:
>
>> If the boot-loader is running little endian and the kernel is compiled
>> big endian then it will not verify the magic number of the front of the
>> kernel.
>>
>> Note, do we need to also reverse the two values after the magic, or are
>> they used later on in the kernel decompressor?
>
> Those value instances are not used by the code.  So for consistency they
> would have to be reversed, yes.  Given those are variable and determined
> by the linker, I don't know how you could manage it.

By breaking it down into parts I think...

I think this patch should be re-worked depending on the outcome of
re-doing the whole ATAG endian configuration so that these are in
the same endian-ness as we expect the ATAGs to be in.

>> Signed-off-by: Ben Dooks<ben.dooks@codethink.co.uk>
>> ---
>>   arch/arm/boot/compressed/head.S |    4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
>> index 39940a7..b6c7ec8 100644
>> --- a/arch/arm/boot/compressed/head.S
>> +++ b/arch/arm/boot/compressed/head.S
>> @@ -129,7 +129,11 @@ start:
>>    THUMB(		adr	r12, BSYM(1f)	)
>>    THUMB(		bx	r12		)
>>
>> +#ifdef CONFIG_CPU_BE8_BOOT_LE
>> +		.word	0x18286f01
>> +#else
>>   		.word	0x016f2818		@ Magic numbers to help the loader
>> +#endif
>>   		.word	start			@ absolute load/run zImage address
>>   		.word	_edata			@ zImage end address
>>    THUMB(		.thumb			)
>> --
>> 1.7.10.4
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


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

[PATCH 12/17] ARM: fix magic for bootloader in BE8

[Nicolas Pitre]

On Mon, 11 Feb 2013, Ben Dooks wrote:

> On 09/02/13 04:06, Nicolas Pitre wrote:
> > On Fri, 8 Feb 2013, Ben Dooks wrote:
> > 
> > > If the boot-loader is running little endian and the kernel is compiled
> > > big endian then it will not verify the magic number of the front of the
> > > kernel.
> > > 
> > > Note, do we need to also reverse the two values after the magic, or are
> > > they used later on in the kernel decompressor?
> > 
> > Those value instances are not used by the code.  So for consistency they
> > would have to be reversed, yes.  Given those are variable and determined
> > by the linker, I don't know how you could manage it.
> 
> By breaking it down into parts I think...
> 
> I think this patch should be re-worked depending on the outcome of
> re-doing the whole ATAG endian configuration so that these are in
> the same endian-ness as we expect the ATAGs to be in.

I don't think this is related to ATAGS at all.

Those values are making a header for bootloaders to use in identifying 
an ARM Linux zImage binary.  If you want to boot from a LE environment, 
the header must look like if this is a LE kernel.


Nicolas

[PATCH 13/17] 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 |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/include/asm/hardware/debug-pl01x.S b/arch/arm/include/asm/hardware/debug-pl01x.S
index f9fd083..6f3a003 100644
--- a/arch/arm/include/asm/hardware/debug-pl01x.S
+++ b/arch/arm/include/asm/hardware/debug-pl01x.S
@@ -12,18 +12,26 @@
 */
 #include <linux/amba/serial.h>
 
+#ifdef __ARMEB__
+#define ARM_BE(x...) x
+#else
+#define ARM_BE(x..)
+#endif
+
 		.macro	senduart,rd,rx
 		strb	\rd, [\rx, #UART01x_DR]
 		.endm
 
 		.macro	waituart,rd,rx
 1001:		ldr	\rd, [\rx, #UART01x_FR]
+  ARM_BE(	rev	\rd, \rd )
 		tst	\rd, #UART01x_FR_TXFF
 		bne	1001b
 		.endm
 
 		.macro	busyuart,rd,rx
 1001:		ldr	\rd, [\rx, #UART01x_FR]
+  ARM_BE(	rev	\rd, \rd )
 		tst	\rd, #UART01x_FR_BUSY
 		bne	1001b
 		.endm
-- 
1.7.10.4

[PATCH 13/17] ARM: pl01x debug code endian fix

[Russell King - ARM Linux]

On Fri, Feb 08, 2013 at 11:17:43PM +0000, Ben Dooks wrote:
> +#ifdef __ARMEB__
> +#define ARM_BE(x...) x
> +#else
> +#define ARM_BE(x..)

Buggy.

> +#endif

Rather than littering the code with stuff like this, define it in one
central place please, and include it where necessary.

[PATCH 13/17] ARM: pl01x debug code endian fix

[Ben Dooks]

On 09/02/13 12:09, Russell King - ARM Linux wrote:
> On Fri, Feb 08, 2013 at 11:17:43PM +0000, Ben Dooks wrote:
>> +#ifdef __ARMEB__
>> +#define ARM_BE(x...) x
>> +#else
>> +#define ARM_BE(x..)
>
> Buggy.
>
>> +#endif
>
> Rather than littering the code with stuff like this, define it in one
> central place please, and include it where necessary.

I'll add this to arch/arm/include/asm/assembler.h

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

[PATCH 14/17] 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 551c97e..9373571 100644
--- a/arch/arm/mach-highbank/Kconfig
+++ b/arch/arm/mach-highbank/Kconfig
@@ -13,3 +13,4 @@ config ARCH_HIGHBANK
 	select HAVE_SMP
 	select SPARSE_IRQ
 	select USE_OF
+	select ARCH_SUPPORTS_BIG_ENDIAN
-- 
1.7.10.4

[PATCH 14/17] highbank: enable big-endian

[Rob Herring]

On 02/08/2013 05:17 PM, Ben Dooks wrote:
> 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 551c97e..9373571 100644
> --- a/arch/arm/mach-highbank/Kconfig
> +++ b/arch/arm/mach-highbank/Kconfig
> @@ -13,3 +13,4 @@ config ARCH_HIGHBANK
>  	select HAVE_SMP
>  	select SPARSE_IRQ
>  	select USE_OF
> +	select ARCH_SUPPORTS_BIG_ENDIAN

Considering that there is nothing highbank specific to enable BE support
and all the support is within the A9 core (as BE support was never an
intended feature), I wonder if this is really the right place for this
option. All this really says is BE has been tested on this platform and
presumably it would work on other platforms ignoring raw vs. relaxed
accessors.

In any case:

Acked-by: Rob Herring <rob.herring@calxeda.com>

Rob

[PATCH 14/17] highbank: enable big-endian

[Ben Dooks]

On 09/02/2013 21:33, Rob Herring wrote:
> On 02/08/2013 05:17 PM, Ben Dooks wrote:
>> 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 551c97e..9373571 100644
>> --- a/arch/arm/mach-highbank/Kconfig
>> +++ b/arch/arm/mach-highbank/Kconfig
>> @@ -13,3 +13,4 @@ config ARCH_HIGHBANK
>>  	select HAVE_SMP
>>  	select SPARSE_IRQ
>>  	select USE_OF
>> +	select ARCH_SUPPORTS_BIG_ENDIAN
>
> Considering that there is nothing highbank specific to enable BE 
> support
> and all the support is within the A9 core (as BE support was never an
> intended feature), I wonder if this is really the right place for 
> this
> option. All this really says is BE has been tested on this platform 
> and
> presumably it would work on other platforms ignoring raw vs. relaxed
> accessors.

 From reading previous ARM documentation, I believe that the big endian
is not a requirement for ARMv7 and can be compiled out of the core if
the implementor does not want it. However, we've yet to find any of the
cores out there with it removed.

As such, we still have to test on Freescale and OMAP devices.

If anyone else objects to this, or feels it would be better moved
to the V7 cpu selection, or removed entirely then let me know.

> In any case:
>
> Acked-by: Rob Herring <rob.herring@calxeda.com>
>
> Rob

[PATCH 15/17] xgmac: fix printing of hardware version

[Ben Dooks]

The current driver attempts to print netdev_info() before registering the
network device and allowing the name to be set. Change this print to be
after the network deviec has been registered.

Fix the following issue:

calxedaxgmac fff50000.ethernet (unregistered net_device): h/w version is 0x1012

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
 drivers/net/ethernet/calxeda/xgmac.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/calxeda/xgmac.c b/drivers/net/ethernet/calxeda/xgmac.c
index f7f0290..f91d9b2 100644
--- a/drivers/net/ethernet/calxeda/xgmac.c
+++ b/drivers/net/ethernet/calxeda/xgmac.c
@@ -1715,9 +1715,6 @@ static int xgmac_probe(struct platform_device *pdev)
 		goto err_io;
 	}
 
-	uid = readl(priv->base + XGMAC_VERSION);
-	netdev_info(ndev, "h/w version is 0x%x\n", uid);
-
 	writel(0, priv->base + XGMAC_DMA_INTR_ENA);
 	ndev->irq = platform_get_irq(pdev, 0);
 	if (ndev->irq == -ENXIO) {
@@ -1771,6 +1768,9 @@ static int xgmac_probe(struct platform_device *pdev)
 	if (ret)
 		goto err_reg;
 
+	uid = readl(priv->base + XGMAC_VERSION);
+	netdev_info(ndev, "h/w version is 0x%x\n", uid);
+
 	return 0;
 
 err_reg:
-- 
1.7.10.4

[PATCH 15/17] xgmac: fix printing of hardware version

[Russell King - ARM Linux]

On Fri, Feb 08, 2013 at 11:17:45PM +0000, Ben Dooks wrote:
> The current driver attempts to print netdev_info() before registering the
> network device and allowing the name to be set. Change this print to be
> after the network deviec has been registered.

typo: device

[PATCH 15/17] xgmac: fix printing of hardware version

[Ben Dooks]

On 09/02/2013 12:10, Russell King - ARM Linux wrote:
> On Fri, Feb 08, 2013 at 11:17:45PM +0000, Ben Dooks wrote:
>> The current driver attempts to print netdev_info() before 
>> registering the
>> network device and allowing the name to be set. Change this print to 
>> be
>> after the network deviec has been registered.
>
> typo: device

Thanks. I'll send this patch to the netdev list, forgot to remove it 
from
here.

-- 
Ben

[PATCH 15/17] xgmac: fix printing of hardware version

[Rob Herring]

On 02/08/2013 05:17 PM, Ben Dooks wrote:
> The current driver attempts to print netdev_info() before registering the
> network device and allowing the name to be set. Change this print to be
> after the network deviec has been registered.
> 
> Fix the following issue:
> 
> calxedaxgmac fff50000.ethernet (unregistered net_device): h/w version is 0x1012
> 
> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
> ---

Please post to netdev list.

Acked-by: Rob Herring <rob.herring@calxeda.com>

>  drivers/net/ethernet/calxeda/xgmac.c |    6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/ethernet/calxeda/xgmac.c b/drivers/net/ethernet/calxeda/xgmac.c
> index f7f0290..f91d9b2 100644
> --- a/drivers/net/ethernet/calxeda/xgmac.c
> +++ b/drivers/net/ethernet/calxeda/xgmac.c
> @@ -1715,9 +1715,6 @@ static int xgmac_probe(struct platform_device *pdev)
>  		goto err_io;
>  	}
>  
> -	uid = readl(priv->base + XGMAC_VERSION);
> -	netdev_info(ndev, "h/w version is 0x%x\n", uid);
> -
>  	writel(0, priv->base + XGMAC_DMA_INTR_ENA);
>  	ndev->irq = platform_get_irq(pdev, 0);
>  	if (ndev->irq == -ENXIO) {
> @@ -1771,6 +1768,9 @@ static int xgmac_probe(struct platform_device *pdev)
>  	if (ret)
>  		goto err_reg;
>  
> +	uid = readl(priv->base + XGMAC_VERSION);
> +	netdev_info(ndev, "h/w version is 0x%x\n", uid);
> +
>  	return 0;
>  
>  err_reg:
> 

[PATCH 16/17] xgmac: replace __raw with relaxed IO

[Ben Dooks]

The xgmac driver is using __raw read and write functions, where it
should be using readl_relaxed and writel_relaxed to avoid any issues
with which endian mode the CPU is running in.

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
 drivers/net/ethernet/calxeda/xgmac.c |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/calxeda/xgmac.c b/drivers/net/ethernet/calxeda/xgmac.c
index f91d9b2..08a6f9e 100644
--- a/drivers/net/ethernet/calxeda/xgmac.c
+++ b/drivers/net/ethernet/calxeda/xgmac.c
@@ -1202,7 +1202,7 @@ static int xgmac_poll(struct napi_struct *napi, int budget)
 
 	if (work_done < budget) {
 		napi_complete(napi);
-		__raw_writel(DMA_INTR_DEFAULT_MASK, priv->base + XGMAC_DMA_INTR_ENA);
+		writel_relaxed(DMA_INTR_DEFAULT_MASK, priv->base + XGMAC_DMA_INTR_ENA);
 	}
 	return work_done;
 }
@@ -1347,7 +1347,7 @@ static irqreturn_t xgmac_pmt_interrupt(int irq, void *dev_id)
 	struct xgmac_priv *priv = netdev_priv(dev);
 	void __iomem *ioaddr = priv->base;
 
-	intr_status = __raw_readl(ioaddr + XGMAC_INT_STAT);
+	intr_status = readl_relaxed(ioaddr + XGMAC_INT_STAT);
 	if (intr_status & XGMAC_INT_STAT_PMT) {
 		netdev_dbg(priv->dev, "received Magic frame\n");
 		/* clear the PMT bits 5 and 6 by reading the PMT */
@@ -1365,9 +1365,9 @@ static irqreturn_t xgmac_interrupt(int irq, void *dev_id)
 	struct xgmac_extra_stats *x = &priv->xstats;
 
 	/* read the status register (CSR5) */
-	intr_status = __raw_readl(priv->base + XGMAC_DMA_STATUS);
-	intr_status &= __raw_readl(priv->base + XGMAC_DMA_INTR_ENA);
-	__raw_writel(intr_status, priv->base + XGMAC_DMA_STATUS);
+	intr_status = readl_relaxed(priv->base + XGMAC_DMA_STATUS);
+	intr_status &= readl_relaxed(priv->base + XGMAC_DMA_INTR_ENA);
+	writel_relaxed(intr_status, priv->base + XGMAC_DMA_STATUS);
 
 	/* It displays the DMA process states (CSR5 register) */
 	/* ABNORMAL interrupts */
@@ -1403,7 +1403,7 @@ static irqreturn_t xgmac_interrupt(int irq, void *dev_id)
 
 	/* TX/RX NORMAL interrupts */
 	if (intr_status & (DMA_STATUS_RI | DMA_STATUS_TU | DMA_STATUS_TI)) {
-		__raw_writel(DMA_INTR_ABNORMAL, priv->base + XGMAC_DMA_INTR_ENA);
+		writel_relaxed(DMA_INTR_ABNORMAL, priv->base + XGMAC_DMA_INTR_ENA);
 		napi_schedule(&priv->napi);
 	}
 
-- 
1.7.10.4

[PATCH 16/17] xgmac: replace __raw with relaxed IO

[Rob Herring]

On 02/08/2013 05:17 PM, Ben Dooks wrote:
> The xgmac driver is using __raw read and write functions, where it
> should be using readl_relaxed and writel_relaxed to avoid any issues
> with which endian mode the CPU is running in.
> 
> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
> ---
>  drivers/net/ethernet/calxeda/xgmac.c |   12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)

This will break on arches which don't have the _relaxed variants. David
Miller will reject restricting this to build on ARM only. See this:

http://www.spinics.net/lists/netdev/msg215457.html

Rob

> 
> diff --git a/drivers/net/ethernet/calxeda/xgmac.c b/drivers/net/ethernet/calxeda/xgmac.c
> index f91d9b2..08a6f9e 100644
> --- a/drivers/net/ethernet/calxeda/xgmac.c
> +++ b/drivers/net/ethernet/calxeda/xgmac.c
> @@ -1202,7 +1202,7 @@ static int xgmac_poll(struct napi_struct *napi, int budget)
>  
>  	if (work_done < budget) {
>  		napi_complete(napi);
> -		__raw_writel(DMA_INTR_DEFAULT_MASK, priv->base + XGMAC_DMA_INTR_ENA);
> +		writel_relaxed(DMA_INTR_DEFAULT_MASK, priv->base + XGMAC_DMA_INTR_ENA);
>  	}
>  	return work_done;
>  }
> @@ -1347,7 +1347,7 @@ static irqreturn_t xgmac_pmt_interrupt(int irq, void *dev_id)
>  	struct xgmac_priv *priv = netdev_priv(dev);
>  	void __iomem *ioaddr = priv->base;
>  
> -	intr_status = __raw_readl(ioaddr + XGMAC_INT_STAT);
> +	intr_status = readl_relaxed(ioaddr + XGMAC_INT_STAT);
>  	if (intr_status & XGMAC_INT_STAT_PMT) {
>  		netdev_dbg(priv->dev, "received Magic frame\n");
>  		/* clear the PMT bits 5 and 6 by reading the PMT */
> @@ -1365,9 +1365,9 @@ static irqreturn_t xgmac_interrupt(int irq, void *dev_id)
>  	struct xgmac_extra_stats *x = &priv->xstats;
>  
>  	/* read the status register (CSR5) */
> -	intr_status = __raw_readl(priv->base + XGMAC_DMA_STATUS);
> -	intr_status &= __raw_readl(priv->base + XGMAC_DMA_INTR_ENA);
> -	__raw_writel(intr_status, priv->base + XGMAC_DMA_STATUS);
> +	intr_status = readl_relaxed(priv->base + XGMAC_DMA_STATUS);
> +	intr_status &= readl_relaxed(priv->base + XGMAC_DMA_INTR_ENA);
> +	writel_relaxed(intr_status, priv->base + XGMAC_DMA_STATUS);
>  
>  	/* It displays the DMA process states (CSR5 register) */
>  	/* ABNORMAL interrupts */
> @@ -1403,7 +1403,7 @@ static irqreturn_t xgmac_interrupt(int irq, void *dev_id)
>  
>  	/* TX/RX NORMAL interrupts */
>  	if (intr_status & (DMA_STATUS_RI | DMA_STATUS_TU | DMA_STATUS_TI)) {
> -		__raw_writel(DMA_INTR_ABNORMAL, priv->base + XGMAC_DMA_INTR_ENA);
> +		writel_relaxed(DMA_INTR_ABNORMAL, priv->base + XGMAC_DMA_INTR_ENA);
>  		napi_schedule(&priv->napi);
>  	}
>  
> 

[PATCH 16/17] xgmac: replace __raw with relaxed IO

[Ben Dooks]

On 09/02/2013 20:59, Rob Herring wrote:
> On 02/08/2013 05:17 PM, Ben Dooks wrote:
>> The xgmac driver is using __raw read and write functions, where it
>> should be using readl_relaxed and writel_relaxed to avoid any issues
>> with which endian mode the CPU is running in.
>>
>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>> ---
>>  drivers/net/ethernet/calxeda/xgmac.c |   12 ++++++------
>>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> This will break on arches which don't have the _relaxed variants. 
> David
> Miller will reject restricting this to build on ARM only. See this:
>
> http://www.spinics.net/lists/netdev/msg215457.html

I was considering changing it anyway to keep the __raw functions
and simply swapping the endian-ness of the data when necessary
as we don't need about three rev instructions in there where one
will do.

Will sort out looking at this when I am back in the office on Monday.

-- 
Ben

[PATCH 17/17] 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/headsmp.S |    4 ++++
 2 files changed, 5 insertions(+)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 440b13e..2afa026 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/headsmp.S b/arch/arm/mach-mvebu/headsmp.S
index a06e0ed..8b09f8d 100644
--- a/arch/arm/mach-mvebu/headsmp.S
+++ b/arch/arm/mach-mvebu/headsmp.S
@@ -36,6 +36,10 @@
  */
 ENTRY(armada_xp_secondary_startup)
 
+#ifdef CONFIG_CPU_BE8_BOOT_LE
+	setend	be
+#endif
+
 	/* Read CPU id */
 	mrc     p15, 0, r1, c0, c0, 5
 	and     r1, r1, #0xF
-- 
1.7.10.4

ARM big-endian on current kernels for linux-3.8

[Thomas Petazzoni]

Dear Ben Dooks,

On Fri,  8 Feb 2013 23:17:30 +0000, Ben Dooks wrote:
> I have been working on getting big-endian kernels working, mainly from
> little-endian boot envrionments. The following patch series is what I
> have been working on, mainly on the highbank and axp systems.

Nice!

> Feedback and testing is welcome.

I've tested your patch set on Armada XP. The kernel boots fine, but it
fails to bring up the secondary CPUs:

Booting CPU 1
CPU1: failed to come online
Booting CPU 2
CPU2: failed to come online
Booting CPU 3
CPU3: failed to come online
Brought up 1 CPUs
SMP: Total of 1 processors activated (1332.01 BogoMIPS).

The other problem is that I've not been able to build a working armeb
userspace (I tried only very quickly with a Crosstool-NG toolchain I
built for armeb). Do you have a known working armeb toolchain around?

Thanks,

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

ARM big-endian on current kernels for linux-3.8

[Ben Dooks]

On 12/02/13 17:08, Thomas Petazzoni wrote:
> Dear Ben Dooks,
>
> On Fri,  8 Feb 2013 23:17:30 +0000, Ben Dooks wrote:
>> I have been working on getting big-endian kernels working, mainly from
>> little-endian boot envrionments. The following patch series is what I
>> have been working on, mainly on the highbank and axp systems.
>
> Nice!
>
>> Feedback and testing is welcome.
>
> I've tested your patch set on Armada XP. The kernel boots fine, but it
> fails to bring up the secondary CPUs:

Yes, missed updating the coherency_ll.S patch.

Attached new patch

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mvebu-be2.patch
Type: text/x-patch
Size: 1777 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130212/01874b7e/attachment.bin>

ARM big-endian on current kernels for linux-3.8

[Thomas Petazzoni]

Dear Ben Dooks,

On Tue, 12 Feb 2013 17:25:40 +0000, Ben Dooks wrote:

> >> Feedback and testing is welcome.
> >
> > I've tested your patch set on Armada XP. The kernel boots fine, but
> > it fails to bring up the secondary CPUs:
> 
> Yes, missed updating the coherency_ll.S patch.
> 
> Attached new patch

Thanks, I'll test this one tomorrow. Any pointer for a known-working
armeb toolchain?

Thanks,

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

ARM big-endian on current kernels for linux-3.8

[Ben Dooks]

On 12/02/13 18:49, Thomas Petazzoni wrote:
> Dear Ben Dooks,
>
> On Tue, 12 Feb 2013 17:25:40 +0000, Ben Dooks wrote:
>
>>>> Feedback and testing is welcome.
>>>
>>> I've tested your patch set on Armada XP. The kernel boots fine, but
>>> it fails to bring up the secondary CPUs:
>>
>> Yes, missed updating the coherency_ll.S patch.
>>
>> Attached new patch
>
> Thanks, I'll test this one tomorrow. Any pointer for a known-working
> armeb toolchain?

I've been building with gcc 4.6.3

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

ARM big-endian on current kernels for linux-3.8

[Thomas Petazzoni]

Dear Ben Dooks,

On Tue, 12 Feb 2013 17:25:40 +0000, Ben Dooks wrote:

> > I've tested your patch set on Armada XP. The kernel boots fine, but it
> > fails to bring up the secondary CPUs:
> 
> Yes, missed updating the coherency_ll.S patch.
> 
> Attached new patch

Thanks. Your patch did not build, because ARM_BE() isn't defined
anywhere in coherency_ll.S. I've fixed this by using an ifdef
CONFIG_CPU_BE8_BOOT_LE (updated patch attached), and now the secondary
CPUs boot fine.

That said, I still haven't fixed my userspace, so I could only verify
that the kernel boots, not more.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-mvebu-support-running-big-endian.patch
Type: text/x-patch
Size: 2201 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130213/995addba/attachment.bin>

ARM big-endian on current kernels for linux-3.8

[Russell King - ARM Linux]

On Fri, Feb 08, 2013 at 11:17:30PM +0000, Ben Dooks wrote:
> I have been working on getting big-endian kernels working, mainly from
> little-endian boot envrionments. The following patch series is what I
> have been working on, mainly on the highbank and axp systems.

What is missing from this is the justification about why we need this
additional pain, given that all the supporting userspaces today are all
LE based.

Sure, I know that telcos have an endless love of big endian and don't
understand anything else, but getting this working on non-telco socs
seems to be a little odd.

ARM big-endian on current kernels for linux-3.8

[Ben Dooks]

On 12/02/13 17:13, Russell King - ARM Linux wrote:
> On Fri, Feb 08, 2013 at 11:17:30PM +0000, Ben Dooks wrote:
>> I have been working on getting big-endian kernels working, mainly from
>> little-endian boot envrionments. The following patch series is what I
>> have been working on, mainly on the highbank and axp systems.
>
> What is missing from this is the justification about why we need this
> additional pain, given that all the supporting userspaces today are all
> LE based.
>
> Sure, I know that telcos have an endless love of big endian and don't
> understand anything else, but getting this working on non-telco socs
> seems to be a little odd.

Our problem is we have some code that works on a lot of big endian data
but is not easy to re-build to work on ARM little endian. The current 
solution is to change to running the system big endian.

Unfortunately we cannot just run user-space big endian as the MMU is
fetched in the same endian mode as the processor's data.

If we ignore the ATAG issue, then most of the support is currently in
the kernel to do this and there's not a lot of changes. I think
that some of the boot changes could be dealt with by a post-process
of the zImage (such as the zImage magic) which would make this
series less intrusive to the kernel.

I will send a new series in a day or so and see what people think.

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

ARM big-endian on current kernels for linux-3.8

[Nicolas Pitre]

On Tue, 12 Feb 2013, Ben Dooks wrote:

> If we ignore the ATAG issue, then most of the support is currently in
> the kernel to do this and there's not a lot of changes.

You could make CPU_BE8_BOOT_LE depend on !ATAG.

> I think that some of the boot changes could be dealt with by a 
> post-process of the zImage (such as the zImage magic) which would make 
> this series less intrusive to the kernel.

No, please don't do that.  Especially if the kernel binary _expects_ to 
be booted from a LE environment.  Otherwise we might end up with 
kernels that don't boot because there are environment expectation 
mismatch, etc.

Here's what could be done for the zImage header:

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 4d5f4192ee..2077ebb734 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -129,9 +129,9 @@ start:
  THUMB(		adr	r12, BSYM(1f)	)
  THUMB(		bx	r12		)
 
-		.word	0x016f2818		@ Magic numbers to help the loader
-		.word	start			@ absolute load/run zImage address
-		.word	_edata			@ zImage end address
+		.word	_magic_sig	@ Signature to help the loader (0x016f2818)
+		.word	_magic_start	@ zImage load/run address (0 if relocatable)
+		.word	_magic_end	@ zImage end address
  THUMB(		.thumb			)
 1:
 		mrs	r9, cpsr
diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index a517153a13..52539f46c1 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -200,8 +200,11 @@ CFLAGS_font.o := -Dstatic=
 $(obj)/font.c: $(FONTC)
 	$(call cmd,shipped)
 
-$(obj)/vmlinux.lds: $(obj)/vmlinux.lds.in arch/arm/boot/Makefile $(KCONFIG_CONFIG)
+$(obj)/vmlinux.lds.S: $(obj)/vmlinux.lds.in arch/arm/boot/Makefile $(KCONFIG_CONFIG)
 	@sed "$(SEDFLAGS)" < $< > $@
 
+$(obj)/vmlinux.lds: $(obj)/vmlinux.lds.S
+	$(call if_changed,cpp_lds_S)
+
 $(obj)/hyp-stub.S: $(srctree)/arch/$(SRCARCH)/kernel/hyp-stub.S
 	$(call cmd,shipped)
diff --git a/arch/arm/boot/compressed/vmlinux.lds.in b/arch/arm/boot/compressed/vmlinux.lds.in
index 4919f2ac8b..567250fb7d 100644
--- a/arch/arm/boot/compressed/vmlinux.lds.in
+++ b/arch/arm/boot/compressed/vmlinux.lds.in
@@ -7,6 +7,16 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
+
+#ifdef CONFIG_CPU_BE8_BOOT_LE
+#define ZIMAGE_MAGIC(x) ( (((x) >> 24) & 0x000000ff) | \
+			  (((x) >>  8) & 0x0000ff00) | \
+			  (((x) <<  8) & 0x00ff0000) | \
+			  (((x) << 24) & 0xff000000) )
+#else
+#define ZIMAGE_MAGIC(x) (x)
+#endif
+
 OUTPUT_ARCH(arm)
 ENTRY(_start)
 SECTIONS
@@ -57,6 +67,10 @@ SECTIONS
   .pad			: { BYTE(0); . = ALIGN(8); }
   _edata = .;
 
+  _magic_sig = ZIMAGE_MAGIC(0x016f2818);
+  _magic_start = ZIMAGE_MAGIC(_start);
+  _magic_end = ZIMAGE_MAGIC(_edata);
+
   . = BSS_START;
   __bss_start = .;
   .bss			: { *(.bss) }

ARM big-endian on current kernels for linux-3.8

[Ben Dooks]

On 12/02/13 22:13, Nicolas Pitre wrote:
> On Tue, 12 Feb 2013, Ben Dooks wrote:
>
>> If we ignore the ATAG issue, then most of the support is currently in
>> the kernel to do this and there's not a lot of changes.
>
> You could make CPU_BE8_BOOT_LE depend on !ATAG.

That would be one consideration. For my next series I've removed the
CPU_BE8_BOOT_LE and added the 'setend be' as conditional on running BE8
as this is such as small code addition it seems to make sense to do it
that way.

I will put together a new series that deals with the endian-ness of the
bootloader.

>> I think that some of the boot changes could be dealt with by a
>> post-process of the zImage (such as the zImage magic) which would make
>> this series less intrusive to the kernel.
>
> No, please don't do that.  Especially if the kernel binary _expects_ to
> be booted from a LE environment.  Otherwise we might end up with
> kernels that don't boot because there are environment expectation
> mismatch, etc.
>
> Here's what could be done for the zImage header:

I will keep this in mind, it looks like a pretty good solution to the
whole issue.

> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index 4d5f4192ee..2077ebb734 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -129,9 +129,9 @@ start:
>    THUMB(		adr	r12, BSYM(1f)	)
>    THUMB(		bx	r12		)
>
> -		.word	0x016f2818		@ Magic numbers to help the loader
> -		.word	start			@ absolute load/run zImage address
> -		.word	_edata			@ zImage end address
> +		.word	_magic_sig	@ Signature to help the loader (0x016f2818)
> +		.word	_magic_start	@ zImage load/run address (0 if relocatable)
> +		.word	_magic_end	@ zImage end address
>    THUMB(		.thumb			)
>   1:
>   		mrs	r9, cpsr
> diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
> index a517153a13..52539f46c1 100644
> --- a/arch/arm/boot/compressed/Makefile
> +++ b/arch/arm/boot/compressed/Makefile
> @@ -200,8 +200,11 @@ CFLAGS_font.o := -Dstatic=
>   $(obj)/font.c: $(FONTC)
>   	$(call cmd,shipped)
>
> -$(obj)/vmlinux.lds: $(obj)/vmlinux.lds.in arch/arm/boot/Makefile $(KCONFIG_CONFIG)
> +$(obj)/vmlinux.lds.S: $(obj)/vmlinux.lds.in arch/arm/boot/Makefile $(KCONFIG_CONFIG)
>   	@sed "$(SEDFLAGS)"<  $<  >  $@
>
> +$(obj)/vmlinux.lds: $(obj)/vmlinux.lds.S
> +	$(call if_changed,cpp_lds_S)
> +
>   $(obj)/hyp-stub.S: $(srctree)/arch/$(SRCARCH)/kernel/hyp-stub.S
>   	$(call cmd,shipped)
> diff --git a/arch/arm/boot/compressed/vmlinux.lds.in b/arch/arm/boot/compressed/vmlinux.lds.in
> index 4919f2ac8b..567250fb7d 100644
> --- a/arch/arm/boot/compressed/vmlinux.lds.in
> +++ b/arch/arm/boot/compressed/vmlinux.lds.in
> @@ -7,6 +7,16 @@
>    * it under the terms of the GNU General Public License version 2 as
>    * published by the Free Software Foundation.
>    */
> +
> +#ifdef CONFIG_CPU_BE8_BOOT_LE
> +#define ZIMAGE_MAGIC(x) ( (((x)>>  24)&  0x000000ff) | \
> +			  (((x)>>   8)&  0x0000ff00) | \
> +			  (((x)<<   8)&  0x00ff0000) | \
> +			  (((x)<<  24)&  0xff000000) )
> +#else
> +#define ZIMAGE_MAGIC(x) (x)
> +#endif
> +
>   OUTPUT_ARCH(arm)
>   ENTRY(_start)
>   SECTIONS
> @@ -57,6 +67,10 @@ SECTIONS
>     .pad			: { BYTE(0); . = ALIGN(8); }
>     _edata = .;
>
> +  _magic_sig = ZIMAGE_MAGIC(0x016f2818);
> +  _magic_start = ZIMAGE_MAGIC(_start);
> +  _magic_end = ZIMAGE_MAGIC(_edata);
> +
>     . = BSS_START;
>     __bss_start = .;
>     .bss			: { *(.bss) }


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

ARM big-endian on current kernels for linux-3.8

[Matthieu CASTET]

Ben Dooks a ?crit :
> On 12/02/13 17:13, Russell King - ARM Linux wrote:
>> On Fri, Feb 08, 2013 at 11:17:30PM +0000, Ben Dooks wrote:
>>> I have been working on getting big-endian kernels working, mainly from
>>> little-endian boot envrionments. The following patch series is what I
>>> have been working on, mainly on the highbank and axp systems.
>> What is missing from this is the justification about why we need this
>> additional pain, given that all the supporting userspaces today are all
>> LE based.
>>
>> Sure, I know that telcos have an endless love of big endian and don't
>> understand anything else, but getting this working on non-telco socs
>> seems to be a little odd.
> 
> Our problem is we have some code that works on a lot of big endian data
> but is not easy to re-build to work on ARM little endian. The current 
> solution is to change to running the system big endian.
> 
> Unfortunately we cannot just run user-space big endian as the MMU is
> fetched in the same endian mode as the processor's data.
> 
Which architecture are you using ?

On armv7 the mmu endian mode is selected by SCTLR.EE [1], but userspace can
change it's endian with setend instruction [2].

As the endian state is stored in cpsr, it should be preserved across context switch.


Matthieu



[1]
Exception Endianness. This bit defines the value of the CPSR.E bit on entry to
an exception vector,
including reset. The possible values of this bit are:
0           Little-endian.
1           Big-endian.
This bit value also defines the endianness of the translation table data for
translation table lookups.
In an implementation that includes the Security Extensions, this bit is Banked
between the Secure
and Non-secure copies of the register.

[2]
The ARM and Thumb instruction sets both include an instruction to manipulate
ENDIANSTATE:
SETEND BE   Sets ENDIANSTATE to 1, for big-endian operation.
SETEND LE   Sets ENDIANSTATE to 0, for little-endian operation.

ARM big-endian on current kernels for linux-3.8

[Ben Dooks]

On 13/02/13 10:24, Matthieu CASTET wrote:
> Ben Dooks a ?crit :
>> On 12/02/13 17:13, Russell King - ARM Linux wrote:
>>> On Fri, Feb 08, 2013 at 11:17:30PM +0000, Ben Dooks wrote:
>>>> I have been working on getting big-endian kernels working, mainly from
>>>> little-endian boot envrionments. The following patch series is what I
>>>> have been working on, mainly on the highbank and axp systems.
>>> What is missing from this is the justification about why we need this
>>> additional pain, given that all the supporting userspaces today are all
>>> LE based.
>>>
>>> Sure, I know that telcos have an endless love of big endian and don't
>>> understand anything else, but getting this working on non-telco socs
>>> seems to be a little odd.
>>
>> Our problem is we have some code that works on a lot of big endian data
>> but is not easy to re-build to work on ARM little endian. The current
>> solution is to change to running the system big endian.
>>
>> Unfortunately we cannot just run user-space big endian as the MMU is
>> fetched in the same endian mode as the processor's data.
>>
> Which architecture are you using ?
>
> On armv7 the mmu endian mode is selected by SCTLR.EE [1], but userspace can
> change it's endian with setend instruction [2].
>
> As the endian state is stored in cpsr, it should be preserved across context switch.

Ah yes, I got confused as there is also an endian mode for the page
tables that needs to match the endian mode that the kernel is doing
loads/stores in.

However if we had BE userland with LE kernel then things are going to
get difficult with a BE<>LE syscall issue.

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

ARM big-endian on current kernels for linux-3.8

[Catalin Marinas]

On Wed, Feb 13, 2013 at 11:18:35AM +0000, Ben Dooks wrote:
> On 13/02/13 10:24, Matthieu CASTET wrote:
> > Ben Dooks a ?crit :
> >> On 12/02/13 17:13, Russell King - ARM Linux wrote:
> >>> On Fri, Feb 08, 2013 at 11:17:30PM +0000, Ben Dooks wrote:
> >>>> I have been working on getting big-endian kernels working, mainly from
> >>>> little-endian boot envrionments. The following patch series is what I
> >>>> have been working on, mainly on the highbank and axp systems.
> >>> What is missing from this is the justification about why we need this
> >>> additional pain, given that all the supporting userspaces today are all
> >>> LE based.
> >>>
> >>> Sure, I know that telcos have an endless love of big endian and don't
> >>> understand anything else, but getting this working on non-telco socs
> >>> seems to be a little odd.
> >>
> >> Our problem is we have some code that works on a lot of big endian data
> >> but is not easy to re-build to work on ARM little endian. The current
> >> solution is to change to running the system big endian.
> >>
> >> Unfortunately we cannot just run user-space big endian as the MMU is
> >> fetched in the same endian mode as the processor's data.
> >>
> > Which architecture are you using ?
> >
> > On armv7 the mmu endian mode is selected by SCTLR.EE [1], but userspace can
> > change it's endian with setend instruction [2].
> >
> > As the endian state is stored in cpsr, it should be preserved across context switch.
> 
> Ah yes, I got confused as there is also an endian mode for the page
> tables that needs to match the endian mode that the kernel is doing
> loads/stores in.
> 
> However if we had BE userland with LE kernel then things are going to
> get difficult with a BE<>LE syscall issue.

I had an (insane) idea once but no time to pursue. You can enable the
'compat' layer for a 32-bit ARM kernel and define all the compat_* types
to be the same as the native ones. The compat layer has several handlers
for syscalls which pretty much do the conversion between compat and
native structures. The compat structures are read/written from/to user
using get_user/put_user on each member. You then need change the ARM
get_user/put_user code to test a new TIF_BE flag and do a 'rev' on the
data. At this point the native kernel structures would have the correct
little endianness.

I reckon the above would cover 70-80% of the syscalls. You need to chase
other syscalls and update the binfmt_elf.c to cope with BE ELF files.
Probably there are other issues as well.

-- 
Catalin

ARM big-endian on current kernels for linux-3.8

[Ben Dooks]

On 13/02/13 15:52, Catalin Marinas wrote:
> On Wed, Feb 13, 2013 at 11:18:35AM +0000, Ben Dooks wrote:
>> On 13/02/13 10:24, Matthieu CASTET wrote:
>>> Ben Dooks a ?crit :
>>>> On 12/02/13 17:13, Russell King - ARM Linux wrote:
>>>>> On Fri, Feb 08, 2013 at 11:17:30PM +0000, Ben Dooks wrote:
>>>>>> I have been working on getting big-endian kernels working, mainly from
>>>>>> little-endian boot envrionments. The following patch series is what I
>>>>>> have been working on, mainly on the highbank and axp systems.
>>>>> What is missing from this is the justification about why we need this
>>>>> additional pain, given that all the supporting userspaces today are all
>>>>> LE based.
>>>>>
>>>>> Sure, I know that telcos have an endless love of big endian and don't
>>>>> understand anything else, but getting this working on non-telco socs
>>>>> seems to be a little odd.
>>>>
>>>> Our problem is we have some code that works on a lot of big endian data
>>>> but is not easy to re-build to work on ARM little endian. The current
>>>> solution is to change to running the system big endian.
>>>>
>>>> Unfortunately we cannot just run user-space big endian as the MMU is
>>>> fetched in the same endian mode as the processor's data.
>>>>
>>> Which architecture are you using ?
>>>
>>> On armv7 the mmu endian mode is selected by SCTLR.EE [1], but userspace can
>>> change it's endian with setend instruction [2].
>>>
>>> As the endian state is stored in cpsr, it should be preserved across context switch.
>>
>> Ah yes, I got confused as there is also an endian mode for the page
>> tables that needs to match the endian mode that the kernel is doing
>> loads/stores in.
>>
>> However if we had BE userland with LE kernel then things are going to
>> get difficult with a BE<>LE syscall issue.
>
> I had an (insane) idea once but no time to pursue. You can enable the
> 'compat' layer for a 32-bit ARM kernel and define all the compat_* types
> to be the same as the native ones. The compat layer has several handlers
> for syscalls which pretty much do the conversion between compat and
> native structures. The compat structures are read/written from/to user
> using get_user/put_user on each member. You then need change the ARM
> get_user/put_user code to test a new TIF_BE flag and do a 'rev' on the
> data. At this point the native kernel structures would have the correct
> little endianness.
>
> I reckon the above would cover 70-80% of the syscalls. You need to chase
> other syscalls and update the binfmt_elf.c to cope with BE ELF files.
> Probably there are other issues as well.

Yes, it is far more work than just running the entire system BE, but
could be done. I however only have a budget of a beer, or maybe two
beers if pushing it.

I might have a go at this if I have some spare time

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

ARM big-endian on current kernels for linux-3.8

[Arnd Bergmann]

On Wednesday 13 February 2013 15:52:20 Catalin Marinas wrote:
> 
> I had an (insane) idea once but no time to pursue. You can enable the
> 'compat' layer for a 32-bit ARM kernel and define all the compat_* types
> to be the same as the native ones. The compat layer has several handlers
> for syscalls which pretty much do the conversion between compat and
> native structures. The compat structures are read/written from/to user
> using get_user/put_user on each member. You then need change the ARM
> get_user/put_user code to test a new TIF_BE flag and do a 'rev' on the
> data. At this point the native kernel structures would have the correct
> little endianness.
> 
> I reckon the above would cover 70-80% of the syscalls. You need to chase
> other syscalls and update the binfmt_elf.c to cope with BE ELF files.
> Probably there are other issues as well.

ioctl will be the biggest one by far. You would have to add compat
handlers for every device driver and a lot of other things like
network protocols.

Doable in theory, but also much more work than the 32 bit emulation
on 64 bit kernels, and that was something that took a lot of work
to get right.

However, qemu-user already has a mostly syscall emulation layer
including ioctl that covers most of the common stuff, certainly
enough to run most applications. The missing piece there is switching
to native other-endian execution instead of interpreting the
instructions. You might need to run the task in a separate process
though and use ptrace to trap all system calls.

The part you cannot solve this way is IPC: any data that is shared
between processes needs to match, and the only sane solution for that
is probably to run a separate container for all the big-endian
processes, and not let that talk to any of the little-endian tasks
using things like AF_UNIX sockets or shared mmap.

	Arnd