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: ffd04000Note the odd vm child of the sbus node.
Now, all I need to do is connect an SCSI disk again and enable autoboot.