Originally Published: Friday, 3 November 2000 Author: Bastien Nocera
Published to: enhance_articles_hardware/Hardware Articles Page: 1/1 - [Std View]

Linux From The Hip: The Rio500 Project

Bastien 'Hadess' Nocera has turned in a cool interview with Cesar Miquel, Keith Clayton and Bruce Tenison, developers for the Rio500/Linux project. Read on to find out what was easy, what was hard, and what they have in store for the future!

During August 2000, I interviewed Cesar Miquel, Keith Clayton and Bruce Tenison by e-mail. These interviews, obtained for the French magazine Linux Pratique, were supposed to be background for an article on using the Rio500. For various reasons (including the installation of dozens of Sun boxes in North England), publication didn't occur. Cesar, Keith and Bruce are programmers on the Rio500/Linux project. More on the project can be found at http://rio500.sourceforge.net/

Hadess: First at all, who the heck are you?

Keith: Nothing like a nice broad question to start out. Let's see, I'm a Lake Tahoe ski/climbing bum who writes code for fun, enjoyment, and to finance my climbing and skiing habit! Seriously though, I'm a programmer at a small community college in South Lake Tahoe, CA. I maintain a minor x86 Linux box there. Mostly, I maintain and write custom code for a registration system running under OpenVMS, massage db info in this archaic VMS database called POISE, and move data back and forth between VMS and Win9x/NT. It's sometimes interesting, and sometimes mundane.

At home I run LinuxPPC . . currently a highly tweaked and updated version of their pre-R5 from back in 1998(?) I first made the plunge to Linux back in 1997, running LinuxPPC R4.

Other details . . I have a BS in math from Berkeley, and I'd have a master's in math if I ever finished my thesis. I've been writing code since I was about 13, and I'm 32 now. I probably would have been a CS major, except I've always found my own programming projects much more interesting and worthwhile than any assignment I was given.

Cesar: I'm a graduate student at the University of Buenos Aires in Argentina. I'm doing my PhD thesis on quantum computation. I've been programming since I was 11 for fun and profit. I've worked with industrial applications and scientific programs (for research). Lately, I've contributed code to open source applications (in particular a gtk calendar widget, an application to look at the system logs, and the "about" widget in gnome).

I've been using Linux for the past 5 years, and I only use Windows when I have to write an application for profit. My latest project was the driver and utilities for the Rio 500. I didn't want to use Windows whenever I wanted to transfer a song to it, so it was a high priority to get it working under Linux.

Bruce: I'm currently teaching industrial electronics technology at a two-year college in Alabama (U.S.). I have a bachelor's and a master's degree, both in electrical engineering from Auburn University. I've been with the Linux movement as an observer/user since the early days of the Linux kernel (back before these nice distributions!) I think this has been the most fun I've ever had on a project!

Hadess: Cesar already explained us the reason of his involvement in the project. What about you Keith and Bruce?

Keith: My involvement was a typical case of "an itch needing scratching." I'd just gotten a new rio500 and couldn't bear the idea of needing to reboot just to load it up with music. Somewhere along the line of Google searches for rio500 and Linux, I stumbled onto Cesar's e-mail address and wrote him to see if he had any info. At that point, Cesar was working on reverse engineering the comm protocol.

I offered to work on endian problems and the port to linuxppc. Cesar took me up on that ,and he hasn't been able to get rid of me since. In my mind, Cesar deserves a world of credit not only for getting the project rolling, but also for being receptive to outside help. Once the driver was on ppc, I was having such a good time that I stayed along for the ride. It's been a real pleasure to work with both Cesar and Bruce.

Bruce: It all stemmed from an initial e-mail that I had posted to the linux-usb list back in November of 1999. I bought the Rio mainly to see if I could hack it and learn how to communicate with a device using this new USB technology. Cesar saw my posting. He had already done a lot of protocol decoding and driver engineering, and we started hacking. I'm glad he did, since my wits were about at their end. I had even gone so far as to contact Diamond, in hopes of talking them into revealing the communication specifications for the Rio500. They didn't seem to want to part with that information.

It seemed like a great idea to get the thing working for Linux users, since it is an operating system that I run both at home and at work exclusively, and I know that there are a lot of others out there who want to be able to use a mp3 player device with Linux. There are some utilities to communicate with the Rio300, but there was no information on the Rio500. To boot Windows JUST to load my Rio500 seemed like a waste! Plus, both Cesar and Keith are (as we say down south) "my kind of folk," meaning, I like these people and they are fun to work with!

Hadess: How did you get started in this project? I mean, I don't think you wrote it blindly and it worked the first time. What was the process to get it to work?

Cesar: The first step was trying to understand enough about how USB works, since I didn't have any previous experience. For this, I basically downloaded the USB specs from http://www.usb.org/ and read them through. Once I had an idea of how USB works, I looked at the Linux pages to see what was already completed. Fortunately for me, the USB team had done a great job, and the basic routines to send messages and bulk transfers (the two things I needed to do) were in place. Actually writing the Linux driver was fairly easy. The hardest part was figuring out how to log the USB traffic. There are devices which will do it, but I didn't have access to one, so I had to do it through software. My idea was to look at the Windows device driver, figure out where in the program it sent USB messages, and somehow intercept them. This was really hard, but I got lucky. It turns out that on Microsoft's web site, there is an example device driver that shows how to transfer data through a bulk "pipe" (USB jargon).

Diamond basically took this file, modified it a little, and used that for the driver. That meant that I basically had the C sources to the code of their driver! So, with a disassembler I looked though the code, identified what was what, and then figured out a way to modify it to log the traffic. The final solution was to use a Windows debugger. There is a really neat thing about Windows - you can connect to another computer through the serial interface, run Windows on the machine, and drop into the debugger at any time to see the content of all the memory and registers from the other computer. Very cool!

So, I modified the driver so that it would drop into the debugger when it loaded. Then, I added breakpoints at the places where traffic was going through, and made the debugger print that information and continue. This way I was able to log the USB traffic. The rest is fairly easy. You basically have to analyize the traffic and figure out what is what. There's a lot of trial and error there. You basically do an operation, log the traffic. Do another thing, log what happens. Once I had an idea of the protocol, I tested it from Linux. Of course, now, it's much easier to log the traffic through software. There is an application that will do it for you! Here's the URL: http://www.jps.net/koma/.

Keith: I was responsible for the ppc port once the driver was working on x86. I knew we had a working driver, so I just needed to root out endian issues. It's so much easier to work on code that you know is "supposed to work". The initial driver code created some really nice hex dumps of information passing from cpu->rio and vice versa. Between examining the struct looking for multi-byte values and comparing the logs I was generating to logs generated by Cesar and Bruce, I was able to isolate areas where endianness became problematic. With the utilities themselves, most of the endian problems came in the font code. It was pretty obvious there were endian problems with fonts when I transferred a song and got a completely hosed bitmap on the rio display (though the song played). Again, Bruce had some great debugging code in place, which made my job much easier.

Bruce:I started with general testing of the driver and the utils that Cesar had created, and since my system was the flakiest at the time, my system became the measure by which we could say whether things worked reliably or not! After the initial testing phase, I began to work on the font loading code. We were looking for bitmap fonts that would be readily available, and I came across (along with Cesar's help) some specifications for the format of .fnt type font files. These, however, didn't seem to be to prevalant on the Internet, so I started looking at .fon file hexdumps, and developed a specification for the structure of the .fon bitmaps. We then wrote a loader, and with the help of Cesar and Keith we have them loading on both the PPC and the X86 platforms. After we had this working, I turned my attention to usbdevfs (kernel driver-less interface, basically using ioctl calls) and created another interface for the utils to use (and at this time created autoconf support for the Rio500 utils) mainly for testing of transfer rates.

Hadess: What are the plans for the future? The Rio600 will soon be out... Or you would prefer to shift to other projects?

Keith: As far as the rio500 utils, we're going to push to integrate the userspace and kernel driver interfaces so that they're more transparent to users. Basically, everyone can grab the same tarball/rpm and use it. If you have the modular driver, it'll use that or fall over to the userspace driver. This will hopefully make things less confusing for users, leave an easy transition to userspace drivers (if Linux-usb heads that direction in 2.5), and leave the module interface in place for the BSD guys and for those choosing not to utilize usbdevfs (embedded systems comes to mind). Other things we have planned are a separation of low level code into librio500 and higher level access code into librio500_api for ease of longer term maintenance, and to present a nicer interface for anyone writing gui interfaces. This will bring us to v1.0 at which point I think we'll enter maintenance mode. We've talked about the rio600 some, but I think the protocols are going to be totally different, in the way that the rio500 was different than the rio300. If this is true, my rio500 and I won't be much help. I think the rio600 is going to be a new project for a new group of people. I suspect I'll be moving into some new project after v1.0, but who knows . .

Cesar: I've been also working on a frontend which uses the API we have developed. I generally use this frontend (which is nicer than the console utils) but I've yet to correct some bugs, improve the interface so it's more functional, add smartmedia support and release it. I just don't have too much time lately.

Bruce: Ditto again. I've been away from the project for a bit, but I plan on helping with the parts of the project that Keith mentioned above. Maybe one day, I'll spend a bit more money on the Rio500 to buy some smartmedia support, but, I doubt I'll purchase a Rio600 at the moment. Ditto on what Cesar said about time!

Hadess: You are all part of this broader project that is Linux-USB, and that is very important to the desktop. What do you see as a part of the acceptance of Linux on the desktop, that isn't achieved yet?

Cesar: I think that there is still a long way to go for Linux to be accepted as desktop OS. Even though I love Linux and use it 95% of the time, I'm aware that most people can't do so. There has been a lot of progress on this, and the Gnome and KDE projects (with help from companies like Helix Code, Eazel, Loki, etc.) have done a great deal. Among the still unsolved issues are: companies not releasing drivers or even specs, installing software easily (setup.exe), printing, modem configuration, office compatibility (very important), DVD, etc. There are partial solutions to these all problems but there is much to do.

Granted, setting up hardware under Windows is also difficult, but still much easier than in Linux. But I'm confident that if we all contribute we will solve these problems. I'm glad I had the chance to do so with our project for the Rio 500.

Bruce: I see a common desktop environment as a problem that will need to be addressed. Also, more ported applications would be nice, at least some of which are compatible with Windows applications (such as Star Office). USB is a step in the right direction, but it will need to be as transparent as possible for the average desktop computer user. What I mean is, just plug in the device, have the driver (or if the userspace driver implementation is used, one doesn't have to worry about this) auto-load without user intervention. Last, I really wish we had a journaling filesystem available, but Linus says we'll see this in the in 2.5/2.6 series kernels.

Keith: Drivers, drivers, drivers . . Most of us using Linux right now love to tweak the system, and like the challenge of getting our hardware to work with Linux. I've had a blast with our project. However, the average user doesn't want to mess around with code or spend time searching the net for an open source driver. They want to buy a piece of hardware, maybe stick in a driver floppy to install a drive,r and have it work. When you can buy something like a rio500 and have the driver on the cd or buy an Epson printer and pull it out of the box and get it going quickly, based on packaged directions/drivers, then I think Linux will really start making inroads with the average user. Based on the culture around our OS and the multitude of platforms it runs on, I think open source drivers will remain incredibly important, but we need them "in the box" with hardware too. The two other things, I think, are pre-installation of Linux by bigname sellers of desktop machines, and an industry acceptable office suite. My mom has a Windows 95 PC at home. She never tweaks the OS, never. She truthfully could care less what the OS is - she just needs to see where her files are, and to be able to double click icons to start applications. If Linux were pre-installed with Gnome/KDE/whatever, she'd be just as happy. Her major reason for choosing Windows 95 was Word and Excel, and the ability to "easily" move documents back and forth with work. Yeah, yeah, StarOffice, gnumeric, "save as . ." . . you know what, most novice users don't want to think about that. With everything, they want it to just work. We need to keep that in mind.

Hadess: A last word, for the readers.

Cesar: Keep on using and improving Linux. Contribute with whatever you can and have fun! :)

Bruce: This sure has been a fun project, and I hope it will show that we can easily get together and make things work for our beloved operating system.

Keith: We live in exciting times . . when else in history could guys from California, Alabama and Argentina (not withstanding contributions from a multitude of others) collaborate on a project together so easily? The net, Linux, the open source movement as a whole have open unprecedented avenues for people to work together. Jump in and see what we're talking about!

Post-Scriptum: Since the interview, Ron Forrester has been working on the Rio600 support, available at http://pointless.net/~jasper/rio600.tgz Meanwhile Ron has offered a way for Cesar to get the Rio500 specifications. Browse the mailing-lists archives to know the whole story.


Bastien Nocera (http://mailto:hadess@writeme.com) is a system administrator, telecom engineer, programmer, journalist, and artist, all at the same time, but none of them really good. His works can be found at http://hadess.net/