We use cookies to provide our visitors with an optimal site experience. View our privacy notice and cookie notice to learn more about how we use cookies and how to manage your settings. By proceeding on our website you consent to the use of cookies.
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?
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:
This case is one of their first batches, with the (known-to-be) problematic JMicron controller;
The company (52Pi) hasn’t been replacing the SSD board (and by extension, the SATA controller) like they said;
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).
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.
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.
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.
usb-storage.quirks=152d:0562:u
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.
Sweet!
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.
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.
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?
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
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.
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
Which SATA controller is that in the DeskPi case you have? What is the output of this command:
$ lsusb
What are you doing when the freeze happens–are you using the RPi when the freezes happen?
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.
Many thanks for your suggestions. Much appreciated.
Not clear to me how I would be able to run dmesg once the the Pi hangs/crashes/freezes.
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.
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.
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.
