Clip+ lsusb Recovery Info

[Bilgus]

I have a clip+ 4gb unit it is a different hardware revision than the one in the SansaAMSUnbrick
but it has pins to short in a similar location

flash chip P/N: SDTNPNAHEM-004G

output of lsusb -v

Code: [Select]

Bus 001 Device 036: 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:     0x060a
  (Bus Powered)
  Remote Wakeup Enabled

output of fdisk-l
Disk /dev/sdb: 3965 MB, 3965190144 bytes
122 heads, 62 sectors/track, 1023 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: 0xffffffff
Disk /dev/sdb doesn't contain a valid partition table

and finally output of fdisk -l while NOT in Recovery
Disk /dev/sdb: 3933 MB, 3933732864 bytes
122 heads, 62 sectors/track, 1015 cylinders, total 7683072 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

[Bilgus]

I helped a user recover his nearly broken clipzip
We were still able to boot it to run the recovery firmware and replace the internal firmware

Code: [Select]

<CLIP ZIP RECOVERY PROCESS on RASPI -- Edited for length>

<Bilgus>	get your PI up
<Bilgus>	plug your extra usb stick
<Bilgus>	and NOT the device yet
<Bilgus>	do sudo fdisk -l and sudo lsblk
<Bilgus>	get all the info for whats already on the system
<Bilgus>	I'm guessing on the PI you are running NOOBs and that has some gotchas
<PI_USER>	Yes im running raspbian
<Bilgus>	when you get all that done start the ZIP as normal and do fdisk and lsblk again
<Bilgus>	(after you plug it in)

<PASTED INFO>
~$ lsblk
sda           8:0    1  117G  0 disk
└─sda1        8:1    1 29.3G  0 part /media/pi/NEW VOLUME
sdb           8:16   1  3.7G  0 disk
└─sdb1        8:17   1  3.7G  0 part /media/pi/F634-E483
----------------------------------------------------------
~ $ sudo fdisk -l
Disk /dev/sdb: 3.7 GiB, 3933732864 bytes, 7683072 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
Disklabel type: dos
Disk identifier: 0x6f20736b
----------------------------------------------------------
<PASTED INFO>

<Bilgus>	yeah looks like you have sdb Lets make an Image of the drive on the ClipZip

<Bilgus>	sudo dd if=/dev/sdb of="/media/pi/NEW VOLUME/clip_zip_disk.img"

<PI_USER>	7683072+0 records in 7683072+0 records out 3933732864 bytes (3.9 GB) copied, 634.81 s, 6.2 MB/s

<Bilgus>	awesome no errors

<Bilgus>	now you will disconnect the device run the recovery.sansa file and wait till the init message disappears and plug it in to usb

<Bilgus>	do fdisk -l and lsblk again to see what they are now, sometimes it changes sometimes not
<Bilgus>	you will need to wait till the WaRNING RECOVERY MODE message shows up and a bit after that before fdisk and lsblk will show anything
<PI_USER>	the messege appeared immediately

<PI_USER>	it's sdb again
<Bilgus>	so now lets try dd again

<Bilgus>	dd if=/dev/sdb of="/media/pi/NEW VOLUME/clip_zip_hidden.img" bs=512 count=$((0xf000))

<Bilgus>	yeah linux tends to move it back and forth but not always thats why its dangerous to assume
<PI_USER>	yeah, like the letters in windows

<PI_USER>	ok it's done, error ofc

<Bilgus>	whats the message?
<PI_USER>	pi@raspberrypi:~ $ sudo dd if=/dev/sdb of="/media/pi/NEW VOLUME/clip_zip_hidden.img" bs=512 count=$((0xf000)) 
            dd: error reading ‘/dev/sdb’: Input/output error 3040+0 records in 3040+0 records out 1556480 bytes (1.6 MB) copied, 83.42 s, 18.7 kB/s

<Bilgus>	ok try ..
<Bilgus>	dd if=/dev/sdb of="/media/pi/NEW VOLUME/clip_zip_hidden.img" bs=512 count=$((0xbdf))
<PI_USER>	sdb is gone, the device panic'd

<Bilgus>	Give me a few I'm going to make a new recovery firmware for the clipzip with longer timouts
<Bilgus>	compiling now i'll upload itwhen done
<Bilgus>	https://www.mediafire.com/folder/pyydmx9m5zi1d/Recovery_Images
<Bilgus>	its in the clipzip folder
<Bilgus>	ok same thing again 
<Bilgus>	let me know when you get to..
<Bilgus>	dd if=/dev/sdX of="/media/pi/NEW VOLUME/clip_zip_hidden.img" bs=512 count=$((0xf000))
<Bilgus>	don't forget sudo
<Bilgus>	once thats done type sudo chmod 666 "/media/pi/NEW VOLUME/clip_zip_hidden.img"

<Bilgus>	you will start the recovery FW wait for init message to disappear plug USb wait for warning message do sudo lsblk
<Bilgus>	figure out drive do dd again replace X with your drives letter
<Bilgus>	see if it completes without error
<Bilgus>	in this firmware I upped all the timeouts and retries are way higher so hopefully its able to complete
<PI_USER>	ok, dd is running
<PI_USER>	pi@raspberrypi:~ $ sudo dd if=/dev/sdb of="/media/pi/NEW VOLUME/clip_zip_hidden.img" bs=512 count=$((0xf000)) 
<PI_USER>	dd: error reading ‘/dev/sdb’: Input/output error 3040+0 records in 3040+0 records out 1556480 bytes (1.6 MB) copied, 83.6416 s, 18.6 kB/s
<Bilgus>	ok lets keep going
<PI_USER>	ok
<Bilgus>	sudo chmod 666 "/media/pi/NEW VOLUME/clip_zip_hidden.img"
<Bilgus>	here we are removing sudo from the file you wrote

<Bilgus>	hexdump "/media/pi/NEW VOLUME/clip_zip_hidden.img" -C -n 5000 > "/media/pi/NEW VOLUME/clip_zip_hidden.txt"
<Bilgus>	paste the contents
<PI_USER>	the zip panicked
<PI_USER>	white screen
<Bilgus>	nbd just disconnect it and long press power to turn it off
<Bilgus>	we'll come back to it

<Bilgus>	ok do the whole clipzip thing again this time we will tell dd to ignore errors
<PI_USER>	ok
<Bilgus>	<Bilgus> dd if=/dev/sdX of="/media/pi/NEW VOLUME/clip_zip_hidden.img" bs=512 count=$((0xf000)) conv=noerror
<Bilgus>	sudo chmod 666 "/media/pi/NEW VOLUME/clip_zip_hidden.img"
<PI_USER>	dd is stuck in a loop
<PI_USER>	it tries to do something, gives and error and repeats
<Bilgus>	if its pulling a non existient drive it just pulls random data
<PI_USER>	and the zip panicked
<PI_USER>	3040+0 records in 3040+0 records out 1556480 bytes (1.6 MB) copied, 233.664 s, 6.7 kB/s dd: error reading ‘/dev/sdb’: Input/output error
<PI_USER>	this messege ran in loops

<Bilgus>	try conv=sync,noerror
<Bilgus>    dd if=/dev/sdX of="/media/pi/NEW VOLUME/clip_zip_hidden.img" bs=512 count=$((0xf000)) conv=sync,noerror

<PI_USER>	3040+58400 records in 61440+0 records out 31457280 bytes (31 MB) copied, 103.197 s, 305 kB/s
<Bilgus>	<Bilgus> dd if=/dev/sdb of="/media/pi/NEW VOLUME/clip_zip_hidden.img" bs=512 count=$((0xf000)) iflags=direct
<Bilgus>    Email the dump to me <REMOVED>
<PI_USER>	7z does a good job, 1 mb instead of 32
<PI_USER>	tho it is mostly 0's so it should be easy for it...
<Bilgus>	that probably means lots of 0's

<Bilgus>	I literally just opened the dump file in a hex editor and looked through it
<PI_USER>	but those 0;s represent?
<Bilgus>	the image has 00 where it couldn't read
<Bilgus>	but there are places filled with 00 in the drive anyways
<Bilgus>	so i compared the 00's in your file to the ones in my firmware dump

<Bilgus>	ok so what we will try now is to pull just the parts we need to replace
<Bilgus>	give me a second to build the dd command for you
<Bilgus>	if player isn't already connected go ahead and do that now and get me the sdb sdc etc
<PI_USER>	in normal firmware or recovery
<Bilgus>	in recovery mode
<PI_USER>	its sdb

<Bilgus>	dd if=/dev/sdb of="/media/pi/NEW VOLUME/clip_zip_hidden.img" bs=512 count=$((0xf000)) skip=$((0xAA00))
<Bilgus>	hopefully thats past the point it errors on
<PI_USER>	pi@raspberrypi:~ $ sudo dd if=/dev/sdb of="/media/pi/NEW VOLUME/clip_zip_hidden.img" bs=512 count=$((0xf000)) skip=$((0xAA00)) 
            61440+0 records in 61440+0 records out 31457280 bytes (31 MB) copied, 12.2217 s, 2.6 MB/s
            
<PI_USER>	I dont see errors
<Bilgus>	cool now sudo chmod 666 "/media/pi/NEW VOLUME/clip_zip_hidden.img"
<Bilgus>    and finally hexdump -C -n5000 "/media/pi/NEW VOLUME/clip_zip_hidden.img" > dump.txt
<Bilgus>	I can only skip whole sectors so I need to see where to start so we can copy over our new file
<PI_USER>	done hexdumping

<Bilgus>	and the clipZip didn't panic right?
<PI_USER>	https://pastebin.com/DqSRm1mK

<Bilgus>	download this if you haven't already
<Bilgus>	http://www.mediafire.com/file/yibi1m6s589rq4j/clipzip4GB_RECOVERY_image32.bin
<PI_USER>	ok, to the sd card?

<Bilgus>	now this is the dangerous part
<Bilgus>	no you want it on the pi

<Bilgus>	you can put it on the USB stick if you must
<PI_USER>	and how confident should I be
<Bilgus>	just don't hit the usb cord and disconnect
<Bilgus>	and 95% confident

<Bilgus>	ok so first we need the path to your freshly downloaded .bin file
<PI_USER>	media/pi/NEW VOLUME/clipzip4GB_RECOVERY_image32.bin

<Bilgus>	dd of=/dev/sdb if="/media/pi/NEW VOLUME/clipzip4GB_RECOVERY_image32.bin" bs=512 skip=$((0x74FA)) seek=$((0xAA00))

<Bilgus>	and tell me what it says, notice the of and if switched we are writing back a portion of the bin file to the good area on your device

<PI_USER>	31494+0 records in 31494+0 records out 16124928 bytes (16 MB) copied, 17.0948 s, 943 kB/s

<Bilgus>	dd of=/dev/sdb if="/media/pi/NEW VOLUME/clipzip4GB_RECOVERY_image32.bin" bs=512 count=$((0x800))

<Bilgus>	just get this done so danger is past
<PI_USER>	2048+0 records in 2048+0 records out 1048576 bytes (1.0 MB) copied, 1.00955 s, 1.0 MB/s
<Bilgus>	once that is all done don't disconnect
<PI_USER>	it's just 1 MB?
<Bilgus>	we did the last part then the first part

<Bilgus>	ok next at your leisure Send me a new dump dd if=/dev/sdX of="/media/pi/NEW VOLUME/clip_zip_hidden.img" bs=512 count=$((0xf000)) conv=sync,noerror
<Bilgus>	I just need to check that everything copied right before you disconnect and reboot the player

<Bilgus>	one extra thing lets dump a bit of the drive after the firmware area just to make sure the drive is still intact
<Bilgus>	ok next at your leisure Send me a new dump dd if=/dev/sdb of="/media/pi/NEW VOLUME/clip_zip_drive_cur.img" bs=512 skip=$((0xF000)) count=$((0xf000)) conv=sync,noerror
<Bilgus>	that should be the first 32 mb of the actual drive you see when the player isn't in recovery mode

<PI_USER>	im back and the dd you told me to run is done, the zip panicked
<Bilgus>	ok well no choice then, go ahead and disconnect and long press power

<PI_USER>	loading of firmware file not found
<PI_USER>	plug usb cable, thats the zip talking
<Bilgus>	good sign though, ok plug in the usb cable
<Bilgus>	actually do you have the multiboot fw on your flash card yet?
<Bilgus>	so the .rockbox folder will be in the root of your sdcard
<Bilgus>	its this one http://www.mediafire.com/file/a6ndfooqpdopo2o/MultiBoot_FW_ClipZip_5-22-17_rockbox-full.zip
<Bilgus>	open the zip and copy the .rockbox folder to the root of the sdcard
<Bilgus>	when done copying make a file on the sdcard root called rockbox_main.clipzip open it and put a single / in it save and close
<Bilgus>	ok try restarting the player only a single '/' in the rockbox_main file right?
<PI_USER>	the one on sd card? yeah
<Bilgus>	ok try restarting it
<PI_USER>	ok, starts normally


<Bilgus>	go to debug menu
<PI_USER>	debug menu?
<Bilgus>	it worked but lets double check

<Bilgus>	system>debug>boot info
<PI_USER>	oh, ok boot data you mean

<Bilgus>	just the fact you see that yes we booted from the sdcard
<Bilgus>	as long as it says root <1> and crc: ok! its all good
<PI_USER>	oh good!
<PI_USER>	root <0>
<Bilgus>	hmm might be because it didn't find the internal drive

<Bilgus>	ok you want to redo the internal drive now?
<Bilgus>	go ahead and shut down the player
<PI_USER>	hahhaha it really doesnt show the internal storage in file manager
<Bilgus>	eject the sdcard, reconnect after you turn it on
<Bilgus>	plug in the clipzip to usb like normal
<Bilgus>	and then do sudo lsblk
<PI_USER>	its sdb again
<Bilgus>	lets finish fixing the internal drive
<Bilgus>	ok so now type mkfs.msdos -F 32 /dev/sdb
<PI_USER>	mkfs.fat 3.0.27 (2014-11-12) mkfs.msdos: Device partition expected, not making filesystem on entire device '/dev/sdb' (use -I to override)
<Bilgus>	I'm guessing we wiped out a bit of the internal drive table which not a huge deal but we will reformat it now to fix it
<Bilgus>	ok so now type mkfs.msdos -F 32 /dev/sdb1
<PI_USER>	no such file or dir
<Bilgus>	being that its not setup with a partition we might have to force it with -I
<Bilgus>	ok so now type mkfs.msdos -I -F 32 /dev/sdb
<PI_USER>	done, no messege, like a good linux program
<Bilgus>	ok power off player
<Bilgus>	insert sd card
<Bilgus>	power on and in file browser should have the internal drive
<PI_USER>	looks like microsd0
<Bilgus>	should have 0 and 1
<PI_USER>	yeah have 0 which is empty and 1 which is sd
<Bilgus>	the sansas consider the internal drive and the sdcard to be sd cards
<Bilgus>	ok 0 is your internal drive now for words of warning
<Bilgus>	open sdcard1
<Bilgus>	long press and choose start here in the list

<Bilgus>	now some warnings
<Bilgus>	yes because its running from there but it will essentially hide the internal
<Bilgus>	any file you copy to that internal drive rather than the sdcard is one step closer to a bricked device
<Bilgus>	maybe not the next file maybe not the 100th but one of them will be the last file you ever copy to it
<Bilgus>	you can boot into the OF now but it really hits that drive hard so try not to
<PI_USER>	why, what does it do
<Bilgus>	it does a lot of reads and writes
<PI_USER>	its not like im recording data..
<Bilgus>	the OF has a database of all files on the device thats why it always wants to refresh the darn thing
<Bilgus>	each time it refreshes that database it reads every file and writes their names to another file
<PI_USER>	is there a way to make rockbox not look at internal storage when making it's own databases?
<Bilgus>	rockbox doesn't do that, and yes there is but no reason to
<Bilgus>	booting from sd card makes it so rockbox doesn't use the internal drive
<Bilgus>	rb only builds the database on demand and when stuff changes it just writes the differences to a new file

<PI_USER>	so can I update now normally? with util or by hand?
<Bilgus>	no you will need a sd card capable firmware to upgrade
<Bilgus>	so yes you can upgrade by hand but it needs to be a special firmware

<PI_USER>	and is there a way to easily compile such firmware on demand?
<Bilgus>	Yes you can compile your own with the proper patches
<Bilgus>	http://forums.rockbox.org/index.php/topic,51844.0.html
<Bilgus>	I wrote up the instructions here
<Bilgus>	its not easy but Its step by step
<PI_USER>	is there an easy way to make it automatic? like with bash or something
<Bilgus>	johnb I think did that you might ask him for his script