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

[funman]

I've found 2 other buttons for the Clip:

power is GPIOA_PIN7
list (or down) is GPIOB_PIN0
hold is GPIOA_PIN3

I tested the byte at  [GPIO_BASE, #(4 << PIN) ] for PIN: 0 -> 7

PIN        0        1      2      3        4      5     6      7
           __________________________________________
GPIOA | #0     #0   #0   HOLD #0   #0   USB  POWER
GPIOB | MENU #0   #0   #1    #1    #1   #1   #1
GPIOC | #1     #1   #0   #0    #0    #0   #1   #1/#0
GIPOD | #0     #0   #0   #0    #0    #0   #0   #0

Notes:
A6 is 1 when plugging usb
I tested C7 2 times and its value changed, maybe I did too much testing today, or the value has some meaning we don't know (FM?).

That means 7 buttons are still missing for the clip, and the mapping may change in each model

But I had an idea: in the diagnosis mode, there is a menu to test each button: if we can find in the firmware where is this special mode, we can hack around to find the code for buttons.

At least now we have a recovery mode for the clip, still a bit fragile but it's there

[atomikpunk]

I guess those discoveries will pump a new hacking rage in here

Tonight I did look at the display controller for the clip and I thin it might be a Solomon-Systech IC. The display itself seems to be an adelco UG-2864 and the display controller (from Solomon) might be in the family of the SSD1303. Well at least the documented commands from the datasheet looks like those I found in the firmware so that's looking good.

A display controller isn't necessarily need in a primary bootloader but it's a hell lot easier to develop when you can show some stuff on the screen

There's still something that tickles me: even though we found a way to read a button to select custom or original firmware, how can we tell that a broken custom firmware won't brick the device (until power off, battery discharged or something)? I mean, maybe the power off handling is done in the firmware itself, no?

Well I'll think about it in my sleep

[fragilematter]

I'm going to shave and then come back here and go about testing the e200v2's GPIOs. And probably I'll try to brick it with an infinite loop afterwards, because I know that in the OF, if it becomes unresponsive, you can hold the power button and after a few seconds it resets.

Edit: I've finished testing GPIOA:

Pin	0	1	2	3	4	5	6	7
Value	#1	#0	#0	USB	#0	#1	#0	#0

I will continue testing as soon as I'll have the time.

funman: GPIOC pin 1 is always #0

[atomikpunk]

Isn't it nice to get visual feedback when hacking stuff, so I thought I'd share that pin D7 on the clip is the led driver on the button "ring", and this is verified

Here's my (simple) test code:

Code: [Select]

OrigEntry:
  .word 0

  /* Enable the GPIO module clock */
  LDR   R1, =CGU_PERI
  LDR   R2, [R1]
  MOV   R0, #0x10000
  ORR   R2, R2, R0
  STR   R2, [R1]

  /* Be sure  GPIOA port is set to all inputs*/
  LDR   R1, =GPIOA_REG
  MOV   R2, #0
  STR   R2, [R1, #0x400]

  /* Read GPIOA pin 3 */
  LDRB  R2, [R1, #0x20]

  /* Check its state */
  CMP   R2, #0

  /* Resume original firmware if hold is not active */
  BEQ   resume

  /* Make D7 an output */
  LDR   R2, =GPIOD_REG
  LDRB  R0, [R2, #0x400]
  ORR   R0, R0, #0x80
  STRB  R0, [R2, #0x400]

  /* Start by toggling off */
  MOV   R3, #0
  /* Let's toggle 8 times (4 on/off cycles) */
  MOV   R1, #0x8

loop1:
  /* toggle led on pin D7 */
  STRB  R3, [R2, #0x200]
  /* and prepare for next cycle */
  EOR   R3, R3, #0xFF

  /* approx 1/4 second delay */
  MOV   R0, #0x40000
loop2:
  SUBS  R0, R0, #1
  BNE   loop2

  /* Let's do 4 on/off cycles */
  SUBS  R1, R1, #1
  BNE   loop1
  
resume:
  /* Jump back and resume original firmware! */
  LDR   PC, OrigEntry

.set  CGU_PERI,   0xC80F0014
.set  GPIOA_REG,  0xC80B0000
.set  GPIOD_REG,  0xC80E0000

Owh and I thought I'd share that I did another test. I modified the above code to do 40 toggling of the led. This gave me plenty of time to try to turn off the clip while it was flashing. And the good news is that it works! I turned the clip on with hold active so that to branch to my test code. Seeing the led blink, I moved the hold/power button to the power position and about 0.5 to 1 second later, the led stopped flashing. The device indeed was turned off in the middle of my custom code! So that means that if by mistake we try some code that crashes, we should be able to simply turn off the device and reboot.

Simplified and in short, we finally found an easy and safe way to develop code on the sansa v2 Maybe we should put it all together and develop some scripts to reduce mistake risks... Anyway, I'm not much the guy for that stuff, maybe someone else?

As of hacking, if I check items that should be our todo next list, maybe we should now head toward those points:

• Find a way to insert code at different places in the OF, or increase the usable part in the OF that we can use to store custom code
• Find how to access the flash
• Develop a first stage bootloader that can load a file from the flash in the RAM and execute it
• Investigate on the hardware we don't know yet
• Develop drivers for the hardware used in the sansa v2 devices, being (other) buttons, LCD, eventually sound, etc.
• Anything else I forgot at this time...

[username]

hi all,

first of all, thank you for your efforts to port rockbox to the sansa v2 series!
Unfortunately i cannnot help you to write code for the devices, but today i played around with my e260v2 and discovered some things.
i downloaded some v2 firmware images from daniel.haxx.se  and was very surprised to see that the md5sum for each version number is the same, regardless of the region code.

dave@haganah:~/sansae200v2fw/16$ md5sum *bin
12563ad71b25a1034cf2092d1e0218c4  e200pA.bin
12563ad71b25a1034cf2092d1e0218c4  e200pE.bin
12563ad71b25a1034cf2092d1e0218c4  e200pF.bin
12563ad71b25a1034cf2092d1e0218c4  e200pG.bin
12563ad71b25a1034cf2092d1e0218c4  e200pH.bin
12563ad71b25a1034cf2092d1e0218c4  e200pM.bin
12563ad71b25a1034cf2092d1e0218c4  e200pN.bin
12563ad71b25a1034cf2092d1e0218c4  e200pS.bin

so, if you rename e200pA.bin to e200pE.bin and copy it to the root directory of the device and unplug it, you end up with an update that installs the european version without the radio functionality. therefore, it seems that there is only one firmware for each version number.

furthermore, if you rename the firmware file to e200pT.bin and move it to / of the device, you can access the diagnosis mode (settings -> diagnosis) which lets you test the buttons, lcd, microphone and other funny things.

hope that helps, happy hacking!

[Pampersrocker]

with usernames discoverings I've found out that my e260v2 also have radio: I've just installed the e200pF firmware on my player and could listen to radio, so there'll may not be some differences between the v2 models...

sry for my English 

[username]

i guess every e2x0v2 model has radio functionality. the reason why there are A and F versions is that in the A version you can select radio settings->fm region world, u.s. and japan, whereas the F version only has world but not japan. this is probably due to the fact that german (and maybe other european) authorities use some frequencies in the "japan fm region" for their communications.

nevertheless, i wonder why sansa sells devices in germany with have radio chips built-in but are disabled via firmware, although there is a firmware which excludes the frequency range which normal people are not supposed to listen.

hope not too off-topic.

[AlexP]

nevertheless, i wonder why sansa sells devices in germany with have radio chips built-in but are disabled via firmware, although there is a firmware which excludes the frequency range which normal people are not supposed to listen.

Due to licensing costs in Europe - it costs more to sell a device with a radio as you have to pay for the licence for it.

[fragilematter]

atomikpunk: when I tried to patch the firmware with the led blink code (just to see if it's there) I got a linker error:

Code: [Select]

arm-elf-ld -e 0 -o test.elf test.o
test.o: In function `loop2':
: undefined reference to `loop1'
make: *** [test.elf] Error 1

I'm thinking it has something to do with the fact that we have one loop inside another. I've got arm-elf-ld version 2.16.1.

As a side-note, I won't be able to test stuff until Wednesday, I've got some restant exams.

[funman]

atomikpunk: when I tried to patch the firmware with the led blink code (just to see if it's there) I got a linker error:

Code: [Select]

arm-elf-ld -e 0 -o test.elf test.o
test.o: In function `loop2':
: undefined reference to `loop1'
make: *** [test.elf] Error 1

I scratched my head this morning and linuxstb found the problem: comment line 33 is not terminated

EDIT:
fragilematter, you shouldn't try this code on the e200 because the GPIO mapping is different.
Instead you should reverse engineer the firmware to find the corresponding registers for your device.
/EDIT

by the way thanks you so much atomicpunk for this finding, this is much better to look for light rather than count the seconds ...

I have written a pattern search test, and tested 2 library blocks: usb_functio and otg_functio, and they are not loaded at their base address, neither when I boot the Clip by usb.

After work I will look for patterns in the FAT32 partition, maybe the NAND is enabled and mapped at boot ? Somehow I doubt it but it's worth a try

[fragilematter]

Okay, the led pin is the same on e200v2's also, it blinks them quite nicely. The only difference is that A3 is USB, not hold, so it only triggers when you start the sansa by plugging it into a usb port.

Anyhow, great finding, it will make my life easier as I'll test the other GPIOs.

Edit: funman, thanks for the warning, but it seems I was lucky. Anyhow, even if it went bad, I've got nand access to recover it

[atomikpunk]

Hi peeps,

hehe sorry I may have added the comments after compiling the code, my fault

Yes funman, there seem to be a library loading routine somewhere in the firmware block. I don't fully understand it yet but it is pretty that this routine loads a library block somewhere into RAM. I'll have a closer look and see if I can understand the flash mapping. It seems that the flash is directly accessed in the CPU memory map, not using the dedicated AMS3525 NAND interface(?).

But if you can find how to directly access the filesystem that would be THE finding of the day as we could load anything we want and would not be limited by the firmware size anymore

Edit: be careful when trying to output to GPIO pins, most should be safe but we don't know how they are connected and putting a 1 or 0 to a pin that isn't supposed to be driven this way could damage circuitry...

[funman]

Hola fellow supporters of sansaV2 port

Some more informations today:

The library memory mappings overlap with each other.
I loaded acp_decoder and mp3_decoder and they shared a common area, that means only one can be loaded at a time.

That seems logic considering the small amount of RAM on the clip: 2Mbits

While writting a pattern search, I came on big problem: my code was 2 instructions too long to fit in the firmware block.

I couldn't reduce it, so I had a look at other firmwares: the firmware v17 (instead of latest v29) has the biggest room for code:
The firmware fills up 0x28 bytes in the last 0x200 bytes block, that leaves us with 0xD8 (216) bytes

We'll leave with this while a e200 owner flashes a modified firmware with firmware block's size incremented by 0x200, and following blocks shifted by 0x200.
mkamsboot.c should do this for you, but you should check if modifying the whole file size is ok, or if you have to remove 0x200 bytes from the end of the file (I'm not sure if it's padding or not)

For pattern testing, I want the device to do an infinite loop into 2 different states:
1 which blinks the led for ever
1 which lights the led; and do an infinite loop

light on / light blinking is our boolean for pattern found / not found; but I have trouble leaving the LED on.
I'll probably get some fresh air and return to it

See you

[fragilematter]

Well, you could probably engineer a image that I could dd directly to my e200v2 if space is a problem. I don't know how much we can assume that the code form the clips is similar to the e200s, the led was a lucky break.

Oh, and the firmware image and bridging the pads definitely works, I've managed to guide sucitrams into repairing his sansa by dd-ing the first ~30MB from my dump. He reported that his sansa wasn't doing anything that indicated it was running, and we got it to work again from the first try.

[saratoga]

If you can flash and recovery anything using the pad trick, maybe its time to think about replacing the OF with a simple bootloader.