|
|
|
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]
![]() |
![]() |