Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
funman:
It wouldn't give you anything else than the directions and values.
If you already tried to read them one by one and it failed, i see no other solution than looking at the disassembly.
kugel.:
Don't you think it helps if I compare the GPIOs before and after the OF touched them?
funman:
kugel I think you misbelieve what is "touching": the OF will not do anything except changing the direction registers (each pin is input or output) and write values into the pins set as output.
If it's output, then you'll get the value written (useless for the keypad)
If it's input you'll get nothing more than what you tried to read already.
Also if you want to get something from the OF you must be sure that it has made this information available before overwriting the bootloader with code loaded from SD.
In the Clip case, the GPIO registers aren't even accessed before that step.
In fact if you want to modify the code I use for the Clip you'll need to disassemble and study your fuze firmware first; so why not starting it now ?
It's not something impossible, and once you start i and others will of course be able to give you advices.
On the Fuze the buttons could very well be accessed via a special controller, in fact we can imagine everything until someone do the hard work and start disassembling the firmware.
The LCD code was easy to do, linuxstb did it in less than one day I believe; but if he hadn't looked at the disassembly it wouldn't have been present.
So I only have one thing to say: do it ;) (and you can count on my help, but not to do it for you)
EDIT: remove a french word spotted by BigBambi
atomikpunk:
Hi again peeps,
well I wouldn't mind having a look at the fuze OF, but I'm quite busy at work these days and it'll last up to next week. So if you don't mind waiting for next week (and the time needed to find the buttons), I can have a look for you.
Of course if you decide to do it yourself or give a hand, be sure I'll help too.
funman:
I have some information about the big function which initializes the SD card (I call it 'init_card')
First the prototype is init_card(int drive, int MMC_STATUS_value, int *command_response)
More precisely, this function is called from an higher level function which initializes the PL180 controller, and then call init_card().
I call this higher level function 'init_chip'
In the first call, the function at offset 0x18 is set to NULL, and since we see it in the structure dump, that means that the first call failed, and the second one succeeded.
The difference between failure and success is in:
* What the first call to init_card did (calling various functions, modifying the structure)
* setting the pin D7 to 0 and clearing the bit 7 of MMC_POWER
I insert my branch code instead of these instructions (thumb code):
--- Quote ---ldr r0, [r7] @ r7 points to the acmd41 command response, so r0 contains the response
asrs r1, r0, 31 @ if the bit 31 was set (meaning card ready), now r1 == 0xffffffff
adds r1, #1 @ if the bit 31 was set, now r1 == 0
beq card_ready @ if the bit 31 was set, branch to card_ready
...
card_ready:
lsls r0, r0, #8
lsrs r0, r0, #8 @ clears the 8 most significative bits
str r0, [r4, #0x14] @ store the result in memory (it indicates the supported voltages)
ldr r0, [r4, #0x8]
--- End quote ---
I have put the branch at the location card_ready, so as soon as the correct response is detected, it executes the bootloader.
To dump the content of the structure when the first call to init_chip returned, I have put my branch between the 2 calls to init_chip function.
CAUTION: Don't forget the OF code is interrupt-driven !
The 2nd call to init_chip returns when the procedure is still ongoing through the interrupts (init_card is called back from the isr, again, and again)
The OF uses a busy loop (checking CmdActive bit of MMC_STATUS) to know when it completed.
I dumped the structure used in the SD code (of size 0xEC bytes), here it is:
--- Quote ---offset - value when acmd41 succeeded - (value when 1st call returned if different) - comment
00 C8000000 @ pl180 controller base
04 3D09000 = 64000000 = clock reference (64MHz, probably CGU_PERI)
08 0 @ card selected (value written in MCI_SELECT)
0C 0
10 1 (0)
14 0xFF8000 @ the supported voltages
18 6429 (0) @ a function called at various places in the init function
1C 45E9 (0) @ the command response handler (it is the init function itself)
20 - 24 : 0
28 0 @ another function, always set to 0 (NULL)
2C 4 (0)
30 400 (0)
34 3 @ the clock divider for "high" frequency of 20MHz (64/20 == 3)
38 - 44 : 0
48 0 @ here it's weird, it should always be set to 1, and this value -1 is written into MMC_SELECT, not sure why it's 0 there (to analyze)
4C - 60 : 0
64 10
68 - 74 : 0
78 4D (0) @ the loop counter for acmd41 (starts at 0x50, decremented each time acmd41 fails, abort when it reaches 0)
7C 1FF
80 1FF @ I'm not sure, but it corresponds to the maximum clock divider we can use in MMC_CLOCK (511 == 255*2 + 1)
84 - A4 : 0
A8 8 (1) @ The status of the card in the intialisation (detailed after) , here means we were reading the acmd41 answer
AC 1 (0xffffffff)
B0 - D0 : 0
D4 1 (0) @ To check carefully, at some point, thevalue 1 seems to mean SD (as opposed to MMC), but it is set to 2 and 0 as well .. quite a few branches depend on it, to investigate
D8 0 @ Indicates if the card is SDHC or not
DC - E8 : 0
--- End quote ---
Here are the values I have found for the offset A8 of this structure (the status)
* 1 : the pl180 clock has been enabled
* 2 : ?
* 3 : ?
* 4 : will issue a go idle (cmd0) command
* 5 : will issue a send_if_cond (cmd8) command (to check sdhc support)
* 6 : will check the send_if_cond answer
* 7 : will send a send_op_cond command (acmd41)
* 8 : will check the send_op_conf answer
* 9 : will read cid
* 10 : will read rca
* 11 : will read csd
* 12-19: ?
Note that higher values are used in another function, they probably have meaning for data transfer
Hope that narrows the research we have to do
See you
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version