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

[calv]

You could set all GPIOs (except those needed for display) to read, and read them in a loop and display for each bit a pixel, so you can see the status. Then you can see the response of the buttons directly on the screen.

[funman]

Hello, I had another idea I already experimented on 'real' OS like windows & linux to understand what they needed to boot: delete stuff until it doesn't boot anymore

So far I disabled some functions (one by one, not all in a row), by writing a 'bx lr' instruction at their entry point

• The function which switches between 20MHz and 200kHz clock speed, and toggles bit 6 of MMC_POWER (opendrain)
• The function which modifies i2c registers (4 consecutive calls in the hardware init)
• The function just before this one (related to i2c also)
• The last function called in 'init_card' (related to clock divider and data_ctrl register) : it seemed refreshing library was slower but mp3 still played real time
• The function which toggles bit 7 of MMC_POWER (rod) and pin D7

I also replaced the function used in field 0x18 of the structure (which was only set for the 2nd call to init_card) by NULL.

And each time the OF booted fine, which meant it had access to the SD

I also disabled this ones:

• The function which initializes DMA
• The function called in the isr

And each time the OF didn't boot (black screen).
That doesn't mean the SD init didn't work because these functions are likely used to transfer data, and if it can't transfer the boot logo from SD we can't see it.
Of course I suppose the logo is loaded from SD, but I have no evidence of this.

Something else: before dumping the content of the structure between the 2 calls to init_chip, I made sure all the interrupts had been executed, and the voltage wasn't set so the function failed.

Now I'm running out of idea of what to disable with a single instruction write (I don't want to modify too much mkamsboot by fear of bricking my Clip).

Now that we can ignore those functions, reverse engineering is getting a little bit simpler


EDIT:
After resting a bit, I see the first call to 'init_chip' will in fact shut down the controller, and not call the 'init_card' function at all, so we only have one call (well plus the times when it's called from  the isr) to analyze.
That explains why they were not waiting for the status of the SD to be cleared ^^

[Moarc]

I'm very happy to help out on this project if I can. I do not want to damage my current c250, buts thats an easy problem to solve - I just went out and bought another one. The local store is selling them for about $22 dollars US so its not much to spend if it'll help get Rockbox up and running on one.
So fire away - tell me what you want and where to get the info i'll need to do it, and I'll do what I can to help.

 

You can:
- help us with hacking original firmware
-  disassemble your playes and send us scans/photos of hardware
- get $22 from us, buy a player and send it to somebody of us :p

[funman]

First thing to do is to find out at least one button so we can use it to dual boot and add the c200v2 target in the rockbox tree.

To do that you need an old version (revision 18706 is fine) of mkamsboot, the one in svn is too complex.

You will patch your firmware with a check for 1 gpio pin (there is 64), and it the OF will boot immediately or with a little delay, depending on the value of this pin.
Then start the OF, note the presence or not of the delay; shut it down; start it again while pressing a button, note if the delay changed.

Note that you'll need to modify the test.S file to include the button check.

Maybe it'll be easier to come on IRC to do that.


Something else, I've gained access to the embedded SD card !
The diff is really small but was hard as hell to find

Next step: implement the full SD protocol to read (write can wait) a firmware file from it and boot it.

[fragilematter]

Also tested on e200v2:



Funman awesome job dude!

[gabe565]

Just tested on my Fuze, it does the same thing that fragilematter 's e200 does. I don't have a camera with me right now, but I will have a picture up soon!


EDIT:
Here's a really bad picture taken with my phone, you can barely tell what it says, but it works for now.
It says:

Loop number #2
OP COND: 0x80FF8000
now - card ready !

EDIT 2: I know this is a stupid question, but is there a dual boot yet, or should I just reinstall the regular firmware?

[kugel.]

My today findings:

a) On the Fuze, you need to have the backlight on for the buttonlight. GPIO D7 is the button light, but setting it high doesn't do anything without lcd backlight. That's the reason I thought it's not D7 in the first place, we just didn't have backlight, and so buttonlight didn't work.

b) I can 'access' my external microSD after #defining HAVE_MULTIVOLUME. Without a mSD inserted, it reads *PANIC* response timeout, and with a mSD inserted, it reads card ready just like with the internel one. It also needs 2 loops for the external card.

[RockRabbit]

First thing to do is to find out at least one button so we can use it to dual boot and add the c200v2 target in the rockbox tree.

To do that you need an old version (revision 18706 is fine) of mkamsboot, the one in svn is too complex.

You will patch your firmware with a check for 1 gpio pin (there is 64), and it the OF will boot immediately or with a little delay, depending on the value of this pin.
Then start the OF, note the presence or not of the delay; shut it down; start it again while pressing a button, note if the delay changed.

Note that you'll need to modify the test.S file to include the button check.

Maybe it'll be easier to come on IRC to do that.


Something else, I've gained access to the embedded SD card !
The diff is really small but was hard as hell to find

Next step: implement the full SD protocol to read (write can wait) a firmware file from it and boot it.

I''ll need to know the following:

1. Where to get version 18706 of mkamsboot
2. How to reteive it
3. How to compile it
4. How to install it on the player.

Ive had no luck so far locating this information trawling around on the site, although its a big site and I have'nt had time to explore it thoroughly. Can you point me in the direction of the info or perhaps provide it to me yourself?

I have downloaded the source for Rockbox and attempted to compile it. So far every attempt with different targets (e200 v1, e200 v2, c200 v1) has errored out (various errors) some way thru the compile process. I wont go into that now, but I am wondering if its anything to do with running Ubuntu 8.10. Will follow that up with someone later if I cannot vlear the problem myself.

Regards,

Phil T.

[kugel.]

http://www.rockbox.org/twiki/bin/view/Main/DevelopmentGuide, http://www.rockbox.org/twiki/bin/view/Main/LinuxSimpleGuideToCompiling and http://www.rockbox.org/twiki/bin/view/Main/UsingSVN should help you.

[funman]

Hello !

Finally I committed the bootloader code to the SVN repository
Now there is no need to reflash always with mkamsboot, standard make zip and unzip will work fine.

Some stuff remains todo:

• Make the Normal build target at least .. build, because now it doesn't
• Check out for problems on Fuze/e200/m200 (but I hope there will be none)
• See if we can reinitialize the SD controller & cards in the newly booted firmware (that's a bit boring to do so, I imagine we could transfer the Card registers between the bootloadER and the bootloadED, but that's not very clean ...)
• Code Code Code Code
• Code Code Code Code

Many thanks to all the people who wrote that big piece of software in the first place, and to the people who helped/tested on the sansav2.
It's very interesting and I learn a lot of stuff

See you !

[Bagder]

Isn't it time we added one or two v2 bootloaders to the build table now? I mean to make sure they keep building fine etc.

[funman]

The "USB disk" offset (the number of blocks reserved for the OF in the SD) is hardcoded and needs to be calculated for e200 and fuze since they have too big firmwares (the value for Clip is 10MB, and is likely the same for m200 and c200).
You just need to print the number of sectors reported by the card and substract the number of sectors reported by the computer when you plug the model.

Moreover the code doesn't seem to work with a 8GB e200, it was only reported to work on 1GB Clip.

Maybe the SD card doesn't report as SDHC and we need to do "bank switching" (there is a vendor specific command used in the PP driver to do so)

That will need some code from the owner of a high capacity model.

The bootloader can be added to the build table, but since it doesn't work on all models maybe it can wait a bit ?

[kugel.]

My Fuze's 4GB also have been detected as 1GB only.

Also, when trying to compile the build, I got a linker error. My rockbox.sansa didn't fit into DRAM. Then I replaced MEMORYSIZE with 8 in firmware/target/arm/as3525/app.lds and it compiled.

Is the memory size from configure not properly passed to app.lds?

Sadly, I get the disk_init failed message, so i can't test further.

Edit: My microSD is detected properly with 4GB.

[funman]

Moreover the code doesn't seem to work with a 8GB e200, it was only reported to work on 1GB Clip.

Maybe the SD card doesn't report as SDHC and we need to do "bank switching" (there is a vendor specific command used in the PP driver to do so)

That will need some code from the owner of a high capacity model.

I have a Sansa e280 with 8GB.
I'm not sure if I can help here because my programing skills are rather low but maybe I can have a look, nevertheless...

If you have a look, read a bit the firmware/target/arm/ata-sd-pp.c file, I hope a similar technique is used (this file is used in sansa e200v1 and c200v1 at least).
It seems the SD is not reported as High Capacity, so I suppose the code switches between several 1GB banks.

[RockRabbit]

http://www.rockbox.org/twiki/bin/view/Main/DevelopmentGuide, http://www.rockbox.org/twiki/bin/view/Main/LinuxSimpleGuideToCompiling and http://www.rockbox.org/twiki/bin/view/Main/UsingSVN should help you.

Thanks. I had already used the SimpleGuideToCompiling to compile rockbox but it did not work. I added the path to perl mentioned in the DevGuide and also re-donwloaded the source, and now it works. Not sure which bit fixed it, assuming the perl link.

I have been able to retrieve and compile the mkamsboot, but without knowing what to modify or how to install it I cannot go any further. BEing completely new to the project it looks like I will need to spend loads of time going thru the code, which is probably beyond me. Unless someone can perhaps provide me with the exe and instructions how to install? If no one has the time to do that, I may not be able to go any further at present.

Phil T.