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

[linuxstb]

The main Rockbox website is currently unavailable, so people may not see this, but I've just committed the Fuze to SVN, including my first attempt at an LCD driver.  (this doesn't use Kugel's work on adding the Fuze to the build system, as I couldn't access that patch this morning - I had to redo it myself).

This needs testing by a Fuze owner.  Details of the commit are here:

http://svn.rockbox.org/viewvc.cgi?view=rev&revision=18957

It's using the backlight code from the e200v2 - I don't know if that has already been tested or not.  The LCD driver itself is still in a very raw format, but I'm hoping it's working...

[kugel.]

Ok, I'll give it a shot in a few minutes.

Edit: No success

I've done some changes changes (such as correcting firmware/SOURCES) which shouldn't break the lcd code though if it was working.


I'll upload my svn diff to the tracker, it includes a keymap and a simulator. FS#9512

[Mac n00b]

I have been snooping around in some of the latest IRQ logs, and discovered that you are in the need for some Clip-pictures for the Simulator, here are two pictures i have taken myself, you are free to use them anyway you want:

http://img222.imageshack.us/my.php?image=clipsimyg4.png

[kugel.]

Good news! After adding _buttonlight_on() to the bootloader, I saw this:


Rockbox logo on the Fuze! Good job guys.

PS: Sorry for the crappy quality. I only have a mobile phone camera. The logo is rather light blue than yellow.

[bombjack]

I fixed the Clip image a little.
Its far from perfect but at least usable I think.

Strangely enough the same file looks much better in gimp than in firefox?!

Grab it from here:
http://img504.imageshack.us/my.php?image=sansaclipfc1.png

Hope I could be of help.

Great work you're doing here!

[funman]

Hello

Great finding for the fuze, the only targets without display are now the c200v2 and the still mysterious Clipv2 !

Thanks for the images, but there is already a background image for the Clip simulator here

If you have noticed FS#9512 we miss an image for the Fuze however..

[bombjack]

Ok, seems like somebody has been missing something ...
Just trying to figure how things work here.

Anyway: What about this Fuze then?

[linuxstb]

The initial version of the Fuze LCD driver had corrupted colours, but that's now been fixed.

[funman]

Hello

Good news today: I am able to hijack the Clip OF and branch to my (modified a bit to not disturb the current state) bootloader.

Thanks to the help of mc2739 who helped me testing & debugging the code on his unbrickabe e200, and not thanks to the numerous and still unexplainable data aborts which slow down the procedure, I can now look at the OF state precisely.

Oh and I chose carefully the location where I branch from the OF to my bootloader: it's exactly when the embedded SD card answered "I'm powered-up", i.e. the bit 31 of the response to acmd41 is set.

Yesterday mc2739 was not answering (or just a bit since it appeared in lsusb, but not as a mass storage device); let's hope it works again when he comes back!

For now I checked the i2c registers and the pl180 registers but there is nothing interesting there..

Next step is to check GPIO directions & values (now I can't run the test presumably because of the data aborts).

EDIT1: GPIO checked, they just show what we set in the lcd init routine
EDIT2: GPIO re-checked, before the lcd init routine and they all are on input

If you hackers have a clear idea of what to check just tell it, or contact me to have the hijacking code (I don't want to give it to everybody to avoid people bricking their devices just to be on the razor edge, especially if they don't have anything clever to test)

[kugel.]

I'd like to have this code in order to check the Fuze GPIOs. They're more or less unknown at all (except A3).
That should help finding the buttons at least.

[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):

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]

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:

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

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