SOLVED: SSD Enclosures with Jmicron chips JMS580 and JMS583 don't boot up. RPi4.

[carras]

Hi there:

With the latest EEPROM firmware. I've try critical, stable and beta channels. My SSD enclosure from ORICO using the chip JMS580 from Jmicron doesn't boot up. And I've seen other people with the same issue with enclosure with JMS580.

If we plug the raspi on and after we connect the ssd, then it boots up.

And It was working before, but the latest critical and stable don't work now.

PD: I want to boot up HassOS form the SSD, but the implemented an auto firmware (EEPROM) update that it's always going to prevent me to use an older firmware.

Update: I add JMS578 too, to de list of controllers with the same issue.

TRY THIS SOLUTION:

Solution: with the command "sudo -E rpi-eeprom-config --edit" you edit the EEPROM BOOTLOADER then you the next configuration: USB_MSD_PWR_OFF_TIME=0

[timg236]

I've attached an experimental change which works for me with the Orico and the other awkward devices which I have at home. It won't get released until I can get back in the lab in the new year and ideally look at some of these devices with a scope.

However, feel free to post interop reports here which will give us more (or less) confidence about releasing this.

rpi-eeprom-recovery-nvme.zip

BOOTLOADER_VERSION: Dec 19 2020 4e126d29

Flash the bootloader using the Raspberry Pi Imager "custom image" with the attached zip

The issue seems to be that some USB devices get into a bad state during the chip-reset on Pi 4 1,24 GB . Unplugging them normally resolves this so the bootloader uses the port power control to simulate this. The problem is that to do this it actually has to initialise the XHCI controller which causes some activity. So the generic solution is finding the best sequencing of XHCI reset + power on.

[THX1180]

I've attached an experimental change which works for me with the Orico and the other awkward devices which I have at home. It won't get released until I can get back in the lab in the new year and ideally look at some of these devices with a scope.

However, feel free to post interop reports here which will give us more (or less) confidence about releasing this.

rpi-eeprom-recovery-nvme.zip

BOOTLOADER_VERSION: Dec 19 2020 4e126d29

Flash the bootloader using the Raspberry Pi Imager "custom image" with the attached zip

The issue seems to be that some USB devices get into a bad state during the chip-reset on Pi 4 1,24 GB . Unplugging them normally resolves this so the bootloader uses the port power control to simulate this. The problem is that to do this it actually has to initialise the XHCI controller which causes some activity. So the generic solution is finding the best sequencing of XHCI reset + power on.

Awesome!

I will try this out and i will report back asap!!!!

Update:

The problems occurs less frequently now, so that's really an improvement. it's not resolved but we are getting there...👍

Thanks for all of your hard work!!!!

[vodoc]

pi@raspberrypi:~ $ sudo rpi-eeprom-update
BCM2711 detected
Dedicated VL805 EEPROM detected
BOOTLOADER: up-to-date
CURRENT: Sat 19 Dec 10:06:09 UTC 2020 (1608372369)
 LATEST: Fri 11 Dec 11:15:17 UTC 2020 (1607685317)
 FW DIR: /lib/firmware/raspberrypi/bootloader/beta
VL805: up-to-date
CURRENT: 000138a1
 LATEST: 000138a1
pi@raspberrypi:~ $ sudo rpi-eeprom-config
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0

SSD based on JMS583. boots fine. Thank you very much!

[timg236]

I've attached an experimental change which works for me with the Orico and the other awkward devices which I have at home. It won't get released until I can get back in the lab in the new year and ideally look at some of these devices with a scope. However, feel free to post interop reports here which will give us more (or less) confidence about releasing this. rpi-eeprom-recovery-nvme.zip BOOTLOADER_VERSION: Dec 19 2020 4e126d29 Flash the bootloader using the Raspberry Pi Imager "custom image" with the attached zip The issue seems to be that some USB devices get into a bad state during the chip-reset on Pi 4 1,24 GB . Unplugging them normally resolves this so the bootloader uses the port power control to simulate this. The problem is that to do this it actually has to initialise the XHCI controller which causes some activity. So the generic solution is finding the best sequencing of XHCI reset + power on.

Awesome!

I will try this out and i will report back asap!!!!

Update:

The problems occurs less frequently now, so that's really an improvement. it's not resolved but we are getting there...👍

Thanks for all of your hard work!!!!

Interesting. It’s survived a few hundred reboots for me but there might be some variation between boards and cables. Looks like I’ll need to use the scope after all!

[sanyafifa]

Guys, hello! After the update, it stopped booting from the SSD disk. It starts if you turn off / turn on the SSD while the raspberry is running, the red and green diodes are constantly on.

`vcgencmd bootloader_version Dec 11 2020 11:15:17

lsusb Bus 002 Device 002: ID 152d:1576 JMicron Technology Corp. / JMicron USA Technology Corp.`

`sudo -E rpi-eeprom-config --edit

[all] BOOT_UART=0 WAKE_ON_GPIO=1 POWER_OFF_ON_HALT=0 DHCP_TIMEOUT=45000 DHCP_REQ_TIMEOUT=4000 TFTP_FILE_TIMEOUT=30000 ENABLE_SELF_UPDATE=1 DISABLE_HDMI=0 BOOT_ORDER=0xf41 USB_MSD_PWR_OFF_TIME=0`

[pvnnpavan]

I had same issue with orico and jmicron controller and have to revert back to 3 Sep boot loader.

Is "USB_MSD_PWR_OFF_TIME=0" permanent fix or is this workaround ?

Also I noticed difference with boot loaders which got copied into below folder, why are all entries removed in Dec boot loader and how is this going to affect the booting.

/lib/firmware/raspberrypi/bootloader/stable

-rw-r--r-- 1 root root 98904 Feb 28 2020 vl805-000137ad.bin -rw-r--r-- 1 root root 524288 Apr 23 2020 pieeprom-2020-04-16.bin -rw-r--r-- 1 root root 524288 Jun 17 2020 pieeprom-2020-06-15.bin -rw-r--r-- 1 root root 99224 Jul 20 08:17 vl805-000138a1.bin -rw-r--r-- 1 root root 524288 Jul 20 08:17 pieeprom-2020-07-16.bin -rw-r--r-- 1 root root 524288 Aug 10 10:17 pieeprom-2020-07-31.bin -rw-r--r-- 1 root root 524288 Sep 7 10:35 pieeprom-2020-09-03.bin -rw-r--r-- 1 root root 106392 Dec 15 04:51 recovery.bin -rw-r--r-- 1 root root 524288 Dec 15 04:51 pieeprom-2020-12-11.bin

root@pavanraspi:/lib/firmware/raspberrypi/bootloader/stable# rpi-eeprom-config pieeprom-2020-07-31.bin [all] BOOT_UART=0 WAKE_ON_GPIO=1 POWER_OFF_ON_HALT=0 DHCP_TIMEOUT=45000 DHCP_REQ_TIMEOUT=4000 TFTP_FILE_TIMEOUT=30000 ENABLE_SELF_UPDATE=1 DISABLE_HDMI=0 BOOT_ORDER=0xf41

root@pavanraspi:/lib/firmware/raspberrypi/bootloader/stable# rpi-eeprom-config pieeprom-2020-09-03.bin [all] BOOT_UART=0 WAKE_ON_GPIO=1 POWER_OFF_ON_HALT=0 DHCP_TIMEOUT=45000 DHCP_REQ_TIMEOUT=4000 TFTP_FILE_TIMEOUT=30000 ENABLE_SELF_UPDATE=1 DISABLE_HDMI=0 BOOT_ORDER=0xf41

root@pavanraspi:/lib/firmware/raspberrypi/bootloader/stable# rpi-eeprom-config pieeprom-2020-12-11.bin [all] BOOT_UART=0 WAKE_ON_GPIO=1 POWER_OFF_ON_HALT=0

[3avidity]

I can confirm that my SATA/USB boot stopped working with an update I did yesterday. Enclosure: ORICO TCM2F-C3 NGFF to USB3.1 found at https://www.newegg.com/orico-tcm2f-c3/p/0VN-0003-001G9, using JMS580 controller.

I can also confirm that once I set POWER_OFF_ON_HALT=0, then reboots started working again.

Symptoms: When power is applied to the RPi4 the blue SATA enclosure light comes on bright (normal) and then a split second later goes into a very dim (not normal) output. This indicates to me that the enclosure thinks it's in a "power standby" mode. In this state the Pi cannot use it to boot off of because it's not responding, when the Pi thinks it should.

I have a question: Will future updates to the firmware settings re-set this back to 1000ms?

[llooping]

I confirm the issue also with JMS577/9 Series (But use JMS578 firmware)

I will do the test with USB_MSD_PWR_OFF_TIME=0 to see if ti works well or not

[timg236]

@vodoc @THX1180

There's an updated version of the generic USB power off changes here. I left it running in a loop and survived a few thousand reboots. rpi-eeprom-recovery-nvme-v3.zip

N.B For the current stable/beta releases using a USB3 HUB seems to make the JMicron chip happier. The Realtek and AsMedia devices worked fine with both releases.

@3avidity The rpi-eeprom-update automatic update process preserves the bootloader configuration so you would only need to re-apply the changes if you used the Raspberry Pi Imager to revert to factory settings.

[THX1180]

@vodoc @THX1180

There's an updated version of the generic USB power off changes here. I left it running in a loop and survived a few thousand reboots. rpi-eeprom-recovery-nvme-v3.zip

N.B For the current stable/beta releases using a USB3 HUB seems to make the JMicron chip happier. The Realtek and AsMedia devices worked fine with both releases.

@3avidity The rpi-eeprom-update automatic update process preserves the bootloader configuration so you would only need to re-apply the changes if you used the Raspberry Pi Imager to revert to factory settings.

First of all Happy New Year!!!

Thanks for uploading this! Going to test it out and report back with my experience.

Cheers!

UPDATE:

Sadly nothing has really changed in my case... Here's a couple of vids and some pics of what actually happens (watch them from beginning to end):

https://imgur.com/gallery/LklTZkX

The first vid shows the boot failure in action, the led on the hub blinks faintly for a second an that's that. It actually looks like some kind of connection failure or something, again I can reboot normally but it's very inconsistent and random.

Second vid shows the system booting normally as it should, the led on the hub lights up and connection is there! This only works when I've shut it down for a while, i would say 30 to 40 seconds or so... It's weird.

It's like booting it up too fast after shutting it down blocks the connection (if that makes sense).

Hope the vids are helpful in sorting this out!!!

Cheers!

[timg236]

@THX1180 Does USB_MSD_PWR_OFF_TIME=0 resolve this for you? For some people it does, but not others.

[timg236]

As a heads-up the attached version will be the next official beta release. After some more experiments with known awkward hardware (Geekworm, Microsoft Wireless keyboard, Orico NVME) I went back to something similar to the September release with the minimal changes for slow to init devices (Geekworm)

This issue has become a little confused because there are minor differences between board revisions hubs etc so people are seeing different behaviour. Therefore, once it's released I'll close this and ask people to fork specific bugs, personally I'd rather have one bug per hardware setup and close as duplicate once we are sure than debug two things at once :)

rpi-eeprom-recovery-nvme-v4.zip

[THX1180]

@THX1180 Does USB_MSD_PWR_OFF_TIME=0 resolve this for you? For some people it does, but not others.

Nope it was already set but it doesn't change anything.

Guess I'll have to get by with this for now....

Thanks for all of your hard work!!!

[3avidity]

Interesting ... My Orico NVMe with JMS583 did not have the problem, while the Orico SATA/JMS580 did. I think the brand really won't matter too much, as the complexity of solving this completely depends on the master chip used, and the version of firmware. I have a number of SSD enclosures with varying chips. I'd be happy to spend some time trying them if you think this would help you.

[timg236]

@3avidity The brand is important because manufacturers because in addition to the chipset external power supplies, buttons can change behaviour e.g. I've had some enclosures which require the power button to be pressed after a reboot (USB power toggle) making it unsuitable for use as a boot device.

[3avidity]

@timg236 In general, I agree with you. I was looking at it from the perspective that device(s) that had been working before the December update suddenly stopped working. So unsuitable devices would not have been being used for this purpose prior to the December update. In my software development experience a priority has been "Don't break what has been working." It's embarrassing to explain to customers why something they have come to depend on suddenly is broken. When it comes to "new" features, it is less painful as users have not had time to come to depend on it, and are more forgiving as they understand that sometimes "things just happen."

I was just suggesting I could bring to table results of devices I possess, which you may not have available to you.

[timg236]

@3avidity Interop reports are welcome, I was just asking for enough information that someone could reproduce the entire setup if they wanted.

The "power button" behaviour is an example of a device which has never worked (and never will) because it assumes that USB power will never go away during a reset which is not possible with the Pi 4B hardware. The brand and model was significant because other enclosures using the same chipset behaved correctly.

This 'issue' is addressing support for devices which typically fail by not enumerating or hanging after a reset on R1.0, R1.1 Pi4 B boards (not relevant on 1.4/8GB Pi400). The 5th Dec release is pretty much identical to the Sep release and works with all the known awkward devices including those which failed with Sep release. If you know of an exception please let us know because this is going to be frozen very soon.

After that, if a device enumerates but hangs then generic code to reset endpoints etc might be improved. If it fails to enumerate then it's invisible to software and rather than tweaking generic behaviour, I think the answer will likely involve some EEPROM configurable delay (if it helps) or maybe forced PMIC reset.

[llooping]

Hi, I can confirm the Solution: with the command "sudo -E rpi-eeprom-config --edit" you edit the EEPROM BOOTLOADER then you the next configuration: USB_MSD_PWR_OFF_TIME=0

Works for me with a JMS577/9 with a firmware based on JMS578.

Thank you guys

[timg236]

Has anyone managed to try the Dec 5th release without USB_MSD_PWR_OFF_TIME=0? Just trying to get an idea of on whether the factory-default settings now support the maxmium possible set of devices.

N.B. There is an unrelated failure (perhaps 1 in 1000 reboots) which also occurs with this device on Sep release. USB boot starts but a SCSI read hangs. I'll look at that separately to see whether it can be recovered. From what I've seen and what I can tell from the comments this 'issue' fails virtually every time.

[3avidity]

@timg236 The Dec 5th release, I believe, is what broke my Pi 4 bootup. Applying the '0' setting then allowed it to boot up.

[llooping]

Same here, I updated my PI 2 weeks ago and It was broken and Now the the the line + 0 it works again :)

[timg236]

I released a new beta yesterday (12 Jan) which works with Oricio NVMe with Pi 4b R1.0, R1.1, R1.4 with/without USB_MSD_PWR_OFF_TIME set to zero.

This will be the next stable release unless a major regression is found because the default configuration improves interop over 11th Dec release.

N.B. The default Sep release does actually power off the ports but it looks as though the VLI is a little timing-sensitive which is why the behaviour changed in the Dec stable release. Setting this to zero avoids any USB PWR control which is good for some devices but bad for others.

[sanyafifa]

I released a new beta yesterday (12 Jan)

it worked for me, thanks! Bus 002 Device 002: ID 152d:1576 JMicron Technology Corp. / JMicron USA Technology Corp.

[timg236]

@sanyafifa Thanks for the test. Please could you update your comment to link to the USB device as well of the chipset? It helps others including RPi reproduce the setup in the future.

[etiennebz]

Hello, I have a raspberry 3B+ with the Orico BH100, which as the: Bus 001 Device 005: ID 152d:0567 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge

Until yesterday it worked fine, however after an update it won't boot anymore. I tried what was mentioned above: sudo -E rpi-eeprom-config --edit USB_MSD_PWR_OFF_TIME=0

also in my config.txt I already had and have: program_USB_boot_mode=1

in cmdline.txt I have also tried changing the root=PARTUUID=85f65e63-02 to root=/dev/sda2.

All to no avail.

To be honest I am not sure how to reflash the eeprom back to 09-30 version, if that would help.

The Orico drive now also has issues being recognized on my Mac; diskutil list shows no drive....(yesterday the mac first didn't find it, and then it does; the raspberry pi does see it clearly) Using an SD I have no issues getting into the Rasperry Pi. Is it possible that the EEPROM update somehow messed up the Orico firmware? lsusb and lsblk do show that the Orico SSD is connected though.

[pelwell]

A 3B+ does not have an EEPROM, so editing the EEPROM config will not do anything useful.

[etiennebz]

A 3B+ does not have an EEPROM, so editing the EEPROM config will not do anything useful.

I just figured that out ;-). Thanks for confirming that. I do see rpi-eeprom updates coming by when I do sudo update, a bit confusing ;-)

[pelwell]

That's because rpi-update (and the apt update mechanisms) is intended to maintain the image for all models of Pi, not just the one you are using. The only exception to this is if you are running an old image without Pi 4 support it won't add it - just in case the boot partition isn't large enough.

[bschatzow]

Not sure if this is a good place to post or not. My issue is I use Home Assistant on the rpi-4 4 GB. My system boots off the SSD drive an has no issues with OS 5.2 any updates after this causes my system to freeze in 2 hours to 2 days. No useful information in the logs. CPU use rises, Memory, and everything else is normal. My Controller is a StarTech (USB3S2SAT3CB) and the SSD is a Kingston 120GB A400 SATA 3 2.5" Internal SSD SA400S37. Many comments in https://github.com/home-assistant/operating-system/issues/1119. I am willing to help test. Let me know what addition information is needed and what I should try. Thanks.

[tablatronix]

testing USB_MSD_PWR_OFF_TIME Not sure if this fixes all my ssd issues, but I just rebooted and it booted incredibly fast, I think I was having boot failures before looping. Promising so far.

[timg236]

Not sure if this is a good place to post or not. My issue is I use Home Assistant on the rpi-4 4 GB. My system boots off the SSD drive an has no issues with OS 5.2 any updates after this causes my system to freeze in 2 hours to 2 days. No useful information in the logs. CPU use rises, Memory, and everything else is normal. My Controller is a StarTech (USB3S2SAT3CB) and the SSD is a Kingston 120GB A400 SATA 3 2.5" Internal SSD SA400S37. Many comments in home-assistant/operating-system#1119. I am willing to help test. Let me know what addition information is needed and what I should try. Thanks.

That sounds like a Linux kernel update issue because the Linux kernel doesn't depend upon the bootloader USB stack.

[THX1180]

Hi guys a quick update (workaround) for those who own the Orico BH100 external SSD.

This could potentially work for other models/brands as well. But it kind of defeats the purpose of this thread lol.

Check out the gallery:

http://imgur.com/gallery/plL1F0t

I basically replaced the Jmicron controller with a ASM1153E bridge, it's super easy to do and works flawlessly. Open up the external case by removing the plastic tab on the front/back, slide out the SSD and detach the Jmicron controller. Plug in the ASM (of your choice) controller and slide back into the case.

Mind you it's not secured in the case (need to figure out how to, but it's not necessary to do so).

Jmicron is just not suitable in my opinion.

[timg236]

Hello, I have a raspberry 3B+ with the Orico BH100, which as the: Bus 001 Device 005: ID 152d:0567 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge

Until yesterday it worked fine, however after an update it won't boot anymore. I tried what was mentioned above: sudo -E rpi-eeprom-config --edit USB_MSD_PWR_OFF_TIME=0

also in my config.txt I already had and have: program_USB_boot_mode=1

in cmdline.txt I have also tried changing the root=PARTUUID=85f65e63-02 to root=/dev/sda2.

All to no avail.

To be honest I am not sure how to reflash the eeprom back to 09-30 version, if that would help.

The Orico drive now also has issues being recognized on my Mac; diskutil list shows no drive....(yesterday the mac first didn't find it, and then it does; the raspberry pi does see it clearly) Using an SD I have no issues getting into the Rasperry Pi. Is it possible that the EEPROM update somehow messed up the Orico firmware? lsusb and lsblk do show that the Orico SSD is connected though.

The 3B+ doesn’t have a bootloader in SPI flash. This repo is specific to Pi4

[THX1180]

Hello, I have a raspberry 3B+ with the Orico BH100, which as the: Bus 001 Device 005: ID 152d:0567 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge

Until yesterday it worked fine, however after an update it won't boot anymore. I tried what was mentioned above: sudo -E rpi-eeprom-config --edit USB_MSD_PWR_OFF_TIME=0

also in my config.txt I already had and have: program_USB_boot_mode=1

in cmdline.txt I have also tried changing the root=PARTUUID=85f65e63-02 to root=/dev/sda2.

All to no avail.

To be honest I am not sure how to reflash the eeprom back to 09-30 version, if that would help.

The Orico drive now also has issues being recognized on my Mac; diskutil list shows no drive....(yesterday the mac first didn't find it, and then it does; the raspberry pi does see it clearly) Using an SD I have no issues getting into the Rasperry Pi. Is it possible that the EEPROM update somehow messed up the Orico firmware? lsusb and lsblk do show that the Orico SSD is connected though.

Check out my answer... I have the Pi 4 but could be useful for you.

[timg236]

Try the latest stable release (raspi-config advanced) 2021-01-16 if that doesn’t work raise a new bug. Closing this because the original problem fixed. From now no one bug report per hardware configuration

[bschatzow]

Not sure if this is a good place to post or not. My issue is I use Home Assistant on the rpi-4 4 GB. My system boots off the SSD drive an has no issues with OS 5.2 any updates after this causes my system to freeze in 2 hours to 2 days. No useful information in the logs. CPU use rises, Memory, and everything else is normal. My Controller is a StarTech (USB3S2SAT3CB) and the SSD is a Kingston 120GB A400 SATA 3 2.5" Internal SSD SA400S37. Many comments in home-assistant/operating-system#1119. I am willing to help test. Let me know what addition information is needed and what I should try. Thanks.

That sounds like a Linux kernel update issue because the Linux kernel doesn't depend upon the bootloader USB stack.

Any idea where I can ask for help? Thanks.

[sstefanowski]

Maybe it could be interesting for other users but I have also ORICO BH100 (JMicron 567) and encountered major issues trying to boot a Raspberry PI 3B+ with it. I think this drive may be poorly designed.

1. Is it possible that ORICO BH100 have some power issues? My RPi3B+ was booting from this drive only when connected to the powerfull source - it was not booting from standard RPi Power source giving 2.5A but it was booting successfully when RPi was powered from Huawei charger giving as much as 4.5A(!). It's quite strange anyway as I thought RPi USB power is limited by the board. But this observation was absolutely repeatable issue.
2. Second - I encountered random read failures on this SSD. It was like after some time the random incorrect bytes were read from files on SSD making some services (Home Assistant mostly unusable). The strange thing was after reboot the file previously corrupted was read correctly and after some time the read error appeared in another place. I tried to change USB cable, power source and RPi and it was still the issue.
3. Strange is when Orico BH100 is powered by my Win10 laptop there is no issue, but when I connected this drive to my Networked Media Player (Dune HD - based on Linux) then the movies from this disk were rendered on the TV screen with visual artefacts - I assume it just confirms the byte-read-failure issues on this disk.

Conclusions???? maybe this is a faulty item? Or problems are related to USB on Linux? (as I mentined DuneHD probably has the same issues)? Or power problem with BH100 case (JMicron 567)? No idea.... Any hints?

Final of the story... I replaced Orico BH100 with Kingston A400 120GB + IBox HD-05 (with JMicron 578 inside!) and it works fine. RPi 3B+ boots successfully even on Standard RPi power giving 2.5A. I even managed to enable FSTRIM on this disk but... hmmmm... it required downgrading firmware of the HD-05 case (JMicron 587) to 5.00.08 in my case (the process is to be found on the web)... Edit: Wooow... I just noticed that downgrading JMicron 578 Chipset firmware (in HD-05 case) to 5.00.08 changes productID now its 1337 and recognizes Kingston drive inside(!) It was

Jan 27 22:19:49 raspberrypi kernel: [    4.204532] usb 1-1.3: New USB device found, idVendor=152d, idProduct=0578, bcdDevice= 1.00
Jan 27 22:19:49 raspberrypi kernel: [    4.209876] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 27 22:19:49 raspberrypi kernel: [    4.212784] usb 1-1.3: Product: USB to ATA/ATAPI Bridge
Jan 27 22:19:49 raspberrypi kernel: [    4.215660] usb 1-1.3: Manufacturer: JMicron
Jan 27 22:19:49 raspberrypi kernel: [    4.218487] usb 1-1.3: SerialNumber: 0123456789ABCDEF
Jan 27 22:19:49 raspberrypi kernel: [    4.224602] usb 1-1.3: The driver for the USB controller dwc_otg_hcd does not support scatter-gather which is
Jan 27 22:19:49 raspberrypi kernel: [    4.230218] usb 1-1.3: required by the UAS driver. Please try an other USB controller if you wish to use UAS.
Jan 27 22:19:49 raspberrypi kernel: [    4.235873] usb-storage 1-1.3:1.0: USB Mass Storage device detected
Jan 27 22:19:49 raspberrypi kernel: [    4.239720] usb-storage 1-1.3:1.0: Quirks match for vid 152d pid 0578: 1000000
Jan 27 22:19:49 raspberrypi kernel: [    4.242951] scsi host0: usb-storage 1-1.3:1.0
...
Jan 27 22:19:49 raspberrypi kernel: [    5.276185] scsi 0:0:0:0: Direct-Access     JMicron  Generic          4102 PQ: 0 ANSI: 6

and after changing firmware to 5.00.88 it is....

Jan 27 22:32:42 raspberrypi kernel: [    4.196597] usb 1-1.3: New USB device found, idVendor=152d, idProduct=1337, bcdDevice= 5.08
Jan 27 22:32:42 raspberrypi kernel: [    4.201897] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 27 22:32:42 raspberrypi kernel: [    4.204818] usb 1-1.3: Product: jmicron
Jan 27 22:32:42 raspberrypi kernel: [    4.207644] usb 1-1.3: Manufacturer: jmicron
Jan 27 22:32:42 raspberrypi kernel: [    4.210445] usb 1-1.3: SerialNumber: 7F833EEF5DC0
Jan 27 22:32:42 raspberrypi kernel: [    4.213951] usb 1-1.3: The driver for the USB controller dwc_otg_hcd does not support scatter-gather which is
Jan 27 22:32:42 raspberrypi kernel: [    4.219463] usb 1-1.3: required by the UAS driver. Please try an other USB controller if you wish to use UAS.
Jan 27 22:32:42 raspberrypi kernel: [    4.225026] usb-storage 1-1.3:1.0: USB Mass Storage device detected
Jan 27 22:32:42 raspberrypi kernel: [    4.228671] scsi host0: usb-storage 1-1.3:1.0
...
Jan 27 22:32:42 raspberrypi kernel: [    5.276220] scsi 0:0:0:0: Direct-Access     KINGSTON  SA400S37120G    0508 PQ: 0 ANSI: 6

and FSTRIM works!

Now... I think I will try to replace JMicron in BH100 with ASM1153E as advised by @THX1180.

[stek29]

@sstefanowski what version of VL805 firmware were you using on your latest test?

[pepsonEL]

Hi Anybody can help me please. I have Orico case for mSATA SSD on USB3.0 and i try to boot from it my RPI 4 8GB. no found solution , also try many many FW for JMS578 and nothing. Also try this solution: Solution: with the command "sudo -E rpi-eeprom-config --edit" you edit the EEPROM BOOTLOADER then you the next configuration: USB_MSD_PWR_OFF_TIME=0 but also not help me.... My RPI no boot. I have in my RPI eeprom latest FW from 17.03.2021.... BETA. Please help me

[var1ableX]

SOLVED: I’d been trying to get SSD to boot all day. Believe SABRENT enclosure is the problem. What I tried:

1. Created SSD image on MacOS using RPi Imager (tried lite, and full 32 bit images). Didn’t boot.
2. Tried to copy MicroSD image onto SSD using Copy SD function of RPi GUI. Got Aborting Drives Changed error.

Finally I saw articles suggesting SABRENT was the problem so I switched enclosure to a UGREEN enclosure I was using for another drive. Everything worked.

I did come to realize that an intermittent green led that constantly flashes is not a sign that anything is wrong. I’m guessing it just means Pi is waiting for data. This would be different if it’s flashing 3x 4x 5x etc. But if it’s just flashing constantly then it’s ok.

[tiagoboldt]

This can be solved using by appending the following argument to /boot/cmdline.txt.:

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

Confirm with lsusb if your enclosure has that USB product ID, you might need to adjust the argument to match your enclosure version.

[lurch]

@tiagoboldt Yeah that's mentioned in the documentation here.

[eebssk1]

I know this is quietly old but I still want to notice that JMicron chips do not work very well in many use cases. I just fell into the pit today.You may want to get a enclosure with rtl or asm chips instead.

[tablatronix]

Yeah I gave up and wound up using nvme in a sabrent usb c case

[Zyzonix]

That's actually true, but those issues are only present when using USB 3. Think Raspberry Pi doesn't provide enough power (also with the official PS) to power the external NVMe and the PCIe bride. If you aren't in need for high transferrates just use USB 2, it's a bit slower, but works fine. @tablatronix @eebssk1

[eebssk1]

That's actually true, but those issues are only present when using USB 3. Think Raspberry Pi doesn't provide enough power (also with the official PS) to power the external NVMe and the PCIe bride. If you aren't in need for high transferrates just use USB 2, it's a bit slower, but works fine. @tablatronix @eebssk1

Might be incompatible instructions. Usb3/2 their difference are only max suppliable current. The disks use constant current when R/W. The only difference is USB2 only support BOT as transfer method while USB3 support both BOT and UASP(preferred.) BOT is more compatible as it's the first file transfer protocol born with USB.

[Other information(off topic): It seems that JMS58* is incompatible with USB3.1 HUB that uses genesys logic chip. I returned the JMS580b enclosure and then replaced it with a enclosure with RTL9201R(even cheapier), everything works fine now.]

[tablatronix]

Bus 002 Device 003: ID 0bda:9210 Realtek Semiconductor Corp. RTL9210 M.2 NVME Adapter

 sudo hdparm -Tt /dev/sda2

/dev/sda2:
 Timing cached reads:   2106 MB in  1.99 seconds = 1055.70 MB/sec
 Timing buffered disk reads: 1034 MB in  3.01 seconds = 344.05 MB/sec
 ...
 Timing O_DIRECT disk reads: 996 MB in  3.00 seconds = 331.75 MB/sec

[terrafirma2021]

This can be solved using by appending the following argument to /boot/cmdline.txt.:

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

Confirm with lsusb if your enclosure has that USB product ID, you might need to adjust the argument to match your enclosure version.

Thanks, this is the solution for this controller,