Subject: RE: booting kernel on SA1110

From: Jeff Sutherland <[email-masked]>
Date: Thu, 27 Apr 2000 16:19:46 -0400

> 	I'm trying to get a kernel to boot on an SA1110 platform
> (development board with 64mb SDRAM).  I set up the memory 
> configurations
> in mm/mm-sa1100.c and kernel/arch.c.  I pass architecture 
> number 0x10 from
> the bootloader but it never gets out of head-armv.S.  I 
> traced the problem
> to the instruction turning on the MMU:
> 
> mcr     p15, 0, r0, c1, c0
> 
> 	At this point r0 = 0xc000517d; mmu, write buffer, and all caches
> on.  Is all of that really supposed to happen here?  Or is r0 getting
> incorrectly set in __create_page_tables?
> 
> 	I remember someone else reporting a freeze when the MMU is
> switched on (SA1110 also).  Any ideas?
> 
> Thanks,
> Chris

Well, I'm not exactly an expert on this, but I did successfully get a kernel
running on an SA1110 platform.  First off, what kernel are you using?  For
SA1110 you'd better go get 2.3.99-pre3 and the latest patches from
ftp.netwinder.org/users/n/nico and ftp.arm.linux.org.uk.  The kernel wants
to begin execution at 0xC0008000.  Stock setup has the compressed kernel
image being loaded at 0xC008000, then jump to that address. Then it
decompresses, etc. etc. but you know all that already I assume.  I moved the
initial load address to accommodate my custom bootloader but the
decompressed kernel still gets put at 0xC008000.  I suspect that if you're
trying to load the kernel somewhere else that's where things are getting
messed up.  Russell King had a good comment about possible problems when
using a debugger.

Another possibility: If the Icache has not been enabled up to now, turning
on the buffers and the Icache initiates an 8 word burst transfer on the
memory buss.  If the memory timing is not set correctly, especially when
using SDRAMs on the SA1110, or there are other signal integrity issues, this
is a good time for things to blow up.  How do I know this???

Regards,
//Jeff

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]
++        Please use [email-masked] for           ++
++                        kernel-related discussions.                      ++

---

From: Chris Blazie <[email-masked]>
Date: Thu, 27 Apr 2000 16:34:32 -0400 (EDT)

> running on an SA1110 platform.  First off, what kernel are you using?

	I'm using 2.3.99-pre3 with rmk1/np3 patches.  I'll look at the
later patches to see if any significant changes were made in this area.

> to begin execution at 0xC0008000.  Stock setup has the compressed kernel

	I'm using an uncompressed Image and loading to C0008000.

> is a good time for things to blow up.  How do I know this???

	Is it possible to test for this by NOT enabling the Icache at this
point in head-armv.S?  Or will that blow up for other reasons?

Thanks,
Chris

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Thu, 27 Apr 2000 21:29:27 +0100 (BST)

> is a good time for things to blow up.  How do I know this???

I think all those issues got solved back in 2.3.5x days by doing identity
mappings etc.  Is this a new problem with this processor?
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |            http://www.arm.linux.org.uk/            /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Nicolas Pitre <[email-masked]>
Date: Thu, 27 Apr 2000 17:16:09 -0400 (EDT)

> later patches to see if any significant changes were made in this area.

There were.  Rather subtile but important.

> 	I'm using an uncompressed Image and loading to C0008000.

You really should use zImage.  Unless you are confident you know what
you're doing and what compressed/head-sa1100.S is doing for you.

Nicolas

---

From: Nicolas Pitre <[email-masked]>
Date: Thu, 27 Apr 2000 17:45:40 -0400 (EDT)

> mappings etc.  Is this a new problem with this processor?

No.  The issue was a cache coherency problem with head-sa1100.S that got
solved in my latest patch.

Nicolas

---

From: "Zach Welch" <[email-masked]>
Date: Thu, 27 Apr 2000 15:08:33 -0700

Nicolas,

Could you please give a brief explanation as to why zImage is preferred over
Image in the current SA-1100 build? Our bootloader uses a built-in
compression scheme that I need to use, and the idea of compressing the
zImage is not appealing. My understanding is that the two images should be
the same (except zImage has to extract the piggyback kernel).

Thanks

Zach Welch

----- Original Message -----
From: Nicolas Pitre <[email-masked]>
To: Chris Blazie <[email-masked]>
Cc: Jeff Sutherland <[email-masked]>; Linux on ARM Mailing List
(E-mail) <[email-masked]>
Sent: Thursday, April 27, 2000 2:16 PM
Subject: RE: booting kernel on SA1110

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Fri, 28 Apr 2000 00:15:57 +0100 (BST)

> the same (except zImage has to extract the piggyback kernel).

Oh dear.  I've been around this one with Rebel.com (when they were Corel
Computer).  They were basically decompresing and elf-loading the top-level
vmlinux file.

What is the reason for having your own compression scheme built into your
boot loader?  It doesn't make sense when the kernel one is tried, tested
and proved to work.

Please explain why you thought it was a good idea.
   _____

---

From: "Zach Welch" <[email-masked]>
Date: Thu, 27 Apr 2000 16:48:58 -0700

The principal motivating factors here are:

1) We also use our bootloader for Windows CE; otherwise, this wouldn't be an
issue.
2) The compression is "better" (_very_ fast decompression).
3) Our loader uses ATA loading code that allows us to load the image off of
a compact flash and decompress it in one shot.
4) Our code is already proven to work, and we know it sets up the hardware
correctly.*
5) I really don't want to mess with our loader's code, if at all possible.

(*Well, actually, I've been trying to reconcile the differences between what
WinCE and Linux each think is right. But that's an issue seperate from
compression...)

Really, though, I don't care one way or the other which image we use; the
size of the image is about the same and the speed will still be better than
CE. In any event, my original question still stands: what's the difference?
I've looked at the code, but the comments don't tell me enough... ;) ;)

Cheers,

Zach Welch

---

From: Nicolas Pitre <[email-masked]>
Date: Thu, 27 Apr 2000 19:54:46 -0400 (EDT)

> the same (except zImage has to extract the piggyback kernel).

In latest kernels, this extraction is done with all caches enabled so it
takes less than half a second to execute.  So it shouldn't be a big deal
for you to blindlessly use zImage, even if you had it compressed already.
There is a nice side effect too -- there is a checksum performed on the
kernel image while it is uncompressed so you won't silently boot a
truncated or corrupted kernel image.

Now the SA1100 reason for using zImage is this: Some, if not most, SA1100
boards uses many different bootloaders, some leaves the MMU activated,
some jumps in the kernel while not in SVC mode, some doesn't initialize
the serial port on which debugging output should be sent, some doesn't
actually set proper values in r0/r1 for kernel entry, etc. A good example
of this is the angel debug monitor.

The linker script for the compressed boot image allows for inserting an
arbitrary chunk of code very near the beginning of the execution so all
SA1100 specific hacks and tweaks are isolated away in a single file:
head-sa1100.S.  This makes things pretty clean without polluting the main
code with #ifdef ...

In head_sa1100.S, you'll find some code to get control from angel's hands,
caches are cleaned (very important) and MMU turned off (doesn't matter if
it is off already, but just in case), serial ports might be initialized,
etc. The idea is to put the CPU in the barest state so the mainline kernel
code can start over with no catch. Since this code should not run twice, I
linked it with zImage only since zImage is what most people would use.
Like I said above, it can't arm if you always use zImage anyway.

Nicolas

---

From: Nicolas Pitre <[email-masked]>
Date: Thu, 27 Apr 2000 20:02:48 -0400 (EDT)

On Fri, 28 Apr 2000, Russell King - ARM Linux Admin wrote:

> boot loader?

Some bootloaders are designed to load other ... OSes which might not have
autodecompression capabilities.

> It doesn't make sense when the kernel one is tried, tested
> and proved to work.

Well... As long as zImage is still used, the CRC will stool broken
bootloader decompression schemes...

Nicolas

---

From: Nicolas Pitre <[email-masked]>
Date: Thu, 27 Apr 2000 20:06:06 -0400 (EDT)

> 2) The compression is "better" (_very_ fast decompression).

Like I said, this has improoved a lot in latest kernels. I really mean a
lot.

Nicolas

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Fri, 28 Apr 2000 09:17:58 +0100 (BST)

> Like I said, this has improoved a lot in latest kernels. I really mean a

On a NetWinder running at 275MHz with a 38400 baud serial port, I am unable
to practically measure the decompression time it's soo short.  I think the
serial port may actually be slowing the thing down actually.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |            http://www.arm.linux.org.uk/            /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |