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

[Holland1]

Can confirm there is a similar issue with the JMS583 controller.

[caro7372]

I have exactly the same problem as above described.

[timg236]

Please can you add screenshots showing the failure on the bootloader HDMI diagnostics screen or UART traces.

[lurch]

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.

You could try setting the FREEZE_VERSION option as a workaround to stop that? https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711_bootloader_config.md

[timg236]

Yes FREEZE_VERSION will prevent upgrades except for rescue image and because it's in the EEPROM will work if you swap SD cards.

The most likely explanation is that the controller is fussy about exactly how long USB port power is off for and any delays during initialisation. However, we'd need screenshots / logs to confirm.

N.B. Please can you also confirm that when booted from SD card the enclosure works reliably when mounted under Linux and will hotplug correctly if you connect/disconnect the cable without pressing any special power buttons on the enclosure?

[carras]

@timg236 This is it, but it's not Raspberry Pi OS. I can do it with it if you ask, this is HassOS. Is this ok?

The disk enclosure Is visible when you boot Raspberry Pi OS and remember "If we plug the raspi on and after we connect the ssd, then it boots up."

[carras]

I add JMS578 too, to de list of controllers with the same issue. As being reported by other user.

[carras]

I just contacted Jmicron in case the need something to add, or they can help with the next message:

When try to boot up from USB enclosure on a Raspberry Pi 4 your controllers JMS578, JMS580 and JMS583 are reported to be not working properly.

I've open an issue in the Github page of the EEPROM firmware of the Raspberry Pi 4:
#266

There are many Raspberry Pi 4 users in world that would like to boot up with USB on a SSD and your chips are in many cases like ORICO (which I have two) or Kingspecs. As te result of your controller no working those brands and your brand is losing popularity over Realtech or ASM with apparently work better.

Could you please investigate the issue and help the Raspberry Pi team to work on this problem?

Thanks.

[timg236]

I doubt this is anything to do with the JMicron chip because there are plenty of people on the forums using JMicron USB SATA adapters. Some of the older chips have issues with UAS but that's not relevant until Linux runs.
I think the issue is with the design of the enclosure.

[caro7372]

Please can you add screenshots showing the failure on the bootloader HDMI diagnostics screen or UART traces.

[caro7372]

Yes FREEZE_VERSION will prevent upgrades except for rescue image and because it's in the EEPROM will work if you swap SD cards.

The most likely explanation is that the controller is fussy about exactly how long USB port power is off for and any delays during initialisation. However, we'd need screenshots / logs to confirm.

N.B. Please can you also confirm that when booted from SD card the enclosure works reliably when mounted under Linux and will hotplug correctly if you connect/disconnect the cable without pressing any special power buttons on the enclosure?

Yes, SD card works! And cable SSD out and in again boot works.

[timg236]

Please post links to the SSD enclosure. If it's still for sale and we should be able to get one for some interop testing in the new year. Please also confirm the exact EEPROM version that worked for you. It may be that a configurable timeout quirk could be added to support such devices.

[Holland1]

The one with the JMS583 chip

https://www.amazon.nl/dp/B07QN2WFGB/ref=pe_19967891_404437601_TE_item

[caro7372]

https://www.aliexpress.com/item/4001278381663.html

[vodoc]

Small investigation of my SSD (based on JMS583)
https://aliexpress.ru/item/4000402460407.html
EEPROM versions:
Thu 3 Sep 12:11:43 UTC 2020 (1599135103) - boots ok.
Wed 28 Oct 17:32:40 UTC 2020 (1603906360) - boots only after unplug + plug again
Fri 11 Dec 11:15:17 UTC 2020 (1607685317) - boots only after unplug + plug again

[carras]

I've got this bundle which I think its a really good quality/price:
https://www.aliexpress.com/item/1005001413198976.html?spm=a2g0s.9042311.0.0.27424c4dTdwJ3z

It uses JMS580 and a SATA m.2 SSD.

[carras]

@caro7372 I have this Orico enclosure with the JMS578 but it has the format of 2.5 inches disks. And it works perfectly to boot up with the Raspberry. Can you check with other ssd blade? Nevermind, you can not open your enclosure.
https://www.aliexpress.com/item/4001146259311.html?spm=a2g0s.9042311.0.0.27424c4dc8LdKF
*In that enclosure I put a Samsung 540 SSD.

[timg236]

Has anyone tried increasing the USB port power-off time by setting USB_MSD_PWR_OFF_TIME=5000 in the EEPROM config? This should look identical to a disconnect to the device. The default off-time may be less between 3rd September and subsequent releases.

[caro7372]

I will check and try!
I had to find out how to edit config.txt but I managed it.
So I set USB_MSD_PWR_OFF_TIME=5000 there in the config.txt
Reboot without SD-card so SSD should boot but no succes.

[carras]

Has anyone tried increasing the USB port power-off time by setting USB_MSD_PWR_OFF_TIME=5000 in the EEPROM config? This should look identical to a disconnect to the device. The default off-time may be less between 3rd September and subsequent releases.

Well, this made the trick. I didn't make it 5000 I made it 0. Then it works. I've tried your 5000 suggestion but It didn't work.

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 guess there is a reason for it. How much USB_MSD_PWR_OFF_TIME=1000 is necesary? Is it bad to have it at 0? Why is important to cut the power to the USB for some time before it boots?

From release notes:
"USB ports are now powered off for 1 second at startup regardless of boot mode to resolve issues with some USB devices which failed after a reboot. This can be configured via the existing USB_MSD_PWR_OFF_TIME EEPROM setting."
https://github.com/raspberrypi/rpi-eeprom/releases/tag/v2020.07.31-138a1

The documentation can be found:
https://www.raspberrypi.org/documentation/hardware/raspberrypi/booteeprom.md
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711_bootloader_config.md

[caro7372]

@carras
Where did you set that 0 ms?
In the config.txt ( on the SD-card ) or ???? I'm a bit confused now if I did the right thing.

[carras]

@carras
Where did you set that 0 ms?
In the config.txt ( on the SD-card ) or ???? I'm a bit confused now if I did the right thing.

You get an SD-card with Raspberry Pi OS and boot with it.
Then you execute the command in SSH/terminal: sudo -E rpi-eeprom-config --edit
You are now in one text file and you need to add this at the end of the list: USB_MSD_PWR_OFF_TIME=0

[caro7372]

@carras
Where did you set that 0 ms?
In the config.txt ( on the SD-card ) or ???? I'm a bit confused now if I did the right thing.

You get an SD-card with Raspberry Pi OS and boot with it.
Then you execute the command in SSH/terminal: sudo -E rpi-eeprom-config --edit
You are now in one text file and you need to add this at the end of the list: USB_MSD_PWR_OFF_TIME=0

What I see know is that the 2020-10-28 has no stable release?
2020-12-11 is latest stable.
You see that too?

After applying the USB ...... to 0 you reboot with or without the SD card in ( for the first time ? ).
Sorry for my noob questions but I'm relatively new to Linux.

--> Okay, you nailed it. I was setting it on the wrong place. Once you pointed me in the right direction it is working!!

[timg236]

USB port power is not guaranteed across a reboot, it goes away briefly on 2G, 4G during reset and for much longer on 8G. This is the same as a disconnect and for devices such as spinning hard drive enclosures, it's better to have a long power off than a short one. For an NVMe SSD it should be fine to have USB_MSD_PWR_OFF_TIME=0 because it will power on almost immediately.

So changes to improve compatibility for spinning hard drive enclosures seems to be worse for some JMicron NVME adapters. There might be a common change which is good for both but NVME enclosures have been fairly low down the compatibility list because there's no performance benefit of USB SATA SSD

[timg236]

@carras
Where did you set that 0 ms?
In the config.txt ( on the SD-card ) or ???? I'm a bit confused now if I did the right thing.

You get an SD-card with Raspberry Pi OS and boot with it.
Then you execute the command in SSH/terminal: sudo -E rpi-eeprom-config --edit
You are now in one text file and you need to add this at the end of the list: USB_MSD_PWR_OFF_TIME=0

What I see know is that the 2020-10-28 has no stable release?
2020-12-11 is latest stable.
You see that too?

After applying the USB ...... to 0 you reboot with or without the SD card in ( for the first time ? ).
Sorry for my noob questions but I'm relatively new to Linux.

2020-10-28 is the version number of a beta release. Stable releases are a subset of beta releases and default releases (and critical updates) are a subset of stable releases. Therefore, if you configure your system to track the beta releases you'll see all the images, some good, some bad.

[caro7372]

@carras
Where did you set that 0 ms?
In the config.txt ( on the SD-card ) or ???? I'm a bit confused now if I did the right thing.

You get an SD-card with Raspberry Pi OS and boot with it.
Then you execute the command in SSH/terminal: sudo -E rpi-eeprom-config --edit
You are now in one text file and you need to add this at the end of the list: USB_MSD_PWR_OFF_TIME=0

What I see know is that the 2020-10-28 has no stable release?
2020-12-11 is latest stable.
You see that too?
After applying the USB ...... to 0 you reboot with or without the SD card in ( for the first time ? ).
Sorry for my noob questions but I'm relatively new to Linux.

2020-10-28 is the version number of a beta release. Stable releases are a subset of beta releases and default releases (and critical updates) are a subset of stable releases. Therefore, if you configure your system to track the beta releases you'll see all the images, some good, some bad.

Yes, I understand that ( now ) but was a bit confused about Home Assistant 5.8 was setting it to 2020-10-28 although it now seems it was Beta.

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

[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