Wolfgang:

> Let me start by telling you that last year I did a port of NetBSD to a
> 403GCX based platform.  The 403GCX is an embedded PowerPC from IBM. It has
> some similarities to the 860, especially it also has a software reloaded
> tlb, albeit the organization of the tlb is somewhat different.
> 
> I do have the rights to and will release the source to the port after some
> cleanup (and after some additional tuning which I'm currently doing).
> Unfortunately, this will take some time.  However, there probably is quite
> a bit of code there that could be taken for an 860 based machine.

That would be very helpful, I'm sure.
 
> > > We don't now what typ of memory model the mac use, like Big-endian ocg
> > > PPC-endian or Little-endian.
> 
> (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.

> AFAIK, the mac uses big-endian. (Well, it should be possible to implement
> an OS which would use little-endian, but who in his right mind would want
> to? :-))
> 
> > I have studied the data books on the MPC821/860.  The memory management
> > hardware is simpler than the 600 series, but Motorola made an effort to
> > make it compatible.
> 
> Hmm, AFAICT the 860 mmu is quite different from the 6xx/7xx ones. But
> since the tlb is software reloaded, you could ignore the hardware support
> for hierarchical page tables and implement a page table scheme more or
> less as you like.

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

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.

> > I think that the ofppc port may be simpler, thus requiring less
> > modification.  I could be wrong here.
> 
> Hmm, you are right in that the ofppc port is simpler in terms of hardware
> support, as it doesn't itself support any hardware directly, but relies on
> OpenFirmware for that.  Therefor it might be easier to single out the
> drivers from the rest of the code.
> 
> Depending on your periperals, and if you can wait some weeks, you should
> probably better start with the ns3c port that should become available
> then.

This is my first attempt at a NetBSD port, so it's entirely possible I'll
still be in the beginning stages when your code becomes available.

Regards,

David Querbach
Real-Time Systems Inc.