http://www.rockbox.org/ is a portable music player software/firmware
In company facilities in the city of Ghent, Belgium, a fine crowd of Rockbox hackers have gathered to hack, chat, drink beer and design new stuff. Rockbox Devcon 2009 is in progress.
This year we’re entertaining the inhabitants of #rockbox and #rockbox-community with two webcam streams from ustream.tv. View both cams at once using rasher’s page.
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.
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.
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.
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!
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.
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…
What didn’t get included:
A more detailed list can be found in the Release notes for 3.2.
For the third year in a row, the Rockbox project participates in Google’s Summer of Code and has just now officially been accepted as a mentor organization.
This is a great chance for every student or others who have been looking for a good chance to join in an open source project, and in particular if you’re interested in embedded systems developing for (relatively) low-resource devices.
The Rockbox project also has a very large developer base, a very large community and a healthy and friendly surrounding that is welcoming to newbies.
If you’re even just the slightest intrigued, please don’t hesitate to read further on the Rockbox gsoc 2009 page.
The two previous years we’ve had four students each year with 15-20 applications.
Let’s make this a great gsoc year!
Frank Gevaerts and Jonas Häggqvist in the Rockbox project spent some time the other night when they should’ve been sleeping and made the Rockbox USB stack possible to fake being an iPod and thereby tricking iTunes to work with a non-iPod player quite transparently. As the picture shows, the target used here is a SanDisk Sansa e2x0 player…
This is still work in progress and not yet in SVN. Keep up with the bleeding edge activity in the #rockbox IRC channel on freenode!
The road to get a fully working and enabled mass-storage USB stack in Rockbox has been long and bumpy.
Back in the early days of mp3 players, they all had bridge-chips which basically meant that the entire USB handling was handled by a dedicated chip that also “took control” of the hard drive (right, most of the interesting players used hard drives initially) so Rockbox didn’t have to do much except hand over control, show something nice on the screen in the mean time and then when the plug was pulled, regain control of the drive again and continue working.
But similar to how early players used dedicated HW-solutions to do music playback and then ditched that for pure CPU-powered solutions, the HW-solutions for USB also died out and all recent models do USB in software.
The PortalPlayer chips being notorious for their complete lack of public docs were more or less considered impossibly hard to get USB working on by us. Until MrH came along 2006 and figured out that the USB parts of the PP5024 chip (used in the sansa e200v1 models) was identical to the USB core used by Freescale’s imx31 chip and there are public docs available for that.
The first step towards a software USB stack for Rockbox was taken in the 2007 gsoc, when Christian “austriancoder” Gmeiner took on the task. He went for a Linux-kernel inspired and quite ambitious approach that at the end of the gsoc project still didn’t quite work. The plan was at that point to primarily write a driver for the Sandisk Sansa e200 series, and secondary for other PortalPlayer based targets (such as ipods etc).
Enter Björn “Zagor” Stenberg who had a much more minimalistic approach. Not being pleased with the “big” approach Christian had provided, the existing code was simply cut out and replaced with the new leaner version. Focus was then to get something small and simple to work, and then add fancier layers or features later on instead of providing the architecture for that already from the start. The stack started to partially work for mass-storage.
USB wizard Frank Gevaerts joined the effort and worked fiercely on the thing and not only did he bring USB serial support (that does enable things like logf() support to debug rockbox) he also made the mass storage support almost reliable. The non-existing docs for the hardware made the remaining few flaws very hard to catch and the development of the stack stood still at this point for a great while.
Meanwhile, the USB stack could successfully be used on various new (in the Rockbox sense, these models are no longer new on the mp3 player market) targets like the Toshiba Gigabeat S and the Onda series etc. Parts of the Cowon D2 reverse engineering was greatly enhanced thanks to the USB stack as figuring out the FTL is even more tricky without a fine way to get data over to the host PC. All this proved that the stack itself worked nicely but that there were target-specific inits or setups that were missing for the PortalPlayer targets.
Of course the other new targets were not PortalPlayer based so it took efforts from clueful hackers like Vitja Makarov to implement the hardware driver for the TCC chips and Maurus Cuelenaere who did the driver for the Onda.
Now, in 2009 our reverse engineering hero Boris “dreamlayers” Gjenero banged his head against the problem and by doing really nice disassembly he figured out previously not done initiation sequences. These have now been committed to the Rockbox SVN respository, and the early tests of this are very promising showing the mass storage support to be very close to get supported “out of the box” on the PortalPlayer 5022 based targets now. The PP5020 ones still seem unstable, and we have no support on the PP5002 ones.
If things just proceed this fine, we’ll be able to ship Rockbox’s own USB stack by default in the upcoming 3.2 release!
At Wed, 25 Feb 2009 23:40:15 +0100, the USB code was enabled in the SVN code: “Enable USB mass storage on PP5020, PP5022 and PP5024 targets”
Updates: this post was updated several times to gain accuracy and truths pointed out to me by Dave Chapman, Björn Stenberg, Frank Gevaerts, Jens Arnold and others. Thanks!
I’ve mentioned the fancy distributed build system of Rockbox before, and now it just got even fancier as I’ve introduced a “blame” script that sends a mail to the commit mailing list (that gets mailed with a diff of every single commit) every time one or more builds in the automatic system show up red in the build table. Red builds are for errors (as opposed to yellow for just warnings or green for OK)…
The mail simply mentions that the builds are now red and who did the commit(s) that was included in the failing build. Due to the nature of it, it can be one or more committers and in fact there can be more commits than one from any of them. It’ll help us get alerted about the problems, and hopefully get them fixed again a little faster.
Only seven months after my initial post here, Maurus Cuelenaere strikes back with this video of current status for Rockbox on the Onda VX747.
Impressive!