Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Bagder:
--- Quote from: atomikpunk on May 06, 2008, 12:51:31 PM ---I'm pretty new to the "firmware replacement scene" so I take any advices :) But since I really don't want to brick my device, I'd prefer if some other brave souls would try it before I do ;D
--- End quote ---
I'll be bold and say that as long as we do this slowly and carefully and the code we try to run is reviewed and agreed to by a few Rockbox persons who should know this stuff, we will of course fund a replacement player for the brave soul who tries this the first time - if it breaks.
saratoga:
Figuring out how to do JTAG might be a better approach. We've got the docs and the pinout, so we could unbrick if things go bad.
atomikpunk:
Tonight I created a wiki page for the Sansa v2 firmware. I also linked to it from the v2 port pages (and BTW created the m200v2 port page).
Please have a look there, and feel free to comment...
linuxstb:
I've just ordered myself a 1GB Clip (as a cheap example of a v2), and (unless someone else gets there first), will probably attempt running my own code on it.
My plan of attack is along the following lines:
1) Understand the firmware format, and determine where the different parts of the firmware file are loaded into RAM.
2) (Unless such space is already available), attempt to "expand" the firmware file to create some space to insert my own code in.
3) Modify the branch instruction at the reset vector (0x0) to branch to the start of this new space, which initially will just contain a branch instruction to the original entry point of the firmware. This is a risky step if we haven't got the load address figured out correctly, but relative branches can probably be used to minimise/remove the risk.
4) Add a delay loop into my code, so that there is a visible delay when booting (this will be my initial feedback method to see if my code is working - i.e. "true" will be to insert this delay before branching back to the OF, "false" will be to return to the OF immediately).
5) Using that delay loop as an indicator, investigate the GPIO pins, and see which (if any) buttons are linked to GPIO. i.e. for each pin in turn, perform the delay based on its status, and try booting with and without each button pressed. This may take a while, although disassembly of the OF might help.
6) (Hopefully) once a suitable gpio-detectable button is detected, then use this to implement dual-boot, with the default action being to branch back to the OF's entry point, and the "on key press" action being to continue to execute our own test code.
Anyone have any better ideas? I agree JTAG would be nice, but I don't own JTAG hardware and have no skill with a soldering iron...
atomikpunk:
Great linuxstb, please have a look at this topic and the wiki, we already did some work on the v2 firmware file format and are pretty close to be able to create an experimental version to play with. There is still a field that we don't understand that could prevent creation of custom firmware files, details are on the wiki.
I really like your "non-destructive invasive" approach. I already did some OF analysis though I'm far from finished. In fact, I was to the point of GPIO analysis in the disassembly, so I'll share what I find as soon as possible. But maybe I could help in the development of your dual-boot experimental firmware. Most of my analysis details are on the wiki at http://www.rockbox.org/twiki/bin/view/Main/SansaV2Firmware, but I left some incomplete/misunderstood analysis details locally on my machine (specifically on the disassembly analysis).
j8048188: Could you detail on your RAM concern about the clip? Could it also matter for other models?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version