[Clfs-support] Oops booting a working kernel cross-compiled with CLFS cross-toolchain [SOLVED]

Fri Apr 8 02:34:15 PDT 2011

Hi again forum.

I have built a buildroot-based toolchain with the same package versions used
in CLFS book, to compile my custom kernel (2.6.30.4)

binutils-2.21
gcc-4.5.2
uClibc-0.9.31

The kernel image generated with that toolchain also generated the Oops
message reported yesterday building with CLFS toolchain. So, it was
obviously not related with any missing CLFS patch...

I tryied again a buildroot-based toolchain, but setting up with older
version of gcc/binutils/uClibc packages. Just to test, I selected:

binutils-2.20
gcc-4.2.4
uClibc-0.9.30

And surprisingly (at least for me), the image of that kernel works fine, it
does not generate any Oops message. It seems that not every version of gcc
can build a working linux kernel. I'm curious to know why both
cross-compilers generate a kernel image fine, but only one of the generated
images runs fine on my platform. Does that have some sense to you?

Thank you in advance!!
Best regards,
  -- Ivan

2011/4/7 Angel Ivan Castell Rovira <al004140 at gmail.com>

>
> Hello forum!
>
> I just have build my own uClibc EABI toolchain for my ARMv4t, based on the
> CLFS book. All the userspace libs/bins I have built, seem to compile fine.
> The CLFS setup used was this:
>
> CLFS_HOST=i486-cross-linux-gnu
> CLFS_TARGET=armv4-linux-uclibceabi
> CLFS_FPU=
> CLFS_ARM_ARCH=armv4t
> CLFS_ARM_MODE=arm
> CLFS_ARCH=arm
> CLFS_ABI=aapcs-linux
> CLFS_ENDIAN=little
> CLFS_FLOAT=soft
>
> Now I was trying to cross-compile my running kernel sources with that CLFS
> cross-compiler built from scratch. My kernel is a customized version for my
> board, but I know this kernel runs fine on my ARM target, because I have
> tested it cross-compiling with a different toolchain.
>
> I though building my kernel sources with the CLFS EABI cross-compiler, I
> should also build a working kernel. But it doesn't work at all.
>
> The kernel cross-compiled fine, following the steps:
>
>     $ make ARCH=${CLFS_ARCH} CROSS_COMPILE=${CLFS_TARGET}- mrproper
>     $ make ARCH=${CLFS_ARCH} CROSS_COMPILE=${CLFS_TARGET}- distclean
> # 'cp' my .config here
>     $ make ARCH=${CLFS_ARCH} CROSS_COMPILE=${CLFS_TARGET}- menuconfig
>     $ make ARCH=${CLFS_ARCH} CROSS_COMPILE=${CLFS_TARGET}- make
>
> Once installed on the flash, I boot the system from the u-boot as usual.
> The kernel uncompresses, initializes all the subsystems, and even mounts the
> rootfs fine. But after "freeying init memory", I suppose almost ready to
> start the init process (a busybox applet), it hangs with an Oops with number
> "817".
>
> I checked my .config is properly configured with the following flags
> enabled:
>
>     CONFIG_AEABI=y
>     CONFIG_OABI_COMPAT=y
>
> I installed the sanitized headers of my running kernel when building my own
> CLFS toolchain (It is a kernel 2.6.30.4, so I suppose that should not
> matter, or it could be?).
>
> Hope you can give some advise to discover the problem based on your own
> experience.
>
> Thank you very much!!
> Best regards,
>   -- Ivan
>
>
> This is the kernel crash, hope it can be helpful:
>
> VFS: Mounted root (yaffs2 filesystem) on device 31:2.
> Freeing init memory: 112K
> Unable to handle kernel paging request at virtual address 00100104
> pgd = c3a24000
> [00100104] *pgd=339ea031, *pte=00000000, *ppte=00000000
> Internal error: Oops: 817 [#1]
> Modules linked in:
> CPU: 0    Not tainted  (2.6.30.4 #1)
> PC is at rmqueue_bulk.clone.39+0x54/0x7c
> LR is at __rmqueue+0x20/0x238
> pc : [<c006562c>]    lr : [<c00653c0>]    psr: 80000093
> sp : c381d9f0  ip : c03b7764  fp : c381da14
> r10: 00000013  r9 : c039ce20  r8 : 00000002
> r7 : 00000002  r6 : c03b773c  r5 : 00000003  r4 : c03f5338
> r3 : c03f5338  r2 : 00100100  r1 : 00000000  r0 : c03f5320
> Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
> Control: c000717f  Table: 33a24000  DAC: 00000015
> Process init (pid: 1, stack limit = 0xc381c268)
> Stack: (0xc381d9f0 to 0xc381e000)
> [...
> a bunch of stack addresses
> ...]
> Backtrace:
> [<c00655d8>] (rmqueue_bulk.clone.39+0x0/0x7c) from [<c006580c>]
> (get_page_from_)
>  r8:60000013 r7:00000001 r6:c03b773c r5:c03b775c r4:00000002
> r3:00000002
> [<c0065654>] (get_page_from_freelist+0x0/0x41c) from [<c0065b18>]
> (__alloc_page)
> [<c0065a70>] (__alloc_pages_internal+0x0/0x424) from [<c00681b4>]
> (__do_page_ca)
> [<c00680d0>] (__do_page_cache_readahead+0x0/0x27c) from [<c0068894>]
> (do_page_c)
> [<c006882c>] (do_page_cache_readahead+0x0/0x7c) from [<c00606ac>]
> (filemap_faul)
>  r7:c38d51b8 r6:c039ce20 r5:00000000 r4:c38d6380
> [<c0060380>] (filemap_fault+0x0/0x3d4) from [<c0071f4c>]
> (__do_fault+0x58/0x3d4)
> [<c0071ef4>] (__do_fault+0x0/0x3d4) from [<c00745f8>]
> (handle_mm_fault+0xf8/0xa)
> [<c0074500>] (handle_mm_fault+0x0/0xa8c) from [<c002b734>]
> (do_page_fault+0x1a0)
> [<c002b594>] (do_page_fault+0x0/0x268) from [<c002b8fc>]
> (do_translation_fault+)
> [<c002b888>] (do_translation_fault+0x0/0x7c) from [<c00241e4>]
> (do_DataAbort+0x)
>  r6:c381ddf0 r5:4000d008 r4:00000805 r3:00000005
> [<c00241b0>] (do_DataAbort+0x0/0x9c) from [<c00249c0>]
> (__dabt_svc+0x40/0x60)
> Exception stack(0xc381ddf0 to 0xc381de38)
> dde0:                                     4000d008 00000ff0 00000000
> 8100dfff
> de00: c38d6300 c39ca000 00000000 c381df50 c381c000 c38d6380 40000000
> c381de4c
> de20: 00000000 c381de38 c00b81f8 c0132f10 20000013
> ffffffff
>  r8:c381c000 r7:c381df50 r6:00000000 r5:c381de24 r4:ffffffff
> [<c00b81a4>] (padzero+0x0/0x60) from [<c00b90d0>]
> (load_elf_binary+0xb0c/0x11e8)
> [<c00b85c4>] (load_elf_binary+0x0/0x11e8) from [<c00890d8>]
> (search_binary_hand)
> [<c0089024>] (search_binary_handler+0x0/0x250) from [<c008a220>]
> (do_execve+0x2)
> [<c008a00c>] (do_execve+0x0/0x290) from [<c0028260>]
> (kernel_execve+0x40/0x8c)
> [<c0028220>] (kernel_execve+0x0/0x8c) from [<c0024284>]
> (run_init_process+0x1c/)
>  r7:00000000 r6:00000000 r5:c001d36c r4:c03b7d20
> [<c0024268>] (run_init_process+0x0/0x24) from [<c0024314>]
> (init_post+0x88/0x10)
> [<c002428c>] (init_post+0x0/0x10c) from [<c00089c8>]
> (kernel_init+0xc0/0xe8)
>  r4:c03b7d20 r3:c3401080
> [<c0008908>] (kernel_init+0x0/0xe8) from [<c0039dc8>] (do_exit+0x0/0x638)
>  r5:00000000 r4:00000000
> Code: 0a000008 e5942000 e2877001 e1570005 (e5823004)
> ---[ end trace 219da93bf697758d ]---
> Kernel panic - not syncing: Attempted to kill init!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clfs.org/pipermail/clfs-support-clfs.org/attachments/20110408/61730119/attachment.html>