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

[atomikpunk]

I continued analyzing the M200 4.1.08 firmware and understanding more stuff in it, though I'm far from complety understanding the whole firmware. Nonetheless, here we go for an update on my findings.

For consistency, I will document every addresses in here relative to the file beginning except where otherwise noted.

Firmware file overview
The firmware file is divided in a bunch of blocks as we already know. In the M200 firmware, there seem to be 32 blocks:

Block Index	Address in the file	Description
0	0x000000	Firmware header
1	0x000400	Firmware
2 to 18	0x400 + (Index * Block Multiplier)	Library blocks
19	0x21AC00	Empty library block (filled with 0xFF)
20 to 26	Unregular, read below	Resource blocks
27	0x4D5400	Empty resource block (filled with DEADBEEF)
28	0x4D5600	Unknown data block
29	0x4D5800	Unknown data block 2 (only contains 0xDF0 at 0x4D5800)
30	0x4D5A00	Unicode certificate data
31	0x4D6800	Empty ending block (filled with DEADBEEF)

Firmware Header Block (0)
Nothing newer than what is already known.

Boot Code Block (1)
I can confirm that this block actually contains a bootable code. So this code is loaded at address 0x0000000 in whatever ROM/FLASH/stuff that the AS3525 can boot. This code initialize some stuff like the AS3525 clock generation unit, etc. There is MUCH more to analyze in this block since this is where we'll find the most info about the V2 design (peripherals addresses, how to initialize the devices, etc.).

The following exception vector table (that contains jump instructions, which is standard for ARM vector tables) is present at 0x400:

Address	Function	Handler summary
0x400	Reset	Main code at 0x4B8
0x404	Undefined instruction	Infinite loop
0x408	Software Interrupt	Infinite loop
0x40C	Prefetch Abort	Infinite loop
0x410	Data Abort	Infinite loop
0x414	Reserved	NOP
0x418	Interrupt Request	Interrupt handler at 0x8468
0x41C	Fast Interrupt Request	Interrupt handler at 0x8468

Library Blocks (2-18)
The 17 library blocks are tagged with the following "library names":

Block Index	Library Name
2	usb_functio
3	mp3_decoder
4	otg_functio
5	wav_codec
6	acp_decoder
7	aud_decoder
8	drm10_nonpk
9	drm10_pkcpt
10	drm10__Init
11	wma_decoder
12	wma_decInit
13	wma_decPlay
14	drm10_InitT
15	drm10_host_
16	wmaPDDRMini
17	wmaPDDRMper
18	sd_reload__

The following (improved) table describes the library blocks header (offsets are relative to each block base address):

Offset	Value(s)	Description
0x00	Library name	Offset to the library name
0x04	Library base address	Base address of the library
0x08	Library end address	Seems to be the library end address, but seems to include extra space(?)
0x0C	Block effective size	Size of effective data in this block
0x10	Unknown value	Still unknown. Needed space for variables?
0x14	Exports count	Number of publicly exported functions
0x18	Exports	An array of [export count] addresses which points to library functions

Resource Blocks (20-26)
These blocks are still mostly misunderstood, but they seems to contain various resources (localized strings, etc.). Resource blocks size is understood to be the next 0x200 bytes boundary after the block effective size. For example, a resource block with an effective size of 0x1234 would end 0x1400 bytes after the block beginning.

The resource blocks have the following header:

Offset	Value(s)	Description
0x00	Block effective size	Size of effective data in this block
0x04	Resource ID	The more plausible signification is a resource ID number
0x08	"HEADER"	The "HEADER" ascii string

So that's about it for tonight, I hope it helps understanding the firmware file format. I'll try to continue understanding the file format... Or if more experienced developpers thinks I could help somewhere else, feel free to suggest!

Edit: Changed the "Boot block of the firmware" to "Firmware" as block 1 seems to be the whole firmware (without libraries)

[Bagder]

I'm curious why you think that block 1 is "boot code". Why isn't it simply the entire firmware, apart from the lib stuff that is provided in the other blocks?

Also, given this description I figure a custom firmware could easily just be block 0 and block 1.

[atomikpunk]

Lambda: Yes I did however I did not have time to ask for write permission yet. You are right, this kind of info is best stored on the wiki, though I think that maybe we should dedicate a separate page for the V2 firmware stuff if we don't want to monopolize the M200 page for the firmware

Bagder: You are right, what I really meant to write was that block 1 is the block that is effectively run by the hardware on boot. Though I didn't analyze everything in there, it is reasonable to think that is much more than just a bootloader in this block. I also think that this block could hold the rockbox bootloader and this should do the trick. Probably that we will need to follow the firmware file format nonetheless, for example, on a first pass, only substitute block 0 and 1, then on a second pass completely the firmware file only to include required blocks.

Can someone reading the forums and with wiki admin access give me write access to the wiki? Else, I'll try to poke someone on IRC tonight...

[Bagder]

Seeing that we don't have a recovery mode, we need to be very very careful when trying to insert code and run it on the v2 models, so yes we should make the Rockbox bootloader get inserted in the block 1 part, and based on some magic (like if we press a key, assuming we can easily read that without too much code) the code should proceed as normal and not run the Rockbox code. Thus we minimize the risk of bricking the device due to putting a bad image onto it.

This all of course requires that we now know how to generate a complete firmware upgrade file, so that we can insert a chunk of code in block 1 and generate a new file to upgrade to. Given the last updates of the firmware format, there's only that checksum in the header for block 1?

[atomikpunk]

If you don't mind, I'll create a specific wiki page about the V2 firmware format here and link every v2 port pages to it. It will alleviate port pages from firmware details and still provide info to those interested... And since many Sansa devices use the same firmware format, I guess that a central page about it wouldn't hurt... What do you think?

Also based on Bagder idea, I guess that looking into the current firmware for button sensing would really help so I'll aim my analysis around that...

Calculus: thanks for the wiki access, I'll have a look at it tonight.

Bagder:  I guess that should do it... There are still a couple of unknown fields in the firmware header, but they seem to always be the same so I guess we could use those without much damage...

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

[Bagder]

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

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?

[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...