It came from route66 . . .

Several years ago, I started a database-driven car MP3 player project called route66. It was featured in MaximumPC magazine and earlier this year as the cover story in Maximum Linux Magazine, as it uses Linux and other open-source packages. The basic design philosophy was to leverage the power of a database to make a system that learns my musical tastes and plays songs I am likely to want to hear so I can keep my eyes on the road while driving.

The project ramped up quickly, and I began to abstract the concept for use in home systems as well as cars. Soon it seemed that embedded systems were really the right way to go, and I settled on the GCT-Allwell 1030N set-top box as an ideal platform for a home version of route66, because it could be made with no moving parts (hence, no noise).

What follows is my initial experiences getting Linux up and running on the GTC-Allwell set-top box.

The GTC-Allwell 1030N set-top box

Getting started

I purchased the 1030n with a 266MHz Nat Semi Geode GX1, 32 megs of ram, 32 megs of DiskOnChip, an IR keyboard and an IR remote. Honestly, I really didn't know what I wanted; I just bought. The total bill was $514 including shipping. They can be reached at 1-626-968-1116

If you don't add an optional 2.5-inch hard drive, the 1030n has no moving parts. There isn't a fan on the power supply or the chip, making this a very silent and therefore desirable part of a component stereo system or a/v setup. I, of course, intend to use this box to play MP3s in my home. And of course, having TV output is a handy side effect.

So how do you boot the thing if there isn't a hard drive? Well, there are actually two options here: you could boot over the network, but this requires some sort of external dependency that I didn't want to have; or, you could boot from the solid state disk (DiskOnChip) — which is what I decided to do. This requires a few tricks with drivers and a special lilo, but it all works out in the end.

Another option might have been to get a CompactFlash to IDE converter and boot with that, but I hadn't thought about this when I purchased my system.

When I got the system, I had no idea how I was going to get the DiskOnChip to be the primary boot device. Did the BIOS have to support DiskOnChip? Would it show up like a SCSI drive or an IDE?

I got the system up and running by attaching an old Windows 95 hard drive I borrowed from another machine and connected to the onboard IDE chain. To my amazement, it booted right up and ran Windows. Looking through the documentation, I had found that all the M-Systems (the company that makes the DiskOnChip) utilities run in DOS, so I would have had to get DOS running at some point anyhow. The utilities stepped me through initializing the DiskOnChip and getting it to show up under Windows. It worked right off the bat — really simple!

Driving the TV screen

Another question I had was how was this thing going to put a picture on the television? Did I have to flip something to get the video out to the TV? Would it run in text mode? Or just certain graphics modes?

As it turns out, both the SVGA outputs and NTSC outputs are running all the time (although, if you don't boot with a monitor, I think it may turn off the monitor output.) This happens to be a really nice thing because I don't have to worry about setting these things while in Linux.

Rear view showing video and other connections

Getting Linux into the DiskOnChip

Now the trick was to try and get Linux going on this thing.

I pilfered a Linux drive from another system and booted the box with that. Again, it worked with no special modifications. I had downloaded a PDF file and some drivers from the M-Systems website and put them on that hard drive so I would have something to fool with.

When the system came up, I took a look at what I had gotten from M-Systems. There were a few kernel patches to get DiskOnChip drivers into the kernel. I created the DiskOnChip devices in /dev/msys, patched up a 2.2.18 kernel, got the kernel compiled, installed it on the hard drive and rebooted.

The system came up with DiskOnChip support. I was ready to go.

The only problem was that I had an MS-DOS filesystem on the DiskOnChip and that just wouldn't do for Linux, so i did an fdisk /dev/msys/fla and created a Linux filesystem. The chip took all of 1 second to format with a mke2fs and it mounted just as any other hard drive would with a mount /dev/msys/fla1 /mnt/doc.

The next step was to try and get the DiskOnChip to be the primary boot device of the machine, so I started setting up a basic Linux file structure on it. I didn't have any hope for a successful boot without a fleshed out filesystem, but I wanted to see how the DiskOnChip would behave as the primary boot device.

There is an alternate to lilo called doc-lilo which is used to write the boot loader to the DiskOnChip. doc-lilo, like lilo, does two things: it installs the boot loader and points to the raw block on the filesystem that contains the kernel so that during boot, the loader can pass off to the appropriate kernel. The problem is, the kernel exists on the flash device and I wanted to point to the lilo.conf there instead of the hard drive that was the root filesystem just now. It turns out that doc-lilo supports the -r flag so you can specify root somewhere else. So I did a doc-lilo -v -r /mnt/doc and all was well.

I rebooted, and . . . (drum roll, please) . . . it didn't work. I got boot failure messages all over the place, no matter what I set in the BIOS as the boot device. So I figured it was probably time to start looking at the instructions.

After some reading I found that what I should be doing is booting in DOS again, and installing some code called doc42.exb which will “enable the DiskOnChip to boot”. Sounds easy enough, but for the life of me, I couldn't find the file doc42.exb. It wasn't on the CDROM I got, nor was it on the website. I was stumped.

After some time, I became a bit desperate. I had tried searching the net for this file, but to no avail. I again went back to the files I had downloaded from M-Systems and searched for everything ending in exb. Voila! There was doc123.exb. A far cry from doc42.exb, but I was crazed by this point. I ran the little DOS app that installs this questionable piece of code, and rebooted. To my utter amazement, the DiskOnChip was found as the primary boot device and it started to boot the kernel!

After I had shown everyone within earshot (whose comments ranged from “hey, that's cool!” to “yeah, and . . .?”), I set about building a working Linux filesystem for my new kernel. It must have taken over 100 reboots swapping back and forth between the hard drive and the DiskOnChip, but with the use of ldd and strace, I finally got a working tree with all the essentials. Now when I reboot the system, I get a usable Linux machine within 5 seconds! what a feeling!

Making the Ethernet interface work

The next task was to get networking going on this box. On the CDROM was an Ethernet driver for Linux, so I compared that file with the one that came with the kernel. There weren't any major differences. It seemed to be basically the same file. I compiled it up, but nothing I tried ever worked. I flipped debugging on and sat there trying the driver with every known optional parameter, but to no avail. I had already wised up and taken a look at the docs for the Ethernet, but nothing helped. The driver that was distributed was a Realtek 8139 fast Ethernet driver and there was even the PDF file for the Realtek chip on the CD.

So I ripped the case open and looked for the chip. Try as I may, I never found it.

Inside the box

However, I did find an Intel chip, so I decided to try the Intel drivers just for good measure. The first one I tried hard-locked the machine while trying to probe. When I rebooted, I tried the ether express pro 100 driver . . . and voila, it worked!

I had apparently been banging my head against the wall for 4 hours trying to install a driver for hardware I didn't even have! Then I took a look at the sales receipt and packing list. Sure enough, it said “Realtek fast Ethernet lan”. The only thing that mentioned something different was the 1030n PDF of the Users Guide, which was very nontechnical but which did list the correct hardware. Go figure!

The last frontier: sound

The last, and critically important frontier was sound support. Of course the box uses some weird, never before seen chipset for audio. So I chose the brute-force approach and compiled all the sound drivers that came with the kernel.

Surprise, surprise; the soundblaster compatible driver worked almost right out of the box. Initially the audio was choppy, but a switch from irq5 to irq10 in the BIOS and a recompile fixed that.

As it turns out, sound comes out the RCA jacks and the line out at the same time. That's nice, because it tends to behave more like a component sound system device this way. I was never a fan of using a stereo mini-din to RCA patch cord.

Closeup of rear, showing connector functions

Making it do stuff

As soon as I had a working system with network access, I was able to take the system home and continue to build the filesystem. It was critical to have nfs support so I could mount my MP3s, so I set out to start building my final implementation. I have a computer at the office with all my music on it which I intended to mount at home. I have a cable broadband connection at home which is more than fast enough to play 256KB/sec MP3 files from the net.

I only have one IP address at home, so I run a masquerading firewall on a Linux box to distribute the Internet connection. I plugged my set-top box in above my TV and got things up and running.

Watching as Linux boots on my TV

But when I tried to mount my MP3 collection from work on my new set-top machine, I was getting “connection refused” errors. Looking on the server side, my MP3 server was complaining that an insecure port was requesting a mount, so it was denying the connection. When my set-top machine was making requests, they were going through the masquerading firewall and being mapped to higher ports.

There was nothing I could do about making the masquerading happen on secure ports (< 1024) because this was a very early design decision of masquerading. As luck would have it, there is a flag in the Linux implementation of nfsd on the server side that causes the server to ignore the insecure nature of a high port and let the nfs mount go through anyway. I just needed to add "insecure" to the options for the share in /etc/exports. Basking in success

All in all, it's a nice system. The keyboard is really nice and incorporates a mouse. There is also another “TV” style remote control for which I intend to build a daemon to do simple tasks like play, pause, stop, next and previous.

Outside of a music player though, nothing beats the ability to wake up in the middle of the night, turn on the TV and have a shell to ssh anywhere in the world. To commemorate the occasion, I did my email on my television that night!

route66 is a work in progress. At this point I don't yet have a fully-functional home route66 setup, but work progresses. Check out the route66 home/car MP3 player project.

---

About the author: Anders Brownworth created the route66 database driven car MP3 player project, which has since been modified for home use. In past lives, Anders has been the Chief Web Guru for Imagine Media where, among other things, he built a purely Linux-powered 3 tier Web farm and had the idea to start Maximum Linux Magazine. Previous to that, he put the Dow Jones Industrial Average on Dow Jones Television by building a real-time rendering system out of a bunch of really expensive Silicon Graphics machines. When not fooling with technology, Anders can be found traveling the world in search of subjects for yet another great digital picture or flying helicopters in the skies above New York and San Francisco.

This article is copyright © 2001, Anders Brownworth. All rights reserved. Reproduced with permission.

---

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.