Tag Archives: Rockbox

Open Source, Rockbox

Rockbox in gsoc 2009

Gsoc 2009

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!

Rockbox

Rockboxitunes

6 Comments

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…

frankosansa

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!

Rockbox

Rockbox USB – A Long Journey

4 Comments

The road to get a fully working and enabled mass-storage USB stack in Rockbox has been long and bumpy.

Bridge-Chip

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.

Research

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.

Software Stack

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).

Made Working

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.

Not Yet Stable

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.

Stable?

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!

Commit

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”

Rockbox

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!

Rockbox

Blame game

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.

Rockbox

IT Politics, Rockbox

Apple patents another Rockbox idea

2 Comments

We’ve just read about Apple’s patent application (that seems to have been filed on July 17 2007) to alter the volume of a media player based on the external surrounding.

It’s funny how this was suggested to the Rockbox project already back in September 2002 and is logged fine independently by archive.org – and in fact also on Sourceforge where we hosted our request-tracker back then.

This is not the first time we see this consumer electronics giant patent ideas we’ve already implemented or discussed publicly a very long time before in the Rockbox project.

In 2006 Apple filed to patent a system to read up audio clips to the user to help menu navigation, a concept we at that time already had implemented and I must say was fairly polished in Rockbox. (Link to their patent application.)

Two obvious cases of where the ideas certainly were not new. Not that it tend to prevent patent applications, but still…

Rockbox

Rockbox

Binary size changes over time

Jonas “rasher” Häggqvist is the main man behind behind a distributed effort to gather a huge set of data on Rockbox builds of the past. Currently there are a number of build servers running “out there” providing info back to the master server about the bin size and ram size used by Rockbox builds (for a limited set of selected targets) of basically every single SVN revision since the dawn of time… Or more specifically almost 20000 revisions with rev 1 committed on January 17th 2002 (although the first files with contents were committed in r4, March 25th that year).

The repository was originally using CVS but was converted to SVN using cvs2svn in January 2007.

While this extensive work isn’t finished yet, you can already see the results appearing on Jonas’ site at:

http://rasher.dk/rockbox/graphs/

Rockbox, Technology

BYO rockbox player partly alive

Jorge “casainho” Pinto is known in the Rockbox circles as the main guy behind the “Rockbox Player” project which strives to build their own portable music player to run Rockbox.

They’ve made some progress latetly, and they’ve now run Rockbox far enough to display stuff on their screen:

Click the image for the full photo. Cortesy of Casainho himself. “I hope to take no more than 1 month to finish the port.“

The target is using an Atmel AT91SAM9260 at 200MHz and the screen is a 12bit color 128×128 one.

IT Politics, Rockbox, Technology

Rockbox 3.1

2 Comments

After three months of work since the last release, we manage to keep the schedule and ship Rockbox 3.1. The list of news since 3.0 include the following:

  • A bitmap scaler was added to Rockbox, which means that album art no longer has to be pre-scaled to the correct dimensions on your computer. See AlbumArt for more information.
  • The calendar plugin which has existed for the Archos units for a long time is now available on all devices equipped with a clock.
  • The spacerocks plugin which was removed from version 3.0 due to a major bug has been brought back.
  • Optimised MP3 decoder on dual-core targets, giving several more hours of battery life in most situations.
  • Optimizations for AAC and APE decoding
  • Backlight fading is now available on most targets.
  • When recording in mono, you can now chose between recording the left or right channel, or a mix of both.
  • It is now possible to configure which items are shown in the Quick Screen.
  • Several new features were added to the WPS syntax
  • The build system received a major overhaul. This only matters for people who compile their own builds.

Of course you can find a more detailed list in the MajorChanges wiki page, and the full release notes for 3.1.

My personal contribution has been very tiny this time around and I’ve basically just built the release builds and admined the distributed build system somewhat.

Rockbox