Subject: starting init on StrongARM (shark)

From: [email-masked] (Alexander Schulz)
Date: Mon, 19 Jul 1999 14:10:55 +0200 (CES)

Hello,

I am trying to start init on a Digital shark under Linux but it won't work.

I changed the kernel until most of the hardware is detectet and working, so
now should be the time to ru init. The exec-syscalls work until somewhere in
binfmt_elf.c they try to zero a region of userspace memory (__clear_user).
At that point, the machine hangs completely (Can't even ping it anymore).

But this should be software that also runs on other arms and should not be
architecture-dependend except physical memory (I adjusted the constants in
memory.h, is there something else I must do?) and perhaps the exceptions.
But as far as I understand it, those are only processor-dependend, and it is
a StrongARM like others. And I once had a kerbnel-oops (unable to handle
kernel paging-request) so it seems they are running.

So I would like some hints from people who know the exec stuff. Just some
intelligent guesses perhaps. Are there any Architecture dependences in the
MMU-code (not just processor-specific)? How can I debug this? Where can I
find some documentation about this part of the kernel (I only have Rubini
here, and starting init ist not exactly a device :-)

Thanks
   Alexander

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Mon, 19 Jul 1999 13:40:20 +0100

>here, and starting init ist not exactly a device :-)

It does sound like your memory mappings are not being set up properly.  
What exactly do you have in memory.h, and what is the physical layout of the 
Shark's memory map?

p.

---

From: [email-masked] (Alexander Schulz)
Date: Mon, 19 Jul 1999 15:35:46 +0200 (CES)

> What exactly do you have in memory.h, and what is the physical layout of the 

Memory starts at 0x0e00.0000 (but this depends on the amount of memory
installed, I have 32MB) I don't have the source here at the moment, I will
have a look as soon as I am at home. Kernel is mapped at c000.0000 as on the
other arms.

BTW: I forgot to tell this the last time:
The first elf_bss that should be cleared is at 0x4002.1408 the second is at
0x0200.e3d8 each one hangs the machine.

When I comment them out, I get to the debug messages which tell me that the
code also is around 0x0200.0000, the stack at 0xbfff.ff30

So some numbers at least, I'll send you the memory.h stuff.

Thanks
  Alexander

---

From: Philip Blundell <[email-masked]>
Date: Mon, 19 Jul 1999 15:10:01 +0100

>code also is around 0x0200.0000, the stack at 0xbfff.ff30

Those all look correct.  You need to check what pages in physical memory 
the two BSS areas are mapped to.

The stack grows down from the bottom of kernel memory (ie the first word is at 
0xbffffffc).  Programs typically get loaded at 0x02000000 and libraries from 
0x40000000 upwards, though both of these can vary a bit.

p.