Hi Pete.  So you're not hanging around the salt mines any more?

	On Wed, Apr 18, 2001 at 20:35:17 -0700, Jason R Thorpe wrote:

	>  > 8042 at obio0 slot 0 offset 0x300060 not configured
	> 
	> Huh, PC keyboard controller.  All this time I had assumed that they
	> put the PC keyboard on a Zilog SCC.

Need to get a full dump of the OFW nodes to really know what's
going on there.

[...]

	Hey, this thing doesn't even boot yet ;-).  Given the pathologic OBP
	in this box (weird location, no CPU node etc), I'm somewhat cautious
	as integrating support (read: special casing) for this chimera going
	to be a pain.

	BTW, how much does kernel virtual space relocation cost?  I mean, if I
	move the kernel to, say, E8 (to avoid alignment problems) and keep
	virtual_avil at F008000 (past the OBP), what penalty it will incur?
	Is it possible to preserve that stupid OBP mapping by other means?

The big issue with moving the kernel above the OBP is that the sparc
kernel assumes a shared address space for user and kernel land.  Hence
addresses above KERNBASE are kernel, but below KERNBASE are user addresses.
If the PROM is below KERNBASE it will conflict with user addresses.

I think you have 3 options:

1) Put the kernel below F0000000.  This will severly limit both the size
of the kernel and userspace.

2) Put the kernel above the PROM, say at F1000000 but start userspace
at F000000.  This is probably the simplest solution.  For this you need
change things so either KERNBASE is at F0000000 but TRAPBASE is higher,
or TRAPBASE and KERNBASE are above the PROM but the end of the user stack
is below the PROM.

3) Bite the bullet and separate the kernel address space from user
address spaces.  This is what I did for sparc64.  To do this you
need to be sure that the MMU can handle this sort of thing.  You
need to fix copyin(), copyout(), [fs]u{byte,word,long}, and fix
some drivers that access userspace w/o using copyin()/copyout().

Eduardo