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

[Chronon]

It has JTAG: http://www.rockbox.org/twiki/bin/view/Main/SansaE200v2#JTAG

[atomikpunk]

If there is a (reasonably) safe way to contribute to the firmware, then I'd love to do so.

If you are inclined at hacking a bit, you can try using the (old) bootloader with delay which will delay on a custom condition (e.g.: button press) and don't wait in the opposite. With it, you'll be able to try buttons and see if you can find buttons on the ams-v2-e200... I assume you can first check that the mapping hasn't changed (based on the ams-v1-e200). Have a look at the bootloader history in svn to find the "good" one, or have a look earlier in this thread, I think funman already put a link to it...

Welcome among us

[RockRabbit]

@RockRabbit : you must first revert utils/AMS/hacking to revision 18663 to get the old basic mkamsboot (which inserts a delay)
Then if you are not familiar with assembly, you should come on the IRC channel and see if someone (like me if i'm present) can give you the steps

I've got the rev 18663 code from subversion. Can you tell me where I can get the c250 firmware? Is there a way to get it off the player? I can't seem to find it on the Sansa web site.

I intend to try the raw code as is (without any key code checking) just to see that I can get it to work, before I do anything more useful.

[saratoga]

http://forums.sandisk.com/sansa/board/message?board.id=c200&thread.id=2029

[Bagder]

Allow me to also mention that I collect most (all?) of the AMS Sansa firmwares here:

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

[RockRabbit]

Thanks to saratoga and bagder I obtained the C200PA.BIN firmware, and have been able to run mkamsboot, giving me a PATCHED.BIN file.SO far so good.

Now I need to get this onto the target somehow. Is there a development version of sansapatcher or something similar?

Also do I need to rename the patched file to c200PA.BIN?

Many thanks.

[Domonoky]

There is no need for a sansapatcher for the ams-sansas. Just put the patched bin file with the correct name (c200pA.bin), to the root of you player, and the OF will flash it after USB-unplug.

But be carefull, as far as i know, the dualboot.S isnt tested on c200v2. If the dualboot function fails, it could brick your player !  (So it would be best to modify dualboot.S, so it always boots into the OF (after some delay for button checks) )

greetings, and good luck.

[saratoga]

Thanks to saratoga and bagder I obtained the C200PA.BIN firmware, and have been able to run mkamsboot, giving me a PATCHED.BIN file.SO far so good.

Now I need to get this onto the target somehow.

The link I posted has the install instructions for a firmware file. 

[RockRabbit]

There is no need for a sansapatcher for the ams-sansas. Just put the patched bin file with the correct name (c200pA.bin), to the root of you player, and the OF will flash it after USB-unplug.

But be carefull, as far as i know, the dualboot.S isnt tested on c200v2. If the dualboot function fails, it could brick your player !  (So it would be best to modify dualboot.S, so it always boots into the OF (after some delay for button checks) )

greetings, and good luck.

Thanks for the warning. Actually I am following funman's instructions and using an old version of mkamsboot that simply inserts a delay into the boot process. Later I will get more adventurous and start to insert some additional keymap checking code, once I do a bit more investigation and get used to the arm instruction set.

Installed the patched bootloader and everything looks good. No brick tendencies detected. Loads the standard firmware after the delay and runs fine. Now ready for the next part.

I have come up with the following code, which is a combination of the test.s code in version 18663 or mkamsboot and the some code from dualboot.S from the current version of mkamsboot. I have made some alterations to the registers used so that hopefully the two pieces of code will work together. I have saved this code to the test.S file in place of the original 18663 version (which just contained the delay loop). Am I right in assuming that I can compile the code via make exactly as before without any more changes?

The intention is that the code will test for the left button to be pressed and exit the loop immediately if it is.  I am assuming (hoping) that the c200 might be very similar to the e200.

Code:

/* This value is filled in by mkamsboot */
originalentry:   .word   0
.set GPIOC,     0xC80D0000

        /* A delay loop - just to prove we're running */
        mov   r2, #0x500000       /* Approximately 5 seconds */
loop:       
   /* LEFT button check */
        ldr   r0,  =GPIOC /* gpioc */
        mov   r1, #0
        str   r1, [r0, #0x400]
        ldr   r1, [r0, #0x20]    /* read pin C3 */
        cmp   r1, #0             /* C3 = #0 means button pressed */
        beq   exloop

        subs  r2, r2, #1         /* decrement counter setting status flags #/
        bne   loop

        /* Now branch back to the original firmware's entry point */
exloop:  ldr   pc, originalentry
 
Does that sort of look ok?

Thanks.

[atomikpunk]

Does that sort of look ok?

I see no obvious error in there, but it is a wild guess to think that the C200 is similar to the E200 IMHO I would personally have thought that it would look more like the M200/clip, but I may be wrong... If you have some knowledge in disassembling, you could have a look at the C200 OF and try to figure out the buttons in there...

But I guess there is no harm in trying it out and see...

[kugel.]

RockRabbit: The next step is to find at least one button. Make the 5s delay dependent of the state of a GPIO pin of your choise. Then, try to boot and press buttons to see if the delay changed due to the button press.
Do this also for USB, the USB detection is like a button (i.e. boot with USB cable inserted, and without to see if delay changes).

My first recommendation would be to check GPIOA3. This pin is representing a button on the other AMS sansas as well.

Once you found a button, we can enable dual boot. Dual boot doesn't need a working bootloader, that's the fine thing about our ams sansas

[RockRabbit]

I have placed the code shown below into test.S of version 18663 of mkamsboot. The player will load the OF after approx 33 seconds delay, but will load immediately the power button is pressed a second time. Does this mean that the code is successfully detecting the keypress for the power button?

Note that the statement "bne bootof" which branches out of the delay loop when the button is pressed was originally "beq bootof" in the dualboot.S file I copied it from in the current version of mkamsboot. This is contrary to the note beside the line which states the button press is detected when the value is zero, whearas my code checks for non-zero and seems to work. Can someone explain this?

Does the code look ok for me to continue adjusting the port addresses to detect more buttons, or have I got it completely wrong?

Also, can someone explain the meaning of the two lines "str   r1, [r0, #0x400]" and "ldr   r1, [r0, #0x20] "? I understand what they are trying to do, but cannot understand the immediate values. Why 0x20? This is binary 00100000 , which appears to select bit 2 rather than bit 3, and the 0x400 offset baffles me completely. Any help greatly appreciated.

Im beginning to enjoy myself immensely doing this. Lets hope I can make some progress before I brick it.


/* This value is filled in by mkamsboot */
originalentry:   .word   0
.set GPIOA,     0xC80B0000
.set CGU_PERI,  0xC80F0014

        /* A delay loop - just to prove we're running */
        mov   r2, #0xB00000       /* Approximately 5 seconds */

        /* enable gpio clock */
        ldr   r0, =CGU_PERI
        ldr   r1, [r0]
        orr   r1, r1, #(1<<16)
        str   r1, [r0]

loop:

        /* LEFT button */
        ldr   r0, =GPIOA
        mov   r1, #0
        str   r1, [r0, #0x400]
        ldr   r1, [r0, #0x20]    /* read pin C3 */

        cmp   r1, #0             /* C3 = #0 means button pressed */
        bne   bootof
 
   subs  r2, r2, #1
        bne   loop

        /* Now branch back to the original firmware's entry point */
bootof:   

   ldr   pc, originalentry

[kugel.]

r0 contains the GPIOA base address. r0+0x400 is the the GPIOA_DIR address. Clearing GPIO*_DIR (for a specific pin, e.g. ~(1<<3), or all pins on that port, 0x0) sets the pins to input, which means that the hardware sets the bit high/low. If they're set, the hardware cannot change the state.

0x20(1<<3; pin 3) is the offset of GPIOA base address, that holds the actual pin. This is read, and (possibly) changed due to a button press.

And yes, if the power button made the of boot immediately, it means you fount the power button
I'll add your find to the V2HardwareMapping wiki page. Next step would to edit mkamsboot to implement dual boot.

Edit: If you feel brave enough, can you try setting GPIOD7, I assume that's the button light.

Take this code (test.S).

/* This value is filled in by mkamsboot */
originalentry:   .word   0
.set GPIOA,     0xC80B0000
.set GPIOD,     0xC80E0000
.set CGU_PERI,  0xC80F0014

        /* A delay loop - just to prove we're running */
        mov   r2, #0xB00000       /* Approximately 5 seconds */

        /* enable gpio clock */
        ldr   r0, =CGU_PERI
        ldr   r1, [r0]
        orr   r1, r1, #(1<<16)
        str   r1, [r0]

        ldr   r4, =GPIOD
        mov   r3, #128
        str   r3, [r4, #0x400] /* set Pin 7 to output, 128 = 1<<7 */
        str   r3, [r4, #512] /* set pin to high to enable buttonlight, 512 = 128<<2 */
loop:

        /* LEFT button */
        ldr   r0, =GPIOA
        mov   r1, #0
        str   r1, [r0, #0x400]
        ldr   r1, [r0, #0x20]    /* read pin C3 */

        cmp   r1, #0             /* C3 = #0 means button pressed */
        bne   bootof
 
   subs  r2, r2, #1
        bne   loop

        /* Now branch back to the original firmware's entry point */
bootof:   

   ldr   pc, originalentry

[RockRabbit]

Thanks for the help kugel. Cannot really understand the explanation re the ports and how they are addressed. I take it each pin is not a single bit within a word, but there are seperate words for each pin?

Is there anyway I can get hold of a copy of the AMS datasheet? It might help me understand the hardware better. Ive tried getting one from AMS, but they are asking what company i am with and when is my product going to hit the market. It all sounds depressingly corporate.

[Moarc]

RockRabbit,

Something you'll need to work on the Sansa AMS is the AS3525 datasheet.
Unfortunately it's not redistributable, but if you come on irc (and prove you are interested) you can ask Bagder for it (he is allowed to redistribute it to developers on an individual basis, at the condition to not redistribute / make it public of course).