Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
embrion:
--- Quote from: atomikpunk on July 11, 2008, 02:00:23 PM ---Well a big news for today: I got JTAG to work on my M200!!! ;D
[...]
So what's next? Install the winarm toolkit and try to debug this thing. If I can debug that thing and insert my own instructions, that would make my day (because I could recover my bricked m200 ;D)
--- End quote ---
Nice, can't wait to hear You resurrected Your player :)
atomikpunk:
Hi peeps,
another news but not good this time, it seems that JTAG stopped responding on my device. I could be many things because I was working on a pretty risky setup with a breadboard and stuff so maybe I inadvertently shorted wires or something. Anyway, no big deal, I was already prepared not to revive my sansa... :(
But I can give more detail on my method...
I came across the OCD Commander software by Macraigor, which is the original producer of the Wiggler JTAG adapter/cable. It's very nice because you can directly control the cpu, halt it, reset it, inject instructions, replace instructions, etc. And most of all, it is free ;D
This software, however, requires to add a jumper between pin 8 and 15 of the parallel port to be recognized, so here is a valid schematic to be used with the OCD Commander software. Note to use the buffered version with the 74HC244 (or 74AC244 if that's what you have...).
With this setup, I was able to connect to the JTAG module on the Sansa m200 SoC, halt it, reset it, update the clock generation unit register to re-enable the external memory module, inject a valid ORR instruction to fix my faulty AND instruction and make the program run again. And guess what, I saw the sansa logo again since a long time ;D However, god-knows-why, the device booted in MTP mode and I was not able to update the firmware so I tried to fix that up and that's probably when I messed something up because I wasn't able to see the device again with OCD Commander (and H-JTAG for those that wonder). It kept telling me the cable was disconnected though I haven't touched a thing there, and checking that "pop API errors" checkbox, I was able to see that this error was triggered when attempting to contact the device...
I was able to connect/disconnect/reset/restart a lot of time and the device was up for all those tries before the last. And the problem is not the parallel port because I checked it out otherwise and it works fine. The only I haven't tested is to use a battery but that's difficult because of the open case so I'd have to tape the battery there and that wouldn't be practical... But honestly, I doubt it would work anyway...
Anyway that's about it for JTAG. My conclusion is: it should be possible to resurrect a bricked player with JTAG if someone is able to solder small wire on its PCB. It should also provide invaluable help to developers to test their firmwares. However, it can be risky because all the electronic is open and a single error can be dangerous.
Now onto the firmware side.
Pedrov and Darkstylist, thanks for the info, it confirms what we have found up to now. If you are interested in helping out, you can contact me via PM and we'll try to keep in touch via jabber, msn or something. We already did a lot of disassembling and analysis work but there are still plenty of misunderstood routines. I'm still searching for a good mean to share work, but meanwhile, we have the wiki, and more precisely that page: http://www.rockbox.org/twiki/bin/view/Main/SansaV2Firmware. Please be sure to read that whole thread because there are a lot of information in here.
See ya later guys
mlifted:
Hi folks,
found this out (mainly by accident ;)). Hopefully this is new to you:
The FM Chip seen in the Fuze/Clip Disassembly pix from abi is the Si4702 from Silicon Labs.
The Markings on the Fuze Pic are:
0219 -> Si4702 / Frimware Revision 19
CXXX -> Revision Code C Die
741 -> Production Year 2007/Week 41
The Markings on the Clip Pic are:
0215 -> Si4702 / Frimware Revision 15
BXXX -> Revision Code B Die
735 -> Production Year 2007/Week 35
Hope that helps, and keep up your good work! ;D
marco
draeath:
atomikpunk, is there anything we can do to help replace your device?
funman:
Hello,
Thanks to all of you for working on the reverse engineering, this progress is very great :D
I would like to help figuring out the firmware format, I read this thread and the SansaV2Firmware wiki page,
so I decided to try this techniques to analyze the firmware running on my Sansa Clip
The firmware is version 01.01.29F, md5sum c12711342169c66e209540cd1f27cd26, available on http://forums.sandisk.com/sansa/board/message?board.id=clip&thread.id=6720
I want to split the .bin file in separate blocks to be able to study their content separately.
The information I found on this thread matched exactly... or should I say almost.
* Every value is 32 bits little endian if not specified otherwise
* Every block's size is padded on a 0x200 bytes boundary
OFFSET 0x0
The first 0x400 bytes are 2 identical blocks of 0x200 bytes (except their first byte is respectively 0 and 1.
This block is the "Firmware header" block.
OFFSET 0x400
Then follow a block whose size is written at offset 0x0c of 1st block: the "Firmware" block.
Then follow all kinds of blocks:
OFFSET 0x1e400
The block following immediately is a "library block" (for the function "drmndt_pers")
(By the way the "drm10*" functions have been replaced by "drmpd_*" functions, but I think you don't care much about drm ;)
Like all library blocks, its block size is written at offset 0xc
OFFSET 0x30800
Immediately after this block, follows a special padding block: it's 4 first bytes are 0xdeadbeef, but the rest of the block is just random (or meaningful?) data.
I assume the size of this block is 0x200 bytes.
OFFSET 0x30a00 - 0x46400
After this padding block follow 346 undetermined blocks, assumed of size 0x200.
OFFSET 0x46400
A library block for function "otg_functio", size 0x21000 bytes
OFFSET 0x67400
A padding block whose 4 first bytes are 0xdeadbeef
OFFSET 0x67600 - 0x6e400
After this padding block follow 7502 undetermined blocks, assumed of size 0x200.
OFFSET 0x6e400
A library block for function "usb_functio", size 0x1ee00 bytes
and so one for all the 22 library blocks, each followed by a padding block, and by unknown blocks
OFFSET 0x29e400 - 0x473200
6 header blocks followed by a padding block
OFFSET 0x473400 - END
Unknown blocks
@atomic_punk
I don't understand when you say the offset of the library blocks can be obtained with:
0x400 + (Index * block multiplier )
I suppose index is the index of the library block (1st block's index is 0), but this formulae doesn't match with my firmware.
The relation I found with the block multiplier field is : 512 * block multiplier == size of the firmware block.
Tested on 3 different firmwares: The 01.01.29 for clip, a firmware for fuze, and firmware for M200 (versions unknown (by the way we could check if we find a byte which would be 29 for version 01.01.29 and 20 for 01.01.20. This is doable because it's most likely a 32bits number, and the firmwares often (always?) have the same size: 5243904 bytes).
By the way what is the md5sum of the firmware you're analyzing ?
I've got a firmware fc9dd6116001b3e6a150b898f1b091f0 m200p-4.1.08A.bin but the offsets differs a little so I think it's not the exact same version than yours.
I have written a little tool to display the structure of a firmware, and make checks to verify certain assumptions. I can attach to the forum if you want to help, when it works well against all known firmwares, I will propose it to replace utils/AMS/hacking/amsinfo.c in svn.
Thanks, I will continue my research tomorrow ;D
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version