SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2

[wnmnkh]

Since we have two kinds of hardware versions for Clip, is this project aiming for version 1 or version 2?

I read some and it seems there are some hardware changes.

[funman]

Since we have two kinds of hardware versions for Clip, is this project aiming for version 1 or version 2?

Personally I own a ClipV1, and we have no details about the V2 except the firmware update recently released (which let us think that the ClipV2 comes with external RAM).

Parts of this project are common across all the Sansav2 models (including Clipv1 AND v2), since they are all based on the same AS3525 SoC.

But some development (like the LCD driver for example) is specific to each model.

Until someone comes with a ClipV2, we have no idea if all or some of the work done for the ClipV1 can be reused for the ClipV2

[atomikpunk]

Haha now that's good news, good work funman (though I deserve thanks for part of it ).

Now let's hack that damn flash, with the LCD help of course!

[funman]

Of course many thanks to you atomic punk !!

I think without you there would be nothing today which let us hope for a port!

I pushed my rockbox branch in the gitorious tree, so we can synchronize the work.

[saratoga]

Any implementation of the Simplified Specification may require a license from the SD Card Association, SD Group, SD-3C, LLC or other third parties.

I believe this will be a problem, so we rather should not look at this document at all.

I believe that refers to SD communication itself, not the datasheet (which is itself available under reasonable license).  Generally such things are safely ignored since they are effectively unenforceable against source code.

[tobi-lu]

That's what I thought as well...

In the end, we'll HAVE to use things that are in this document, because that's just how the SD communication works, no matter how we find it out.

[funman]

Hey guys

Now with the help of the LCD I'm sure that I can issue commands to the SD, but the protocol is still quite confusing to me.

I attach the code I use to power the device and send commands, but without my buggy commands

P.S. I uploaded a nicer HD picture of the lcd

[daniel_at]

WOW! Congrats to funman, atomikpunk and all other helpers! This is really great news.

I am just looking at the current GIT-Tree and feeling somehow unsure, how I cleanly get to a rockbox.bin file which i can stuff into the mkamsboot-makefile. Any Hints?

Now as we can print out more informations i would eagerly want to know where the interrupt-vector points, which handles the power-button. Because, if the "power-off" it is software driven, this vector would point to a region which is executed befor the OF (and now our rockboxloader) is executed from flash. Which will be the mask-ROM mentioned in the datasheet. According to the pdf this ROM can be mapped onto 0x00000000, but that seems unreasonable in our case, because here lies RAM which gets loaded with data from flash. So Sansa has maybe modified the Address which the mask-ROM maps to. Or the power-off is hardware driven - then forget about all i wrote

Daniel

[funman]

I am just looking at the current GIT-Tree and feeling somehow unsure, how I cleanly get to a rockbox.bin file which i can stuff into the mkamsboot-makefile. Any Hints?

You can use tools/configure and use the Clip target, bootloader only.
But before you should be sure to disable the lcd driver, because it is specific to the Clip: I don't think it will work on the E200.

Now as we can print out more informations i would eagerly want to know where the interrupt-vector points, which handles the power-button. Because, if the "power-off" it is software driven, this vector would point to a region which is executed befor the OF (and now our rockboxloader) is executed from flash. Which will be the mask-ROM mentioned in the datasheet. According to the pdf this ROM can be mapped onto 0x00000000, but that seems unreasonable in our case, because here lies RAM which gets loaded with data from flash. So Sansa has maybe modified the Address which the mask-ROM maps to. Or the power-off is hardware driven - then forget about all i wrote

Daniel

I think the power-off is software driven, because on the Clip I see a logo animation before it shutdown.
You can access the ROM at 0x80000000 (it is an alias) but I think it's useless because before being able to dump its content we need flash driver :/

Also I looked at the NAND / SD registers, because I supposed the ROM bootloader would leave them initialized, but they are reset to 0 .. so nothing useful here.

The LCD controller for the Clip is very similar if not identical to controllers for other rockbox targets, and it may be the same for the E200: check the controller model on the wiki page for E200 port

[atomikpunk]

Hi,

The LCD controller for the Clip is very similar if not identical to controllers for other rockbox targets, and it may be the same for the E200: check the controller model on the wiki page for E200 port

Hmm I really doubt it, if I remember correctly, the display controller on the e200 serie is an ILI-something. Anyway, it is a color display so it wouldn't work with the SSD1303

I think the power-off is software driven, because on the Clip I see a logo animation before it shutdown.

Oh that's some news, I didn't noticed. Though I think there is an hardware "recovery" power-off if you hold the power button long enough (about 4-5 seconds). I often used it with infinite loops broken test firmware

Gitorious is back, yay! (See ya later peeps)

[funman]

The LCD controller for the Clip is very similar if not identical to controllers for other rockbox targets, and it may be the same for the E200: check the controller model on the wiki page for E200 port

Hmm I really doubt it, if I remember correctly, the display controller on the e200 serie is an ILI-something. Anyway, it is a color display so it wouldn't work with the SSD1303

I meant another rockbox target (not the Clip) may have code for a similar controller.
But first you need the initialization sequence, which is specific to the E200v2.

I think the power-off is software driven, because on the Clip I see a logo animation before it shutdown.

Oh that's some news, I didn't noticed. Though I think there is an hardware "recovery" power-off if you hold the power button long enough (about 4-5 seconds). I often used it with infinite loops broken test firmware

Note also that if you boot the OF, you need to press the power button at least 4-5 seconds, but with my tests, 1/2 second is enough (when using my custom code).

So that "recovery" power off is customizable, and the time needed to hold the power button is extended by the OF.

Is it similar on E200/Fuze ?

[kugel.]

There's two power offs. The one where you see the goodbye logo, which should be software driven. The other, were the device is powered off immediately, is doutfully software driven, that'd render the purpose of "emergency power off" useless.

On the e200v1, this emergency power off was also hardware driven.

[funman]

I have put the patch for Clip port on the patch tracker: FS#9467

[Hillshum]

Don't get mad at me, but I think putting a hacked firmware image on my sansa has made it not support drm. Hey, I only free drm(aka Overdrive). So yeah. Bad for dualboot. I've looked for a solution and tried all kinds of things, including clean firmware, none have worked.

[Llorean]

Installing Rockbox on h300 also requires the loss of DRM support. If that happens, it happens, we're not going to get particularly upset about it. It would be ideal to find a way to avoid this, but if not, ah well.