Krups (microSPARC-IIep) support was committed on Dec 11, 2001.  I
meant to feed these notes through someone who can shape them into
something readable, but it seems there are no tech-writing resources
available for a while, so here's my brain dump - please excuse wrong
spelling, bad grammar and chaotic narration.



JavaStation-1, aka "Mr.Coffee".
JavaStation-NV, aka JavaStation-10, aka "Krups".

* Binaries

    ftp://ftp.netbsd.org/pub/NetBSD/misc/uwe/



* Linux JavaStation HowTo has useful hardware info etc:

    http://www.linuxdoc.org/HOWTO/JavaStation-HOWTO/index.html



* All JS


** Correcting PROM quirks

PROMs in all javastations has, mmm, peculiarities.  boot.net in
-current has an infrastructure to correct known problems in PROM
device tree, so that we don't have to make a lot of special casing and
work arounds in the kernel (e.g. missing or inconsistent "interrupts"
property etc).

While this could be addressed with an NVRAM script, this would be
inconvenient if you want to run a lot of javastations (e.g. seti@home
farm).  So instead of you typing NVRAM script on each unit to patch
known problems, boot.net will just do this job for you every time
before booting netbsd kernel.


** PC-AT keyboard/mouse

All JavaStations use PC-style keyboard/mouse controller.  NetBSD has a
MI pckbc(4) driver for it and attachment code for obio or ebus is very
easy to write, but we need to work out how to plug it into the rest of
the system.

Currently dumb PROM console works for OFW machines.  On Mr.Coffee with
OBP2 the PROM itself doesn't know how to handle pc keyboard, so you
have to use serial console for initial installation.

*** Mr.Coffee: TCX + PC keyboard/mouse

  * Xsun supports TCX

  * Xsun supports PC keyboard as Type4/US101A, we just need to
    translate pc scancodes to sun scancodes.

  * sparc kd driver knows sun keyboard, so pc keyboard presented as
    Type4 works (I'm using it on my headful Mr.Coffee in the office,
    leds etc seems work ok).

  * For mouse we need to convert PS/2 mouse protocol to Sun (mouse
    systems, iirc) protocol (needs to be done).

For Mr.Coffee this seems like the least possible effort, as existing
Xsun will be able to run on Mr.Coffee.  I already test-ran Xsun on
Mr.Coffee (with fake mouse driver to get it started) and at a first
glance it's ok - keyboard in X works.

I still have weird stray interrupts from pckbc (while kernel is in
idle loop), I haven't figured why they happen yet.


*** Krups: VGA (no text mode) + PC keyboard/mouse

For krups emulating sun kbd/mouse is not practical b/c we need a VGA
X-server anyway.  Since wscons needs text-mode vga it's not directly
usable (vga in suns don't support text mode), hence I'm waiting for
Bang Jun-Young to clean up and commit uwscons that supports raster
vga.  This way I hope to use MI drivers for all this stuff and use
XFree86 (VGA+pckbd+ps/2 mouse) as X-server.



* OFW machines

Krups is OFW only.  Some Mr.Coffee units are OBP2 and some are OFW.
This discussion refers to problems common for OFW and shared by Krups
and Mr.Coffee.


** Relocated kernel

OFW occupies virtual addresses starting at f000.0000.  The problem is
that this is exactly the va's where sparc kernel starts.  To start
working on hardware support I worked around this problem my relocating
the kernel to e800.0000.  It's a quick hack (just few lines) and it
allowed me to concentrate on the porting effort.

Kernel pmap initialization goes as usual, but then we just skip past
the PROM and all subsequent memory allocation happens from the area
after the PROM end.

This is very ad-hoc and is probably wasteful as well, so I this change
is not committed.

Why e800.0000 (not ef00.0000)?  because code in pmap.c uses fast
qzero() function to zero quad-aligned blocks with size that is a
multiple of 8 and using 'ef' breaks that constraint for some pmap data
structures.

The patch to relocate kernel to a different VA is available from ...

This hack is not committable to the tree.  This problem should be
addressed in a more sane way.


** special boot.net

You cannot use stock boot.net to boot OFW javastations for two
reasons.  First, boot loader must know the address the kernel is
linked at, and since kernel is relocated you need a boot loader that
matches the new kernel location.  The other reason is that OFW is much
more picky about the header of the "client program" (as OFW calls it).
For OBP we just fake an a.out header, but OFW needs a real executable.
Fortunately, OFW understands ELF, so we can build boot loader for it
without using elf2aout or some objcopy/ld scripts magic.

You can get prebuilt bootjs.net from ...

[Note: I will probably commit a small patch to build elf boot loaders.
Actually we already build them, but only to mangle them into a.out and
delete the intermediate elf version]



* Mr.Coffee

Stripped down SS4.

These machines has either OBP (2.30) or OFW (3.10, 3.11) proms.
Each version of PROM has its own quirks.

See section on OFW above for problems with OFW versions.

The OBP PROM seems to be a direct SS4 brain transplant.  It claims
that the box has zs at obio (while it doesn't) and it doesn't have a
node for pckbc.  The side effect is that the PROM itself cannot use PC
AT keyboard, so you can talk to PROM only via serial console.

NetBSD supports this machine since 1.5, but keyboard doesn't work at
all (there's no NetBSD driver for pckbc at obio and PROM
doesn't understand it either).


* Krups

See section on OFW above for problems with OFW.

Currently a basic set of devices work.

keyboard/mouse are not yet supported (see above).

vga in krups doesn't have text mode, so MI vga(4) driver won't attach.
use uwscons (vga_raster) when it's committed to the tree?

IGA1682 seems to be supported by XFree, and since krups is a PCI
system, it should be possible to built an XFree server for it.  [Jason
Thorpe committed pci(3) infrastructure to access PCI from user land,
there's a plan to convert XFree to use this infrastructure instead of
rummaging through the kernel memory directly].

Audio is cs4231 at ebus.  EBus DMA code is written and I have playback
working, but cs4231 driver need to be refactored to move DMA-dependent
code into bus-specific attachment so that the rest of thew code can be
shared between sbus and ebus.  Capture is not supported by the cs4231
driver yet.  [and it seems to have some problems with stereo playback].
Prebuilt kernel comes with (uncommitted) audio driver linked in.

MI com(4) driver has a strange problem with comstart() function that
result in stray interrupts being generated.  [I don't know if it's a
Krups problem or a bug in the com(4) driver protocol.  I'll post to
tech-kern shortly to discuss this problem].  I have a very simple
workaround.  Prebuilt kernel comes with this workaround applied.



* Netbooting


** OBP2 (Mr.Coffee)

Netboots like any other sun.  PROM loads "client program" (netbsd boot
loader) by requesting file "HEXIPADR.SUN4M" from tftp.


** OFW (both Mr.Coffee and Krups)

Uses DHCP to boot (I use ISC dhcpd 2.0pl5).  The only diffrence here
is that PROM finds a "client program" to boot via DHCP (netbsd boot
loader in our case).

E.g. here's a dhcpd.conf entry for one of my javastations:

    host brick {
      hardware ethernet 8:0:20:87:b4:a4;
      fixed-address brick.sparc.spb.su;
      filename "netbsd-sparc/bootjs.elf";	# file to TFTP
    }


Then the boot sequence is the same.  After OFW loads the file via tftp
sparc boot.net uses NFS to load the kernel, then the kernel uses
bootparams to find the root and gateway, etc.


SY, Uwe
-- 
uwe@ptc.spbu.ru                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen