Category Archives: Rockbox

http://www.rockbox.org/ is a portable music player software/firmware

A thankful Rockbox user

I just wanted to share with you some very friendly and encouraging words I received in a mail from an individual that shall remain unidentified. It is actually rather unusual to get this kind of cheerful words as people who get things and enjoy them rarely get back, but instead we hear more from the ones who get problems or are otherwise unhappy. sansa e200R - looks almost like a e200 v2

“From someone not nearly so gifted and talented, thanks for your efforts to develop Rockbox on the Sansa e200 v2.
Your efforts are deeply appreciated by many, and I’m glad that there is someone as clever and kind as you working on this project in your spare time (which I’m sure is precious to you.)
Work on the project when you can, but don’t deprive your family of your time and presence – they are your most important treasure. I’m just a private individual, and I know this little expression of thanks doesn’t mean much, but here it is, just the same. All the very best wishes to you and your family for Christmas and the coming new year!”

Thanks a lot. (linkified by me)

I Solved the AMS-Sansas’ Firmware Checksum Puzzle

On my Sansa v2 web page, I’m collecting firmware binaries for these new targets in order to figure them out and kickstart the Rockbox effort for them. All firmware files have a .bin extension.

It is quite clear (by simple human inspection) that the first 0x400 bytes in each .bin file is a header (padded with 0xff bytes), as on the 0x400 index there is the ARM exception vector and then there’s ARM code following.SanDisk marked chip, an AMS AS3525

In the header there are numerous values, but the 32 bit value at index 4 immediately looked like it could be a checksum of some sorts.

We found two very similar firmwares for the M200 model, one for the European and one for the American in which the “checksum” values only differed by 2 even though there were clearly multiple (although not extensive) differences in the files.

A checksum that differs with so little indicates a simple algorithm. With something more fancy, like CRC32 or similar, a very small change in the files would cause a major change in the checksum value. Two checksum values near each other rather hinted on a simple addition, subtraction, xor or similar.

So I did a hexdump of the two files, cut off the headers and ran a ‘diff -u’ on them. That showed me that the first lines that differed (on index 0x15990) looked like this in the euro version:

00 00 a0 e3 a4 40 9f e5 00 00 c1 e5 04 00 a0 e1
00 fb ff eb 04 00 80 e0 45 10 a0 e3 01 10 40 e5

And like this in the US version.

02 00 a0 e3 a4 40 9f e5 00 00 c1 e5 04 00 a0 e1
00 fb ff eb 04 00 80 e0 41 10 a0 e3 01 10 40 e5

The differences are shown in bold above to make them more obvious. Plus 4, minus 2… Or the other way, minus 4 plus 2. That was almost too good to be true! The fact that these particular differences seemed to be 2 when the values were added just have to mean that the checksum is done with addition (if I was lucky). And if so, this was the only change that mattered to the header so therefore the checksum didn’t take the whole file into account…

SanDisk Sansa ClipI wrote up a small tool that would try out some variations of an “addition algorithm” with 32 bit adds and with 8 bit adds and then I tried with XORs instead to the same effect. Then it struck me that the value in the header at index 0x0c was not changing by a lot between firmwares and it had a number which was an index after the change I mentioned above, but before the subsequent changes

The program still didn’t spit out the right value when I restricted the algorithm to the size mentioned in the header… until I realized my tool didn’t skip the header when it did the checksum, and when I added a 0x400 bytes skip the values matched! It was as simple as that. Here’s checksum.c.

There are still a few other unidentified fields in the header.

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.

Rockbox on a Mobile Phone?

Sony Ericsson w580i has no RockboxMany of the hackers involved in the Rockbox project of course have had the dream to hack our phones as well one day to make them start behaving and working more in the way we want them to. Many times people have brought up the possibilities of (and the inherent problems with) porting Rockbox to a mobile phone. Mobile phones being even more locked down protected devices than your ordinary average mp3 player. These days mobile phones get more room for additional data (music and videos etc) and more music and media player abilities so many times Rockbox on the phone would make sense.

With the introduction of Linux-based phones, the chances have greatly improved. A Rockbox “simulator” can already be built for Linux, and that’s basically all Rockbox app-layer code that does everything Rockbox does but on a native Linux/cygwin instead of on a target device. It’s just about only SDL and a POSIX system needed.

While the Rockbox simulator so far in its 5.5 year’s life has had its primary use as just a simulator for Rockbox developers, it should be fairly easy and straight-forward to adapt it to a life as a stand-alone application. I figure the current work with get UI code adapted for use with touch screens also might help.

Here’s some platforms that might be suitable:

Motorola EZX

Motorola E680iMotorola has a series of phones usually referred to as the EZX phone platform (the Motorola E680, E680i, E680g, 780, A1200, ROKR E6, and ROKR E2 phones) that run Linux on an XScale PXA27x (ARM core) and have a working SDL port. A guy from Indonesia known as ‘blackhawk’ has ported Rockbox to it, but the details are scarce and the patches are infrequent and out-of-date. (Yes that’s a license violation.) I also just hate it when people store info about anything in nothing but a (weird and ad-packed) forum… Update: blackhawk just showed up in the Rockbox forum!

Android

Google’s huge effort is an operating system that is Linux-based (on ARM as well), so there’s basically just a fine SDL for it that’s missing before Rockbox can run on it. My suspicion is that Android is so java-focused and targeted so that SDL won’t be a primary goal for any phone that’ll run Android, and most probably it won’t be as easy to install and mess around with native code anyway.

OpenMokoNeo 1973

OpenMoko is another Linux-based operating system and environment for mobile phones, primarily for the Neo1973. SDL support is still only mentioned on their wish list.

Nokia N8x0

Nokia N810While the N800 series isn’t exactly a phone (although you can do IP-telephony over wifi with it), it is an “internet tablet” from Nokia that runs Linux and I would suspect that if it just becomes successful enough there will eventually be a phone based on that platform. And anyway, Rockbox for the N800 series might make sense even while it isn’t a phone… SDL is ported for this target (maemo).

Volunteers

Of course, all these are just possibilities that remain theoretical until there’s actually interested and willing volunteers that step forward and make it happen…

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…

Sansa V2 and View Roundup

There’s been eager activity in the Rockbox forums lately, and I’ve also had help from friendly guys over at anythingbutipod. But now things are much clearer on the Hardware front of many of the recent SanDisk Sansa players:

Sansa ViewSanDisk has released new or updated mp3 players this autumn, named Sansa View, Sansa e200 v2, Sansa c200 v2, Sansa m200 and Sansa Clip. I’ve summed up the situation on the pages those links take you.

All models except the View use the same main SoC chip now, the AS3525. Funnily, the new m200 isn’t called v2 or anything but it is still totally new hardware compared to the older model called… m200!

There’s no docs available for the AS3525 (yet), and the firmware format for it is still not figured out. There’s lots of work to be done, so we really can use all the help you can offer!

Has SanDisk gone AMS?

“skaosmentioned in the Rockbox forum that the markings on the e200 v2 SanDisk chip is very similar to the ones on the newer m200 models (as compared to the older m200 models which use different ones – at least marked completely different). It seems to imply that the m200 series have v2 models too.SanDisk marked chip, possibly an AMS AS3525. Picture from an e280 v2

But more interestingly, I downloaded the latest v4 firmware for the m200 series and looked at it with hexdump -C. While the file is encrypted or at least scrambled somehow (update: I was wrong the file is unencrypted, contains ARM code and strings), it features one plain text string at index 0x420:

AS3525_2_0.cr_5_0_develop.00020021010305000500

AS3525 is the name of a SoC from AMS (makers of the AS3514Stereo Audio Codec with System Power Management” chip used in the Sansa e200 series as well as in the Sansa c200 series) so to me it seems a bit too much of a match to be a mere coincidence! Oh, looking for UTF16-encoded strings, there’s one present that takes away all doubts: “AS3525/27 Demo Player“.

We’ll see what more we can dig up to really verify this theory. Fortunately, we managed to get docs for the AS3514 when some Rockbox guys visited the AMS HQ in Austria so hopefully we can get some for this thing too.

Now we have yet another firmware file format to figure out! ;-(

The SanDisk branded chip in the Sansa Clip does look very similar as well. If anyone has a firmware file for this target I’d be happy to check it out!

Rockbox on v2 Sansas

Sansa c200SanDisk apparently has released updated versions of their Sansa c200 and e200 series, called c200 v2 and e200 v2. Since Rockbox works pretty fine on the original c200 and e200 series and not at all on the new v2 players, users start to take notice!

The v2 series are claimed to be audible.com compliant (it spells DRM), which we originally thought would imply some sort of e200R style, but the first details about the c200 v2 internals seem to hint that the hardware is seriously changed and there’s hardly any hope left for a quick port to these devices.

To recognize a v2 of these devices, carefully look for the “v2” text on the backside or for “audible.com support” on the box.

We’re of course still eagerly awaiting published scans or photos of the internals of the v2 series, as well as getting our hands on firmware upgrades for them. Do they even use mi4 files?

In the mean time, the Sansa View isn’t even available in the stores here in Sweden yet! 🙁 Oh right, we still await scans of the View’s internals as well!

A Google T-Shirt

What doesn’t a man do when there’s a free t-shirt involved?

Google Summer of Code 2007 shirt

I was Google Summer of Code admin for project Rockbox, and it did result in some cool new code. As newbies this year we of course did a bunch of mistakes that we hope to get a chance to correct if we’re allowed to participate again…

I also volunteered as a mentor, but we had something like nine or ten guys stepping forward, we got a lot of students applying for various projects but in the end we were given four slots by Google so I ended up not having to mentor anyone this time.

Apparently, this involvement was good enough for me to be given a shirt, and it arrived in my mailbox today and I took a few crummy shots with my lousy camera in my phone and I thought I’d share them with you!

Google Summer of Code 2007 front print

Google Summer of Code 2007 back figure

On the backside there’s this weird face with a monster-like guy (much appreciated by my daughter!) with binary numbers in its mouth. It wouldn’t surprise me at all if the binary does mean something if we translate it to ascii… for a second or two I was about to investigate it, but then I lost my motivation and bah, why bother?!

Did anyone else check yet?