> Hello,
> 
> [I'll stick my neck out on this, I can't find my 603* manuals. :-)]
> 
> I believe that the *BSD/PowerPC kernels should be able to run on 603 or
> 603e with a small change explained below.
I was under the impression that it did work for 603 already, but I
have not actually tested it.

> 
> As background, both the 603 and 603e handle misses to their VM
> Translation Lookaside Buffers in software - the processor traps to a
> small interrupt handler that either loads a new TLB entry or (if the
> entry isn't found) fudges things so that it looks like a normal `page
> fault'.  The code that handles these traps being contained in processor
> interrupt tables (somewhere in the 0x000..0x2fff address range).
Yes, but the code for both processors is the same for 603/603e.
Vector	Action
1000	itlb miss
1100	data load tbl miss
1200	data store tbl miss

> 
> At present, the *BSD kernels overrides these trap handlers with a
> generic `panic' trap handler.  I can see a number of solutions.
> 
> 	1.	Initially, I'd suggest that machdep.c:initppc()
> 		be modified so that it doesn't write over the
> 		603/603e TLB trap handlers.
> 		If the OpenFirmware is running in virtual mode
> 		then it will have already installed those handlers
> 		for you.  However, if the OpenFirmware is running
> 		in real mode then all bets are off :-)
No Openfirmware is known to run in real mode. OF must itself run in
virtual mode to be able to cache inhibit the device accesses.
It could have set up the client to run in real mode but that is slightly
different.

I also had the impression that the vectors mentioned above were in
the list of things that get restored when OF is called. Other
trap vectors must be restored, these must be as well.

> 
> 	2.	Later, the kernel can be modified so that it detects
> 		the processor and thence installs the approperiate
> 		TLB miss handler.
> 		The handler code is freely available from IBM/Mot's
> 		web sites, just make certain it is the most recent
> 		version.
Be careful with the version of the handler code used. I have not
seen the version available on the web sites, but the versions
in both the 603 and 603e manuals had some gross errors in them.

> 
> Any one see problems with this theory?
Why not just put a couple of instructions at the vector address
that jumps to the appropriate code in the kernel.
As long as the kernel is never greater that 2^ 25 in size
a single branch instruction with the offset filled in would work fine.
It would also be easy to restore for the change back to OF.

Dale