Need help reconstruction filesystem

[errorsmith]

Hi

I have a sansa clip zip wich was running on OF when suddenly it started to freeze on the bootscreen and didn't do anything more. It wasn't even recognized by a computer (win & linux). I tried several tips from this forum and several other sources I found with google and somehow I managed to get it recognized by my linux machine[¹]. I found that the internal storage had no partitions on it, so I think the fs was destroyed somehow (no idea how though).

I can repartition it wich i did (vfat/fat32) and reformat it. But naturally it won't turn on anyway. So now I placed the of .bin-file on the root directory, but I think I need to reconstruct the original fs to get it running again. That's where I need some help from you: I have no idea where to put the files and so on. I need to know exactly wich partition layout the of uses and where to put the files. Just placing the .bin-file onto a new partition is not sufficient... :-(

I would be happy if someone would be able to help me with this or point me to a source where I can find the neccessary information.
If there are more steps to do, I would be happy to get this information also.

kind regards,
errorsmith

[¹]I think holding power for at least 2 minutes and than holding power+Vol up +
menukey to turn it on did the trick

[saratoga]

Usually if a Clip shows up with a large unpartitioned, blank storage space that can't be written to it means that the flash memory failed.

How big is the storage space you see?

[errorsmith]

Hi

The storage I see has 3965M according to fdisk:

Code: [Select]

Disk /dev/sdd: 3965 MB, 3965190144 bytes
106 heads, 30 sectors/track, 2435 cylinders, total 7744512 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1   *          62     7744511     3872225    b  W95 FAT32
This looks ok for me, as it is the 4GB model. And by the way: I could partition, format and write to it, so It is not (complete) dead.


This might be useful too: The output of lsusb

Code: [Select]

Bus 002 Device 002: ID 0781:6200 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          0x6200
  bcdDevice            4.02
  iManufacturer           1 SanDisk
  iProduct                2 M200Plus
  iSerial                 3         i 0744703011
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          4 config1: Mass Storage only
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      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     0x02  EP 2 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

with kind regards,
errorsmith

[errorsmith]

Sorry for replying to myself but I got it working again:
I stumbled over an old thread (http://forums.rockbox.org/index.php/topic,29115.msg185581.html#msg185581) wich refers to unsolder a cable inside my device to force it into a special mode. Actually, my device already behaved like it was in this special mode. And, as it couldn't get worse (and I'm confident with linux), I gave the mentioned commands a try:

Code: [Select]

root@phenom2:~# dd if=/home/errorsmith/clip/clpzV010121.bin of=/dev/sdd
30720+0 blocks in
30720+0 blocks out
15728640 Bytes (16 MB) copied, 72,1622 s, 218 kB/s
root@phenom2:~#

After powercycling the device (holding power and menukey again) I was greeted with the sansa-flower wich was a big success for me! After some time I got a message, telling me that the fat is corrupted and I need to connect the device to a computer. I did this happily (using a windows machine for this). Windows told me that I need to format the removable device wich I did. After this last step, I ejected and unplugged my clipzip and it booted just fine :-)

So, what I've learned from this:
- under special circumstances the clipzip goes into the special mode without unsoldering cables and/or shortening pins (might been one of the button combinations I tried. I can document these in this thread if requested)
- the firmware file is an uncompressed plain "diskimage" wich can be dd'ed to the storage (losing any files previously stored on the device)

Open questions for me:
- why/how could the filesystem became so destroyed that only the bootloader was left?
- how can I prevent this from happening again?
- why jumped the clipzip into special mode without shorting the pins?
- bonusquestion: is it likely that installing rockbox on the device prevents this from happening again or should I get a new device for rockbox?

While my initial problem is solved, it would be nice if someone might have an answer for this questions

kind and happy regards,
errorsmith