SanDisk Sansa m200 series (v1)

[skaos]

That's the one I call "v2", and it uses AS3525.

Wouldn't it be better to call it m200-v4 to avoid any confusion?

I have downloaded firmware 1.3.0, 2.2.5, 4.0.44 and 4.1.08 (from http://files.zefie.com/PMP/sansa/m200/firmware/) and I would guess that there are four hardware versions as well. To my untrained eye 1.3.0 and 2.2.5 looks similar and from the RB wiki they probably use Telechips. The two latter firmware includes an "AS3525" string. I haven't found any 3.x.x firmware.

[GodEater]

That's the one I call "v2", and it uses AS3525.

Wouldn't it be better to call it m200-v4 to avoid any confusion?

Bagder is referring to the hardware version - not the firmware it's running.

[skaos]

I know - there are most likely four hardware revisions/versions of this player as discussed at abi:
http://www.anythingbutipod.com/forum/showthread.php?t=8031
http://www.anythingbutipod.com/forum/showpost.php?p=39607&postcount=2

Silkscreen markings also show v3 and v4.1 versions and I see no reason why Sandisk should use this if there weren't v1 and v2 as well:
v4.1: http://www.rockbox.org/twiki/pub/Main/SansaM200Port/m240back.jpg
v3.0: http://medlem.spray.se/trancentral/sansa1.jpg, http://medlem.spray.se/trancentral/sansa2.jpg

It seems likely that the major firmware version for many (most/all?) Sansa players are linked to hardware revisions/versions.

Anyway, this is pretty academic as long as there is no AS3525 port yet (and I guess that the developers would start with the e200-v2).

[alsaf]

Apologies in advance if I'm getting above myself here.

Would I be right in saying that arm-elf can still be used with the AS3525?

[Bagder]

Would I be right in saying that arm-elf can still be used with the AS3525?

yes

[alsaf]

Don't know if this is any use.

I used the following command on linux CLI,

dd if=/dev/sdb of=temp

Where /dev/sdb is the M240.

I ran hexedit on the output file temp. Did a search for various text strings. I found the following text

1493D0E0   6D 70 33 5F  64 65 63 6F  64 65 72 00  4A 61 6E 20  mp3_decoder.Jan
1493D0F0   32 36 20 32  30 30 37 00  31 34 3A 31  37 3A 32 38  26 2007.14:17:28
1493D100   00 63 72 5F  35 5F 30 5F  64 65 76 65  6C 6F 70 00  .cr_5_0_develop
....
...
...
149633C0   63 3A 5C 00  6D 6D 63 3A  5C 00 6D 32  30 30 70 46  c:\.mmc:\.m200pF
149633D0   69 65 6C 64  55 47 00 4D  32 30 30 50  2E 42 49 4E  ieldUG.M200P.BIN
149633E0   00 6D 32 30  30 70 53 65  6C 66 45 72  61 73 65 00  .m200pSelfErase.
149633F0   23 45 58 54  4D 33 55 00  23 45 58 54  49 4E 46 3A  #EXTM3U.#EXTINF:
14963400   00 FF FF FF  FF 6D 6D 63  3A 5C 4D 54  41 42 4C 45  .....mmc:\MTABLE
14963410   2E 53 59 53  00 00 04 08  0C 42 6C 75  65 73 00 43  .SYS...
...
...
...
149636D0   35 5F 30 5F  64 65 76 65  6C 6F 70 00  00 00 00 00  5_0_develop.....
149636E0   00 23 00 20  00 2F 00 20  00 00 00 6D  6D 63 3A 5C  .#. ./. ...mmc:\
149636F0   52 45 53 5F  49 4E 46 4F  2E 53 59 53  00 00 00 00  RES_INFO.SYS...
...
...
...
148FAE20   41 53 33 35  32 35 5F 32  5F 30 00 63  72 5F 35 5F  AS3525_2_0.cr_5_
148FAE30   30 5F 64 65  76 65 6C 6F  70 00 30 30  30 32 30 30  0_develop.000200
148FAE40   32 31 30 31  30 33 30 35  30 30 30 35  30 30 00 00  21010305000500..


From the last one, the string is exactly the same as the one in the link that Badger posted  http://daniel.haxx.se/blog/2007/11/25/has-sandisk-gone-ams/

That suggests to me that the firmware is stored on the disk?

[LambdaCalculus]

Yes, this looks quite useful.

Can you do two more commands on your m240?

Run fdisk -l, then lsusb -v, and make sure to pipe the outputs to a text file. Append it here when you're done.

[alsaf]

This is in MSC mode. Fdisk -l is not very useful

Disk /dev/sdb: 1016 MB, 1016856576 bytes
32 heads, 61 sectors/track, 1017 cylinders
Units = cylinders of 1952 * 512 = 999424 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System

This is the m240 info from lsusb - v

Bus 003 Device 006: ID 0781:7431 SanDisk Corp.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x0781 SanDisk Corp.
  idProduct          0x7431
  bcdDevice            4.0e
  iManufacturer           1 SanDisk
  iProduct                2 SanDisk Sansa m240
  iSerial                 3 D910FC0A2027B4980000000000000000
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          4 config1: Mass Storage only
    bmAttributes         0xc0
      Self Powered
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk (Zip)
      iInterface              5 ms ifac 1 (SCSI::BULK_ONLY)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0001
  Self Powered

 


This is a snippet from  kern.log when the m240 gets plugged into laptop

Nov 26 18:43:59 laptop kernel: [ 1951.236000] usb 3-1: USB disconnect, address 4
Nov 26 18:51:56 laptop kernel: [ 2428.240000] usb 3-1: new high speed USB device using ehci_hcd and address 5
Nov 26 18:51:56 laptop kernel: [ 2428.380000] usb 3-1: configuration #1 chosen from 1 choice
Nov 26 18:51:56 laptop kernel: [ 2428.384000] scsi3 : SCSI emulation for USB Mass Storage devices
Nov 26 18:51:56 laptop kernel: [ 2428.384000] usb-storage: device found at 5
Nov 26 18:51:56 laptop kernel: [ 2428.384000] usb-storage: waiting for device to settle before scanning
Nov 26 18:52:01 laptop kernel: [ 2433.384000] usb-storage: device scan complete
Nov 26 18:52:01 laptop kernel: [ 2433.384000] scsi 3:0:0:0: Direct-Access     SanDisk  Sansa m240       v4.1 PQ: 0 ANSI: 0
Nov 26 18:52:01 laptop kernel: [ 2433.388000] sd 3:0:0:0: [sdb] 1986048 512-byte hardware sectors (1017 MB)
Nov 26 18:52:01 laptop kernel: [ 2433.388000] sd 3:0:0:0: [sdb] Write Protect is off
Nov 26 18:52:01 laptop kernel: [ 2433.388000] sd 3:0:0:0: [sdb] Mode Sense: 04 00 00 00
Nov 26 18:52:01 laptop kernel: [ 2433.388000] sd 3:0:0:0: [sdb] Assuming drive cache: write through
Nov 26 18:52:01 laptop kernel: [ 2433.396000] sd 3:0:0:0: [sdb] 1986048 512-byte hardware sectors (1017 MB)
Nov 26 18:52:01 laptop kernel: [ 2433.396000] sd 3:0:0:0: [sdb] Write Protect is off
Nov 26 18:52:01 laptop kernel: [ 2433.396000] sd 3:0:0:0: [sdb] Mode Sense: 04 00 00 00
Nov 26 18:52:01 laptop kernel: [ 2433.396000] sd 3:0:0:0: [sdb] Assuming drive cache: write through
Nov 26 18:52:01 laptop kernel: [ 2433.396000]  sdb:
Nov 26 18:52:01 laptop kernel: [ 2433.400000] sd 3:0:0:0: [sdb] Attached SCSI removable disk
Nov 26 18:52:01 laptop kernel: [ 2433.400000] sd 3:0:0:0: Attached scsi generic sg2 type 0

[alsaf]

I think the MBR is MSWIN4.1 link: http://mirror.href.com/thestarman/asm/mbr/MSWIN41.htm

I came to this conclusion from the start of dump:

00000000   E9 00 00 4D  53 57 49 4E  34 2E 31 00  02 40 01 00  02 00 02 00  ...MSWIN4.1..@......
00000014   00 F8 7A 00  3F 00 FF 00  00 00 00 00  00 4E 1E 00  00 00 29 67  ..z.?........N....)g
00000028   45 23 01 4E  4F 20 4E 41  4D 45 20 20  20 20 46 41  54 31 36 20  E#.NO NAME    FAT16

Also found this later on in dump

14908E10   40 00 00 00  4D 53 57 49  4E 34 2E 31  00 00 00 00  @...MSWIN4.1....
14908E20   46 41 54 31  32 20 20 20  00 00 00 00  46 41 54 31  FAT12   ....FAT1
14908E30   36 20 20 20  00 00 00 00  46 41 54 33  32 20 20 20  6   ....FAT32
14908E40   00 00 00 00  6D 6D 63 3A  00 00 00 00  6D 6D 63 3A  ....mmc:....mmc:
14908E50   5C 53 61 6E  73 61 20 6D  32 2E 25 63  30 00 00 00  \Sansa m2.%c0...
14908E60   6D 6D 63 3A  00 00 00 00  2E 20 20 20  20 20 20 20  mmc:.....

It looks like theres definately two partitions on drive but when mounted on linux it only gets dispalyed as a single partition (sdb). Is it possible to mount a hidden FAT partition?

[saratoga]

It looks like theres definately two partitions on drive but when mounted on linux it only gets dispalyed as a single partition (sdb). Is it possible to mount a hidden FAT partition?

On the Sansa E200, you can only do this in recovery mode.  On the 200R, you cannot do it at all without modifying the firmware.  These players have software USB stacks.  Sandisk can expose whatever of the internal memory they like to the UMS driver.

[alsaf]

What I be correct in saying that the porting effort can't go ahead until the partition containing the firmware can be accessed?

Based on imagination rather than experience I can only think of two options to get around this:

1) Use an alternative way of accessing the partition.
2) Finding the firmware in the datadump, amend it then DD it back to m240.

I'll have to check to see if any of the above options are actually possible.

EDIT: Either that or figure a way to get player into recovery mode if that is possible?

[Bagder]

Normally we want a way to get out of a bad firmware install. I'd say that's the primary thing a porter wants.

Once the firmware upgrade file format is figured out and a brave soul wants to try it, how can (s)he get back to the original one afterwards?

[alsaf]

From the looks of the data dump, the partition where music files can be stored and can be accessed is physically the first one on disk. After that it is the partition that contains firmware which can't be accessed.

According to the link on the MSWIN4.1 Boot Record in previous thread, the boot sector starts with 52 52 61 41 and ends with AA55.

As seen from the following extract from the dump, the boot sector is on the second partition.

14904E70   02 F0 FE FD  2A 1C 69 46  07 98 00 F0  6F FF 00 28  ....*.iF....o..(
14904E80   00 D1 E5 62  68 46 02 F0  0B FE 01 20  E4 E7 00 00  ...bhF..... ....
14904E90   55 AA 00 00  52 52 61 41  72 72 41 61  00 00 55 AA  U...RRaArrAa..U.

149084C0   B1 F9 00 28  03 DA 20 1C  FF F7 86 F8  51 E6 20 1C  ...(.. .....Q. .
149084D0   FF F7 82 F8  00 20 4E E6  F0 FF 00 00  88 DF 00 00  ..... N.........
149084E0   F4 0F 00 00  67 45 23 01  55 AA 00 00  FF FF FF 0F  ....gE#.U.......

I'm not sure if the M200 series has a recovery mode. Will have to do a google and post for a few related forums.

Edit:

From the below link it looks like the M200 series does not have a recovery mode. Not exactly from the horses mouth but the explanation is plausible.

http://www.anythingbutipod.com/forum/showthread.php?t=6530&highlight=recovery

[alsaf]

Apologies for repeating what other posters have said (and stating the obvious) but it looks like the next step in this port is to try and update the firmware to expose the second partition. I wouldn't know how to even start doing this, yet.

Is anybody currently working on this port? Although I am only poking about with the player and learning as I go, I want to at least try to do something constructive to get the port moving on rather than repeating something that's already done or is being worked on.

[linuxstb]

I bought a Sansa M260 (v1) a couple of weeks ago - for 20 GBP from here:

http://www.bigpockets.co.uk/product.php?lang=&product=SANDISK044

(they still have some in stock).

It seems to be extremely similar to the Logik DAX player I'm (slowly) in the progress of porting Rockbox to.  It has the same family (tcc77x) of SoC and is using the same LCD controller (SSD1815) to drive a 128x64 mono LCD.

The tcc77x has a USB boot mode, but I couldn't find a way to enter this mode via key combinations whilst booting.  So I used the same trick that worked on my Logik DAX - I removed the NAND module from the motherboard - not being able to find the NAND module causes the tcc77x to default to USB boot mode.

Once I did this, I could use tcctool (the -d c100 option worked) to transfer and run some test code compiled for the Logik DAX - and it worked, including the LCD driver.

The M260's backlight is connected to a different GPIO pin, but a search of an original firmware disassembly and some luck found that - pin 0x40 on GPIOA.

My logik DAX port is still in the very early stages (I have a basic bootloader build working, with a working LCD driver capable of displaying debugging info on the screen), so this is all I can do on the M260 as well.

But as I work on the DAX, I'll be trying to keep the M260 version in sync.