Rockbox Development > New Ports
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:
--- Quote from: RockRabbit on November 07, 2008, 01:42:13 AM ---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.
::)
--- End quote ---
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!
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version