[PPCBug] a couple of pmap-related questions

[peterg at ptree32.com.au]

Hi Rafal,

>1. In pmap_bootstrap() there is a number of assignemnts 
>for BAT entries kept in battable[], but it seems for 
>me that they are never used i.e. the cpu registers are
>never filled out according to this table; only two or 
>three explicit BAT registers assignments exist (like 
>for the bottom 256M and PCI bus io space). The battable[]
>is used however by pmap_bat_mapped() call but only for
>reading. Why is that (or am I missing something)? 

 Have a look at dsitrap in trap_subr.S - the battable[]
array is searched for the faulting address, and if found,
bat 2 or 3 is kicked out and replaced with the values
found from the table.

 Work needs to be done in this area. For instance, it would
be good to be able to use the 8 BATs available on some
G3 & G4 CPUs, and the setting up of battable should be
platform-specific.

>General question: what is the overall intended outcome 
>for further kernel initialisation upon completion of
>pmap_bootstrap()? 

 The kernel will be running in virtual mode and have
full control over VM hardware (e.g. hashed page table).

>2. powerpc_init() takes 'basekernel' as a parmeter but 
>it's never used; more on the same note, 'kernelstart'
>and 'kernelend' are passed down to pmap_bootstrap() 
>but this function doen't make use of it. Question: is 
>there anything to be completed still and these will be 
>used when it gets done? Or it just needs cleaning up?

 I think it's a relic from NetBSD, although it could be
used on systems to exclude the kernel from available memory.

>3. powerpc_init() turns on address translation _before_
>calling pmap_bootstrap() which sets up the memory maps etc.
>My understanding is that one first creates mappings, page
>tables etc. and only after that turns on address
>translations. My guess is the OF has some initial
>translations so it's safe to behave so but I'm not that
>intimate with OF. Comments?

 I think that code can be removed. OF starts the kernel
in virtual mode with it's own mappings, so it's a delicate
dance to switch over to FreeBSD's mappings, while still
retaining the ability to call back into OF after the switch.

>FWIW, my recent status is that the kernel goes through 
>all the mi_startup() routines for SYSINITs compiled in
>(copyright, tunables, vm, all that), and prompts for the
>root mountpoint in the end. There's no device hierarchy
>built yet, no low-level clock support routines, no IRQs 
>set up, nexus and related are stubbed at the moment. 
>Just the kernel skeleton but I'll keep on slowly filling
>out the missing pieces.

 That's great !

later,

Peter.