On Wed, 18 Nov 2009 01:39 +0100, "Florian Fainelli" <florian@xxxxxxxxxxx> wrote: > Hi, > > Le mercredi 18 novembre 2009 01:31:33, myuboot@xxxxxxxxxxx a écrit : > > On Tue, 17 Nov 2009 13:54 -0800, "Chris Dearman" <chris@xxxxxxxx> wrote: > > > Kevin D. Kissell wrote: > > > > This looks like another boot file system setup problem to me. Are you > > > > sure that there's an executable init image at /mnt/root/sbin/init? I'm > > > > pretty sure that the path that you provide to your new init has to be > > > > relative to the new root. > > > > > > That sounds right. > > > > > > Andrew, my suggestion would be to change your initramfs /init script to > > > invoke "/bin/busybox sh" as the last command instead of "exec > > > switch_root". The "Kernel panic - not syncing: Attempted to kill init!" > > > says that switch_root is exiting for some reason. It could be anything > > > from missing files/devices on the /mnt/root file system to a bug in > > > busy_box. > > > By booting into the shell you can run the command by hand (maybe with > > > strace if you have it) to help identify where the problem is. > > > > > > Chris > > > > Chris, > > > > Thanks for your response. Now I changed my init file to the following - > > #!/bin/busybox sh > > mount -t proc proc /proc > > mount -t sysfs sysfs /sys > > mdev -s > > /bin/busybox sh > > > > The Kernel panic is gone but the shell still does not come up. Somehow > > there is no printout on the screen. Below is the error info. > > I have tried similar things previously. I also tried using a statically > > linked hello world in the place of init script. But the result is > > similar - no print out from either hello world or busybox. > > [ 1.169000] TCP cubic registered > > [ 1.173000] NET: Registered protocol family 17 > > [ 15.811000] Freeing unused kernel memory: 1032k freed > > [ 33.978000] Algorithmics/MIPS FPU Emulator v1.5 > > > > And here is the trace on BDI - > > gdb) c > > Continuing. > > > > Breakpoint 2, do_execve (filename=0x9780a000 "/init", argv=0x943dd2bc, > > envp=0x943dd230, regs=0x97819e30) > > at fs/exec.c:1293 > > 1293 retval = unshare_files(&displaced); > > (gdb) c > > Continuing. > > > > Breakpoint 2, do_execve (filename=0x9780a000 "/bin/busybox", > > argv=0x4f73dc, envp=0x4f73ec, regs=0x97987f30) > > at fs/exec.c:1293 > > 1293 retval = unshare_files(&displaced); > > (gdb) c > > Continuing. > > ^C > > Program received signal SIGSTOP, Stopped (signal). > > r4k_wait () at arch/mips/kernel/genex.S:147 > > 147 jr ra > > Current language: auto; currently asm > > > > Let me provide some history about what I am trying to do here in case it > > is relevant to the issue. I have a MIPS32 board very similar to AR7. > > Previously it has working toolchain/u-boot/kernel. I changed the board > > from little endian to big endian mode and have been trying to upgrade > > the toolchain/u-boot/kernel (gcc 4.4.1/u-boot2009.08/kernel 2.6.31). I > > made some changes to the u-boot and kernel on console initialisation in > > order to bring up the console. Up to the point, the kernel comes up > > normally. > > > > Since the time I start porting, I have been wondering if any change > > related to exception needs to be done due to the endianess change. But > > recently I found an AR7 patch for big endian mode( > > https://lists.openwrt.org/pipermail/openwrt-devel/2009-May/004262.html) > > and I did not see any change related to exception there. I hope the > > issue is not something related to exception that messes up the > > execution. Sorry if the above is a stupid question. I am trying to learn > > embedded system. Your suggestion will be appreciated. > > If your board is similar to AR7, then you might need the following patch > which > allows you to cope with the different physical offsets on AR7: > http://www.linux-mips.org/archives/linux-mips/2009-06/msg00004.html > -- > Best regards, Florian Fainelli > Email: florian@xxxxxxxxxxx > Web: http://openwrt.org > IRC: [florian] on irc.freenode.net > ------------------------------- Actually I already got this patch for the board in little endian mode, and it is still there for the big endian mode. And this is one of the place I have been wondering if that needs to be changed for big endian. thanks. Andrew
