Third Party > Repairing and Upgrading Rockbox Capable Players
Clip+ lsusb Recovery Info
(1/1)
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: ---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
--- End code ---
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: ---<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
--- End code ---
Bilgus:
Note: this was using recovery firmware that the user was still able to boot rockbox to run the recovery fw..
if you aren't able to run files all is not lost yet...
the device needs to be taken apart to short the
NAND on boot to expose the hidden partition
you will need some sort of linux (live cd works)
Navigation
[0] Message Index
Go to full version