1 of 1 people found this helpful
It would be helpful if you can specify exactly the brand and model of SSD that you're trying to get working if you're not sure. I suspect you mean mSATA (rather than M.2 or PCIe) as M.2 PCIe cards don't seem to be supported. Have you triple-checked connector alignments and ensured everything fits snugly?
Regardless - is there any changes to the lights on the board once you have the daughter board installed? Does the red LED blink? Does anything get unusually warm? Will it boot if you put a blanked dummy card in the microSD slot (as some people have reported this was necessary)?
Unfortunately, I don't own one of these Pi Desktop setups so I can't really provide any more specific tips.
Thanks for the reply.
You are right - I incorrectly stated it was a M2 - is is as you say a msata
The device in question is a Samsung MZMPC256HBGJ-000D1 256 GB mSATA PCI-E SSD drive.
I have a USB caddy which I have installed it in and connected it to one of the three remaining USB ports on the pi (one is iused to connect the SSD board supplied with the pi desktop.
In this configuration it is able to boot and function normally (without a micro sd card).
However when I take this (working) SSD and fit it to the board fitted to the pi inside the pi desktop case - it will no longer boot - in fact the monitor connected to it goes to power save mode - presumably as the hdmi has not come online.
I'm guessing you're connecting the M.2 via external USB, using an adaptor, and not plugging in any mSATA in the Pi Desktop board.
Like lui_gough I'm afraid I can only guess the issue, I've not seen the Pi Desktop in real life.
Anyway, it's best to eliminate things to narrow down the issue. Personally I'd try to remove the Pi Desktop and test the Pi on its own with the USB boot capability. Once that works, then install in the Pi Desktop. The Pi Desktop board is not needed for the USB boot functionality to be tested, because that functionality is part of the Pi 3B+.
Also, there is a note here that states that the feature is experimental and doesn't work with all devices.
If the feature doesn't work with your M.2 SSD + adapter combination, then you could use it just for a USB connected file system, and still boot from micro SSD.
Hi thanks for replying.
I made a miskate in describing the SSD - it is a Samsung MZMPC256HBGJ-000D1 256 GB mSATA PCI-E SSD drive.
It does fit onto the ssd board that is supplied to fit on top of the raspbery pi.
This ssd will boot the pi when connected to one of the three remaining usb ports using a usb caddy.
Using this ssd on the 'daughter' board the pi then doesn't even seem to boot.
I don't know if there are any diagnostic commands to see if the daughter board is functioning - when booted from the USB caddy via the raspberry pi usb ports.
1 of 1 people found this helpful
The documentation states the USB connection on the daughter board is for a USB Flash drive, but a SSD consumes more power, or there may be some other limitation due to the difference between Flash and SSD sticks, so I'm wondering if that port really can only be used for a USB flash drive (aka typical memory stick) or not. From what I can tell, the combination of Pi and the daughter board are really only designed for the specific scenarios as per the user instructions, and any straying off it (even something slightly) can result in difficulty it seems. There are others who wanted to do things like (say) auto-power-on after a power outage, and this scenario is not supported for instance.
Another possible test is to see if, once booted fron microSD, can the internal USB port be used for accessing a file system on the SSD? And another could be to try to boot off a memory stick just to verify that USB port functions, but at some stage it may be easier to just leave the SSD attached to the Pi's USB port if that can work for you practically and aesthetically. I think it's unfortunately all experimental to reach your goal, unless someone else can try it out and report on it too.
I've not seen close-up photos of the board and case, and if cables could be routed appropriately, so I don't know if that is practical or not.
EDIT: Just noticed you mention it's not an M.2 disk? In that case, if the on-board mSATA connection isn't working, it sounds like a board issue. But it's just a guess. Hopefully you get a response from someone else who has used that SSD, or otherwise can identify the issue.
1 of 1 people found this helpful
As Shabaz says it's most likely to be a power issue ...in fact those high speed SSD drives will take quite a bit of current in service and many have an heatsink for the purpose of dumping all that heat I would certainly consider supplying it with an external/additional 5V even though you could apparently leach it off the USB.
I've had many a drive where low power has left us with an intermittent drive and this can even corrupt the filesystem if you are unlucky and writing to the FS at the time
Hi, Sorry it's taken so long to reply to this - been a bit busy.
When the Raspberry pi is installed in the Pi Desktop case the original micro usb port that is used to power it is no longer accessible - it cannot be used.
Instead the daughter board that plugs into the header on the Raspberry pi has two micro usb ports.
One is now used for the power supply and the other is used to connect to one of the four USB ports on the raspberry pi itself. (top right)
This makes sense as the daughter board has a physical power on/off button.
This daughter board also has a mSATA connector as well a a real time clock powered by a coin battery.
As far as I can see it would not be possible to suplement the power for the mSata without dispensing with the pi desktop case.
I have upgraded the PSU to 3.0 amp in any case - but this didn't resolve the problem.
Curiously this mSATA SSD will work (boot etc) when the caddy is connected directly to the Raspberry pi USB port - which takes it power VIA the daugther board.
When I then move this SSD to the daughter board itself - the Raspberry pi then resfuses to boot. If it was a power issue, I would have thought that neither should work.
I'll try and sort out a photo showing this in the next day or so.
Sorry for the rather poor photo.
Hopefully you can make out that the power is not direct to the Raspberry pi in this instance but via the add on board.
To the right you should be able to make out the connector supplied with the case that plugs into the top right USB of the pi and the right most micro usb on the daughter board.
The other USB cables go to the USB SSD caddy for the mSATA and the Keyboard/Mouse (shared).
Seems like something has changed with maybe some O/S updates. This used to work for me but now I have to follow the instruction above of separately powering the HAT.
In addition on boot it now complains about the filesystem dependency not being met. This happened on two Pi-Desktops that were previously working.
Does a disk check and seems to time out as it is waiting to complete maybe due to size of drive...
Timed out waiting for device dev-disk-by\x2dpartuuid-c28c1a14\x2d01.device.
Dependency failed for File Sutems check on /dev/disk/by-partuuid/c28c1a14-01
goes into recovery mode and then will boot. After allowing the disk check to finish powered off the USB port separately; The timing seemed to resolve and I was again able to run the power directly off the board again. This seems to have resolved my issue.
eSata being used is a Samsung 256G 860 EVO
I have had lots of trouble with this case using a 128 gig msata drive. It will not boot if you have a USB hub attached (I use mine for keyboard/mouse/webcam). It appears as though the OS looks for a bootable USB drive and gets confused. If you plug the hub into the pi after the rainbow screen it will boot. Now it will not properly reboot, and if you use it remotely as I do, it will not boot since the hub is installed.
So far, not impressed at the waste of time and money.
My advice - dont buy this case.
Does anyone have any pointers as to how I might troubleshoot this further?
I have A Raspberry Pi3 B+ installed in a Pi Desktop case.
Having failed to get the pi to boot from the SSD using the instructions (and various other methods by googling) I tried this route:
Using Etcher on a Window PC and the M2 in a USB3 SSD caddy I was able to transfer the latest image.
Transferring the caddy to one of the USB ports on the pi Desktop I can then reliably boot from the SSD without a micro sd card installed.
On fitting the SSD to the Pi Desktop SSD 'daughter' card the pi refuses to boot. The monitor senses this and goes into power saving mode - so I guess hdmi out on the pi is dead at this point.
Thinking it might be the PSU I am now using a 3.0 amp version. This made no difference.
The daughter card appears to be working as when I remove the ethernet cable (left for several hours) and reboot - the data and time are current.
Any advice gratefully received.
Message was edited by: Ian Martin Brain fade as to SSD type