New 2.6 port: why would kernel not start /sbin/init?

New 2.6 port: why would kernel not start /sbin/init?

[Marc Singer]

I've got a port to a new chip (ARM920 core) that is very close to
booting.  There appears to be something keeping the /sbin/init process
from starting.

In this setup, I'm running a patched 2.6.2 kernel from flash memory.
The root filesystem is a JFFS2 partition in flash.  The
run_init_process() call appears to succeed because it doesn't return.

The sysrq-task list shows that there is an init task, but there seems
to be something wrong with the stack.

                         free                        sibling
  task             PC    stack   pid father child younger older
init          R current      0     1      0     2               (NOTLB)
[<c0021a88>] (show_state+0x44/0xac) from [<c0309e70>] (0xc0309e70)
Backtrace aborted due to bad frame pointer <c0308000>

I've traced through the elf binary loader and gotten to the point
where it does a start_thread().  The only odd thing I see is that that
the interpreter, elf_entry=0x400015f0, refers to an address that
doesn't appear to have any code there.  (I'm using gdb to debug the
kernel through a JTAG emulator.)

(gdb) x/20 elf_entry
0x400015f0:     0x00000000      0x00000000      0x00000000      0x00000000
0x40001600:     0x00000000      0x00000000      0x00000000      0x00000000
0x40001610:     0x00000000      0x00000000      0x00000000      0x00000000
0x40001620:     0x00000000      0x00000000      0x00000000      0x00000000
0x40001630:     0x00000000      0x00000000      0x00000000      0x00000000

My hardware debugger complains of a 'data abort' when I look at that
address which usually means that the CPU returned a page fault.

Should I expect that these pages be mapped already?  Can you offer any
suggestions as to where in the kernel to look for this kind of
failure?

Cheers.

Re: New 2.6 port: why would kernel not start /sbin/init?

[Russell King - ARM Linux]

On Thu, Feb 19, 2004 at 08:38:19PM -0800, Marc Singer wrote:
> My hardware debugger complains of a 'data abort' when I look at that
> address which usually means that the CPU returned a page fault.
> 
> Should I expect that these pages be mapped already?

No.  Pages are faulted in as required.