Rio Karma

[LambdaCalculus]

Sorry, evilnick... you did give me the idea originally. That is true.

[ukre]

Monkey's Audio on a decrepit PortalPlayer target? You're kidding right ?

 

At least we can have Musepack and AAC, though!

Anyway, like I mentioned before, it turns out that the PP5003 in the Karma is very, very similar to the PP5002, except that (from what I read) the PP5002 had a "crippled" cache, and the PP5003 doesn't. So the PP5003 might be a little better performance-wise.

I'm going to hunt down datasheets and as much information for the unique hardware in the Karma, but since a lot of its internal hardware is also in some of the other targets we support (iPod and H10, I'm looking at you two! , that should make it less painful to start a port.

Oh yes, almost forgot... gotta see the firmware upgrade format on the Karma. I hope the Deities Above and Below are good to me and reveal that they're mi4-based!

Here's what I remember, FWIW... I did a lot of the HW design and bringup of the platform...

The 5003 is really similar to the 5020 in terms of register locations; it's more an early 5020 than a late 5002. Beyond that, I can't really help. Speed is the same as a 5020 pretty much. I think it had 96kB of IRAM vs 64kB on the 5002 and 128k on the 5020?

No idea what you mean by "mi4" based for the firmware. The Karma firmware is stored in flash (4MB - Intel 28F320) and is copied to RAM before being run, though resources live on disk ISTR, in a system filesystem. There's 16MB of SDRAM in there.

USB is a tweaked MSC (so it doesn't appear as MSC because of the FS) running essentially what is ReplayTV's journalled filesystem. No reason why you can't load the vanilla MSC code from Cypress onto the USB controller and just use it as a normal MSC device. There's a low-bandwidth side-channel (I2C) to the main CPU used for things like setting the time.

Flash upgrades are done by laying down a new firmware image at the start of the disk (I think the first 16MB is the "system" area) and sending a reboot command which forces the bootrom - stored in the locked-down area of the flash - to pull the mildly-encrypted image from disk and flash it. We used to also have a flash bootstrap image that'd just boot images from disk as this was quicker for development.

The 5003 also had onboard 100mbit ethernet, as supported by the shipping sw, but this was very flaky to work with and you had to use IRAM for everything... we had to jump through many hoops to get ethernet reliable and hooked up to the eCos stack.

Speaking of eCos, we ran the last version under the RHEPL, and submitted the diffs back to redhat per the license terms. Getting hold of the diffs would give you a lot of info about the hardware....

[GodEater]

ukre,

Thanks for the response - it's much appreciated.

Just a quick query on one of your points above :

The 5003 is really similar to the 5020 in terms of register locations; it's more an early 5020 than a late 5002. Beyond that, I can't really help. Speed is the same as a 5020 pretty much. I think it had 96kB of IRAM vs 64kB on the 5002 and 128k on the 5020?

All the knowledge we have of the register locations for *any* of the portal player targets we have is based on guess work / reverse engineering. Do you have any solid docs still lying around anywhere which can actually confirm any of this work we've done?

[ukre]

ukre,

Thanks for the response - it's much appreciated.

Just a quick query on one of your points above :

The 5003 is really similar to the 5020 in terms of register locations; it's more an early 5020 than a late 5002. Beyond that, I can't really help. Speed is the same as a 5020 pretty much. I think it had 96kB of IRAM vs 64kB on the 5002 and 128k on the 5020?

All the knowledge we have of the register locations for *any* of the portal player targets we have is based on guess work / reverse engineering. Do you have any solid docs still lying around anywhere which can actually confirm any of this work we've done?

Nope, 'fraid not. Previous company. I was just saying that what you have for the 5020 has more chance of working than 5002 stuff.

If you can get the eCos source diffs then you will get some register maps I believe, eg timers, IRQ controller, etc.

[LambdaCalculus]

ukre, we have a wiki page for the Karma here:

http://www.rockbox.org/twiki/bin/view/Main/RioKarmaPort

Any information you have for the Karma can be posted there, and would be much appreciated.

I still need to get a Karma in my hands; my coworker who showed me his refuses to part with it.

[GodEater]

Nope, 'fraid not. Previous company. I was just saying that what you have for the 5020 has more chance of working than 5002 stuff.

If you can get the eCos source diffs then you will get some register maps I believe, eg timers, IRQ controller, etc.

Any idea of who might be a good contact to talk to at Redhat? Also - which company were you submitting the diffs from? Rio? Empeg? Rough idea on dates so I could help them track the things down ?

Any help would be super appreciated!

[ukre]

Nope, 'fraid not. Previous company. I was just saying that what you have for the 5020 has more chance of working than 5002 stuff.

If you can get the eCos source diffs then you will get some register maps I believe, eg timers, IRQ controller, etc.

Any idea of who might be a good contact to talk to at Redhat? Also - which company were you submitting the diffs from? Rio? Empeg? Rough idea on dates so I could help them track the things down ?

Any help would be super appreciated!

Not really; RedHat shut down their eCos development years ago now. Maybe try emailing the Sourceware people who took it on? http://ecos.sourceware.com

The diffs were submitted from Rio, I guess around Karma launch time. Late 2003?

[LambdaCalculus]

Very much worth a try. Thanks for that, ukre.

(EDIT): ukre's link doesn't work, but this one does: http://ecos.sourceware.org/

[GodEater]

Just as a note for people watching this thread, I've today sent an email to the ecos discussion list enquiring about these patches.

[LambdaCalculus]

I now officially owe GodEater a beer of his choosing.

[linuxstb]

ukre,

Do you remember the exact license Rio used ecos under?  The only version of the RHEPL I can find is here:

http://ecos.sourceware.org/old-license.html

If I'm reading that license correctly, paragraph 3.2 is saying that Rio should have offered recipients of the executable (i.e. firmware binary) their diffs to the ecos source code, not just RedHat.

I've no idea who owns the Rio source code nowadays, but it seems the firmware is still being distributed via rioaudio.com, so I would interpret the RHEPL to mean that that organisation should also be offering the source code changes.

[pdh11]

The Ecos diff from last-rhepl is on the CD that came with every Rio Karma. Subsequent firmware releases didn't include any new modifications to Ecos itself. I believe that the licensing conditions allow anyone with that CD to repost the diff (but check first!); I don't have a copy to hand myself any more.

I don't like to pour cold water on this -- especially as I once said that nobody would ever reverse-engineer the Karma USB protocol, but people did -- but there are substantial obstacles to third-party firmware on the Rio Karma.

Firstly, the firmware is encrypted. I'm pretty sure that the bootrom will refuse to boot firmware images that haven't been encrypted with the correct key.

Secondly, datasheets on some of the chips used are hard to obtain without NDA. The Ipod Linux people have reverse-engineered some of the on-chip peripherals of the PP5002 and PP5020, but I don't know how different the PP5003 was.

Thirdly, there is a very serious silicon bug in the cache on the PP5003. If you ever flush the cache (or a region of it), it can get into a state where the wrong cache line gets written randomly somewhere in external memory. And, because the two CPUs on the 5003 are not cache-coherent, you end up flushing the cache a lot if you try and run stuff on both CPUs simultaneously. (Which you need to do, because the two clocks are locked together, so if you've got 90MHz worth of work to do, it uses much less power to run both CPUs at 45MHz than it does to do it all on one CPU and have the other doing 90MHz worth of nothing.) There is a workaround, which is only available because (bizarrely but fortunately) the 5003 memory-maps the entire internal logic of the cache controller, so you can go and rewrite all the tags and dirty bits to point to somewhere innocuous. Do not issue a cache flush, on either CPU, without following it up (running from IRAM) with the workaround sequence: arbitrary code or data will be overwritten, and your program will randomly crash. (Like, *cough*, the Karma 1.0 firmware did until we fixed it in 1.2.) This workaround is in the application code, not Ecos itself, and so does not appear in the ecos-last-rhepl diff.

Peter

[GodEater]

The Ecos diff from last-rhepl is on the CD that came with every Rio Karma. Subsequent firmware releases didn't include any new modifications to Ecos itself. I believe that the licensing conditions allow anyone with that CD to repost the diff (but check first!); I don't have a copy to hand myself any more.

Guess who's currently cursing they no longer have that CD anymore?

Firstly, the firmware is encrypted. I'm pretty sure that the bootrom will refuse to boot firmware images that haven't been encrypted with the correct key.

We have plenty of other targets where that's the case too - and we eventually surmounted those hurdles. I'm not saying that with a cocky swing in my step - we *may* not crack it - but it's certainly not foreign territory for us as a project - look at all the current PP502x targets we have which use the .mi4 firmware format (which is signed).

Secondly, datasheets on some of the chips used are hard to obtain without NDA. The Ipod Linux people have reverse-engineered some of the on-chip peripherals of the PP5002 and PP5020, but I don't know how different the PP5003 was.

We're hoping that the diffs (should we ever get hold of them) will help us out with the rest of the PP internals. We've managed to build on the work of the iPL guys and get a few more of the secrets out of the chips too - but it's slow ponderous work.

Thirdly, there is a very serious silicon bug in the cache on the PP5003. If you ever flush the cache (or a region of it), it can get into a state where the wrong cache line gets written randomly somewhere in external memory.

Thanks for the heads up - we'll bear it in mind

Peter

* GodEater wonders if Peter is someone else he met on his trip to Cambridge to visit Roger once upon a time...

[jacoby]

I have the CD, but looking through it I don't know what files on it would be useful to post.
I have plenty of webspace, should I just upload the whole thing?  I suppose that would be on shaky grounds license wise, but I really doubt that Rio would care all that much about a dead player's CD being available.

However, if going that route is not wanted, I will comply.

actually, if you dont like the whole CD being posted, please just edit out this link:
[Deleted] as per peter's comment below.

It is currently uploading but I need to go to work.  I should be done uploading around 2pm, eastern

[pdh11]

I have the CD, but looking through it I don't know what files on it would be useful to post.

The ones you want should have "ecos" in the name, like maybe ecos.tar.gz and ecos-last-rhepl.diff. Don't upload the whole CD; not everything on that CD is under RHEPL and, while Rio may be defunct, that just means there's nobody left there except lawyers...

Peter