Third Party > Repairing and Upgrading Rockbox Capable Players
Need help reconstruction filesystem
(1/1)
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: ---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
--- End code ---
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: ---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
--- End code ---
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: ---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:~#
--- End code ---
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
Navigation
[0] Message Index
Go to full version