Re: SV: Re: MPC860 or the mpc850de

[ws%tools.de@localhost (Wolfgang Solfrank)]

Hi,

> > (What do you mean by PPC-endian?)
> 
> It's some sort of a mixed big/little endian hack.  It's described in the
> Motorola PowerPC documentation.  I doubt if it's worth consideration.

Ah, ok, you're talking about PPC-little-endian mode, which actually isn't
used on all ppc cpus.  There are cpus that do real little-endian instead.

> They appear compatible in the sense that the MPC821 provides most of the
> important bit-fields, albeit organized quite differently.  The two biggest
> differences are:
> 
>   1. the MPC821 lacks the BAT system (but is this used in NetBSD?)

Yes, NetBSD/powerpc uses BATs to map all of memory and device space into
kernel virtual memory 1:1 (i.e. physical and virtual addresses are the
same).  User virtual memory (and some part of kernel virtual memory, too)
is mapped via ordinary pages.

The reason I used BATs for mapping in the kernel are:

        1. since during trap catches the mmu is disabled, mapping kernel
           memory 1:1 makes things quite a bit easier.
        2. using BATs reduces tlb usage quite a bit.

You can do something similar (and the 403GCX port does it) by using large
pages for mapping in kernel virtual space.  (At least I think that the
8xx mmu does support varying page sizes, too.)

>   2. the MPC821 has a heavily truncated segment register implementation --
>      there are no 52-bit addresses and no hash table.  Only a couple of the
>      memory protection bits survive, and they are bit-packed into 16 2-bit
>      fields in a single 32-bit register.

Quite similar to the 403GCX mmu.

Since in your last sentence you are obviously talking about the access
protection register (which is available in the 403GCX, too), there is not
much point in using this for our purposes.  You should simply program its
bits for "permission defined by page protection bits" and be done with it.

> I haven't yet looked closely at the PowerPC memory management code, but I
> expect to be able to split it into two layers (if it is not already arranged
> so).  The top layer would assume the usual PowerPC MMU model, and the lower
> layer would implement it with whatever hardware is available, emulating or
> ignoring the missing features.

Hmm, this probably would be suboptimal.  While I'm not sure whether it's
worthwhile to support the two level page table, for which there is hardware
support in the 8xx cpus, trying to blindly emulate the standard ppc mmu
model would quite likely hurt performance.  Plus, since the mmu code is
quite isolated, there is no need for this, as long as you stick with the
overall model of the port (like the 1:1 mapping of memory in the kernel).
Of course you could even change that, but then there wouldn't remain
much in common with the other ppc ports.

Ciao,
Wolfgang
-- 
ws%TooLs.DE@localhost     (Wolfgang Solfrank, TooLs GmbH)       +49-228-985800