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.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.
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:
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.
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 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:
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:
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!):
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).
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?
# 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)
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
# 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.
Welcome and thanks for the kind words from you as well!
Everything looks good here. You’ve successfully installed the firmware. From the ODROID version list:
2019.3.7 v173.01.00.01 v173.01.00.02 1. Fix TRIM command 2. Support ATA command set - 4(ACS-4) Specification .
It looks like your bridge firmware is now returning “Bridge Firmware Version: v173.1.0.2” which is exactly what we want to see! This should fix trim on the adapter and with any luck it will fix UAS support and quirks mode will be able to be turned off theoretically. This update should definitely fix trim support (running sudo fstrim -av should be able to trim the drive now). Depending on your adapter quirks mode may or may not be fixed (it depends, there’s different variations of JMS578 and some of them have been fixed completely and others have had working TRIM support after the flash but still need quirks mode to boot) but you should definitely be able to try taking the quirks line out and try booting.
For your partition trick it should be able to theoretically work but it’s quite tricky in practice. The NTFS partitions should definitely be after the end as these partitions may be seen within Linux possibly as different drive letters (like /dev/sda3,sda4, etc.). There is a *lot* that can go wrong with these type of operations but as long as you have complete backups (that are accessible) there’s nothing that should stop you from doing this. I’d just say the chances of it just working are quite low but if you have proper backups and are willing to fight with it a little bit I think this will likely work as well. If everything is past the end of the partitions that the Pi is looking for it shouldn’t require changes to /etc/fstab or anything like that.
I think you’re pretty much ready to start testing as the firmware upgrade process looks complete. Hopefully that helps!
Shawn Wilsher
2 years 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.
That’s strange, I’ve confirmed your findings as well here. That one has always worked in the past (it’s the old variant) but I was able to find someone else saying it didn’t work (and was even called out personally as jamesachambers.com for it apparently) here on the Raspberry Pi forums. It wasn’t just me saying it though, as the post author noted it’s multiple sources that confirmed this as working (including lots of posts in the comments from users all over the world still there to this day) and I still have a working one for USB booting on the Pi 4. Something is different / has changed.
I do still have one working USB3S2SAT3CB (this is the StarTech Adapter USB 3.0 variant, and not the 3.1 version) in service. At this point I have had it for nearly 3-4 years. The chipset in my adapter does not match the one that the person in the forum post above had and it probably won’t match yours either (the chipset identified by lsusb is basically what determines whether you have issues or not, some chipsets are known to not cooperate with the Pi). I’m almost wondering if they have changed the chipset since I bought mine years ago (as well as the others who have bought it that it worked for) at this point.
The people in the forum post linked above seemed to find some irregularities with the chipset so this seems like a strong possibility. We’ve ran into chipsets silently changing in the middle of product runs before without the manufacturer changing the model # or making any indication it’s different with other adapters and hardware (this is happening in the SSD market a lot too right now).
I think I am going to need to add a warning for this adapter between your report (which led me to discovering this other one). I’m not totally sure what’s going on but I think something has changed. On top of me having some of the 3.0 variants a few years back there’s a ton of commenters documented over the years with that adapter (bought at the same time or 6-12 months after mine) but this year this forum post came up and now this post so it seems like this is no longer a safe choice. Maybe this is why the firmware download is no longer available. There may be multiple chipsets in this same “model” of adapter which looks to be the case from the lsusb dumps people are posting.
One thing you may want to double check is power. Quirks mode tends to lower the power requirements slightly (it disables UAS or USB-attached SCSI which also slightly lowers performance) and this can tend to make drives right on the edge of not having enough power work in quirks mode but not in “normal” boot mode without the assistance of a powered USB hub. Does this happen to be a large SATA HDD or a known power hungry / older SSD? If you have a powered USB hub it may be worth your while to try it on there and see if your results change at all. I mention this because even though we now have a few reports of problems this was a known good adapter for many years but if we’re right that the chipset has been changed then this may not help.
I’m not sure what can be done without a firmware update as the person in the thread I linked to ended up getting a different adapter. Sorry about this, and thanks for letting me know that there’s no firmware update available for it and it’s not working. It seems that only the 3.1 variants like USB312SAT3CB are safe now. I’ll update my lists and get the warning out!
Rich
2 years 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.
Congrats, I was writing another reply before I saw that you got it, congratulations! It’s been a while since I modified the fstab file for one of these but it used to be required way back in the day before native USB booting was introduced for the Pi.
I think this will help people a lot. I appreciate you posting your follow up / solution!
Rich
2 years 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
2 years 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).
That is definitely some strange behavior. Which adapter are you using? It makes sense that the quirks would not impact booting from SD card. The quirks line is looking for the specific ID of your USB adapter and only impacts the USB behavior basically (nothing with the data or partitions, this line would be completely ignored for a SD card). The quirks mode also does apply if you plug in the adapter after booting from the SD card interestingly enough as it is tied to that specific adapter id that you got from the lsusb command.
It sounds adapter (or more specifically the storage adapter’s onboard chipset) related to me. I have not heard of the JSMicro adapter and when I googled for JSMicro with “jsmicro adapter” your post on this site was the #4 result as well! Let’s see which chipset your adapter uses by running the command:
sudo lsusb
and it should give us the type of adapter chipset in that output from lsusb. It could also be power related as I’ve seen before where the Pi will not boot from the drive but can still access all of the files as a secondary drive. In this reduced power mode state it can’t boot from the USB but you can *slowly* browse the files. An easy test to see if you’re in this mode is try transferring some large files back and forth and watch the speed of the drive. If it’s in a low power state you will notice that the directories are sluggish to open and transfer speeds are reduced.
I have a feeling this is going to end up being one of the lower JMicron (JMS) chipsets that have been known to have a lot of problems like this. I was going to ask if you had the ELUTENG adapter which often has behaved like this but I reread your previous post and saw you did mention that it was a JSMicro adapter.
You mentioned that this happened after doing a dd copy of some of the partitions to a backup drive. It’s possible it may have tweaked your partition table somehow. Do you have any spare blank drives we could use as a test to try a clean install of like Raspberry Pi OS or something like that? My reasoning here is we need to narrow down if this is an adapter issue or a partition issue. This would mean a reinstall though if you don’t have any spare drives but if you do happen to have one it would be a great test to narrow things down. Hopefully that helps and let’s see what your output shows for some of those commands and see if we can get it going here!
Rich
2 years 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 the kind words and welcome! The quirks mode definitely explains the score difference. I’m guessing it’s not working without the quirks mode enabled.
I would say it definitely makes sense to try both a firmware upgrade on your Pi (making sure it’s running the latest) as well as your storage adapter. It may be the storage adapter that is the issue (enabling quirks mode is often required for certain adapters). It’s very possible that the others were using an adapter that does not require quirks mode to work but this might be able to be fixed with a firmware update for your adapter if one is available.
One other thing to watch out for is power. I have seen some cases where quirks mode was actually lowering the power requirement but the true fix was using a powered USB hub in some cases.
Hopefully that helps!
J L
2 years 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?
Great question. You absolutely can, and the reason is that you can enable quirks mode to use for storage devices you are just plugging in normally and not booting from.
Some people may have to enable quirks to get certain external portable SSDs/HDDs to work for example (for a lot of the same reasons as these storage adapters, improper firmware support for certain commands, differences in how manufacturers implemented different standards, etc.).
Since it looks by USB device ID it makes no difference if it’s the boot device and putting/leaving the line in there won’t actually do anything unless / until the device is plugged in otherwise it will do nothing.
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:~# lsjms578fwupdater.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.binJMS578_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 lsShows one file –
JMS578_STD-v00.04.01.04_Self Power + ODD.binI 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.binAny 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
Hey Richard,
Welcome and thanks for the kind words from you as well!
Everything looks good here. You’ve successfully installed the firmware. From the ODROID version list:
2019.3.7 v173.01.00.01 v173.01.00.02 1. Fix TRIM command 2. Support ATA command set - 4(ACS-4) Specification.It looks like your bridge firmware is now returning “Bridge Firmware Version: v173.1.0.2” which is exactly what we want to see! This should fix trim on the adapter and with any luck it will fix UAS support and quirks mode will be able to be turned off theoretically. This update should definitely fix trim support (running sudo fstrim -av should be able to trim the drive now). Depending on your adapter quirks mode may or may not be fixed (it depends, there’s different variations of JMS578 and some of them have been fixed completely and others have had working TRIM support after the flash but still need quirks mode to boot) but you should definitely be able to try taking the quirks line out and try booting.
For your partition trick it should be able to theoretically work but it’s quite tricky in practice. The NTFS partitions should definitely be after the end as these partitions may be seen within Linux possibly as different drive letters (like /dev/sda3,sda4, etc.). There is a *lot* that can go wrong with these type of operations but as long as you have complete backups (that are accessible) there’s nothing that should stop you from doing this. I’d just say the chances of it just working are quite low but if you have proper backups and are willing to fight with it a little bit I think this will likely work as well. If everything is past the end of the partitions that the Pi is looking for it shouldn’t require changes to /etc/fstab or anything like that.
I think you’re pretty much ready to start testing as the firmware upgrade process looks complete. Hopefully that helps!
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.
Hey Shawn,
That’s strange, I’ve confirmed your findings as well here. That one has always worked in the past (it’s the old variant) but I was able to find someone else saying it didn’t work (and was even called out personally as jamesachambers.com for it apparently) here on the Raspberry Pi forums. It wasn’t just me saying it though, as the post author noted it’s multiple sources that confirmed this as working (including lots of posts in the comments from users all over the world still there to this day) and I still have a working one for USB booting on the Pi 4. Something is different / has changed.
I do still have one working USB3S2SAT3CB (this is the StarTech Adapter USB 3.0 variant, and not the 3.1 version) in service. At this point I have had it for nearly 3-4 years. The chipset in my adapter does not match the one that the person in the forum post above had and it probably won’t match yours either (the chipset identified by lsusb is basically what determines whether you have issues or not, some chipsets are known to not cooperate with the Pi). I’m almost wondering if they have changed the chipset since I bought mine years ago (as well as the others who have bought it that it worked for) at this point.
The people in the forum post linked above seemed to find some irregularities with the chipset so this seems like a strong possibility. We’ve ran into chipsets silently changing in the middle of product runs before without the manufacturer changing the model # or making any indication it’s different with other adapters and hardware (this is happening in the SSD market a lot too right now).
I think I am going to need to add a warning for this adapter between your report (which led me to discovering this other one). I’m not totally sure what’s going on but I think something has changed. On top of me having some of the 3.0 variants a few years back there’s a ton of commenters documented over the years with that adapter (bought at the same time or 6-12 months after mine) but this year this forum post came up and now this post so it seems like this is no longer a safe choice. Maybe this is why the firmware download is no longer available. There may be multiple chipsets in this same “model” of adapter which looks to be the case from the lsusb dumps people are posting.
One thing you may want to double check is power. Quirks mode tends to lower the power requirements slightly (it disables UAS or USB-attached SCSI which also slightly lowers performance) and this can tend to make drives right on the edge of not having enough power work in quirks mode but not in “normal” boot mode without the assistance of a powered USB hub. Does this happen to be a large SATA HDD or a known power hungry / older SSD? If you have a powered USB hub it may be worth your while to try it on there and see if your results change at all. I mention this because even though we now have a few reports of problems this was a known good adapter for many years but if we’re right that the chipset has been changed then this may not help.
I’m not sure what can be done without a firmware update as the person in the thread I linked to ended up getting a different adapter. Sorry about this, and thanks for letting me know that there’s no firmware update available for it and it’s not working. It seems that only the 3.1 variants like USB312SAT3CB are safe now. I’ll update my lists and get the warning out!
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
Hey Rich,
Congrats, I was writing another reply before I saw that you got it, congratulations! It’s been a while since I modified the fstab file for one of these but it used to be required way back in the day before native USB booting was introduced for the Pi.
I think this will help people a lot. I appreciate you posting your follow up / solution!
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
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
Hey Rich,
That is definitely some strange behavior. Which adapter are you using? It makes sense that the quirks would not impact booting from SD card. The quirks line is looking for the specific ID of your USB adapter and only impacts the USB behavior basically (nothing with the data or partitions, this line would be completely ignored for a SD card). The quirks mode also does apply if you plug in the adapter after booting from the SD card interestingly enough as it is tied to that specific adapter id that you got from the lsusb command.
It sounds adapter (or more specifically the storage adapter’s onboard chipset) related to me. I have not heard of the JSMicro adapter and when I googled for JSMicro with “jsmicro adapter” your post on this site was the #4 result as well! Let’s see which chipset your adapter uses by running the command:
sudo lsusband it should give us the type of adapter chipset in that output from lsusb. It could also be power related as I’ve seen before where the Pi will not boot from the drive but can still access all of the files as a secondary drive. In this reduced power mode state it can’t boot from the USB but you can *slowly* browse the files. An easy test to see if you’re in this mode is try transferring some large files back and forth and watch the speed of the drive. If it’s in a low power state you will notice that the directories are sluggish to open and transfer speeds are reduced.
I have a feeling this is going to end up being one of the lower JMicron (JMS) chipsets that have been known to have a lot of problems like this. I was going to ask if you had the ELUTENG adapter which often has behaved like this but I reread your previous post and saw you did mention that it was a JSMicro adapter.
You mentioned that this happened after doing a dd copy of some of the partitions to a backup drive. It’s possible it may have tweaked your partition table somehow. Do you have any spare blank drives we could use as a test to try a clean install of like Raspberry Pi OS or something like that? My reasoning here is we need to narrow down if this is an adapter issue or a partition issue. This would mean a reinstall though if you don’t have any spare drives but if you do happen to have one it would be a great test to narrow things down. Hopefully that helps and let’s see what your output shows for some of those commands and see if we can get it going here!
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 🙂
Hey Rich,
Thanks for the kind words and welcome! The quirks mode definitely explains the score difference. I’m guessing it’s not working without the quirks mode enabled.
I would say it definitely makes sense to try both a firmware upgrade on your Pi (making sure it’s running the latest) as well as your storage adapter. It may be the storage adapter that is the issue (enabling quirks mode is often required for certain adapters). It’s very possible that the others were using an adapter that does not require quirks mode to work but this might be able to be fixed with a firmware update for your adapter if one is available.
One other thing to watch out for is power. I have seen some cases where quirks mode was actually lowering the power requirement but the true fix was using a powered USB hub in some cases.
Hopefully that helps!
Just to confirm. With the quirk mode you edit the
/boot/firmware/cmdline.txton the SD Card and still boot from the SD card or?Hey J L,
Great question. You absolutely can, and the reason is that you can enable quirks mode to use for storage devices you are just plugging in normally and not booting from.
Some people may have to enable quirks to get certain external portable SSDs/HDDs to work for example (for a lot of the same reasons as these storage adapters, improper firmware support for certain commands, differences in how manufacturers implemented different standards, etc.).
Since it looks by USB device ID it makes no difference if it’s the boot device and putting/leaving the line in there won’t actually do anything unless / until the device is plugged in otherwise it will do nothing.
Hopefully that helps!