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

[Bagder]

Could the v2s have a separate flash memory area for storing the active firmware that isn't exposed by the USB interface.

It could certainly have that. Either there's a separate NOR flash for the firmware or it is simply stored somewhere on the NAND that isn't made available over usb-storage.

[gletob]

here is the output of fdisk -l for my c250 v2

Code: [Select]

owner@glenn-desktop:~$ fdisk -l /dev/sdf

Disk /dev/sdf: 2044 MB, 2044198912 bytes
63 heads, 62 sectors/track, 1022 cylinders
Units = cylinders of 3906 * 512 = 1999872 bytes
Disk identifier: 0x6f20736b

This doesn't look like a partition table
Probably you selected the wrong device.

   Device Boot      Start         End      Blocks   Id  System
/dev/sdf1   ?      199216      491461   570754815+  72  Unknown
Partition 1 has different physical/logical beginnings (non-Linux?):
     phys=(357, 116, 40) logical=(199215, 34, 11)
Partition 1 has different physical/logical endings:
     phys=(357, 32, 45) logical=(491460, 44, 51)
Partition 1 does not end on cylinder boundary.
/dev/sdf2   ?       43188      538843   968014120   65  Novell Netware 386
Partition 2 has different physical/logical beginnings (non-Linux?):
     phys=(288, 115, 43) logical=(43187, 17, 47)
Partition 2 has different physical/logical endings:
     phys=(367, 114, 50) logical=(538842, 14, 42)
Partition 2 does not end on cylinder boundary.
/dev/sdf3   ?      478721      974376   968014096   79  Unknown
Partition 3 has different physical/logical beginnings (non-Linux?):
     phys=(366, 32, 33) logical=(478720, 18, 30)
Partition 3 has different physical/logical endings:
     phys=(357, 32, 43) logical=(974375, 14, 39)
Partition 3 does not end on cylinder boundary.
/dev/sdf4   ?           1      931190  1818613248    d  Unknown
Partition 4 has different physical/logical beginnings (non-Linux?):
     phys=(372, 97, 50) logical=(0, 0, 1)
Partition 4 has different physical/logical endings:
     phys=(0, 10, 0) logical=(931189, 36, 30)
Partition 4 does not end on cylinder boundary.

Partition table entries are not in disk order

and  lsusb --verbose

[h2gofast]

fdisk -l   for an e280 v2

Code: [Select]

Disk /dev/sdb: 8187 MB, 8187281408 bytes
252 heads, 62 sectors/track, 1023 cylinders
Units = cylinders of 15624 * 512 = 7999488 bytes
Disk identifier: 0x6f20736b

This doesn't look like a partition table
Probably you selected the wrong device.

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   ?       49804      122866   570754815+  72  Unknown
Partition 1 has different physical/logical beginnings (non-Linux?):
     phys=(357, 116, 40) logical=(49803, 223, 11)
Partition 1 has different physical/logical endings:
     phys=(357, 32, 45) logical=(122865, 44, 51)
Partition 1 does not end on cylinder boundary.
/dev/sdb2   ?       10797      134711   968014120   65  Novell Netware 386
Partition 2 has different physical/logical beginnings (non-Linux?):
     phys=(288, 115, 43) logical=(10796, 206, 47)
Partition 2 has different physical/logical endings:
     phys=(367, 114, 50) logical=(134710, 140, 42)
Partition 2 does not end on cylinder boundary.
/dev/sdb3   ?      119681      243594   968014096   79  Unknown
Partition 3 has different physical/logical beginnings (non-Linux?):
     phys=(366, 32, 33) logical=(119680, 18, 30)
Partition 3 has different physical/logical endings:
     phys=(357, 32, 43) logical=(243593, 203, 39)
Partition 3 does not end on cylinder boundary.
/dev/sdb4   ?      184696      184699       27749+   d  Unknown
Partition 4 has different physical/logical beginnings (non-Linux?):
     phys=(372, 97, 50) logical=(184695, 104, 25)
Partition 4 has different physical/logical endings:
     phys=(0, 10, 0) logical=(184698, 243, 33)
Partition 4 does not end on cylinder boundary.

Partition table entries are not in disk order


[hth]

Has anyone tried to scan the disk for the firmware image?

Found no firmware on the mass storage device shown by my Sansa 280v2.

Is anybody certain that the SanDisk MCU (see bottom) is an AS3525? It's labeled different, though it's also CTBGA224, 13mmx13mm with 15x15 balls and with a quick glance i found 2 usb balls of the SanDisk chip at exactly the same location as the AMS SoC.

This is the information i found out so far:
I have found no information on the flash chips, but i suppose they are 2x4G NAND flash mapped to a 8G msc device. I *guess* they reserved at least the first x MB of either one or both flash chips and put the firmware at offset 0 of the first flash (at least it'd be the easiest to implement).

Read/Write spead to device: 4MB/sec.
Best case: Flash chips are class 4 -> 8G= concatenation of flashes
Worst case: Flash chips are class 2 -> capacity by xkB striping

Also found no way to initiate a firmware recovery, yet.

Odd things:

• Files transferred in MSC mode are not seen in MTP mode and vice versa.
  Note: A list of all physical paths, files and basic tag metadata is stored into MTABLE.SYS.
  It appears to contain multiple "packets" of null separated, equal aligned (16-bit aligned, null-filled) data chunks. Text is stored as null terminated, variable length strings (i.e. not padded, so you cannot use offsets to calculate the position of the next record within MTABLE.SYS). Logical file location and filename are stored in UTF8 format, metadata like title, artist, album, genre are stored in either UTF16 or UCS-2.
  
• In MSC Mode mass storage device reported is:
  
  • Windows XP: 8GB drive with full size 1rst primary partition mapped to logical drive; drive is not selectable by diskpart
    
  • Windows XP: there's a second partition 0 bytes large mapped to a 2nd logical drive; it cannot be formated nor read because its too small to store a filesystem on it
    
  • Linux: 8GB drive of the same size with invalid partition table or no partition table, fat32 filesystem on the whole drive (so physically the same)
    

Also tried initiating a recovery mode by overwriting the hole disc with zero (in mind: firmware must be somewhere on the flash).
After a second or so (some of first MB nulled) the display changes from "writing" to "connected", and the process on my pc writing to the sansa hangs.
After disconnecting the e280v2, it fails rereading the media database (remember: vfat is stored on the beginning of physical target). I cannot tell the exact error message i got, but it was something like:
"Unable to read media database. Need at least 90MB space.".

Exactly the time you needed reading the message, the Sansa e280v2 turns off again. After several tries to access or write to the device (with the 90MB needed error followed by auto-turnoff), i managed to format the entire 8G device with fat32. Same message with autoturnoff.
After copying a backup of all files (as shipped) on the newly formated drive again, it worked. I chose format on the e280v2, to be sure nothing is corrupted.

I then tried to find that 90MB message within the firmware, but didn't find it, yet. Four possibilities to figure out:

• some messages stored in UTF16, UCS2 or some exotic encoding like EBCDIC?
• a .bin file may contain subparts of a complete firmware?
• parts of firmware are crypted?
• error sitting in front of device

Does anybody have a datasheet or the exact specs for the flash chip below?
Perhaps somebody got the specs for the Sandisk MCU (i already got the AS3525 datasheet from AMS; i hope finding out some details about the bootloader code on the 1M-ROM and wether a hardware recovery mode is implemented; based on AMS datasheet chances are 1/2 and 1/2)?
--
SanDisk Sansa e280 v2 with:
MCU: SanDisk, 20-99-00112-2, S735-691106, SDC1, TAIWAN = AS3525A?
Memory: 8MB SHDR-DRAM 4Mx16, Samsung K4S641632K-UC75
Flash: 2x4096G Flash , i.e. 2xSanDisk S747118642, SDTNLLBHSM-4096, CP0086818

[saratoga]

I skimmed the firmware file.  Its actually quite readable, sandisk seems to have no problem with people looking at their stuff.

I think the firmware is basically a bunch of 100-200kb+ segments concatenated together.  Each one starts with a header like the one Bagder found that contains a simple checksum and the length of the segment.  You walk the file by reading the segment length from the header and then jumping ahead that many bytes plus however many bytes are needed so that you're 256 byte aligned.  That is sometimes the start of the next header, and sometimes the start of a "DEADBEEF" section followed by the header.  I'm not sure why they do that or how you know to skip over it.  I did this 4 or 5 times and it worked each one, but I didn't have the patience to go all the way through the file.  

Anyway, thats my quick look.  Hopefully its helpful to someone.

[Bagder]

Ah, cool. So perhaps the test (by rondestvedt 2008-01-05) that didn't manage to "upgrade" to a modified firmware altered strings in a section that did't get the checksum properly updated!

[rondestvedt]

My first test was flawed. I thought the checksum was just a simple addition of all chars in the file. After looking at Badger's code for the  checksum and seeing that it was adding 32bit integers instead of 8bit chars like I thought, I tried again, but instead of switching two letters side by side, I switched a group of 4 characters that were 32bit aligned with the beginning of the file. This time it successfully upgraded with the modified firmware, and I was able to see the changes I made. However this was just a simple switch, and the original checksum was not modified. I'm still wondering if the last 32 bits of the file is another checksum, as they differ between the versions 11 and 14.

[Bagder]

Then I guess another test would be to actually test with a changed checksum. And also see if you can change the file in another "section" than the first.

[hth]

UTF16 little endian to be specific, and I don't understand why that would tell if the image is complete or not...

This alone definetly doesn't tell that, sorry.

I was referring to my previous post: When first examining the firmware i didn't find an error message i was looking for and thought that maybe the e200p*.bin didn't contain the entire firmware, which seems to be wrong.

There's still a slight chance left for some hidden bootloader code on the flash.

I'm not sure yet either, but perhaps the firmware is a modification of AMS 's SDK for the AS352xs, which seems to be possibly build upon Segger's embOS, embFile and embWin. It also looks like the firmware contains parts of libjpeg for decoding jpeg files.

Sorry again if somebody got the idea that you can tell wether a complete
firmware image is distributed by a vendor by just looking at the encoding of
strings.

[rondestvedt]

I tried the same method, and it did not work. I did notice in the firmware files some strings that seem to be a diagnostic menu, with references to various kinds of tests, such as a sdram test and other hardware tests. Not sure but this testing mode might be related to a recovery mode, if we could find out how to activate it.

[hth]

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

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