The photo here was taken by “shotofadds”, and is the first proof of actual custom code running on the Cowon D2 target.

The D2 features a TCC7801 chip from Telechips as the main SoC. More HW details are in the Rockbox wiki page.

(The photo is slightly bigger in the forum but just as dark…)

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.

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

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.

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…

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

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

OpenMoko

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

While 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…

“skaos” mentioned 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.

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 AS3514 “Stereo 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!

SanDisk 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!