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.

MMU is enabled by Redboot. Further, Redboot prepares a
page table that maps 0xa0000000 to 0xc0000000. It
works correctly because it is able to execute code.

>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 

The kernel is loaded at 0xa0200000 which corresponds
to 0xc0200000.

>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 seems to prepare the startup L1 table at (freeend).
The L1 page table is prepared by initarm().

>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
I actually used the physical address 0xa0200000. 
>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

I have copied over lubbock _start.S and _machdep.S
code. This is because the underlying processor is the
same (Intel PXA255) only difference being lubbock is a
development board whereas Triton (by Karo Inc.) is a
production board. It may not be doing what you refer
to as -double mapping. And there is v little mostly in
terms of memory maps which changes between the 2
ports.
 >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. 
The problem is that the entries seem correct and yet
there is no diagnostic -as if I handed over control to
a program that doesn't consider it necessary to
provide error/diagnostic messages. Looking at the log,
I can say the L1 page table looks something like this
(as printed by pmap_map_chunk() in
sys/arch/arm/arm32/pmap.c0:-
--------------------------------------
pa=0xa0200000 va=0xc0200000 size=0x10d000
(kernel)pa=0xa030d000 va=0xc030d000 size=0x3d000 
------------------------------------
> 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.  

But MMU was already enabled when we added new entries.
The problem happens immediately after translation
buffer has been invalidated with an mcr. 

>Otherwise, say, two
>tables differ inconsistently, CPU gets knocked down
>immediately at the point.

Is there any diagnostic message that can be (made to
be) printed if the L1 table doesn't match requirement.


>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...

Redboot has the facility to load elf32 files and has a
gdb stub in it too.



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com