This is definitely a good tenet @Tithrion! (and very close to my own recent years’ understanding of the price/performance ratio 
).
Best regards
I’d love to see this one.
Hi @Kirtai!
You definitely will; I’ll post a picture of my shapeless contraption. I am slooowly working on a bespoke 3D printed enclosure for the whole kit: I have acquired all the necessary bits and cables but as always time is a tyrant!
Best regards 
1 Like
Looking forward to it.
(My Zynthian is probably an even worse mess)
1 Like
Hi
To all those interested in an nvme V 5.1 mod:
I did a bit of online research, about different lengths of PCIe ribbon cables possibly affecting performance to a significant extent, but it turned out that the prevailing consensus is that it does not really influence that much the data transfer, especially when we talk about differences of a few centimeters.
Conversely, as often pointed out in this forum, the ribbon cable for SD card read/write operation is very sensitive to even small changes in length, due to synchrony aspects apparently.
Just as a possibly useful bit of info, and of course I can be mistaken on this.
Regards!
1 Like
BTW,
for those in the proces of evaluating NVME options for RPI5, I’m quite satisfied with this aliexpress NVME module that can be screwed together with the active cooler. Another good feature is that, so far, it works nicely just with the power provided by the pcie ribbon cable. This was an important feature for me since I use the module in a KKSB case zynthian, where i needed the power pins for the touch display and the DAC.
3 Likes
Hi everybody! Can I ask @jofemodo if you confirm that the [to Hat - to Pi5] ribbon cable has to be inserted with the printed surface facing outwards, both on the Tiny Hat and the Raspi5 PCIe connector? (as per your original photos reposted here).
I have returned the Orico nvme and coincidentally got the same KingSpec NX drive as @jofemodo’s (mine is the 512 GB size). The @riban’s script worked fine again with the new SSD, and I further updated the Pi5 bootloader firmware, but Oram is nowhere to be found on the drive, and the system appears to be even unable to see and locate any nvme partitions after the successful completion of the script.
I wonder if I have wrongly connected the PCIe ribbon to the Pi5, and the copying routine behaves anyway as if there was an SSD drive available to the OS, confirming that the copy of the OS to the new drive has been performed, even if it hasn’t.
That is why I am asking about the ribbon cable orientation (I will post some photos later).
Thanks!
As mentioned, these are two pics of my current V5.1 + nvme hat setup. It can be seen that the printed side of the flat cable is facing outwards, both on the Tiny Hat and Rpi5 PCIe connectors.
Before resigning to decouple (again) the SBC and thermal block from the bottom case, in order to possibly reverse the ribbon cable orientation on the PCIe port, I would like to know from other nvme modders (and @riban and @jofemodo) if they detect anything wrong in my placement of the 16-pin flat cable.
In general, I tend to think that the issue of both Oram and Raspberry OS not seeing the SSD drive (even after successful completion of the @riban’s script) should not be related to the length of the ribbon cable (80 mm), either because PCIe data transmission does not seem to be actually much affected by the length of wiring, or because 40-60-80 mm is the stock gamut of spare ribbon sizes explicitly sold by Raspberry nvme hats brands themselves.
Any useful opinions/suggestions appreciated!
All best regards
If I remember correctly, my Tiny NVME hat is installed the other way round (!), with the NVME facing upwards. Cable is also fed directly from the Pi to the hat but I currently can’t say how the cable exactly is oriented or if it makes any difference. But having the hat turned will definitely result in problems.
I remember to having checked exactly the pictures in the corresponding amazon page of the hat, where you can find detailed pictures on how to install the cable.
Just copied the relevant picture from the amazon page:
Looks like the cable is inserted wrong in the hat.
Hi @Tithrion
I did not know that placing the hat upside-down (hence the nvme drive downwards) was known to be problematic. As a matter of fact, this is how @jofemodo himself arranged it inside the bottom case: see in the compared photos how the shape and orientation of the hat are the same, and the printed text “to Hat” appears facing downwards the hat board.
Anyway, I tried before to stick it with adhesive tape to the upper rim of the bottom case (the right-side ridge in both mine and Fernando’s photos) and it did not make any difference to the drive visibility in the OS. Besides, I guess that laying the SSD down, in contact with the bottom metal surface, is a way to dissipate heat efficiently. Can it be?
As far as I remember from the Zynthian building wiki, it might be that, as long as respective alignments are complied with, ribbon cables orientation should be reversible, but I am very unsure about it.
Anyway, it looks like the recommended ribbon orientation on the Hat in your Amazon pictures is exactly the opposite of mine and @jofemodo’s mod…
What concerns me particularly is the relationship between the cable’s orientations on the Raspi5 PCIe port and hat’s PCI connector.
Although the photos in the TinyHat accompanying booklet were very blurry - and it was already a significant strain on the spacial cognition to look at everything upside-down, and often left-right reversed respective to the position of the Pi5 inside the Zynthian box - I came to the (possibly wrong) conclusion that the printed side of the ribbon cable must be seen facing outwards, looking at the brown PCIe port lock from outside the SBC.
Edit: I forgot to mention that I already tried to reverse the ribbon orientation in the hat’s connector, like in your Amazon photos, and it did not solve the issue of the nvme drive being invisible to the OS.
Ideally, I would like to hear also from our beloved in-house main designer, before removing the mainboard from the case again!
Thanks for your hints and contribution to the subject @Tithrion 
All the best
I’m not sure if there is enough thermal flow without a heat pad between NVME and heatsink/case and without it, it also might lead to heat accumulation. Otherwise the possibly already heated case near the RPi5 heat sink position might induce additional heat and the position other way round might provide more air to spread the heat to? [Not sure about that].
That might not be true in every case and chip.
And “reversible” would implie that both ends are switched.
I too already noticed that, but thought it was due to a possible design change. At least it works for me with the setup according to the picture from my amazon order.
Interestingly on this picture the setup with the ribbon cable the other way round is explicitly flagged as wrong.
To be honest I also was kind of thankful, as the switched hat orientation also lead to a better accessibility of the NVME itself without having to remove the whole hat in case a change would be needed.
My HAT installed:
You can’t see directly the orientation at the RPi side but it’s inserted straight and you can extrapolate from this image of the spare FPC which came with my hat:
[edit]
Just checked @jofemodo s link to amazon.es which contains the exact same picture I posted from my amazon.de order.
@jofemodo as you - according to your photo - installed the fpc as it is flagged wrong by this picture, does everything work for you?
1 Like
Many thanks for your detailed feedback @Tithrion 
Very kind of you!
I have to say that I am rather tempted to stop investigating further, and to mimic directly your hat placement and ribbon position. I obviously do have the same stock 40 mm flat cable as you, which came in the hat’s package.
It would entail switching the ribbon orientation, both on the hat’s connector and Raspi PCI port, with related mainboard decoupling and likely rupture of thermal tape, but it is probably worth the try and effort.
All best regards 
Alright, back to the topic:
-
I have set a KingSpec NX 512 Gb nvme drive on S2Pi Tiny Hat exactly as @Tithrion’s. Same hat position with SSD facing upwards, same ribbon orientation on both ends, same flat cable length.
-
I have run the @riban’s script successfully, and then typed raspi-config nonint do_boot_rom E1 0 as instructed.
I am still unable to boot from nvme after powering off, rebooting and extracting the SD card.
This is the result of my ensuing monitoring of the mounted drives and partitions:
- root@zynthian://zynthian# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
mmcblk0 179:0 0 59.5G 0 disk
├─mmcblk0p1 179:1 0 512M 0 part /boot/firmware
└─mmcblk0p2 179:2 0 59G 0 part /
root@zynthian://zynthian# lspci
00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2712 PCIe Bridge (rev 21)
01:00.0 Ethernet controller: Raspberry Pi Ltd RP1 PCIe 2.0 South Bridge
root@zynthian://zynthian# df -h
Filesystem Size Used Avail Use% Mounted on
udev 3.9G 0 3.9G 0% /dev
tmpfs 806M 14M 793M 2% /run
/dev/mmcblk0p2 59G 33G 24G 58% /
tmpfs 4.0G 104M 3.9G 3% /dev/shm
tmpfs 5.0M 48K 5.0M 1% /run/lock
tmpfs 100M 48K 100M 1% /tmp
tmpfs 50M 32K 50M 1% /var/log
tmpfs 200M 0 200M 0% /var/tmp
/dev/mmcblk0p1 510M 65M 446M 13% /boot/firmware
from which it is obvious that no nvme drives partitions are either mounted or active.
This is the output from the nvme script completion. I seem to detect some wrong lines:
Fixing mount UUIDs
Finishing up…
umount: /mnt/nvme/firmware: not mounted.
umount: /mnt/nvme/root: not mounted.
Setting boot order to SD, NVMe, USB
Updating boot rom
/bin/raspi-config: 1932: [: Illegal number:
BOOTLOADER: up to date
CURRENT: Tue 12 Nov 16:10:44 UTC 2024 (1731427844)
LATEST: Tue 10 Sep 13:40:30 UTC 2024 (1725975630)
RELEASE: latest (/lib/firmware/raspberrypi/bootloader-2712/latest)
Use raspi-config to change the release.
Installation complete. Power down then remove uSD.
Furthermore, it seems that the raspi-config nonint do_boot_rom E1 0 bootloader update has rendered the Oram startup unpredictable, that is it mostly work and sometimes not.
I had to reset the bootloader several times, with a recovery SD burnt on Pi Imager, but now the Zynthian startup has become not completely reliable, sort of hit and miss. What can it possibly have gone south? Am I the lucky owner of a faulty Tiny Hat?
BTW - I had to manually enable the PCI gen 3 port in sudo raspi-config, in order for it to be visible, but it reverts to invisible as soon as I reboot. And, sudo raspi-config cannot handle any boot order changes, should I want to do so, since it claims that the bootloader version is not updated. Does possibly the script set a wrong or outdated bootloader version?
Any further advice on this by now unfathomable enigma?
EDIT/UPDATE:
Zynthian seems to have reverted to normal and nominal SD functionality, and for the time being I will leave it as it stands. My nvme mount looks fairly correct, and potentially working, but something in the combined OS drives management and bootloader configuration prevents it from behaving so. I guess that, for the moment, there must be something inherently conflicting, between the overall Zynthian OS framework and the usage of SSD media for system loading, to the extent that even small setup differences between identical hardware layouts make it problematic.
I will likely drop the subject of this nvme mod for a while, since it is draining too much time from music composition and I definitely cannot afford it right now. The overall plan behind equipping also my V5.1 kit with nvme was to set up a multi-Zynth orchestral template with soundfonts, and see how it holds against a typical PC-based gear with sample libraries. To this end, having SSD for quickly auditioning instruments and loading large templates is absolutely beneficial, besides making the system flow much more reliable. To better times then!
Thanks, regards 
Maybe the script should run lsblk first to determine that the nvme is available. It looks like a hardware issue with your RPi / NVMe hat / NVMe drive. When booted into an OS, e.g. zynthian via SD you should see the NVMe drive. If you can’t then you need to fix that before attempting to install to it.
I haven’t had to diagonse such problems so have little experince to offer. I would start with lsblk and lspci to investigate what your machine can see. On my RPi5, booted into zynthian on NVMw only, I see:
(venv) root@zynthian-rpi5:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1 259:0 0 238.5G 0 disk
├─nvme0n1p1 259:1 0 511M 0 part /boot/firmware
└─nvme0n1p2 259:2 0 238G 0 part /
(venv) root@zynthian-rpi5:~# lspci
0000:00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2712 PCIe Bridge (rev 21)
0000:01:00.0 Non-Volatile memory controller: Silicon Motion, Inc. SM2263EN/SM2263XT SSD Controller (rev 03)
0001:00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2712 PCIe Bridge (rev 21)
0001:01:00.0 Ethernet controller: Raspberry Pi Ltd RP1 PCIe 2.0 South Bridge
@Aethermind
Try also the following command:
dmesg|grep -i nvme
For reference, my output:
root@zynthian:~# dmesg|grep -i nvme
[ 0.395473] nvme nvme0: pci function 0000:01:00.0
[ 0.395483] nvme 0000:01:00.0: enabling device (0000 → 0002)
[ 0.410879] nvme nvme0: allocated 64 MiB host memory buffer.
[ 0.474935] nvme nvme0: 4/0/0 default/read/poll queues
[ 0.484188] nvme0n1: p1 p2
[ 1.595892] EXT4-fs (nvme0n1p2): mounted filesystem 7dff538e-6a56-472b-bbb6-3d894c13091d ro with ordered data mode. Quota mode: none.
[ 1.919072] EXT4-fs (nvme0n1p2): re-mounted 7dff538e-6a56-472b-bbb6-3d894c13091d r/w. Quota mode: none.
root@zynthian:~# lspci
0000:00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2712 PCIe Bridge (rev 21)
0000:01:00.0 Non-Volatile memory controller: Micron/Crucial Technology P310 NVMe PCIe SSD (DRAM-less) (rev 01)
0001:00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2712 PCIe Bridge (rev 21)
0001:01:00.0 Ethernet controller: Raspberry Pi Ltd RP1 PCIe 2.0 South Bridge
root@zynthian:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1 259:0 0 931.5G 0 disk
├─nvme0n1p1 259:1 0 511M 0 part /boot/firmware
└─nvme0n1p2 259:2 0 931G 0 part /
As you can see, currently no SD inserted.
If you don’t get the relevant NVME lines, your hat isn’t recognized at all.
If you have it connected the same as I did, I assume as @riban already mentioned a hardware defect. You could try the other FPC, but if that also fails the error will be in the hat (or worst case in the Pi).
Do you maybe have another RPi5 or NVME hat to test with?
You might try to reach out to the vendor, in case it has already been defective on delivery…
Thank you @riban. Yes, for how unfortunate and rare it may be, an underlying hardware problem would explain my persistent issues with adding nvme to V5.1, because it otherwise works flawlessly on my custom Oram Pi5 (but on a completely different hardware, except Pi5 of course).
I indeed attached the results of those commands, and it is blatant that no nvme drive is mounted and partitioned on my V5.1.
I unfortunately never obtained this CLI output, but
appeared once when I forcibly enabled PCI gen 3 via sudo raspi-config, only to disapper on reboot.
Thank you @Tithrion, will have a try.
Indeed, I am starting to see the potential culprit in the hat itself. At least, it is powered by the Pi5, since I can clearly see an active led under the KingSpec nvme card.
Thanks to both @riban and @Tithrion for your support. I am not very optimistic at the moment about providing my V5.1 with SSD.
All best regards 
I ordered everything to mount the NVMe, it will arrive tomorrow, but in the meantime I designed and printed the support to keep it at the right distance from the Raspberry… Pure madness for me to try this thing, but I am an experimenter of my ignorance… I’ll follow you…
1 Like
I have ordered the same set Lanfranco, but delivery to norway is slower!
Aethermind, what a long struggle. Hardware fault seems likely, but it is so annoying the time one spends before arriving at that conclusion. And then it is still just a possibility. And there are several pieces of hardware…
Still some confusing in my head around the ribbon cable orientation, but soon at least there will be two more footsoldiers battling the NVME war with the exact same weapons! (physical weapons that is - judging by my nice visit to Lanfrancos site i concluded he is soaring on a much higher build level than i am)
It returns an absolutely blank line @Tithrion, so again no nvme drives detected in the system…
You just started the nvme quest on a higher ground @Lanfranco, with your bespoke TinyHat holder!
I too tried the Orico SSD, but later returned it and went for a 512 Gb KingSpec, to no avail currently and unfortunately .
All best luck, and please let us updated!