There's an interaction between Linaro GCC or FSF GCC 4.7 and Linux kernels before 3.2 which causes the kernel to halt straight after showing 'Uncompressing Linux'. The question comes up every couple of months so I've blogged about it: http://seabright.co.nz/2012/06/11/kernel-not-booting-with-linaro-gcc/
""" Is your ARM Linux kernel not booting when building with Linaro GCC or FSF GCC 4.7? Does it halt shortly after showing ‘Uncompressing Linux’? You may have run into an interaction between older kernels and the new unaligned access support in GCC. This affects Linaro GCC from 4.6-2011.11 onwards, GCC from 4.7.0 on, and kernels earlier than 3.2 including the Galaxy Nexus Icecream Sandwich release.
The work-around is to add -mno-unaligned-access to KBUILD_CFLAGS in the top level kernel Makefile or to backport 8428e84d42179c2a00f5f6450866e70d802d1d05 from the current kernel tree.
ARMv6K and later processors have hardware support for doing unaligned loads and stores which is faster than the old byte-by-byte/recombine that was done in software. Later versions of GCC use this to do quicker loads when working on known unaligned data, such as when working on a protocol buffer or a packed structure.
The CPU can be configured to trap on unaligned access. This trap is off at reset, but pre 3.2 kernels turn this on during the initial boot. An interaction between -fconserve-stack and -munaligned-access on a char buffer lead to an unaligned access, which causes a trap, which causes the kernel to halt.
This does not affect userspace programs as they run with the trap turned off. """
-- Michael
On 06/10/2012 05:31 PM, Michael Hope wrote:
There's an interaction between Linaro GCC or FSF GCC 4.7 and Linux kernels before 3.2 which causes the kernel to halt straight after showing 'Uncompressing Linux'. The question comes up every couple of months so I've blogged about it: http://seabright.co.nz/2012/06/11/kernel-not-booting-with-linaro-gcc/
""" Is your ARM Linux kernel not booting when building with Linaro GCC or FSF GCC 4.7? Does it halt shortly after showing ‘Uncompressing Linux’? You may have run into an interaction between older kernels and the new unaligned access support in GCC. This affects Linaro GCC from 4.6-2011.11 onwards, GCC from 4.7.0 on, and kernels earlier than 3.2 including the Galaxy Nexus Icecream Sandwich release.
The work-around is to add -mno-unaligned-access to KBUILD_CFLAGS in the top level kernel Makefile or to backport 8428e84d42179c2a00f5f6450866e70d802d1d05 from the current kernel tree.
ARMv6K and later processors have hardware support for doing unaligned loads and stores which is faster than the old byte-by-byte/recombine that was done in software. Later versions of GCC use this to do quicker loads when working on known unaligned data, such as when working on a protocol buffer or a packed structure.
The CPU can be configured to trap on unaligned access. This trap is off at reset, but pre 3.2 kernels turn this on during the initial boot. An interaction between -fconserve-stack and -munaligned-access on a char buffer lead to an unaligned access, which causes a trap, which causes the kernel to halt.
This does not affect userspace programs as they run with the trap turned off. """
I've also hit this with u-boot if I enable armv7-a builds. Mainline u-boot generally builds using -march=armv5 and unaligned accesses disabled in h/w. Generally u-boot starts but dies on certain commands. I think there may be other u-boot issues with v7 compiles on newer gcc versions, but haven't debugged things further.
Rob
-- Michael
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On 14 June 2012 04:22, Rob Herring robherring2@gmail.com wrote:
On 06/10/2012 05:31 PM, Michael Hope wrote:
There's an interaction between Linaro GCC or FSF GCC 4.7 and Linux kernels before 3.2 which causes the kernel to halt straight after showing 'Uncompressing Linux'. The question comes up every couple of months so I've blogged about it: http://seabright.co.nz/2012/06/11/kernel-not-booting-with-linaro-gcc/
""" Is your ARM Linux kernel not booting when building with Linaro GCC or FSF GCC 4.7? Does it halt shortly after showing ‘Uncompressing Linux’? You may have run into an interaction between older kernels and the new unaligned access support in GCC. This affects Linaro GCC from 4.6-2011.11 onwards, GCC from 4.7.0 on, and kernels earlier than 3.2 including the Galaxy Nexus Icecream Sandwich release.
The work-around is to add -mno-unaligned-access to KBUILD_CFLAGS in the top level kernel Makefile or to backport 8428e84d42179c2a00f5f6450866e70d802d1d05 from the current kernel tree.
ARMv6K and later processors have hardware support for doing unaligned loads and stores which is faster than the old byte-by-byte/recombine that was done in software. Later versions of GCC use this to do quicker loads when working on known unaligned data, such as when working on a protocol buffer or a packed structure.
The CPU can be configured to trap on unaligned access. This trap is off at reset, but pre 3.2 kernels turn this on during the initial boot. An interaction between -fconserve-stack and -munaligned-access on a char buffer lead to an unaligned access, which causes a trap, which causes the kernel to halt.
This does not affect userspace programs as they run with the trap turned off. """
I've also hit this with u-boot if I enable armv7-a builds. Mainline u-boot generally builds using -march=armv5 and unaligned accesses disabled in h/w. Generally u-boot starts but dies on certain commands. I think there may be other u-boot issues with v7 compiles on newer gcc versions, but haven't debugged things further.
Note that this is done through a unaligned access trap that is off by default. A quick grep through u-boot git shows that it defines CR_A but doesn't use it.
-- Michael
On 06/13/2012 03:26 PM, Michael Hope wrote:
On 14 June 2012 04:22, Rob Herring robherring2@gmail.com wrote:
On 06/10/2012 05:31 PM, Michael Hope wrote:
There's an interaction between Linaro GCC or FSF GCC 4.7 and Linux kernels before 3.2 which causes the kernel to halt straight after showing 'Uncompressing Linux'. The question comes up every couple of months so I've blogged about it: http://seabright.co.nz/2012/06/11/kernel-not-booting-with-linaro-gcc/
""" Is your ARM Linux kernel not booting when building with Linaro GCC or FSF GCC 4.7? Does it halt shortly after showing ‘Uncompressing Linux’? You may have run into an interaction between older kernels and the new unaligned access support in GCC. This affects Linaro GCC from 4.6-2011.11 onwards, GCC from 4.7.0 on, and kernels earlier than 3.2 including the Galaxy Nexus Icecream Sandwich release.
The work-around is to add -mno-unaligned-access to KBUILD_CFLAGS in the top level kernel Makefile or to backport 8428e84d42179c2a00f5f6450866e70d802d1d05 from the current kernel tree.
ARMv6K and later processors have hardware support for doing unaligned loads and stores which is faster than the old byte-by-byte/recombine that was done in software. Later versions of GCC use this to do quicker loads when working on known unaligned data, such as when working on a protocol buffer or a packed structure.
The CPU can be configured to trap on unaligned access. This trap is off at reset, but pre 3.2 kernels turn this on during the initial boot. An interaction between -fconserve-stack and -munaligned-access on a char buffer lead to an unaligned access, which causes a trap, which causes the kernel to halt.
This does not affect userspace programs as they run with the trap turned off. """
I've also hit this with u-boot if I enable armv7-a builds. Mainline u-boot generally builds using -march=armv5 and unaligned accesses disabled in h/w. Generally u-boot starts but dies on certain commands. I think there may be other u-boot issues with v7 compiles on newer gcc versions, but haven't debugged things further.
Note that this is done through a unaligned access trap that is off by default. A quick grep through u-boot git shows that it defines CR_A but doesn't use it.
The A bit is on in u-boot.
armv7 start.S:
mrc p15, 0, r0, c1, c0, 0 bic r0, r0, #0x00002000 @ clear bits 13 (--V-) bic r0, r0, #0x00000007 @ clear bits 2:0 (-CAM) orr r0, r0, #0x00000002 @ set bit 1 (--A-) Align orr r0, r0, #0x00000800 @ set bit 11 (Z---) BTB #ifdef CONFIG_SYS_ICACHE_OFF bic r0, r0, #0x00001000 @ clear bit 12 (I) I-cache #else orr r0, r0, #0x00001000 @ set bit 12 (I) I-cache #endif mcr p15, 0, r0, c1, c0, 0 mov pc, lr @ back to my caller
There is no trap handler in u-boot. I've turned off the A bit, but still had some problems which I did not debug further.
Rob
-- Michael
-
Michael Hope -
Rob Herring