Tag Archives: Rockbox

50 hours offline

Several sites in the haxx.se domain and other stuff related to me and my fellows were completely offline for almost 50 hours between August 24th 19:00 UTC and August 26th 20:30 UTC.

The sites affected included the main web sites for the following projects: curl, c-ares, trio, libssh2 and Rockbox. It also affected mailing lists and CVS repositories etc for some of those.

The reason for the outage has been explained by the ISP (Black Internet) to be because of some kind of sabotage. Their explanation given so far (first in Swedish):

Strax efter kl 20 i måndags drabbades Black Internet och Black Internets kunder av ett mycket allvarligt sabotage. Sabotaget gjordes mot flera av våra core-switchar, våra knutpunkter. Detta resulterade i ett mer eller mindre totalt avbrott för oss och våra kunder. Vi har polisanmält händelsen och har ett bra samarbete med dem.

Translated to English (by me) it becomes:

Soon after 8pm on Monday, Black Internet and its customers were struck by a very serious act of sabotage. The sabotage was made against several of our core switches. This resulted in a more or less total disruption of service for us and our customers. We have reported the incident to the police and we have a good cooperation with them.

Do note that you could keep track of this situation by following me on twitter.

It’s good to be back. Let’s hope it’ll take ages until we go away like that again!

Update: according to my sources, someone erased/cleared Black Internet’s core routers and then they learned that they had no working backups so they had to restore everything by hand.

Decrypting ipods

Recently we’ve seen progress by the linux4nano guys in their quest to get custom code to run on an Ipod Nano 2nd generation. They’ve apparently managed to extract the bootrom off a 2nd gen ipod nano (my copy of their extracted data is here – a reminder on objdump usage: “arm-elf-objdump -D --target binary -marm [file]“). I believe their intent is to port Linux to the newer ipods. Possibly ipodlinux. They do mention providing the necessary info to Rockbox and yes we will welcome it.

A large crowd of Rockbox hackers have joined their IRC channel and have been hanging out with them and helped out discussing ideas and pushed them towards publishing their news and infos on how this all is accomplished etc. Their SVN repo hosts some (most?) of the tools made so far.

The Rockbox wiki page for nano2g has been updated and hopefully it will keep track of what happens.

There have been speculations, but I don’t yet know based on what facts, that this recent news and hacks will be usable on other recent (encrypted) ipod models.

Summary: very interesting progress has been made. Lots of it is still left to figure out. There seems to be a bunch of skilled people around and now we’re seeing information and documentation for this getting published so I can’t but to hope for a bright future!

Concepts of a new distributed build

It was time to make an overhaul of our distributed builds system for Rockbox. The one currently in place is quite fancy and it does build 106 builds in around 7-8 minutes, but during the years it has served us we have found a few areas where we want to improve.

The goals for the new system were primarily:

  • do all the builds faster
  • reverse the connection so that people can contribute clients easier
  • make a system that is more allowing for slower machines to contribute

The biggest weaknesses of the existing system:

  • The master uses ssh to the distributed clients, which forces them to have an accessible ssh server and port etc. It also makes it awkward for people behind NATs who wants to run more clients.
  • It only hands out a particular build to one client, so thus if a large build happens to get handed to a slow client towards the end of a build round, all the other clients will sit idle waiting for the last client to finish.
  • The build and the subsequent upload of results to the master are synchronous, so thus a client with a very slow uplink may spend a significant time on the upload before it can start the next build.

The  new system is currently in development. It consists of a server that runs on one of our main servers, and there’s a client script that each volunteer contributor runs on their systems.

The clients connect to the master on a dedicated TCP port, specifying user name, password, name of the particular client instance, what particular architectures the client can build and how many bogomips the client boasts. While bogomips is a bogus way to measure anything, we’ve started out using it for a rough way to sort the the build clients based on speed.

The clients keep connected to the server all the time. There’s a ping message from the master every N second of idleness to make sure the connection is kept alive. As soon as the master wants the client to do a build, it sends a message to it detailing exactly how it should build it and using what SVN revision. The client will then do the build at once, upload the results using HTTP to a dedicated place and then tell the server the build is complete.

The server knows about all builds to do at a  commit, what we call a build round. It has a rough “score” or “weight” for each build that grades them in a slow to fast order. When a build round starts, the server will first sort all builds based on number of times they’ve been handed out and as secondary sort key the “weight” of it. Then it loops over the currently connected build clients and hand out builds from the sorted build table. The server then continues to do that until all clients have three builds each to build. As soon as a build is reported to have been completed by a client, that client will get the next build from the sorted build list.

If a client connects to the server and the server deems the client to be too old (since it does specify its version in the handshake message), it will be told to update to a specific version instead and come back then. This way the server can update all build clients when important things are fixed.

The clients will soon start to get assigned builds that already have been assigned to another client. This is not a problem but in fact our intention. The client that completes the build first will simply tell the server, and the server will then tell all the other clients that build that same build that they should cancel that particular build.

A client that joins the server in the middle of a build round will simply get a bunch of builds immediately and join in. A client that disconnects during a build round simply won’t complete its builds and other clients will instead do them. The system is also tolerant against the fact that bogomips is lame to compare computers with, and that the build “score” may not be very accurate or even that some server will have very slow or very fast upload speeds at unpredictable times.

The build master itself does not know when to start a new build round. It simply knows about the concept and it knows how to tell clients to complete a round. To make the master to start a new round, you need to connect to the server’s listening port and issue a special command and provide a password and then you can tell the server to start a build of a specific SVN revision. Or to queue up a build to be performed after the current one if there happens to be one in progress already.

When a full build round is complete, a hundred or so builds have been done, and full packages and log files are now in a directory on the build server, the server will simply trigger an external script that then takes care of updating our build table etc. In fact, every single completed build will optionally trigger an external script to allow web pages or stats pages to get updated as we go.

This build system is currently pretty Rockbox-specific as this is the project and development system we’re writing this for, but there’s really nothing in this that must be this way. I’m sure that if someone (you?) wants to adapt this for another project, I’d be more than happy to assist and to help ensuring that this becomes a more generic distributed build system. Just raise your hand and step forward!

At the time of this writing, (primarily) me and Björn are still ironing out quirks in this new system to hopefully get it going live real soon…


Rockbox Devcon 2009 Summary

Rockbox Team Devcon in Ghent Belgium 2009

The Rockbox team that gathered in Ghent for this weekend of talk, hacking and socializing (drinking beer) is caught on this group picture. Click the image for a slightly larger version. Photo by Petur.

The people on the photo

The top line from the left: amiconn, markun, bertrik, gevaerts, GodEater, AlexP, Zagor, domonoky, Bagder (me!)

The lower line from the left: kugel, pixelma, scorche, petur

We did have a 2-hour discussion session on the saturday, and I expect to post an mp3 of it later on. The short and compressed outcome in plain text is found here. Petur was a great host. The facilities were nice, the hotel was great, the food arrangements worked out perfectly. A swell weekend!

As our tradition demands, we did bring out all our targets (portable music devices that can run Rockbox or at least have some code in the Rockbox repo) to be used as building bricks to create a Tower of Rockbox.

This first picture shows that we have a pretty wide selection of players in this room:

Rockbox Tower 2009 Device Overview

With all those “bricks” put in an imaginative order on top of each other, the result could look something like this:

Rockbox Rower 2009

you may enjoy comparing this building with last year’s creation.

More pictures from this year can be found in Petur’s collection and gevaerts’ collection.


I’ve previously blogged about the initiative to build an own open hardware platform that can run Rockbox fine, and just today I noticed their new site is up and alive at:


The hardware has changed quite significantly since the last blog entry of mine, and they’re now using a LPC3130 from NXP instead of the Atmel they had before, and I believe they’ve also changed codec/DAC etc. Me knowingly, Rockbox does not yet run on this newly produced board.

Lyre PCB

I should probably also add that this board is of course still quite far from being portable and there’s no news or info anywhere on how or if you can actually get one of these yourself yet.

Video: How to build Rockbox

I recorded a 10 minute screencast on how to build Rockbox from SVN (on Linux) just now. It’s something I’ve been meaning to do for a long time since I believe a lot of users need to get this shown rather than just a static text describing it. It really is easy and I think my video shows that.


The video is available as:

This recording was done using recordmydesktop. I did resize down my browser and reduce the font size to make it look decent in the smaller window. I consider this shot a bit of a test on how it works, and what I can do with it.

Rockbox gsoc2009

So finally it went public that this year Rockbox will be mentoring five students to reach their

individual goals and get their projects turned into realities.Gsoc 2009

The projects are new codecs, one is a new port, one is USB HID work and finally there’s this “make Rockbox an instrument” project.

Personally I’m admin for Rockbox gsoc effort for the third year, and this year I’m also co-mentoring a student (Robert Keevil) in his project to bring Rockbox to the Sansa View.

Let’s make this a great gsoc year!

HD is the thing

Thomson apparently brought the new mp3hd format for music the other day. “HD” is apparently the thing we need to have included when a new term is announced. Why does the world need another lossless music format?

It seems they’ve introduced a crafty dual-format thing where they stuff MPEG-4 SLS lossless encoded data in a new id3 XHD3 tag within the mp3 and then stuff a “regular” mp3 as the normal data in there. This way it is supposed to still work fine with existing and older mp3 players. Of course the total size of all id3v2 tags is limited to 256MB, which could be a limiting factor for it.

As usual, you can find a thriving discussion on this topic on hydrogenaudio.

Rockbox should of course be possible to at first use the mp3 parts and if this truly is an existing established lossless codec there’s a chance it might be able to play that part in the future.

Rockbox 3.2

The never-ending flow of creativity in the Rockbox project was today turned into a release that we label 3.2. The goodies this time include the things below. The three-months release cycle does prevent the list from growing terribly big…

  • Faster text/graphics rendering on colour targets and in the greyscale library, speeding up list scrolling noticeably on ipod Video.
  • PictureFlow supports all targets except Archos Player, and can function during playback on all non-Archos targets.
  • Add LCD sleep/wakeup for iPod Video (5G, 5.5G) which allows significant increase of battery runtime.
  • New game, Goban plugin.
  • Battery charging on Sansa e200v1/c200v1.
  • PictureFlow resizes cover art on load, and supports greyscale targets.
  • Preliminary support for Ipod accessories.

What didn’t get included:

  • The ‘natsort’ which sorts files with numbers as the number and not by ascii. This caused quite a lot of discussions and will be sorted out for 3.3
  • The Rockbox USB stack. It has been enabled in SVN build for several weeks already, but due to it causing some pretty drastic problems to some users we decided to play it safe and disable it in the release. We really hope it’ll be fine for 3.3.
  • Support for any new targets. The Gigabeat S, the Ondas and the AMS sansas aren’t terribly far away, but still not “there”.

A more detailed list can be found in the Release notes for 3.2.