DeskPi Pro bad SATA controller?

Hello All,

I purchased a DeskPi Pro case for an RPi4, about a week ago. Wanting to use the internal SSD tray (that also facilitates the use of an m.2 SSD), I assembled the case with a Samsung EVO 860 SSD drive. I had been using this SSD to boot an RPi4 for several months, using a generic SSD/USB adapter cable I purchased from Amazon. It worked perfectly. However after assembling the Desk Pi and configuring the Raspbian OS, downloaded last week, the Pi will not boot from the internal SSD.

I’ve researched the matter for several hours and it would appear that this is a known issue, which I honestly thought had been fixed. It seems that the JMicron SATA controller doesn’t play well with others, and there are many reports of DeskPi Pro customers having the exact same issue. There’s a fellow named Kevin Feng, who apparently works for 52Pi, and posted a 52+ minute YouTube video with instructions for getting this case to work with SSD…but that procedure doesn’t work, and a whole bunch of people have reported as much in the comment section of his video:

Seeed Studios’ product page also shows people having the same problem with the SATA controller. However in the YouTube comments on the video I linked to, Mr. Feng makes reference to them (52Pi) having a new controller that the company will provide to get this working. I’ve sent a couple of email inquiries to them on their web page, and have tried their “live chat” feature several times. There’s no one home.

So I’m curious to know whether or not anyone else has had experience with this product? DigiKey stock shows 39 units, and Christoph from Tech Support tells me that they were apparently all stocked at the same time–so I’m wondering if ALL of these would have the same (apparently) dodgy SATA controller?

Thanks in advance.

Tom Betka
Green Bay, WI

Hi @tcbetka , welcome to the TechForum.

First I don’t actually have that exact Pi Adapter, but I do have quite a few Pi4b’s in my server room with various usb-sata adapters…

PS, this site can be helpful for known working/fixing broken adapters: New Raspberry Pi 4 Bootloader USB / Network Boot Guide

So, let’s check your bootloader version, by running: vcgencmd bootloader_version

pi@raspberrypi:~ $ vcgencmd bootloader_version
Mar 18 2021 08:54:11
version 1b43d5b6fe5b71c300563afc0548122752a0618b (release)
timestamp 1616057651
update-time 1617898087
capabilities 0x0000001f

To Flash the eeprom, grab the latest verison of

  1. Download latest Pi OS version:

  1. Use balenaEtcher - Flash OS images to SD cards & USB drives to flash it… (with an microSD card…)

  2. Login: run apt update/apt upgrade

  3. Run sudo raspi-config:

  4. Select: 6. Advanced Options:

  5. Select A7: Bootloader Version

  6. Select E1: Latest

  7. Select: Yes

  8. Select: Yes

  9. Select: Finish

  10. Select: yes (reboot now)

  11. Board rebooting…

  12. vcgencmd bootloader_version


Hi Robert, thanks for your reply…

I did all that–I was the Technical Editor on Derek’s “Exploring Raspberry Pi” book, after you and Jason worked on his BBB book. As I mentioned in my first post, the OS was downloaded from the Raspberry Pi site last week (ie; it’s the latest version available), and my bootloader is the latest version as well–and the same as you showed:

pi@rpi4-4gb:~ $ vcgencmd bootloader_version
Mar 18 2021 08:54:11
version 1b43d5b6fe5b71c300563afc0548122752a0618b (release)
timestamp 1616057651
update-time 1617415102

That said, I do not believe this is an issue with the RPi4 itself, its OS, or the bootloader. All the forum posts I find referencing this issue, appear to point to the JMicron USB-to-SATA controller as the issue. I was just wondering whether or not someone has ordered a DeskPi Pro case from DigiKey lately (in the past month or so) and NOT had issues with USB boot?

My suspicion is that:

  1. This case is one of their first batches, with the (known-to-be) problematic JMicron controller;
  2. The company (52Pi) hasn’t been replacing the SSD board (and by extension, the SATA controller) like they said;
  3. I’ll not hear anything back from them on this.

Thanks again for your reply. I find it disappointing that I can’t seem to get any response from the manufacturer, and in fact that they seem to have stopped responding to everyone at all on this issue (as evidenced by several reports in the forums).


Which controller (lsusb) is on that kit?

I see: RPI4 8GB problem with boot JMicron JMS578 · Issue #316 · raspberrypi/rpi-eeprom · GitHub

Otherwise, i’d really add an issue here:


It’s this one:

Bus 002 Device 002: ID 152d:0562 JMicron Technology Corp. / JMicron USA Technology Corp.

Thanks for that link. I’ll nose around some more on the RPi forums, and see if I can’t come up with something that might work. I can access the SSD, if I simply mount it manually and then cd into that directory. So in theory, it almost seems as though it should boot from the drive too. It did work once this past weekend, but it took like 5-6 minutes to boot (no uSD card in the slot), but then subsequent attempts would just hang with the message:

“mmc failed to release inhibit bits”

It was something like that–it’s from memory, and that’s basically right. I spent some time researching that, but couldn’t come up with a fix. When the uSD is in the case, it will only hang for 30-45 seconds or so when trying to boot to the SSD…because after that it just reverts back to the uSD card, and off it goes.



found this report:

This case would have been perfect. However, they decided to use the flawed JMicron USB bridge that has all sorts of UASP issues. You will be required to add usb-storage.quirks=152d:0562:u to your PIs /boot/cmdline.txt file if you want to use the internal sata.

Smells like you’d be forced to use microsd for boot-up, switch to rootfs on the usb sata adapter…


Seems like it, yes indeed. Bummer. I’ve done that procedure though–a couple of years ago I think, before they offered the new bootloader functionality. By the way, I meant to mention this in my last post but forgot: The new eeprom-based bootloader is automagically updated by the rpi-eeprom service that’s started at boot. So it apparently keeps the bootloader updated for you, as I read this page:

Bootloader updates are performed by rpi-eeprom-update service provided by the rpi-eeprom package. This service runs at boot and updates the bootloader at the next reboot if a new production release is available. The service automatically migrates the current boot settings to the new bootloader release.

Very cool.

Thanks for your help Robert.


Very cool, works on my usb systems:

voodoo@rpi4b4g-02:~ $ vcgencmd bootloader_version
Sep  3 2020 13:11:43
version c305221a6d7e532693cc7ff57fddfc8649def167 (release)
timestamp 1599135103
update-time 0
capabilities 0x00000000
voodoo@rpi4b4g-02:~ $ journalctl | grep rpi-eeprom-update
Apr 01 12:17:36 rpi4b4g-02 rpi-eeprom-update[371]: BOOTLOADER: up-to-date
Apr 01 12:17:36 rpi4b4g-02 rpi-eeprom-update[371]:    CURRENT: Thu 03 Sep 2020 12:11:43 PM UTC (1599135103)
Apr 01 12:17:36 rpi4b4g-02 rpi-eeprom-update[371]:     LATEST: Thu 03 Sep 2020 12:11:43 PM UTC (1599135103)
Apr 01 12:17:36 rpi4b4g-02 rpi-eeprom-update[371]:    RELEASE: default (/lib/firmware/raspberrypi/bootloader/default)
Apr 01 12:17:36 rpi4b4g-02 rpi-eeprom-update[371]:             Use raspi-config to change the release.
Apr 01 12:17:36 rpi4b4g-02 rpi-eeprom-update[371]:   VL805_FW: Dedicated VL805 EEPROM
Apr 01 12:17:36 rpi4b4g-02 rpi-eeprom-update[371]:      VL805: up-to-date
Apr 01 12:17:36 rpi4b4g-02 rpi-eeprom-update[371]:    CURRENT: 000138a1
Apr 01 12:17:36 rpi4b4g-02 rpi-eeprom-update[371]:     LATEST: 000138a1


Well Robert, you’re not going to believe this…but it’s working! LOL…

All the RPi folks do now with their little SD card copying utility, is to copy all the contents of the uSD card onto whatever USB device you select when you run the GUI from their desktop. And since the RPi boots from the partition using the PARTUUID of the boot and rootfs partitions, that just gets cloned from the uSD card and onto the SSD (in my case). So then when you remove your uSD card, the system still goes to the fstab file and looks at the PARTUUID needed for locating the /boot and / partitions. Well, since it was cloned from the uSD card, the SSD card fills the bill, and it’s off to the races you go.

So thanks to your post I simply appended that bit he mentioned onto my cmdline.txt file…IN the SSD’s copy of /boot.


Then I rebooted the RPi4, which still gives me the message about the mmc controller not releasing the inhibit bits, but now it’s quite transient…and within about 10 seconds or so, up comes the OS.


I’ll grab a short video of it and upload it to YouTube, and post a link here. Hopefully this will help someone else at some point.

Thanks so much for finding that fellow’s post. Funny thing is that I went through that discussion section over on the Seeed Studios product page, and either didn’t see it or (more likely) didn’t remember seeing it.


Here’s the little video I recorded.

Robert, please pass on my thanks to Christoph for his help, and let him know I did manage to get this working with your help. As I said, hopefully this will help someone else at some point. I sure found a bunch of posts from frustrated people when researching this issue.

Thanks again.



That’s great news Tom!

Thank you!

No problem, thanks for all your help.


For completeness, here’s another resource I found on this issue: