Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
hth:
OK, posted as task 8843,
Link: http://www.rockbox.org/tracker/task/8843
Bagder:
Cool, if nobody else does it I hope to soon be able to go over it and commit at least parts of it to SVN to enable more people to join in this effort easier.
Xav:
Here are e200v2 V03.01.16 firmwares:
http://mp3support.sandisk.com/firmware/e200/e200v203.01.16a.zip (America)
http://mp3support.sandisk.com/firmware/e200/e200v203.01.16e.zip (Europe)
http://mp3support.sandisk.com/firmware/e200/e200v203.01.16f.zip (Europe with FM Radio)
atomikpunk:
I recently got into looking at rockbox for my M250 and I noticed that I got the V2 and no rockbox port is still available. I have some skills in electronics, programming and disassembly analysis, and since I'd really like to try rockbox on my M250, I thought I'd help where possible in the project.
So I got the firmware in some tools I got and started looking at the firmware file. For the records, I've got the american V2 version with the 4.1.08A firmware in it. I also took note of the info which badger is keeping on his web page.
First of all, I'd like to thank badger and andva for their work since it is what got me started with the firmware analysis.
It's a bit late here but I think it's worth that I share at least part of my findings up to now. So here we go:
Naming convention & Header block(s)
First of all, I also found that the firmware file for the M250 is divided in what seems to be library blocks. However, I think that what andva consider the header block is in fact composed of 2 header chunks. The first one (that I'll name FWHeader) being only 0x400 bytes long, while the remaining bytes before block 0 are what I call BlockA. So for the blocks naming, I'd mostly stay with the convention andva defined, with the following exception: I'll refer to the 0x400 bytes block as the FWHeader block, and the remaining of bytes before Block0 being referred to as BlockA.
However, I think that the "regular blocks" are only up to the empty block. After that, the block structure doesn't seem to be used anymore. In the case of the M250 firmware, there are:
1 x FWHeader block
1 x BlockA
17 x regular blocks
1 x empty block
then, there are some other unanalyzed data.
FWHeader format
This block is 0x400 bytes long and only contain 2 data structures in it, the first one present at 0x00000000 being (almost) mirrored at 0x00000200. The structure has already been described by badger on his web site, though I think I found a bit more info about it (denoted by italic rows), so here it goes (numbers between parenthesis are for the mirrored structure at 0x200):
OffsetValue(s)Description0x000 (1)This seems to be the index of the header structure0x04ChecksumSeems to be a checksum0x08Block multiplierThis seems to be used in the calculation of the regular blocks size: [block multiplier] * 0x200 = [regular block size]0x0CBlockA sizeBlockA actual size, counted from offset 0x400 in the file (that's why I think there should be both FWHeader and BlockA blocks)0x103A file format version number maybe?0x148-bit checksum?A 8-bit checksum? Would be redundant IMO0x15Model IdModel identifier0x160Zero(?)0x1840Fourthy(?)0x1C1One(?)
BlockA
I didn't go deep as of now, but the first thing is that offset 0x0 of this block is an indirect branch instruction to some code at 0x4B8. I didn't have time to analyze it yet but it seems to be valid arm code.
Numeral block headers
For each regular block, a block header is also present right at offset 0x0 in each block. The block header structure can be incomplete, but the following is always present:
OffsetValue(s)Description0x00String offsetBlock offset to the string describing the block's content0x04Lower addressSeems to be the lower bound of an address range, still unknown0x08Upper addressSeems to be the upper bound of an address range, still unknown0x0CBlock sizeActual size of the block "effective" data, that is where there is valid code or data
So that's pretty much it for tonight, I'll try to continue looking at the firmware when I'll have some spare time. Meanwhile, please have a look at my finding and confirm (or infirm) that it is correct. Of course Badger you can add this info to your web site as you like :)
Good night peeps.
Edit: Clarified the "block multiplier" description in the FWHeader structure
saratoga:
I applied Bagder's checksum code to blocks other then the first one, but unfortunately this did not give me the checksum in the header.
The first header is different then the rest though. Its length is the offset of the next block relative to the end of the present header, while the others are the relative address from the start of the header. But even making that change didn't get me the right checksum, unless i'm doing something wrong. I also tested the theory that the subsequent headers might be smaller or larger, but starting from the end of the block and going backward printing all possible checksums didn't yield the right sum either.
Looks like more work is required.
---
Also interesting, the datasheet mentions a USB repair mode in the SOC's internal ROM that works even if the FLASH is corrupted. Unfortunately, as I suspected you need to trigger it electrically. According to the sheet, GPIOA bit 4 is flipped on and then GPIOA bit 0 is read to see if the "firmware update button" has been pressed to connect them during power-on. Unfortunately, looking at the pictures, its not clear whats hooked up to that those pins in either the E, Fuze, or Clip, as the connecting traces seems to be inside the PCB. At first I thought the JTAG connector might also go to those pins, but it looks like this is not the case on the Clip at least.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version