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!


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.


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 “”. 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


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.


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 | 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 | 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 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:


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 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


Inline Feedbacks
View all comments

11 months ago

I am testing several times INTEL 760p 128GB NVMe on AXAGON GTX with Pi4 4GB, Transcend 120GB mSATA in EVOLVEO USB box and old mSATA 64GB from the computer in mSATA 3GB speed USB box. Just to add, that all tests in variants with/without USB powered HUB. For some combination it does not work with USB HUB even just because of USB-C cable. Finally should be the difference for Pi4 new power version (related with Bullseye upgrade info). I am recomend to add some possibility to comment the results some time later – if the configuration works stable or not. For me – only old version of 3GB speed mSATA USB box works perfectly with mSATA disk, now testing Transcend in EVOLVEO looks OK for just short time now.

11 months ago

Hi James,
GTX is my mistake…AXAGON EEM2-GTR is the one I had been testing.
You can see I did a lot of tests 🙂 as I mentioned. I am really flustrating when realised today, that some of them significantly influenced results just because of USB 3 cable used to connect Pi4 with powered USB HUB. The topic is visible between Test #53,476 and Test #53,472. The difference just USBA-C cable. The result is great, but Pi4 stop working after some time even with good cable 🙁 anyway.
Most of the times I tested even Quirks solution, but with no serious difference in stability.
I changed my Raspberry Pi4 for new 4GB version with updated power part, therefore repeated tests if the solution exist.
And last but not least… I realised, that I have better results with powered USB HUB where both Pi4 & USB BOX are connected as “the equipment” in the box, means not used main USB connector… have no idea why. I am still looking for the final configuration where it is no needs for powerd USB HUB. Expect you do not need lsusb for AXAGON GTR :-).

11 months ago

I’ve found the point! As part of the optimization I upgraded my RPi from 2GB to 4GB. And I found out that my original RPi4-2GB has HW version 1.1. Maybe you know that this version 1.1 has a problem with the specification of the power part/USBC connector. That is, if I used the original USB3 cable, there was not enough power supply to work with the SSD.

11 months ago

Thank you very much for posting this! The usb-storage.quirks addition worked well for my Sabrent EC-SSHD sata to usb adapter. Boot times went from ~ 1:30s to 0:18s using a WD 500Gb SATA III drive! Really appreciate your help!

Richard Hornby
Richard Hornby
1 year ago

Hi James

It worked 🙂 🙂 Hopefully this account will enable those who may have watched these posts with amusement / bemusement to take something useful away.


1 To create a backup SD from an SSD which is over 32Gb in size, because it also contains an NTFS data partition.

2 To be able to update / upgrade astroberry without crashing the SSD.


1 Turn this process on its head and create a base SD image which can be updated / amended and then deployed to SSD as required

2 Burn a new astroberry image to SD, apt-get update and upgrade, then install any extra components required (NTFS support is now included automatically). Install gparted.

3 Use gparted to shrink /root partition as required to create ~2Gb unallocated space after /root

4 Install and configure everything required on the SD eg timesync and WiFi

6 COPY THE SD TO USB using SD Card copier. Copier will report it could not mount one partition – ignore.

7 Shut down, remove SD card from pi, check it boots from USB.

8 Assuming all ok, shut down again, then plug in SSD, insert SD Card and copy SD card to SSD via SD card copier.

9 Shutdown again, remove SD card and boot from SSD.

10 The SSD should have /boot, /root and a large unallocated space. Use gparted to format the space as NTFS (or as you wish).


Now you have (i) a working backup SD in case of SSD crash, (ii) a backup / dev USB to update before deploying to SD/SSD, and (iii) a working SSD for day-to-day use.

One of my posts concerned updating the JMS 587 firmware driver. I was able to do this, but the drive seems still to require /boot/cmdline.txt to contain quirks.

Hope this may be of use.


Richard Hornby
Richard Hornby
1 year ago

Ok very useful post! The video essentially shows where I had got to with your help, but somewhere along the line I seem to have lost the PARTUUID references – or possibly the firmware,as I have all the correct references in the correct files 🙁

Is it possible to install the firmware to the SSD directly without booting from it first?

Here’s where I am:

1 Made a fresh astroberry image to SD. This boots. Got the PARTUUID’s with blkid and checked they are referenced in cmdline.txt and fstab. They are, and are different from the PARTUUIDs for the SSD partitions.

Changed the fstab and cmdline on the SSD to point to the SD for /boot and the SSD for root. No boot. Changed them back – ie left them pointing to the SSD PARTUUID.

Tried booting from SSD without SD – fails with a GRUB-type message ‘failed to find target’. I can’t log on with CTL-ALT-F2 so have left this for the moment. I can’t read the error messages.

There seems to be a full image on the SSD rootfs, but I’m not sure.

2 On the new astroberry image, I have updated the FW to latest stable version – I guess this should be OK. As I said, this boots fine.

3 I think my only remaining course of action, unless there is a way of installing the correct firmware to the SSD without booting from it (as above) is to image the new working SD to the SSD, which will remove the data partition, then install gparted, restore the data partition (and NTFS file support, and everything else I had!), and hope all works.

SO going forward … any advice on making backup images of only the boot and root partitions for the future? The video shows how to copy all the partitions on the OP’s installation, but he didn’t have a data-only partition.



Richard Hornby
Richard Hornby
1 year ago

Thanks for the advice! There are reasons to stay with Astroberry, viz most importantly it comes with a built in VNC and INDI server and a bunch of bundled astro programs. I have added my own set of apps for my Pi and the whole set is saved on the SSD. One of the bundled apps is ‘aggressively’ 32bit so I need for the mo to stick with the 32 bit astroberry OS. Until the astroberry upgrade it was basically working.

I will download a fresh astroberry image to SD and see if I can at least use that to boot the SSD, but I am not holding my breath.

On another point .. I have found some sites on the web which advocate copying the SD image to the SSD. When I try to do that with the Pi4B it tells me I can’t as it doesn’t find the eeprom. Is it not the case that the Pi4B will still boot from SD even with the Raspberry-Pi OS? This is what the site also suggests. If that is the case, then (1) aren’t all Pi4B users stuck with a 5 yr old process and (2) I’m not sure that loading the Pi OS will help all my issues, specifically how to take backups of a SSD which also includes a data partition. If there is a way to copy the SD to SSD and boot from that, I may have missed it.

I will take it in steps and get a new astroberry image and let you know what happens. I appreciate the help.

Best R

Richard Hornby
Richard Hornby
1 year ago

Hi James

I really appreciate how much you are helping me and I hope the discussion may be useful to others. I definitely want to get a strategy for being able to do n(1) a full system upgrade and (2) a backup of my SSD. I take your point about a compressed backup may be the way to go, but ATM am still stuck on no boot.

So I have concentrated on trying to sort out /etc/fstab – and /etc/.fstab which I also found.

Something odd seems to be happening. Somehow my PARTUUID for the SD card seems to have changed to match the PARTUUID for the SSD. If I just insert the SD and then the SSD into my Linux lappie and do a blkid on each, I’m getting the same PARTUUID. And /etc/fstab seems to have changed to point to that UUID for both /boot and root. Previous to what I can only consider as a change, the PI did boot, but to the wrong drive. Now it won’t boot at all.

Whatever, I think I may have to change the PARTUUID of the SD card to get anything to happen. I guess I would do that then alter fstab and .fstab accordingly on both SD and SSD, and then try again.

Does this make any sense?



Richard Hornby
Richard Hornby
1 year ago

Thanks James, but you are assuming a bit too much!

I haven’t done the update, because the version 173 of the firmware is not the version which is on the odroid site as latest. That is the version. What I was wondering was whether my proposed method of installing that version – ie by running the same commands as in the odroid instructions, but using the .bin file from the odroid .zip download extracted to the same folder as the updater program – was the right way to do it.

However in the meantime I have managed to mess with the whole thing by doing a full APT upgrade on the astroberry. That has fritzed my root and home directories – though I can still see (but not open) the folders on the SSD partitions – and in the meantime I have to work out how to get back to booting to SSD. I think I am going to have to boot from SD and examine the files on the SSD without mounting the partitions. Then I may be able to see what has happened.

Ref the idea of taking a backup before attempting to dd the boot and root partitions of the SD, that is exactly what I am trying to do! How do I ‘bootstrap’ that process to get a backup before backing up? The ‘SD duplicator’ on the PI will only backup complete devices, and I don’t need or want the SSD data partition. You are correct that the pi sees the SSD partitions as sda1, 2 etc. Here are the relevant terminal outputs: do you see anything wrong here?

astroberry@astroberry:~ $ lsblk

sda 8:0 0 119.2G 0 disk
|-sda1 8:1 0 256M 0 part /media/astroberry/boot1
|-sda2 8:2 0 31.7G 0 part /media/astroberry/rootfs1

-sda3 8:3 0 87.3G 0 part /media/astroberry/PI_SSD_DATA
mmcblk0 179:0 0 29.8G 0 disk
|-mmcblk0p1 179:1 0 256M 0 part /boot
-mmcblk0p2 179:2 0 29.6G 0 part /

astroberry@astroberry:~ $ df -h

Filesystem Size Used Avail Use% Mounted on
/dev/root 30G 6.0G 23G 22% /
devtmpfs 3.8G 0 3.8G 0% /dev
tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs 3.9G 9.5M 3.9G 1% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/mmcblk0p1 253M 55M 198M 22% /boot
tmpfs 783M 4.0K 783M 1% /run/user/1001
/dev/sda3 88G 24G 65G 27% /media/astroberry/PI_SSD_DATA
/dev/sda2 31G 16G 14G 53% /media/astroberry/rootfs1
/dev/sda1 253M 49M 204M 20% /media/astroberry/boot1
astroberry@astroberry:~ $

Tks for your continued advice

Best R