Subject: Question: Code in head-armv.S

From: <[email-masked]>
Date: Mon, 20 Sep 1999 17:11:39 -0500 (CDT)

Hi,

I'm running an ebsa285-like system with 2.2.11-rmk1-stk1 (stk1 means
some stuff specific to our board), and I'm seeing something strange.
I've had Linux running on this board for quite some time now, but all of
the time I've noticed that it never boots up all the way each time I
reboot it.  I have vxWorks firmware which facilitates booting over the
Intel 21143 ethernet chip, but I only have about a 50% boot success
rate, i.e. 50% of the time I need to reboot and try again.  I've put
code in head-armv.S to track this down (basically banging individual
characters out the UART), and I've trace it to where the MMU is enabled.
Here's the sequence:

		mov     lr, pc
		mov     pc, r10			@ Call processor flush (returns ctrl reg)
		adr     r5, __entry
		sub     r10, r10, r5 		@ Make r10 PIC
		ldr 	lr, .Lbranch
/** DEBUG! FootBase is 0x42000000 **/
		ldr     r9, FootBase
		mov     r8, #0x33
		str     r8, [r9, #0x160]
/** DEBUG! **/
		mcr     p15, 0, r0, c1, c0	@ Enable MMU & caches.  In 3 instructions
						@ we lose this page!
		mov     pc, lr

What happens is I see the 3 printed out before the jump and then a solid
hang.  I noticed comments in 2.2.12-rmk1 that this is a known problem if
hte mov pc,lr instruction falls on a separate cache line, so I added the
.align 5 aligned_entry stuff from there but it had no affect.  Is there
something else that could be going wrong?

--
Kyle Mestery			| StorageTek's Storage Networking Group
[email-masked]		| http://www.freebsd.org/
[email-masked]		| http://www.netwinder.org/
	Protect your right to privacy: www.freecrypto.org

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

---

From: [email-masked]
Date: Mon, 20 Sep 1999 23:58:37 +0100 (BST)

> something else that could be going wrong?

It's not so much a "known problem" but an effect I observed.  It wouldn't
be causing you the intermittent booting that you're seeing - it generally
just won't boot altogether, or it will always boot.

It sounds like the kernel is getting corrupted.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: <[email-masked]>
Date: Thu, 23 Sep 1999 14:19:03 -0500 (CDT)

Hi,

> just won't boot altogether, or it will always boot.
Okay, that sounds right.

> It sounds like the kernel is getting corrupted.
Something else strange, and I'm not sure if I'm chasing two separate
problems now.  I had a kernel that would boot about 50% of the time, and
the other 50% it would hang.  I never really investigated this much to
figure out what was going on.  I am now modifying the kernel memory maps
for the different processors we are running.  What I'm really doing is
changing the memory map setup code so it can figure out it's memory map
while it's executing rather than at compile time.  This code compiles
fine, but the kernel will not run at all.  This is the kernel I traced
down to not working once the MMU is enabled (i.e. I never make it past
the MMU being enabled in head-armv.S).

I tried something someone else suggested, and that was to map in the
page the kernel is executing when the MMU is enabled, but this didn't
help.  I'm running out of ideas.  Anyone know where I should be
looking?

---

From: [email-masked]
Date: Thu, 23 Sep 1999 20:33:22 +0100 (BST)

> the MMU being enabled in head-armv.S).

I've done a major overhaul of the memory initialisation today in 2.3.18,
so it'll probably knock your changes out.

> help.  I'm running out of ideas.  Anyone know where I should be

It's very unlikely that this is a kernel problem.  The kernel memory
initialisation code works reliably on a lot of NetWinders, RiscPCs,
EBSA285's and EBSA110's.  It's well tested.  I'd suggest checking out
either the way you're calling the kernel, or the hardware itself.

(btw, make sure that the caches are flushed before you enter the kernel
from your loader.  This is an absolute MUST)!
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Jonathan Foster Kliegman <[email-masked]>
Date: Thu, 23 Sep 1999 13:38:03 -0700

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

On kernels we've run on the EBSA-285 we actually added in lines of code
at the very beginning of head-armv.S.  When we were using Angel to
download our code this was necessary as Angel was enabling the MMU. 
Basically we just added lines to the start of head-armv.S to disable
IRQ/FIQs and the MMU and this solved the problems we were having on
bootup.  I may be mixing problems up but I remember that someone
recently had a problem booting off of a Windriver boot loader - I
suspect the problem may be similar...

-Jon
-- 
Quackware, Inc.             www.quackware.com
1875 Charleston Road, Mountain View, CA 94043
Ph (650) 316 3891          Cell (412) 298 5363
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: <[email-masked]>
Date: Fri, 24 Sep 1999 08:38:16 -0500 (CDT)

Hi,

> so it'll probably knock your changes out.
Have you changed it to do what I mentioned above, that is, figure out
it's memory map at runtime vs. compile time?  The reason I need this is
because we have 10 different types of memory maps depending on what
processor we are running on, and compilign 10 different kernels is a
pain.  Letting the kernel pick this at runtime is nicer in our case.

> from your loader.  This is an absolute MUST)!
Well, thanks for the help Russell.  It turns out I wasn't flushing the
caches when I was booting, and this was the actual problem.  Once I put
in the proper cache flushing routines, things are working much better
now.  Thanks for the help!

---

From: [email-masked]
Date: Fri, 24 Sep 1999 15:09:37 +0100 (BST)

> pain.  Letting the kernel pick this at runtime is nicer in our case.

No, and you don't need to.  The idea is:

1. Kernel is loaded (without caches or MMU)
2. Kernel head-armv.S code sets up enough to get the kernel C code
   running.
3. paging_init() and friends set up all the mappings required for
   the architecture.  At this point, the machine_is_xxx() macros
   are workable.

This seems to be a re-occuring problem.  head-arm?.S is not supposed to
contain all the setup code, and MUST NOT be used for that purpose!

You will need to register architecture numbers to use the machine_is_xxx()
stuff - read the stuff in Documentation/arm.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: <[email-masked]>
Date: Fri, 24 Sep 1999 13:14:14 -0500 (CDT)

Hi,

> stuff - read the stuff in Documentation/arm.
I realize this, and I plan on registering architecture numbers soon.
But what I am referring to when I talk about the memory maps is the
#define of MAPPING in the variosu arch/arm/mm/mm-*.c files, specifically
the Footbridge case where you have host mode and add-in mode.  In our
hardware, we have a board with 5 SA-110's on it, one with an ethernet
chip, the other 4 communicating with themselves and the 'host' SA-110
via PCI.  Now, each one has a slightly different memory map.  Instead of
having to know at compile time what MAPPING is defined as, I changed
things around so at runtime it can figure out this information.

I agree with everythign else you mention above, however.  The
head-armv.S stuff should be generic, and I'm moving a lot of my changes
from there into firmware.

---

From: [email-masked]
Date: Fri, 24 Sep 1999 20:19:09 +0100 (BST)

> from there into firmware.

You mention two totally different pieces of code that don't react with
each other here.  MAPPING is not used by head-armv.S
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]