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

[atomikpunk]

Hi Daniel (and everyone),

well there is at least one thing I see missing in your code: you should enable the GPIO module clock. This is done via the CGU_PERI register which is at 0xC80F0014 via bit 16 (0x10000). Be sure to read CGU_PERI, logical _OR_ (damnit) bit 0x10000 with the register content, and then write back to this register...

For my m200 special mode, I'm still clueless why it won't show up a drive. I'm wondering if my ext. mem. firmware is ran before the special mode bootloader... That could explain why the flash is still not found but I wonder how come the firmware would get executed before turning to the bootloader... Anyone got an idea on this?

(damn time zones... if only you guys were from americas  )

Francois

[daniel_at]

Hello thread,

Just played a bit again with my v2. Thx, atomikpunk for the hint with the Clock-Init. The datasheet did not mention it near the GPIO-docu, but some pages apart... Havent planned to read the whole pdf

now my Code looks like this:

Code: [Select]

/* This value is filled in by mkamsboot */
originalentry:   .word   0


.equ AS3525_GPIO1_BASE, 0xC80B0000
.equ GPIO1_DATA, (AS3525_GPIO1_BASE+0x0000)

.equ AS3525_GPIO3_BASE, 0xC80D0000
.equ GPIO3_DATA, (AS3525_GPIO3_BASE+0x0000)

.equ CGU_PERI,0xC80F0014

.equ AS3525_I2C_AUDIO_BASE, 0xC8070000
.equ SYSTEM_REG, (AS3525_I2C_AUDIO_BASE+0x20)

/* enable the GPIO-Clock */
ldr r1, =CGU_PERI
ldr r0,[r1]

orr r0,r0,#(1<<16)
str r0,[r1]

        /* A delay loop - just to prove we're running */

        mov   r1, #0x500000       /* Approximately 5 seconds */
loop:

/* check register */
ldr    r2, =GPIO1_DATA
ldrb   r2, [r2]  /* Load GPIOC-Data into r1 */
        tst    r2, #0x80   /* check if .. is set */
/*cmp r2,#0*/
bne    noloop

        subs  r1, r1, #1
        bne   loop


        /* Now branch back to the original firmware's entry point */
noloop:        ldr   pc, originalentry(Test now in the loop - maybe to circumvent timing problems)

Tried all 8 bitmasks for GPIO1 (which is hopefully GPIOA): no reaction to keypresses - every time it waits the ~5 seconds.

Maybe one problem: Measured the voltage on the switches again - one side is always ground the other one:
 * After power on, but in the wait-loop: 1.9V
 * If the Sansa-Bootscreen appears and in normal mode: 3V
 * In normal mode, but screen (and blue leds) switching off: 0.5V
But even with from that mode (with 0.5V) the sansa can detect keypresses.

(But i have measured with a slow DMS - maybe the keys are tested only for a short periode of time, and the DMS integrates over it... Will test again with oscilloscope some time)

Not sure what that means... but maybe there are some pullups or some powermanagment stuff to enable.

[atomikpunk]

Hi again,

Well I'm looking at the e200 code at the moment and it doesn't seem to have any "keypad scanning" routine, at least not as easily visible. There seems to be GPIOB pin 6 which is read in the routine at 0x851C and then its value is used a little later in that same routine. If the pin is high, then memory variable at 0x2181E is put to 1. If the pin is low, then that same memory variable is unchanged. Could that be the hold button?

Here is a list of the pins, direction (input or output) and routine address(es) where it is used, that could give a clue which one to test...

Pin	Dir	Usage in code
A0	out	0x1FD8, 0x1FF8
A1	in & out	0x851C, 0x8720
A2	in	0x6728
A3	out	0x4418
A4	out	0x72DA
A5	out	0x442C (which seems to be the LCD init routine BTW...
A6	n/a	Unused
A7	out	0x442C (but strange enough since it is only cleared once and not used again...)
B0	n/a	Unused
B1	out	A lot of routines

To be continued... (somewhat sooner than midnight )

[atomikpunk]

Well a big news for today: I got JTAG to work on my M200!!!

Hardware: Wiggler clone as shown in here. However, I needed to add a 10k pull-up resistor between VCC and the RST JTAG line.

Software: H-JTAG, which is a free and very nice windows JTAG interface for debuggers. What is nice about it is that it can auto-detect connected targets. This way, it was easy to know when I got it right because instead of the "unable to detect target" message I was constantly getting, I got the "ARM922T" display in big blue characters.

The JTAG pins on the M200 are (as expected) as noted on the PCB. Beginning from the VCC pin, we have:

VCC

TRST

TDI

TMS

TCLK

TDO

GND

You can get a better view with this picture.

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 )

[pedrov]

Hi all,

I just bought a sansa v2 (e280), and feel a bit disappointed about the current firmware; so I'm interesting in helping to port rockbox on these devices. I read this thread, and I was impressed by what has already been discovered. Well done !

I used hachoir (a tool to discover subfiles into files), and I got this :

Code: [Select]

% hachoir-subfile e200pe.bin
[+] Start search on 15728640 bytes (15.0 MB)

Search: 19.58% -- offset=3080192 (2.9 MB)
[+] File at 3812522 size=21872 (21.4 KB): PNG picture: 256x256x8
[+] File at 3834394 size=2341 (2341 bytes): PNG picture: 132x32x8
[+] File at 3865319 size=52475 (51.2 KB): PNG picture: 256x256x32 (alpha layer)
[+] File at 3917794 size=3882 (3882 bytes): PNG picture: 132x32x32 (alpha layer)
Search: 53.75% -- offset=8454144 (8.1 MB) -- 2.2 MB/sec  -- ETA: 3 sec 111 ms
Search: 77.92% -- offset=12255232 (11.7 MB) -- 2.4 MB/sec  -- ETA: 1 sec 405 ms

[+] End of search -- offset=15728640 (15.0 MB)
Total time: 6 sec 223 ms -- global rate: 2.4 MB/sec

By the way these pictures aren't really interesting to extract (sandisk logos, and pictures of the device ...). But since I did not find any mention of them on the firmware wiki page, I thought it would be interesting to mention.

Another thing : I tried to upgrade to a "by-hand" modified firmware (I just changed "HOLD" into "HALD" in a string), but it did not work as expected. Weird, since the checksum program (available into Daniel's wiki) told me that the checksum did not changed. My sansa did not even want to flash itself with this modified version ('Upgrade in progress ...' and then shutdown).

I'm really interested in giving a hand, if I can.

[embrion]

Well a big news for today: I got JTAG to work on my M200!!!
[...]
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 )

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

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 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!

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 

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 

[atomikpunk]

Hi funman and welcome to the magical world of v2 disassembly

Great work up to now, but maybe some hints will get you back on track with the clip disassembly
1. The firmware header is effectively 0x400 bytes long and there are 2 (almost identical) copies of the same header at 0x000 and 0x200.
2. At 0x400, there is the firmware block, this is where the sansa boots on power-up/reset. Take care however, because that block length is specified in the firmware header at 0x00C and can be calculated using firmware_length = 0x200 * firmware_size_multiplier. I am sorry however, I made a mistake in the table, you are right that the library blocks aren't at 0x400 + index*0x1e000 but at 0x400 + firmware_length + index*0x1e000. And that is for the M200, I know this value (0x1e000) is different for the E200, so it could be different for the clip too.
3. Take care that in my descriptions, I almost always remove the 0x400 byte long header from the file so addresses will probably be off by 0x400. This however really helps with the firmware analysis because the firmware is based at 0x00000000 and with the 0x400 offset, I'd need to do relative offsets all the time...
4. The firmware I used is the one right here.

Yeah sure it would be great if you could attach your little soft, I'd have a look.

If you are interested in cooperation, we could get in touch on irc/jabber/whatever. Send me your instant messenger info in PM so we could talk more easily.

(BTW, if wiki admins are reading this, please fix the directedgraphplugin, that would be nice

[funman]

The mosquitoes don't want me to sleep so I found some weird stuff ^^

1. Ok

2. This is the first bytes of my firmware block:

0000400: 58f0 9fe5 58f0 9fe5 58f0 9fe5 58f0 9fe5  X...X...X...X...

I think in previous posts you describe this block as containing code this way:
The 16 first bytes would contain branching to 4 functions.
However it's all the same: 0x58f09fe5 so that doesn't look like it's the case here.
I should get a assembler / disassembler for the AMS cpu ...

About the block multiplier, I found that all library blocks don't have the same size for me...

I use this theory : all unknown blocks just after the library blocks in my previous message are in fact
part of the library block and represent padding. I just substract the offsets between the next block
and the current block to get their size:

The first 8 blocks are 0x28000 bytes long
The 13 following blocks are 0x14000 bytes long (2 times less)
The last library block seems to be 0x3C000 bytes (it fits in 0x14000 but 320 blocks (0x28000 bytes) follow it...

Some of the first 8 blocks would fit in 0x14000 bytes also but are then followed by 160 unknown blocks
... (0x14000bytes)

So the size is always a multiple of 0x14000, but for the 2 other firmwares I have it
differs: it's a multiple of 128*0x200 (0x10000) or 240*0x200 (0x1e000)

I will check against the 2 other firmwares if the library block sizes are always identical or can vary also.
I tried to relate this variable block size with the unknown values in the firmware header but I made no match :/

Also, by looking at the hexdump I found the Unicode certificate data at 0x473600 (3 blocks after the last header block) and I will found a way to detect it (the packet differs a bit between the different firmwares).

3.4. Ok I understand why the adresses differ, because I use this firmware also in my tests.

I attach my prog, it was meant to split the firmware in multiple files but for now it only prints the different block types with offsets and block sizes.
Note you have to edit the library block size multiplier to match the one from your firmware to avoid getting thousands of padding blocks displayed between library blocks (for now).

In the future I should make a package which fetches different firmwares from sansa ftp and check them all.

Bye ^^

[atomikpunk]

Hi funman,

For the branches, this is absolutely normal because branches are all relatives! The only that it tells you is that the address of the jumps are all in sequence in the firmware, which indeed is the case.

So we have two possibilities for the clip, a library block size of 0x14000 and/or 0x28000. I'll try to have a look on my side in the next days.

I'm glad you posted your program, I'll have a look at it in the next days! Hopefully, we'll be able to check that out online together.

See ya


Edit: Ok I checked out the clip firmware file 1.1.29f. The format is definitely different than the M200. Here's a bit of what I found this morning:

0x00000000: firmware header
0x00000400: firmware
0x0001E400: first library block
0x00030800: another library block
...

It seems that some library blocks now begin with 0xDEADBEEF and I'm not sure they necessarily have all the same size.

Owh BTW, if you're looking for stuff about the AMS3525 SoC, the embedded core is an ARM922T so you can get info about it...

See ya later.

[funman]

"0x00000000: firmware header
0x00000400: firmware
0x0001E400: first library block
0x00030800: another library block
..."

For me the 2nd library block is at 0x46400

"It seems that some library blocks now begin with 0xDEADBEEF and I'm not sure they necessarily have all the same size."

I think we must take 0xDEADBEEF in the literal sense: this block is dead beef aka padding

[atomikpunk]

Hi funman,

The first library block is at 0x1E400 and the second one is as you said 0x46400.  And I can see that there are at least 2-3 more following at the same 0x28000 distance. So I guess that the lib block size on the clip is 0x28000.

About the dead beef values, it seems that the clip changed the way dead beef padding is done. They seem to only mark the first dword of each padding block as dead beef now, but I wouldn't be surprised if the following bytes were still junk.

And I stumbled upon the version number in the firmware, juste in case you were still looking for it. It is a plain string located at 0x1DF3A


Edit: Ok a little something for tonight, funman and I finally got online at the same time/space continuum and found some stuff on the clip firmware. It seems that new versions don't have whole deadbeef padding, but only the first DWORD of padding blocks. That suggests that we could insert our code in there so I guess one problem's gone. Now we need to find how to listen to a button. Owh and the clip firmware as a checksum similar to the e200 one, but it is located 4 bytes earlier in the file, so the file really is a 0x200 multiple with the last DWORD being the checksum. That's it for tonight...