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

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

[David Daney]

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


myuboot@fastmail.fm 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

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

[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@caviumnetworks.com> wrote:
> mips-linux questions will get more attention if you send them to 
> linux-mips@linux-mips.org.
> 
> 
> myuboot@fastmail.fm 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

serial port 8250 messed up after coverting from little endian to big endian on kernel 2.6.31

[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. 

Re: serial port 8250 messed up after coverting from little endian to big endian on kernel 2.6.31

[Florian Fainelli]

[-- Attachment #1: Type: Text/Plain, Size: 1116 bytes --]

Hi,

Le mardi 20 octobre 2009 01:56:04, myuboot@fastmail.fm 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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: serial port 8250 messed up after coverting from little endian to big endian on kernel 2.6.31

[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@openwrt.org> wrote:
> Hi,
> 
> Le mardi 20 octobre 2009 01:56:04, myuboot@fastmail.fm 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.

Re: serial port 8250 messed up after coverting from little endian to big endian on kernel 2.6.31

[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@openwrt.org> wrote:
> Hi,
> 
> Le mardi 20 octobre 2009 01:56:04, myuboot@fastmail.fm 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.

Re: serial port 8250 messed up after coverting from little endian to big endian on kernel 2.6.31

[Shmulik Ladkani]

On Tue, 27 Oct 2009 15:40:13 -0500 myuboot@fastmail.fm 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.

Re: serial port 8250 messed up after coverting from little endian to big endian on kernel 2.6.31

[Sergei Shtylyov]

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

Re: serial port 8250 messed up after coverting from little endian to big endian on kernel 2.6.31

[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@ru.mvista.com> 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
> 
> 

Re: serial port 8250 messed up after coverting from little endian to big endian on kernel 2.6.31

[Shmulik Ladkani]

On Wed, 28 Oct 2009 14:36:15 -0500 myuboot@fastmail.fm 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.

Re: serial port 8250 messed up after coverting from little endian to big endian on kernel 2.6.31

[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@gmail.com> wrote:
> On Wed, 28 Oct 2009 14:36:15 -0500 myuboot@fastmail.fm 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.

PIR OFFSET for AR7

[myuboot]

Hi, What is the use of PIR register for AR7 board in file
arch/mips/ar7/irq.c? If I understand it right, PIR is used to define the
polarity of the interrupts. It seems to me that it needs to initialized?

Best regards, Andrew

Re: PIR OFFSET for AR7

[Thomas Bogendoerfer]

On Thu, Dec 03, 2009 at 07:52:30PM -0600, myuboot@fastmail.fm wrote:
> Hi, What is the use of PIR register for AR7 board in file
> arch/mips/ar7/irq.c?

it gives back the channel and line of the pending interrupt with the
highest priority.

> If I understand it right, PIR is used to define the
> polarity of the interrupts. It seems to me that it needs to initialized?

no, it's a read only register. Why do you think it has something to do
with interrupt polarity ?

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                                [ RFC1925, 2.3 ]

Re: PIR OFFSET for AR7

[myuboot]

Thomas,

Sorry, you are right. I mistook PM_OFFSET for PIR_OFFSET.

Thanks, Andrew
On Fri, 04 Dec 2009 17:03 +0100, "Thomas Bogendoerfer"
<tsbogend@alpha.franken.de> wrote:
> On Thu, Dec 03, 2009 at 07:52:30PM -0600, myuboot@fastmail.fm wrote:
> > Hi, What is the use of PIR register for AR7 board in file
> > arch/mips/ar7/irq.c?
> 
> it gives back the channel and line of the pending interrupt with the
> highest priority.
> 
> > If I understand it right, PIR is used to define the
> > polarity of the interrupts. It seems to me that it needs to initialized?
> 
> no, it's a read only register. Why do you think it has something to do
> with interrupt polarity ?
> 
> Thomas.
> 
> -- 
> Crap can work. Given enough thrust pigs will fly, but it's not necessary
> a
> good idea.                                                [ RFC1925, 2.3
> ]

Kernel panic - not syncing: Attempted to kill init!

[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

Re: Kernel panic - not syncing: Attempted to kill init!

[myuboot]

On Wed, 11 Nov 2009 08:45 +0100, "Gaye Abdoulaye Walsimou"
<walsimou@walsimou.com> wrote:
> myuboot@fastmail.fm 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

problem bring up initramfs and busybox

[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

Re: problem bring up initramfs and busybox

[Ralf Baechle]

On Mon, Nov 16, 2009 at 06:21:21PM -0600, myuboot@fastmail.fm 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

Re: problem bring up initramfs and busybox

[myuboot]

On Tue, 17 Nov 2009 10:33 +0100, "Ralf Baechle" <ralf@linux-mips.org>
wrote:
> On Mon, Nov 16, 2009 at 06:21:21PM -0600, myuboot@fastmail.fm 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.

Re: problem bring up initramfs and busybox

[Florian Fainelli]

Hi,

On Tuesday 17 November 2009 18:39:40 myuboot@fastmail.fm wrote:
> On Tue, 17 Nov 2009 10:33 +0100, "Ralf Baechle" <ralf@linux-mips.org>
> 
> wrote:
> > On Mon, Nov 16, 2009 at 06:21:21PM -0600, myuboot@fastmail.fm 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@uclibc.org/msg04483.html
--
WBR, Florian

Re: problem bring up initramfs and busybox

[myuboot]

On Tue, 17 Nov 2009 18:48 +0100, "Florian Fainelli"
<florian@openwrt.org> wrote:
> Hi,
> 
> On Tuesday 17 November 2009 18:39:40 myuboot@fastmail.fm wrote:
> > On Tue, 17 Nov 2009 10:33 +0100, "Ralf Baechle" <ralf@linux-mips.org>
> > 
> > wrote:
> > > On Mon, Nov 16, 2009 at 06:21:21PM -0600, myuboot@fastmail.fm 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@uclibc.org/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

Re: problem bring up initramfs and busybox

[Kevin D. Kissell]

[-- Attachment #1: Type: text/html, Size: 3514 bytes --]

Re: problem bring up initramfs and busybox

[Chris Dearman]

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: +1 408 530 5092  Cell: +1 408 398 5531
MIPS Technologies Inc            955 East Arques Ave, Sunnyvale CA 94085

Re: problem bring up initramfs and busybox

[myuboot]

On Tue, 17 Nov 2009 13:54 -0800, "Chris Dearman" <chris@mips.com> 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 Dearman               Desk: +1 408 530 5092  Cell: +1 408 398 5531
> MIPS Technologies Inc            955 East Arques Ave, Sunnyvale CA 94085

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.

Thanks, Andrew

Re: problem bring up initramfs and busybox

[Florian Fainelli]

Hi,

Le mercredi 18 novembre 2009 01:31:33, myuboot@fastmail.fm a écrit :
> On Tue, 17 Nov 2009 13:54 -0800, "Chris Dearman" <chris@mips.com> 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@openwrt.org
Web: http://openwrt.org
IRC: [florian] on irc.freenode.net
-------------------------------

Re: problem bring up initramfs and busybox

[myuboot]

On Wed, 18 Nov 2009 01:39 +0100, "Florian Fainelli"
<florian@openwrt.org> wrote:
> Hi,
> 
> Le mercredi 18 novembre 2009 01:31:33, myuboot@fastmail.fm a écrit :
> > On Tue, 17 Nov 2009 13:54 -0800, "Chris Dearman" <chris@mips.com> 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@openwrt.org
> 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

Re: problem bring up initramfs and busybox

[David VomLehn]

On Tue, Nov 17, 2009 at 06:58:35PM -0600, myuboot@fastmail.fm wrote:
> 
> On Wed, 18 Nov 2009 01:39 +0100, "Florian Fainelli"
> <florian@openwrt.org> wrote:
> > -------------------------------
> 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. 

It sounds like you've done a good job getting the bootloader and kernel
to work, so this may be a silly suggestion, but are you sure your root
filesystem and busybox are little-endian? It would be an easy mistake to
make...

> thanks. Andrew

David VL

Re: problem bring up initramfs and busybox

[myuboot]

On Tue, 17 Nov 2009 20:03 -0500, "David VomLehn" <dvomlehn@cisco.com>
wrote:
> On Tue, Nov 17, 2009 at 06:58:35PM -0600, myuboot@fastmail.fm wrote:
> > 
> > On Wed, 18 Nov 2009 01:39 +0100, "Florian Fainelli"
> > <florian@openwrt.org> wrote:
> > > -------------------------------
> > 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. 
> 
> It sounds like you've done a good job getting the bootloader and kernel
> to work, so this may be a silly suggestion, but are you sure your root
> filesystem and busybox are little-endian? It would be an easy mistake to
> make...
> 
> > thanks. Andrew
> 
> David VL

I am pretty sure the filesystem and busybox are big endian. I can see
the following print out when the filesystem is built for big endian
mode. 
"Swapping filesystem endian-ness"
Though I don't know if there is a command to check the endianess of a
filesystem directly.

And below is the header info of the busybox showing it is a big endian
object.
readelf -h busybox-1.14.3/busybox
ELF Header:
  Magic:   7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, big endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           MIPS R3000
  Version:                           0x1
  Entry point address:               0x4001b0
  Start of program headers:          52 (bytes into file)
  Start of section headers:          926564 (bytes into file)
  Flags:                             0x50001007, noreorder, pic, cpic,
  o32, mips32
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         3
  Size of section headers:           40 (bytes)
  Number of section headers:         19
  Section header string table index: 18
Thanks, Andrew

Re: problem bring up initramfs and busybox

[myuboot]

At this point, I just want to be able to bring up the shell so that I
debug further, either with or without initramfs. For initramfs, do I
need to do anything for endianess? I am not aware of anything. 

Thanks, Andrew

On Tue, 17 Nov 2009 20:03 -0500, "David VomLehn" <dvomlehn@cisco.com>
wrote:
> On Tue, Nov 17, 2009 at 06:58:35PM -0600, myuboot@fastmail.fm wrote:
> > 
> > On Wed, 18 Nov 2009 01:39 +0100, "Florian Fainelli"
> > <florian@openwrt.org> wrote:
> > > -------------------------------
> > 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. 
> 
> It sounds like you've done a good job getting the bootloader and kernel
> to work, so this may be a silly suggestion, but are you sure your root
> filesystem and busybox aAt re little-endian? It would be an easy mistake to
> make...
> 
> > thanks. Andrew
> 
> David VL

Re: problem bring up initramfs and busybox

[myuboot]

On Tue, 17 Nov 2009 20:03 -0500, "David VomLehn" <dvomlehn@cisco.com>
wrote:
> On Tue, Nov 17, 2009 at 06:58:35PM -0600, myuboot@fastmail.fm wrote:
> > 
> > On Wed, 18 Nov 2009 01:39 +0100, "Florian Fainelli"
> > <florian@openwrt.org> wrote:
> > > -------------------------------
> > 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. 
> 
> It sounds like you've done a good job getting the bootloader and kernel
> to work, so this may be a silly suggestion, but are you sure your root
> filesystem and busybox are little-endian? It would be an easy mistake to
> make...
> 
> > thanks. Andrew
> 
> David VL
I have some clue on this issue now. It seems there is some problem with
the serial console operating in interrupt mode. If the 8250 is in
polling mode(set the IRQ for the 8250 serial port to 0), the output on
the console is fine. But with 8250 in interrupt mode, 8250 serial driver
does not receive any interrupt in serial8250_interrupt(). The same board
works just fine when operating in little endian mode with interruption.
I probably need to change something in IRQ initialization for big
endian. I will post my solution when I can get it to work. In the
meantime, any suggestion will be welcome.

Best regards, Andrew

Re: problem bring up initramfs and busybox

[Florian Fainelli]

Hi Andrew.

Le jeudi 26 novembre 2009 01:24:13, myuboot@fastmail.fm a écrit :
> On Tue, 17 Nov 2009 20:03 -0500, "David VomLehn" <dvomlehn@cisco.com>
> 
> wrote:
> > On Tue, Nov 17, 2009 at 06:58:35PM -0600, myuboot@fastmail.fm wrote:
> > > On Wed, 18 Nov 2009 01:39 +0100, "Florian Fainelli"
> > >
> > > <florian@openwrt.org> wrote:
> > > > -------------------------------
> > >
> > > 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.
> >
> > It sounds like you've done a good job getting the bootloader and kernel
> > to work, so this may be a silly suggestion, but are you sure your root
> > filesystem and busybox are little-endian? It would be an easy mistake to
> > make...
> >
> > > thanks. Andrew
> >
> > David VL
> 
> I have some clue on this issue now. It seems there is some problem with
> the serial console operating in interrupt mode. If the 8250 is in
> polling mode(set the IRQ for the 8250 serial port to 0), the output on
> the console is fine. But with 8250 in interrupt mode, 8250 serial driver
> does not receive any interrupt in serial8250_interrupt(). The same board
> works just fine when operating in little endian mode with interruption.
> I probably need to change something in IRQ initialization for big
> endian. I will post my solution when I can get it to work. In the
> meantime, any suggestion will be welcome.

Do you need that patch to work in little-endian: 
https://dev.openwrt.org/browser/trunk/target/linux/ar7/patches-2.6.30/500-
serial_kludge.patch ? If so, you are likely to need it in big-endian too since 
it works around a silicon issue.
-- 
Best regards, Florian Fainelli
Email: florian@openwrt.org
Web: http://openwrt.org
IRC: [florian] on irc.freenode.net
-------------------------------

Re: problem bring up initramfs and busybox

[myuboot]

On Thu, 26 Nov 2009 09:45 +0100, "Florian Fainelli"
<florian@openwrt.org> wrote:
> Hi Andrew.
> 
> Le jeudi 26 novembre 2009 01:24:13, myuboot@fastmail.fm a écrit :
> > On Tue, 17 Nov 2009 20:03 -0500, "David VomLehn" <dvomlehn@cisco.com>
> > 
> > wrote:
> > > On Tue, Nov 17, 2009 at 06:58:35PM -0600, myuboot@fastmail.fm wrote:
> > > > On Wed, 18 Nov 2009 01:39 +0100, "Florian Fainelli"
> > > >
> > > > <florian@openwrt.org> wrote:
> > > > > -------------------------------
> > > >
> > > > 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.
> > >
> > > It sounds like you've done a good job getting the bootloader and kernel
> > > to work, so this may be a silly suggestion, but are you sure your root
> > > filesystem and busybox are little-endian? It would be an easy mistake to
> > > make...
> > >
> > > > thanks. Andrew
> > >
> > > David VL
> > 
> > I have some clue on this issue now. It seems there is some problem with
> > the serial console operating in interrupt mode. If the 8250 is in
> > polling mode(set the IRQ for the 8250 serial port to 0), the output on
> > the console is fine. But with 8250 in interrupt mode, 8250 serial driver
> > does not receive any interrupt in serial8250_interrupt(). The same board
> > works just fine when operating in little endian mode with interruption.
> > I probably need to change something in IRQ initialization for big
> > endian. I will post my solution when I can get it to work. In the
> > meantime, any suggestion will be welcome.
> 
> Do you need that patch to work in little-endian: 
> https://dev.openwrt.org/browser/trunk/target/linux/ar7/patches-2.6.30/500-
> serial_kludge.patch ? If so, you are likely to need it in big-endian too
> since 
> it works around a silicon issue.
> -- 
> Best regards, Florian Fainelli
> Email: florian@openwrt.org
> Web: http://openwrt.org
> IRC: [florian] on irc.freenode.net
> -------------------------------
I did not need the patch for little endian. For the UART type, I used
PORT_16550 instead of AR7 and it worked just fine. Thanks for the
suggestion though.
Best regards, Andrew

Re: problem bring up initramfs and busybox

[myuboot]

[-- Attachment #1: Type: text/plain, Size: 2799 bytes --]

Finally, I figured out the problem. The main issue is in file irq.c, in
which the register starting at CHNL_OFFSET() is not set correctly in big
endian mode. With that problem, even though the serial port 8250 is
generating interrupt,  the interrupt controller blocks it.

In  big endian mode, the value written at line 
writel(i, REG(CHNL_OFFSET(i)));

should be 
writel(i << 24, REG(CHNL_OFFSET(i)));

I suspect this problem is applicable to AR7 running in big endian mode
since my board is almost the same to AR7. I am attaching a patch for
anyone's reference. Thanks to Florian, Kevin, Chris and Ralf for your
advise.

Best regards, Andrew



On Thu, 26 Nov 2009 09:45 +0100, "Florian Fainelli"
<florian@openwrt.org> wrote:
> Hi Andrew.
> 
> Le jeudi 26 novembre 2009 01:24:13, myuboot@fastmail.fm a écrit :
> > On Tue, 17 Nov 2009 20:03 -0500, "David VomLehn" <dvomlehn@cisco.com>
> > 
> > wrote:
> > > On Tue, Nov 17, 2009 at 06:58:35PM -0600, myuboot@fastmail.fm wrote:
> > > > On Wed, 18 Nov 2009 01:39 +0100, "Florian Fainelli"
> > > >
> > > > <florian@openwrt.org> wrote:
> > > > > -------------------------------
> > > >
> > > > 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.
> > >
> > > It sounds like you've done a good job getting the bootloader and kernel
> > > to work, so this may be a silly suggestion, but are you sure your root
> > > filesystem and busybox are little-endian? It would be an easy mistake to
> > > make...
> > >
> > > > thanks. Andrew
> > >
> > > David VL
> > 
> > I have some clue on this issue now. It seems there is some problem with
> > the serial console operating in interrupt mode. If the 8250 is in
> > polling mode(set the IRQ for the 8250 serial port to 0), the output on
> > the console is fine. But with 8250 in interrupt mode, 8250 serial driver
> > does not receive any interrupt in serial8250_interrupt(). The same board
> > works just fine when operating in little endian mode with interruption.
> > I probably need to change something in IRQ initialization for big
> > endian. I will post my solution when I can get it to work. In the
> > meantime, any suggestion will be welcome.
> 
> Do you need that patch to work in little-endian: 
> https://dev.openwrt.org/browser/trunk/target/linux/ar7/patches-2.6.30/500-
> serial_kludge.patch ? If so, you are likely to need it in big-endian too
> since 
> it works around a silicon issue.
> -- 
> Best regards, Florian Fainelli
> Email: florian@openwrt.org
> Web: http://openwrt.org
> IRC: [florian] on irc.freenode.net
> -------------------------------

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: irq.patch --]
[-- Type: text/x-patch; name="irq.patch", Size: 2982 bytes --]

--- irq.c	2009-09-21 19:24:30.000000000 -0500
+++ irq.c	2009-12-04 17:52:59.000000000 -0600
@@ -45,7 +45,8 @@
 
 #define REG(addr) ((u32 *)(KSEG1ADDR(AR7_REGS_IRQ) + addr))
 
-#define CHNL_OFFSET(chnl) (CHNLS_OFFSET + (chnl * 4))
+#define CHNL_OFFSET(chnl) (CHNLS_OFFSET + (chnl * 4))  /* priority for interrupt chnl */
+#define LITTLE_TO_BIG_ENDIAN(i)  (24-(i)/8*8 + ((i)%8))  /* convert the bit number from little to big endin within 32 bit*/
 
 static void ar7_unmask_irq(unsigned int irq_nr);
 static void ar7_mask_irq(unsigned int irq_nr);
@@ -78,35 +79,35 @@
 
 static void ar7_unmask_irq(unsigned int irq)
 {
-	writel(1 << ((irq - ar7_irq_base) % 32),
+	writel(1<< LITTLE_TO_BIG_ENDIAN(irq - ar7_irq_base), 
 	       REG(ESR_OFFSET(irq - ar7_irq_base)));
 }
 
 static void ar7_mask_irq(unsigned int irq)
 {
-	writel(1 << ((irq - ar7_irq_base) % 32),
+	writel(1<< LITTLE_TO_BIG_ENDIAN(irq - ar7_irq_base),
 	       REG(ECR_OFFSET(irq - ar7_irq_base)));
 }
 
 static void ar7_ack_irq(unsigned int irq)
 {
-	writel(1 << ((irq - ar7_irq_base) % 32),
+	writel(1<<LITTLE_TO_BIG_ENDIAN(irq - ar7_irq_base),
 	       REG(CR_OFFSET(irq - ar7_irq_base)));
 }
 
 static void ar7_unmask_sec_irq(unsigned int irq)
 {
-	writel(1 << (irq - ar7_irq_base - 40), REG(SEC_ESR_OFFSET));
+	writel(1 << LITTLE_TO_BIG_ENDIAN(irq - ar7_irq_base - 40), REG(SEC_ESR_OFFSET));
 }
 
 static void ar7_mask_sec_irq(unsigned int irq)
 {
-	writel(1 << (irq - ar7_irq_base - 40), REG(SEC_ECR_OFFSET));
+	writel(1 << LITTLE_TO_BIG_ENDIAN(irq - ar7_irq_base - 40), REG(SEC_ECR_OFFSET));
 }
 
 static void ar7_ack_sec_irq(unsigned int irq)
 {
-	writel(1 << (irq - ar7_irq_base - 40), REG(SEC_CR_OFFSET));
+	writel(1 << LITTLE_TO_BIG_ENDIAN(irq - ar7_irq_base - 40), REG(SEC_CR_OFFSET));
 }
 
 void __init arch_init_irq(void)
@@ -123,16 +124,16 @@
 	 * Disable interrupts and clear pending
 	 */
 	writel(0xffffffff, REG(ECR_OFFSET(0)));
-	writel(0xff, REG(ECR_OFFSET(32)));
+	writel(0xff000000, REG(ECR_OFFSET(32)));
 	writel(0xffffffff, REG(SEC_ECR_OFFSET));
 	writel(0xffffffff, REG(CR_OFFSET(0)));
-	writel(0xff, REG(CR_OFFSET(32)));
+	writel(0xff000000, REG(CR_OFFSET(32)));
 	writel(0xffffffff, REG(SEC_CR_OFFSET));
 
 	ar7_irq_base = base;
 
 	for (i = 0; i < 40; i++) {
-		writel(i, REG(CHNL_OFFSET(i)));
+		writel(i<<24, REG(CHNL_OFFSET(i)));
 		/* Primary IRQ's */
 		set_irq_chip_and_handler(base + i, &ar7_irq_type,
 					 handle_edge_irq);
@@ -156,18 +157,18 @@
 	int i, irq;
 
 	/* Primary IRQ's */
-	irq = readl(REG(PIR_OFFSET)) & 0x3f;
+	irq = (readl(REG(PIR_OFFSET)) & 0x3f000000)>>24;
 	if (irq) {
 		do_IRQ(ar7_irq_base + irq);
 		return;
 	}
 
 	/* Secondary IRQ's are cascaded through primary '0' */
-	writel(1, REG(CR_OFFSET(irq)));
+	writel(0x01000000, REG(CR_OFFSET(irq)));
 	status = readl(REG(SEC_SR_OFFSET));
 	for (i = 0; i < 32; i++) {
 		if (status & 1) {
-			do_IRQ(ar7_irq_base + i + 40);
+			do_IRQ(ar7_irq_base + LITTLE_TO_BIG_ENDIAN(i) + 40);
 			return;
 		}
 		status >>= 1;

loadable kernel module link failure - endianness incompatible with that of the selected emulation

[myuboot]

I got a link error when compiling 2 loadable kernel modules -
"endianness incompatible with that of the selected emulation". 

But both kernel and the kernel modules of error are in big endian. I
don't know what I should check or fix. Any suggestions? I checked the
endianess of the kernel by checking the elf header of vmlinux file, is
that the right way to do it?

Below are the error info and the readelf output, showing both the kernel
and a kernel module are in big endian.
Thanks for your help. Andrew

1) error log 
make -C /home/root123/sources/kernel/linux
CROSS_COMPILE=""/home/root123/sources/gcc3.4.3-be"/bin/mips-linux-"
M=/home/root123/sources/sdk/platform/src/linux/mxp/src modules    

  LD [M]  /home/root123/sources/sdk/platform/src/linux/mxp/src/mxpmod.o
/home/root123/sources/gcc3.4.3-be/bin/mips-linux-ld:
/home/root123/sources/sdk/platform/src/linux/mxp/src/mmxpcore.o:
compiled for a big endian system and target is little endian
/home/root123/sources/gcc3.4.3-be/bin/mips-linux-ld:
/home/root123/sources/sdk/platform/src/linux/mxp/src/mmxpcore.o:
endianness incompatible with that of the selected emulation
/home/root123/sources/gcc3.4.3-be/bin/mips-linux-ld: failed to merge
target specific data of file
/home/root123/sources/sdk/platform/src/linux/mxp/src/mmxpcore.o
make[13]: ***
[/home/root123/sources/sdk/platform/src/linux/mxp/src/mxpmod.o] Error 1

2) kernel is in big endian
readelf -h vmlinux
ELF Header:
  Magic:   7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, big endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           MIPS R3000
  Version:                           0x1
  Entry point address:               0x941aa000
  Start of program headers:          52 (bytes into file)
  Start of section headers:          1720624 (bytes into file)
  Flags:                             0x50001001, noreorder, o32, mips32
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         1
  Size of section headers:           40 (bytes)
  Number of section headers:         27
  Section header string table index: 24


3) kernel module is big endian.
readelf -h mmxpcore.o
ELF Header:
  Magic:   7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, big endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           MIPS R3000
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          81024 (bytes into file)
  Flags:                             0x10001001, noreorder, o32, mips2
  Size of this header:               52 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           40 (bytes)
  Number of section headers:         34
  Section header string table index: 31

Re: loadable kernel module link failure - endianness incompatible with that of the selected emulation

[David Daney]

myuboot@fastmail.fm wrote:
> I got a link error when compiling 2 loadable kernel modules -
> "endianness incompatible with that of the selected emulation". 
> 
> But both kernel and the kernel modules of error are in big endian. I
> don't know what I should check or fix. Any suggestions? I checked the
> endianess of the kernel by checking the elf header of vmlinux file, is
> that the right way to do it?
> 
> Below are the error info and the readelf output, showing both the kernel
> and a kernel module are in big endian.
> Thanks for your help. Andrew
> 
> 1) error log 
> make -C /home/root123/sources/kernel/linux
> CROSS_COMPILE=""/home/root123/sources/gcc3.4.3-be"/bin/mips-linux-"
> M=/home/root123/sources/sdk/platform/src/linux/mxp/src modules    
> 
>   LD [M]  /home/root123/sources/sdk/platform/src/linux/mxp/src/mxpmod.o
> /home/root123/sources/gcc3.4.3-be/bin/mips-linux-ld:
> /home/root123/sources/sdk/platform/src/linux/mxp/src/mmxpcore.o:
> compiled for a big endian system and target is little endian
> /home/root123/sources/gcc3.4.3-be/bin/mips-linux-ld:
> /home/root123/sources/sdk/platform/src/linux/mxp/src/mmxpcore.o:
> endianness incompatible with that of the selected emulation
> /home/root123/sources/gcc3.4.3-be/bin/mips-linux-ld: failed to merge
> target specific data of file
> /home/root123/sources/sdk/platform/src/linux/mxp/src/mmxpcore.o
> make[13]: ***
> [/home/root123/sources/sdk/platform/src/linux/mxp/src/mxpmod.o] Error 1
> 

Looks like a toolchain bug/configuration-problem.  Hard to tell though 
as you didn't pass 'V=1' on the make invocation line.

David Daney

Re: loadable kernel module link failure - endianness incompatible with that of the selected emulation

[myuboot]

On Tue, 19 Jan 2010 15:47 -0800, "David Daney"
<ddaney@caviumnetworks.com> wrote:
> myuboot@fastmail.fm wrote:
> > I got a link error when compiling 2 loadable kernel modules -
> > "endianness incompatible with that of the selected emulation". 
> > 
> > But both kernel and the kernel modules of error are in big endian. I
> > don't know what I should check or fix. Any suggestions? I checked the
> > endianess of the kernel by checking the elf header of vmlinux file, is
> > that the right way to do it?
> > 
> > Below are the error info and the readelf output, showing both the kernel
> > and a kernel module are in big endian.
> > Thanks for your help. Andrew
> > 
> > 1) error log 
> > make -C /home/root123/sources/kernel/linux
> > CROSS_COMPILE=""/home/root123/sources/gcc3.4.3-be"/bin/mips-linux-"
> > M=/home/root123/sources/sdk/platform/src/linux/mxp/src modules    
> > 
> >   LD [M]  /home/root123/sources/sdk/platform/src/linux/mxp/src/mxpmod.o
> > /home/root123/sources/gcc3.4.3-be/bin/mips-linux-ld:
> > /home/root123/sources/sdk/platform/src/linux/mxp/src/mmxpcore.o:
> > compiled for a big endian system and target is little endian
> > /home/root123/sources/gcc3.4.3-be/bin/mips-linux-ld:
> > /home/root123/sources/sdk/platform/src/linux/mxp/src/mmxpcore.o:
> > endianness incompatible with that of the selected emulation
> > /home/root123/sources/gcc3.4.3-be/bin/mips-linux-ld: failed to merge
> > target specific data of file
> > /home/root123/sources/sdk/platform/src/linux/mxp/src/mmxpcore.o
> > make[13]: ***
> > [/home/root123/sources/sdk/platform/src/linux/mxp/src/mxpmod.o] Error 1
> > 
> 
> Looks like a toolchain bug/configuration-problem.  Hard to tell though 
> as you didn't pass 'V=1' on the make invocation line.
> 
> David Daney
With the V=1 option suggested, I found the culprit is this "-m
elf32ltsmip". It is working now.

Thanks. Andrew