Subject: Re: 486 SBUS for Sparc IPC
To: None <mcguire@rocinante.digex.net>
From: David S. Miller <davem@caip.rutgers.edu>
List: port-sparc
Date: 05/18/1996 00:07:21
   Date: Fri, 17 May 1996 22:31:22 -0400
   From: Dave McGuire <mcguire@rocinante.digex.net>

   On May 17, you wrote:
   > I bought one of these cards recently (used). Does anyone know any
   > hardware/interface details? It has no memory of its own.

     I have one of them too...It looks like a nice board...it's a
   486DX/25, and I've been told a DX4/100 works well.  BUT...The software
   (called SunPC) is difficult to locate and a big pain in the ass.  It
   uses loadable modules and expects to see BrokenWi...err, OpenWindows.

The Intel CPU on there executes in the same memory space as the Sparc
does, it has a DMA controller so that the Intel memory
pseudo-interface can take advantage of the SBUS bursts available on
the bus you plug it into.

Basically the Intel cpu executes Windows and whatever binaries, WABI
running on the Sparc controls what the intel cpu executes and takes
care of trap processing for the Intel cpu.  It also translates
outb/inb() or whatever I/O accesses done by the intel cpu into X
events to update the screen when Windows tries to access the "video
card" or other devices etc.

This board provokes a shitload of hardware bugs in the Swift processor
(processor found in sun4m SS5), and funnily this is the machine they
marketed the SunPC product in.  The bugs have mostly to do with timing
problems in the Swift cache controller wrt SBUS transactions, also
pte's can get bogus bit settings in them with SunPC running as well
(read as: it's a security hole, users can poke around in the kernel
address space without the proper kernel workaround code...).

Later,
David S. Miller
davem@caip.rutgers.edu