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

[Bagder]

Hey,

We can discuss many things for these players generically, since they seem to share a lot, not the least the main chip AS3525. Which is why I created this new thread.

Speaking of this chip, I've got the data sheet from AMS for it.

Things we need to search for:

1. Figure out the firmware format. There seems to be a header with checksums of some sort, we need to figure them out.

2. We need to see if we can get some kind of recovery mode or something, that will enable us to try possibly bad firmwares and yet be able to recovery and get back to a working state.

3. We have disassembly work to do to figure out stuff that isn't in the data sheet, like LCD (this is likely to differ between the players)

My "sansa v2" summary page: http://daniel.haxx.se/sansa/v2.html

[skaos]

Just a small detail: It looks like the Clip doesn't use SDRAM whereas the others do.

[dan_a]

I've ordered a Clip from Amazon, and I'm going to start on getting the simulator to compile.
I've not been able to find the screen dimensions on the web - does anyone know them?

EDIT:  ABI say that the Clip has a 128x64 screen.

[saratoga]

I've ordered a Clip from Amazon, and I'm going to start on getting the simulator to compile.
I've not been able to find the screen dimensions on the web - does anyone know them?

Given that the clip appears to have just 312KB of RAM, I'm not sure how feasible a rockbox port is.

[dan_a]

Does anyone know anything about the file format for the firmware on the V2s?
Obviously it isn't the MI4 files as it is missing a PPOS header.  It doesn't look like raw ARM code, although it is not encrypted.  There is some kind of checksum, as I tried changing one of the strings and upgrading, and the upgrade didn't take.

[Bagder]

Some initial trivial findings on the .bin format:

The first 0x400 bytes is clearly some kind of header,

The header data at 0x0 is about 0x20 long and is repeated (almost) verbatim at 0x200, and between those the bytes are all 0xff... At 0x400 you can clearly see the ARM exception vectors.

At index 0x0 there's 32 bit 0, at index 0200 there's a 32 bit 1.

I would expect the numbers at 0x4 and/or 0xc to be some kind of checksum.

The bin files are all exactly 0x500400 bytes large except the e200v2 one, but I'm not sure that image is correctly saved/dumped/extracted.

[Bagder]

index   description (value is 32bit unless otherwise noted)

0x0     0
0x4     checksum?
0x8     type? (e4/e8/ed/ea)
0xc     some kind of value that is hardly a checksum as the value differ in
        the four files only between 0x01c6ac and 0x01d854. Possibly it is a
        16 bit value with 0x0e being another 16bit value always set to 0x01!
0x10    0x03
0x14    16 bit checksum3 ?

        Interesting detail about the byte at 0x15: it is 0x22, 0x23, 0x24 and
        0x25 in the files we have...

0x16    16 bit zero
0x18    0x40
0x1c    0x01

0x3c    0x5000 (in the e200 alone)

0x200   0x01
0x204-0x021f same as 0x04-0x1f

0x023c  same as 0x3c (in the e200 alone)

0x400 ARM exception vector and code following

(at the end of the image there are nice "de ad be ef" paddings! :-)

[dan_a]

(at the end of the image there are nice "de ad be ef" paddings! :-)

With 4 bytes at the very end - another checksum?

[Bagder]

With 4 bytes at the very end - another checksum?

Weirdly enough, the m200 and c200 images don't have those extra 4 bytes

[Bagder]

I figured out the checksum on index 4 and it also uses the value at index 0x0c (I wrote a small tool that can reproduce the value). See my description in-progress:

http://daniel.haxx.se/sansa/v2.html

[Bagder]

Didn't someone already provide a fdisk -l output for one of the v2s? Has anyone tried to scan the disk for the firmware image?

[rondestvedt]

I'd say the main problem is that nothing much is actually going on, it is much more talk about what is going on or what could go on...

Well, I'm extremely interested in making this port happen, I just don't have a lot of experience with this sort of development...

What's the next step?  From what I've seen the next big hurdle is figuring out how to upload new firmware to the v2s.  Unfortunately I didn't have a USB monitor set up when I updated my e250v2 using the SanDisk's updater.  It does not appear that there's a way to downgrade using SanDisk's updater and who knows when a new OF update will be issued.

I was able to successfully downgrade the firmware on a e250v2 from 3.01.14A back to 3.01.11A just by using the e200pA.bin file from Daniel's page here -> http://daniel.haxx.se/sansa/v2.html. After putting the .bin file in the root directory while in MSC mode, and after unplugging the USB cable it brought up a screen saying "Firmware update in progress".After it restarted the info page showed 3.01.11A as the firmware. The only problem is if the firmware update is bad, will it still be able to do another update?

[Bagder]

So, a daring person can thus get the .bin file, modify the 32bit value at index 4 (the checksum) and try to upgrade to that, just to see what happens... It might cause trouble, but I expect SanDisk to have some kind of precaution against damaged binaries so my hope is that this triggers some kind of recovery mode.

Another test is to modify a few strings in the image and recalc an updated checksum (based on the algorithm posted on the v2 page) and see if that is accepted and works.

[rondestvedt]

I just tried a simple test. I switched the positions of two letters in the message that comes up when you power on with the hold button on. The message saying that the firmware update was in progress came up, then after a few seconds it powered down without a firmware update complete, and the firmware was unchanged. I'll try again later using the checksum calculator with the same changes.

[jcollie]

Didn't someone already provide a fdisk -l output for one of the v2s? Has anyone tried to scan the disk for the firmware image?

The v2 disk does not appear to be partitioned, so "fdisk -l" will likely just print garbage.  I dumped the entire drive and tried searching for "AS3525" (which is a string I saw in e200pA.bin) and couldn't find it, however that could because I'm running the newer firmware version.  Could the v2s have a separate flash memory area for storing the active firmware that isn't exposed by the USB interface.