Hi,
On Wed Jul 09, 2014 at 01:23:52 +0300, Uwe Geuder wrote:
I'm pretty new to L4 so I hope this is not an FAQ. I tried to search the forum archives but couldn't find an answer.
I'm using L4 on an i.MX6 device. Building fiasco, L4Re and L4Linux succeeded without any errors as far as I can tell. A small ramdisk containing busybox works fine and I can play around on the command line. (The system actually has framebuffer support, so I can even get something on the screen.)
Now I replaced the small "demo" ramdisk by one containing a bigger distro. This bigger ramdisk runs without problems on a native Linux kernel.
However, on L4Linux I always get
RAMDISK: ext2 filesystem found at block 0 RAMDISK: Loading 262144KiB [1 disk] into ram disk... EXT4-fs (ram0): couldn't mount as ext3 due to feature incompatibilities EXT4-fs (ram0): couldn't mount as ext2 due to feature incompatibilities EXT4-fs (ram0): mounted filesystem with ordered data mode. Opts: (null) VFS: Mounted root (ext4 filesystem) readonly on device 1:0. Freeing unused kernel memory: 116K (022f9000 - 02316000) Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
CPU: 0 PID: 1 Comm: sh Not tainted 3.14.0-l4 #7 [<0200c47c>] (unwind_backtrace) from [<02005618>] (show_stack+0x10/0x14) [<02005618>] (show_stack) from [<02238d08>] (panic+0x8c/0x1c8) [<02238d08>] (panic) from [<020186bc>] (complete_and_exit+0x0/0x1c) [<020186bc>] (complete_and_exit) from [<00000001>] (0x1) panic: going to sleep forever, bye l4linux | panic: going to sleep forever, bye
The stack trace is the same for init=/bin/sh and the default systemd. Looks like for some reason user space processes in this setup just crash pretty soon.
The console log before that looks pretty unsuspicious to me. But I can of course post it should it be necessary to understand what is going on.
What comes to my mind is that my user space is built for armv7tnhl, i. e. thumb instruction set, NEON, and hard-float.
-march=armv7-a -mfloat-abi=hard -mfpu=neon -mthumb
Can any of these options be a problem under L4?
(The small busybox ramdisk, which works fine was built by a colleague of mine who is on holidays at the moment. I'm not sure how he built it, but I assume it's neither hard-float nor thumb. Well, I could disassemble something to be sure I guess...)
If armv7tnhl does not cause obvious problems, do you have any debugging hints/pointers how to find out why/where pid 1 is crashing? Address 0x1 is nonsense I suppose, but if tells anything then that the processor is in thumb mode. Which is what I would expect from my user space.
None of those points should be any problem. Are all enabled? CONFIG_VFP=y CONFIG_VFPv3=y CONFIG_NEON=y CONFIG_ARM_THUMB=y
You can also add "print-fatal-signals=1" to get to know the actual address that faulted.
Adam