Rambling about PowerPC OEA64 support

[Matt Thomas <matt%3am-software.com@localhost>]

I've been adding support for 64-bit booke cores (E5500/E6500).  But I figured if 
I do that, I should also try to finish the OEA64 support, specifically looking
at the 970 (G5) CPUs.

The main thing complicating things is the segment lookaside buffer (SLB) list.  This
is basically equivalent to the 16 entry segment registers used by OEA/OEA64BRIDGE.  Like
SRs, the SLB list is per-CPU.

Given exceptions start in real mode, and like the 32-bit PPC, the kernel is currently loaded 
in low memory, overlapping the same address used by user processes.  This restricts the SLB
list to either have kernel segment mappings for real memory (while in the kernel) or user 
segments for mapping user space (while in user space).  This makes exceptions expensive
since the SLB has to be flushed on every kernel/user transition.

But given there is 64-bits of address space, the addresses used to map physical memory can 
be relocated to the well above any VA used by the user-address space.  The kernel will need
to start at or above 0xfffffffffe000000 so that bla can branch into it.  This limits the
kernel text/data/bss to 32MB which might be a problem for kernels with MD disks in them.

We also need to turn on the MMU sooner than we do now since we will be branching into
mapped KVA space.  But since the kernel needs to be in the last 32MB of a [256MB] segment, we
can't the segment to map the kernel with the segment to map the first 256MB unless we load
it at 224MB+.  [Amusingly many BOOKE systems map the primary set of SOC registers at that
address so OEA64 will need a different starting address than BOOKE.]  This might result in
needing a trap64_subr.S 

Give my G4 has 5GB of RAM, 20 (4*5) of the 64 SLB registers to map just physical memory.
Add a few more for mapping I/O space and then even more to map "mapped" KVA space, almost
half of the SLB could be spoken for.  However that leaves 8GB of SLBs left to user space
which should be enough.