Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
linuxstb:
I've started analysising the Clips's firmware (based on the work done by atomikpunk), and it seems to be loading code to the 320KB internal SDRAM at address 0x0, plus more code to address 0x30000000 - which is documented as being the external SDRAM.
So the fact that the disassembky pictures here:
http://www.anythingbutipod.com/archives/2007/11/sandisk-sansa-clip-disassembled.php
are only showing two chips (presumably the AMS SoC and the 1/2/4GB NAND flash) is confusing me.
Here is what my test utility is showing for a Clip firmware (the libraries are sorted by load address, not the offset in the firmware file):
0x00000000:
HEADER: 0x00000000
FirmwareHeaderIndex: 0x00000000
FirmwareChecksum: 0xbc2aff7c
CodeBlockSizeMultiplier: 0x000000ea
FirmwareSize: 0x0001d228
Unknown1: 0x00000003
ModelID: 0x22a1
Unknown2: 0x0000
Calculated firmware checksum: 0xbc2aff7c
LIBRARY BLOCKS:
Offset Name BaseAddr EndAddr BlockSize Unknown1 EntryCount
0x00239800: "sd_reload__" 0x00024ce0 0x00025a24 0x00000d44 0x00000018 0x0000000c
0x0024d800: "dh_decoder_" 0x00029330 0x81031a00 0x0000896c 0x00000414 0x00000001
0x00135800: "aud_decoder" 0x00029330 0x0002dce4 0x000049b4 0x0000a5a4 0x00000001
0x000e5800: "wav_codec " 0x00029330 0x00036ae0 0x00006674 0x00006508 0x00000001
0x001d5800: "winmed_boot" 0x00029330 0x0002997c 0x0000064c 0x00000008 0x00000001
0x001e9800: "wma_decoder" 0x00029990 0x0002a408 0x00000a78 0x0000525c 0x00000003
0x00225800: "wmaPDDRMper" 0x0002f670 0x000314b0 0x00001e40 0x00000004 0x00000001
0x00171800: "drmpd_persi" 0x0002f670 0x0003076c 0x000010fc 0x00000000 0x00000001
0x001c1800: "drmpd_unloc" 0x00030770 0x0003811c 0x000079ac 0x0000aec4 0x00000001
0x001fd800: "wma_decInit" 0x00030770 0x00034514 0x00003da4 0x00000604 0x00000001
0x00211800: "wmaPDDRMini" 0x000314c0 0x000343ac 0x00002eec 0x00001000 0x00000001
0x00095800: "wma_decPlay" 0x000314c0 0x00043ff0 0x00012b30 0x00007440 0x00000001
0x0010d800: "acp_decoder" 0x00039000 0x0003ed70 0x00005d70 0x00000030 0x00000003
0x000bd800: "mp3_decoder" 0x0003dff0 0x00045b4c 0x00007b5c 0x000040b8 0x00000003
0x0015d800: "drmpd_nonpk" 0x00042fe0 0x0004afe4 0x00008004 0x00000000 0x00000001
0x00185800: "drmpd_pki__" 0x00042fe0 0x0004a43c 0x0000745c 0x00000be0 0x00000001
0x00199800: "drmpd_unlro" 0x0004b880 0x0004e978 0x000030f8 0x00000000 0x00000001
0x00045800: "otg_functio" 0x30020f80 0x300d35b0 0x0001fb5c 0x000099f4 0x00000001
0x0006d800: "usb_functio" 0x300026a0 0x300dd000 0x0001e8c8 0x00021614 0x00000001
0x001ad800: "drmpd_mtp__" 0x30040b50 0x3004c3ec 0x0000b89c 0x00016800 0x00000001
0x0001d800: "drmndt_pers" 0x30062bf0 0x30074e24 0x00012234 0x0000b1f0 0x00000001
0x00261800: PADDING BLOCK
linuxstb:
I've been experimenting with trying to install a modified firmware on my Clip, can confirm that the 4 bytes at the very end of the firmware file is a "whole-file" checksum - i.e. a simple sum of each 32-bit word in the file, not including those last 4 bytes.
Without updating this checksum, the only successful firmware update I could do on my Clip was simply swapping two 32-bit words within the main firmware block.
For the record (this wasn't immediately obvious to me), a failed firmware update will just display the message "Firmware upgrade in progress" and then power off the device. A successful update will display the second message "Upgrade completed" before powering off.
I've managed to get the Clip to accept a modified firmware file with a small number of "spare" bytes added at the end of the main firmware image (replacing some of the 0xff padding with 0xdc, increasing the FirmwareSize field in both of the headers, and recalculating the checksums).
What I haven't managed to do yet (and what will be needed for us to run code) is how to extend the firmware image so that it occupies more 0x200-byte blocks than it does originally.
EDIT: I've just run some of my own code on the clip for the first time - "step 3" in my post a few messages earlier in this thread. Now for step 4, which will confirm if step 3 really worked...
linuxstb:
I can confirm that I'm now successfully running my own code on the Clip ;)
This is "step 4" of my plan - I've added a 5 second (approx) delay into the start of firmware, before the code branches back to the original entry point of the original firmware. The firmware then continues to run as normal.
So others can start experimenting, I've committed my test programs to the Rockbox SVN - in the utils/AMS/hacking/ directory. Just edit the "test.S" ARM code to do what you want, and type "make" to generate a patched firmware file (edit the Makefile to point to the unmodified original firmware file).
It requires the standard Rockbox arm-elf-gcc toolchain.
The immediate problem is that I can currently only successfully insert a very small amount of code - up to the next multiple of 0x200.
If anyone makes improvements to these programs, please post patches to Flyspray in the usual way, and I (or someone else with commit rights) will commit.
atomikpunk:
Hi,
very interesting linuxstb. I'll try a patched version with your delay on my M250 to see if it also works on it.
So I guess the next step is seeing if we can insert extra blocks in the firmware file, or at least exactly understand how the updater stores the firmware in the device? Else we'll be stuck with < 0x200 space to play with.
About your step 6, I wonder if the v2 series is handling buttons the same way the M200 v1 did. It seems from SVN that buttons were read from the ADC (?).
Just for the records, in the M200, I think I found some LCD update routine somewhere. It seems that the LCD is connected through DBOP. It probably is an SSD1815 as in the M200 v1. I found some sort of initialization routine and every commands written to DBOP are valid initialization commands for the SSD1815.
I'm still looking at the firmware. Feel free to ask for specific (firmware disassembly) items and I'll see if I can find something about it.
linuxstb:
Yes, it's very possible that the buttons are all on ADC, although it's quite common for at least some buttons to be on GPIO (especially the hold switch).
Assuming the M200v2 has the same 128x64 mono LCD as the v1, then I'm sure you're right about the SSD1815. Which at least makes that step easier. There are two commands specific to the AS3525 that you'll need to find in the original firmware - lcd_write_cmd() and lcd_write_data(). If you've found the LCD init routine in the original firmware, then you should be able to spot these. Plus there is likely to be some LCD controller setup (setting clocks etc).
Writing an LCD driver is always a nice thing to do early in a port - it makes debugging so much easier...
But that will require solving the problem of loading more code than I currently can...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version