Subject: RE: ARM Linux running on Assabet update...

From: Jeff Sutherland <[email-masked]>
Date: Mon, 24 Apr 2000 09:14:07 -0400

> Also, leave the mmu turned off (but do turn the Icache on) in

> head.S as there's an issue with not marking the peripheral controller

> register as non-cacheabe/non-bufferable (looks weird on the screen

> until the kernel does its mmu setup).

Huh?

I want to point out that this was a "heat of battle" type issue that I ran
into with early serial output during the kernel decompression/moving stage.
I didn't definitively toubleshoot the problem but it appeared to be cache or
buffering related.  Turning off the MMU in the early stage fixed the problem
for me, but that doesn't mean that anyone else will experience a problem.
Maybe it was due to the fact that I was using uart 3 instead of uart 1
(0x80050000 instead of 0x8001000) for output. 

-Jeff

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Mon, 24 Apr 2000 18:29:50 +0100 (BST)

> (0x80050000 instead of 0x8001000) for output. 

There is currently a problem with the D-cache and writebuffer being enabled
over all areas of virtual space during the kernel decompressor, but that will
be fixed in -rmk3 (which, btw, is imminent).  I think -rmk2 may have been the
brown paper bag version.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |            http://www.arm.linux.org.uk/            /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

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

---

From: Nicolas Pitre <[email-masked]>
Date: Mon, 24 Apr 2000 14:03:22 -0400 (EDT)

> (0x80050000 instead of 0x8001000) for output. 

No, I don't think it makes a difference.  I would rather suspect the
unusual address at which your Win CE bootloader loads the kernel which may
confuse the code in compressed/head.S.  In all cases you may just disable
serial output during the decompression pass.

Nicolas