A rare breed
SPARCengine systems are among the less well-known SPARC systems out there. They
strike as an oddity in Sun's hardware catalog - neither a workstation nor a
server, these boards were intended to be used for specific automation tasks,
as were its 68020-based predecessors, the Sun 3/E.
Rumour has it that the SPARCengine boards were built to fulfill an important order from Eastman Kodak. After that, Sun left the embedded market, which allowed the usual players in that area, such as FORCE, to design and sell their own SPARC-based systems.
Quoting Computer Business Review on January 24th, 1991:
Sun Microsystems Inc has signed a technology transfer agreement with real-time specialist Force Computers Inc, under which the Campbell, California-based company will second source Sun's Sparcengine 1E processor board. The 1E is a VMEbus version of the Sparcstation 1 motherboard, and will be available from Force, with integrated SunOS and real-time capabilities, from March. Sun hopes the deal will increase its presence in the real-time VME applications market. Sun's long-term intention is to phase out VME board production, handing it over to Force, from which it will then buy-in boards to resell.
[...]
Another real-time software vendor, Wind River Systems, is set to announce the availability of its VxWorks real-time Unix kernel on the Sparcstation 1 VME board, while other real-time players Microware Systems Corp and Uniflex also plan to deliver Sparc implementations later in the year.
Here is what the Sun Hardware FAQ has to say about it:
Rumour has it that the SPARCengine boards were built to fulfill an important order from Eastman Kodak. After that, Sun left the embedded market, which allowed the usual players in that area, such as FORCE, to design and sell their own SPARC-based systems.
Quoting Computer Business Review on January 24th, 1991:
Sun Microsystems Inc has signed a technology transfer agreement with real-time specialist Force Computers Inc, under which the Campbell, California-based company will second source Sun's Sparcengine 1E processor board. The 1E is a VMEbus version of the Sparcstation 1 motherboard, and will be available from Force, with integrated SunOS and real-time capabilities, from March. Sun hopes the deal will increase its presence in the real-time VME applications market. Sun's long-term intention is to phase out VME board production, handing it over to Force, from which it will then buy-in boards to resell.
[...]
Another real-time software vendor, Wind River Systems, is set to announce the availability of its VxWorks real-time Unix kernel on the Sparcstation 1 VME board, while other real-time players Microware Systems Corp and Uniflex also plan to deliver Sparc implementations later in the year.
Here is what the Sun Hardware FAQ has to say about it:
SPARCengine 1 (4/E)
CPU: 501-8035/8058/8064
Bus: VME (6U form factor), SBus (1 slot)
Notes: Single-board VME SPARCstation 1 (or 1+?),
presumably for use as a controller, not as a
workstation. 8K MMU pages rather than 4K.
External RAM, framebuffer, and SCSI/ethernet
boards available. Code name "Polaris".
Pictures
(Click on the pictures to get larger resolution images)
The SPARCengine 1E is a single 6U VME board. There is enough room on the board
to fit:
- A 20MHz SPARC CPU (here, a Fujitsu MB86901A) with 64KB of write-through cache.
- An optional FPU (here, a Weitek WTL3170A).
- 4 megabytes of memory (some boards were fitted with 16).
- Two Zilog Z85C30 dual serial ports, one for the two serial ports on the right side of the faceplate, one for the serial keyboard and mouse, using the type-3 style connector (second connector from the left on the faceplate).
- A (canonical) AMD AM7990 LANCE Ethernet (third connector from the left on the faceplate).
- An (also canonical) Emulex/LSI Logic ESP100A SCSI controller (leftmost connector on the faceplate).
- A single, master capable, SBus slot.
- A VME bus interface.
The other side of the board is quite populated as well. Note the metal bar in
the middle, to improve the rigidity of the board.
Here is a slightly more recent revision of the SPARCengine board.
The main difference with the previous board is that the CPU is an LSI Logic
L64801 (which is an equivalent SPARC v7 implementation to the Fujitsu MB86901
found in the other board).
While there, have a look at the serial port connectors. These are a unique VGA-style 15-pin connector on three rows, and require tailor-made serial cables.
Sun Microsystems also built an expansion board, 501-8060. It is another 6U VME board, which gets connected to the SPARCengine board via the P2 connector (VSB-style), and sports 16 SIMM connectors as well as two SBus slots (slot #2 not being master-capable, in typical early SBus style). The memory connectors are divided into four banks of four SIMMs and accept either 1MB or 4MB SIMMs. A fully populated board can thus expand the SPARCengine memory from 4 or 16MB to a whopping 68 or 80MB.
Quoting CBR again, on January 31st, 1991:
Sun Microsystems Inc has expanded its Sparcengine 1E Eurocard family of boards with five new hardware and software products.
[...]
The 4E60-SRX SBus/RAM Expansion Board enables developers to add a second SBus connector to a Sparcengine 1E and has sockets for memory expansion; and the 4E60-16 Board uses 4M-bit memory chips to offer 16Mb.
[...]
The 4E60-SRX SBus/RAM board costs $900 with no memory fitted; the 16Mb 4E60-16 costs $12,000 including a two-user SunOS right-to-use licence, and both are available now.
While there, have a look at the serial port connectors. These are a unique VGA-style 15-pin connector on three rows, and require tailor-made serial cables.
Sun Microsystems also built an expansion board, 501-8060. It is another 6U VME board, which gets connected to the SPARCengine board via the P2 connector (VSB-style), and sports 16 SIMM connectors as well as two SBus slots (slot #2 not being master-capable, in typical early SBus style). The memory connectors are divided into four banks of four SIMMs and accept either 1MB or 4MB SIMMs. A fully populated board can thus expand the SPARCengine memory from 4 or 16MB to a whopping 68 or 80MB.
Quoting CBR again, on January 31st, 1991:
Sun Microsystems Inc has expanded its Sparcengine 1E Eurocard family of boards with five new hardware and software products.
[...]
The 4E60-SRX SBus/RAM Expansion Board enables developers to add a second SBus connector to a Sparcengine 1E and has sockets for memory expansion; and the 4E60-16 Board uses 4M-bit memory chips to offer 16Mb.
[...]
The 4E60-SRX SBus/RAM board costs $900 with no memory fitted; the 16Mb 4E60-16 costs $12,000 including a two-user SunOS right-to-use licence, and both are available now.
Porting OpenBSD to the SPARCengine 1E
Operating system choice on the SPARCengine 1E is quite limited. Besides SunOS
4.1, and maybe some early (< 2.5) Solaris versions, I am only aware of
VxWorks being ported to the SPARCengine 1E (as mentioned earlier).
It was time to broaden this choice by adding a free software OS to the list!
In fact, years ago, Jason Wright (jason@) had attempted to port OpenBSD to this board. But his board being only fitted with 4MB turned that idea into an exercize in futility. It did not take long to convince him to ship his board to me (this is the first board pictured in this document).
In fact, years ago, Jason Wright (jason@) had attempted to port OpenBSD to this board. But his board being only fitted with 4MB turned that idea into an exercize in futility. It did not take long to convince him to ship his board to me (this is the first board pictured in this document).
So, I installed the board in a VME card cage, powered it on, and it went live:
Trying to be a mix of both worlds, this board ended up being dismissed by both sides, and it is no surprise these boards have never been supported by any free operating system. Until now, that is...
SPARCengine 1E ROM Rev. 1.6, 4 MB memory installed, Serial #12648430. Ethernet address 8:0:20:f:9:35, Host ID: 61c0ffee. Selftest passed Initializing 4 Megabytes of Memory ... Completed Type help for more information okBeing a VME board, it shares the 8KB page size of the existing VME Sun systems (sun3 and sun4). And being a more recent design, it shares the FORTH OpenPROM of the desktop SPARC workstations (i.e. SPARCstation 1, and the rest of the sun4c family).
Trying to be a mix of both worlds, this board ended up being dismissed by both sides, and it is no surprise these boards have never been supported by any free operating system. Until now, that is...
To be honest, I had tinkered with this board in 2003, but could not get it to
load anything over the network.
It turns out this was caused by a stupid PROM bug which makes it fail to TFTP load code which size is an exact multiple of 512 bytes. After deliberately appending a few bytes to my code to make it unpadded, the PROM was sure more than happy to run it.
It did not take much for my code to die horribly. Systems using OpenPROM rely upon the compatible root node property to figure out which kind of system they are running on.
However, the sun4e board is similar to early sun4c here, and doesn't define this property. According to Sun, the machine is then a sun4c. Except that sun4c use a 4KB page size...
Fortunately, we can tell sun4e apart from sun4c by asking for the page size:
From the kernel, we need to get this result somewhere in memory, so it's just a matter of getting it written to a proper address:
With that knowledge, it is now possible to run a working boot loader, and hope to run a kernel.
It turns out this was caused by a stupid PROM bug which makes it fail to TFTP load code which size is an exact multiple of 512 bytes. After deliberately appending a few bytes to my code to make it unpadded, the PROM was sure more than happy to run it.
It did not take much for my code to die horribly. Systems using OpenPROM rely upon the compatible root node property to figure out which kind of system they are running on.
However, the sun4e board is similar to early sun4c here, and doesn't define this property. According to Sun, the machine is then a sun4c. Except that sun4c use a 4KB page size...
Fortunately, we can tell sun4e apart from sun4c by asking for the page size:
ok pagesize . 2000 okThe page size is 2000 hexadecimal, i.e. 8KB.
From the kernel, we need to get this result somewhere in memory, so it's just a matter of getting it written to a proper address:
ok pagesize ADDRESS l! okand then we can get it back:
ok ADDRESS l@ . 2000 okIn C code, this amounts to this:
char tmpstr[24]; u_long pagesize; pagesize = 0; /* paranoia */ snprintf(tmpstr, sizeof tmpstr, "pagesize %lx l!", &pagesize); prom_interpret(tmpstr);And we can check whether pagesize is 4KB (sun4c) or 8KB (sun4e).
With that knowledge, it is now possible to run a working boot loader, and hope to run a kernel.
At this time, I did not have an extra memory board, so I had to build a
stripped-down kernel in order to be able to fit in 4MB... and giving userland
some memory to use.
I eventually succeeded getting a kernel to load, although there were not enough pages left for userland to run without swapping like mad, and thus suffering a severe performance hit.
Yet I have been able to run single user, albeit slowly. Verrrrrrrry slowly.
I eventually succeeded getting a kernel to load, although there were not enough pages left for userland to run without swapping like mad, and thus suffering a severe performance hit.
Yet I have been able to run single user, albeit slowly. Verrrrrrrry slowly.
Eventually I got my hands on a memory and SBus expansion board, half-populated
with eight 4MB SIMMs. No need to run stripped kernels anymore!
Here is a boot log of the system:
As well the output of eeprom -p:
Now, all I need to do is connect an SCSI disk again and enable autoboot.
Here is a boot log of the system:
SPARCengine 1E
ROM Rev. 1.6, 36 MB memory installed, Serial #12648430.
Ethernet address 8:0:20:f:9:35, Host ID: 61c0ffee.
Selftest passed
Initializing 36 Megabytes of Memory ... Completed
Type help for more information
ok boot net bsd
Booting from: le(0,0,0)bsd -s
13000
>> OpenBSD BOOT 2.6
Booting bsd
boot: client IP address: 10.0.1.160
boot: client name: ayoggya
root addr=10.0.1.1 path=/netboot/ayoggya/root
Loading at physical address 5000000
3304984+485864 [52+151328+133536]=0x3e3268
[ using 285288 bytes of bsd ELF symbol table ]
console is ttya
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2013 OpenBSD. All rights reserved. http://www.OpenBSD.org
OpenBSD 5.4-current (GENERIC) #53: Sun Sep 15 01:26:57 GMT 2013
miod@credogne.gentiane.org:/usr/src/sys/arch/sparc/compile/GENERIC
real mem = 37478400 (35MB)
avail mem = 32989184 (31MB)
mainbus0 at root: Sun 4E/120
cpu0 at mainbus0: MB86900/1A or L64801 @ 20 MHz, WTL3170/2 FPU
cpu0: 64K byte write-through, 16 bytes/line, sw flush cache enabled
memreg0 at mainbus0 ioaddr 0xe8000000
clock0 at mainbus0 ioaddr 0xe4000000: mk48t02 (eeprom)
timer0 at mainbus0 ioaddr 0xe6000000: delay constant 7, frequency 1000000 Hz
auxreg0 at mainbus0 ioaddr 0xee800000
zs0 at mainbus0 ioaddr 0xe2000000 pri 12, softpri 6
zstty0 at zs0 channel 0: console
zstty1 at zs0 channel 1
zs1 at mainbus0 ioaddr 0xe0000000 pri 12, softpri 6
zskbd0 at zs1 channel 0: no keyboard
zsms0 at zs1 channel 1
wsmouse0 at zsms0 mux 0
sbus0 at mainbus0 ioaddr 0xf0000000: 20 MHz
dma0 at sbus0 slot 0 offset 0x400000: rev 1
esp0 at sbus0 slot 0 offset 0x800000 pri 4: ESP100, 20MHz
scsibus0 at esp0: 8 targets, initiator 7
le0 at sbus0 slot 0 offset 0xc00000 pri 6: address 08:00:20:0f:09:35
le0: 16 receive buffers, 4 transmit buffers
cgthree0 at sbus0 slot 2 offset 0x0 pri 7: SUNW,501-1415, 1152x900
wsdisplay0 at cgthree0 mux 1
wsdisplay0: screen 0 added (std, sun emulation)
vme at mainbus0 ioaddr 0xefe00000 not configured
led0 at mainbus0
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
bootpath: /sbus0/le0
nfs_boot: using interface le0, with revarp & bootparams
nfs_boot: client_addr=10.0.1.160
nfs_boot: server_addr=10.0.1.1 hostname=ayoggya
root on 10.0.1.1:/netboot/ayoggya/root
swap on 10.0.1.1:/netboot/ayoggya/swap
Automatic boot in progress: starting file system checks.
setting tty flags
pf enabled
ddb.panic: 1 -> 0
ddb.console: 0 -> 1
vm.swapencrypt.enable: 1 -> 0
kern.splassert: 1 -> 2
machdep.led_blink: 0 -> 1
starting network
openssl: generating isakmpd/iked RSA key... done.
ssh-keygen: generating new host keys: RSA1 RSA DSA ECDSA
starting early daemons: syslogd pflogd ntpd.
starting RPC daemons: portmap ypbind.
savecore: no core dump (no dumpdev)
checking quotas: done.
clearing /tmp
starting pre-securelevel daemons:.
setting kernel security level: kern.securelevel: 0 -> 1
creating runtime link editor directory cache.
preserving editor files.
starting network daemons: sshd sendmail inetd.
starting local daemons: cron.
Sun Sep 15 11:27:02 GMT 2013
OpenBSD/sparc (ayoggya.gentiane.org) (console)
login:
As well the output of eeprom -p:
Node 0xffec6618
name: 'Sun 4E/120'
idprom: 01610800.200f0935.0d041444.c0ffeef3.0880c2ab.58620820.44210c0d.972c5a97
clock-frequency: 01312d00
device_type: 'cpu'
fb: ffec6efc
Node 0xffec6670
name: 'options'
sunmon-compat?: 'false'
security-mode: 'none'
security-password: 'ff 79 f6 fd ff fe 7f bf ...'
security-#badlogins: '0'
selftest-#megs: '36'
oem-logo: 'bb ef 5a 72 3f ff 36 17 ...'
oem-logo?: 'false'
oem-banner: ''
oem-banner?: 'false'
vme-rerun: '0'
vme-intr: '0'
vme-slavemap: '0'
vme-a32map: '0'
vme-intena: '254'
vme-mailbox: '0'
vme-buslock: '0'
ttyb-mode: '9600,8,n,1,-'
ttya-mode: '9600,8,n,1,-'
ttyb-rts-dtr-off: 'false'
ttyb-ignore-cd: 'true'
ttya-rts-dtr-off: 'false'
ttya-ignore-cd: 'true'
sbus-probe-list: '012'
fcode-debug?: 'false'
screen-#columns: '80'
screen-#rows: '34'
net-boot-device: 'le()'
boot-from-diag: 'le()vmunix'
boot-from: 'sd()bsd'
auto-boot?: 'false'
watchdog-reboot?: 'false'
input-device: 'keyboard'
output-device: 'screen'
keyboard-click?: 'false'
sd-targets: '01234567'
st-targets: '45670123'
scsi-initiator-id: '7'
vm-server-slavemap: '0'
vm-server-addr: '0'
vm-ip-addr: '0'
hardware-revision: f5ffebd7.f4bb2e2e.ff7bbfff.b8f7e76b.2e2e2e2e.2e2e2e2e.2e2e2e00
last-hardware-update: d7debff7.46fb2e2e.b2f5ffeb.d7f4bb2e.2eff7bbf.ffb8f7e7.2e2e2e00
next-prom?: 'false'
testarea: '0'
mfg-switch?: 'false'
diag-switch?: 'false'
Node 0xffec667c
name: 'zs'
reg: 00000001.e2000000.00000008
address: ffd02000
intr: 0000000c.00000000
slave: 00000000
flags: 00000003
device_type: 'serial'
port-a-ignore-cd:
port-b-ignore-cd:
Node 0xffec672c
name: 'zs'
reg: 00000001.e0000000.00000008
address: ffd00000
intr: 0000000c.00000000
slave: 00000001
flags: 00000103
device_type: 'serial'
keyboard:
port-a-ignore-cd:
port-b-ignore-cd:
Node 0xffec67dc
name: 'sbus'
reg: 00000001.f0000000.04000000
device_type: 'hierarchical'
Node 0xffec6824
name: 'dma'
reg: 00000001.f0400000.00000004
Node 0xffec6860
name: 'esp'
reg: 00000001.f0800000.0000002c
intr: 00000004.00000000
device_type: 'hierarchical'
initiator-id: 00000007
Node 0xffec68bc
name: 'sd'
device_type: 'block'
Node 0xffec68ec
name: 'st'
device_type: 'byte'
Node 0xffec691c
name: 'vm'
device_type: 'network'
Node 0xffec6e24
name: 'le'
alias: 'le'
reg: 00000001.f0c00000.00000004
intr: 00000006.00000000
device_type: 'network'
Node 0xffec6efc
name: 'cgthree'
model: 'SUNW,501-1415'
device_type: 'display'
monitor-sense: 00000007
depth: 00000008
linebytes: 00000480
reg: 00000001.f8000000.01000000
intr: 00000007.00000000
width: 00000480
height: 00000384
cursorshift: 0000000c
address: ffd80000
Node 0xffec6984
name: 'vme'
reg: 00000001.efe00000.0000001d
intr: 00000002.00000000.00000003.00000000.00000005.00000000.00000008.00000000.00000009.00000000.0000000b.00000000.0000000d.00000000
device_type: 'hierarchical'
Node 0xffec69d8
name: 'p2bus'
reg: 00000000.10000000.10000000
device_type: 'hierarchical'
Node 0xffec6a20
name: 'eccmem'
reg: 00000001.fc000000.00000010
intr: 00000007.00000000
device_type: 'memory'
Node 0xffec6cf8
name: 'auxiliary-io'
reg: 00000001.ee800000.00000004
address: ffd0e000
Node 0xffec6cac
name: 'interrupt-enable'
reg: 00000001.ea000000.00000004
address: ffd0a000
Node 0xffec6c60
name: 'memory-error'
reg: 00000001.e8000000.00000004
address: ffd16000
Node 0xffec6c14
name: 'counter-timer'
reg: 00000001.e6000000.00000010
address: ffd06000
intr: 0000000a.00000000.0000000e.00000000
Node 0xffec6bac
name: 'eeprom'
model: 'mk48t02'
reg: 00000001.e4000000.00000800
address: ffd04000
Note the odd vm child of the sbus node.
Now, all I need to do is connect an SCSI disk again and enable autoboot.