Introduction
Ever since I saw one of these devices about 10 years ago I had always wanted to own one, but were always out of the price point I’d pay for a 14 year old network appliance. Low and behold I was able to finally acquire the Gateway rebadged version (unknowingly a rare version) for $41 shipped recently in near perfect condition.
For those that may be unaware, Cobalt Networks, Inc originally released the Qube 2 in 2000 and in September 2000, Sun Microsystems purchased Cobalt Networks (finalized in December 2000), which in turn in 2003 ended the entire line. For more information on the story behind the development, I highly suggest reading the
Startup Story of Cobalt, a very neat story of bringing an idea to fruition (and to a $2.1 billion buyout in 4 years).
Specifications
The Qube and Qube 2 are interesting devices in that they run MIPS R5k cpus (150 MHz RM5230 and 250 MHz RM5231-250-Q respectively). Those following my blog know I am a huge fan of RISC cpus especially MIPS so it was neat for me to get to play around with MIPS in a machine outside of a Silicon Graphics workstation or server, on top of a semi-current operating system. I should note for those curious you can run
NetBSD on some SGI systems, but if you have a Silicon Graphics machine why wouldn’t you want to run IRIX?
My particular model has only 64MB of ram, which can be upgraded to 256MB via 2 128MB SIMMs. The Qube 2 requires a special 72pin EDO SIMM running at 3.3V. Before buying any ram second hand via eBay, Flea Market etc. be sure it is 3.3V. On eBay as of this writing there is one vendor with a stock pile of 128MB SIMMS for a fairly reasonable price – so if you’re in the market for a Qube or have one and running with the stock amount I recommend obtaining the ram now before it spikes because of the obscurity of the ram or worse the lack of supply anywhere.
The IO Board itself is interesting in that it connects to the CPU Board via what looks to be a 32bit 33mhz PCI Slot – meaning the 2 10/100 DEC 21143 Ethernet controllers, VT82C586 VIA ATA 33 controller and any PCI card in the additional slot compete for that ~133 MB/sec bandwidth versus other implementations of the time where each of those devices (or at least a few) would have been on their own controllers. Thinking about that further based on the aforementioned
Startup Story of Cobalt and their thinking of making the Qube Dual CPU – maybe the idea was to simply drop another CPU Board into the opposing PCI Slot while also allowing the OEM or customer to drop in a modem (like Gateway did) or another PCI card?
Another note – temptation might be to throw a Western Digital Black 7200rpm SATA II drive with a SATA->PATA adapter, the tiny exhaust fan on the back of the Qube might not be enough to cool the machine down let alone the additional power requirements on the older power supplies. I highly recommend one of the following: keep with a 5400rpm ATA drive from that era, IDE -> Compact Flash Adapter (slowest option by far) or SATA I/II SSD with a SATA -> PATA converter.
Inside the Qube 2
Pre-Installation Notes
Seeing as how things go away (especially when the product line has been EOL for 10+ years) I’m locally hosting the
Cobalt Qube 2 User Manual, which was helpful in figuring out how to open the Qube 2 properly.
In addition, for those curious the proper Serial Port Settings are 115,200 Baud Rate, 8 Data Bits, 1 Stop Bits, No Parity and No Flow Control. I found it gave me piece of mind to have the serial port connected to my PC during install because outside of the Qube 2’s LCD screen you will have no other indication of what is occurring.
A good SSH/TELNET/SERIAL/RLOGIN client for Windows is the
Netsarang’s Xshell, which is free for home/student work (I prefer it over PuTTY for those curious).
Installing NetBSD

I don’t want to simply regurgitate the very informative
NetBSD/cobalt Restore CD HOWTO, but to put it simply:
Download the latest ISO from the
NetBSD site. As of this writing, the latest is 5.2.2 released on 2/1/2014.
Obtain a crossover Cat5 cable or use an adapter and connect two Cat5(e) cables from the Primary Ethernet port on the Qube to your device
Burn the ISO Image to a CD, pop it into a laptop or desktop and boot from the CD (I used my HP DV7-7010US for those curious and during the boot process the CD will not touch your existing file system)
Once the Restore CD of NetBSD has finished booting up on your device, turn on the Qube and hold the
left and
right arrows until it says
Net booting
It took a few minutes from this point to the
restorecd ready
message being displayed on the LCD screen, then hold the select button for two seconds, hit the
Enter
button twice (once to select the
restore
option and the second time to confirm the restore)
From here it actually installs
NetBSD
, some files took longer than others (due to the size more than likely) and for those curious here are the files installed in 5.2.2:
- base.tgz
- comp.tgz
- etc.tgz
- man.tgz
- misc.tgz
- text.tgz
This step of the installation only took a few minutes and when it was completed the LCD updated to indicate success and that it was rebooting:

After this occurred, the first time I installed
NetBSD
, the LCD appeared stuck on
[Starting up]
. In going through the Serial Connection log – it appeared my SSD was throwing write errors during installation, I then swapped out the SSD for a 160gb Western Digital SATA drive I had laying around, performed the installation again and had a successful boot from the Qube itself:

The point being – if it hangs, hook up the serial connection upon attempting to reinstall
NetBSD
.
Post Installation
After unplugging my laptop and hooking the Qube 2 to one of my gigabit switches, I was under the impression
Telnet
was running and available to connect as
root
without a password. Unfortunately I was given the following error:
[bash]
Trying 192.168.1.193...
Connected to 192.168.1.193.
Escape character is '^]'.
telnetd: Authorization failed.
Connection closed by foreign host.
[/bash]
Doing some research,
RLOGIN
appeared to be the solution to at least get into the device so I could enable
SSH
, after switching from
TELNET
to
RLOGIN
I was in:
[bash]
Connecting to 192.168.1.193:513...
Connection established.
To escape to local shell, press 'Ctrl+Alt+]'.
login: root
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 5.2.2 (GENERIC) #0: Sat Jan 18 18:11:12 UTC 2014
Welcome to NetBSD!
Terminal type is xterm.
We recommend creating a non-root account and using su(1) for root access.
#
[/bash]
Immediately I went into my
/etc/rc.conf
and added
sshd=YES
, ran
/etc/rc.d/sshd start
and immediately sshd generated the keys and started itself.
Also something to make you do is set a password for
root
, which you can do simply by typing in
/usr/bin/passwd
.
By default
SSH
will not allow
root
to connect (for good reasons), so be sure to add another user. You can add another user that has
su
to root abilities with
useradd –m –G wheel johndoe
where
johndoe is the name of the username you wish to add.
Benchmarking Results
As anyone who has followed my blog for some time, one of the first things I do is port
jcBENCH
to the platform if it doesn’t already exist. Luckily,
NetBSD
came with GCC 4.1.1 and BSD derivatives offer a pretty neat C header
sysctl.h that provides a lot of the CPU/Architecture information very easily. After implementing the necessary changes and recompiling (wasn’t too slow to compile I have to say), I ran
jcBENCH
:
[bash]
$ ./jcBench 100000 1
jcBENCH 0.8.752.0306(mips/NetBSD Edition)
(C) 2012-2014 Jarred Capellman
CPU Information
---------------------
Manufacturer: cobalt
Model: Cobalt Qube 2
Count: 1x250mhz
Architecture: mipsel
---------------------
Running Benchmark....
Integer: 475.185 seconds
Floating Point: 2298.39 seconds
[/bash]
For those who recall I recently upgraded a
Silicon Graphics Indy to an R5000 CPU so I was very curious how the Qube running
NetBSD
would compare to the older Indy. I should note a fair comparison would be to compile
jcBENCH
on the exact or similar version of GCC in IRIX instead of the version of the 3.4.6 version in nekoware – so take these results with a grain of salt. The results were interesting in that the Floating Point performance was hugely impacted in the Qube (similarly to the R5000SC and R5000PC used in Silicon Graphics machines).
This led me to investigate the exact variants of the RM5XXX CPUs used in the Silicon Graphics O2, Indy and the Cobalt Qube. Low and behold the Qube’s variant runs on a “crippled” 32bit system bus and without any L2 Cache. This got me thinking of any other R5k series Silicon Graphics I had owned – my
Silicon Graphics O2 I received February 2012 came to mind, but sadly it had the R5000SC CPU with 512kb of Level 2 Cache. Also unfortunate, I sold that machine off before I had a chance to do an IRIX port of
jcBENCH in April 2012.
What’s Next?
The Qube 2 offers a unique opportunity of being a MIPS cpu, extremely low power requirements and virtually silent – leaving me to come up with a 24/7 use for the device. In addition the base
NetBSD
installation even with 64MB of ram leaves quite a bit left over for additional services:
[bash]
load averages: 0.02, 0.05, 0.03; up 0+00:28:26 16:30:24
18 processes: 17 sleeping, 1 on CPU
CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
Memory: 17M Act, 312K Wired, 5516K Exec, 7616K File, 35M Free
Swap: 128M Total, 128M Free
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
0 root 125 0 0K 2040K schedule 0:09 0.00% 0.00% [system]
628 root 43 0 4572K 1300K CPU 0:00 0.00% 0.00% top
583 root 85 0 16M 3944K netio 0:00 0.00% 0.00% sshd
560 jcapellm 85 0 16M 2916K select 0:00 0.00% 0.00% sshd
462 root 85 0 12M 2304K wait 0:00 0.00% 0.00% login
485 root 85 0 11M 1820K select 0:00 0.00% 0.00% sshd
603 jcapellm 85 0 4280K 1336K wait 0:00 0.00% 0.00% sh
114 root 85 0 3960K 1320K select 0:00 0.00% 0.00% dhclient
420 root 85 0 4552K 1204K kqueue 0:00 0.00% 0.00% inetd
630 root 85 0 3636K 1188K pause 0:00 0.00% 0.00% csh
458 root 85 0 4024K 1168K select 0:00 0.00% 0.00% rlogind
454 root 85 0 3636K 1164K ttyraw 0:00 0.00% 0.00% csh
159 root 85 0 4248K 1100K kqueue 0:00 0.00% 0.00% syslogd
1 root 85 0 4244K 1028K wait 0:00 0.00% 0.00% init
439 root 85 0 3956K 988K nanoslp 0:00 0.00% 0.00% cron
444 root 85 0 4216K 956K ttyraw 0:00 0.00% 0.00% getty
437 root 85 0 4224K 924K nanoslp 0:00 0.00% 0.00% getty
395 root 85 0 3960K 868K select 0:00 0.00% 0.00% paneld
[/bash]
Thinking back to the device’s original intent and my current interests of mobile device interoperability with “wired” devices, I’ve decided to go back to an idea I had in November 2012 called
jcNETMAP
. This Windows Phone 8 app’s purpose was to alert you when your set servers went down, utilizing the
Scheduled Task feature of the Windows Phone’s API without relying on any other software or device such as GFI Alerts, a custom Windows Service etc.
Taking the idea in a slightly different direction, take the following example of what I imagine is a typical home network:

Maybe add a few tablets, smart phones, consoles, DVRs etc. but the idea being you’re relying on your router’s internal firewall rules to protect your home network. With the advent of
DD-WRT among others people might be running a more tuned (albeit all around better version), but still how often can you say you’ve gone into your router and updated the firmware or checked the access logs for anything suspicious? Wouldn’t it be nice if you had some way of knowing traffic funneling from outside to your router could be analyzed like a traditional firewall/packet filter, if anything didn’t look right, send a notification to your smart phone and give you weekly analysis of the “unusual” traffic? I know you could probably setup an open source project to do packet filtering, but would it have the mobile component and run on hardware as low as a Qube 2? And first and foremost – it is simply a learning experience for myself to dive into an area I had never really gotten into previously.
Like many of my ideas – there could be some serious hurdles to overcome. Among others the biggest concern I have is whether or not the Qube 2 would be able to process packets fast enough on my home network to even make this possible – let alone connect into the Web Service which in turn would send the notification to your Windows Phone 8.x device quickly. Regardless of how this project ends up I am sure it will be worth the investment of time, if nothing else I will learn a ton.
In the coming days look for
jcBENCH
and
jcDBENCH
MIPS/NetBSD releases. Also I have 2 128MB SIMMS and a 30gb Corsair NOVA SSD coming this week to pop into the Qube 2 - will post any hurdles.
Any general questions about the Qube 2, feel free to comment below and I’ll answer them as soon as I can.