Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
andva:
Next installment: some work on the firmware format. Disclaimer: I don't know a thing about ARM code, but I can try to help :P
I have inspected the firmware binary file (for the e200), and, specifically, the "deadbeef" packing appearances. I have found some interesting structure to it, and I'll post it here in hopes that somebody with more knowledge of ARM assembler can pick it up.
The firmware seems to be divided in some kind of logical "blocks". The first area of the firmware comprises the first 122368 bytes (from 0 to just before 0x1DE00). Then, for simplification, the rest of the firmware can be divided on 77 blocks, each exactly 200 kb (204800 bytes) in size save for the last, which is ~40 kb. For convenience I have numbered these blocks 00 to 76 (I used a splitting utility). So the "header block" begins at the beginning of the firmware and is 122368 bytes long, and then "block N" begins at 122368+204800 * N (in hex, 1DE00 + 32000 * N) and is 200 kb long.
All the first blocks (the header and blocks 00 through 15) use padding. The padding is invariably a bunch of 0xFF bytes until what seems to be the next multiple of 512 (0x200), followed by 0xDEADBEEF padding until the end of the block. (This is not apparent in the header block because there is only a short FF section and no DEADBEEF; in fact, what I did was looking for the end of the DEADBEEF sequences, finding that they always were located 204800 bytes apart, and then extrapolating back to find the end of the header block.) These blocks look like some kind of "libraries" of code. I suspect that the main bulk of the code lies there.
By inspecting the strings, one can guess what each block is for:
Beginning block: initialization, basic filesystem operations, "tasks" (there are a few defined: Control Task, Decoder, Encoder, etc), a suspicious string which says "ASW is erased!", date and time functions, and probably the component which updates the firmware (the string E200P*.BIN is a giveaway)
Block 0: seems to be something related to the DRM
Block 1: more DRM-related things, a bunch of magic numbers, and what seems to be the default boot sector (maybe the formatting routine)
Block 2: something having to do with MSC (string: "Mass storage only"), libjpeg, and more magic numbers (video decoder?) Some firmware-related things, M3U reader, MTABLE.SYS reader, recorder, and Rhapsody-related things.
Block 3: Audible decoding, test mode, MTP implementation
block 4: no idea, could be some kind of image
From now on, one can find some of the functions referenced in the beginning block. The giveaway is that, at the end of each block, there is a string with the function name, plus "cr_5_0_develop" and what looks like a timestamp.
block 5: video decoder (near the end of the block, the string is "mp4_decoder")
block 6: mp3_decoder
block 7: wav_codec (recorder/player)
block 8: aud_decoder (Audible)
block 9: drmpd_persi (DRM related, probably)
block 10: Microsoft DRM in all its glory (drmpd_unlro and a few more things, the strings are a giveaway with things like "ExpirationDate", "FirstUseDate", etc).
block 11: drm_unloc function
block 12: wma decoder
block 13: more wma related functions
block 14: yet more wma/drm functions (it's disgusting how complex DRM is to implement!!)
Block 15 is totally empty (0x200 bytes of 0xFF padding, then DEADBEEF)
Blocks 16 to 22 seem to be data. Some of it looks like images. 17 and 18 contain all localization strings. 18 also contains the Rhapsody capabilities XML.
Block 23 contains the device certificate for the SANSA (more DRM things). There is some weird padding in it.
Block 24 is all DEADBEEF.
From now on, most blocks contain no recognizable strings. I think they contain all the artwork for the player, with no padding. Sometimes, the string HEADER pops up, but I don't know if it is supposed to mark the beginning of some data file.
From 71 on all blocks are all DEADBEEF, save for the very last 4 bytes, which, as Bagder has stated, could be some kind of checksum.
Hope this is of some use.
hth:
--- Quote from: andva on January 28, 2008, 11:01:40 AM ---
--- Quote from: hth on January 17, 2008, 02:03:19 PM ---I then tried to find that 90MB message within the firmware, but didn't find it, yet.
--- End quote ---
Was the exact message "Not enough space for Music DB. Please free 90MB", maybe? It is on the firmware, and it is repeated in quite a few laces (it seems to be the same in all locales).
--- End quote ---
Thank you! It was the message.
--- Quote ---If we can somehow get to the point where the firmware can be erased from within itself, I would suppose that the player would boot on the recovery mode. (Or be borked for all eternity :))
--- End quote ---
Yes, there might be a chance, that after that the player would turn into
a mode supporting initial factory programming, but i'm not sure.
On the one hand, the rom on the SanDisk SoC may contain a different or elder bootloader not supporting usb proming.
On the other hand, i'm missing information on what the AMS rom-bootloader would do exactly and specifically, after triggering a usb bootloading mode. Maybe we trigger it, but don't see anything happening because it's
1. expecting to read the firmware from an usb device in a certain format (which is not described in the datasheet).
2. not able to control the lcd and thus able to display a message like 'no firmware for update found, bootstaging from nand.'
[edit]merge of follow up posting:
--- Quote from: andva on January 28, 2008, 01:48:25 PM ---Next installment: some work on the firmware format. Disclaimer: I don't know a thing about ARM code, but I can try to help :P
--- End quote ---
Great work! I neither know much about ARM, but i've started reading quite a lot about it.
I hope the SoC supports fetching and executing instructions directly from the iNand after mapping the NAND memory into it's address space. As rockbox uses memory statically, it maybe able to reserve about 50k internal RAM for variables, another ~150k buffer for audio decoding and the remaining 120k free for other things.
If so, i will buy a cheaper DAP without additional SDRAM like the Sansa Clip and start coding a bootloader on that, first (in about two weeks, for i don't have much time until then). If it bricks, who cares, but i don't wanna brick my e280... :)
[edit]forgot something i tested out at home:
1. On e200 v2 players, the firmware copied into root must be renamed to e200pt.bin to enable diagnostic mode (so diagnostic menu may work on the m200 v2s as well).
2. Firmware updates (triggered by any file named e200p*.bin within root directory):
* Initiate firmware update, display "Updating firmware."
* Read the e200p*.bin, is it a valid firmware image? (1)
* (1) Yes:
Flash to NAND, display "Upgrade completed" message, then turn off
* (1) No:
Do nothing, just turn off, display nothing further
andva:
I wouldn't be _that_ surprised if the wheel had something to do with entering recovery mode. It is a remote possibility, since that would probably make it somewhat unreliable (you'd have to "click" just at the right time), but it can't be ruled out. The fact that the Clip does not have any rotary encoder is not definitive - after all, the e2x0v2 does have the same key that the c200 uses for (what seems to be) recovery mode, but the same trick does not work.
However, if the c200 has it, then I'm convinced that the e200 (more expensive, more complex) will also have a way of getting it into recovery mode. If the c200 way of doing it is any indication, then the steps are simple: turn off, set HOLD, hold a button (
bclick:
andva - Great work and excellent deductive reasoning. I had just duplicated that very effort, and came here to share it - it's still great to be late to the party!
On flag byte #5 - the T version has ALL languages supported. It is also confirmed that the Hebrew version omits Arabic, and vice versa (for socio-political reasons I suppose). All the other languages are supported by these versions. BTW, G&H are both Hebrew and M&N both Arabic; the difference of course being the radio enable bit.
I came upon the *.BIN suffix letters searching in the m300 FW (at 1D5F4) and at once realized I could have avoided trying all the letters...LOL...and the byte mask jumped out next. In the m300 (Clip, for me) FW, it is identical to what you have listed. So that's great - parallelism between models...
If you search for reference to the "version.sdk" file, it appears that this is written out if missing, using hardcoded strings from within the FW (but the FW version is dynamically written out..between the hard coded strings). Bear with me...
Now, what I suspect the ERASEME.CMD file contains is the text "Do Not Release.." etc., and some factory test / action results in the device writing this file to mmc:0:\ (root), possibly as a flash file system test file / debug flag.
Note the m300 FW appears to have nearly all the rest, including refs to JPG files (which, just ain't no way...), and a diagnostic menu for SD slot testing, as it's bigger brothers. Plenty of commonality. But on the Clip, the "free up space" string calls for "only" 30MB...
saratoga - good points. Somebody has to always throw cold water on!
j/k :D - but even if a full RB port to the Clip is not feasible, there are those who would still be interested in exploring the possibilities and doing a little bit of "personalization", optimization, or plain old awakening of resident but inactive features. MP3 encoding for radio and voice recording alone would be huge.
EDIT - I put an ERASEME.CMD file on there (with just that notice text, no CR/LF), restarted, and....nothing. Music was not deleted, so it's presence alone won't trigger a format. The .CMD file itself was deleted, however.
AND - the UPGRADE.FIN file is written out after a firmware upgrade. I found it by loading a "new" FW file, disconnecting (FW loads, then shuts down), then connecting in "forced MSC mode" (unit OFF, switch in HOLD position, press center button, plug in cable, wait till "connected" is displayed, release center button). Apparently some house cleaning is pending. It contains a single byte (0x03) that decrements with each such connection, and it is deleted when it reaches 0 or the device is connected normally (I think). Anyway it's nothing very exciting.
:o I have also found that the FW can be loaded without any "region code" at all; as "m300.bin" it simply updates the existing version. Probably what the Sansa Updater delivers...
AND, m300SelfErase is nothing more than yet another mechanism to load firmware. I first tried placing a 0 byte file w/ that name, the Firmware Updating message came up, but no Completion. Renamed a copy of the FW file, and in it went, to completion - without altering the region code already in place.
EDIT Ditto for "m300V01"; yet ANOTHER FW filename... Sheesh! Wish there was something more useful to report - but at least, this is another "known"...
And no, ERASEME.CMD is not another way to load FW, and yes, I tried it :P
hth:
While measuring here and there on an e200 v2, i found out something that maybe interesting:
On the right side of the front pcb (under the lcd, on its back is the micro-sd slot, about half an inch above the headphone), there are 8 blank connectors.
At the top of them, there's an arrow and the text DIP. I start counting the most top connector with 1, thus the bottom one is 8. The connectors are no dupe of the micro sd signals - which was what made me curious:
Measurings are quite inaccurate (about 2% tolerance)
Li-Io Battery: GND1..BVDD: 3.95V; GND2..BVDD: 3.91-3.92V
Resistance[Ohm] to GND: 1:15-17.5k; 2..7: INF; 8: 0
Voltage[V] to GND:
--- Code: --- Descr.;Supply over USB only; Battery supply only
1: VDD?? ; 3.12-3.13; 3.14
2: NC??? ; 0.00; 0.00
3: ?? ; 2.45; 2.46
4: ?? ; 2.45; 2.47
5: ?? ; 2.45; 2.46
6: ?? ; 2.45; 2.46
7: RST?? ; 2.90; 2.90
8: GND ;
--- End code ---
7: Looks like the player is off for less than a sec, then while still
measuring:
1.) SanDisk Sansa logo displays (like when turning on)
2.) a) USB Connected: Connected message displays
2.) b) No USB: Last screen displayed again, then music database is
reread
This looks like a kind of reset, the 2.90V did not change.
So maybe this connector is for diagnosis purposes!!!
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version