@@ -1,31 +0,0 @@-#ifndef _ASMARM_MSGBUF_H-#define _ASMARM_MSGBUF_H--/* - * The msqid64_ds structure for arm architecture.- * Note extra padding because this structure is passed back and forth- * between kernel and user space.- *- * Pad space is left for:- * - 64-bit time_t to solve y2038 problem- * - 2 miscellaneous 32-bit values- */--struct msqid64_ds {- struct ipc64_perm msg_perm;- __kernel_time_t msg_stime; /* last msgsnd time */- unsigned long __unused1;- __kernel_time_t msg_rtime; /* last msgrcv time */- unsigned long __unused2;- __kernel_time_t msg_ctime; /* last change time */- unsigned long __unused3;- unsigned long msg_cbytes; /* current number of bytes on queue */- unsigned long msg_qnum; /* number of messages in queue */- unsigned long msg_qbytes; /* max number of bytes on queue */- __kernel_pid_t msg_lspid; /* pid of last msgsnd */- __kernel_pid_t msg_lrpid; /* last receive pid */- unsigned long __unused4;- unsigned long __unused5;-};--#endif /* _ASMARM_MSGBUF_H */
@@ -1,31 +0,0 @@-/*- * arch/arm/include/asm/param.h- *- * Copyright (C) 1995-1999 Russell King- *- * This program is free software; you can redistribute it and/or modify- * it under the terms of the GNU General Public License version 2 as- * published by the Free Software Foundation.- */-#ifndef __ASM_PARAM_H-#define __ASM_PARAM_H--#ifdef __KERNEL__-# define HZ CONFIG_HZ /* Internal kernel timer frequency */-# define USER_HZ 100 /* User interfaces are in "ticks" */-# define CLOCKS_PER_SEC (USER_HZ) /* like times() */-#else-# define HZ 100-#endif--#define EXEC_PAGESIZE 4096--#ifndef NOGROUP-#define NOGROUP (-1)-#endif--/* max length of hostname */-#define MAXHOSTNAMELEN 64--#endif-
@@ -1,18 +0,0 @@-/*- * arch/arm/include/asm/parport.h: ARM-specific parport initialisation- *- * Copyright (C) 1999, 2000 Tim Waugh <tim@cyberelk.demon.co.uk>- *- * This file should only be included by drivers/parport/parport_pc.c.- */--#ifndef __ASMARM_PARPORT_H-#define __ASMARM_PARPORT_H--static int __devinit parport_pc_find_isa_ports (int autoirq, int autodma);-static int __devinit parport_pc_find_nonpci_ports (int autoirq, int autodma)-{- return parport_pc_find_isa_ports (autoirq, autodma);-}--#endif /* !(_ASMARM_PARPORT_H) */
@@ -1,25 +0,0 @@-#ifndef _ASMARM_SEMBUF_H-#define _ASMARM_SEMBUF_H--/* - * The semid64_ds structure for arm architecture.- * Note extra padding because this structure is passed back and forth- * between kernel and user space.- *- * Pad space is left for:- * - 64-bit time_t to solve y2038 problem- * - 2 miscellaneous 32-bit values- */--struct semid64_ds {- struct ipc64_perm sem_perm; /* permissions .. see ipc.h */- __kernel_time_t sem_otime; /* last semop time */- unsigned long __unused1;- __kernel_time_t sem_ctime; /* last change time */- unsigned long __unused2;- unsigned long sem_nsems; /* no. of semaphores in array */- unsigned long __unused3;- unsigned long __unused4;-};--#endif /* _ASMARM_SEMBUF_H */
@@ -1,19 +0,0 @@-/*- * arch/arm/include/asm/serial.h- *- * Copyright (C) 1996 Russell King.- *- * This program is free software; you can redistribute it and/or modify- * it under the terms of the GNU General Public License version 2 as- * published by the Free Software Foundation.- *- * Changelog:- * 15-10-1996 RMK Created- */--#ifndef __ASM_SERIAL_H-#define __ASM_SERIAL_H--#define BASE_BAUD (1843200 / 16)--#endif
@@ -1,42 +0,0 @@-#ifndef _ASMARM_SHMBUF_H-#define _ASMARM_SHMBUF_H--/* - * The shmid64_ds structure for arm architecture.- * Note extra padding because this structure is passed back and forth- * between kernel and user space.- *- * Pad space is left for:- * - 64-bit time_t to solve y2038 problem- * - 2 miscellaneous 32-bit values- */--struct shmid64_ds {- struct ipc64_perm shm_perm; /* operation perms */- size_t shm_segsz; /* size of segment (bytes) */- __kernel_time_t shm_atime; /* last attach time */- unsigned long __unused1;- __kernel_time_t shm_dtime; /* last detach time */- unsigned long __unused2;- __kernel_time_t shm_ctime; /* last change time */- unsigned long __unused3;- __kernel_pid_t shm_cpid; /* pid of creator */- __kernel_pid_t shm_lpid; /* pid of last operator */- unsigned long shm_nattch; /* no. of current attaches */- unsigned long __unused4;- unsigned long __unused5;-};--struct shminfo64 {- unsigned long shmmax;- unsigned long shmmin;- unsigned long shmmni;- unsigned long shmseg;- unsigned long shmall;- unsigned long __unused1;- unsigned long __unused2;- unsigned long __unused3;- unsigned long __unused4;-};--#endif /* _ASMARM_SHMBUF_H */
From: Rob Herring <hidden> Date: 2012-08-05 01:23:57
From: Rob Herring <redacted>
With the generic unaligned.h, more kernel headers get pulled in including
dynamic_debug.h which needs strstr. As it is not really used, we only need
a declaration here.
Signed-off-by: Rob Herring <redacted>
---
arch/arm/boot/compressed/decompress.c | 3 +++
1 file changed, 3 insertions(+)
@@ -32,6 +32,9 @@ extern void error(char *);# define Tracecv(c,x)#endif+/* Not needed, but used in some headers pulled in by decompressors */+externchar*strstr(constchar*s1,constchar*s2);+#ifdef CONFIG_KERNEL_GZIP#include"../../../../lib/decompress_inflate.c"#endif
From: Rob Herring <hidden> Date: 2012-08-05 01:23:59
From: Rob Herring <redacted>
As pointed out by Arnd Bergmann, this fixes a couple of issues but will
increase code size:
The original macro user_termio_to_kernel_termios was not endian safe. It
used an unsigned short ptr to access the low bits in a 32-bit word.
Both user_termio_to_kernel_termios and kernel_termios_to_user_termio are
missing error checking on put_user/get_user and copy_to/from_user.
Signed-off-by: Rob Herring <redacted>
Reviewed-by: Nicolas Pitre <redacted>
---
arch/arm/include/asm/Kbuild | 1 +
arch/arm/include/asm/termios.h | 92 ----------------------------------------
2 files changed, 1 insertion(+), 92 deletions(-)
delete mode 100644 arch/arm/include/asm/termios.h
From: Rob Herring <hidden> Date: 2012-08-05 01:24:00
From: Rob Herring <redacted>
By implmenting arch_local_irq_restore with constant flags, we can use
asm-generic/irqflags.h and remove some of the ARM version of irqflags.h.
Verified the code is equivalent by checking the disassembled code.
Signed-off-by: Rob Herring <redacted>
---
arch/arm/include/asm/irqflags.h | 131 ++++++++++++++-------------------------
1 file changed, 45 insertions(+), 86 deletions(-)
From: Thomas Petazzoni <hidden> Date: 2012-08-05 09:34:21
Le Sat, 4 Aug 2012 20:23:55 -0500,
Rob Herring [off-list ref] a ?crit :
From: Rob Herring <redacted>
Inspired by the AArgh64 claim that it should be separate from ARM and
one reason was being able to use more asm-generic headers. Doing a
diff of arch/arm/include/asm and include/asm-generic there are
numerous asm headers which are functionally identical to their
asm-generic counterparts and others which can use more of the generic
versions.
V2 separates unaligned.h and termios.h changes to separate patches.
Also, it adds a fix for build failures on non-gzip decompressor
compile.
Rob
Rob Herring (5):
ARM: use generic version of identical asm headers
ARM: add strstr declaration for decompressors
ARM: use generic unaligned.h
ARM: use generic termios.h
ARM: convert asm/irqflags.h to use asm-generic/irqflags.h
Built and boot tested on Armada XP evaluation platform.
Tested-by: Thomas Petazzoni <redacted>
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
From: Rob Herring <redacted>
Inspired by the AArgh64 claim that it should be separate from ARM and one
reason was being able to use more asm-generic headers. Doing a diff of
arch/arm/include/asm and include/asm-generic there are numerous asm
headers which are functionally identical to their asm-generic counterparts
and others which can use more of the generic versions.
V2 separates unaligned.h and termios.h changes to separate patches. Also,
it adds a fix for build failures on non-gzip decompressor compile.
This patch has been merged into mainline as commit below.
d25c881 ARM: 7493/1: use generic unaligned.h
It introduces a regression for me. Check out the commit on mainline,
build a v7 only kernel (imx5/6) with imx_v6_v7_defconfig, the kernel
halts in decompressor. But v6/v7 kernel (imx3/5/6) works fine. The
kernel built on the parent commit below works all fine.
ef1c209 ARM: 7492/1: add strstr declaration for decompressors
Shawn
On Sat, Aug 04, 2012 at 08:23:58PM -0500, Rob Herring wrote:
quoted hunk
From: Rob Herring <redacted>
This moves ARM over to the asm-generic/unaligned.h header. This has the
benefit of better code generated especially for ARMv7 on gcc 4.7+
compilers.
As Arnd Bergmann, points out: The asm-generic version uses the "struct"
version for native-endian unaligned access and the "byteshift" version
for the opposite endianess. The current ARM version however uses the
"byteshift" implementation for both.
Thanks to Nicolas Pitre for the excellent analysis:
Test case:
int foo (int *x) { return get_unaligned(x); }
long long bar (long long *x) { return get_unaligned(x); }
With the current ARM version:
foo:
ldrb r3, [r0, #2] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 2B], MEM[(const u8 *)x_1(D) + 2B]
ldrb r1, [r0, #1] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 1B], MEM[(const u8 *)x_1(D) + 1B]
ldrb r2, [r0, #0] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D)], MEM[(const u8 *)x_1(D)]
mov r3, r3, asl #16 @ tmp154, MEM[(const u8 *)x_1(D) + 2B],
ldrb r0, [r0, #3] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 3B], MEM[(const u8 *)x_1(D) + 3B]
orr r3, r3, r1, asl #8 @, tmp155, tmp154, MEM[(const u8 *)x_1(D) + 1B],
orr r3, r3, r2 @ tmp157, tmp155, MEM[(const u8 *)x_1(D)]
orr r0, r3, r0, asl #24 @,, tmp157, MEM[(const u8 *)x_1(D) + 3B],
bx lr @
bar:
stmfd sp!, {r4, r5, r6, r7} @,
mov r2, #0 @ tmp184,
ldrb r5, [r0, #6] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 6B], MEM[(const u8 *)x_1(D) + 6B]
ldrb r4, [r0, #5] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 5B], MEM[(const u8 *)x_1(D) + 5B]
ldrb ip, [r0, #2] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 2B], MEM[(const u8 *)x_1(D) + 2B]
ldrb r1, [r0, #4] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 4B], MEM[(const u8 *)x_1(D) + 4B]
mov r5, r5, asl #16 @ tmp175, MEM[(const u8 *)x_1(D) + 6B],
ldrb r7, [r0, #1] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 1B], MEM[(const u8 *)x_1(D) + 1B]
orr r5, r5, r4, asl #8 @, tmp176, tmp175, MEM[(const u8 *)x_1(D) + 5B],
ldrb r6, [r0, #7] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 7B], MEM[(const u8 *)x_1(D) + 7B]
orr r5, r5, r1 @ tmp178, tmp176, MEM[(const u8 *)x_1(D) + 4B]
ldrb r4, [r0, #0] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D)], MEM[(const u8 *)x_1(D)]
mov ip, ip, asl #16 @ tmp188, MEM[(const u8 *)x_1(D) + 2B],
ldrb r1, [r0, #3] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 3B], MEM[(const u8 *)x_1(D) + 3B]
orr ip, ip, r7, asl #8 @, tmp189, tmp188, MEM[(const u8 *)x_1(D) + 1B],
orr r3, r5, r6, asl #24 @,, tmp178, MEM[(const u8 *)x_1(D) + 7B],
orr ip, ip, r4 @ tmp191, tmp189, MEM[(const u8 *)x_1(D)]
orr ip, ip, r1, asl #24 @, tmp194, tmp191, MEM[(const u8 *)x_1(D) + 3B],
mov r1, r3 @,
orr r0, r2, ip @ tmp171, tmp184, tmp194
ldmfd sp!, {r4, r5, r6, r7}
bx lr
In both cases the code is slightly suboptimal. One may wonder why
wasting r2 with the constant 0 in the second case for example. And all
the mov's could be folded in subsequent orr's, etc.
Now with the asm-generic version:
foo:
ldr r0, [r0, #0] @ unaligned @,* x
bx lr @
bar:
mov r3, r0 @ x, x
ldr r0, [r0, #0] @ unaligned @,* x
ldr r1, [r3, #4] @ unaligned @,
bx lr @
This is way better of course, but only because this was compiled for
ARMv7. In this case the compiler knows that the hardware can do
unaligned word access. This isn't that obvious for foo(), but if we
remove the get_unaligned() from bar as follows:
long long bar (long long *x) {return *x; }
then the resulting code is:
bar:
ldmia r0, {r0, r1} @ x,,
bx lr @
So this proves that the presumed aligned vs unaligned cases does have
influence on the instructions the compiler may use and that the above
unaligned code results are not just an accident.
Still... this isn't fully conclusive without at least looking at the
resulting assembly fron a pre ARMv6 compilation. Let's see with an
ARMv5 target:
foo:
ldrb r3, [r0, #0] @ zero_extendqisi2 @ tmp139,* x
ldrb r1, [r0, #1] @ zero_extendqisi2 @ tmp140,
ldrb r2, [r0, #2] @ zero_extendqisi2 @ tmp143,
ldrb r0, [r0, #3] @ zero_extendqisi2 @ tmp146,
orr r3, r3, r1, asl #8 @, tmp142, tmp139, tmp140,
orr r3, r3, r2, asl #16 @, tmp145, tmp142, tmp143,
orr r0, r3, r0, asl #24 @,, tmp145, tmp146,
bx lr @
bar:
stmfd sp!, {r4, r5, r6, r7} @,
ldrb r2, [r0, #0] @ zero_extendqisi2 @ tmp139,* x
ldrb r7, [r0, #1] @ zero_extendqisi2 @ tmp140,
ldrb r3, [r0, #4] @ zero_extendqisi2 @ tmp149,
ldrb r6, [r0, #5] @ zero_extendqisi2 @ tmp150,
ldrb r5, [r0, #2] @ zero_extendqisi2 @ tmp143,
ldrb r4, [r0, #6] @ zero_extendqisi2 @ tmp153,
ldrb r1, [r0, #7] @ zero_extendqisi2 @ tmp156,
ldrb ip, [r0, #3] @ zero_extendqisi2 @ tmp146,
orr r2, r2, r7, asl #8 @, tmp142, tmp139, tmp140,
orr r3, r3, r6, asl #8 @, tmp152, tmp149, tmp150,
orr r2, r2, r5, asl #16 @, tmp145, tmp142, tmp143,
orr r3, r3, r4, asl #16 @, tmp155, tmp152, tmp153,
orr r0, r2, ip, asl #24 @,, tmp145, tmp146,
orr r1, r3, r1, asl #24 @,, tmp155, tmp156,
ldmfd sp!, {r4, r5, r6, r7}
bx lr
Compared to the initial results, this is really nicely optimized and I
couldn't do much better if I were to hand code it myself.
Signed-off-by: Rob Herring <redacted>
Reviewed-by: Nicolas Pitre <redacted>
---
arch/arm/include/asm/Kbuild | 1 +
arch/arm/include/asm/unaligned.h | 19 -------------------
2 files changed, 1 insertion(+), 19 deletions(-)
delete mode 100644 arch/arm/include/asm/unaligned.h
--
1.7.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Rob Herring <hidden> Date: 2012-10-08 20:34:57
On 10/08/2012 11:43 AM, Shawn Guo wrote:
This patch has been merged into mainline as commit below.
d25c881 ARM: 7493/1: use generic unaligned.h
It introduces a regression for me. Check out the commit on mainline,
build a v7 only kernel (imx5/6) with imx_v6_v7_defconfig, the kernel
halts in decompressor. But v6/v7 kernel (imx3/5/6) works fine. The
kernel built on the parent commit below works all fine.
It actually fails in the decompressor or that's the last output you get?
I compared the decompressor disassembly of both cases and get the same
number of ldrb/strb instructions, so I don't think it is directly
related to alignment.
I tried the XY decompressor as that is one difference, but that works
fine for me on highbank.
Does it work with an empty uncompress.h functions? That should be the
only difference in our decompressor code.
Rob
ef1c209 ARM: 7492/1: add strstr declaration for decompressors
Shawn
On Sat, Aug 04, 2012 at 08:23:58PM -0500, Rob Herring wrote:
quoted
From: Rob Herring <redacted>
This moves ARM over to the asm-generic/unaligned.h header. This has the
benefit of better code generated especially for ARMv7 on gcc 4.7+
compilers.
As Arnd Bergmann, points out: The asm-generic version uses the "struct"
version for native-endian unaligned access and the "byteshift" version
for the opposite endianess. The current ARM version however uses the
"byteshift" implementation for both.
Thanks to Nicolas Pitre for the excellent analysis:
Test case:
int foo (int *x) { return get_unaligned(x); }
long long bar (long long *x) { return get_unaligned(x); }
With the current ARM version:
foo:
ldrb r3, [r0, #2] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 2B], MEM[(const u8 *)x_1(D) + 2B]
ldrb r1, [r0, #1] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 1B], MEM[(const u8 *)x_1(D) + 1B]
ldrb r2, [r0, #0] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D)], MEM[(const u8 *)x_1(D)]
mov r3, r3, asl #16 @ tmp154, MEM[(const u8 *)x_1(D) + 2B],
ldrb r0, [r0, #3] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 3B], MEM[(const u8 *)x_1(D) + 3B]
orr r3, r3, r1, asl #8 @, tmp155, tmp154, MEM[(const u8 *)x_1(D) + 1B],
orr r3, r3, r2 @ tmp157, tmp155, MEM[(const u8 *)x_1(D)]
orr r0, r3, r0, asl #24 @,, tmp157, MEM[(const u8 *)x_1(D) + 3B],
bx lr @
bar:
stmfd sp!, {r4, r5, r6, r7} @,
mov r2, #0 @ tmp184,
ldrb r5, [r0, #6] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 6B], MEM[(const u8 *)x_1(D) + 6B]
ldrb r4, [r0, #5] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 5B], MEM[(const u8 *)x_1(D) + 5B]
ldrb ip, [r0, #2] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 2B], MEM[(const u8 *)x_1(D) + 2B]
ldrb r1, [r0, #4] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 4B], MEM[(const u8 *)x_1(D) + 4B]
mov r5, r5, asl #16 @ tmp175, MEM[(const u8 *)x_1(D) + 6B],
ldrb r7, [r0, #1] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 1B], MEM[(const u8 *)x_1(D) + 1B]
orr r5, r5, r4, asl #8 @, tmp176, tmp175, MEM[(const u8 *)x_1(D) + 5B],
ldrb r6, [r0, #7] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 7B], MEM[(const u8 *)x_1(D) + 7B]
orr r5, r5, r1 @ tmp178, tmp176, MEM[(const u8 *)x_1(D) + 4B]
ldrb r4, [r0, #0] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D)], MEM[(const u8 *)x_1(D)]
mov ip, ip, asl #16 @ tmp188, MEM[(const u8 *)x_1(D) + 2B],
ldrb r1, [r0, #3] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 3B], MEM[(const u8 *)x_1(D) + 3B]
orr ip, ip, r7, asl #8 @, tmp189, tmp188, MEM[(const u8 *)x_1(D) + 1B],
orr r3, r5, r6, asl #24 @,, tmp178, MEM[(const u8 *)x_1(D) + 7B],
orr ip, ip, r4 @ tmp191, tmp189, MEM[(const u8 *)x_1(D)]
orr ip, ip, r1, asl #24 @, tmp194, tmp191, MEM[(const u8 *)x_1(D) + 3B],
mov r1, r3 @,
orr r0, r2, ip @ tmp171, tmp184, tmp194
ldmfd sp!, {r4, r5, r6, r7}
bx lr
In both cases the code is slightly suboptimal. One may wonder why
wasting r2 with the constant 0 in the second case for example. And all
the mov's could be folded in subsequent orr's, etc.
Now with the asm-generic version:
foo:
ldr r0, [r0, #0] @ unaligned @,* x
bx lr @
bar:
mov r3, r0 @ x, x
ldr r0, [r0, #0] @ unaligned @,* x
ldr r1, [r3, #4] @ unaligned @,
bx lr @
This is way better of course, but only because this was compiled for
ARMv7. In this case the compiler knows that the hardware can do
unaligned word access. This isn't that obvious for foo(), but if we
remove the get_unaligned() from bar as follows:
long long bar (long long *x) {return *x; }
then the resulting code is:
bar:
ldmia r0, {r0, r1} @ x,,
bx lr @
So this proves that the presumed aligned vs unaligned cases does have
influence on the instructions the compiler may use and that the above
unaligned code results are not just an accident.
Still... this isn't fully conclusive without at least looking at the
resulting assembly fron a pre ARMv6 compilation. Let's see with an
ARMv5 target:
foo:
ldrb r3, [r0, #0] @ zero_extendqisi2 @ tmp139,* x
ldrb r1, [r0, #1] @ zero_extendqisi2 @ tmp140,
ldrb r2, [r0, #2] @ zero_extendqisi2 @ tmp143,
ldrb r0, [r0, #3] @ zero_extendqisi2 @ tmp146,
orr r3, r3, r1, asl #8 @, tmp142, tmp139, tmp140,
orr r3, r3, r2, asl #16 @, tmp145, tmp142, tmp143,
orr r0, r3, r0, asl #24 @,, tmp145, tmp146,
bx lr @
bar:
stmfd sp!, {r4, r5, r6, r7} @,
ldrb r2, [r0, #0] @ zero_extendqisi2 @ tmp139,* x
ldrb r7, [r0, #1] @ zero_extendqisi2 @ tmp140,
ldrb r3, [r0, #4] @ zero_extendqisi2 @ tmp149,
ldrb r6, [r0, #5] @ zero_extendqisi2 @ tmp150,
ldrb r5, [r0, #2] @ zero_extendqisi2 @ tmp143,
ldrb r4, [r0, #6] @ zero_extendqisi2 @ tmp153,
ldrb r1, [r0, #7] @ zero_extendqisi2 @ tmp156,
ldrb ip, [r0, #3] @ zero_extendqisi2 @ tmp146,
orr r2, r2, r7, asl #8 @, tmp142, tmp139, tmp140,
orr r3, r3, r6, asl #8 @, tmp152, tmp149, tmp150,
orr r2, r2, r5, asl #16 @, tmp145, tmp142, tmp143,
orr r3, r3, r4, asl #16 @, tmp155, tmp152, tmp153,
orr r0, r2, ip, asl #24 @,, tmp145, tmp146,
orr r1, r3, r1, asl #24 @,, tmp155, tmp156,
ldmfd sp!, {r4, r5, r6, r7}
bx lr
Compared to the initial results, this is really nicely optimized and I
couldn't do much better if I were to hand code it myself.
Signed-off-by: Rob Herring <redacted>
Reviewed-by: Nicolas Pitre <redacted>
---
arch/arm/include/asm/Kbuild | 1 +
arch/arm/include/asm/unaligned.h | 19 -------------------
2 files changed, 1 insertion(+), 19 deletions(-)
delete mode 100644 arch/arm/include/asm/unaligned.h
--
1.7.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Mon, Oct 08, 2012 at 03:34:57PM -0500, Rob Herring wrote:
On 10/08/2012 11:43 AM, Shawn Guo wrote:
quoted
This patch has been merged into mainline as commit below.
d25c881 ARM: 7493/1: use generic unaligned.h
It introduces a regression for me. Check out the commit on mainline,
build a v7 only kernel (imx5/6) with imx_v6_v7_defconfig, the kernel
halts in decompressor. But v6/v7 kernel (imx3/5/6) works fine. The
kernel built on the parent commit below works all fine.
It actually fails in the decompressor or that's the last output you get?
I think it fails in the decompressor, because what I see is
Uncompressing Linux...
not
Uncompressing Linux... done, booting the kernel.
I compared the decompressor disassembly of both cases and get the same
number of ldrb/strb instructions, so I don't think it is directly
related to alignment.
I tried the XY decompressor as that is one difference, but that works
fine for me on highbank.
Does it work with an empty uncompress.h functions? That should be the
only difference in our decompressor code.
No, empty putc() in uncompress.h does not help.
New finding is that it only fails with LZO decompressor while the other
3 Gzip, LZMA and XZ all work good. We happen to have LZO as the default
one in imx_v6_v7_defconfig.
Shawn
From: Rob Herring <hidden> Date: 2012-10-09 02:27:31
On 10/08/2012 06:28 PM, Shawn Guo wrote:
On Mon, Oct 08, 2012 at 03:34:57PM -0500, Rob Herring wrote:
quoted
On 10/08/2012 11:43 AM, Shawn Guo wrote:
quoted
This patch has been merged into mainline as commit below.
d25c881 ARM: 7493/1: use generic unaligned.h
It introduces a regression for me. Check out the commit on mainline,
build a v7 only kernel (imx5/6) with imx_v6_v7_defconfig, the kernel
halts in decompressor. But v6/v7 kernel (imx3/5/6) works fine. The
kernel built on the parent commit below works all fine.
It actually fails in the decompressor or that's the last output you get?
I think it fails in the decompressor, because what I see is
Uncompressing Linux...
not
Uncompressing Linux... done, booting the kernel.
quoted
I compared the decompressor disassembly of both cases and get the same
number of ldrb/strb instructions, so I don't think it is directly
related to alignment.
I tried the XY decompressor as that is one difference, but that works
fine for me on highbank.
Does it work with an empty uncompress.h functions? That should be the
only difference in our decompressor code.
No, empty putc() in uncompress.h does not help.
New finding is that it only fails with LZO decompressor while the other
3 Gzip, LZMA and XZ all work good. We happen to have LZO as the default
one in imx_v6_v7_defconfig.
I must have had an old config with XZ. LZO fails because of this:
lib/decompress_unlzo.c: version = get_unaligned_be16(parse);
lib/decompress_unlzo.c: if (get_unaligned_be32(parse) & HEADER_HAS_FILTER)
lib/decompress_unlzo.c: dst_len = get_unaligned_be32(in_buf);
lib/decompress_unlzo.c: src_len = get_unaligned_be32(in_buf);
This was what I was afraid of. The decompressor runs with the sysctrl
register A bit in whatever state the bootloader left it in. In the case
of u-boot it is set, and the maintainers are pretty set on not allowing
unaligned accesses if you've seen the recent discussion.
This should fix things.
Rob
8<---------------------------------------------------------------------
On Mon, Oct 08, 2012 at 09:27:31PM -0500, Rob Herring wrote:
quoted hunk
I must have had an old config with XZ. LZO fails because of this:
lib/decompress_unlzo.c: version = get_unaligned_be16(parse);
lib/decompress_unlzo.c: if (get_unaligned_be32(parse) & HEADER_HAS_FILTER)
lib/decompress_unlzo.c: dst_len = get_unaligned_be32(in_buf);
lib/decompress_unlzo.c: src_len = get_unaligned_be32(in_buf);
This was what I was afraid of. The decompressor runs with the sysctrl
register A bit in whatever state the bootloader left it in. In the case
of u-boot it is set, and the maintainers are pretty set on not allowing
unaligned accesses if you've seen the recent discussion.
This should fix things.
Rob
8<---------------------------------------------------------------------
From: Nicolas Pitre <hidden> Date: 2012-10-09 04:01:05
On Mon, 8 Oct 2012, Rob Herring wrote:
On 10/08/2012 06:28 PM, Shawn Guo wrote:
quoted
On Mon, Oct 08, 2012 at 03:34:57PM -0500, Rob Herring wrote:
quoted
On 10/08/2012 11:43 AM, Shawn Guo wrote:
quoted
This patch has been merged into mainline as commit below.
d25c881 ARM: 7493/1: use generic unaligned.h
It introduces a regression for me. Check out the commit on mainline,
build a v7 only kernel (imx5/6) with imx_v6_v7_defconfig, the kernel
halts in decompressor. But v6/v7 kernel (imx3/5/6) works fine. The
kernel built on the parent commit below works all fine.
It actually fails in the decompressor or that's the last output you get?
I think it fails in the decompressor, because what I see is
Uncompressing Linux...
not
Uncompressing Linux... done, booting the kernel.
quoted
I compared the decompressor disassembly of both cases and get the same
number of ldrb/strb instructions, so I don't think it is directly
related to alignment.
I tried the XY decompressor as that is one difference, but that works
fine for me on highbank.
Does it work with an empty uncompress.h functions? That should be the
only difference in our decompressor code.
No, empty putc() in uncompress.h does not help.
New finding is that it only fails with LZO decompressor while the other
3 Gzip, LZMA and XZ all work good. We happen to have LZO as the default
one in imx_v6_v7_defconfig.
I must have had an old config with XZ. LZO fails because of this:
lib/decompress_unlzo.c: version = get_unaligned_be16(parse);
lib/decompress_unlzo.c: if (get_unaligned_be32(parse) & HEADER_HAS_FILTER)
lib/decompress_unlzo.c: dst_len = get_unaligned_be32(in_buf);
lib/decompress_unlzo.c: src_len = get_unaligned_be32(in_buf);
This was what I was afraid of. The decompressor runs with the sysctrl
register A bit in whatever state the bootloader left it in. In the case
of u-boot it is set, and the maintainers are pretty set on not allowing
unaligned accesses if you've seen the recent discussion.
This is not an u-Boot issue. The kernel code expects misaligned
accesses to be handled by the hardware on ARMv6+ now. So it better
enforce proper A bit state itself.
quoted hunk
This should fix things.
Rob
8<---------------------------------------------------------------------
From: Rob Herring <hidden> Date: 2012-10-10 13:29:27
On 10/08/2012 11:01 PM, Nicolas Pitre wrote:
On Mon, 8 Oct 2012, Rob Herring wrote:
quoted
On 10/08/2012 06:28 PM, Shawn Guo wrote:
quoted
On Mon, Oct 08, 2012 at 03:34:57PM -0500, Rob Herring wrote:
quoted
On 10/08/2012 11:43 AM, Shawn Guo wrote:
quoted
This patch has been merged into mainline as commit below.
d25c881 ARM: 7493/1: use generic unaligned.h
It introduces a regression for me. Check out the commit on mainline,
build a v7 only kernel (imx5/6) with imx_v6_v7_defconfig, the kernel
halts in decompressor. But v6/v7 kernel (imx3/5/6) works fine. The
kernel built on the parent commit below works all fine.
It actually fails in the decompressor or that's the last output you get?
I think it fails in the decompressor, because what I see is
Uncompressing Linux...
not
Uncompressing Linux... done, booting the kernel.
quoted
I compared the decompressor disassembly of both cases and get the same
number of ldrb/strb instructions, so I don't think it is directly
related to alignment.
I tried the XY decompressor as that is one difference, but that works
fine for me on highbank.
Does it work with an empty uncompress.h functions? That should be the
only difference in our decompressor code.
No, empty putc() in uncompress.h does not help.
New finding is that it only fails with LZO decompressor while the other
3 Gzip, LZMA and XZ all work good. We happen to have LZO as the default
one in imx_v6_v7_defconfig.
I must have had an old config with XZ. LZO fails because of this:
lib/decompress_unlzo.c: version = get_unaligned_be16(parse);
lib/decompress_unlzo.c: if (get_unaligned_be32(parse) & HEADER_HAS_FILTER)
lib/decompress_unlzo.c: dst_len = get_unaligned_be32(in_buf);
lib/decompress_unlzo.c: src_len = get_unaligned_be32(in_buf);
This was what I was afraid of. The decompressor runs with the sysctrl
register A bit in whatever state the bootloader left it in. In the case
of u-boot it is set, and the maintainers are pretty set on not allowing
unaligned accesses if you've seen the recent discussion.
This is not an u-Boot issue. The kernel code expects misaligned
accesses to be handled by the hardware on ARMv6+ now. So it better
enforce proper A bit state itself.
quoted
This should fix things.
Rob
8<---------------------------------------------------------------------
That's OK for ARMv7, but in the ARMv6 case we use __armv4_mmu_cache_on.
So this patch is incomplete.
It is still optional on v6 and the compiler will not emit unaligned
accesses for v6 (which is why it worked when v6 platforms were enabled).
That does raise a bigger question. If we're doing combined v6 and v7
builds, do we want this to require unaligned accesses are enabled and if
so, can we force that on in the compiler?
Rob
From: Nicolas Pitre <hidden> Date: 2012-10-10 13:57:57
On Wed, 10 Oct 2012, Rob Herring wrote:
On 10/08/2012 11:01 PM, Nicolas Pitre wrote:
quoted
On Mon, 8 Oct 2012, Rob Herring wrote:
quoted
On 10/08/2012 06:28 PM, Shawn Guo wrote:
quoted
On Mon, Oct 08, 2012 at 03:34:57PM -0500, Rob Herring wrote:
quoted
On 10/08/2012 11:43 AM, Shawn Guo wrote:
quoted
This patch has been merged into mainline as commit below.
d25c881 ARM: 7493/1: use generic unaligned.h
It introduces a regression for me. Check out the commit on mainline,
build a v7 only kernel (imx5/6) with imx_v6_v7_defconfig, the kernel
halts in decompressor. But v6/v7 kernel (imx3/5/6) works fine. The
kernel built on the parent commit below works all fine.
It actually fails in the decompressor or that's the last output you get?
I think it fails in the decompressor, because what I see is
Uncompressing Linux...
not
Uncompressing Linux... done, booting the kernel.
quoted
I compared the decompressor disassembly of both cases and get the same
number of ldrb/strb instructions, so I don't think it is directly
related to alignment.
I tried the XY decompressor as that is one difference, but that works
fine for me on highbank.
Does it work with an empty uncompress.h functions? That should be the
only difference in our decompressor code.
No, empty putc() in uncompress.h does not help.
New finding is that it only fails with LZO decompressor while the other
3 Gzip, LZMA and XZ all work good. We happen to have LZO as the default
one in imx_v6_v7_defconfig.
I must have had an old config with XZ. LZO fails because of this:
lib/decompress_unlzo.c: version = get_unaligned_be16(parse);
lib/decompress_unlzo.c: if (get_unaligned_be32(parse) & HEADER_HAS_FILTER)
lib/decompress_unlzo.c: dst_len = get_unaligned_be32(in_buf);
lib/decompress_unlzo.c: src_len = get_unaligned_be32(in_buf);
This was what I was afraid of. The decompressor runs with the sysctrl
register A bit in whatever state the bootloader left it in. In the case
of u-boot it is set, and the maintainers are pretty set on not allowing
unaligned accesses if you've seen the recent discussion.
This is not an u-Boot issue. The kernel code expects misaligned
accesses to be handled by the hardware on ARMv6+ now. So it better
enforce proper A bit state itself.
quoted
This should fix things.
Rob
8<---------------------------------------------------------------------
That's OK for ARMv7, but in the ARMv6 case we use __armv4_mmu_cache_on.
So this patch is incomplete.
It is still optional on v6 and the compiler will not emit unaligned
accesses for v6 (which is why it worked when v6 platforms were enabled).
Hmmm, right. However if you look at commit 8428e84d42, the A bit is
cleared whenever we compile for ARMv6 or higher. Of course, the
decompressor doesn't have to deal with unknown user space binaries and
in that case we might trust that the compiler will never emit known to
be unaligned loads.
In that case...
Acked-by: Nicolas Pitre <redacted>
That does raise a bigger question. If we're doing combined v6 and v7
builds, do we want this to require unaligned accesses are enabled and if
so, can we force that on in the compiler?
When we compile ARMv6 and ARMv7 targets together, the compiler is told
to compile for ARMv6. We know that unaligned accesses will be done
usingLDRB/STRB in that case.
Nicolas
From: Rob Herring <hidden> Date: 2012-10-11 12:43:22
From: Rob Herring <redacted>
With recent compilers and move to generic unaligned.h in commit d25c881
(ARM: 7493/1: use generic unaligned.h), unaligned accesses will be used
by the LZO decompressor on v7 cores. So we need to make sure unaligned
accesses are allowed by clearing the SCTLR A bit.
While v6 can support unaligned accesses, it is optional and current
compilers won't emit unaligned accesses. So we don't clear the A bit for
v6.
Signed-off-by: Rob Herring <redacted>
Acked-by: Nicolas Pitre <redacted>
Tested-by: Shawn Guo <redacted>
---
The contents of this were already reviewed on this thread, so I sent this
to the patch system and this was Russell's reply:
NAK for two reasons.
1. It hasn't been on the list (I can't find a match for "clear SCTLR.A"
in my mailbox)
2. The behaviour of unaligned accesses vary depending on CPU. Some
fix-up the access, others load the word and then rotate it. If we have
decompressors which perform unaligned accesses, we need to fix this
properly to avoid the CPU specific behaviour, rather than tweaking
control bits to hide the problem.
I'm simply matching the behavior of the kernel itself. The A bit is cleared
for v7 kernels and compilers only generate unaligned accesses for v7.
Without this the initial state of the A bit is undefined as a bootloader
could have cleared it already. We should document the required state or set
it to what we want.
Rob
arch/arm/boot/compressed/head.S | 1 +
1 file changed, 1 insertion(+)
From: Russell King - ARM Linux <hidden> Date: 2012-10-11 13:09:56
On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
The contents of this were already reviewed on this thread, so I sent this
to the patch system and this was Russell's reply:
So that's why I couldn't find it - the mailing list thread has a different
subject line to the patch. Don't do that. Given the amount of list
traffic we have today, that's as good as not having been posted at all.
quoted
NAK for two reasons.
1. It hasn't been on the list (I can't find a match for "clear SCTLR.A"
in my mailbox)
2. The behaviour of unaligned accesses vary depending on CPU. Some
fix-up the access, others load the word and then rotate it. If we have
decompressors which perform unaligned accesses, we need to fix this
properly to avoid the CPU specific behaviour, rather than tweaking
control bits to hide the problem.
I'm simply matching the behavior of the kernel itself. The A bit is cleared
for v7 kernels and compilers only generate unaligned accesses for v7.
Without this the initial state of the A bit is undefined as a bootloader
could have cleared it already. We should document the required state or set
it to what we want.
Irrespective of this, (2) still stands. Unaligned accesses in the
decompressor without a fixup (which will be very hard to provide)
will return different data depending on the CPU as I mention in point
2.
So, using unaligned accesses in the decompressor may not give expected
results in all cases, so they're best avoided.
And if they're avoided, then we don't care about the setting of the A
bit.
From: Rob Herring <hidden> Date: 2012-10-11 13:31:47
On 10/11/2012 08:09 AM, Russell King - ARM Linux wrote:
On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
quoted
The contents of this were already reviewed on this thread, so I sent this
to the patch system and this was Russell's reply:
So that's why I couldn't find it - the mailing list thread has a different
subject line to the patch. Don't do that. Given the amount of list
traffic we have today, that's as good as not having been posted at all.
quoted
quoted
NAK for two reasons.
1. It hasn't been on the list (I can't find a match for "clear SCTLR.A"
in my mailbox)
2. The behaviour of unaligned accesses vary depending on CPU. Some
fix-up the access, others load the word and then rotate it. If we have
decompressors which perform unaligned accesses, we need to fix this
properly to avoid the CPU specific behaviour, rather than tweaking
control bits to hide the problem.
I'm simply matching the behavior of the kernel itself. The A bit is cleared
for v7 kernels and compilers only generate unaligned accesses for v7.
Without this the initial state of the A bit is undefined as a bootloader
could have cleared it already. We should document the required state or set
it to what we want.
Irrespective of this, (2) still stands. Unaligned accesses in the
decompressor without a fixup (which will be very hard to provide)
will return different data depending on the CPU as I mention in point
2.
This only affects v7 cores. It should not vary for v7 cores as unaligned
access is a required feature. So how is it going to vary on v7 CPUs?
We've got bigger problems if there are v7 cores that don't handle
unaligned accesses.
Rob
So, using unaligned accesses in the decompressor may not give expected
results in all cases, so they're best avoided.
And if they're avoided, then we don't care about the setting of the A
bit.
From: Russell King - ARM Linux <hidden> Date: 2012-10-11 13:41:30
On Thu, Oct 11, 2012 at 08:31:47AM -0500, Rob Herring wrote:
On 10/11/2012 08:09 AM, Russell King - ARM Linux wrote:
quoted
On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
quoted
The contents of this were already reviewed on this thread, so I sent this
to the patch system and this was Russell's reply:
So that's why I couldn't find it - the mailing list thread has a different
subject line to the patch. Don't do that. Given the amount of list
traffic we have today, that's as good as not having been posted at all.
quoted
quoted
NAK for two reasons.
1. It hasn't been on the list (I can't find a match for "clear SCTLR.A"
in my mailbox)
2. The behaviour of unaligned accesses vary depending on CPU. Some
fix-up the access, others load the word and then rotate it. If we have
decompressors which perform unaligned accesses, we need to fix this
properly to avoid the CPU specific behaviour, rather than tweaking
control bits to hide the problem.
I'm simply matching the behavior of the kernel itself. The A bit is cleared
for v7 kernels and compilers only generate unaligned accesses for v7.
Without this the initial state of the A bit is undefined as a bootloader
could have cleared it already. We should document the required state or set
it to what we want.
Irrespective of this, (2) still stands. Unaligned accesses in the
decompressor without a fixup (which will be very hard to provide)
will return different data depending on the CPU as I mention in point
2.
This only affects v7 cores. It should not vary for v7 cores as unaligned
access is a required feature. So how is it going to vary on v7 CPUs?
We've got bigger problems if there are v7 cores that don't handle
unaligned accesses.
Rob,
Your patch may only affect v7 cores, but you've raised the issue of the
decompressor performing unaligned accesses in general. Shall I re-repeat
my point over that or is the problem here going to finally sink in?
From: Russell King - ARM Linux <hidden> Date: 2012-10-11 13:59:26
On Thu, Oct 11, 2012 at 08:31:47AM -0500, Rob Herring wrote:
This only affects v7 cores. It should not vary for v7 cores as unaligned
access is a required feature. So how is it going to vary on v7 CPUs?
We've got bigger problems if there are v7 cores that don't handle
unaligned accesses.
Oh, and this gives me a third reason to NAK this patch. Why only ensure
that the A bit is clear for v7 CPUs? Why not v6, v5, v4 too? Why does
ARMv7 get this special treatment?
Any argument you can make for clearing the bit on ARMv7 also applies to
the other architectures too, but not even that negates my point (2) which
is far more fundamental.
From: Nicolas Pitre <hidden> Date: 2012-10-11 15:44:31
On Thu, 11 Oct 2012, Russell King - ARM Linux wrote:
On Thu, Oct 11, 2012 at 08:31:47AM -0500, Rob Herring wrote:
quoted
On 10/11/2012 08:09 AM, Russell King - ARM Linux wrote:
quoted
On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
quoted
The contents of this were already reviewed on this thread, so I sent this
to the patch system and this was Russell's reply:
So that's why I couldn't find it - the mailing list thread has a different
subject line to the patch. Don't do that. Given the amount of list
traffic we have today, that's as good as not having been posted at all.
quoted
quoted
NAK for two reasons.
1. It hasn't been on the list (I can't find a match for "clear SCTLR.A"
in my mailbox)
2. The behaviour of unaligned accesses vary depending on CPU. Some
fix-up the access, others load the word and then rotate it. If we have
decompressors which perform unaligned accesses, we need to fix this
properly to avoid the CPU specific behaviour, rather than tweaking
control bits to hide the problem.
I'm simply matching the behavior of the kernel itself. The A bit is cleared
for v7 kernels and compilers only generate unaligned accesses for v7.
Without this the initial state of the A bit is undefined as a bootloader
could have cleared it already. We should document the required state or set
it to what we want.
Irrespective of this, (2) still stands. Unaligned accesses in the
decompressor without a fixup (which will be very hard to provide)
will return different data depending on the CPU as I mention in point
2.
This only affects v7 cores. It should not vary for v7 cores as unaligned
access is a required feature. So how is it going to vary on v7 CPUs?
We've got bigger problems if there are v7 cores that don't handle
unaligned accesses.
Rob,
Your patch may only affect v7 cores, but you've raised the issue of the
decompressor performing unaligned accesses in general. Shall I re-repeat
my point over that or is the problem here going to finally sink in?
The decompressor is not performing direct unaligned accesses. It uses
the get_unaligned() and put_unaligned() accessors. That means that
we're in control of how this is happening.
So let's talk about the how. On pre ARMv7, those accesses are performed
with a series of byte accesses. When compiling for ARMv7, gcc knows and
that the hardware can do unaligned accesses, and it does optimize its
output by using ldr/str instructions. But the A bit has to be cleared
in that case, and only in that case. This is why the patch clears the A
bit only for ARMv7.
So this patch is only setting up the hardware to match gcc's
expectations when generating code from the use of get_unaligned() and
put_unaligned() when optimizing for ARMv7.
As always, any code doing unaligned access and _not_ using those
accessors is broken.
Nicolas
From: Nicolas Pitre <hidden> Date: 2012-10-11 15:58:15
On Thu, 11 Oct 2012, Russell King - ARM Linux wrote:
On Thu, Oct 11, 2012 at 08:31:47AM -0500, Rob Herring wrote:
quoted
This only affects v7 cores. It should not vary for v7 cores as unaligned
access is a required feature. So how is it going to vary on v7 CPUs?
We've got bigger problems if there are v7 cores that don't handle
unaligned accesses.
Oh, and this gives me a third reason to NAK this patch. Why only ensure
that the A bit is clear for v7 CPUs? Why not v6, v5, v4 too? Why does
ARMv7 get this special treatment?
As I said, gcc knows that ARMv7 can perform word sized accesses even
with misaligned pointers. So when it is passed a pointer marked with
the packed attribute, it will generate a series of byte accesses when
compiling for anything but ARMv7, and use a single ldr or str when
compiling for ARMv7.
Nicolas
On Thu, 11 Oct 2012, Russell King - ARM Linux wrote:
quoted
On Thu, Oct 11, 2012 at 08:31:47AM -0500, Rob Herring wrote:
quoted
On 10/11/2012 08:09 AM, Russell King - ARM Linux wrote:
quoted
On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
quoted
The contents of this were already reviewed on this thread, so I sent this
to the patch system and this was Russell's reply:
So that's why I couldn't find it - the mailing list thread has a different
subject line to the patch. Don't do that. Given the amount of list
traffic we have today, that's as good as not having been posted at all.
quoted
quoted
NAK for two reasons.
1. It hasn't been on the list (I can't find a match for "clear SCTLR.A"
in my mailbox)
2. The behaviour of unaligned accesses vary depending on CPU. Some
fix-up the access, others load the word and then rotate it. If we have
decompressors which perform unaligned accesses, we need to fix this
properly to avoid the CPU specific behaviour, rather than tweaking
control bits to hide the problem.
I'm simply matching the behavior of the kernel itself. The A bit is cleared
for v7 kernels and compilers only generate unaligned accesses for v7.
Without this the initial state of the A bit is undefined as a bootloader
could have cleared it already. We should document the required state or set
it to what we want.
Irrespective of this, (2) still stands. Unaligned accesses in the
decompressor without a fixup (which will be very hard to provide)
will return different data depending on the CPU as I mention in point
2.
This only affects v7 cores. It should not vary for v7 cores as unaligned
access is a required feature. So how is it going to vary on v7 CPUs?
We've got bigger problems if there are v7 cores that don't handle
unaligned accesses.
Rob,
Your patch may only affect v7 cores, but you've raised the issue of the
decompressor performing unaligned accesses in general. Shall I re-repeat
my point over that or is the problem here going to finally sink in?
The decompressor is not performing direct unaligned accesses. It uses
the get_unaligned() and put_unaligned() accessors. That means that
we're in control of how this is happening.
So let's talk about the how. On pre ARMv7, those accesses are performed
with a series of byte accesses. When compiling for ARMv7, gcc knows and
that the hardware can do unaligned accesses, and it does optimize its
output by using ldr/str instructions. But the A bit has to be cleared
in that case, and only in that case. This is why the patch clears the A
bit only for ARMv7.
So this patch is only setting up the hardware to match gcc's
expectations when generating code from the use of get_unaligned() and
put_unaligned() when optimizing for ARMv7.
As always, any code doing unaligned access and _not_ using those
accessors is broken.
So is there a chance that this patch will be applied for 3.7?
Currently I can't boot anymore Armada XP or Armada 370, if kernel is
compressed in LZO. It's annoying.
Russell, did Nicolas manage to convince you?
If not, what should be the solution to fix this issue?
Thanks,
Gregory
From: Johannes Stezenbach <hidden> Date: 2012-10-25 09:34:11
On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
With recent compilers and move to generic unaligned.h in commit d25c881
(ARM: 7493/1: use generic unaligned.h), unaligned accesses will be used
by the LZO decompressor on v7 cores. So we need to make sure unaligned
accesses are allowed by clearing the SCTLR A bit.
I just read this in http://gcc.gnu.org/gcc-4.7/changes.html:
On ARM, when compiling for ARMv6 (but not ARMv6-M), ARMv7-A, ARMv7-R, or
ARMv7-M, the new option -munaligned-access is active by default, which for
some source codes generates code that accesses memory on unaligned addresses.
This will require the kernel of those systems to enable such accesses
(controlled by CP15 register c1, refer to ARM documentation). Alternatively
or for compatibility with kernels where unaligned accesses are not supported,
all code has to be compiled with -mno-unaligned-access. Linux/ARM in official
releases has automatically and unconditionally supported unaligned accesses
as emitted by GCC due to this option being active, since Linux version 2.6.28.
My understanding is that gcc, using the same generic unaligned.h
source code, will generate code for ARMv6 and ARMv7 that uses
unaligned access, while for ARMv5 and older it won't. So it seems
gcc requires Linux to clear SCTLR.A and set SCTLR.U for ARMv6+.
Or add -mno-unaligned-access.
Is my understanding correct?
While v6 can support unaligned accesses, it is optional and current
compilers won't emit unaligned accesses. So we don't clear the A bit for
v6.
not true according to the gcc changes page
Thanks
Johannes
From: Russell King - ARM Linux <hidden> Date: 2012-10-25 12:07:19
On Tue, Oct 23, 2012 at 10:32:44PM +0200, Gregory CLEMENT wrote:
So is there a chance that this patch will be applied for 3.7?
Currently I can't boot anymore Armada XP or Armada 370, if kernel is
compressed in LZO. It's annoying.
Russell, did Nicolas manage to convince you?
Frankly, no - less so now that we have a question mark over ARMv6 which
seems to conflict with Nicolas' justification. This issue is larger than
just ARMv7...
From: Rob Herring <hidden> Date: 2012-10-25 12:41:45
On 10/25/2012 04:34 AM, Johannes Stezenbach wrote:
On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
quoted
With recent compilers and move to generic unaligned.h in commit d25c881
(ARM: 7493/1: use generic unaligned.h), unaligned accesses will be used
by the LZO decompressor on v7 cores. So we need to make sure unaligned
accesses are allowed by clearing the SCTLR A bit.
I just read this in http://gcc.gnu.org/gcc-4.7/changes.html:
On ARM, when compiling for ARMv6 (but not ARMv6-M), ARMv7-A, ARMv7-R, or
ARMv7-M, the new option -munaligned-access is active by default, which for
some source codes generates code that accesses memory on unaligned addresses.
This will require the kernel of those systems to enable such accesses
(controlled by CP15 register c1, refer to ARM documentation). Alternatively
or for compatibility with kernels where unaligned accesses are not supported,
all code has to be compiled with -mno-unaligned-access. Linux/ARM in official
releases has automatically and unconditionally supported unaligned accesses
as emitted by GCC due to this option being active, since Linux version 2.6.28.
I don't think there is such a thing as ARMv6-M.
My understanding is that gcc, using the same generic unaligned.h
source code, will generate code for ARMv6 and ARMv7 that uses
unaligned access, while for ARMv5 and older it won't. So it seems
gcc requires Linux to clear SCTLR.A and set SCTLR.U for ARMv6+.
Or add -mno-unaligned-access.
Is my understanding correct?
quoted
While v6 can support unaligned accesses, it is optional and current
compilers won't emit unaligned accesses. So we don't clear the A bit for
v6.
not true according to the gcc changes page
What are you going to believe: documentation or what the compiler
emitted? At least for ubuntu/linaro 4.6.3 which has the unaligned access
support backported and 4.7.2, unaligned accesses are emitted for v7
only. I guess default here means it is the default unless you change the
default in your build of gcc.
If we are going to do combined v6k and v7 kernels, then it would be nice
if we could get the compiler to emit unaligned accesses (assuming we
agree we can require that for v6).
Rob
On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
quoted
With recent compilers and move to generic unaligned.h in commit d25c881
(ARM: 7493/1: use generic unaligned.h), unaligned accesses will be used
by the LZO decompressor on v7 cores. So we need to make sure unaligned
accesses are allowed by clearing the SCTLR A bit.
I just read this in http://gcc.gnu.org/gcc-4.7/changes.html:
On ARM, when compiling for ARMv6 (but not ARMv6-M), ARMv7-A, ARMv7-R, or
ARMv7-M, the new option -munaligned-access is active by default, which for
some source codes generates code that accesses memory on unaligned addresses.
This will require the kernel of those systems to enable such accesses
(controlled by CP15 register c1, refer to ARM documentation). Alternatively
or for compatibility with kernels where unaligned accesses are not supported,
all code has to be compiled with -mno-unaligned-access. Linux/ARM in official
releases has automatically and unconditionally supported unaligned accesses
as emitted by GCC due to this option being active, since Linux version 2.6.28.
I don't think there is such a thing as ARMv6-M.
There is, that would be the Cortex-M0/M0+/M1. You cannot run Linux on these.
Arnd
From: Johannes Stezenbach <hidden> Date: 2012-10-25 14:16:45
On Thu, Oct 25, 2012 at 07:41:45AM -0500, Rob Herring wrote:
On 10/25/2012 04:34 AM, Johannes Stezenbach wrote:
quoted
On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
quoted
While v6 can support unaligned accesses, it is optional and current
compilers won't emit unaligned accesses. So we don't clear the A bit for
v6.
not true according to the gcc changes page
What are you going to believe: documentation or what the compiler
emitted? At least for ubuntu/linaro 4.6.3 which has the unaligned access
support backported and 4.7.2, unaligned accesses are emitted for v7
only. I guess default here means it is the default unless you change the
default in your build of gcc.
Since ARMv6 can handle unaligned access in the same way as ARMv7
it seems a clear bug in gcc which might hopefully get fixed.
Thus in this case I think it is reasonable to follow the
gcc documentation, otherwise the code would break for ARMv6
when gcc gets fixed.
Johannes
From: Rob Herring <hidden> Date: 2012-10-25 14:25:06
On 10/25/2012 09:16 AM, Johannes Stezenbach wrote:
On Thu, Oct 25, 2012 at 07:41:45AM -0500, Rob Herring wrote:
quoted
On 10/25/2012 04:34 AM, Johannes Stezenbach wrote:
quoted
On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
quoted
While v6 can support unaligned accesses, it is optional and current
compilers won't emit unaligned accesses. So we don't clear the A bit for
v6.
not true according to the gcc changes page
What are you going to believe: documentation or what the compiler
emitted? At least for ubuntu/linaro 4.6.3 which has the unaligned access
support backported and 4.7.2, unaligned accesses are emitted for v7
only. I guess default here means it is the default unless you change the
default in your build of gcc.
Since ARMv6 can handle unaligned access in the same way as ARMv7
it seems a clear bug in gcc which might hopefully get fixed.
Thus in this case I think it is reasonable to follow the
gcc documentation, otherwise the code would break for ARMv6
when gcc gets fixed.
But the compiler can't assume the state of the U bit. I think it is
still legal on v6 to not support unaligned accesses, but on v7 it is
required. All the standard v6 ARM cores support it, but I'm not sure
about custom cores or if there are SOCs with buses that don't support
unaligned accesses properly.
Rob
From: Nicolas Pitre <hidden> Date: 2012-10-25 15:02:18
On Thu, 25 Oct 2012, Rob Herring wrote:
On 10/25/2012 09:16 AM, Johannes Stezenbach wrote:
quoted
On Thu, Oct 25, 2012 at 07:41:45AM -0500, Rob Herring wrote:
quoted
On 10/25/2012 04:34 AM, Johannes Stezenbach wrote:
quoted
On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
quoted
While v6 can support unaligned accesses, it is optional and current
compilers won't emit unaligned accesses. So we don't clear the A bit for
v6.
not true according to the gcc changes page
What are you going to believe: documentation or what the compiler
emitted? At least for ubuntu/linaro 4.6.3 which has the unaligned access
support backported and 4.7.2, unaligned accesses are emitted for v7
only. I guess default here means it is the default unless you change the
default in your build of gcc.
Since ARMv6 can handle unaligned access in the same way as ARMv7
it seems a clear bug in gcc which might hopefully get fixed.
Thus in this case I think it is reasonable to follow the
gcc documentation, otherwise the code would break for ARMv6
when gcc gets fixed.
But the compiler can't assume the state of the U bit. I think it is
still legal on v6 to not support unaligned accesses, but on v7 it is
required. All the standard v6 ARM cores support it, but I'm not sure
about custom cores or if there are SOCs with buses that don't support
unaligned accesses properly.
The fact is that gcc assumes the A bit is cleared when generating code
for ARMv7, period. We need to conform our environment to gcc
expectations, or always compile the decompressor using a lower
architecture level than ARMv7. My preference is the former.
Nicolas
From: Johannes Stezenbach <hidden> Date: 2012-10-25 15:08:16
On Thu, Oct 25, 2012 at 09:25:06AM -0500, Rob Herring wrote:
On 10/25/2012 09:16 AM, Johannes Stezenbach wrote:
quoted
On Thu, Oct 25, 2012 at 07:41:45AM -0500, Rob Herring wrote:
quoted
On 10/25/2012 04:34 AM, Johannes Stezenbach wrote:
quoted
On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
quoted
While v6 can support unaligned accesses, it is optional and current
compilers won't emit unaligned accesses. So we don't clear the A bit for
v6.
not true according to the gcc changes page
What are you going to believe: documentation or what the compiler
emitted? At least for ubuntu/linaro 4.6.3 which has the unaligned access
support backported and 4.7.2, unaligned accesses are emitted for v7
only. I guess default here means it is the default unless you change the
default in your build of gcc.
Since ARMv6 can handle unaligned access in the same way as ARMv7
it seems a clear bug in gcc which might hopefully get fixed.
Thus in this case I think it is reasonable to follow the
gcc documentation, otherwise the code would break for ARMv6
when gcc gets fixed.
But the compiler can't assume the state of the U bit. I think it is
still legal on v6 to not support unaligned accesses, but on v7 it is
required. All the standard v6 ARM cores support it, but I'm not sure
about custom cores or if there are SOCs with buses that don't support
unaligned accesses properly.
Well, I read the "...since Linux version 2.6.28" comment
in the gcc changes page in the way that they assume the
U-bit is set. (Although I'm not sure it really is???)
Looking at it from another side, if using the hw unaligned
access capability gives a performance benefit then it
would be useful to support it even if gcc doesn't
behave as documented. One could still use a special
unaligned.h for ARMv6 to get the performance benefit.
(If it doesn't give performance benfit, then why
bother, let's just use -mno-unaligned-access for v7, too.)
In the ARMv6 ARM unaligned support and the U-bit is
not optional, so you could use the same SoC bus argument
for some hypothetical v7 SoCs.
Johannes
From: Dave Martin <hidden> Date: 2012-11-05 10:48:50
On Thu, Oct 25, 2012 at 05:08:16PM +0200, Johannes Stezenbach wrote:
On Thu, Oct 25, 2012 at 09:25:06AM -0500, Rob Herring wrote:
quoted
On 10/25/2012 09:16 AM, Johannes Stezenbach wrote:
quoted
On Thu, Oct 25, 2012 at 07:41:45AM -0500, Rob Herring wrote:
quoted
On 10/25/2012 04:34 AM, Johannes Stezenbach wrote:
quoted
On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
quoted
While v6 can support unaligned accesses, it is optional and current
compilers won't emit unaligned accesses. So we don't clear the A bit for
v6.
not true according to the gcc changes page
What are you going to believe: documentation or what the compiler
emitted? At least for ubuntu/linaro 4.6.3 which has the unaligned access
support backported and 4.7.2, unaligned accesses are emitted for v7
only. I guess default here means it is the default unless you change the
default in your build of gcc.
Since ARMv6 can handle unaligned access in the same way as ARMv7
it seems a clear bug in gcc which might hopefully get fixed.
Thus in this case I think it is reasonable to follow the
gcc documentation, otherwise the code would break for ARMv6
when gcc gets fixed.
But the compiler can't assume the state of the U bit. I think it is
still legal on v6 to not support unaligned accesses, but on v7 it is
required. All the standard v6 ARM cores support it, but I'm not sure
about custom cores or if there are SOCs with buses that don't support
unaligned accesses properly.
Well, I read the "...since Linux version 2.6.28" comment
in the gcc changes page in the way that they assume the
U-bit is set. (Although I'm not sure it really is???)
Actually, the kernel checks the arch version and the U bit on boot,
and chooses the appropriate setting for the A bit depending on the
result. (See arch/arm/mm/alignment.c:alignment_init().)
Currently, we depend on the CPU reset behaviour or firmware/
bootloader to set the U bit for v6, but the behaviour should be
correct either way, though unaligned accesses will obviously
perform (much) better with U=1.
From the compiler's point of view we have always implemented the
U=1 behaviour, but it has to be done via the alignment fault
handler prior to v6 or with U=0.
Looking at it from another side, if using the hw unaligned
access capability gives a performance benefit then it
would be useful to support it even if gcc doesn't
behave as documented. One could still use a special
unaligned.h for ARMv6 to get the performance benefit.
(If it doesn't give performance benfit, then why
bother, let's just use -mno-unaligned-access for v7, too.)
For v7, we should definitely use -munaligned-access where available
(unless it's the default?)
For v6, the question is whether there is any legitimate reason
ever to run the kernel with U=0. If not, could we explicitly
set it early and build with -munaligned-access where the compiler
supports this?
The only counterargument I can think of is that some people might
be running some ancient userspace which actually relies on the U=0
behaviour. I don't know whether anyone is actually doing that on
v6, though.
Cheers
---Dave
In the ARMv6 ARM unaligned support and the U-bit is
not optional, so you could use the same SoC bus argument
for some hypothetical v7 SoCs.
Johannes
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Russell King - ARM Linux <hidden> Date: 2012-11-05 11:13:46
On Mon, Nov 05, 2012 at 10:48:50AM +0000, Dave Martin wrote:
On Thu, Oct 25, 2012 at 05:08:16PM +0200, Johannes Stezenbach wrote:
quoted
On Thu, Oct 25, 2012 at 09:25:06AM -0500, Rob Herring wrote:
quoted
On 10/25/2012 09:16 AM, Johannes Stezenbach wrote:
quoted
On Thu, Oct 25, 2012 at 07:41:45AM -0500, Rob Herring wrote:
quoted
On 10/25/2012 04:34 AM, Johannes Stezenbach wrote:
quoted
On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
quoted
While v6 can support unaligned accesses, it is optional and current
compilers won't emit unaligned accesses. So we don't clear the A bit for
v6.
not true according to the gcc changes page
What are you going to believe: documentation or what the compiler
emitted? At least for ubuntu/linaro 4.6.3 which has the unaligned access
support backported and 4.7.2, unaligned accesses are emitted for v7
only. I guess default here means it is the default unless you change the
default in your build of gcc.
Since ARMv6 can handle unaligned access in the same way as ARMv7
it seems a clear bug in gcc which might hopefully get fixed.
Thus in this case I think it is reasonable to follow the
gcc documentation, otherwise the code would break for ARMv6
when gcc gets fixed.
But the compiler can't assume the state of the U bit. I think it is
still legal on v6 to not support unaligned accesses, but on v7 it is
required. All the standard v6 ARM cores support it, but I'm not sure
about custom cores or if there are SOCs with buses that don't support
unaligned accesses properly.
Well, I read the "...since Linux version 2.6.28" comment
in the gcc changes page in the way that they assume the
U-bit is set. (Although I'm not sure it really is???)
Actually, the kernel checks the arch version and the U bit on boot,
and chooses the appropriate setting for the A bit depending on the
result. (See arch/arm/mm/alignment.c:alignment_init().)
That is in the kernel itself, _after_ the decompressor has run. It is
not relevant to any discussion about the decompressor.
Currently, we depend on the CPU reset behaviour or firmware/
bootloader to set the U bit for v6, but the behaviour should be
correct either way, though unaligned accesses will obviously
perform (much) better with U=1.
Will someone _PLEASE_ address my initial comments against this patch
in light of the fact that it's now been proven _NOT_ to be just a V7
issue, rather than everyone seemingly buring their heads in the sand
over this.
The fact is, unaligned accesses in the decompressor are *undefined* at
present.
For v7, we should definitely use -munaligned-access where available
(unless it's the default?)
No such option on my compiler - according to the manual I have, the only
option there is starting -munaligned is on SPARC for -munaligned-doubles.
However, I believe GCC does believe that unaligned accesses are fine on
V6 and above.
From: Dave Martin <hidden> Date: 2012-11-05 13:02:55
On Mon, Nov 05, 2012 at 11:13:46AM +0000, Russell King - ARM Linux wrote:
On Mon, Nov 05, 2012 at 10:48:50AM +0000, Dave Martin wrote:
quoted
On Thu, Oct 25, 2012 at 05:08:16PM +0200, Johannes Stezenbach wrote:
quoted
On Thu, Oct 25, 2012 at 09:25:06AM -0500, Rob Herring wrote:
quoted
On 10/25/2012 09:16 AM, Johannes Stezenbach wrote:
quoted
On Thu, Oct 25, 2012 at 07:41:45AM -0500, Rob Herring wrote:
quoted
On 10/25/2012 04:34 AM, Johannes Stezenbach wrote:
quoted
On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
quoted
While v6 can support unaligned accesses, it is optional and current
compilers won't emit unaligned accesses. So we don't clear the A bit for
v6.
not true according to the gcc changes page
What are you going to believe: documentation or what the compiler
emitted? At least for ubuntu/linaro 4.6.3 which has the unaligned access
support backported and 4.7.2, unaligned accesses are emitted for v7
only. I guess default here means it is the default unless you change the
default in your build of gcc.
Since ARMv6 can handle unaligned access in the same way as ARMv7
it seems a clear bug in gcc which might hopefully get fixed.
Thus in this case I think it is reasonable to follow the
gcc documentation, otherwise the code would break for ARMv6
when gcc gets fixed.
But the compiler can't assume the state of the U bit. I think it is
still legal on v6 to not support unaligned accesses, but on v7 it is
required. All the standard v6 ARM cores support it, but I'm not sure
about custom cores or if there are SOCs with buses that don't support
unaligned accesses properly.
Well, I read the "...since Linux version 2.6.28" comment
in the gcc changes page in the way that they assume the
U-bit is set. (Although I'm not sure it really is???)
Actually, the kernel checks the arch version and the U bit on boot,
and chooses the appropriate setting for the A bit depending on the
result. (See arch/arm/mm/alignment.c:alignment_init().)
That is in the kernel itself, _after_ the decompressor has run. It is
not relevant to any discussion about the decompressor.
This was merely meant as an argument that the kernel does not make
assumptions about the U bit, and so the zImage decompressor probably
shouldn't either.
quoted
Currently, we depend on the CPU reset behaviour or firmware/
bootloader to set the U bit for v6, but the behaviour should be
correct either way, though unaligned accesses will obviously
perform (much) better with U=1.
Will someone _PLEASE_ address my initial comments against this patch
in light of the fact that it's now been proven _NOT_ to be just a V7
issue, rather than everyone seemingly buring their heads in the sand
over this.
The fact is, unaligned accesses in the decompressor are *undefined* at
present.
Why not allow unaligned accesses in the decompressor, though, both
for v6 and v7?
The decompressors run with the cache on, so we should have fault-free
unaligned access on all CPUs which support it, provided that we set the
SCTLR bits appropriately, and provided that the decompressers are
written in correct C.
The counterargument is that zImage would then just fall over if booted
on a CPU older than the baseline architecture the kernel was built for.
However, that should be detected before executing any C code, giving
the zImage code a chance to bail out with a suitable error message.
A kernel which contains support for v6/v7 platforms cannot work on older
CPUs anyway, because the kernel itself doesn't support such combinations.
quoted
For v7, we should definitely use -munaligned-access where available
(unless it's the default?)
No such option on my compiler - according to the manual I have, the only
option there is starting -munaligned is on SPARC for -munaligned-doubles.
OK, I guess that's something backported into the Linaro toolchain I'm
currently using then. But it seems a good idea to use this if available,
because it allows the compiler to generate better code in some situations,
especially for packed struct access.
However, I believe GCC does believe that unaligned accesses are fine on
V6 and above.
Possibly, but I've never seen it use them deliberately, prior to the
-munaligned-access support.
Cheers
---Dave
From: Johannes Stezenbach <hidden> Date: 2012-11-05 13:43:26
On Mon, Nov 05, 2012 at 01:02:55PM +0000, Dave Martin wrote:
On Mon, Nov 05, 2012 at 11:13:46AM +0000, Russell King - ARM Linux wrote:
quoted
On Mon, Nov 05, 2012 at 10:48:50AM +0000, Dave Martin wrote:
quoted
For v7, we should definitely use -munaligned-access where available
(unless it's the default?)
No such option on my compiler - according to the manual I have, the only
option there is starting -munaligned is on SPARC for -munaligned-doubles.
OK, I guess that's something backported into the Linaro toolchain I'm
currently using then. But it seems a good idea to use this if available,
because it allows the compiler to generate better code in some situations,
especially for packed struct access.
quoted
However, I believe GCC does believe that unaligned accesses are fine on
V6 and above.
Possibly, but I've never seen it use them deliberately, prior to the
-munaligned-access support.
http://gcc.gnu.org/gcc-4.7/changes.html says -munaligned-access is
enabled by default.
I haven't had a chance to try gcc-4.7 yet, but gcc-4.6+linaro
has the option but fails to generate the expected code for ARMv6
while it works for ARMv7. However it does
#define __ARM_FEATURE_UNALIGNED 1
and
.eabi_attribute 34, 1
This seems to be the commit which introduced unaligned support in gcc:
http://repo.or.cz/w/official-gcc.git/commitdiff/eb04cafba3a6f1eddbdb5ec031d8a7074930d5b9
I cannot figure out why this works for v7 but not for v6.
(I used gcc-4.6.4 20121001 (prerelease) toolchain built with crosstool-NG.)
Johannes
From: Rob Herring <hidden> Date: 2012-11-05 13:48:37
On 11/05/2012 05:13 AM, Russell King - ARM Linux wrote:
On Mon, Nov 05, 2012 at 10:48:50AM +0000, Dave Martin wrote:
quoted
On Thu, Oct 25, 2012 at 05:08:16PM +0200, Johannes Stezenbach wrote:
quoted
On Thu, Oct 25, 2012 at 09:25:06AM -0500, Rob Herring wrote:
quoted
On 10/25/2012 09:16 AM, Johannes Stezenbach wrote:
quoted
On Thu, Oct 25, 2012 at 07:41:45AM -0500, Rob Herring wrote:
quoted
On 10/25/2012 04:34 AM, Johannes Stezenbach wrote:
quoted
On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
quoted
While v6 can support unaligned accesses, it is optional and current
compilers won't emit unaligned accesses. So we don't clear the A bit for
v6.
not true according to the gcc changes page
What are you going to believe: documentation or what the compiler
emitted? At least for ubuntu/linaro 4.6.3 which has the unaligned access
support backported and 4.7.2, unaligned accesses are emitted for v7
only. I guess default here means it is the default unless you change the
default in your build of gcc.
Since ARMv6 can handle unaligned access in the same way as ARMv7
it seems a clear bug in gcc which might hopefully get fixed.
Thus in this case I think it is reasonable to follow the
gcc documentation, otherwise the code would break for ARMv6
when gcc gets fixed.
But the compiler can't assume the state of the U bit. I think it is
still legal on v6 to not support unaligned accesses, but on v7 it is
required. All the standard v6 ARM cores support it, but I'm not sure
about custom cores or if there are SOCs with buses that don't support
unaligned accesses properly.
Well, I read the "...since Linux version 2.6.28" comment
in the gcc changes page in the way that they assume the
U-bit is set. (Although I'm not sure it really is???)
Actually, the kernel checks the arch version and the U bit on boot,
and chooses the appropriate setting for the A bit depending on the
result. (See arch/arm/mm/alignment.c:alignment_init().)
That is in the kernel itself, _after_ the decompressor has run. It is
not relevant to any discussion about the decompressor.
quoted
Currently, we depend on the CPU reset behaviour or firmware/
bootloader to set the U bit for v6, but the behaviour should be
correct either way, though unaligned accesses will obviously
perform (much) better with U=1.
Will someone _PLEASE_ address my initial comments against this patch
in light of the fact that it's now been proven _NOT_ to be just a V7
issue, rather than everyone seemingly buring their heads in the sand
over this.
I tried adding -munaligned-accesses on a v6 build and still get byte
accesses rather than unaligned word accesses. So this does seem to be a
v7 only issue based on what gcc will currently produce. Copying Michael
Hope who can hopefully provide some insight on why v6 unaligned accesses
are not enabled.
The fact is, unaligned accesses in the decompressor are *undefined* at
present.
quoted
For v7, we should definitely use -munaligned-access where available
(unless it's the default?)
No such option on my compiler - according to the manual I have, the only
option there is starting -munaligned is on SPARC for -munaligned-doubles.
It's only added in 4.7 and backported to Linaro 4.6.3.
Rob
However, I believe GCC does believe that unaligned accesses are fine on
V6 and above.
From: Nicolas Pitre <hidden> Date: 2012-11-05 16:13:51
On Mon, 5 Nov 2012, Russell King - ARM Linux wrote:
On Mon, Nov 05, 2012 at 01:02:55PM +0000, Dave Martin wrote:
quoted
Why not allow unaligned accesses in the decompressor, though, both
for v6 and v7?
EXACTLY.
I have no objections to that. In fact, I made a remark to this effect
in my initial review of this patch. Whether or not gcc does take
advantage of this hardware ability in the end is orthogonal.
Nicolas
From: Dave Martin <hidden> Date: 2012-11-05 17:26:24
On Mon, Nov 05, 2012 at 11:13:51AM -0500, Nicolas Pitre wrote:
On Mon, 5 Nov 2012, Russell King - ARM Linux wrote:
quoted
On Mon, Nov 05, 2012 at 01:02:55PM +0000, Dave Martin wrote:
quoted
Why not allow unaligned accesses in the decompressor, though, both
for v6 and v7?
EXACTLY.
I have no objections to that. In fact, I made a remark to this effect
in my initial review of this patch. Whether or not gcc does take
advantage of this hardware ability in the end is orthogonal.
For the sake of argument, here's how it might look.
Currently, I make no attempt to restore the original state of the U bit.
The A bit if forced later by the kernel during boot, after a short window
during which we should only run low-level arch code and therefore where
no unaligned accesses should happen.
Does anyone think these issues are likely to be important?
Cheers
---Dave
From 160a5576b53264951ff8164775146b2d4feddecb Mon Sep 17 00:00:00 2001
From: Dave Martin <redacted>
Date: Mon, 5 Nov 2012 16:34:57 +0000
Subject: [PATCH] ARM: decompressor: Enable unaligned memory access for v6 and above
Modern GCC can generate code which makes use of the CPU's native
unaligned memory access capabilities. This is useful for the C
decompressor implementations used for unpacking compressed kernels.
This patch disables the alignment faults and enabled the v6
unaligned access on CPUs which support these features (i.e., v6 and
later), allowing full unaligned access support for C code in the
decompressor.
The decompressor C code must not be built to assume that unaligned
access works if support for v5 or older platforms is included in
the kernel.
Signed-off-by: Dave Martin <redacted>
---
Note: I have only build-tested this so far.
arch/arm/boot/compressed/head.S | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
From: Rob Herring <hidden> Date: 2012-11-05 17:44:52
On 11/05/2012 11:26 AM, Dave Martin wrote:
On Mon, Nov 05, 2012 at 11:13:51AM -0500, Nicolas Pitre wrote:
quoted
On Mon, 5 Nov 2012, Russell King - ARM Linux wrote:
quoted
On Mon, Nov 05, 2012 at 01:02:55PM +0000, Dave Martin wrote:
quoted
Why not allow unaligned accesses in the decompressor, though, both
for v6 and v7?
EXACTLY.
I have no objections to that. In fact, I made a remark to this effect
in my initial review of this patch. Whether or not gcc does take
advantage of this hardware ability in the end is orthogonal.
For the sake of argument, here's how it might look.
Currently, I make no attempt to restore the original state of the U bit.
The A bit if forced later by the kernel during boot, after a short window
during which we should only run low-level arch code and therefore where
no unaligned accesses should happen.
Does anyone think these issues are likely to be important?
And here is my updated version that does v6 somewhat differently:
8<------------------------------------------------------------------
From 76c2b7685397f13aa53f426822128430fc24b8a0 Mon Sep 17 00:00:00 2001
From: Rob Herring <redacted>
Date: Mon, 5 Nov 2012 11:39:48 -0600
Subject: [PATCH v2] ARM: decompressor: clear SCTLR.A bit for v6 and v7 cores
With recent compilers and move to generic unaligned.h in commit d25c881
(ARM: 7493/1: use generic unaligned.h), unaligned accesses will be used
by the LZO decompressor on v7 cores. So we need to make sure unaligned
accesses are allowed by clearing the SCTLR A bit.
While v6 can support unaligned accesses, it is optional and current
compilers won't emit unaligned accesses. In case this changes and to align
with the kernel behavior, we clear the A bit and set the U bit.
Signed-off-by: Rob Herring <redacted>
Acked-by: Nicolas Pitre <redacted>
Tested-by: Shawn Guo <redacted>
---
arch/arm/boot/compressed/head.S | 6 ++++++
1 file changed, 6 insertions(+)
From: Nicolas Pitre <hidden> Date: 2012-11-05 17:46:40
On Mon, 5 Nov 2012, Dave Martin wrote:
On Mon, Nov 05, 2012 at 11:13:51AM -0500, Nicolas Pitre wrote:
quoted
On Mon, 5 Nov 2012, Russell King - ARM Linux wrote:
quoted
On Mon, Nov 05, 2012 at 01:02:55PM +0000, Dave Martin wrote:
quoted
Why not allow unaligned accesses in the decompressor, though, both
for v6 and v7?
EXACTLY.
I have no objections to that. In fact, I made a remark to this effect
in my initial review of this patch. Whether or not gcc does take
advantage of this hardware ability in the end is orthogonal.
For the sake of argument, here's how it might look.
Currently, I make no attempt to restore the original state of the U bit.
The A bit if forced later by the kernel during boot, after a short window
during which we should only run low-level arch code and therefore where
no unaligned accesses should happen.
Does anyone think these issues are likely to be important?
Cheers
---Dave
quoted
From 160a5576b53264951ff8164775146b2d4feddecb Mon Sep 17 00:00:00 2001
From: Dave Martin <redacted>
Date: Mon, 5 Nov 2012 16:34:57 +0000
Subject: [PATCH] ARM: decompressor: Enable unaligned memory access for v6 and above
Modern GCC can generate code which makes use of the CPU's native
unaligned memory access capabilities. This is useful for the C
decompressor implementations used for unpacking compressed kernels.
This patch disables the alignment faults and enabled the v6
unaligned access on CPUs which support these features (i.e., v6 and
later), allowing full unaligned access support for C code in the
decompressor.
The decompressor C code must not be built to assume that unaligned
access works if support for v5 or older platforms is included in
the kernel.
I'd suggest here that the code must always use the get_unaligned and
put_unaligned accessors when dealing with unaligned pointers, regardless
of this patch. The compiler will optimize the access performed via
those accessors when possible.
Signed-off-by: Dave Martin <redacted>
Acked-by: Nicolas Pitre <redacted>
quoted hunk
---
Note: I have only build-tested this so far.
arch/arm/boot/compressed/head.S | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
--
1.7.4.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Nicolas Pitre <hidden> Date: 2012-11-05 20:02:51
On Mon, 5 Nov 2012, Rob Herring wrote:
On 11/05/2012 11:26 AM, Dave Martin wrote:
quoted
On Mon, Nov 05, 2012 at 11:13:51AM -0500, Nicolas Pitre wrote:
quoted
On Mon, 5 Nov 2012, Russell King - ARM Linux wrote:
quoted
On Mon, Nov 05, 2012 at 01:02:55PM +0000, Dave Martin wrote:
quoted
Why not allow unaligned accesses in the decompressor, though, both
for v6 and v7?
EXACTLY.
I have no objections to that. In fact, I made a remark to this effect
in my initial review of this patch. Whether or not gcc does take
advantage of this hardware ability in the end is orthogonal.
For the sake of argument, here's how it might look.
Currently, I make no attempt to restore the original state of the U bit.
The A bit if forced later by the kernel during boot, after a short window
during which we should only run low-level arch code and therefore where
no unaligned accesses should happen.
Does anyone think these issues are likely to be important?
And here is my updated version that does v6 somewhat differently:
If I had to choose, I'd prefer Dave's version as being a bit cleaner.
From 76c2b7685397f13aa53f426822128430fc24b8a0 Mon Sep 17 00:00:00 2001
From: Rob Herring <redacted>
Date: Mon, 5 Nov 2012 11:39:48 -0600
Subject: [PATCH v2] ARM: decompressor: clear SCTLR.A bit for v6 and v7 cores
With recent compilers and move to generic unaligned.h in commit d25c881
(ARM: 7493/1: use generic unaligned.h), unaligned accesses will be used
by the LZO decompressor on v7 cores. So we need to make sure unaligned
accesses are allowed by clearing the SCTLR A bit.
While v6 can support unaligned accesses, it is optional and current
compilers won't emit unaligned accesses. In case this changes and to align
with the kernel behavior, we clear the A bit and set the U bit.
Signed-off-by: Rob Herring <redacted>
Acked-by: Nicolas Pitre <redacted>
Tested-by: Shawn Guo <redacted>
---
arch/arm/boot/compressed/head.S | 6 ++++++
1 file changed, 6 insertions(+)
From: Michael Hope <hidden> Date: 2012-11-05 22:02:27
On 6 November 2012 02:48, Rob Herring [off-list ref] wrote:
On 11/05/2012 05:13 AM, Russell King - ARM Linux wrote:
quoted
On Mon, Nov 05, 2012 at 10:48:50AM +0000, Dave Martin wrote:
quoted
On Thu, Oct 25, 2012 at 05:08:16PM +0200, Johannes Stezenbach wrote:
quoted
On Thu, Oct 25, 2012 at 09:25:06AM -0500, Rob Herring wrote:
quoted
On 10/25/2012 09:16 AM, Johannes Stezenbach wrote:
quoted
On Thu, Oct 25, 2012 at 07:41:45AM -0500, Rob Herring wrote:
quoted
On 10/25/2012 04:34 AM, Johannes Stezenbach wrote:
quoted
On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
quoted
While v6 can support unaligned accesses, it is optional and current
compilers won't emit unaligned accesses. So we don't clear the A bit for
v6.
not true according to the gcc changes page
What are you going to believe: documentation or what the compiler
emitted? At least for ubuntu/linaro 4.6.3 which has the unaligned access
support backported and 4.7.2, unaligned accesses are emitted for v7
only. I guess default here means it is the default unless you change the
default in your build of gcc.
Since ARMv6 can handle unaligned access in the same way as ARMv7
it seems a clear bug in gcc which might hopefully get fixed.
Thus in this case I think it is reasonable to follow the
gcc documentation, otherwise the code would break for ARMv6
when gcc gets fixed.
But the compiler can't assume the state of the U bit. I think it is
still legal on v6 to not support unaligned accesses, but on v7 it is
required. All the standard v6 ARM cores support it, but I'm not sure
about custom cores or if there are SOCs with buses that don't support
unaligned accesses properly.
Well, I read the "...since Linux version 2.6.28" comment
in the gcc changes page in the way that they assume the
U-bit is set. (Although I'm not sure it really is???)
Actually, the kernel checks the arch version and the U bit on boot,
and chooses the appropriate setting for the A bit depending on the
result. (See arch/arm/mm/alignment.c:alignment_init().)
That is in the kernel itself, _after_ the decompressor has run. It is
not relevant to any discussion about the decompressor.
quoted
Currently, we depend on the CPU reset behaviour or firmware/
bootloader to set the U bit for v6, but the behaviour should be
correct either way, though unaligned accesses will obviously
perform (much) better with U=1.
Will someone _PLEASE_ address my initial comments against this patch
in light of the fact that it's now been proven _NOT_ to be just a V7
issue, rather than everyone seemingly buring their heads in the sand
over this.
I tried adding -munaligned-accesses on a v6 build and still get byte
accesses rather than unaligned word accesses. So this does seem to be a
v7 only issue based on what gcc will currently produce. Copying Michael
Hope who can hopefully provide some insight on why v6 unaligned accesses
are not enabled.
This looks like a bug. Unaligned access is enabled for armv6 but
seems to only take effect for cores with Thumb-2. Here's a test case
both with unaligned field access and unaligned block copy:
struct foo
{
char a;
int b;
struct
{
int x[3];
} c;
} __attribute__((packed));
int get_field(struct foo *p)
{
return p->b;
}
int copy_block(struct foo *p, struct foo *q)
{
p->c = q->c;
}
With -march=armv7-a you get the correct:
bar:
ldr r0, [r0, #1] @ unaligned @ 11 unaligned_loadsi/2 [length = 4]
bx lr @ 21 *arm_return [length = 12]
baz:
str r4, [sp, #-4]! @ 25 *push_multi [length = 4]
mov r2, r0 @ 2 *arm_movsi_vfp/1 [length = 4]
ldr r4, [r1, #5]! @ unaligned @ 9 unaligned_loadsi/2 [length = 4]
ldr ip, [r1, #4] @ unaligned @ 10 unaligned_loadsi/2 [length = 4]
ldr r1, [r1, #8] @ unaligned @ 11 unaligned_loadsi/2 [length = 4]
str r4, [r2, #5] @ unaligned @ 12 unaligned_storesi/2 [length = 4]
str ip, [r2, #9] @ unaligned @ 13 unaligned_storesi/2 [length = 4]
str r1, [r2, #13] @ unaligned @ 14 unaligned_storesi/2 [length = 4]
ldmfd sp!, {r4}
bx lr
With -march=armv6 you get a byte-by-byte field access and a correct
unaligned block copy:
bar:
ldrb r1, [r0, #2] @ zero_extendqisi2
ldrb r3, [r0, #1] @ zero_extendqisi2
ldrb r2, [r0, #3] @ zero_extendqisi2
ldrb r0, [r0, #4] @ zero_extendqisi2
orr r3, r3, r1, asl #8
orr r3, r3, r2, asl #16
orr r0, r3, r0, asl #24
bx lr
baz:
str r4, [sp, #-4]!
mov r2, r0
ldr r4, [r1, #5]! @ unaligned
ldr ip, [r1, #4] @ unaligned
ldr r1, [r1, #8] @ unaligned
str r4, [r2, #5] @ unaligned
str ip, [r2, #9] @ unaligned
str r1, [r2, #13] @ unaligned
ldmfd sp!, {r4}
bx lr
readelf -A shows that the compiler planned to use unaligned access in
both. My suspicion is that GCC is using the extv pattern to extract
the field from memory, and that pattern is only enabled for Thumb-2
capable cores.
I've logged PR55218. We'll discuss it at our next meeting.
-- Michael
On 6 November 2012 02:48, Rob Herring [off-list ref] wrote:
quoted
I tried adding -munaligned-accesses on a v6 build and still get byte
accesses rather than unaligned word accesses. So this does seem to be a
v7 only issue based on what gcc will currently produce. Copying Michael
Hope who can hopefully provide some insight on why v6 unaligned accesses
are not enabled.
This looks like a bug. Unaligned access is enabled for armv6 but
seems to only take effect for cores with Thumb-2. Here's a test case
both with unaligned field access and unaligned block copy:
struct foo
{
char a;
int b;
struct
{
int x[3];
} c;
} __attribute__((packed));
int get_field(struct foo *p)
{
return p->b;
}
int copy_block(struct foo *p, struct foo *q)
{
p->c = q->c;
}
With -march=armv7-a you get the correct:
bar:
ldr r0, [r0, #1] @ unaligned @ 11 unaligned_loadsi/2 [length = 4]
bx lr @ 21 *arm_return [length = 12]
baz:
str r4, [sp, #-4]! @ 25 *push_multi [length = 4]
mov r2, r0 @ 2 *arm_movsi_vfp/1 [length = 4]
ldr r4, [r1, #5]! @ unaligned @ 9 unaligned_loadsi/2 [length = 4]
ldr ip, [r1, #4] @ unaligned @ 10 unaligned_loadsi/2 [length = 4]
ldr r1, [r1, #8] @ unaligned @ 11 unaligned_loadsi/2 [length = 4]
str r4, [r2, #5] @ unaligned @ 12 unaligned_storesi/2 [length = 4]
str ip, [r2, #9] @ unaligned @ 13 unaligned_storesi/2 [length = 4]
str r1, [r2, #13] @ unaligned @ 14 unaligned_storesi/2 [length = 4]
ldmfd sp!, {r4}
bx lr
With -march=armv6 you get a byte-by-byte field access and a correct
unaligned block copy:
bar:
ldrb r1, [r0, #2] @ zero_extendqisi2
ldrb r3, [r0, #1] @ zero_extendqisi2
ldrb r2, [r0, #3] @ zero_extendqisi2
ldrb r0, [r0, #4] @ zero_extendqisi2
orr r3, r3, r1, asl #8
orr r3, r3, r2, asl #16
orr r0, r3, r0, asl #24
bx lr
baz:
str r4, [sp, #-4]!
mov r2, r0
ldr r4, [r1, #5]! @ unaligned
ldr ip, [r1, #4] @ unaligned
ldr r1, [r1, #8] @ unaligned
str r4, [r2, #5] @ unaligned
str ip, [r2, #9] @ unaligned
str r1, [r2, #13] @ unaligned
ldmfd sp!, {r4}
bx lr
readelf -A shows that the compiler planned to use unaligned access in
both. My suspicion is that GCC is using the extv pattern to extract
the field from memory, and that pattern is only enabled for Thumb-2
capable cores.
I've logged PR55218. We'll discuss it at our next meeting.
Just tried with gcc-linaro-4.7-2013.01 (gcc-4.7.3 20130102 (prerelease)),
the issue is still unfixed. Do you have any idea how to fix it?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55218
Thanks,
Johannes