DeskPi Pro bad SATA controller?

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:


Hello All,

Apologies for being late to the party.

I purchased a DeskPi Pro case about ten days ago. It’s one of the new ones with the modifications to the SATA support. My problem is that the Pi, which is configured to boot from a SATA drive, now freezes once or twice each day, which it never did before putting it into the DeskPi Pro case. Previously, the SATA drive was connected through a StarTech USB to SATA cable (USB3S2SAT3CB (Chipset: ASM1153E)) and the Pi was absolutely stable. When using the DeskPi Pro case I have also noticed that the boot time seems slightly longer, possibly because the new version of the case no longer supports UASP.

Has anybody else experienced the same problem that I am having?

Many thanks.

not the same problem
but mine had the old pcb board inside
i orderd at the same time
it did not work at all
the support of digi-key are great and help me so good
have you update the firmware ???
and the 8gig pi needs a update
thats all i know

Hi @haan2787

Thank you for the suggestions. I am already on the most recent firmware. As I said, everything was working fine until I installed my 4GB Pi into the DeskPi Pro case. The SSD has now been removed from the case and is connected externally once more using the StarTech USB to SATA cable and everything is stable again. It must be due to a remaining bug on the new board.

I have also just discovered that the new board in the DeskPi Pro cases no longer provides UASP or TRIM support. Poor show on the part of the manufacturer.

oke i am sorry for that
and yes its a bad thing
if a find something a will let you know

A couple of things to check…

  1. Does the kernel ring buffer show any obvious errors when it hangs up? What does this command output right when it hangs (ie; right after the time the thing hangs up):

$ dmesg

  1. Which SATA controller is that in the DeskPi case you have? What is the output of this command:

$ lsusb

  1. What are you doing when the freeze happens–are you using the RPi when the freezes happen?

  2. Are you sure the SATA drive is OK? How old is the drive? Did you try to reformat it and install a new version of the OS?

Some things to try anyway, to maybe get some more information.


1 Like

Hi @tcbetka

Many thanks for your suggestions. Much appreciated.

  1. Not clear to me how I would be able to run dmesg once the the Pi hangs/crashes/freezes.

  2. The output from lsusb with SSD connected externally is:

Bus 003 Device 003: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Bus 003 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 045e:0047 Microsoft Corp. IntelliMouse Explorer 3.0
Bus 001 Device 003: ID 03f0:354a HP, Inc 
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I cannot provide the corresponding output for the SSD mounted internally without quiet a bit of case re-assembling work.

  1. I am intending to run the Pi as a headless server for a work-related project. In practice, the Pi just crashes/freezes at random times when idling.

  2. I am as certain as I can be that the SSD is OK. It has had light use in a Windows PC before it’s present use with the PI. It was reformatted as FAT32 prior to writing Raspberry Pi OS to it from a working microSD boot drive. The point to remember here is that the system is totally stable when the the SSD is mounted externally, but unstable when it’s mounted internally. Must be something wrong with the SSD board in the DeskPi Pro.

Yes, good point about dmesg. You should be able to read from the kernel logs that get written though–there might be some useful information there. See this link for some hints:

Your ASMedia Technology device should be fine–everything I’ve read about those indicates that it’s not as problematic as the JMicron one I had in my DeskPi unit (ie; the entire reason I started this thread, lol). But I was able to work around that issue, as I posted near the end of the resolution on my original issue. And indeed, the Argon One case I bought now, also has the ASMedia Technology SATA/USB converter device in it–and it seems to work flawlessly, right out of the box.

I am not sure what to tell you, to be honest. Your suspicion might indeed be correct, about the internal SSD board (and controller) being wonky–but again, the ASMedia Technology device is supposed to be pretty good, as far as I know. Here’s the device they’re using in the Argon One case I just bought:

pi@rpi4-8gb:~ $ lsusb
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge

I guess I would advise you to sniff around a bit in those kernel logs, and see if you can spot anything.


Hi @tcbetka

Thanks again for your suggestions.

I would have to put the SSD back into the case and wait for a crash to be able to inspect the kernel logs. I might just try that if things get desperate.

The ASMedia Technology ASM1051E SATA 6Gb/s bridge that is detected using lsusb is with the SSD connected externally with the StarTech SATA to USB3 adapter. It ought to be easy for me to do a shutdown, disconnect the external SSD, reboot from a microSD card and run lsusb again to see the identity of the internal chipset. Perhaps that internal chipset is what is being identified as:

Bus 003 Device 003: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter

Just for the sake of completeness, the SSD is a Kingston A400 120GB (SA400S37/120G) which is one that I have seen recommended in this rather useful guide:

I have a busy work day tomorrow and will report back when I can find the time.

LOL… Well, we certainly can’t help you debug a problem in a given system, when you’re not actually using said system.

If you’re interested in pursuing this issue further, in terms of why things lock up when your Pi is in the DeskPi case (along with that SSD), then you’ll have to put it back into the configuration that it was in when you experienced the problem. Then we can figure it out from there.


The SSD is now back in the DeskPi Pro case. I now just need to wait until it crashes to see what dmesg might reveal.

lsusb reveals that the SATA chipset that’s fitted to the the case is:

ASMedia Technology Inc. ASM1153 SATA 3Gb/s bridge

That’s the (allegedly) good SATA/USB controller. It’s the JMicron unit that people have complained about, from what I saw in the forums while researching my issue.

Yeah, I think you’re sort of stuck until it freezes up again. Problem is (like you said), if it’s entirely frozen you won’t be able to access the thing to run dmesg. However you should still be able to have a look at the various logs to see if there was a hint of an issue right before it froze up.