FYI: rudimentary loader for ppcbug-based systems

Peter Grehan grehan at freebsd.org
Fri Oct 17 03:34:07 PDT 2003


>  > which is why I think there is a reasonable chance of getting a GENERIC ppc
> 
> That would be great.  I'm not trying to discourage this,   I'm just
> trying to correct what appear to be some misconceptions about the
> alpha port, or perhaps are my misconceptions about ppc hardware.
> Will one pmap module work for all ppc platforms?  Does the TLB look
> the same everywhere?

 The same pmap will work for 603e, G2 (i.e. 824x), G3 and G4, but not for the
MPC8xx or IBM 4xx processors. Also, some G3 and G4 models allow the hash table
lookup to be disabled, and that might be worth investigating for performance
reasons, and to have an implementation for the 8xx/4xx CPUs. So, it might
be worth making this a run-time switch.

 There are TLB routines that are CPU independent, but any of the models that
allow s/w TLB miss have CPU-specific instructions to allow TLB refill.

 The 8xx/4xx CPUs don't have BAT registers, the 603e and some G3/G4s have 4 BATs,
while other G3/G4s have 8 BATs, and some G4s have an extended BAT that can map
up to 4G. The current port is dependent on BATs to direct-map physical memory,
so BAT emulation with locked TLBs may have to be done on the 8xx/4xx CPUs.

 I'd like to have a kernel that can take advantage of CPU-specific features at
run-time, rather than having to conditionally-compile for each CPU model, or
having a lowest-common denominator GENERIC.

later,

Peter.


More information about the freebsd-ppc mailing list