Initial mips-NetBSD jcBench and jcDBench Releases

Mar 16, 2014

After a little bit of work on both getting the platform specific code working perfectly - I am proud to announce the initial releases of both jcBench and jcDBench for mips/NetBSD. Both have 0 dependencies so just extract and run. Man pages and a true installer will come with the big 1.0 release (more on that at a later date).

You can download jcBench 0.8.752.0306 here.

You can download jcDBench 0.1.47.0312 here.

No known issues in my testing on NetBSD 5.2.2 with my Cobalt Qube 2.

Any suggestions, issues, comments etc. just leave a comment below and I'll get back to you as soon as possible.

TAGS

NetBSD and a Cobalt Qube 2

Mar 09, 2014

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:

1. base.tgz
2. comp.tgz
3. etc.tgz
4. man.tgz
5. misc.tgz
6. 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.

TAGS