Rockbox Development > New Ports
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 ;D
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#0USB#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 ;D
Here's my (simple) test code:
--- Code: ---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
--- End code ---
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 ;D 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.
--- Quote ---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
--- End quote ---
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!
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version