Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
hth:
--- Quote ---My guess is that the sansa will refuse to upgrade to it. Did you compare the U60 .bin image with the e2x0v2 one to see how similar they are? It could possibly help us figure out the remaining parts...
--- End quote ---
The U60 firmware image is crypted and i don't see a checksum at 0x4/0x204. If you have a look at 0xb4b400...0xb4bb9bf at the u60 bin, you see each 32-bit pair following a pattern regarding each half of each the high and low nibble of the most significant byte. This pattern can be seen at other offsets probably containing neither code nor data as well for byte 2..0, so the cryption varies with the offset.
[edit]merged follow up posting:
I found no recovery mode for the e280v2 yet, so i have some questions regarding recovery possibilities:
* Did anybody get any additional technical information on the boot modes supported by the AS3525, as booting from USB or field firmware updates over usb? If not, is there a standard for field firmware updates over usb?
Page 2: Bootloader on AS3525 ROM: field firmware update by connecting the usb interface
http://www.austriamicrosystems.com/03products/data/AS352x_SDK6_sw_pb.pdf
Pages 24,30: Bootloader on DevBoards: USB + 2nd stage
http://www.ednchina.com/campaign/innovation_conference/download/008.pdf
* The AS3525 has a JTAG interface, which seems not to be accessible on the e280.
Are there any pcb scans for other players using the AS3525, so we perhaps find a player which can be used as a kind of development board with a jtag interface (leaving porting the lcd when everything else works fine)?
bucko:
If you'll excuse my extremely fudgey C, I uploaded an "improved" checksum calculator here: http://www.bucko.me.uk/sansachecksum.c
It walks the file for quite a few blocks before exploding; I didn't bother to work out the offset into the file because I don't know how to fgetpos() an fd. :(
Many of the suspected "checksums" do not change between firmware versions -- even though the computed checksums do. So I don't think any of them are real checksums, and I'm probably missing something in my interpretation of the header.
I'd appreciate it if someone could clean it up and place it in somewhere appropriate.
bclick:
I've discovered a few things:
1.) A factory diagnostic menu; to enable it, rename the FW file m300t.bin ("t" for "test") and place it on the device root, etc. Details on menu content at ABI forum, where I announced that finding to the community, here: http://www.anythingbutipod.com/forum/showthread.php?t=25408
Not sure if that works on the other V2 players based on the AMS SoC but, probably. BTW this was only verified on the .20 Clip FW.
2.) Hidden filesystem contents. By using a data recovery utility and connected in MSC mode, I found a couple folders; ##MUSIC#, which is the MTP data, and ##PORT# (funny choice of name, eh?) which has some rather interesting file content. There is a ~20MB file called Object.dat, which I have not yet analyzed, but it does appear to contain references to the FW version, anyway, and could be the recovery mode image container (what's loaded if a FW update fails/aborts etc.).
3.) Firmware reference to MP3 encoder. Possibly this codec support is already there, but presently not used (would sure be better than WAV for voice and radio recording).
4.) Of my two Clips, one of them reports 1921MB total flash space, and the other 1949MB. Yes, same FW and yes I have reformatted them both. Probably bad NAND blocks.
EDIT - bucko - if you need a guaranteed V2 player - all Sansa Clips are AMS S0C based.
Bagder:
Interesting find bclick! The "m300" name will of course need to be replaced with the one used for your target if you're gonna try this on your own (non-clip) Sansa.
So if you put the file there, all it does is make a new menu appear in the fw? Can you put any file there using that name, or is it in fact using the specific one you put there?
bclick:
Yes, all it does is enable a hidden menu option. Not really much of interest in there to a porting effort, but the existence of hidden folders in the filesystem should be somewhat of interest...
You pose an interesting question...I suspected that the firmware is truly being read in, not just a matter of the filename being checked. To answer that, I changed one byte in one of the copies of the CRCs in the header and tried to update (the same version, different "letter code" in filename), and - it is refused, just like any corrupted FW...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version