During the festive holiday period a part of one of the projects I have been working on involved moving my home automation setup from a Raspberry Pi 3B+ to a Raspberry Pi 4B 4GB. As part of this, I wanted to switch from using an SD card to booting from an SSD for improved performance.
I already had spare parts lying around which would be reused for this.
After using the Raspberry Pi Imager to provision the SSD with Raspberry Pi OS Lite, mounting the boot partition to add the
ssh file, and connecting the enclosure to one of the USB 3 ports on the Pi it wouldn’t boot. After a bit of digging I found a workaround to get this working.
This is in no way a recommendation for this USB enclosure, just a workaround to get it working. If I was buying new parts, I would do some research into working setups that others have used.
While this is an Orico branded enclosure that I got in late 2019, I do also have an Anker enclosure that I have had for a few years which also did not boot and is visually the same. There may be many different branded versions of this generic enclosure.
This is listed in the Amazon listing as using a JMS578 chipset, and there is a lengthy thread on a Raspberry Pi GitHub issue around flakey support. This suggests adding an extra setting to the beginning of the
/boot/cmdline.txt file to enable
usb-storage mode for the device (instead of the
After adding this, it still wouldn’t boot. Connecting it to a USB 2 port however did allow it to boot (albeit with much lower performance). I wanted to get to a USB 3 boot though, and forum posts suggested that it should have been possible.
The “quirks” setting that we applied has a value that consists of of the vendor and device IDs for the USB device, and should match what
lsusb lists. The values I tried came from the forum post, not my own checks.
lsusb shows our device registering with an “unknown” vendor id, 0080, which didn’t seem right. While trying to find out more about this device and if there were firmware updates available for it, I came across a post on the ODROID forums talking about other issues with this chipset and sleep/wake behaviour. The manufacturer has no updated software on their site for it, and it sounds like it has more issues with long term usage. This forum post did however point to a firmware updater utility on the ODROID site.
Using this utility I could see that it reports back a firmware version, which I hoped confirmed that the product page was correct about the chipset used in the enclosure.
[email protected]:~/JMS578FwUpdater $ sudo ./JMS578FwUpdate -d /dev/sda -v Bridge Firmware Version: v0.2.0.4
Next I updated the firmware, using the instructions on the utility page and disabled the auto spin down feature (as I was using an SSD anyway).
[email protected]:~/JMS578FwUpdater $ sudo ./JMS578FwUpdate -d /dev/sda -f ./JMS578-Hardkenel-Release-v173.01.00.02-20190306.bin -b ./backup.bin -t 0 Update Firmware file name: ./JMS578-Hardkenel-Release-v173.01.00.02-20190306.bin Backup Firmware file name: ./backup.bin Auto spin-down timer: 0 min. Backup the ROM code sucessfully. Programming & Compare Success!!
Using the utility again to check the version number reported the original version, until I performed a reboot. I was running this utility from the PI, targeting the disk it was booting from over USB 2, so could not just disconnect and reconnect the device.
After performing this firmware update,
lsusb now reports the device as we expected to see.
Bus 001 Device 003: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
Now I could shut down the Pi, move the enclosure to a USB 3 port and boot from USB 3 successfully.
At the start we had enabled “quirks” mode to use
usb-storage instead of
uas. This is still required to maintain consistent drive performance, but on the upside we can now boot over USB 3 after performing this firmware upgrade.