STICKY: USB-MSD boot EEPROM fourth update - 2020-06-15

[HawaiianPi]

So using your udev rules file for my Eluteng adapter. I'm getting good performance and TRIM works with my Samsung 1TB QVO SSD

Glad that's working well for you.

I'm still curious about the performance of your SanDisk 256GB Extreme PRO USB 3.1 flash drive, in terms of speed and UAS/TRIM support. Have you tried making a UDEV rule for that?

My Samsung BAR Plus 64GB USB 3.1 flash drive works pretty well, including TRIM (Raspbian/RPiOS).

Raspberry Pi Diagnostics - version 0.4 (all below are average of 3 runs)
Seq Write 21,749 KB/s
Write IOPS 2,887
Read IOPS 3,252

Not SSD performance, but faster than SD card. For comparison, here's the budget SSD that I'm booting my 4B2 from.

Silicon Power A55 256GB SATA-III SSD (Eluteng USB 3.0 adapter cable)
Seq Write 297,890 KB/s
Write IOPS 19,997
Read IOPS 14,739

Not bad for only $29.99, which is currently $20 less than a 250GB Crucial MX500, and $10 less than a SanDisk Ultra A1 256GB SD card.

I don't have a 250GB Crucial MX500 for comparison, but this is what a 500GB can do.
Seq Write 329,880 KB/s
Write IOPS 20,454
Read IOPS 17,529

And a Samsung 850 EVO (500GB mSATA).
Seq Write 330,989 KB/s
Write IOPS 20,289
Read IOPS 19,243

And a 256GB Samsung NVMe SSD in a USB 3.1 Gen2 10Gbps enclosure (NOT recommended due to high heat and power consumption).
Seq Write 318,672 KB/s
Write IOPS 18,550
Read IOPS 18,224

And while we're on the subject of the Raspberry Pi Diagnostics utility, it would be nice if it displayed Sequential Read as well (just for the sake of completeness), and allowed us to select the drive to be tested (to test something other than the system drive). Although, technically, we're not on that subject, because this is the bootloader thread...

[Wronglebowski]

I feel like I'm missing something but I'm having very little luck getting my Pi up on USB SSDs. I've tried the following adapters.

Sabrent EC-SSHD
Kingwin ADP-07U3
Vantec CB-STU3-2PB

All in use with Iland 120/240GB SSDs

All my Pis are 1/2GB 4B models on the June 15th Firmware.

I've tried flashing the latest 32 Bit release with the replaced .elf and .dat files from the latest firmware. Also I've tried the 64 Bit release from that beta thread.

The Pi will often turn on, take a very long time to reach the "resizing" partition phase and then a much longer time to progress. Sometimes after 20-30 mins I'll hit the "Raspberry Pi OS" splash screen, but the desktop never actually loads. Sometimes it'll just freeze on screens like this.

https://imgur.com/a/UiCG0yw

Even the worst SD cards will get me on the desktop in 5 minutes. Am I doing something wrong?

[paulwratt]

@Wronglebowski

I have read all 4 beta usb-boot threads (1st and 3rd took me 2 days each), and noone has had the issues you mention (explicitly) except to say slowness to boot and 99% were resolved, however that screen shot shows (in my mind) why you have issues, your kernel is booting and the Ext-4 filesystem is failing.

Sabrent EC-SSHD
Kingwin ADP-07U3
Vantec CB-STU3-2PB

re: your 3 different interfaces, it is possible that they are ALL in need of the "quirks", you need to check the chipsets of each (skim thru this thread to find the command other have used).

I would say go to OP and refollow instructions, double and tripple check everything, use command mentioned in this (and previous) threads to verify what your eyes confirm, if you still have issues (esp. the same issue) and you are 110% your ext4 filesystem is A-OK, then you might have "a corner case" which is one of the things a beta should be hoping to expose

post your results here

[jfabernathy]

So using your udev rules file for my Eluteng adapter. I'm getting good performance and TRIM works with my Samsung 1TB QVO SSD

Glad that's working well for you.

I'm still curious about the performance of your SanDisk 256GB Extreme PRO USB 3.1 flash drive, in terms of speed and UAS/TRIM support. Have you tried making a UDEV rule for that?

The SanDisk 256 Extreme Pro USB 3.1 flash drive is fast but when I implemented the UDEV rule it still worked but fstrim failed with an i/o error.

Since it booted quickly and was fast I stopped at that. I've deployed my RPi4 with Eluteng adapter and Samsung QVO SSD as a Mythtv combo backend and frontend, and my other RPi4 is waiting for the RMA's Startech adapter to arrive. I'll start using ASmedia 1153E firmware based adapters and SSDs for all solutions as the total cost is much less than smaller USB 3.1 flash drives, as you pointed out. The SanDisk 256 Extreme Pro drive will go into backup rotation of home computers.

[HawaiianPi]

Sabrent EC-SSHD

I have one of those myself, and it definitely needs quirks to disable UAS. Add this to the beginning of the line in cmdline.txt with a single space delimiter (keeping it all as one single line).

usb-storage.quirks=152d:0578:u,152d:1561:u

$ cat /boot/cmdline.txt
usb-storage.quirks=152d:0578:u,152d:1561:u console=tty1 console=serial0,115200 root=PARTUUID=b79f160c-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

The second quirk (152d:1561:u) is specifically for that Sabrent adapter cable. The 1st one should handle many other common JMicron based adapters or enclosures. Hopefully all of your adapters will work with those. If not, we'll need to see the output of lsusb for them.

Since you are using SSD, be aware that disabling UAS will also disable TRIM, which is important for SSD. So while quirks will get your adapters working, it's not ideal for SSD (fine for HDD). The Eluteng USB 3.0 to SATA-III adapter cable works with UAS and TRIM.

[itsmedoofer]

Hi,

I have a ELUTENG clear USB caddy, ID 2537:1068, no issues with booting from it with any of the beta firmware released so far, it works fine and it is stable..

https://www.amazon.co.uk/ELUTENG-Enclos ... +enclosure

However be aware that it appears to be blacklisted by default and may not be suitable for SSD usage due to the lack of TRIM...

Code: Select all

[    1.236164] usb 2-2: New USB device found, idVendor=2537, idProduct=1068, bcdDevice= 1.00
[    1.238775] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    1.241341] usb 2-2: Product: NS1068
[    1.243883] usb 2-2: Manufacturer: Norelsys
[    1.246441] usb 2-2: SerialNumber: 0123456789ABCDE
[    1.251988] usb 2-2: UAS is blacklisted for this device, using usb-storage instead
[    1.254620] usb 2-2: UAS is blacklisted for this device, using usb-storage instead
[    1.257148] usb-storage 2-2:1.0: USB Mass Storage device detected
[    1.260067] usb-storage 2-2:1.0: Quirks match for vid 2537 pid 1068: 800000

That being said I have been using it since the launch of the Pi4 without issue, is TRIM such a big deal ?

I've just ordered the ELUTENG cable recommended previously so will give that a go, however a caddy solution would be much preferable...

[Wronglebowski]

To clarify, it's just the adapter that matters? Or does the adapter and SSD itself need to have Driver support for TRIM and USAP?

[Araforn]

Hi All.

I've been following this thread avidly and made the decision to update my EEPROM after the stable was released.

After updating I can boot just fine to USB3 using a few sticks I had.
However what Im seeing as strange is that the Kingston M.2 and adaptor only boots when connected to the usb 2.0 ports!.

Of course this negates the benefit of USB booting entirely. Can anyone help me with this or perhaps indicate why it would boot only on USB2.0?.

Kingston M.2:
https://www.amazon.co.uk/Kingston-A400- ... 163b7d9294

M.2 Adaptor:
https://www.amazon.co.uk/gp/product/B07 ... UTF8&psc=1

I really want to BOOT to this M.2 SSD over USB. Any help would be much appreciated.

Thanks in advance guys.

Best Regards,

Paul.

[jfabernathy]

Hi All.

I've been following this thread avidly and made the decision to update my EEPROM after the stable was released.

After updating I can boot just fine to USB3 using a few sticks I had.
However what Im seeing as strange is that the Kingston M.2 and adaptor only boots when connected to the usb 2.0 ports!.

Of course this negates the benefit of USB booting entirely. Can anyone help me with this or perhaps indicate why it would boot only on USB2.0?.

Kingston M.2:
https://www.amazon.co.uk/Kingston-A400- ... 163b7d9294

M.2 Adaptor:
https://www.amazon.co.uk/gp/product/B07 ... UTF8&psc=1

I really want to BOOT to this M.2 SSD over USB. Any help would be much appreciated.

Thanks in advance guys.

Best Regards,

Paul.

I don't know for sure, but it appears that the adapter uses the JMICRON JMS578 chipset. Some of the Jmicron chipsets have been reported as having issue using UAS and must have the Quirks boot statement added as has been referenced in this thread.
EDIT: I think some of the JMS578 chipsets have a firmware update that needs to be applied.

[Araforn]

Hi All.

I've been following this thread avidly and made the decision to update my EEPROM after the stable was released.

After updating I can boot just fine to USB3 using a few sticks I had.
However what Im seeing as strange is that the Kingston M.2 and adaptor only boots when connected to the usb 2.0 ports!.

Of course this negates the benefit of USB booting entirely. Can anyone help me with this or perhaps indicate why it would boot only on USB2.0?.

Kingston M.2:
https://www.amazon.co.uk/Kingston-A400- ... 163b7d9294

M.2 Adaptor:
https://www.amazon.co.uk/gp/product/B07 ... UTF8&psc=1

I really want to BOOT to this M.2 SSD over USB. Any help would be much appreciated.

Thanks in advance guys.

Best Regards,

Paul.

I don't know for sure, but it appears that the adapter uses the JMICRON JMS578 chipset. Some of the Jmicron chipsets have been reported as having issue using UAS and must have the Quirks boot statement added as has been referenced in this thread.
EDIT: I think some of the JMS578 chipsets have a firmware update that needs to be applied.

Thanks a lot for your reply. From what I am reading I'm concerned that using the UAS method will affect my performance also. Can anyone confirm how badly it affects it compared to not having to do it.

Also, I'm. Not sure how I can update the firmware on this chipset. Any ideas?

Thanks guys.

[Greenwellington]

I have an Orico enclosure:
httphs://www.amazon.co.uk/gp/product/B074S2ZT9M/ ... UTF8&psc=1
and KingDian 120GB SSD:
https://www.amazon.co.uk/gp/product/B00 ... UTF8&psc=1
and I am also having difficulties with this.
It tries to boot and then freezes on the "Welcome to Raspberry Pi Desktop" screen
Checked and BOOTORDER =0xf41
Does this sound like enclosure or SSD problem?

[Bookingyo]

anyone else having issues when trying to export the config file?

Code: Select all

sudo rpi-eeprom-config pieeprom.bin > bootconf.txt
bash: bootconf.txt: Permission denied

[HawaiianPi]

However what Im seeing as strange is that the Kingston M.2 and adaptor only boots when connected to the usb 2.0 ports!.

Of course this negates the benefit of USB booting entirely. Can anyone help me with this or perhaps indicate why it would boot only on USB2.0?.

What does lsusb return with that enclosure connected?

That enclosure uses a JMicron USB-SATA bridge chip, and those are somewhat notorious for not properly supporting UAS in Linux. Assuming the output of lsusb indicates a vendor ID of 152d and device ID of 0578, then adding usb-storage.quirks=152d:0578:u to the beginning of the line in /boot/cmdline.txt (with a single space delimiter) should get you up and running from USB 3.0.

In theory, UAS can deliver up to 20% faster performance over USB 3.0, but in real life practical use it's probably less, and might not even be noticeable. However, disabling UAS will also disable TRIM, and that will definitely affect performance with time and use.

I would normally suggest the Eluteng adapter cable, but since you are using an M.2 drive that won't help you. Look for another enclosure with an ASMedia ASM1153E controller, and hope that it doesn't need a firmware update (some do, while others work out of the box, which is preferable, since firmware updates can be hard to find).

It's too bad you didn't get the 2.5" version of that SSD (less expensive, and you could use the Eluteng adapter cable).

[HawaiianPi]

Hi,

I have a ELUTENG clear USB caddy, ID 2537:1068, no issues with booting from it with any of the beta firmware released so far, it works fine and it is stable. However be aware that it appears to be blacklisted by default and may not be suitable for SSD usage due to the lack of TRIM...

That being said I have been using it since the launch of the Pi4 without issue, is TRIM such a big deal ?

I've just ordered the ELUTENG cable recommended previously so will give that a go, however a caddy solution would be much preferable...

That uses the Norelsys 1068X chip, and yes, they are UAS blacklisted in Linux by default.

TRIM is a big deal with SDD (not needed for HDD). Without periodic trimming the SSD will get slower over time with continued use. TRIM also reduces write amplification, which can affect the lifespan of the SSD.

You should be able to find an enclosure (caddy) with an ASMedia controller, but advertised specifications don't always include that information (and it still might need a firmware update).

2.5 inch SSD models are already in a caddy of sorts, since they are really just little circuit boards inside of a 2.5 inch drive compatible case, so adding yet another case outside of that is not really needed.

To clarify, it's just the adapter that matters? Or does the adapter and SSD itself need to have Driver support for TRIM and USAP?

I can't imagine an SSD without TRIM support, so it's normally only the USB-SATA adapter or enclosure you need to worry about.

I have an Orico enclosure: https://www.amazon.co.uk/gp/product/B074S2ZT9M
and KingDian 120GB SSD: https://www.amazon.co.uk/gp/product/B00WVZKZMU
and I am also having difficulties with this.
It tries to boot and then freezes on the "Welcome to Raspberry Pi Desktop" screen
Checked and BOOTORDER =0xf41
Does this sound like enclosure or SSD problem?

Could be either. If that's the same enclosure I have, it also uses the Norelsys bridge chip (see above). I had no trouble booting my SSD in that enclosure, but it has UAS blacklisted in Linux by default, so it doesn't support TRIM (fine for HDD but not good for SSD).

Check the output of lsusb and if the VID:PID is not 2537:1068 post the output here.

[HawaiianPi]

To expand a bit more on my post at the top of page 5 in this thread (viewtopic.php?f=63&t=277413&start=100#p1684547) I ran more tests today, and some of the results were unexpected and interesting.

To refresh your memory, my 64GB Samsung BAR Plus USB 3.1 flash drive scored as follows.

• Seq Write 21,749 KB/s
• Write IOPS 2,887
• Read IOPS 3,252

So how does that compare to booting from an A1 rated card?

SanDisk Ultra A1 32GB micro SD card (in the SD card slot).

• Seq Write 18,272 KB/s
• Write IOPS 904
• Read IOPS 2,386

But what if you USB-boot that in a card reader?

Same SD card in a SanDisk MobileMate USB 3.0 card reader.

• Note: this is SanDisk's recommended reader!
• Seq Write 9,607 KB/s FAIL! <10,000
• Write IOPS 648
• Read IOPS 1,430 FAIL! <1,500

This was a surprising result, because this reader works well for transferring files and writing images, and it's quite fast. I honestly expected this to be the #1 reader, but I ran the test sequence 3 times (total of 9 tests), and the results were consistent. ¯\_(ツ)_/¯

Let's give a few more readers a try...

Same card in a generic USB 3.0 reader (<$5).

• Seq Write 28,600 KB/s
• Write IOPS 751
• Read IOPS 1,911

And again, in yet another reader (Rocketek RT-CR5 dual slot).

• Seq Write 20,244 KB/s
• Write IOPS 848
• Read IOPS 1,953

And just for the heck of it, one more reader (Alxum dual card, dual interface).

• Seq Write 32,679 KB/s <
• Write IOPS 738
• Read IOPS 1,552

Wow, that Alxum reader kicks butt at sequential write!

However, faster random IOPS should make the Samsung BAR Plus a better overall performer (as an OS drive).


Question: How does all of that compare to a budget SSD?

Identical OS configuration on a Silicon Power A55 256GB SATA-III SSD (with Eluteng USB 3.0 adapter cable).

• Seq Write 297,890 KB/s
• Write IOPS 19,997
• Read IOPS 14,739

Answer: It doesn't. The SSD wins easily, and costs less than either a 256GB SanDisk Ultra A1 micro SD card or Samsung BAR Plus flash drive.

[mby]

Here's a nice overview: https://storage.jamesachambers.com

[njheb]

I have an Orico enclosure:
httphs://www.amazon.co.uk/gp/product/B074S2ZT9M/ ... UTF8&psc=1
and KingDian 120GB SSD:
https://www.amazon.co.uk/gp/product/B00 ... UTF8&psc=1
and I am also having difficulties with this.
It tries to boot and then freezes on the "Welcome to Raspberry Pi Desktop" screen
Checked and BOOTORDER =0xf41
Does this sound like enclosure or SSD problem?

If your enclosure is like mine then on the underside of the circuit board it has the revision code "2139U3_R2.0" and from my notes its stock firmware causes lsusb to report
VID:PID=152d:0578 which is for a Jmicron usb/sata bridge chip. It did not support trouble free uas or trim out of the box for me with a crucial BX500 120GB SSD, so I moved on to using a cable mentioned by timg236

This one:
£7.49 - USB 3.0 to SATA Adapter Cable
https://www.amazon.co.uk/USB-SATA-Adapt ... B01N2JIQR7

Sorry I don't know how to find the post_id that the details came from as this is my second ever post.

The original source was "Sticky: USB-MSD boot EEPROM third update - 2020-06-12", third post, page one.

As to a possible way forward if you want to persist with this enclosure. I have seen people talk about replacing the firmware for other adapters/enclosures. I have not tried this and do not know of a source for the firmware one could try. I suspect you would be tied to using windows software to attempt a firmware upgrade if you can find a trustworthy source to download it from. Maybe someone else could help identify a source of firmware and comment on the reasonableness of trying a firmware upgrade.

Another thing to note about Crucial 500BX120GB is that msecli on x86 Linux reports that it does not support adjusting the overprovisioning amount. I'm completely new to SATA and SSD btw so I'm not sure how important increasing the reserved space is to extend the life of a drive; if any one wants to enlighten me and others I'd be pleased to hear.

[CaptainMidnight]

M.2 Adaptor:
https://www.amazon.co.uk/gp/product/B07 ... UTF8&psc=1

I really want to BOOT to this M.2 SSD over USB. Any help would be much appreciated.

The version of M.2 adaptoer enclosure you use can be critical and ensuring it uses a ASMedia ASM1153E controller chip can provided dividends, here's an example of such an adaptor / enclosure along with expected transfer rates: -

CSL M.2 enclosure

CSL M.2 Enclosure.png (199.9 KiB) Viewed 4761 times

The configuration required to update the ASM1153E firmware and enable fstrim and unmap can be found in the forum thread here viewtopic.php?f=63&t=277210

[philrandal]

This one:
£7.49 - USB 3.0 to SATA Adapter Cable
https://www.amazon.co.uk/USB-SATA-Adapt ... B01N2JIQR7

I'll second that Adapter cable. I'm using it with a £42 WD Blue 250GB SSD (https://www.amazon.co.uk/gp/product/B073SB2MXW/).

With the udev rule mentioned earlier (viewtopic.php?p=1683190#p1683190) trim works fine.

Benchmark results from one of my Pi 4s are here: https://storage.jamesachambers.com/benchmark/28124

Cheers,

Phil

[Maniac69]

Hi all,

I'm a newbie in RPI and not really familar with Unix/Linux OS (I'm a MS admin)
I bought me a RPI 4B (8GB) and could install and start it with a 128GB SD card without any problems.
Since SD cards are not constructed to hold thousands or millions of r/w cycles, I decided to try the boot from USB option.
It works well with the (German) instructions under https://www.verdrahtet.info/2020/05/22/ ... -sd-karte/
I could remove the SD and boot from the USB3 attached HDU (WD Passport 1TB)
But in the year of 2020 with the prices and lightning speed of SSD's I decided to try it with a SSD (ADATÂ SD700, 1TB) but my RPI no more booted from the SSD
I tried to re-install all components several times according the instructions on https://www.verdrahtet.info/2020/05/22/ ... -sd-karte/
but as soon as I attached the SSD I only receive the 4 raspberrys followed by a blinking cursor under it. After a couple of minutes it looks like a Linux is starting with lots of error messages telling me, that the dependency of \boot is not correct or missing and many other errors
So I saw, that on github the pieeprom-2020-06-15.bin has the status "stable" meanwhile and I updated the eeprom with the according commands on my RPI:
- Not replaced "critical" by "beta" on /etc/default/rpi-eeprom-update
- modified command to sudo rpi-eeprom-update -d -f /lib/firmware/raspberrypi/bootloader/stable/pieeprom-2020-06-15.bin
All was updated and worked well with the SD card and the HDU, but as soon as I attach the SSD it will no more reboot.
I even cloned the complete HDU to the SSD sector by sector and not in file mode (and the tool told me it was successful), but no chance to get the SSD booting my RPI

Any hints for a newbie to get this running like with the attached HDU ?

[Kendek]

But in the year of 2020 with the prices and lightning speed of SSD's I decided to try it with a SSD (ADATÂ SD700, 1TB) but my RPI no more booted from the SSD

The ADATA SD700 is an external SSD with JMicron JMS578 bridge chip inside. This chip is UAS-compatible, but it's well known that RPi4 is very picky, especially for JMicron. So you just need to disable the UAS, with usb-storage.quirks=aaaa:bbbb:u kernel parameter in the cmdline.txt file.

[paulwratt]

(if you can still find them) anyone interested in trying USB-Boot with a HDD should give an WD Elements a crack:
https://storage.jamesachambers.com/hdd/

(yeah, the top one is mine, better than some SSD - I cant test it because its a backup drive for various OS, not just Pi/Linux)

Paul

[HawaiianPi]

This one:
£7.49 - USB 3.0 to SATA Adapter Cable
https://www.amazon.co.uk/USB-SATA-Adapt ... B01N2JIQR7

I'll second that Adapter cable. I'm using it with a £42 WD Blue 250GB SSD.

That just looks like a more expensive version of the Eluteng adapter cable I've been recommending.

Amazon UK link: £6.99 ELUTENG USB 3.0 to SATA-III Adapter Cable

ASMedia bridge chip, and it works with UAS and TRIM out of the box (no firmware update needed).

UDEV rule for above (to enable TRIM).

Code: Select all

# /etc/udev/rules.d/01-unmap-trim.rules
# ASMedia ASM1153E controller (Eluteng adapters)
ACTION=="add|change", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="55aa", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"

Then enable and start the weekly fstrim.timer service.

Code: Select all

sudo systemctl enable fstrim.timer
sudo systemctl start fstrim.timer

To double-check that the service is running.

Code: Select all

systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
   Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
   Active: active (waiting) since Sun 2020-06-28 18:26:18 PDT; 3min 5s ago
  Trigger: Mon 2020-06-29 00:00:00 PDT; 5h 30min left
     Docs: man:fstrim

Jun 28 18:26:18 RaspberryPi4 systemd[1]: Started Discard unused blocks once a week.

[Mark_F]

Success. Seagate 1TB SSD works fine.
The only trouble I had is doing rsync from one SSD to another when both are connected to USB-3 ports. There's no trouble when going from USB-3 to USB-2. I suspect that it is a power problem however even though I'm using a genuine Raspberry power supply.
https://jandmf.com/index.php/2020/06/29/usb-boot/

[njheb]

I have an Orico enclosure:
httphs://www.amazon.co.uk/gp/product/B074S2ZT9M/ ... UTF8&psc=1
and KingDian 120GB SSD:
https://www.amazon.co.uk/gp/product/B00 ... UTF8&psc=1
and I am also having difficulties with this.
It tries to boot and then freezes on the "Welcome to Raspberry Pi Desktop" screen
Checked and BOOTORDER =0xf41
Does this sound like enclosure or SSD problem?

If your enclosure is like mine then on the underside of the circuit board it has the revision code "2139U3_R2.0" and from my notes its stock firmware causes lsusb to report
VID:PID=152d:0578 which is for a Jmicron usb/sata bridge chip. It did not support trouble free uas or trim out of the box for me with a crucial BX500 120GB SSD, so I moved on to using a cable mentioned by timg236

This one:
£7.49 - USB 3.0 to SATA Adapter Cable
https://www.amazon.co.uk/USB-SATA-Adapt ... B01N2JIQR7

Sorry I don't know how to find the post_id that the details came from as this is my second ever post.

The original source was "Sticky: USB-MSD boot EEPROM third update - 2020-06-12", third post, page one.

As to a possible way forward if you want to persist with this enclosure. I have seen people talk about replacing the firmware for other adapters/enclosures. I have not tried this and do not know of a source for the firmware one could try. I suspect you would be tied to using windows software to attempt a firmware upgrade if you can find a trustworthy source to download it from. Maybe someone else could help identify a source of firmware and comment on the reasonableness of trying a firmware upgrade.

Another thing to note about Crucial 500BX120GB is that msecli on x86 Linux reports that it does not support adjusting the overprovisioning amount. I'm completely new to SATA and SSD btw so I'm not sure how important increasing the reserved space is to extend the life of a drive; if any one wants to enlighten me and others I'd be pleased to hear.

In case this is useful to anyone else and to show I was wrong about being tied to windows software:

After finding a tool to make the firmware upgrade natively [https://wiki.odroid.com/odroid-xu4/soft ... _fw_update] I dug out my enclosure and had a go at a firmware update.

Code: Select all

sudo ./JMS578FwUpdate -d /dev/sda -f ./JMS578-Hardkenel-Release-v173.01.00.02-20190306.bin -b ./v0_2_0_4_backup.bin

Output:
"Update Firmware file name: ./JMS578-Hardkenel-Release-v173.01.00.02-20190306.bin"
"Backup Firmware file name: ./v0_2_0_4_backup.bin"
"Backup the ROM code sucessfully."
"Programming & Compare Success!!"

Post cold boot.

Code: Select all

sudo ./JMS578FwUpdate -d /dev/sda -v

Returns "Bridge Firmware Version: v173.1.0.2"

The tool works perfectly on the pi2b rev1.1 I tested it on, but it has not helped. Reviewing the output from dmesg there is an explanation by means of a warning from the device driver. If I had looked at this first I might never have bothered.

[ 3.840349] usb 1-1.3: New USB device found, idVendor=152d, idProduct=0578, bcdDevice=31.02
[ 3.855779] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3.869996] usb 1-1.3: Product: USB to ATA/ATAPI Bridge
[ 3.882233] usb 1-1.3: Manufacturer: JMicron
[ 3.893259] usb 1-1.3: SerialNumber: 0123456789ABCDEF
[ 3.906138] usb 1-1.3: The driver for the USB controller dwc_otg_hcd does not support scatter-gather which is
[ 3.923135] usb 1-1.3: required by the UAS driver. Please try an other USB controller if you wish to use UAS.
[ 3.940152] usb-storage 1-1.3:1.0: USB Mass Storage device detected
[ 3.955106] usb-storage 1-1.3:1.0: Quirks match for vid 152d pid 0578: 1000000
[ 3.969862] scsi host0: usb-storage 1-1.3:1.0

I suspect that Jmicron bridge enclosures and adapters like this orico one will all fail without usb-storage.quirks=152d:0578:u added to /boot/cmdline.txt, unless the problem happens to stem from a partial implementation of the necessary protocols on the firmware side. I looked into this because I had seen people saying that their adapter could be fixed with a firmware upgrade.

So you can see this is not helping the SSD situation because of the lack of trim, but the ability to upgrade might be useful with a HDD if your stock firmware is buggy. I am by no means recommending this particular firmware but the tool could be handy if you need to upgrade a Jmicron bridge with pid=0578 and have a reliable source for firmware. Use at your own risk.

I have no 2.5" HDD to test with and did not try quirks after the upgrade.

For completeness a partial quote from HawaiianPi shows how to use usb-storage.quirks

usb-storage.quirks=152d:0578:u,152d:1561:u

$ cat /boot/cmdline.txt
usb-storage.quirks=152d:0578:u,152d:1561:u console=tty1 console=serial0,115200 root=PARTUUID=b79f160c-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

The second quirk (152d:1561:u) is specifically for that Sabrent adapter cable. The 1st one should handle many other common JMicron based adapters or enclosures. Hopefully all of your adapters will work with those. If not, we'll need to see the output of lsusb for them.

Since you are using SSD, be aware that disabling UAS will also disable TRIM, which is important for SSD. So while quirks will get your adapters working, it's not ideal for SSD (fine for HDD). The Eluteng USB 3.0 to SATA-III adapter cable works with UAS and TRIM.