Subject: Re: Re:-pmap initlialization
To: None <port-arm@netbsd.org>
From: Toru Nishimura <locore64@alkyltechnology.com>
List: port-arm
Date: 01/06/2005 12:38:41
As already explained by Richard, there is an important assumption inside
initarm() pmap initialization logic.

initarm() is called under the circumstance where;
- MMU is enabled (this means ARM cache is active),
- kernel address space is prepared correctly _just as_   NetBSD is
going to (re-) build.

Your hardware has SDRAM at 0xa000-0000.  It's rather odd arrangement
compared to other processors.  Your kernel is going to use KVA (kernel
virtual address space) in 0xc000-0000.  There are number of hardware
registers must be seen by NetBSD kernel.  PCI address space, which is
known huge, is also accounted.  These devices require mapped
somewhere beyond 0xc000-0000.   xxxx_start.S, on behalf of ill-designed
bootloader coloured by red, prepares the initial KVA scratching L1 table.
It must be matched with NetBSD foundation which will be (re-) built later
by initarm().  Bootloader picks up the target kernel image and loads it
on SDRAM, and then jumps to the beginning.  At this memoment, PC
(program counter) may point to physical address (0xa000-0000) or
MMU enabled virtual address (0xc000-0000).  Let's assume the latter
here.  xxx_start.S, in turn, turns off MMU for a while to build NetBSD L1
table.  Some ARM ports arrange double map SDRAM to have 0xa000-0000
KVA range and 0xc000-0000 range to help id*t programmers.   xxx_start.S
jumps to the real NetBSD entry point kernel_text: using freshly built L1 table turned
by MMU.  CPU is now running virtual address again.  Shortly, initarm() takes
control and starts preparing vital pmap foundation biting available SDRAM
storage.  When all completed, initarm() switchs KVA to "the NetBSD address
space" which has been freshly built.  As long as the initial L1 table made by
xxx_start.S and NetBSD address space match each other, CPU will not aware
that MMU has been re-enabled using a new TLB map.  Otherwise, say, two
tables differ inconsistently, CPU gets knocked down immediately at the point.

In my case, I made LIBSA bootloader which prepares the initial L1 table and
can handle ELF32 image handsomely.  So there is no hack required by
xxx_start.S  And it also allowed me to have ELF DDB instantly.  Shoot the red...

Toru Nishimura/ALKYL Technology, a NetBSD company.