Could someone bear with another question from me, and elucidate the
reasoning behind and layout of the PROCESS_PAGE_TBLS_BASE area (or has
its origin been lost in the midst of time, marked "here be dragons")?

Robert Swindells <swindellsr@genrad.com> writes:

> >> Why not describe the VM layout that you are implementing along with
> >> the physical memory map. 
> 
> >My trouble is that I rewrote rpc_machdep.c :-)
> 
> I would expect you to create your own xxx_machdep.c, you are using
> different hardware.

Yes but this one was rewritten from scratch.

> Most of the changes should be in the l1_sec_table. You can also
> simplify things if you can live without real console support until
> you jump into main().

That is a myth IMHO. I get real console support with one call:
consinit in initarm. No extra hassle involved at all. Don't know why
people find it so difficult :-)

> >My version is about half the size, and it appears that the reason for
> >that is my ommission to undertake certain necessary things.
> 
> I would start from a clean copy and reapply your changes.

As I said, rewrote from scratch. The {rpc,hpc,etc}_machdep.c are very
very crufty. My edition is much shorter.

> >> I'm sure we can suggest some things to try.
> 
> >Currently my big problem is not understanding the kernel_ptpt
> >business. It is a sort of array of the addresses to pagetables (?) 
> >that sometimes is treated as a pagetable (?).
> 
> >Then pmap_pte does not return the pte at all but the pagetable (or am
> >I barking up the wrong tree?)
> 
> You shouldn't need to change anything around that area.

I'm trying to clean that area up :-)

I gave up initially and transliterated most of the stuff relating to
kernel_ptpt from rpc_machdep.c, and the boot process was getting quite
far - past uvm_init in main(), IIRC. I figured that they blew up,
because (if I interpret correctly) I didn't copy all of the
kernel_ptpt stuff from rpc_machdep, but left out mapping the kernel in
kernel_ptpt. I had a bunch of problems before that because there was
too little virtual address space (somehow I had got hold of a
vmparam.h with only 4Mb set for kva).

> One thing to bear in mind is that the other arm32 ports rely on the
> MMU being set up before jumping into the kernel, ARM Linux expects
> the MMU to be off. You may find life easier if you modify arlo to
> set up a simple pagetable when it loads a NetBSD kernel.

The hpcarm port also starts with the MMU off. Enabling the MMU and
setting up normal mappings works just fine and hunky dory. The trouble
is the pmap->pm_{v,p}ptpt (set from kernel_ptpt in pmap_bootstrap and
mapped to PROCESS_PAGE_TBLS_BASE) are not correctly set up, causing
pmap_extract/pmap_pte to fall down on them.

-- 

	http://ape.n3.net