Fixing Storage Adapters for Raspberry Pi via Firmware Updates

StarTech USB312SAT3CB
StarTech USB312SAT3CB*

I’ve covered how to get the right type of storage adapter for your Raspberry Pi for years on this site and cataloged storage adapters that both work and don’t work with the Raspberry Pi. Over the years we’ve learned that many of these adapters can be “fixed” with a firmware update to work with the Raspberry Pi.

In this article I’ll put together an evolving list of firmware adapters that can be fixed with these updates from my own experience as well as comments people have left over the years!

Overview

The preferred and safest way to identify your device is by brand name. This will work if you have a “popular” or “name brand” storage adapter.

If you have a generic / unbranded adapter then the next best way is by chipset. We can identify your chipset by using the following command:

sudo lsusb

This yields the following result:

pi@pi:~ $ lsusb
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 04d9:0007 Holtek Semiconductor, Inc.
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Yours will look similar to mine. I’ve bolded the important line which is our storage adapter. The above result is for the StarTech 2.5″ SATA to USB 3.1 (USB312SAT3CB) adapter. This example is a name brand adapter that will be on the list but if it wasn’t the generic chipset would be the ASMedia ASM1153E chipset for this adapter. Other common chipsets include JMS-578, etc.

If you’re confused about which is which use this version of the command to get a lot more detail (including device properties that often make it much easier to identify):

sudo lsusb -v

This will yield something like this:

Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
 Device Descriptor:
   bLength                18
   bDescriptorType         1
   bcdUSB               3.10
   bDeviceClass            0
   bDeviceSubClass         0
   bDeviceProtocol         0
   bMaxPacketSize0         9
   idVendor           0x174c ASMedia Technology Inc.
   idProduct          0x55aa Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
   bcdDevice            1.00
   iManufacturer           2 asmedia
   iProduct                3 ASMT1051
   iSerial                 1 123456799FA6
   bNumConfigurations      1
   Configuration Descriptor:
     bLength                 9
     bDescriptorType         2
     wTotalLength       0x0079
     bNumInterfaces          1
     bConfigurationValue     1
     iConfiguration          0
     bmAttributes         0xc0
       Self Powered
     MaxPower                0mA
     Interface Descriptor:
       bLength                 9
       bDescriptorType         4
       bInterfaceNumber        0
       bAlternateSetting       0
       bNumEndpoints           2
       bInterfaceClass         8 Mass Storage
       bInterfaceSubClass      6 SCSI
       bInterfaceProtocol     80 Bulk-Only
       iInterface              0

The above example didn’t give us the name “StarTech” anywhere but it did give us some clues. This is identified as a “Mass Storage” interface class device which definitely narrows things down. Your other peripherals will show as the category they are from like mouse, keyboard, etc. You should be able to narrow things down by unplugging everything else from your Pi if you are still having trouble identifying which is which.

Many of these updates need to be applied using a Windows machine as that will be the only platform these updates will be offered on from their web site. Some manufacturers have update utilities for multiple platforms available but from what I’ve found if you’re lucky enough they offer them at all it will usually be for Windows.

Warning / Disclaimer

This is not an entirely risk free procedure. If something goes wrong during a firmware update it is possible to brick it. This doesn’t happen very often but understand it’s possible. If you lose power at the moment you are updating the firmware for example that could definitely do it.

There is less risk for the “branded” adapters as these are the manufacturer’s tools intended for the manufacturer’s devices. It’s as safe as it gets but even in these cases things can go wrong (like the examples I mentioned above). There is also some risk that even chipsets identifying as the same chip may have slight variations in how they are actually implemented or which revision they are.

Make sure you understand this is not a completely risk free procedure (and carries the same risk as firmware updates on any other device, and a little bit extra risk even for the generics since they may not have been intended for that exact device) before proceeding!

StarTech Adapters

StarTech 2.5″ SATA to USB 3.1 Adapter

StarTech 2.5" SATA to USB 3.0/3.1 Adapter
StarTech 2.5″ SATA to USB 3.1 Adapter

The USB 3.1 variant of the StarTech 2.5″ SATA adapter works well with the Pi 4. The USB 3.0 variant doesn’t have firmware updates available and is not recommended.

Links: Amazon.com*, Amazon.ca*, Amazon.com.au*, Amazon.co.jp*, Amazon.co.uk*, Amazon.de*, Amazon.es*, Amazon.fr*, Amazon.it*, Amazon.nl*, Amazon.pl*, Amazon.se*, Amazon.sg*

There are a few different variants. Check the tag on your cable to see which exact model you have.

usb312sat3cb – USB 3.1 Gen2 Version

usb31csat3cb – USB 3.1 Gen1 Version

usb3s2sat3cb – USB 3.0 Version – No updates available

Click the “downloads” tab and choose “firmware.zip”. This must be ran on a Windows machine. It will update the firmware almost instantly when you launch the program with the adapter plugged in and say “SUCCESS – UNPLUG AND REPLUG THE DEVICE”.

Sabrent Adapters

Sabrent and Orico both have the worst track records for working storage adapters for the Pi. I don’t recommend them at all but they can sometimes be fixed.

The following Sabrent JMicron adapters can be updated with their official tool:

Important Note: After the update the Sabrent adapters often work but usually only with quirks mode enabled (see bottom Quirks section of article).

For Sabrent’s version of the JMicron firmware update tool: Sabrent JMicron Update Tool

EC-SNVE*

PSiler has reported that you can fix UAS support on the EC-SNVE* with a firmware update available at: Sabrent EC-SNVE Download Page

For the general Sabrent adapters firmware update list (check if your adapter is listed): Sabrent Firmware Update Download Page

Generic Adapters

Note with generic adapters there is some risk. These may not necessarily be by the same manufacturer of your device. It usually doesn’t matter as these all have the same storage controller but due to slight variations in the way some manufacturers implement this technology it’s possible it could cause an issue / brick it. Make sure you understand that there is some risk before proceeding!

JMicron JMS578 Firmware

This is a copy of the JMS578 firmware that has fixed this issue for many people (but not everyone) on the Raspberry Pi. You may still need to enable “quirks mode” (see quirks mode section) even with the updated firmware in some cases.

It’s a little bit trickier to use than some of the other ones but not too extraordinarily difficult. You will need the updater utility and the .bin file.

Here is the updater utility: ODroid – jms578fwupdater.tgz

Here is the JMS578 firmware update: ODroid – jms578_fw_update

And finally the how to use the updater utility / instructions here: ODroid Wiki – How to use jms578_fw_update

This thread is worth a read as well to see the different types of adapters/chipsets people tried with this and their different results: Raspberry Pi Forums – Topic 245931

Watch Out For Power Issues

If you are using a drive that has high power demands a common solution I’ve been recommending for years is to use a Sabrent powered USB hub to power the drive. This eliminates your Pi from having to use it’s own power to power the drive at all. This is often required for higher performance NVMe drives.

Sabrent Powered USB Hub
Sabrent Powered USB 3.0 Hub

The Sabrent powered USB hub delivers a whopping 2.5A of dedicated power for your USB attached devices. This is almost as much as the Pi adapter itself is rated for (3.0A). It will easily power the most thirsty of setups such as NVMe enclosures.

Links: Amazon.com*, Amazon.ca*, Amazon.com.au*, Amazon.co.uk*, Amazon.es*, Amazon.it*, Amazon.nl*, Amazon.pl*, Amazon.se*

Note: Make sure Amazon doesn’t try to take you to the non-powered version and that it’s the one with the AC adapter that plugs in to provide extra power

Verify Drive Performance

You can make sure everything is running correctly (and as fast as it should be) by running my quick storage benchmark. You can run the benchmark with the following one-liner:

sudo curl https://raw.githubusercontent.com/TheRemote/PiBenchmarks/master/Storage.sh | sudo bash

This will give you a score you can compare to the other Raspberry Pi Storage Benchmark results and make sure that you are getting an equivalent speed to your peers with the same device!

Benchmarking / Testing Storage

If you want to verify your drive’s performance you may want to run my storage benchmark with:

sudo curl https://raw.githubusercontent.com/TheRemote/PiBenchmarks/master/Storage.sh | sudo bash

If you search for the model of your drive on Pi Benchmarks you can compare your score with others and make sure the drive is performing correctly!

Fix (some) USB Adapter Problems Using Quirks

Some adapters can be made to work by using USB quirks to disable UAS mode on the drive. This lowers performance, but it’s still much faster than a SD card and your adapter won’t go to waste. Some adapters also require it even with the updated firmware!

To find out the quirks we need to find the device ID string for your adapter and then add an entry to cmdline.txt telling the kernel to apply them on boot.

Find Your Adapter

To apply the quirks we first need to get the adapter id. We will use the sudo lsusb command:

$ sudo lsusb
 Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

On line 2 we can see my ASM1051E SATA 6Gb/s bridge adapter (it’s the known working StarTech.com 2.5″ SATA to USB 3.0* adapter). You will see something very similar to mine when you run the command and it shouldn’t be too hard to figure out which device it is. If you need more information add a -v switch to make the command sudo lsusb -v. This can sometimes add some additional details to make it easier to figure out which one is your adapter.

If you’re still not sure, we have another command that between the two that can narrow things down. Type / paste the following:

sudo dmesg | grep usb

 [0.828535] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 4.19
 [0.828568] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
 [0.828597] usb usb3: Product: DWC OTG Controller
 [0.828620] usb usb3: Manufacturer: Linux 4.19.75-v7l+ dwc_otg_hcd
 [0.828644] usb usb3: SerialNumber: fe980000.usb
 [0.830051] usbcore: registered new interface driver uas
 [0.830182] usbcore: registered new interface driver usb-storage
 [0.836488] usbcore: registered new interface driver usbhid
 [0.836511] usbhid: USB HID core driver
 [0.971598] usb 1-1: new high-speed USB device number 2 using xhci_hcd
 [1.154217] usb 1-1: New USB device found, idVendor=2109, idProduct=3431, bcdDevice= 4.20
 [1.154254] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
 [1.154281] usb 1-1: Product: USB2.0 Hub
 [1.301989] usb 2-1: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
 [1.332965] usb 2-1: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
 [1.332999] usb 2-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
 [1.333026] usb 2-1: Product: ASM105x
 [1.333048] usb 2-1: Manufacturer: ASMT
 [1.333071] usb 2-1: SerialNumber: 123456789B79F

This is the dmesg log showing the hardware detection as hardware is activated on the Pi. If your log is really long you can generate fresh entries by just unplugging a device and plugging it back in and running the command again. Here we can clearly see that the ASM105x is what our StarTech adapter is being detected as.

Now we can go back to our first lsusb command and we want the 8 characters from the ID field that comes right after the Device:

Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge

Our adapter’s ID is: 174c:55aa

Applying Quirks

To apply the quirks to our USB adapter we are going to edit /boot/cmdline.txt. Type:

sudo nano /boot/cmdline.txt

We are going to add the following entry into the very front of cmdline.txt:

usb-storage.quirks=XXXX:XXXX:u

In place of the X’s above you will put in your adapter’s ID that we got before. With the example commands I gave above mine would look like this: usb-storage.quirks=174c:55aa:u. After this my cmdline.txt looks like this (everything should be one continuous line, no line breaks!):

usb-storage.quirks=174c:55aa:u console=serial0,115200 console=tty1 root=PARTUUID=d34db33f-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

Now reboot the Pi. If the Pi fails to boot you can plug the SD card into the computer and go to /boot/cmdline.txt and undo the change we did so you can boot back in with your SD card.

Verifying Quirks

Once you have rebooted after changing cmdline.txt we can verify the quirks have been applied by doing another dmesg | grep usb command:

sudo dmesg | grep usb
 [1.332924] usb 2-1: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
 [1.332957] usb 2-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
 [1.332983] usb 2-1: Product: ASM105x
 [1.333006] usb 2-1: Manufacturer: ASMT
 [1.333028] usb 2-1: SerialNumber: 123456789B79F
 [1.335967] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
 [1.336071] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
 [1.336103] usb-storage 2-1:1.0: USB Mass Storage device detected
 [1.336479] usb-storage 2-1:1.0: Quirks match for vid 174c pid 55aa: c00000
 [1.336611] scsi host0: usb-storage 2-1:1.0

This time we can see in dmesg that UAS was blacklisted for the device and it has loaded with the usb-storage driver instead. This driver tends to be more compatible with the “problematic adapters” but the performance is usually significantly lower. It’s definitely worth a try though as some adapters do better with the quirks performance-wise. The only way to know for sure is to run a benchmark (see “Verify Drive Performance” section).

Other Resources

For the CM4 (Compute Module 4) check out Raspberry Pi Compute Module 4 and using real PCI-Express/NVMe on the Pi

To find out where to get the 64 bit Raspberry Pi OS beta check out my Where to get 64 bit Raspberry Pi OS article here

If you are looking for storage adapters or the best SSDs to use for Raspberry Pi my Best Storage Adapters / SSDs for the Pi 4 / 400 guide should be able to be of some assistance

guest

63 Comments
Inline Feedbacks
View all comments

Richard Hornby
Richard Hornby
1 year ago

Hi James and thanks for the kind words 😉

Back to the question of updating the FirmWare for the SSD. I hope this is intelligible, I swap between listing what appears on the console and comments, I have tried to indicate comments with #.

The instructions on the Odroid website are probably clear for those with more knowledge than I, but in view of the potential for bricking the device I have ‘translated’ them below. Could I ask you to review and correct if necessary?

With many thanks

R

From the instructions on ODROID here

root@odroid:~# ls
jms578fwupdater.tgz

# implies that I have downloaded the updater to my Pi (to downloads folder) then copied or moved it to the home folder. On my pi that is astroberry@astroberry:~

# Then 'ls' lists the files in that location. The downloader .tgz file is in that location

root@odroid:~# tar xzf jms578fwupdater.tgz

# this unpacks the /tgz file to the same (home) directory.

root@odroid:~# ls -l

# this lists the files now present in the home directory after unpacking.

total 308
drwxr-xr-x 2 root root 4096 Nov 1 05:34 jms578fwupdater
-rw-r--r-- 1 root root 309402 Nov 1 05:35 jms578fwupdater.tgz

# This shows there is a new folder - ~/jms578fwupdater. In my installation the folder has a slightly different name with extra capital letters

root@odroid:~# cd JMS578FwUpdater

# This changes location to the new folder. In entering the name of the new folder the correct capitalisation must be used.

root@odroid:~/JMS578FwUpdater# ls -l

# This lists the files in the new folder.

total 4700
-rwxr-xr-x 1 root root 4130828 Apr 19 2018 JMS578FwUpdate
-rwxr-xr-x 1 root root 519032 Nov 1 2017 JMS578FwUpdate.v1.00
-rwxr-xr-x 1 root root 50688 Mar 7 09:33 JMS578-Hardkenel-Release-v173.01.00.02-20190306.bin
-rw-r--r-- 1 root root 50688 Dec 5 2017 JMS578_Hardkernel_v173.01.00.01.bin
-rwxr-xr-x 1 root root 50688 Nov 1 2017 JMS578-v0.1.0.5.bin
root@odroid:~/jms578fwupdater#

# Here lies my real question. Listed here is a different driver from that which is recommended. The driver(s) listed is (are)

JMS578-Hardkenel-Release-v173.01.00.02-20190306.bin
JMS578_Hardkernel_v173.01.00.01.bin

Though only the first is executable.

The recommended driver is v00.04.01.04. The download is provided on the odroid site at as a .zip package. Installing ZIP on the Pi (sudo apt-get install zip) allowed me to unzip the file to ~/Downloads. I then unpacked it to the Downloads directory.

astroberry@astroberry:~/Downloads ls

Shows one file – JMS578_STD-v00.04.01.04_Self Power + ODD.bin

I assume the single quotes are because the file name contains spaces.

Returning now to the instructions on the odroid website: for a simple update these are:

root@odroid:~# ./JMS578FwUpdate -d /dev/sda -f ./JMS578-Hardkenel-Release-v173.01.00.02-20190306.bin -b ./backup.bin

# Pausing there: this instructs the shell to use the updater to execute the v173.01.00.02 file (ie the executable one) and to write something to backup. But I don't get whether that backs up the existing driver, or the new one. I assume the old one (whatever that is). The script returns:

Update Firmware file name: ./JMS578-Hardkenel-Release-v173.01.00.02-20190306.bin
Backup Firmware file name: ./backup.bin
Backup the ROM code sucessfully.
Programming & Compare Success!!
root@odroid:~#

# In order for this to work with the new release, I am assuming that I have to copy the v04.01.00.04.bin file to the astroberry@astroberry:~ folder - ie the same location where I unpacked the updater.

Is it also correct that I could leave the existing .bin files (the v173 files) where they are and the updater will ignore them? Or should I delete them before running the script?

Then to run the updater with the v04 file I would execute

astroberry@astroberry/~:# ./JMS578FwUpdate -d /dev/sda -f ./'JMS578_STD-v00.04.01.04_Self Power + ODD.bin' -b ./backup.bin

Any comments? Is it enough to use /dev/sda or should I use /dev/sda1 (for boot?) or sda2 (for root?).

# Then finally to check the updated driver, the instructions say:

root@odroid:~# ./JMS578FwUpdate -d /dev/sda -v

# returns
Bridge Firmware Version: v173.1.0.2
root@odroid:~#

# Assuming I use the correct /dev/sda identifier this should return Bridge Firmware version including the string "-v00.04.01.04".

When I have updated the firmware, how would I see if it is still necessary to use quirks? Is it as simple as applying the firmware upgrade, the deleting the quirks entry in /boot/cmdline.txt and benchmarking?

I do have another question related to backing up the SSD before doing all this. I have deliberately kept the SSD boot and root partitions to no more than 32Gb. The rest is NTFS as I want to be able to plug the SSD into a Windows machine for fast transfer of files for later processing. Should it be a simple matter to use dd fi /dev/sda1 [and sda2] fo /dev/[USBID] to copy the boot and root partitions to a USB, and is it correct to assume (for the moment) that I could dd the partitions back again from the USB to a newly formatted SSD if it all goes horribly wrong? If necessary I can do the dd on my linux laptop and not the Pi.

Many thanks for your patience with a noobie.

Best R

Shawn Wilsher
Shawn Wilsher
1 year ago

I’ve got a USB3S2SAT3CB that unfortunately doesn’t work well unless it is in quirks mode. Sadly, they no longer have firmware to download on the link provided on this page.

Rich
Rich
1 year ago

Well I’ve sorted it – with a hack. Rather than work out what PARTUUID should be referenced where, I looked at /etc/fstab on the SSD and altered all references to /rootfs to point to the same PARTUUID as /etc/fstab. That is, in BOTH /boot/cmdline.txt AND /etc/fstab on BOTH the SD AND the SSD.

Then I altered the PARTUUID of the SSD again, but this time to suit the file entries.

Reverse engineering like this got me booting back to the SSD again. Now I have a different problem which is a 100% full root partition, but I can find solutions for that.

Not sure if this will have helped anyone, and I would be interested in knowing whether it is possible to boot from the /boot partition of the SSD rather than the SD, on the Pi 4B.

Best
R

Rich
Rich
1 year ago

Since writing the previous, I have done some research and found that /etc/fstab could be referring to the wrong PARTUUID. I altered it on the SD card so that /root pointed to the SSD UUID, but the Pi would not boot to the SSD. I am now wondering whether there is some connection between device UUID and PARTUUID such that my changes to UUID are not recognised. All my reading suggests this is not the case.

Still stumped .. Booting PI from SD alone works, with /root directed to the SD PARTUUID. Changing root to the SSD PARTUUID does not work.

Tks R

Rich
Rich
1 year ago

Thanks James will give it a go .. however I’ve been hit by another problem which is stumping me. I had a working installation with my 4B and SSD adapter until I tried dd’ing the first two partitions to a spare USB as backup. Since then chaos.

Shortly stated I can no longer boot TO (not from) SSD. I think that I used to be able to boot FROM SSD, thought I’m aware that with the Pi 4B that should not be possible. When I say boot TO SSD I mean that when the SSD is connected, my Pi will not boot at all, but when it is not, it will (obviously, only to the SD). Whatever, this is where I am:

ON SD

/boot/cmdline.txt shows the correct PARTUUID for my SSD, with three partitions: boot, filesystem, and data. I have tried inserting quirks for the adapter into this file, but it makes no difference.

On my old (working) installation, the quirks were present not in this file but on the SSD itself (in /media/astroberry/boot/cmdline.txt). This installation worked, and the quirk entry is still there.

I have tried enabling boot from USB in raspi-config, but this returns a ‘No-EEPROM’ message (as expected!).

ON SSD

/media/astroberry/boot/cmdline.txt contains the quirks and directs to the correct UUID for the filesystem root.

When I insert the SSD after booting from SD the filesystem seems intact and I can access all the files from File Manager. Also the boot and data partitions, so the quirk on the SSD seems to be working. As I said, there is currently no quirk entry in cmdline.txt in /boot on the SD, and inserting it seems to make no difference.

I have re-read the guidance carefully but cannot spot my error. I do have a question for clarification resulting from my experiences: in your instructions for applying quirks you do not say which version of /boot/cmdline.txt should be amended – as I say I found to my surprise that the version which worked was that on the SSD itself – but you have probably spotted the gotcha – how did it get there if the SSD could not be accessed? And why amend the SSD /boot/cmdline.txt if the system is actually booting from the SD (remember, this is a Pi 4B)?

Happy to post any logs/error messages required. BTW I didn’t get as far as writing any changes to /etc/fstab yet, but my previous point leads me to ask – to which version? That on the SD or that on the SSD (if I get there).

Yours in hope .. R

Rich
Rich
1 year ago

Hello James

I have a JSMicro adapter on my Pi 4B for which I have had to enable quirks following the excellent guidance on this site.

My benchmark with the Transcend MSA drive is 5288 and others are getting 6.5 – 8k (!).

Does it make sense to try a firmware upgrade, and is it possible to remove quirks if that works? And how would you test?

Thanks for this great resource 🙂

J L
J L
1 year ago

Just to confirm. With the quirk mode you edit the /boot/firmware/cmdline.txt on the SD Card and still boot from the SD card or?

1 2 3