PowerPC development from the bargain basement

The good, the bad, and the funky -- a first look at the Kuro Box

The Kuro Box promises something fairly interesting: a usable single-board PowerPC computer, for only US$160 -- when other PowerPC development boards often cost ten times as much. Peter Seebach guides you through setup and install in this developerWorks hardware howto.


Peter Seebach (crankyuser@seebs.plethora.net), Author, Freelance

Peter SeebachPeter Seebach has been using computers for years and is gradually becoming acclimated. He still doesn't know why mice need to be cleaned so often, though. You can contact Peter at crankyuser@seebs.plethora.net.

14 December 2004

You might think the Kuro Box sounds too good to be true. A PowerPC® development board, for roughly a tenth of the cost of other boards? And yet, the price isn't that weird. It's a little cheaper than x86 SBCs, but not outlandishly so. So, into the breach: Here's a report on what I discovered from getting one of these and starting to try it out. The name, we are told, means "expert box;" there is certainly some targeting here at experienced users.

What's in the box

What shows up in the mail is, well, the box. There's a little stand for it (if you want to put it standing up), a couple of screws, a CD, the documentation, and the box itself. The Kuro Box is a small plastic box, with little spots for diagnostic LED lights. On the back are a power cord, an ethernet port, and a USB port. That's it for connectors. It has a reset button, a switch which I think turns the ethernet port into an uplink port, and a power button (in front). The raw specs are pretty simple: 200Mhz PowerPC processor, 64MB of memory. (Which PowerPC? It's a Freescale® 8241, sometimes known as the "G2," which is sort of like a PowerPC 603e.)

The documentation is a bit of a surprise. It's a single folded sheet of paper containing the instructions... in Japanese! The only supported path is to run a setup program from a Windows® machine, after the hard drive has been installed. But to find that out, you have to go to the Web site (unless you read Japanese). (Actually, an astute reader can probably guess it from the list of Windows versions in the manual, and the text "CD (squiggle) Setup.exe" in the instructions.)

The distributor in the U.S. appears to be forwarding pretty much generic Japanese kits, then providing support on their Web site (see Resources).

Initial setup

The machine won't actually boot without a hard drive installed, and none is included. It takes a standard 3.5-inch one-third height drive, the kind you can get free in a box of cereal these days. (Expect to pay about US$80 for the cereal.) I used a spare 40GB drive, figuring it would be plenty. It was.

The user might be reasonably mystified. What's this "Setup" program going to do on my Windows box? Reformat my hard drive so I can then transfer it? Ask which hard drive to partition? No. What they've done is much more interesting. The on-board flash ROM is used to boot the machine in a fairly naive mode, where it will look for DHCP, or self-assign an IP address. Once it's up, the setup program can scan your network looking for it, and take advantage of its naturally wide-open setup to start programming it, specifically, partitioning and formatting the disk, and loading a minimal software install on it.

Once the setup program is run, the box should (in theory), reboot with a possibly-updated flash, and a root file system that can be mounted and used. In fact, the first time I ran it, it didn't do this correctly; I don't know why. I re-ran it, and it worked fine the second time.

This is a very interesting way to run setup. It's very much oriented at producing an end-user appliance; you get no control at all over the setup. Don't like their partitioning scheme? Tough. Want to load something else? You'll have to log in and do it later. The default arrangement is simple: you get a gigabyte of root file system, 127MB of swap, and the rest of the disk mounted as /mnt, with a directory (/mnt/share) ready to be shared out.

The software install is pretty minimal, in some ways: no developer tools, and no ssh daemon (everything is done through wide-open telnet). You telnet in as user root (password kuro). (Obviously, you should change this immediately.) The machine comes up sharing the bulk of the installed disk over AppleTalk and Samba, and running a Web server interface. By the way, when you telnet in to change the password, don't use a real password; use a dummy password that's not related to any password you actually use, so that when you have ssh set up, and want to set the password without sending it in plain text, you haven't given anything away.

The Web server interface is also in Japanese. The nice folks at Buffalo Technology distribute a set of patch files, which are discussed below, in Getting the English Web server running.

Installing more stuff

The first big candidate for installation is the big zip file full of binaries. However, the Kuro Box doesn't have an unzip utility. (It has gzip, but that only handles the first file in a zip archive.) So, you have to unzip the file on another system, and copy the binaries over somehow. I mounted the file system over the network and copied the files over, which went very smoothly. Then, telnet in and extract them. They're standard gzipped tar files, and both gzip and tar are already there.

One of the binaries is ssh. In fact, you can now set up sshd. This is pretty simple; you just need to add a link for it to the relevant rc.d directory.

Listing 1. Enabling ssh
root@KURO-BOX:/# cd /etc/rc.d/rc2.d
root@KURO-BOX:/etc/rc.d/rc2.d# ln -s ../init.d/ssh S30ssh
root@KURO-BOX:/etc/rc.d/rc2.d# sh S30ssh start

Of course, this won't really work. There are no pregenerated host keys, and the ssh script won't generate new ones by default. Edit that script, and remove the # character from line 14, right in front of the text AUTOKEYGEN=yes. Now try again.

If you're like me, being able to use ssh to access the box makes you a lot more comfortable. Now's a good time to change the root password to something a little more reasonable. I'd say turn off telnet access, but I don't trust the machine that much yet. Just keep it on a private network for now.

Surprisingly, there's still no unzip utility! But now you have a compiler, and you can build your own. Here's one set of instructions to do it:

  1. Make a working directory, called /mnt/unzip. Change into that directory.
  2. Download the unzip source from info-zip's FTP site. As of this writing, the URL is <ftp://ftp.info-zip.org/pub/infozip/src/unzip551.tar.gz>.
  3. Untar that archive. This will create a directory named "unzip-5.51". Change into that directory.
  4. Configure for a UNIX® build, by copying in the Unix-specific Makefile. The command is mv unix/Makefile .
  5. Run a make. For Linux, it appears that make generic does the right thing.
  6. Install the software. make install will install it all in /usr/local. Since that's in your default path, you're done!

Getting the English Web server running

This is based on the file called KuroBoxWWW.zip, found on Buffalo's Web page (see Resources for the download page). First, you will have to install an unzip program. This gives you a directory called WWW without htpasswd, a name reflecting their decision not to include the .htpasswd file for the root directory. The cgi-bin directory still has an original copy of that file, though, so you'll have to reset your password again if you changed that one.

There are a few other issues. All of the scripts are unzipped with mode 666, which is particularly inauspicious in that it lacks execute permission. However, the files are also DOS-format text files, complete with carriage returns. While Perl is smart enough to detect this and politely ignore them, the Linux kernel isn't, and tries to find a program named perl^M to run them.


If you are reading this prior to extracting the files, just use unzip -a. If you are facing a folder full of ^Ms (or forget to use the -a option), here's how to fix it after the fact:

Listing 2. Fixing the cgi-bin directory
root@KURO-BOX:/www/cgi-bin# for i in *
> do
> tr -d '\015' < $i > $i.new; mv $i.new $i
> done
root@KURO-BOX:/www/cgi-bin# chmod 755 *.cgi *.pl

With this done, you can visit the front page and poke around with the provided CGI scripts. You will probably want to set an htpasswd:

Listing 3. Assigning a Web server password
root@KURO-BOX:/# cd www
root@KURO-BOX:/www# htpasswd -b .htpasswd root newpass
Updating password for user root
root@KURO-BOX:/www# cd cgi-bin
root@KURO-BOX:/www/cgi-bin# htpasswd -b .htpasswd root newpass
Updating password for user root

After I ran these instructions, I found that the Web server directory had become world-writable. Furthermore, the Web server's configuration file specifies as a CGI directory /cgi-bin*/*. As a result, when I forgot the root password I'd set, I was able to create a CGI script that would be run by root by creating a new directory, /www/cgi-bin2/, and putting the script there. The original CGI directory was not world-writable, so the curious configuration file did matter.

Note that changes to the "administrative password" made through the Web interface do not affect the root shell account, only the htpasswd files.


Of particular interest is that the system thinks it has a pair of 16550 serial ports. Unfortunately, these are far from completely wired up. I talked to someone who did it, by taking apart and desoldering a USB to serial adapter to connect the Kuro Box's 3.3 volt, inverted, serial signals to another chip that used these -- and soldered the missing resistor onto the Kuro Box's motherboard. This is, perhaps, a little more "expert" than most people are hoping, but it is a way to get ttyS0 up and running, for people who want to watch the kernel boot, or log in on a serial console. Inexplicably, the relevant getty is already configured and running, even though most of the hardware you'd need to get a standard serial port out of this machine is missing.

The real key to expansion is the USB port on the back. That's just one port, but it's USB 2, so there's real speed there. The Kuro Box comes with a fairly limited selection of driver modules, but the ones you're most likely to need are present: a couple of serial port widgets and the standard mass storage driver. So, if you can't fit a big enough hard drive in the box, you can always add an external drive.

One other thing: one of the commands not installed is dmesg, so you have to browse /var/log/messages to see whether the system recognized a given device you plugged in.


The Kuro Box is the same hardware as the LinkStation network attached storage (NAS) device (see Resources). This shows in a few places. Some of the hardware decisions that might otherwise seem odd are perfect fits for that market. What this means is that the Kuro Box is not very much like the evaluation boards you would get from a PowerPC embedded systems vendor hoping to sell you on PowerPC development.

There are a few ways to look at this. If you're used to the x86 embedded systems market, where a US$200 or so computer will have standard serial ports, a flash memory slot, and maybe not much else, the Kuro Box seems oddly limited -- especially the lack of a serial port (given that the hardware is almost all there). If you're used to the PowerPC embedded systems market, where vendors often charge US$1,500 for an evaluation board, then it may seem a little less surprising that a few parts were trimmed.

The option of using a standard IDE drive is clearly part of the Kuro Box's heritage as a black box network storage device. Likewise, the on-board flash memory is what you'd expect from a box aimed at retail shelves: most developer-oriented systems would have a CF slot, allowing you to redo the flash on another system (see Resources for more on redoing Kuro flash).

Zork was an early text adventure game inspired by ADVENT® (aka Colossal Cave). It was written from 1977-1979 on a DEC PDP-10 by four members of the MIT Dynamic Modeling Group; three of those programmers then joined with some others to found Infocom™ in 1979. Their games were very popular, and even spawned a ZUG (Zork User's Group) and a best-selling book series of Invisiclues hints for their games.

Infocom launched in an era of competing hardware running competing operating systems (from IBM® compatibles to the Apple® ][ to the Atari 800 and Commodore's Amiga® and C64), when portability was a significant differentiator; this inspired Infocom to run on top of a virtual machine -- the Z-machine, which was named for Zork. Thus, you can still run Zork on virtually any system with the help of modern Z-machine interpreters like Frotz -- or you can also run it on the older hardware for which it was originally written.

Infocom was bought out by Activision® in 1986, and shut down in 1989. For more on the Infocom story, see the Wiki articles Zork and Infocom.

The box has some pluses. In a world full of SBCs with loose power leads, giant "wall wart" power supplies, elaborate power requirements, and exposed chips, it's nice to have a box where, once the hard drive is in it, it takes a standard electrical outlet (two-prong, even, for those of you in older houses) and Just Works. An upcoming developerWorks series will document a project that uses Kuro as a development platform, with all of the ups and downs that may entail -- so keep an eye out for that.

In the meantime, people who read Japanese, and thus have access to more complete documentation, have done some awfully neat stuff. While trying to find documentation on some parts of this box, I found dmesg output from a NetBSD kernel booting on one of these.

The Zork Test

An embedded system might not have a graphical display, but it generally has some kind of text console available. In a world full of expensive but often useless benchmarks, I have found an alternative benchmark. It is just as often useless, but it is very cheap: The Zork Test. Zork is a game which ran on everything from the C64 to a VAX. The way this was accomplished was a virtual machine, called the Z-machine. This simple virtual machine has support for virtualized memory access, so a game much larger than the C64's eponymous 64K of memory could be run. It provides a number of abstracted features which, conveniently, map onto modern embedded systems tolerably (see the sidebar About: Zork for more on Zork and the Z-machine).

To run this test, you will need a Z-machine interpreter: I chose Frotz (see About: Zork). In addition to being very small-footprint, Frotz makes a sort of standardized litmus test of whether a system's programming toolkit is reasonably complete. It's a good quick sanity check: stable C compiler, <curses.h> implementation, things like that.

Frotz can be downloaded from the maintainer's Web page (see Resources). Once you've got it, unpack it (it's a normal gzipped tar file), and just run make to build it. A make install will install it conveniently in /usr/local. Now, all you need is a story file for it to interpret. I use Zork I, which Activision allows people to copy freely these days -- a link to it can also be found in Resources. Once you've got the story file, just run frotz Zork1.z5 and enjoy! (I suggest you begin by examining the mailbox.)

You might expect that since the Kuro comes with a Linux environment, that it would pass the Zork Test with flying colors. Sure enough, it did (but this is not always the case, and it's better to know these things earlier rather than too late). Here are the Kuro's test results:

Listing 4. Frotz output
seebs@KURO-BOX:~$ frotz Zork1.z5
ZORK I: The Great Underground Empire
Copyright (c) 1981, 1982, 1983 Infocom, Inc. All rights reserved.
ZORK is a registered trademark of Infocom, Inc.
Revision 88 / Serial number 840726

West of House
You are standing in an open field west of a white house, with a boarded front
There is a small mailbox here.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into developerWorks

Zone=Multicore acceleration, Linux
ArticleTitle=PowerPC development from the bargain basement