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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/