Re: KEXEC on the Freescale MX31

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


This seems to be part of a bigger problem with i.MX31 cpu's.
We build a custom board based on the freescale ADS. The kernel boots but
hangs after "booting the kernel". We also traced the problematic code to
some lines in linux/arch/arm/kernel/head-common.S but haven't found a
solution yet.

Maarten


2008/10/17 Dave Kroetsch <dave@xxxxxxxxxx>

> Hi All,
>
> Wondering if anyone has had any experience running kexec on the arm cpu in
> the
> Freescale MX31?   My setup is:
>
>        Kernel: 2.6.22
>        Board:  LogicPD MX31 Litekit
>
> First kernel boots and runs great.  I'm using the kexec-tools 1.101 to load
> the kernel.  To start I'm using the kernel that booted successfully the
> first
> time round and trying to kexec it.
>
> I've done a fair amount of debugging and I have isolated the problem.
>        - kexec relocation code works fine
>        - the cpu resets to that address and begins running the new zImage
>                - the zImage is loaded to 0x8100000
>        - the zImage decompression code seems to work without a problem
>                - decompresses the kernel to 0x80008000
>                - this is the same location that the first kernel uses
>        - the decompressed image beings running the kernel startup code:
>                linux/arch/arm/kernel/head.S
>                - using some GPIO LED debugging I can see that it gets
>                  all the way through to __turn_mmu_on and then jumps
>                  correctly to __switch_data
>        - code in __switch_data (linux/arch/arm/kernel/head-common.S) starts
>          running, but something in here goes wrong, because the code
>          never gets to start_kernel( ) (from linux/init/main.c)
>
> The spot in which it dies is only like 10 lines of assembler.  It looks
> like
> it's as simple as copying the data segment and zeroing some static
> variables
> and then branching to the start_kernel( ) function.
>
> My fear is that something is going wacky with the mmu and so things are
> hanging.  Does any one have any ideas on how I can try to track down this
> problem further?  I can't upgrade to the latest version of the kernel, but
> I've looked at the kexec code in the latest kernel tree, and there are no
> changes.  Any ideas on what in the mmu might look different from the first
> time booting that's causing this problem?
>
> Any help/suggestions would be appreciated.
>
> Thanks,
>        Dave
>
> -------------------------------------------------------------------
> List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
> FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
> Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php
>
-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php

[Linux ARM]     [Linux ARM MSM]     [Linux ARM Kernel]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

Add to Google Follow linuxarm on Twitter