[PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option

[PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option

[Jonas Jensen]

CPU_FA526 lacks thumb state support and doesn't get along with some
of the options enabled by ARCH_MULTI_V4T.

More specifically it doesn't get along with CPU_ARM920T:

CPU_ABRT_EV4T
CPU_CACHE_V4WT
CPU_COPY_V4WB
CPU_TLB_V4WBI

One or a combination of the above cause trouble for userspace, the
following happens when kernel tries to exec init:

[   11.790000] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
[   11.790000]
[   11.790000] CPU: 0 PID: 1 Comm: init Not tainted 3.13.0-rc3-next-20131212+ #1332
[   11.790000] [<c000d620>] (unwind_backtrace) from [<c000ba54>] (show_stack+0x18/0x1c)
[   11.790000] [<c000ba54>] (show_stack) from [<c027f498>] (dump_stack+0x20/0x28)
[   11.790000] [<c027f498>] (dump_stack) from [<c027ce80>] (panic+0x98/0x1ec)
[   11.790000] [<c027ce80>] (panic) from [<c0016d4c>] (do_exit+0x80c/0x8e8)
[   11.790000] [<c0016d4c>] (do_exit) from [<c0016ea4>] (do_group_exit+0x44/0xb8)
[   11.790000] [<c0016ea4>] (do_group_exit) from [<c0022dbc>] (get_signal_to_deliver+0x2fc/0x5a4)
[   11.790000] [<c0022dbc>] (get_signal_to_deliver) from [<c027ca38>] (do_signal+0xac/0x3e0)
[   11.790000] [<c027ca38>] (do_signal) from [<c000b460>] (do_work_pending+0xcc/0xe8)
[   11.790000] [<c000b460>] (do_work_pending) from [<c0009374>] (work_pending+0xc/0x20)

Reinsert ARCH_MULTI_V4 so it can be used on platforms with CPU_FA526.

Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
---

Notes:
    I don't know how to handle this so I'm making it standalone for
    your feedback (it was broken out from MOXA ART SoC series).
    
    This is important for MOXA ART (and other FA526 platforms),
    please have a look.
    
    Applies to next-20131213

 arch/arm/Kconfig | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b64a8ef..4f88ff3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -863,6 +863,11 @@ menu "Multiple platform selection"
 
 comment "CPU Core family selection"
 
+config ARCH_MULTI_V4
+	bool "ARMv4 based platforms (FA526, StrongARM)"
+	depends on !ARCH_MULTI_V6_V7
+	select ARCH_MULTI_V4_V5
+
 config ARCH_MULTI_V4T
 	bool "ARMv4T based platforms (ARM720T, ARM920T, ...)"
 	depends on !ARCH_MULTI_V6_V7
-- 
1.8.2.1

Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option

[Russell King - ARM Linux]

On Fri, Dec 13, 2013 at 09:09:09AM +0100, Jonas Jensen wrote:
> CPU_FA526 lacks thumb state support and doesn't get along with some
> of the options enabled by ARCH_MULTI_V4T.
> 
> More specifically it doesn't get along with CPU_ARM920T:
> 
> CPU_ABRT_EV4T
> CPU_CACHE_V4WT
> CPU_COPY_V4WB
> CPU_TLB_V4WBI

Having these selected doesn't change how the kernel is compiled or how
the kernel uses the code which these provide.  These mainly control
which files are built.

They also control indirectly how the code is called - but the ultimate
decision is made by the CPU which is detected and the block in
__fa526_proc_info.

So, having these symbols enabled (provided the right ones for FA526 are
also enabled) makes no difference.  So I don't buy your explanation.

Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option

[Jonas Jensen]

On 13 December 2013 10:56, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> So, having these symbols enabled (provided the right ones for FA526 are
> also enabled) makes no difference.  So I don't buy your explanation.

The explanation is indeed false, CPU_FA526 and CPU_ARM920T get along just fine.
That's not where the problem is.

Panic goes away after removing CONFIG_ARM_THUMB=y.

I assume this is what should happen on processors without thumb?

Thanks,
Jonas

Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option

[Russell King - ARM Linux]

On Fri, Dec 13, 2013 at 11:51:09AM +0100, Jonas Jensen wrote:
> On 13 December 2013 10:56, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > So, having these symbols enabled (provided the right ones for FA526 are
> > also enabled) makes no difference.  So I don't buy your explanation.
> 
> The explanation is indeed false, CPU_FA526 and CPU_ARM920T get along just fine.
> That's not where the problem is.
> 
> Panic goes away after removing CONFIG_ARM_THUMB=y.
> 
> I assume this is what should happen on processors without thumb?

I see what's causing this: the kuser helpers are using "bx lr" to return
which will be undefined on non-Thumb CPUs.  We generally cope fine with
non-Thumb CPUs, conditionalising where necessary on HWCAP_THUMB or the
T bit in the PSR being set.

However, it looks like the kuser helpers got missed.  As a check, please
look at arch/arm/kernel/entry-armv.S, find the line with:

	.macro	usr_ret, reg

and ensure that the mov pc, \reg case always gets used.  Please report
back.

Thanks.

Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option

[Jonas Jensen]

Boots without panic when bx is removed.

Diff and boot log:

diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index b3fb8c9..ad736b3 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -737,8 +737,8 @@ ENDPROC(__switch_to)

        .macro  usr_ret, reg
 #ifdef CONFIG_ARM_THUMB
-       bx      \reg
-#else
+#      bx      \reg
+##else
        mov     pc, \reg
 #endif
        .endm


Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 3.13.0-rc3-next-20131213+ (i@Ildjarn)
(gcc version 4.6.3 (crosstool-NG 1.16.0) ) #1346 PREEMPT Fri Dec 13
13:16:00 CET 2013
[    0.000000] CPU: FA526 [66015261] revision 1 (ARMv4), cr=0000397f
[    0.000000] CPU: VIVT data cache, VIVT instruction cache
[    0.000000] Machine model: MOXA UC-7112-LX
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] Memory policy: Data cache writeback
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 8120
[    0.000000] Kernel command line: console=ttyS0,115200n8 earlyprintk
root=/dev/mmcblk0p1 rw rootwait
[    0.000000] PID hash table entries: 128 (order: -3, 512 bytes)
[    0.000000] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Memory: 23116K/32768K available (2521K kernel code,
108K rwdata, 572K rodata, 150K init, 5884K bss, 9652K reserved)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xc2800000 - 0xff000000   ( 968 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xc2000000   (  32 MB)
[    0.000000]       .text : 0xc0008000 - 0xc030d914   (3095 kB)
[    0.000000]       .init : 0xc030e000 - 0xc0333b30   ( 151 kB)
[    0.000000]       .data : 0xc0334000 - 0xc034f160   ( 109 kB)
[    0.000000]        .bss : 0xc034f16c - 0xc090e378   (5885 kB)
[    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] sched_clock: 32 bits at 100 Hz, resolution 10000000ns,
wraps every 21474836480000000ns
[    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat,
Inc., Ingo Molnar
[    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.000000] ... MAX_LOCK_DEPTH:          48
[    0.000000] ... MAX_LOCKDEP_KEYS:        8191
[    0.000000] ... CLASSHASH_SIZE:          4096
[    0.000000] ... MAX_LOCKDEP_ENTRIES:     16384
[    0.000000] ... MAX_LOCKDEP_CHAINS:      32768
[    0.000000] ... CHAINHASH_SIZE:          16384
[    0.000000]  memory used by lock dependency info: 3695 kB
[    0.000000]  per task-struct memory footprint: 1152 bytes
[    0.000000] kmemleak: Kernel memory leak detector disabled
[    0.000000] kmemleak: Early log buffer exceeded (673), please
increase DEBUG_KMEMLEAK_EARLY_LOG_SIZE
[    0.120000] Calibrating delay loop... 144.79 BogoMIPS (lpj=723968)
[    0.200000] pid_max: default: 4096 minimum: 301
[    0.210000] Mount-cache hash table entries: 512
[    0.290000] CPU: Testing write buffer coherency: ok
[    0.310000] Setting up static identity map for 0x266a60 - 0x266ae8
[    0.370000] devtmpfs: initialized
[    0.420000] kworker/u2:0 (13) used greatest stack depth: 6296 bytes left
[    0.430000] NET: Registered protocol family 16
[    0.460000] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    1.050000] bio: create slab <bio-0> at 0
[    1.390000] DMA-API: preallocated 4096 debug entries
[    1.390000] DMA-API: debugging enabled by kernel config
[    1.400000] Switched to clocksource moxart_timer
[    1.510000] NET: Registered protocol family 2
[    1.530000] TCP established hash table entries: 1024 (order: 0, 4096 bytes)
[    1.550000] TCP bind hash table entries: 1024 (order: 3, 36864 bytes)
[    1.560000] TCP: Hash tables configured (established 1024 bind 1024)
[    1.570000] TCP: reno registered
[    1.570000] UDP hash table entries: 128 (order: 1, 10240 bytes)
[    1.580000] UDP-Lite hash table entries: 128 (order: 1, 10240 bytes)
[    1.600000] NET: Registered protocol family 1
[    1.720000] kworker/u2:0 (136) used greatest stack depth: 6196 bytes left
[    2.330000] jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
[    2.370000] msgmni has been set to 45
[    2.380000] io scheduler noop registered
[    2.380000] io scheduler cfq registered (default)
[    2.430000] Serial: 8250/16550 driver, 1 ports, IRQ sharing enabled
[    2.520000] 98200000.uart: ttyS0 at MMIO 0x98200000 (irq = 21,
base_baud = 921600) is a 16550A
[    2.530000] console [ttyS0] enabled
[    2.530000] console [ttyS0] enabled
[    2.540000] bootconsole [earlycon0] disabled
[    2.540000] bootconsole [earlycon0] disabled
[    2.650000] 80000000.flash: Found 1 x16 devices at 0x0 in 16-bit
bank. Manufacturer ID 0x000089 Chip ID 0x000018
[    2.660000] Intel/Sharp Extended Query Table at 0x0031
[    2.660000] Intel/Sharp Extended Query Table at 0x0031
[    2.670000] Using buffer write method
[    2.670000] cfi_cmdset_0001: Erase suspend on write enabled
[    2.680000] 4 ofpart partitions found on MTD device 80000000.flash
[    2.690000] Creating 4 MTD partitions on "80000000.flash":
[    2.690000] 0x000000000000-0x000000040000 : "bootloader"
[    2.780000] 0x000000040000-0x000000200000 : "linux kernel"
[    2.840000] 0x000000200000-0x000000a00000 : "root filesystem"
[    2.910000] 0x000000a00000-0x000001000000 : "user filesystem"
[    3.650000] libphy: MOXA ART Ethernet MII: probed
[    4.340000] libphy: MOXA ART Ethernet MII: probed
[    4.420000] moxart-ethernet 90900000.mac eth0: generated random MAC
address ee:8e:8b:cb:a1:e2
[    4.460000] moxart-ethernet 92000000.mac eth1: generated random MAC
address 1a:78:21:30:99:8c
[    4.490000] input: gpio_keys_polled.2 as
/devices/gpio_keys_polled.2/input/input0
[    4.550000] moxart-rtc rtc.0: rtc core: registered rtc.0 as rtc0
[    4.740000] TCP: cubic registered
[    4.780000] mmc0: new SD card at address 636c
[    4.830000] console [netcon0] enabled
[    4.850000] netconsole: network logging started
[    4.850000] moxart-rtc rtc.0: setting system clock to 2010-02-08
03:35:33 UTC (1265600133)
[    4.860000] mmcblk0: mmc0:636c SD02G 1.83 GiB
[    4.920000]  mmcblk0: p1
[    5.400000] EXT3-fs (mmcblk0p1): warning: ext3_clear_journal_err:
Filesystem error recorded from previous mount: IO failure
[    5.410000] kjournald starting.  Commit interval 5 seconds
[    5.420000] EXT3-fs (mmcblk0p1): warning: ext3_clear_journal_err:
Marking fs in need of filesystem check.
[    5.450000] EXT3-fs (mmcblk0p1): warning: mounting fs with errors,
running e2fsck is recommended
[    5.480000] EXT3-fs (mmcblk0p1): using internal journal
[    5.730000] EXT3-fs (mmcblk0p1): recovery complete
[    5.730000] EXT3-fs (mmcblk0p1): mounted filesystem with ordered data mode
[    5.740000] VFS: Mounted root (ext3 filesystem) on device 179:1.
[    5.770000] devtmpfs: mounted
[    5.780000] Freeing unused kernel memory: 148K (c030e000 - c0333000)
init started: BusyBox v1.22.0.git (2013-12-13 13:22:47 CET)
starting pid 264, tty '': '/etc/init.d/start'
[    7.220000] mount (265) used greatest stack depth: 5924 bytes left
[    7.700000] route (272) used greatest stack depth: 5872 bytes left
PING 10.0.1.200 (10.0.1.200): 56 data bytes
64 bytes from 10.0.1.200: seq=0 ttl=64 time=20.008 ms
[    9.450000] libphy: 90900090.mdio--1:01 - Link is Up - 100/Full
[    9.500000] libphy: 92000090.mdio--1:01 - Link is Up - 100/Full
64 bytes from 10.0.1.200: seq=1 ttl=64 time=3.308 ms
[   10.180000] SysRq : Terminate All Tasks
starting pid 275, tty '': '/bin/cttyhack /bin/sh'
[   10.210000] ping (274) used greatest stack depth: 5628 bytes left
# zcat /proc/config.gz | grep THUMB
CONFIG_ARM_THUMB=y

Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option

[Jonas Jensen]

On 13 December 2013 12:39, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> I see what's causing this: the kuser helpers are using "bx lr" to return
> which will be undefined on non-Thumb CPUs.  We generally cope fine with
> non-Thumb CPUs, conditionalising where necessary on HWCAP_THUMB or the
> T bit in the PSR being set.
>
> However, it looks like the kuser helpers got missed.  As a check, please
> look at arch/arm/kernel/entry-armv.S, find the line with:
>
>         .macro  usr_ret, reg
>
> and ensure that the mov pc, \reg case always gets used.  Please report
> back.

Uwe and Arnd came up with a solution except it doesn't work when I test it.

The suggested patch is:

diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 1879e8d..de15bfd 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -739,6 +739,18 @@ ENDPROC(__switch_to)

        .macro  usr_ret, reg
 #ifdef CONFIG_ARM_THUMB
+       /*
+        * Having CONFIG_ARM_THUMB isn't a guarantee that the cpu has support
+        * for Thumb and so the bx instruction. Use a mov if the address to
+        * jump to is 32 bit aligned. (Note that this code is compiled in ARM
+        * mode, so this is the right test.)
+        */
+#if defined(CONFIG_CPU_32v4)
+       tst     \reg, #3
+       moveq   pc, \reg
+       b       .
+#endif
+
        bx      \reg
 #else
        mov     pc, \reg


With this applied, and the following two possibilities in next-20140403:

[1] ARCH_MULTI_V4 only (no CONFIG_ARM_THUMB)
     CONFIG_CPU_32v4=y

[2] ARCH_MULTI_V4 and ARCH_MULTI_V4T
     CONFIG_ARM_THUMB=y
     CONFIG_CPU_32v4=y
     CONFIG_CPU_32v4T=y


Booting a kernel with either option [1] or [2] yield the following results:

[1] works
[2] hangs after "[    2.730000] Freeing unused kernel memory: 104K
(c02f5000 - c030f000)"


Any help why the moveq doesn't work would be much appreciated.


The commit where this was tested:
https://bitbucket.org/Kasreyn/linux-next/commits/48320cbe0d5a1fb6ada52cea9efd87c7712367cb


Regards,
Jonas

Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option

[Uwe Kleine-König]

On Wed, Apr 09, 2014 at 04:54:16PM +0200, Jonas Jensen wrote:
> On 13 December 2013 12:39, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > I see what's causing this: the kuser helpers are using "bx lr" to return
> > which will be undefined on non-Thumb CPUs.  We generally cope fine with
> > non-Thumb CPUs, conditionalising where necessary on HWCAP_THUMB or the
> > T bit in the PSR being set.
> >
> > However, it looks like the kuser helpers got missed.  As a check, please
> > look at arch/arm/kernel/entry-armv.S, find the line with:
> >
> >         .macro  usr_ret, reg
> >
> > and ensure that the mov pc, \reg case always gets used.  Please report
> > back.
> 
> Uwe and Arnd came up with a solution except it doesn't work when I test it.
> 
> The suggested patch is:
> 
> diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
> index 1879e8d..de15bfd 100644
> --- a/arch/arm/kernel/entry-armv.S
> +++ b/arch/arm/kernel/entry-armv.S
> @@ -739,6 +739,18 @@ ENDPROC(__switch_to)
> 
>         .macro  usr_ret, reg
>  #ifdef CONFIG_ARM_THUMB
> +       /*
> +        * Having CONFIG_ARM_THUMB isn't a guarantee that the cpu has support
> +        * for Thumb and so the bx instruction. Use a mov if the address to
> +        * jump to is 32 bit aligned. (Note that this code is compiled in ARM
> +        * mode, so this is the right test.)
> +        */
> +#if defined(CONFIG_CPU_32v4)
> +       tst     \reg, #3
> +       moveq   pc, \reg
> +       b       .
> +#endif
> +
>         bx      \reg
>  #else
>         mov     pc, \reg
> 
> 
> With this applied, and the following two possibilities in next-20140403:
> 
> [1] ARCH_MULTI_V4 only (no CONFIG_ARM_THUMB)
>      CONFIG_CPU_32v4=y
> 
> [2] ARCH_MULTI_V4 and ARCH_MULTI_V4T
>      CONFIG_ARM_THUMB=y
>      CONFIG_CPU_32v4=y
>      CONFIG_CPU_32v4T=y
> 
> 
> Booting a kernel with either option [1] or [2] yield the following results:
> 
> [1] works
> [2] hangs after "[    2.730000] Freeing unused kernel memory: 104K
> (c02f5000 - c030f000)"
> 
> 
> Any help why the moveq doesn't work would be much appreciated.
doing s/moveq/mov/ does the trick on the machine in question, but this
is obviously not an option for mainline. But it means that even on this
non-Thumb capable machine \reg contains an address that is not aligned.

Where does \reg come from? Is it provided by userspace? If so, is it a
userspace bug?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option

[Russell King - ARM Linux]

On Wed, Apr 09, 2014 at 04:54:16PM +0200, Jonas Jensen wrote:
> On 13 December 2013 12:39, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > I see what's causing this: the kuser helpers are using "bx lr" to return
> > which will be undefined on non-Thumb CPUs.  We generally cope fine with
> > non-Thumb CPUs, conditionalising where necessary on HWCAP_THUMB or the
> > T bit in the PSR being set.
> >
> > However, it looks like the kuser helpers got missed.  As a check, please
> > look at arch/arm/kernel/entry-armv.S, find the line with:
> >
> >         .macro  usr_ret, reg
> >
> > and ensure that the mov pc, \reg case always gets used.  Please report
> > back.
> 
> Uwe and Arnd came up with a solution except it doesn't work when I test it.
> 
> The suggested patch is:
> 
> diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
> index 1879e8d..de15bfd 100644
> --- a/arch/arm/kernel/entry-armv.S
> +++ b/arch/arm/kernel/entry-armv.S
> @@ -739,6 +739,18 @@ ENDPROC(__switch_to)
> 
>         .macro  usr_ret, reg
>  #ifdef CONFIG_ARM_THUMB
> +       /*
> +        * Having CONFIG_ARM_THUMB isn't a guarantee that the cpu has support
> +        * for Thumb and so the bx instruction. Use a mov if the address to
> +        * jump to is 32 bit aligned. (Note that this code is compiled in ARM
> +        * mode, so this is the right test.)
> +        */
> +#if defined(CONFIG_CPU_32v4)
> +       tst     \reg, #3
> +       moveq   pc, \reg
> +       b       .
> +#endif
> +
>         bx      \reg

What's wrong with:
	tst	\reg, #3
	moveq	pc, \reg
	bx	\reg

rather than ending in an infinite loop?

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option

[Russell King - ARM Linux]

On Wed, Apr 09, 2014 at 05:04:48PM +0200, Uwe Kleine-König wrote:
> On Wed, Apr 09, 2014 at 04:54:16PM +0200, Jonas Jensen wrote:
> > On 13 December 2013 12:39, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> > > I see what's causing this: the kuser helpers are using "bx lr" to return
> > > which will be undefined on non-Thumb CPUs.  We generally cope fine with
> > > non-Thumb CPUs, conditionalising where necessary on HWCAP_THUMB or the
> > > T bit in the PSR being set.
> > >
> > > However, it looks like the kuser helpers got missed.  As a check, please
> > > look at arch/arm/kernel/entry-armv.S, find the line with:
> > >
> > >         .macro  usr_ret, reg
> > >
> > > and ensure that the mov pc, \reg case always gets used.  Please report
> > > back.
> > 
> > Uwe and Arnd came up with a solution except it doesn't work when I test it.
> > 
> > The suggested patch is:
> > 
> > diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
> > index 1879e8d..de15bfd 100644
> > --- a/arch/arm/kernel/entry-armv.S
> > +++ b/arch/arm/kernel/entry-armv.S
> > @@ -739,6 +739,18 @@ ENDPROC(__switch_to)
> > 
> >         .macro  usr_ret, reg
> >  #ifdef CONFIG_ARM_THUMB
> > +       /*
> > +        * Having CONFIG_ARM_THUMB isn't a guarantee that the cpu has support
> > +        * for Thumb and so the bx instruction. Use a mov if the address to
> > +        * jump to is 32 bit aligned. (Note that this code is compiled in ARM
> > +        * mode, so this is the right test.)
> > +        */
> > +#if defined(CONFIG_CPU_32v4)
> > +       tst     \reg, #3
> > +       moveq   pc, \reg
> > +       b       .
> > +#endif
> > +
> >         bx      \reg
> >  #else
> >         mov     pc, \reg
> > 
> > 
> > With this applied, and the following two possibilities in next-20140403:
> > 
> > [1] ARCH_MULTI_V4 only (no CONFIG_ARM_THUMB)
> >      CONFIG_CPU_32v4=y
> > 
> > [2] ARCH_MULTI_V4 and ARCH_MULTI_V4T
> >      CONFIG_ARM_THUMB=y
> >      CONFIG_CPU_32v4=y
> >      CONFIG_CPU_32v4T=y
> > 
> > 
> > Booting a kernel with either option [1] or [2] yield the following results:
> > 
> > [1] works
> > [2] hangs after "[    2.730000] Freeing unused kernel memory: 104K
> > (c02f5000 - c030f000)"
> > 
> > 
> > Any help why the moveq doesn't work would be much appreciated.
> doing s/moveq/mov/ does the trick on the machine in question, but this
> is obviously not an option for mainline. But it means that even on this
> non-Thumb capable machine \reg contains an address that is not aligned.
> 
> Where does \reg come from? Is it provided by userspace? If so, is it a
> userspace bug?

Well, in case (2), if usr_ret is returning to a caller running thumb code,
it will lock up - because the register will not be aligned, so moveq will
fail, and the next instruction is a branch which only ever branches to
itself.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option

[Uwe Kleine-König]

Hello Russell,

On Wed, Apr 09, 2014 at 04:06:40PM +0100, Russell King - ARM Linux wrote:
> On Wed, Apr 09, 2014 at 04:54:16PM +0200, Jonas Jensen wrote:
> > On 13 December 2013 12:39, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> > > I see what's causing this: the kuser helpers are using "bx lr" to return
> > > which will be undefined on non-Thumb CPUs.  We generally cope fine with
> > > non-Thumb CPUs, conditionalising where necessary on HWCAP_THUMB or the
> > > T bit in the PSR being set.
> > >
> > > However, it looks like the kuser helpers got missed.  As a check, please
> > > look at arch/arm/kernel/entry-armv.S, find the line with:
> > >
> > >         .macro  usr_ret, reg
> > >
> > > and ensure that the mov pc, \reg case always gets used.  Please report
> > > back.
> > 
> > Uwe and Arnd came up with a solution except it doesn't work when I test it.
> > 
> > The suggested patch is:
> > 
> > diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
> > index 1879e8d..de15bfd 100644
> > --- a/arch/arm/kernel/entry-armv.S
> > +++ b/arch/arm/kernel/entry-armv.S
> > @@ -739,6 +739,18 @@ ENDPROC(__switch_to)
> > 
> >         .macro  usr_ret, reg
> >  #ifdef CONFIG_ARM_THUMB
> > +       /*
> > +        * Having CONFIG_ARM_THUMB isn't a guarantee that the cpu has support
> > +        * for Thumb and so the bx instruction. Use a mov if the address to
> > +        * jump to is 32 bit aligned. (Note that this code is compiled in ARM
> > +        * mode, so this is the right test.)
> > +        */
> > +#if defined(CONFIG_CPU_32v4)
> > +       tst     \reg, #3
> > +       moveq   pc, \reg
> > +       b       .
> > +#endif
> > +
> >         bx      \reg
> 
> What's wrong with:
> 	tst	\reg, #3
> 	moveq	pc, \reg
> 	bx	\reg
> 
> rather than ending in an infinite loop?
The added b . was a test to check if the machine then hangs instead of
crashing. (And yes, that was the case, so it was tried to return to a
non-aligned address.)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option

[Russell King - ARM Linux]

On Wed, Apr 09, 2014 at 05:13:26PM +0200, Uwe Kleine-König wrote:
> Hello Russell,
> 
> On Wed, Apr 09, 2014 at 04:06:40PM +0100, Russell King - ARM Linux wrote:
> > On Wed, Apr 09, 2014 at 04:54:16PM +0200, Jonas Jensen wrote:
> > > On 13 December 2013 12:39, Russell King - ARM Linux
> > > <linux@arm.linux.org.uk> wrote:
> > > > I see what's causing this: the kuser helpers are using "bx lr" to return
> > > > which will be undefined on non-Thumb CPUs.  We generally cope fine with
> > > > non-Thumb CPUs, conditionalising where necessary on HWCAP_THUMB or the
> > > > T bit in the PSR being set.
> > > >
> > > > However, it looks like the kuser helpers got missed.  As a check, please
> > > > look at arch/arm/kernel/entry-armv.S, find the line with:
> > > >
> > > >         .macro  usr_ret, reg
> > > >
> > > > and ensure that the mov pc, \reg case always gets used.  Please report
> > > > back.
> > > 
> > > Uwe and Arnd came up with a solution except it doesn't work when I test it.
> > > 
> > > The suggested patch is:
> > > 
> > > diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
> > > index 1879e8d..de15bfd 100644
> > > --- a/arch/arm/kernel/entry-armv.S
> > > +++ b/arch/arm/kernel/entry-armv.S
> > > @@ -739,6 +739,18 @@ ENDPROC(__switch_to)
> > > 
> > >         .macro  usr_ret, reg
> > >  #ifdef CONFIG_ARM_THUMB
> > > +       /*
> > > +        * Having CONFIG_ARM_THUMB isn't a guarantee that the cpu has support
> > > +        * for Thumb and so the bx instruction. Use a mov if the address to
> > > +        * jump to is 32 bit aligned. (Note that this code is compiled in ARM
> > > +        * mode, so this is the right test.)
> > > +        */
> > > +#if defined(CONFIG_CPU_32v4)
> > > +       tst     \reg, #3
> > > +       moveq   pc, \reg
> > > +       b       .
> > > +#endif
> > > +
> > >         bx      \reg
> > 
> > What's wrong with:
> > 	tst	\reg, #3
> > 	moveq	pc, \reg
> > 	bx	\reg
> > 
> > rather than ending in an infinite loop?
> The added b . was a test to check if the machine then hangs instead of
> crashing. (And yes, that was the case, so it was tried to return to a
> non-aligned address.)

If it's called from ARM code, then \reg will contain a 4-byte aligned
address.  If it's called from Thumb code, \reg will contain a 2-byte
aligned address with bit 0 *always* set.

So, with the code originally quoted above, if the helper is called from
thumb code, and CONFIG_CPU_32v4 is enabled, then we end up falling past
the moveq to the "b ." and entering an infinite loop.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option

[Arnd Bergmann]

On Wednesday 09 April 2014 16:27:11 Russell King - ARM Linux wrote:
> On Wed, Apr 09, 2014 at 05:13:26PM +0200, Uwe Kleine-König wrote:
> > On Wed, Apr 09, 2014 at 04:06:40PM +0100, Russell King - ARM Linux wrote:
> > > On Wed, Apr 09, 2014 at 04:54:16PM +0200, Jonas Jensen wrote:
> > > > On 13 December 2013 12:39, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> > > > diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
> > > > index 1879e8d..de15bfd 100644
> > > > --- a/arch/arm/kernel/entry-armv.S
> > > > +++ b/arch/arm/kernel/entry-armv.S
> > > > @@ -739,6 +739,18 @@ ENDPROC(__switch_to)
> > > > 
> > > >         .macro  usr_ret, reg
> > > >  #ifdef CONFIG_ARM_THUMB
> > > > +       /*
> > > > +        * Having CONFIG_ARM_THUMB isn't a guarantee that the cpu has support
> > > > +        * for Thumb and so the bx instruction. Use a mov if the address to
> > > > +        * jump to is 32 bit aligned. (Note that this code is compiled in ARM
> > > > +        * mode, so this is the right test.)
> > > > +        */
> > > > +#if defined(CONFIG_CPU_32v4)
> > > > +       tst     \reg, #3
> > > > +       moveq   pc, \reg
> > > > +       b       .
> > > > +#endif
> > > > +
> > > >         bx      \reg
> > > 
> > > What's wrong with:
> > >     tst     \reg, #3
> > >     moveq   pc, \reg
> > >     bx      \reg
> > > 
> > > rather than ending in an infinite loop?
> > The added b . was a test to check if the machine then hangs instead of
> > crashing. (And yes, that was the case, so it was tried to return to a
> > non-aligned address.)
> 
> If it's called from ARM code, then \reg will contain a 4-byte aligned
> address.  If it's called from Thumb code, \reg will contain a 2-byte
> aligned address with bit 0 *always* set.

Right, that is the assumption.

> So, with the code originally quoted above, if the helper is called from
> thumb code, and CONFIG_CPU_32v4 is enabled, then we end up falling past
> the moveq to the "b ." and entering an infinite loop.

As Uwe said, that "b ." was not meant to be in the patch used for
submission, it was to check what goes wrong when running this code
on ARMv4 -- either crash user space or hang in an infinite loop.
I forgot what the result of that experiment was.

The trouble is that this code:

       .macro  usr_ret, reg
#ifdef CONFIG_ARM_THUMB
#ifdef CONFIG_CPU_32v4
	tst     \reg, #3
	moveq   pc, \reg
#endif
        bx      \reg
#else
	mov	pc, \reg
#endif
	.endm

for some reason does the wrong thing running on ARMv4 (fa526) with non-thumb
user space when both CONFIG_CPU_32v4 and CONFIG_ARM_THUMB are enabled:
it still tries to do the 'bx' and triggers an invalid opcode exception.

	Arnd

Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option

[Russell King - ARM Linux]

On Wed, Apr 09, 2014 at 05:50:57PM +0200, Arnd Bergmann wrote:
> On Wednesday 09 April 2014 16:27:11 Russell King - ARM Linux wrote:
> > If it's called from ARM code, then \reg will contain a 4-byte aligned
> > address.  If it's called from Thumb code, \reg will contain a 2-byte
> > aligned address with bit 0 *always* set.
> 
> Right, that is the assumption.
> 
> > So, with the code originally quoted above, if the helper is called from
> > thumb code, and CONFIG_CPU_32v4 is enabled, then we end up falling past
> > the moveq to the "b ." and entering an infinite loop.
> 
> As Uwe said, that "b ." was not meant to be in the patch used for
> submission, it was to check what goes wrong when running this code
> on ARMv4 -- either crash user space or hang in an infinite loop.
> I forgot what the result of that experiment was.
> 
> The trouble is that this code:
> 
>        .macro  usr_ret, reg
> #ifdef CONFIG_ARM_THUMB
> #ifdef CONFIG_CPU_32v4
> 	tst     \reg, #3
> 	moveq   pc, \reg
> #endif
>         bx      \reg
> #else
> 	mov	pc, \reg
> #endif
> 	.endm
> 
> for some reason does the wrong thing running on ARMv4 (fa526) with non-thumb
> user space when both CONFIG_CPU_32v4 and CONFIG_ARM_THUMB are enabled:
> it still tries to do the 'bx' and triggers an invalid opcode exception.

I assume this has been discussed in off-list (maybe on some irc channel
somewhere), because there's nothing on-list apart from these emails...

So, let's repeat the debugging which probably has already occured, but
this time on-list...

It would be useful to see the register state from the undefined
instruction exception.  That needs this patch, CONFIG_DEBUG_USER in the
kernel config enabled, and user_debug=1 passed on the kernel command
line.

diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 172ee18ff124..abd2fc067736 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -445,6 +445,7 @@ asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
 	if (user_debug & UDBG_UNDEFINED) {
 		printk(KERN_INFO "%s (%d): undefined instruction: pc=%p\n",
 			current->comm, task_pid_nr(current), pc);
+		__show_regs(regs);
 		dump_instr(KERN_INFO, regs);
 	}
 #endif


-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option

[Jonas Jensen]

On 9 April 2014 18:01, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> It would be useful to see the register state from the undefined
> instruction exception.  That needs this patch, CONFIG_DEBUG_USER in the
> kernel config enabled, and user_debug=1 passed on the kernel command
> line.

I have done two tests, one with user_debug=1, and one with
user_debug=31, since I expected more information on user_debug=1.

As Arnd pointed out, this is booting into a non-thumb userspace, built
with gcc version 4.9.0 20140316 and buildroot 2014.02.

Buildroot config:
https://code.google.com/p/mkrom-uc7112lx/source/browse/configs/buildroot-2014-02_eglibc-2.17_binutils-2.22_external-toolchain.config

Results:

user_debug=1 ( https://bitbucket.org/Kasreyn/linux-next/commits/3a32b929d7a399751c6397f0c973b356c6c9a71d
):

    Uncompressing Linux... done, booting the kernel.
    [    0.000000] Booting Linux on physical CPU 0x0
    [    0.000000] Linux version 3.14.0-next-20140409+ (i@Ildjarn)
(gcc version 4.9.0 20140316 (experimental) (crosstool-NG 1.19.0) )
#2431 PREEMPT Thu Apr 10 09:12:35 CEST 2014
..
    [    0.000000] Kernel command line: console=ttyS0,115200n8
earlyprintk root=/dev/mmcblk0p1 rw rootwait debug user_debug=1
..
    [    2.700000] Freeing unused kernel memory: 104K (c02f4000 - c030e000)
    [    3.380000] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
    [    3.380000]
    [    3.380000] CPU: 0 PID: 1 Comm: init Not tainted
3.14.0-next-20140409+ #2431
    [    3.380000] [<c000d4e0>] (unwind_backtrace) from [<c000bcbc>]
(show_stack+0x10/0x14)
    [    3.380000] [<c000bcbc>] (show_stack) from [<c0268f74>]
(panic+0x98/0x1f4)
    [    3.380000] [<c0268f74>] (panic) from [<c0016bcc>] (do_exit+0x908/0x938)
    [    3.380000] [<c0016bcc>] (do_exit) from [<c0016c70>]
(do_group_exit+0x4c/0xe8)
    [    3.380000] [<c0016c70>] (do_group_exit) from [<c0022098>]
(get_signal_to_deliver+0x218/0x5f0)
    [    3.380000] [<c0022098>] (get_signal_to_deliver) from
[<c000b358>] (do_signal+0x100/0x48c)
    [    3.380000] [<c000b358>] (do_signal) from [<c000b8ac>]
(do_work_pending+0xd4/0xe4)
    [    3.380000] [<c000b8ac>] (do_work_pending) from [<c000933c>]
(work_pending+0xc/0x20)
    [    3.380000] Rebooting in 10 seconds..

user_debug=31 (
https://bitbucket.org/Kasreyn/linux-next/commits/8ed2db951baca29c6254de328765873fe5457727
):

    [    0.000000] Booting Linux on physical CPU 0x0
    [    0.000000] Linux version 3.14.0-next-20140409+ (i@Ildjarn)
(gcc version 4.9.0 20140316 (experimental) (crosstool-NG 1.19.0) )
#2431 PREEMPT Thu Apr 10 09:12:35 CEST 2014
    [    0.000000] CPU: FA526 [66015261] revision 1 (ARMv4), cr=0000397f
    [    0.000000] CPU: VIVT data cache, VIVT instruction cache
    [    0.000000] Machine model: MOXA UC-7112-LX
    [    0.000000] bootconsole [earlycon0] enabled
    [    0.000000] Memory policy: Data cache writeback
    [    0.000000] On node 0 totalpages: 8192
    [    0.000000] free_area_init_node: node 0, pgdat c0322324,
node_mem_map c1fba000
    [    0.000000]   Normal zone: 64 pages used for memmap
    [    0.000000]   Normal zone: 0 pages reserved
    [    0.000000]   Normal zone: 8192 pages, LIFO batch:0
    [    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
    [    0.000000] pcpu-alloc: [0] 0
    [    0.000000] Built 1 zonelists in Zone order, mobility grouping
on.  Total pages: 8128
    [    0.000000] Kernel command line: console=ttyS0,115200n8
earlyprintk root=/dev/mmcblk0p1 rw rootwait debug user_debug=31
    [    0.000000] PID hash table entries: 128 (order: -3, 512 bytes)
    [    0.000000] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
    [    0.000000] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
    [    0.000000] Memory: 29092K/32768K available (2542K kernel code,
74K rwdata, 448K rodata, 104K init, 116K bss, 3676K reserved)
    [    0.000000] Virtual kernel memory layout:
    [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    [    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    [    0.000000]     vmalloc : 0xc2800000 - 0xff000000   ( 968 MB)
    [    0.000000]     lowmem  : 0xc0000000 - 0xc2000000   (  32 MB)
    [    0.000000]       .text : 0xc0008000 - 0xc02f3d80   (2992 kB)
    [    0.000000]       .init : 0xc02f4000 - 0xc030e36c   ( 105 kB)
    [    0.000000]       .data : 0xc0310000 - 0xc0322aa0   (  75 kB)
    [    0.000000]        .bss : 0xc0322aac - 0xc033fbc0   ( 117 kB)
    [    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
    [    0.000000] Preemptible hierarchical RCU implementation.
    [    0.000000] NR_IRQS:16 nr_irqs:16 16
    [    0.000000] sched_clock: 32 bits at 100 Hz, resolution
10000000ns, wraps every 21474836480000000ns
    [    0.010000] Calibrating delay loop... 146.84 BogoMIPS (lpj=734208)
    [    0.100000] pid_max: default: 4096 minimum: 301
    [    0.100000] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
    [    0.110000] Mountpoint-cache hash table entries: 1024 (order:
0, 4096 bytes)
    [    0.120000] CPU: Testing write buffer coherency: ok
    [    0.130000] Setting up static identity map for 0x26e308 - 0x26e390
    [    0.150000] devtmpfs: initialized
    [    0.160000] NET: Registered protocol family 16
    [    0.180000] DMA: preallocated 256 KiB pool for atomic coherent
allocations
    [    0.330000] Switched to clocksource moxart_timer
    [    0.370000] NET: Registered protocol family 2
    [    0.390000] TCP established hash table entries: 1024 (order: 0,
4096 bytes)
    [    0.410000] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
    [    0.410000] TCP: Hash tables configured (established 1024 bind 1024)
    [    0.430000] TCP: reno registered
    [    0.430000] UDP hash table entries: 256 (order: 0, 4096 bytes)
    [    0.450000] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
    [    0.470000] NET: Registered protocol family 1
    [    0.490000] futex hash table entries: 16 (order: -5, 192 bytes)
    [    0.590000] jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
    [    0.610000] msgmni has been set to 56
    [    0.610000] io scheduler noop registered
    [    0.640000] io scheduler cfq registered (default)
    [    0.640000] gpiochip_add: registered GPIOs 0 to 31 on device: moxart-gpio
    [    0.660000] Serial: 8250/16550 driver, 3 ports, IRQ sharing enabled
    [    0.690000] console [ttyS0] disabled
    [    0.690000] 98200000.uart: ttyS0 at MMIO 0x98200000 (irq = 21,
base_baud = 921600) is a 16550A
    [    0.700000] console [ttyS0] enabled
    [    0.700000] console [ttyS0] enabled
    [    0.710000] bootconsole [earlycon0] disabled
    [    0.710000] bootconsole [earlycon0] disabled
    [    0.720000] MOXA Smartio/Industio family driver version 2.0.5
    [    0.730000] mxser: found MOXA UC-7112-LX board (CAP=0x0)
    [    0.740000] ttyMX0 at I/O 0xf9820040 (irq = 21, base_baud = 0)
is a 16550A
    [    0.750000] ttyMX1 at I/O 0xf9820060 (irq = 21, base_baud = 0)
is a 16550A
    [    0.760000] mxser: mxser_initbrd success IRQ=21 max baud=921600 bps
    [    0.820000] loop: module loaded
    [    0.860000] 80000000.flash: Found 1 x16 devices at 0x0 in
16-bit bank. Manufacturer ID 0x000089 Chip ID 0x000018
    [    0.870000] Intel/Sharp Extended Query Table at 0x0031
    [    0.880000] Intel/Sharp Extended Query Table at 0x0031
    [    0.890000] Using buffer write method
    [    0.890000] cfi_cmdset_0001: Erase suspend on write enabled
    [    0.900000] erase region 0: offset=0x0,size=0x20000,blocks=128
    [    0.900000] 4 ofpart partitions found on MTD device 80000000.flash
    [    0.910000] Creating 4 MTD partitions on "80000000.flash":
    [    0.910000] 0x000000000000-0x000000040000 : "bootloader"
    [    0.930000] 0x000000040000-0x000000200000 : "linux kernel"
    [    0.950000] 0x000000200000-0x000000a00000 : "root filesystem"
    [    0.970000] 0x000000a00000-0x000001000000 : "user filesystem"
    [    1.600000] libphy: MOXA ART Ethernet MII: probed
    [    2.220000] libphy: MOXA ART Ethernet MII: probed
    [    2.260000] moxart-ethernet 90900000.ethernet eth0:
moxart_mac_probe: IRQ=19 address=00:00:00:00:00:00
    [    2.270000] moxart-ethernet 90900000.ethernet eth0: generated
random MAC address a6:07:0d:68:31:c4
    [    2.280000] moxart-ethernet 92000000.ethernet eth1:
moxart_mac_probe: IRQ=20 address=00:00:00:00:00:00
    [    2.300000] moxart-ethernet 92000000.ethernet eth1: generated
random MAC address 5a:e7:48:87:f5:5e
    [    2.310000] of_get_named_gpiod_flags exited with status 0
    [    2.320000] input: gpio_keys_polled.2 as
/devices/gpio_keys_polled.2/input/input0
    [    2.330000] evbug: Connected device: input0 (gpio_keys_polled.2
at gpio-keys-polled/input0)
    [    2.340000] of_get_named_gpiod_flags exited with status 0
    [    2.350000] of_get_named_gpiod_flags exited with status 0
    [    2.350000] of_get_named_gpiod_flags exited with status 0
    [    2.360000] moxart-rtc rtc.0: rtc core: registered rtc.0 as rtc0
    [    2.380000] of_get_named_gpiod_flags: can't parse gpios
property of node '/soc/mmc@98e00000[0]'
    [    2.390000] of_get_named_gpiod_flags: can't parse gpios
property of node '/soc/mmc@98e00000[0]'
    [    2.450000] of_get_named_gpiod_flags exited with status 0
    [    2.450000] of_get_named_gpiod_flags exited with status 0
    [    2.460000] TCP: cubic registered
    [    2.470000] NET: Registered protocol family 17
    [    2.490000] console [netcon0] enabled
    [    2.490000] netconsole: network logging started
    [    2.500000] moxart-rtc rtc.0: setting system clock to
2014-04-10 07:16:34 UTC (1397114194)
    [    2.510000] Waiting for root device /dev/mmcblk0p1...
    [    2.520000] mmc0: new SDHC card at address 0fd0
    [    2.530000] mmcblk0: mmc0:0fd0 SD04G 3.69 GiB
    [    2.550000]  mmcblk0: p1
    [    2.650000] kjournald starting.  Commit interval 5 seconds
    [    2.650000] EXT3-fs (mmcblk0p1): warning: maximal mount count
reached, running e2fsck is recommended
    [    2.680000] EXT3-fs (mmcblk0p1): using internal journal
    [    2.680000] EXT3-fs (mmcblk0p1): recovery complete
    [    2.690000] EXT3-fs (mmcblk0p1): mounted filesystem with
ordered data mode
    [    2.690000] VFS: Mounted root (ext3 filesystem) on device 179:1.
    [    2.710000] devtmpfs: mounted
    [    2.720000] Freeing unused kernel memory: 104K (c02f4000 - c030e000)
    [    3.390000] init: unhandled page fault (11) at 0xffff1007, code 0x01f
    [    3.400000] pgd = c1a24000
    [    3.400000] [ffff1007] *pgd=01ffd831, *pte=01fff0cf, *ppte=01fff00e
    [    3.400000]
    [    3.410000] CPU: 0 PID: 1 Comm: init Not tainted
3.14.0-next-20140409+ #2431
    [    3.420000] task: c1828000 ti: c182c000 task.ti: c182c000
    [    3.420000] PC is at 0xb6df2478
    [    3.430000] LR is at 0x1c
    [    3.430000] pc : [<b6df2478>]    lr : [<0000001c>]    psr: 60000010
    [    3.430000] sp : bee48eb8  ip : bee48fe0  fp : 00000000
    [    3.440000] r10: 00000000  r9 : b6f34958  r8 : bee48f1c
    [    3.450000] r7 : bee48f14  r6 : bee48f1c  r5 : 00000001  r4 : b6f08000
    [    3.460000] r3 : 00000008  r2 : bee48fd4  r1 : 00115c40  r0 : ffff0fff
    [    3.470000] Flags: nZCv  IRQs on  FIQs on  Mode USER_32  ISA
ARM  Segment user
    [    3.480000] Control: 0000397f  Table: 01a24000  DAC: 00000015
    [    3.490000] CPU: 0 PID: 1 Comm: init Not tainted
3.14.0-next-20140409+ #2431
    [    3.500000] [<c000d4e0>] (unwind_backtrace) from [<c000bcbc>]
(show_stack+0x10/0x14)
    [    3.510000] [<c000bcbc>] (show_stack) from [<c000eb64>]
(__do_user_fault+0xbc/0xc8)
    [    3.520000] [<c000eb64>] (__do_user_fault) from [<c000edd4>]
(do_page_fault+0x264/0x29c)
    [    3.530000] [<c000edd4>] (do_page_fault) from [<c0008444>]
(do_DataAbort+0x34/0x98)
    [    3.540000] [<c0008444>] (do_DataAbort) from [<c000c9a4>]
(__dabt_usr+0x44/0x60)
    [    3.550000] Exception stack(0xc182dfb0 to 0xc182dff8)
    [    3.550000] dfa0:                                     ffff0fff
00115c40 bee48fd4 00000008
    [    3.560000] dfc0: b6f08000 00000001 bee48f1c bee48f14 bee48f1c
b6f34958 00000000 00000000
    [    3.570000] dfe0: bee48fe0 bee48eb8 0000001c b6df2478 60000010 ffffffff
    [    3.580000] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
    [    3.580000]
    [    3.580000] CPU: 0 PID: 1 Comm: init Not tainted
3.14.0-next-20140409+ #2431
    [    3.580000] [<c000d4e0>] (unwind_backtrace) from [<c000bcbc>]
(show_stack+0x10/0x14)
    [    3.580000] [<c000bcbc>] (show_stack) from [<c0268f74>]
(panic+0x98/0x1f4)
    [    3.580000] [<c0268f74>] (panic) from [<c0016bcc>] (do_exit+0x908/0x938)
    [    3.580000] [<c0016bcc>] (do_exit) from [<c0016c70>]
(do_group_exit+0x4c/0xe8)
    [    3.580000] [<c0016c70>] (do_group_exit) from [<c0022098>]
(get_signal_to_deliver+0x218/0x5f0)
    [    3.580000] [<c0022098>] (get_signal_to_deliver) from
[<c000b358>] (do_signal+0x100/0x48c)
    [    3.580000] [<c000b358>] (do_signal) from [<c000b8ac>]
(do_work_pending+0xd4/0xe4)
    [    3.580000] [<c000b8ac>] (do_work_pending) from [<c000933c>]
(work_pending+0xc/0x20)
    [    3.580000] Rebooting in 10 seconds..

    defconfig:
    # CONFIG_LOCALVERSION_AUTO is not set
    CONFIG_SYSVIPC=y
    # CONFIG_USELIB is not set
    CONFIG_NO_HZ_IDLE=y
    CONFIG_IKCONFIG=y
    CONFIG_IKCONFIG_PROC=y
    CONFIG_LOG_BUF_SHIFT=16
    # CONFIG_UID16 is not set
    # CONFIG_ELF_CORE is not set
    # CONFIG_BASE_FULL is not set
    # CONFIG_EVENTFD is not set
    # CONFIG_AIO is not set
    CONFIG_EMBEDDED=y
    # CONFIG_VM_EVENT_COUNTERS is not set
    # CONFIG_SLUB_DEBUG is not set
    # CONFIG_COMPAT_BRK is not set
    # CONFIG_LBDAF is not set
    # CONFIG_BLK_DEV_BSG is not set
    # CONFIG_IOSCHED_DEADLINE is not set
    CONFIG_ARCH_MULTI_V4=y
    CONFIG_ARCH_MULTI_V4T=y
    # CONFIG_ARCH_MULTI_V7 is not set
    CONFIG_ARCH_MOXART=y
    CONFIG_MACH_UC7112LX=y
    CONFIG_PREEMPT=y
    CONFIG_AEABI=y
    # CONFIG_CROSS_MEMORY_ATTACH is not set
    # CONFIG_ATAGS is not set
    CONFIG_ARM_APPENDED_DTB=y
    CONFIG_NET=y
    CONFIG_PACKET=y
    CONFIG_UNIX=y
    CONFIG_INET=y
    CONFIG_IP_MULTICAST=y
    CONFIG_IP_PNP=y
    CONFIG_IP_PNP_DHCP=y
    # CONFIG_INET_XFRM_MODE_TRANSPORT is not set
    # CONFIG_INET_XFRM_MODE_TUNNEL is not set
    # CONFIG_INET_XFRM_MODE_BEET is not set
    # CONFIG_INET_LRO is not set
    # CONFIG_INET_DIAG is not set
    # CONFIG_IPV6 is not set
    # CONFIG_WIRELESS is not set
    CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
    CONFIG_DEVTMPFS=y
    CONFIG_DEVTMPFS_MOUNT=y
    # CONFIG_PREVENT_FIRMWARE_BUILD is not set
    # CONFIG_FW_LOADER is not set
    CONFIG_MTD=y
    CONFIG_MTD_BLOCK=y
    CONFIG_MTD_CFI=y
    CONFIG_MTD_CFI_ADV_OPTIONS=y
    CONFIG_MTD_CFI_GEOMETRY=y
    CONFIG_MTD_CFI_INTELEXT=y
    CONFIG_MTD_COMPLEX_MAPPINGS=y
    CONFIG_MTD_PHYSMAP=y
    CONFIG_MTD_PHYSMAP_OF=y
    CONFIG_BLK_DEV_LOOP=y
    CONFIG_NETDEVICES=y
    CONFIG_NETCONSOLE=y
    CONFIG_NETCONSOLE_DYNAMIC=y
    # CONFIG_NET_VENDOR_ARC is not set
    # CONFIG_NET_CADENCE is not set
    # CONFIG_NET_VENDOR_BROADCOM is not set
    # CONFIG_NET_VENDOR_CIRRUS is not set
    # CONFIG_NET_VENDOR_FARADAY is not set
    # CONFIG_NET_VENDOR_INTEL is not set
    # CONFIG_NET_VENDOR_MARVELL is not set
    # CONFIG_NET_VENDOR_MICREL is not set
    CONFIG_ARM_MOXART_ETHER=y
    # CONFIG_NET_VENDOR_NATSEMI is not set
    # CONFIG_NET_VENDOR_SEEQ is not set
    # CONFIG_NET_VENDOR_SMSC is not set
    # CONFIG_NET_VENDOR_STMICRO is not set
    # CONFIG_NET_VENDOR_VIA is not set
    # CONFIG_NET_VENDOR_WIZNET is not set
    CONFIG_REALTEK_PHY=y
    CONFIG_MDIO_MOXART=y
    # CONFIG_WLAN is not set
    # CONFIG_INPUT_MOUSEDEV is not set
    CONFIG_INPUT_EVDEV=y
    CONFIG_INPUT_EVBUG=y
    # CONFIG_KEYBOARD_ATKBD is not set
    CONFIG_KEYBOARD_GPIO_POLLED=y
    # CONFIG_INPUT_MOUSE is not set
    # CONFIG_SERIO is not set
    # CONFIG_VT is not set
    # CONFIG_LEGACY_PTYS is not set
    CONFIG_MOXA_SMARTIO=y
    # CONFIG_DEVKMEM is not set
    CONFIG_SERIAL_8250=y
    CONFIG_SERIAL_8250_CONSOLE=y
    CONFIG_SERIAL_8250_NR_UARTS=3
    CONFIG_SERIAL_8250_RUNTIME_UARTS=3
    CONFIG_SERIAL_8250_EXTENDED=y
    CONFIG_SERIAL_8250_SHARE_IRQ=y
    CONFIG_SERIAL_OF_PLATFORM=y
    # CONFIG_HW_RANDOM is not set
    CONFIG_DEBUG_GPIO=y
    CONFIG_GPIO_SYSFS=y
    CONFIG_GPIO_MOXART=y
    # CONFIG_HWMON is not set
    CONFIG_WATCHDOG=y
    CONFIG_WATCHDOG_CORE=y
    CONFIG_WATCHDOG_NOWAYOUT=y
    CONFIG_MOXART_WDT=y
    # CONFIG_USB_SUPPORT is not set
    CONFIG_MMC=y
    CONFIG_MMC_MOXART=y
    CONFIG_NEW_LEDS=y
    CONFIG_LEDS_CLASS=y
    CONFIG_LEDS_GPIO=y
    CONFIG_LEDS_TRIGGERS=y
    CONFIG_LEDS_TRIGGER_TIMER=y
    CONFIG_LEDS_TRIGGER_ONESHOT=y
    CONFIG_LEDS_TRIGGER_HEARTBEAT=y
    CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
    CONFIG_RTC_CLASS=y
    CONFIG_RTC_DRV_MOXART=y
    CONFIG_DMADEVICES=y
    CONFIG_MOXART_DMA=y
    # CONFIG_IOMMU_SUPPORT is not set
    CONFIG_MCB=y
    CONFIG_EXT3_FS=y
    CONFIG_TMPFS=y
    CONFIG_CONFIGFS_FS=y
    CONFIG_JFFS2_FS=y
    # CONFIG_NETWORK_FILESYSTEMS is not set
    CONFIG_PRINTK_TIME=y
    CONFIG_DEBUG_INFO=y
    # CONFIG_ENABLE_WARN_DEPRECATED is not set
    # CONFIG_ENABLE_MUST_CHECK is not set
    CONFIG_MAGIC_SYSRQ=y
    CONFIG_PANIC_ON_OOPS=y
    CONFIG_PANIC_TIMEOUT=10
    # CONFIG_SCHED_DEBUG is not set
    # CONFIG_DEBUG_PREEMPT is not set
    # CONFIG_FTRACE is not set
    CONFIG_DEBUG_USER=y
    CONFIG_DEBUG_LL=y
    CONFIG_DEBUG_LL_UART_8250=y
    CONFIG_DEBUG_UART_PHYS=0x98200000
    CONFIG_DEBUG_UART_VIRT=0xf9820000
    CONFIG_EARLY_PRINTK=y
    # CONFIG_CRYPTO_ANSI_CPRNG is not set
    # CONFIG_CRYPTO_HW is not set
    CONFIG_CRC32_BIT=y


Regards,
Jonas