"Unhandled fault: Alignment Exception" Error booting Freescale 2.6.35 Kernel

[DonaldR_PooleJr]

Hello All,

I've downloaded and compiled Freescale's 2.6.35 kernel from their opensource gitweb, but when I boot the kernel on my i.MX53QSB I get a series of 8 Unhandled fault: alignment exception errors.  I've attached my complete boot output, but the first occurrence of the boot error is shown below:

MMC read: dev # 0, block # 2048, count 6144 ... 6144 blocks read: OK
## Booting kernel from Legacy Image at 70800000 ...
   Image Name:   Linux-2.6.35.3
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2917388 Bytes = 2.8 MiB
   Load Address: 70008000
   Entry Point:  70008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Linux version 2.6.35.3 (victory@ubuntu) (gcc version 4.5.2 (Sourcery G++ Lite 2011.03-41) ) #1 PREEMPT Wed Nov 30 11:30:54 CST 2011

CPU: ARMv7 Processor [412fc085] revision 5 (ARMv7), cr=10c53c7f

CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache

Machine: Freescale MX53 LOCO Board

Memory policy: ECC disabled, Data cache writeback

Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 250880

Kernel command line: console=ttymxc0,115200 root=/dev/mmcblk0p1 rw rootfstype=ext3 rootwait video=mxcdi0fb:RGB24,1024x768M@60

PID hash table entries: 4096 (order: 2, 16384 bytes)

Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)

Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)

Memory: 480MB 512MB = 992MB total

Memory: 998300k/998300k available, 17508k reserved, 0K highmem

Virtual kernel memory layout:

    vector  : 0xffff0000 - 0xffff1000   (   4 kB)

    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)

    DMA     : 0xf9e00000 - 0xffe00000   (  96 MB)

    vmalloc : 0xe0800000 - 0xf4000000   ( 312 MB)

    lowmem  : 0x80000000 - 0xe0000000   (1536 MB)

    pkmap   : 0x7fe00000 - 0x80000000   (   2 MB)

    modules : 0x7f000000 - 0x7fe00000   (  14 MB)

      .init : 0x80008000 - 0x80033000   ( 172 kB)

      .text : 0x80033000 - 0x807e0000   (7860 kB)

      .data : 0x80804000 - 0x8085b4a0   ( 350 kB)

SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1

Hierarchical RCU implementation.

.RCU-based detection of stalled CPUs is disabled.

.Verbose stalled-CPUs detection is disabled.

NR_IRQS:368MXC GPIO hardware

MXC IRQ initialized

MXC_Early serial console at MMIO 0x53fbc000 (options '115200')

bootconsole [ttymxc0] enabled

Console: colour dummy device 80x30

Calibrating delay loop... 799.53 BogoMIPS (lpj=3997696)

pid_max: default: 32768 minimum: 301

Mount-cache hash table entries: 512

CPU: Testing write buffer coherency: ok

Unhandled fault: alignment exception (0x001) at 0x8079112a

Internal error: : 1 [#1] PREEMPT

last sysfs file: 

Modules linked in:

CPU: 0    Not tainted  (2.6.35.3 #1)

PC is at devtmpfs_init+0xc/0xa4

LR is at driver_init+0x8/0x28

pc : [<8001dea4>]    lr : [<8001de54>]    psr: 80000013

sp : df039fd0  ip : 00000000  fp : 00000000

r10: 00000000  r9 : 00000000  r8 : 00000000

r7 : 00000013  r6 : 800349fc  r5 : 800088f0  r4 : 800321a8

r3 : 8079112a  r2 : 800a2218  r1 : 00000000  r0 : 8083f1fc

Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel

Control: 10c5387f  Table: 70004019  DAC: 00000017

Process swapper (pid: 1, stack limit = 0xdf0382e8)

Stack: (0xdf039fd0 to 0xdf03a000)

9fc0:                                     00000000 00000000 800a2218 00000000

9fe0: 800321a8 8001de54 800321a8 8000896c 00000000 800349fc 01207b65 89251006

[<8001dea4>] (devtmpfs_init+0xc/0xa4) from [<8001de54>] (driver_init+0x8/0x28

[<8001de54>] (driver_init+0x8/0x28) from [<8000896c>] (kernel_init+0x7c/0x168

[<8000896c>] (kernel_init+0x7c/0x168) from [<800349fc>] (kernel_thread_exit+0x0/0x8)

Code: 8083f1ec e92d401f e59f3080 e59f0080 (e5932000)

The kernel eventually stops displaying output and appears to hang.  Has anyone encountered this kind of error booting the Freescale kernel?  I'm at a lose right now since I don't know what angle to attack this problem from.  Thanks in advance!

[Michael_McTerna]

Addendum: some kernels (at least 2.6.35.3 and 2.6.38 from the Freescale Quick Start Board BSP) override EXTRA_CFLAGS in the Makefiles, so needs an extra patch to make the kernel bootable when using a newer toolchain with EXTRA_CFLAGS=-mno-unaligned-access.

The main culprit seems to be in arch/arm/boot/compressed/Makefile:

-EXTRA_CFLAGS := -fpic -fno-builtin
-EXTRA_ASFLAGS := -Wa,-march=all
+ccflags-y := -fpic -fno-builtin
+asflags-y := -Wa,-march=all

[Michael_McTerna]

Leon Woestenberg said:

yes your approach seems the safest one. I just found out that the new Freescale kernel patch set (2011 December) has additional alignment issues (and other new issues regarding the IPU...).

Good to know - thanks!  I'm definitely sticking with the switch for now :-D

What kernel source base are you using?

3.0.0.

[sidebranch]

Michael,

yes your approach seems the safest one. I just found out that the new Freescale kernel patch set (2011 December) has additional alignment issues (and other new issues regarding the IPU...).

What kernel source base are you using?

Regards,

Leon.

[Michael_McTerna]

Leon Woestenberg said:

So could you confirm (or deny) that you had enabled devtmpfs in the config (Freescale has it off by default AFAIK).

I do have that, so tried a build without CONFIG_DEVTMPFS set, and sadly that's not it, or at least not the only non-aligned access.

In my case, I find the problem really early on, as the boot output looks like this:

Uncompressing Linux... done, booting the kernel.

So I'll stick with EXTRA_CFLAGS=-mno-unaligned-access since it's more convenient than having yet another ARM tool chain installed

Also note that this isn't a stock BSP kernel although it does have the Freescale patch set in it.

[sidebranch]

I ran into that problem also, I just read this forum posting much later, so I went of I solved it on my own.

I first traced the bug down to the init function of devtmpfs (i.e. this is where the unaligned access occurs).

So could you confirm (or deny) that you had enabled devtmpfs in the config (Freescale has it off by default AFAIK).

Regards,

Leon.

[DonaldR_PooleJr]

Thanks for the reply Micheal.  I just came across that flag yesterday when I was reading through the changelog for codesourcery toolchain.  Wish I would've known earlier because it would've saved me a lot of time.

Michael McTernan said:

Donald R. Poole, Jr. said:

Update: It looks like the problem was with my cross-compile toolchain.

...

The CodeSourcery 2011.03-41 version of the toolchain is built with "Unaligned access support" optimization,

You can disable this behaviour by building with -mno-unaligned-access e.g.

  make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- EXTRA_CFLAGS=-mno-unaligned-access

There's a good description of this here: http://blog.galemin.com/tag/codesourcery/

[Michael_McTerna]

Donald R. Poole, Jr. said:

Update: It looks like the problem was with my cross-compile toolchain.

...

The CodeSourcery 2011.03-41 version of the toolchain is built with "Unaligned access support" optimization,

You can disable this behaviour by building with -mno-unaligned-access e.g.

  make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- EXTRA_CFLAGS=-mno-unaligned-access

There's a good description of this here: http://blog.galemin.com/tag/codesourcery/

[DonaldR_PooleJr]

Update: It looks like the problem was with my cross-compile toolchain.

Technically, there is a bit called the "A-bit" in the Control Register (CR) of processor that controls how unaligned memory faults are handled: 0=strict alignment fault checking disabled, 1=strict alignment fault enabled.  The CodeSourcery 2011.03-41 version of the toolchain is built with "Unaligned access support" optimization, which assumes that the hardware (A-bit=0) will handle unaligned memory loads.  But, the linux kernel by default uses software (A-bit=1) handlers (traps) for unaligned memory access faults.  So, although the kernel was compiled and optimized to assume no strict alignment fault checking, it's still configured to set the "A-bit" to check for memory alignment faults.  I found all this out after reading the Cortex-A8 Technical Reference Manual and doing some googling.

But, I said all of that to say this: If you run into this problem and you are using the CodeSourcery 2011.03-41 tool-chain, you can either use and older version of the tool-chain or use a different tool-chain altogether.  I ended up using the Ubuntu's GNU C/C++ Compiler/Preprocessor for ARM found in ubuntu software center.

I hope that this is able to help somebody if they encounter the same situation.