Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
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,
--- Quote from: funman on November 30, 2008, 03:28:32 PM ---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).
--- End quote ---
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version