Category Archives: Rockbox

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

Installing Rockbox on e200R is Scary

The initial way of installing Rockbox on the Sansa e200R series seriously scare away lots of people, and some of those who have attempted to perform the install really should better have been scared, judging from their desperate cries for help in the forum etc.

Another downside of the initial procedure was that it required the user to download a binary-patched version of the original bootloader, a bootloader that is the property of SanDisk that we have no rights to redistribute – especially not a modified one.

The current work-in-progress method is to build an installer program that can be uploaded to the player and then it does the necessary patching live in the target, removing the need to download anything that isn’t clearly a product of the Rockbox project.

We still lack a working way for this on Windows though, so the current plan is to initially provide a live CD with Linux and the e200R installer on for the Windows crowd, but we’ll see how things evolve…

Manufacturers Hate Customers

I’ve been involved in the Rockbox project since before it was named Rockbox and in fact long before the first code as written. I’ve contributed to it pretty much over the years and I have a fair insight in how most of the ports have been made and what efforts that are behind them. Today, Rockbox runs on around 25 different digital music players.

The first ports of Rockbox was (in retrospect) rather easy since we took it to architectures what were made with circuits and chips for which we could find documentation online.

Recently, music players as well as other consumer electronics are being made using products and circuits from companies that blatantly refuse to hand out documentation. Companies such as PortalPlayer (now Nvidia), Austrian Micro Systems, Samsung, ALI, NEC, Broadcom, Telechip, Texas Instruments, Sigmatel (to name a few) all make interesting and fun hardware but…

Let’s say I am looking into alternatives when creating new hardware. I want to build something new and cool. Something not done before, that would be portable and feature sound and an LCD and whatnot. I see what cool manufacturers there are out there and I can read their propaganda on their fancy web sites. So, I want to compare company A’s fancy chip with company B’s. I contact them in order to get to know as much as possible to be able to compare these beauties.

Data Sheet for a technical thing

No, you cannot get any docs. We will not tell you how our products are used until you sign up for a huge contract. These companies don’t only require NDAs to be signed and similar, they simply won’t let you get the docs no matter what if you’re a small player and are just interested in comparing and evaluating products.

I’ve contacted several companies with this purpose in mind. I work with embedded products for companies doing products using such chips, so I would assume I should be the kind of person these companies would respond to with an open mind and a will to sell me their stuff. But they clearly hate customers.

This problem is of course also tightly related with the eternal discussion of manufacturers not wanting to hand out docs to hardware they sell for PCs, such as graphic cards (AMD/ATI, Nvidia, etc) and network cards (Broadcom, etc). These companies usually hide behind a blurry statement about protecting their intellectual property and being afraid of ending up in the hands of the competition but that always and unconditionally end up with the arguments:

  • The competitors can get this info anyway by simply acting like a big customer, or possibly by buying the info from an existing customer. This protection only hides the info from the little people, not from the big guys with resources.
  • Getting information from the hardware based on a detailed description on how to use it is quite frankly a very ineffective way of cloning someone else’s design and not a likely scenario.
  • Development in these areas is at such a high speed these days, so getting the docs for the current hardware give hardly any competitive edge since the mere operation of copying it to make an own version of it takes a long time and by the time it would be done it would already be outdated.

I sometimes wonder if the chip manufacturers do this on demand from their bigger customers, the consumer electronics companies, to help them keep things hidden so that we – the general public – will have a harder time to modify and/or reverse engineer their products, which may lead to additional support issues for them.

We see this development of secret-docs going in the wrong direction. Samsung used to publish a lot of docs for their ARM-core based microcontrollers, but they no longer do so. Marvell bought the Xscale family from Intel and recently they took away all the public docs for them…

We see “open source” projects (like Neuros uses TI chips) go with these companies so that they can’t reveal all source code.nvidia chip

Luckily, not everything is darkness. There are occasional bright spots, as the other day when AMD announced their intention of bringing their open source ATI drivers up to speed with what could be expected of them..

So what is there to do about this? What can we “little people” do to change these big evil corporations? There’s really only one way: put the money where the docs is! Buy stuff from the good companies. Recommend your clients to release docs openly. Recommend your clients to buy hardware (parts) from companies that host their documentation publicly.

Rockbox build downloads Aug 2007

rockbox400.png

During August 2007, 71164 Rockbox zip files were downloaded from build.rockbox.org. All existing 25 different packages were downloaded and the download counters were distributed like this:

(Model, number of downloads, share of the total number of downloads)

  1. ipodvideo 17829 (25.1%)
  2. sansae200 9909 (13.9%)
  3. ipodnano 9110 (12.8%)
  4. ipodvideo64mb 7649 (10.7%)
  5. h300 3153 (4.4%)
  6. gigabeatf 3113 (4.4%)
  7. h120 2720 (3.8%)
  8. iaudiox5 2712 (3.8%)
  9. ipodcolor 2400 (3.4%)
  10. ipodmini2g 2286 (3.2%)
  11. ipod4gray 2098 (2.9%)
  12. h10_5gb 1380 (1.9%)
  13. h10 1322 (1.9%)
  14. ipodmini1g 1191 (1.7%)
  15. ipod3g 984 (1.4%)
  16. recorder 615 (0.9%)
  17. ipod1g2g 606 (0.9%)
  18. player 551 (0.8%)
  19. iaudiom5 341 (0.5%)
  20. h100 299 (0.4%)
  21. recorder8mb 256 (0.4%)
  22. recorderv2 227 (0.3%)
  23. fmrecorder 207 (0.3%)
  24. ondiofm 105 (0.1%)
  25. ondiosp 101 (0.1%)

Do note that #4 on the list is the bigger sized version of the #1 on the list, so taken all ipod video together they account for 35.8% of all downloads!

Also, consider that this list does not include any downloads done from the download.rockbox.org servers (that host the daily and archived builds), nor do we keep track of any svn update traffic etc.

Portalplayer targets are #1 to #4, more than 60% of the downloads…

The downloads split on main architecture:

  1. portalplayer 56764 (79.7%)
  2. coldfire 9225 (12.9%)
  3. samsung 3113 (4.3%)
  4. sh1 2062 (2.8%)

Rockbox on the e200R models

As Austin Appel posted on the Rockbox mailing list (early this morning, euro time), Rockbox now runs on the SanDisk Sansa e200R models.

In the end, it shows there really isn’t much difference between the two e200 versions. The Rhapsody models have a modified USB stack somehow that makes it hide the second “hidden” partition in which the bootloader and system software (mi4) is stored.

The Rhapsody bootloader doesn’t allow bootloader updates, and it also actually verifies the digital signature in the mi4 files, so in order to allow Rockbox we have to do a rather funny work-around: use e200tool to make it start the plain e200 bootloader and use that bootloaders recovery mode to upload a binary-patched version of the Rhapsody bootloader. The patched version puts back the old flawed signature check from the vanilla e200 series.

When the old broken BL signature check is in place, we can “upgrade” the target using the normal means and just put a Rockbox bootloader mi4 and the Sansa will then nicely load and run that.

MrH’s take on e200R

sansa e200RGiven the recent e250R i2c rom dump, MrH brought an analysis of what the rom actually contains and it is indeed the pre-bootloader code that loads the bootloader from the NAND flash and starts it. The perhaps most interesting part is that the e250R’s i2c rom dump is identical to the vanilla e280 one we have… meaning that they both load the bootloader the same way!

So here’s MrH’s suggested steps (keyed in on the wiki page by me) to convert your R model Sansa to make it capable of loading and starting the Rockbox bootloader.

Rockbox on c200 and mi4code

Mark Arigo announced his successful port of Rockbox to the Sandisk Sansa c200 series, and following those footsteps MrH brought mi4code 1.0.1 with built-in keys for the most recent c200 firmwares.

While on the subject of mi4 based players: If you are the owner of a Sandisk Sansa e200R model, please help us out a bit by running e200tool on your target and get a dump of the i2c rom for us!

(Update: we got a dump, thanks. No need for more at this point.)

mi4code 1.0.0

MrH mailed me the latest version of mi4code that now incorporates proper support for the recent Sansa 1.03.07 firmware (claimed to be beta, only available from some unofficial sansa fan sites, such as anythingbutipod.com), and I’ve uploaded it to the mi4code page.

Note that we still don’t advice anyone to actually use the unofficial 1.03 version as it has been reported to be bad in several aspects, such as the removal of MSC mode!

GPLv3 pains start now

rockbox Yeah, Rockbox ships as a GPLv2 licensed package, without the “or later” option for users to switch license at will. This has been all fine and dandy for a long time and Rockbox includes source from a busload of different other projects, licensed as GPLv2 and BSD etc.

Now, some of the projects Rockbox uses or wants to use are slowly turning GPLv3. First out being espeak, and the corresponding Rockbox patch for using it.

GPLv2 and GPLv3 are not compatible. We cannot ship binaries built with a mix of these licenses.

So, we’re now starting to see the real-world effects of the GPLv3 license. Slowly some projects are going v3, and we (as in the Rockbox project) must remain with their older v2 sources until we take the jump (more or less forced) to v3 – only to then have the reversed situation as then we can’t use projects that are licensed strictly GPLv2 (without the “or later”)…

Sigh. The world is a complicated place.