Rockbox Technical Forums

Third Party => Repairing and Upgrading Rockbox Capable Players => Topic started by: Bilgus on October 18, 2017, 08:48:35 AM

Title: Clip+ lsusb Recovery Info
Post by: Bilgus on October 18, 2017, 08:48:35 AM
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
Title: Re: Clip+ lsusb Recovery Info
Post by: Bilgus on May 09, 2018, 03:36:35 PM
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