Subject: Re: Re: Re:-pmap initlialization
To: None <email@example.com>
From: Kamal R. Prasad <firstname.lastname@example.org>
Date: 01/07/2005 03:12:05
Subject: Re: Re:-pmap initlialization
To: None <email@example.com>
From: Toru Nishimura <firstname.lastname@example.org>
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
>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
>address space, which is
>known huge, is also accounted. These devices
>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
>(program counter) may point to physical address
>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
>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
>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
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