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

[atomikpunk]

Hi,

well yes I can help but honestly I'm not sure about the real usefulness of JTAG now. Sure it is very useful in case the device is bricked or for project that don't have safe bootloaders... But it this case, we now have a safe testing bootloader and e200's got a recovery method so...

But if you want to try it as academic learning, I'll try my best to help you. Private message me so we can get in touch in that case.

BTW, really looking forward the decompression method. If we can make it work and be sure it is safe, that would be nice. Good job!

[saratoga]

JTAG could still be useful for reverse engineering because it allows access to register values used by the OF.

Even for documented hardware (like the AMS DAC), a good deal of trial and error was needed on the V1 port to figure out good values, and even then we probably don't set everything quite as intelligently as the OF does.

[linuxstb]

The new UCL compression method of adding our bootloader code to the OF now seems to be working.  The code in SVN has been tested on a Clip, and also on an E200.

This latest code no longer adds anything into the padding at the end of the firmware block - so should work with any original firmware versions.

Some more success reports could be useful, but I think this is good enough to allow more development.

[mbr]

Some more success reports could be useful, but I think this is good enough to allow more development.

Hi there,

I can confirm, that the code in subversion (r18682) works on my e250v2 with firmware e200pa-03.01.16.bin

[Hillshum]

Hi there,

I can confirm, that the code in subversion (r18682) works on my e250v2 with firmware e200pa-03.01.16.bin

r18684 works on my e260 with the same firmware
never mind it's r18679

Update: r18684 does work

[kugel.]

It's also tested on my Fuze. It works.

[Kilar Ezan]

Well, I'm not a programmer and I don't know a thing about the technical side of players, but Sandisk has just released new firmwares for fuze and clip and i think that clip has just became a harder target for rockbox, because Sandisk messed with the pcb, and we have Clips v1 and Clips v2 (hardware revision 1 and revision 2 firmwares) ;/

[funman]

This doesn't make the Clip (v1) a harder target in anyway.

In fact it may be very interesting if someone has a v2 Clip because it appears to have external memory attached (note that it is still based on the same AS3525 SoC).

I also hope that they activated the recovery mode on this one.

Beware before using the tools in SVN on a ClipV2 because the firmware format is a bit different (the 0x20 bytes header has been extended by 32 bits, and a checksum has been added to it).

EDIT: I looked a bit at the new firmware format:
It's basically the same format except that a 32 bits low endian value (0x0000f000) is inserted at offset 0x4, and following data is shifted by 32 bits

After 0x24 until 0x1fc, all the words are 0xffffffff (like previously)

There is a copy of these 0x24 first bytes at offset 0x200, with the difference being that the first word is 1 instead of 0 (like in the previously known format)

At offset 0x1fc, there is the sum of all 32 bit little endian words from 0x0 to 0x1fc (not including this checksum)
The same checksum is at offset 0x3fc (from 0x200 to 0x3fc), and is the 1st checksum + 1

Update the current mkamsboot.c in SVN is trivial, and left as an exercise to the ClipV2 owners

[ziegs]

It's also tested on my Fuze. It works.

I'm interested in rolling a build for my Fuze.  How can I get started?  What architecture should I target in tools/configure?

Thanks,
--z

[fragilematter]

You can't roll a build just yet. We just use mkamsboot from the svn to insert code into the official firmware image and then flash the player using that image. We still need a way to access the nand, so any help would be greatly appreciated.

[Moarc]

I see SanDisk provides iNAND documentation (not full, but e.g. with pin description, isn't it important information?) freely at its website, maybe it should help with hacking NAND on v2's?

http://www.sandisk.com/As...ls/ProdManiNANDAbr1.1.pdf

[cosmocat]

I see SanDisk provides iNAND documentation (not full, but e.g. with pin description, isn't it important information?) freely at its website, maybe it should help with hacking NAND on v2's?

http://www.sandisk.com/As...ls/ProdManiNANDAbr1.1.pdf

Link seems broken, this one should be better....
http://www.sandisk.com/Assets/File/OEM/Manuals/ProdManiNANDAbr1.1.pdf

[funman]

Thanks, this document shows for example that for initializing the device, you have to send ACMD41 until it answers that it's ready.

In the MMC specification, they use CMD1 for that, and CMD41 is 'reserved'

[tobi-lu]

Using google, i've found a "non-abridged" version of the manual:
http://www.spezial.cz/pdf/inand_manual_v3.1.pdf

But this document doesn't say anything about CMD41...


edit: Instead, it has lots of references to the "SDA Physical Layer Specification, Version 2.00" which isn't available freely

edit2: well, a simplified version is available on http://www.sdcard.org/developers/tech/sdcard/pls/

edit3: on page 15, there are some informations about initialization.

The busy bit in the OCR is used by the card to inform the host that initialization of ACMD41 is
completed. Setting the busy bit to 0 indicates that the card is still initializing. Setting the busy bit to 1
indicates completion of initialization. The host repeatedly issues ACMD41 until the busy bit is set to 1.

[funman]

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.

EDIT: unrelated to SD, but good news anyway