Subject: Re: JavaStation1 saga continues
To: None <port-sparc@netbsd.org>
From: Valeriy E. Ushakov <uwe@ptc.spbu.ru>
List: port-sparc
Date: 04/19/2001 09:14:57
On Thu, Apr 19, 2001 at 04:50:09 -0000, eeh@netbsd.org 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.
ok dev /
ok ls
f002d248 sbus
f002b4a4 obio
f002816c virtual-memory
f0027e38 memory@0,0
f0017d28 aliases
f0017cec options
f0017c30 openprom
f0017bf4 chosen
f0017bb8 packages
ok .properties
idprom 01 80 08 00 20 87 b4 c4 00 00 00 00 87 b4 c4 a9
network-ok
network-error
model SUNW,501-3141
name SUNW,JDM1
banner-name JavaStation
breakpoint-trap 0000007f
#size-cells 00000001
#address-cells 00000002
ok dev /obio
ok .properties
device_type hierarchical
ranges 00000000 00000000 00000000 71000000 01000000
name obio
ok ls
f002bbf0 8042@0,300060
f002b73c su@0,3002f8
f002b6e4 eeprom@0,200000
f002b68c auxio@0,900000
f002b628 counter@0,d00000
f002b5c0 interrupt@0,e00000
ok dev /obio/8042
ok .properties
#size-cells 00000000
#address-cells 00000001
reg 00000000 00300060 00000008
00000000 00300060 00000008
device_type 8042
name 8042
model INTC,80c42
ok ls
f002cd60 kdmouse@1
f002c1f4 keyboard@0
ok dev /obio/8042/keyboard
ok .properties
reg 00000000
language EN
compatible pnpPNP,303
port-b-ignore-cd
port-a-ignore-cd
keyboard
device_type serial
name keyboard
ok dev /obio/8042/kdmouse
ok .properties
reg 00000001
compatible pnpPNP,f03
port-b-ignore-cd
port-a-ignore-cd
mouse
device_type serial
name kdmouse
Don't have OBP2 box handy.
> 1) Put the kernel below F0000000. This will severly limit both the
> size of the kernel and userspace.
Can you give me a hint why?
> 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.
As I wrote, I considered this. I decided that I want to beat the box
into submission first by going with 1) above and then do the acrobatic
exercises required for this layout.
> 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().
Wow. Way too risky a change for a very small (even in percents)
potential installation base.
SY, Uwe
--
uwe@ptc.spbu.ru | Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/ | Ist zu Grunde gehen