Re: 2.6.31 kernel for mips compile failure - war.h:12:17: error: war.h: No such file or directory

[David Daney-4]

mips-linux questions will get more attention if you send them to
linux-mips@....


myuboot@... wrote:
> I am trying to use buildroot 2009.08 to compile kernel 2.6.31 for mips,
> but it fails to error -" war.h can't be found". I used the same
> buildroot to build kernel version 2.6.29 with no problem.
>
> Please give me some suggestion on how to fix this issue. The file
> ./arch/mips/include/asm/war.h is there with no problem. Thanks a lot.
>
[...]
>   CC      arch/mips/kernel/asm-offsets.s
> In file included from
> /home/root123/sources/buildroot-2009.08-k/project_build_mips/f1/linux-2.6.31/arch/mips/include/asm/bitops.h:24,
>                  from include/linux/bitops.h:17,
>                  from include/linux/kernel.h:15,
>                  from include/linux/sched.h:52,
>                  from arch/mips/kernel/asm-offsets.c:13:

What does your .config look like?

Also try make V=1 so we can see the exact compiler command line that the
build process is generating.

David Daney

[myuboot]

Thanks. This issue is fixed now. In 2.6.31 the directory
include/asm-mips  is moved as arch/mips/include/asm/. I need to change
my Makefile accordingly.

On Fri, 16 Oct 2009 16:50 -0700, "David Daney"
<ddaney@...> wrote:

> mips-linux questions will get more attention if you send them to
> linux-mips@....
>
>
> myuboot@... wrote:
> > I am trying to use buildroot 2009.08 to compile kernel 2.6.31 for mips,
> > but it fails to error -" war.h can't be found". I used the same
> > buildroot to build kernel version 2.6.29 with no problem.
> >
> > Please give me some suggestion on how to fix this issue. The file
> > ./arch/mips/include/asm/war.h is there with no problem. Thanks a lot.
> >
> [...]
> >   CC      arch/mips/kernel/asm-offsets.s
> > In file included from
> > /home/root123/sources/buildroot-2009.08-k/project_build_mips/f1/linux-2.6.31/arch/mips/include/asm/bitops.h:24,
> >                  from include/linux/bitops.h:17,
> >                  from include/linux/kernel.h:15,
> >                  from include/linux/sched.h:52,
> >                  from arch/mips/kernel/asm-offsets.c:13:
>
> What does your .config look like?
>
> Also try make V=1 so we can see the exact compiler command line that the
> build process is generating.
>
> David Daney

[myuboot]

I am trying to bringup a MIPS32 board using 2.6.31. It is working in
little endian mode. After changing the board's hardware from little
endian to bit endian, the serial port print messed up. It prints now
something like - "àààààààààààààààà" on the screen. When I trace the
execution, I can see the string the kernel is trying print is correct -
"Linux version 2.6.31 ..." and etc.

I guess it means the initialization of the serial port is not properly
done. But I am not sure where I should check for the problem. The serial
port device I am using is 8250. Please give me some advise.

Thanks.

[Florian Fainelli-4]

Hi,

Le mardi 20 octobre 2009 01:56:04, myuboot@... a écrit :

> I am trying to bringup a MIPS32 board using 2.6.31. It is working in
> little endian mode. After changing the board's hardware from little
> endian to bit endian, the serial port print messed up. It prints now
> something like - "àààààààààààààààà" on the screen. When I trace the
> execution, I can see the string the kernel is trying print is correct -
> "Linux version 2.6.31 ..." and etc.
>
> I guess it means the initialization of the serial port is not properly
> done. But I am not sure where I should check for the problem. The serial
> port device I am using is 8250. Please give me some advise.

If the same initialization routine used to work in little-endian, check how
you actually write and read characters from the UART FIFO and especially if
your hardware requires you to do word or byte access to these registers.

You can have a look at AR7, which has the same code working for Little and Big
Endian modes in arch/mips/ar7/prom.c lines 272 to the end of the file. It also
uses a 8250-compatible UART.

[myuboot]

I happen to use the same code from ar7. So this part
serial_int/serial_out should be fine?

#define PORT(offset) (KSEG1ADDR(MY_MIPSBOARD_REGS_UART0 + (offset * 4)))
static inline unsigned int serial_in(int offset)
{
        return readl((void *)PORT(offset));
}

static inline void serial_out(int offset, int value)
{
        writel(value, (void *)PORT(offset));
}

Thanks.



On Tue, 20 Oct 2009 08:17 +0200, "Florian Fainelli"
<florian@...> wrote:

> Hi,
>
> Le mardi 20 octobre 2009 01:56:04, myuboot@... a écrit :
> > I am trying to bringup a MIPS32 board using 2.6.31. It is working in
> > little endian mode. After changing the board's hardware from little
> > endian to bit endian, the serial port print messed up. It prints now
> > something like - "àààààààààààààààà" on the screen. When I trace the
> > execution, I can see the string the kernel is trying print is correct -
> > "Linux version 2.6.31 ..." and etc.
> >
> > I guess it means the initialization of the serial port is not properly
> > done. But I am not sure where I should check for the problem. The serial
> > port device I am using is 8250. Please give me some advise.
>
> If the same initialization routine used to work in little-endian, check
> how
> you actually write and read characters from the UART FIFO and especially
> if
> your hardware requires you to do word or byte access to these registers.
>
> You can have a look at AR7, which has the same code working for Little
> and Big
> Endian modes in arch/mips/ar7/prom.c lines 272 to the end of the file. It
> also
> uses a 8250-compatible UART.

[myuboot]

Thanks, Florian. I found the cause of the problem. My board is 32 bit
based, so each serial port register is 32bit even only 8 bit is used. So
when the board is switched endianess, I need to change the address
offset to access the same registers.
For example, original RHR register address is 0x8001000 with little
endian mode. With big endian, I need to access it as 0x8001003.

On Tue, 20 Oct 2009 08:17 +0200, "Florian Fainelli"
<florian@...> wrote:

> Hi,
>
> Le mardi 20 octobre 2009 01:56:04, myuboot@... a écrit :
> > I am trying to bringup a MIPS32 board using 2.6.31. It is working in
> > little endian mode. After changing the board's hardware from little
> > endian to bit endian, the serial port print messed up. It prints now
> > something like - "àààààààààààààààà" on the screen. When I trace the
> > execution, I can see the string the kernel is trying print is correct -
> > "Linux version 2.6.31 ..." and etc.
> >
> > I guess it means the initialization of the serial port is not properly
> > done. But I am not sure where I should check for the problem. The serial
> > port device I am using is 8250. Please give me some advise.
>
> If the same initialization routine used to work in little-endian, check
> how
> you actually write and read characters from the UART FIFO and especially
> if
> your hardware requires you to do word or byte access to these registers.
>
> You can have a look at AR7, which has the same code working for Little
> and Big
> Endian modes in arch/mips/ar7/prom.c lines 272 to the end of the file. It
> also
> uses a 8250-compatible UART.

[Shmulik Ladkani-2]

On Tue, 27 Oct 2009 15:40:13 -0500 myuboot@... wrote:
> Thanks, Florian. I found the cause of the problem. My board is 32 bit
> based, so each serial port register is 32bit even only 8 bit is used. So
> when the board is switched endianess, I need to change the address
> offset to access the same registers.
> For example, original RHR register address is 0x8001000 with little
> endian mode. With big endian, I need to access it as 0x8001003.

I assume your uart_port's iotype is defined as UPIO_MEM32.
UPIO_MEM32 makes 8250 access serial registers using readl/writel (which might
be a problem for big-endian), while UPIO_MEM makes 8250 access the registers
using readb/writeb.
Maybe you should try UPIO_MEM (assuming hardware allows byte access).

--
Shmulik Ladkani Jungo Ltd.

[Sergei Shtylyov-2]

Hello.

Shmulik Ladkani wrote:

>> Thanks, Florian. I found the cause of the problem. My board is 32 bit
>> based, so each serial port register is 32bit even only 8 bit is used. So
>> when the board is switched endianess, I need to change the address
>> offset to access the same registers.
>> For example, original RHR register address is 0x8001000 with little
>> endian mode. With big endian, I need to access it as 0x8001003.
>>    
>
> I assume your uart_port's iotype is defined as UPIO_MEM32.
>  

   He wouldn't have to add 3 to the register addresses then.

> UPIO_MEM32 makes 8250 access serial registers using readl/writel (which might
> be a problem for big-endian), while UPIO_MEM makes 8250 access the registers
> using readb/writeb.
>  

   Both may be a problem for big endian.

> Maybe you should try UPIO_MEM (assuming hardware allows byte access).

   Contrarywise, I think he now has UPIO_MEM and needs to try UPIO_MEM32.

WBR, Sergei

[myuboot]

Sergei, Shmulik,

Thanks a lot for your suggestions. I was using UPIO_MEM since I was not
aware of the difference between UPIO_MEM and UPIO_MEM32.

I just tried UPIO_MEM32 without adding a offset of 3. But the result is
bad - after the kernel initializes the serial console, the console print
out messes up. The early printk is fine because the u-boot initialises
the serial port fine.

How I tried UPIO_MEM32 is in platform.c changing the iotype to
UPIO_MEM32 in the uart_port structure and passing the structure to
early_serial_setup. What I did is  the same as in
arch/mips/ar7/platform.c.

In 8250.c I removed the offset I added to mem_serial_out and
mem_serial_in.
Did I miss anything? Thanks again for your help.

On Wed, 28 Oct 2009 14:04 +0300, "Sergei Shtylyov"
<sshtylyov@...> wrote:

> Hello.
>
> Shmulik Ladkani wrote:
>
> >> Thanks, Florian. I found the cause of the problem. My board is 32 bit
> >> based, so each serial port register is 32bit even only 8 bit is used. So
> >> when the board is switched endianess, I need to change the address
> >> offset to access the same registers.
> >> For example, original RHR register address is 0x8001000 with little
> >> endian mode. With big endian, I need to access it as 0x8001003.
> >>    
> >
> > I assume your uart_port's iotype is defined as UPIO_MEM32.
> >  
>
>    He wouldn't have to add 3 to the register addresses then.
>
> > UPIO_MEM32 makes 8250 access serial registers using readl/writel (which might
> > be a problem for big-endian), while UPIO_MEM makes 8250 access the registers
> > using readb/writeb.
> >  
>
>    Both may be a problem for big endian.
>
> > Maybe you should try UPIO_MEM (assuming hardware allows byte access).
>
>    Contrarywise, I think he now has UPIO_MEM and needs to try UPIO_MEM32.
>
> WBR, Sergei
>
>

[Shmulik Ladkani-2]

On Wed, 28 Oct 2009 14:36:15 -0500 myuboot@... wrote:
> I just tried UPIO_MEM32 without adding a offset of 3. But the result is
> bad - after the kernel initializes the serial console, the console print
> out messes up. The early printk is fine because the u-boot initialises
> the serial port fine.
>
> Did I miss anything? Thanks again for your help.

I guess you did fine with UPIO_MEM32.

Keeping the UPIO_MEM32 approach, I suggest also to fiddle Y/N with
CONFIG_SWAP_IO_SPACE (might be that you have it set to Y while you don't
really need it, or vice versa).
This is since 'readl' uses 'ioswabl' for (potential) byte-swapping of the read
value. Take a look at asm/io.h and mangle-port.h.

Most important, read your hardware documentation to determine correct access
to the memory mapped serial registers.

--
Shmulik Ladkani Jungo Ltd.

[myuboot]

The CONFIG_SWAP_IO_SPACE was set to Y, but I don't even see it using
xconfig or menuconfig. So I set it manually to n into .config file and
then did a compile - I am using buildroot. But somehow the value always
comes back to y after I type in command "make". The kernel image still
messes up the console after the console is handovered from early printk
to really ttyS01.

Thanks.

On Thu, 29 Oct 2009 10:26 +0200, "Shmulik Ladkani"
<jungoshmulik@...> wrote:

> On Wed, 28 Oct 2009 14:36:15 -0500 myuboot@... wrote:
> > I just tried UPIO_MEM32 without adding a offset of 3. But the result is
> > bad - after the kernel initializes the serial console, the console print
> > out messes up. The early printk is fine because the u-boot initialises
> > the serial port fine.
> >
> > Did I miss anything? Thanks again for your help.
>
> I guess you did fine with UPIO_MEM32.
>
> Keeping the UPIO_MEM32 approach, I suggest also to fiddle Y/N with
> CONFIG_SWAP_IO_SPACE (might be that you have it set to Y while you don't
> really need it, or vice versa).
> This is since 'readl' uses 'ioswabl' for (potential) byte-swapping of the
> read
> value. Take a look at asm/io.h and mangle-port.h.
>
> Most important, read your hardware documentation to determine correct
> access
> to the memory mapped serial registers.
>
> --
> Shmulik Ladkani         Jungo Ltd.

[myuboot]

Hi,

I got the following error trying to bring up the /sbin/init with Kernel
2.6.31 using cramfs filesystem on a MIPS 32 board:

[    1.160000] VFS: Mounted root (cramfs filesystem) readonly on device
31:2.
[    1.171000] Freeing unused kernel memory: 116k freed
[    1.223000] Kernel panic - not syncing: Attempted to kill init!
[    1.229000] Rebooting in 3 seconds..

Using BDI I know the kernel panic happens as soon as
run_init_process("/sbin/init") in init_post() is called. The filesystem
itself seems to be ok, because I can use 'ls' command under u-boot to
see /sbin/init is a symbolic link to busybox. Also the kernel seems to
like the filesystem and can mount the filesystem.  I have for checked
for similar questions for this error, so I tried replacing /sbin/init
with a hello world program, but the result is exactly the same. It seems
neither hello-world or /sbin/init got executed.

At this point, I don't know how to debug this issue. Any suggestion on
how to debug this issue will be greatly appreciated.

Andrew

[myuboot]

On Wed, 11 Nov 2009 08:45 +0100, "Gaye Abdoulaye Walsimou"
<walsimou@...> wrote:

> myuboot@... wrote:
> > Hi,
> >
> > I got the following error trying to bring up the /sbin/init with Kernel
> > 2.6.31 using cramfs filesystem on a MIPS 32 board:
> >  
>
> Just to be sure does:
> $file vmlinux
> $file busybox
> give the same result?
>
> Regards

The file result looks ok. The readelf result looks fine too.

file linux-2.6.31/vmlinux root/bin/busybox
linux-2.6.31/vmlinux: ELF 32-bit MSB executable, MIPS, MIPS32 version 1
(SYSV), statically linked, not stripped
root/bin/busybox:     setuid ELF 32-bit MSB executable, MIPS, MIPS32
version 1 (SYSV), dynamically linked (uses shared libs), stripped

Thanks, Andrew

[myuboot]

I have been struggling to bring up a MIPS 32 board with busybox with or
without initramfs.
The kernel stucks there without the shell coming up.

[    1.153000] nf_conntrack version 0.5.0 (1024 buckets, 4096 max)
[    1.161000] ip_tables: (C) 2000-2006 Netfilter Core Team
[    1.167000] TCP cubic registered
[    1.170000] NET: Registered protocol family 17
[   25.971000] Freeing unused kernel memory: 1032k freed
[   39.969000] Algorithmics/MIPS FPU Emulator v1.5


What I tried here is to use initramfs with statically linked busybox.
The initramfs seems to be up, and runs the commands in the /init one by
one, and then it goes to a inifite loop in r4k_wait at
arch/mips/kernel/genex.S.

The following is the execution sequense when it runs /init. Can anyone
give me some idea what is wrong?

Thanks, Andrew


Breakpoint 2, do_execve (filename=0x9780a000 "/bin/sh", argv=0x4f73a4,
envp=0x4f73ac, regs=0x97997f30) at fs/exec.c:1293
1293            retval = unshare_files(&displaced);
(gdb) c
Continuing.

Breakpoint 2, do_execve (filename=0x9780a000 "/sbin/switch_root",
argv=0x4f7450, envp=0x4f7464, regs=0x97819f30) at fs/exec.c:1293
1293            retval = unshare_files(&displaced);
(gdb) c
Continuing.

Breakpoint 2, do_execve (filename=0x9780a000 "/usr/sbin/switch_root",
argv=0x4f7450, envp=0x4f7464, regs=0x97819f30) at fs/exec.c:1293
1293            retval = unshare_files(&displaced);
(gdb) c
Continuing.

Breakpoint 2, do_execve (filename=0x9780a000 "/bin/switch_root",
argv=0x4f7450, envp=0x4f7464, regs=0x97819f30) at fs/exec.c:1293
1293            retval = unshare_files(&displaced);
(gdb) c
Continuing.

Breakpoint 2, do_execve (filename=0x9780a000 "/usr/bin/switch_root",
argv=0x4f7450, envp=0x4f7464, regs=0x97819f30) 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

-- And here is the content of /init script -
#!/bin/busybox sh

# Mount the /proc and /sys filesystems.
mount -t proc none /proc
mount -t sysfs none /sys

mdev -s
/bin/sh

# Do your stuff here.
echo "This script mounts rootfs and boots it up, nothing more!"

# Mount the root filesystem.
mount -o ro /dev/mtdblock4 /mnt/root

# Clean up.
umount /proc
umount /sys

# Boot the real thing.
exec switch_root /mnt/root /sbin/init

[Ralf Baechle DL5RB]

On Mon, Nov 16, 2009 at 06:21:21PM -0600, myuboot@... wrote:

> I have been struggling to bring up a MIPS 32 board with busybox with or
> without initramfs.
> The kernel stucks there without the shell coming up.
>
> [    1.153000] nf_conntrack version 0.5.0 (1024 buckets, 4096 max)
> [    1.161000] ip_tables: (C) 2000-2006 Netfilter Core Team
> [    1.167000] TCP cubic registered
> [    1.170000] NET: Registered protocol family 17
> [   25.971000] Freeing unused kernel memory: 1032k freed
> [   39.969000] Algorithmics/MIPS FPU Emulator v1.5
>
>
> What I tried here is to use initramfs with statically linked busybox.
> The initramfs seems to be up, and runs the commands in the /init one by
> one, and then it goes to a inifite loop in r4k_wait at
> arch/mips/kernel/genex.S.

r4k_wait is called by the idle loop.  Which means the kernel has no process
to run so runs the idle loop.  This might be because there is no other
process left running or because all processes are waiting for I/O for
example.  So it's not uncommon that even busy systems ocasionally briefly
run the idle loop.  In other words, seeing the processor executing
r4k_wait does not necessarily mean something went wrong.  In this case -
also along with the other information you've provieded it's not obvious
what has gone wrong.

  Ralf

[myuboot]

On Tue, 17 Nov 2009 10:33 +0100, "Ralf Baechle" <ralf@...>
wrote:

> On Mon, Nov 16, 2009 at 06:21:21PM -0600, myuboot@... wrote:
>
> > I have been struggling to bring up a MIPS 32 board with busybox with or
> > without initramfs.
> > The kernel stucks there without the shell coming up.
> >
> > [    1.153000] nf_conntrack version 0.5.0 (1024 buckets, 4096 max)
> > [    1.161000] ip_tables: (C) 2000-2006 Netfilter Core Team
> > [    1.167000] TCP cubic registered
> > [    1.170000] NET: Registered protocol family 17
> > [   25.971000] Freeing unused kernel memory: 1032k freed
> > [   39.969000] Algorithmics/MIPS FPU Emulator v1.5
> >
> >
> > What I tried here is to use initramfs with statically linked busybox.
> > The initramfs seems to be up, and runs the commands in the /init one by
> > one, and then it goes to a inifite loop in r4k_wait at
> > arch/mips/kernel/genex.S.
>
> r4k_wait is called by the idle loop.  Which means the kernel has no
> process
> to run so runs the idle loop.  This might be because there is no other
> process left running or because all processes are waiting for I/O for
> example.  So it's not uncommon that even busy systems ocasionally briefly
> run the idle loop.  In other words, seeing the processor executing
> r4k_wait does not necessarily mean something went wrong.  In this case -
> also along with the other information you've provieded it's not obvious
> what has gone wrong.
>
>   Ralf

According to an email from Kevin, I added a symbolic link from
switch_root to busybox. The switch_root seems to be found now based on
the execution sequence, but I got the following error - "Kernel panic -
not syncing: Attempted to kill init!". This is the same error when I
tried to start the shell without initramfs. Something must be wrong, but
I can't quite figure out.

[    9.250000] Freeing unused kernel memory: 1032k freed
[   10.463000] Algorithmics/MIPS FPU Emulator v1.5
[   41.695000] Kernel panic - not syncing: Attempted to kill init!
[   41.701000] Rebooting in 3 seconds.

Thanks for your help. Andrew

(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 "/sbin/switch_root",
argv=0x4f7450, envp=0x4f7464, regs=0x97819f30)
    at fs/exec.c:1293
1293            retval = unshare_files(&displaced);
(gdb) c
Continuing.

[Florian Fainelli-4]

Hi,

On Tuesday 17 November 2009 18:39:40 myuboot@... wrote:

> On Tue, 17 Nov 2009 10:33 +0100, "Ralf Baechle" <ralf@...>
>
> wrote:
> > On Mon, Nov 16, 2009 at 06:21:21PM -0600, myuboot@... wrote:
> > > I have been struggling to bring up a MIPS 32 board with busybox with or
> > > without initramfs.
> > > The kernel stucks there without the shell coming up.
> > >
> > > [    1.153000] nf_conntrack version 0.5.0 (1024 buckets, 4096 max)
> > > [    1.161000] ip_tables: (C) 2000-2006 Netfilter Core Team
> > > [    1.167000] TCP cubic registered
> > > [    1.170000] NET: Registered protocol family 17
> > > [   25.971000] Freeing unused kernel memory: 1032k freed
> > > [   39.969000] Algorithmics/MIPS FPU Emulator v1.5
> > >
> > >
> > > What I tried here is to use initramfs with statically linked busybox.
> > > The initramfs seems to be up, and runs the commands in the /init one by
> > > one, and then it goes to a inifite loop in r4k_wait at
> > > arch/mips/kernel/genex.S.
> >
> > r4k_wait is called by the idle loop.  Which means the kernel has no
> > process
> > to run so runs the idle loop.  This might be because there is no other
> > process left running or because all processes are waiting for I/O for
> > example.  So it's not uncommon that even busy systems ocasionally briefly
> > run the idle loop.  In other words, seeing the processor executing
> > r4k_wait does not necessarily mean something went wrong.  In this case -
> > also along with the other information you've provieded it's not obvious
> > what has gone wrong.
> >
> >   Ralf
>
> According to an email from Kevin, I added a symbolic link from
> switch_root to busybox. The switch_root seems to be found now based on
> the execution sequence, but I got the following error - "Kernel panic -
> not syncing: Attempted to kill init!". This is the same error when I
> tried to start the shell without initramfs. Something must be wrong, but
> I can't quite figure out.
>
> [    9.250000] Freeing unused kernel memory: 1032k freed
> [   10.463000] Algorithmics/MIPS FPU Emulator v1.5
> [   41.695000] Kernel panic - not syncing: Attempted to kill init!
> [   41.701000] Rebooting in 3 seconds.
>
> Thanks for your help. Andrew
>
> (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 "/sbin/switch_root",
> argv=0x4f7450, envp=0x4f7464, regs=0x97819f30)
>     at fs/exec.c:1293
> 1293            retval = unshare_files(&displaced);
> (gdb) c
> Continuing.

If you happen to use uClibc and gcc-4.4.0 or superior, make sure that you have
that patch applied to uClibc: http://www.mail-
archive.com/uclibc@.../msg04483.html
--
WBR, Florian

[Kevin D. Kissell-2]

myuboot@... wrote:

On Tue, 17 Nov 2009 10:33 +0100, "Ralf Baechle" ralf@...
wrote:
  

On Mon, Nov 16, 2009 at 06:21:21PM -0600, myuboot@... wrote:

    

I have been struggling to bring up a MIPS 32 board with busybox with or
without initramfs.
The kernel stucks there without the shell coming up.

[    1.153000] nf_conntrack version 0.5.0 (1024 buckets, 4096 max)
[    1.161000] ip_tables: (C) 2000-2006 Netfilter Core Team
[    1.167000] TCP cubic registered
[    1.170000] NET: Registered protocol family 17
[   25.971000] Freeing unused kernel memory: 1032k freed
[   39.969000] Algorithmics/MIPS FPU Emulator v1.5


What I tried here is to use initramfs with statically linked busybox.
The initramfs seems to be up, and runs the commands in the /init one by
one, and then it goes to a inifite loop in r4k_wait at
arch/mips/kernel/genex.S.
      

r4k_wait is called by the idle loop.  Which means the kernel has no
process
to run so runs the idle loop.  This might be because there is no other
process left running or because all processes are waiting for I/O for
example.  So it's not uncommon that even busy systems ocasionally briefly
run the idle loop.  In other words, seeing the processor executing
r4k_wait does not necessarily mean something went wrong.  In this case -
also along with the other information you've provieded it's not obvious
what has gone wrong.

  Ralf
    

According to an email from Kevin, I added a symbolic link from
switch_root to busybox. The switch_root seems to be found now based on
the execution sequence, but I got the following error - "Kernel panic -
not syncing: Attempted to kill init!". This is the same error when I
tried to start the shell without initramfs. Something must be wrong, but
I can't quite figure out.

[    9.250000] Freeing unused kernel memory: 1032k freed
[   10.463000] Algorithmics/MIPS FPU Emulator v1.5
[   41.695000] Kernel panic - not syncing: Attempted to kill init!
[   41.701000] Rebooting in 3 seconds.

Thanks for your help. Andrew

(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 "/sbin/switch_root",
argv=0x4f7450, envp=0x4f7464, regs=0x97819f30)
    at fs/exec.c:1293
1293            retval = unshare_files(&displaced);
(gdb) c
Continuing.

  

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.

Kevin K.

[myuboot]

On Tue, 17 Nov 2009 18:48 +0100, "Florian Fainelli"
<florian@...> wrote:

> Hi,
>
> On Tuesday 17 November 2009 18:39:40 myuboot@... wrote:
> > On Tue, 17 Nov 2009 10:33 +0100, "Ralf Baechle" <ralf@...>
> >
> > wrote:
> > > On Mon, Nov 16, 2009 at 06:21:21PM -0600, myuboot@... wrote:
> > > > I have been struggling to bring up a MIPS 32 board with busybox with or
> > > > without initramfs.
> > > > The kernel stucks there without the shell coming up.
> > > >
> > > > [    1.153000] nf_conntrack version 0.5.0 (1024 buckets, 4096 max)
> > > > [    1.161000] ip_tables: (C) 2000-2006 Netfilter Core Team
> > > > [    1.167000] TCP cubic registered
> > > > [    1.170000] NET: Registered protocol family 17
> > > > [   25.971000] Freeing unused kernel memory: 1032k freed
> > > > [   39.969000] Algorithmics/MIPS FPU Emulator v1.5
> > > >
> > > >
> > > > What I tried here is to use initramfs with statically linked busybox.
> > > > The initramfs seems to be up, and runs the commands in the /init one by
> > > > one, and then it goes to a inifite loop in r4k_wait at
> > > > arch/mips/kernel/genex.S.
> > >
> > > r4k_wait is called by the idle loop.  Which means the kernel has no
> > > process
> > > to run so runs the idle loop.  This might be because there is no other
> > > process left running or because all processes are waiting for I/O for
> > > example.  So it's not uncommon that even busy systems ocasionally briefly
> > > run the idle loop.  In other words, seeing the processor executing
> > > r4k_wait does not necessarily mean something went wrong.  In this case -
> > > also along with the other information you've provieded it's not obvious
> > > what has gone wrong.
> > >
> > >   Ralf
> >
> > According to an email from Kevin, I added a symbolic link from
> > switch_root to busybox. The switch_root seems to be found now based on
> > the execution sequence, but I got the following error - "Kernel panic -
> > not syncing: Attempted to kill init!". This is the same error when I
> > tried to start the shell without initramfs. Something must be wrong, but
> > I can't quite figure out.
> >
> > [    9.250000] Freeing unused kernel memory: 1032k freed
> > [   10.463000] Algorithmics/MIPS FPU Emulator v1.5
> > [   41.695000] Kernel panic - not syncing: Attempted to kill init!
> > [   41.701000] Rebooting in 3 seconds.
> >
> > Thanks for your help. Andrew
> >
> > (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 "/sbin/switch_root",
> > argv=0x4f7450, envp=0x4f7464, regs=0x97819f30)
> >     at fs/exec.c:1293
> > 1293            retval = unshare_files(&displaced);
> > (gdb) c
> > Continuing.
>
> If you happen to use uClibc and gcc-4.4.0 or superior, make sure that you
> have
> that patch applied to uClibc: http://www.mail-
> archive.com/uclibc@.../msg04483.html
> --
> WBR, Florian

Yes, I am using uClibc and gcc-4.4.1. So I went ahead and applied the
patch on
./toolchain_build_mips/uClibc-0.9.30.1/libc/sysdeps/linux/mips/bits/syscalls.h.
After that I touched ./toolchain_build_mips/uClibc-0.9.30.1/.configured
and rerun make. But the result is the same - "Kernel panic - not
syncing: Attempted to kill init!". Any of your suggestions will be
welcome. I have tried various things such as changes in init script or
using hello_world as the init, but the result is very similar. Thanks a
lot. Andrew

Breakpoint 1, init_post () at init/main.c:839
839             async_synchronize_full();
(gdb) enable 2
(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 "/sbin/busybox",
argv=0x4f7478, envp=0x4f748c, regs=0x97819f30)
    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

[Chris Dearman-2]

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 Dearman               Desk: [phone]  Cell: [phone]
MIPS Technologies Inc            955 East Arques Ave, Sunnyvale CA 94085