Tag Archives: Rockbox

What Can I do for Rockbox when not Programming?

As in every open source project, people who don’t program but who use and like Rockbox a lot tend to think and sometimes utter the words “I can’t code so I can’t help” when talking about what they can do for the project. But there are of course still endless amount of things we need help with. For example

Rockbox tinyFile good bug reports for bugs. Make an effort to really double-check the details, write up repeat recipes, try to repeat others’ reported bugs, fill in more details on the sparsely reported ones. Tell us when you can’t repeat already reported ones. We have so many bug reports and new ones come at a very high pace, that we need all the help we can get with sorting them out. Killing the bad ones as early as possible and getting the rest as detailed and accurate as possible.

Rockbox tinyHelp out with the manual. The manual covers a lot of functionality for a wide range of targets, and we constantly find bugs and missing stuff in the manual that you can help us out to both find and correct. The manual is what we constantly point newbies to and it needs to remain accurate and well phrased.

Rockbox tinyHelp out with the “support”. People pop in on the IRC channel all the time, we have >14,000 registered users in the forums, we have almost 1,000 subscribers on the mailing lists. You can help out by responding to questions, offer advice etc.

Rockbox tinyDonate money. As blunt as it sounds, we need money at times. The money we receive by donations are primarily used for buying new and more hardware to developers, but we’ve also used it for developer-related activities such as pizza at devcon!

Rockbox tinyDonate server resources and bandwidth. Our sophisticated build-on-commit system requires a fair amount of speedy and available (Linux) servers that can rebuild Rockbox on demand from the build master server. We can always use a few more of these, and we only need 2GHz+ machines with a few gigabyte of storage to spare and a reasonable bandwidth.

Rockbox tinyHelp test patches. We get a lot of patches, and learning how to build your own build and apply your own set of patches is quite easily done and really takes just a little effort. In fact, very often people also post binaries and make pre-built patched Rockbox packages available so many patches can even be tested without having to build anything on your own!

So as you see there’s no reason to be shy any more. Step forward and help us improve!

The Agony of Release

In the Rockbox project we haven’t had an official release in several years. We have >400K lines of code, some 60 committers. Some 300 patch contributors. At least 10,000 users, but probably up to 10-20 times that number.

We produce binary downloads after every single commit. We provide daily builds with a 30 day backlog. We provide a UI-based installer that can install the latest package for you.

So, we have a fair setup that provides releases in a fine way to everone interested. What we don’t have is a stable offer. Nobody can get a recent “stable” release (with a set of known bugs) or similar. We only have this endless series of “beta”-releases. We don’t have any particular push for doing a “real” release and among the developers there aren’t that many who think making releases is any fun, so we’re not really striving towards that.

The last time we tried to put together a release (to be called “3.0”) we decided to have a feature freeze period in which we’d only commit bug fixes and not do any new features. This lead to that most people simply stopped committing and developed their new stuff on the side, waiting for the freeze to go over. Only a few people did any actual bugfixing while we had some pretty serious flaws still in the code, so even with extended freezes we just couldn’t get the bug count down to a satisfiable level… we ended up just dumping the idea of a release 3.0 at that time, and it left some scars in the community that has so far prevented us from returning to this topic.


This said, today we’re more than 18 months further down the road, Rockbox runs on many more platforms, lots of code has changed and been improved since the previous 3.0 effort. Maybe it is time to once again make a release-attempt?

I think there are a few preconditions we need for this to succeed, including:

  • We need a single release manager person who single-handedly can decide when the release is finished. This person would also have the final say on the outstanding-issues list etc. We can’t manage to get consensus among this large amount of people for this black-and-white style of questions.
  • We need to accept that fact that some bugs just have to be in the release and we can live with them – after all most of these sorts of bugs have been with us for a very long time already and all of us have managed to live and use Rockbox fine for years in spite of their presence.
  • We need to accept and realize that most of “us” – the devs, the closest team of followers, will not use the release anyway as the day after the release we will provide a new set of spanking fresh binaries to download and use… We don’t do the release for us. We do the release to the huge audience out there who look for “stable” and “known to work” stuff.
  • Less people need to worry and have strong opinions about exactly what goes into the release or not. If we just get one release out, there will follow more further on that will get the stuff that is left out in this!

I am officially not volunteering to be a release manager! 😉

Rockbox on iPod Touch

iPod TouchWith the recently published jailbreak for iPod Touch, combined with the SDL port for iPhone there should be little in the way for running Rockbox on it as an application, pretty much in exctly the same way I mentioned how Rockbox could be made to run on mobile phones.

It seems a suitable place to start this venture is the iphone-dev project page.

While the iPhone and iPod Touch aren’t 100% identical internally, it seems they’re similar enough to make the differences possible to ignore. Also, the fact that what everyone does is build applications that run under the normal Apple-provided OS, there’s no need to know or learn how to poke on the actual hardware so subtle differences in audio chips etc is abstracted away by the operating system even for applications put on the unit this way.

Update nov 2008: With the recent developments on the linuxoniphone blog, it looks like an iPod Touch version of Rockbox is now a lot more likely to be possible. Still, nobody has yet volunteered to start this work and I won’t even say that it is likely that anyone will make an attempt.

AMS Replied with the AS3525 Data Sheet

SanDisk Sansa Clip

AMS was very friendly and replied to my data sheet requesting email very rapidly, and now I have the data sheet for the AS3525 in my possession. This is good news for an upcoming porting effort to the SanDisk Sansa v2 series of players, but it doesn’t make it all perfectly easy since we still don’t know lots of stuff in them.

The reply even contained these warming words:

I see your initiative increasingly successful and I just read a good review on PC Magazine. My compliments, an outstanding job!

If you have one of these players (e200v2, c200v2, m200 v2 or Clip) and you feel like joining this effort, do jump in on the forum and we’ll get something going! I don’t personally have one of these targets, but I’m pondering on getting one…

Rockbox on iAudio 7

Cowon iAudio 7We’re slowly building a team and effort in the Rockbox project to make a port to the Cowon iAudio 7 player.

It’s a 60 gram 4/8/16 GB flash player with a 1.3″ 160×128 TFT LCD, FM tuner, Telechips TCC771 MCU and a bunch of chips familiar to us from other existing Rockbox ports.

TMM already bricked his first player…

Update: this entry does not allow comments anymore. Go to the Rockbox forums to continue!

Rockbox on the iPod Classic?

Let me be perfectly clear on this:

Nobody has done any sufficient research or investigation on the iPod Classics for anyone to tell how feasable a Rockbox port is or not. But, based on the assumption that the firmware and design choices are similar to that of the Nano 2nd generation, it offers great challenges to any hacker wanting to go down this road.Rockbox

Many many people confuse this matter with the recently discussed Apple adding a new checksum to the itunes database, and then the subsequent “crack” of that system. This will only allow Linux-users to use these ipods. It certainly does not in any way make it easier to run alternative firmwares on them.

I would rather say that you should all take this as an indication that Apple really doesn’t care one bit about Linux users. In fact, they only care for those who buy their whole package and that package is Windows with itunes or MacOS with itunes. If you’re not buying that concept, you should avoid Apple. Yes I really mean that.

To get Rockbox running on these models or any of the other newer ipod versions, we need fearless and skilled people to get players, rip them apart and do some actual hard-core research on how their internals work and how the firmware is stored and how firmware upgrades are made etc. The same old new-rockbox port drill.

There might be “an opening” to this device using the DFU mode.

Update: during July 2009 some people in the #linux4nano-dev channel managed to run code on the nano 2g (thanks to an exploit of an buffer overflow) and since then there have been fierce activity and custom code seem to run on the iPod Classics too. Still a lot of work and problems to overcome for a Rockbox port to become reality.

DOS means Text Based

I find it very amusing that Windows users all so often refer to the command line as DOS, and I’ve tried to figure out how we still today frequently get to read users refer to the ancient operating system.

It was in fact still called “MS-DOS prompt” back in windows 98, as shown in this little picture:

windows 98 MS-DOS prompt

I found that even Microsoft themselves refer to the commands you use on the command line as “MS-DOS commands“, so perhaps this is a primary reason? Even the producers of Windows confuse and mix the terms “command line” and “MS-DOS”…

When they launched Windows XP they no longer called it MS-DOS Prompt, it was then plain and simple “Command Prompt”:

Windows XP command prompt!

We’ve also seen end users in the Rockbox project refer to the interface as DOS or DOS-style, and there is really nothing what so ever in common with MS-DOS in Rockbox. It is just (by default) a basic text-style interface. It is clear that to many people, a text-based interface be it a music player or a command line window, means DOS.

People are weird.

Picture Rockbox on a Camera

Canon Powershot A550Obviously the CHDK guys have working code for Canon‘s (and other’s) Digic II powered cameras, and reading their wiki they use plain arm-elf for the job and… yeah so does Rockbox and… yeah, well it certainly at least opens a possibility for a Rockbox branch for these toys!

Of course there would be porting involved and I don’t know how these cameras have on the audio front, but those are all just details…