That is very useful @riban, thank you for having spent time into unlocking this apparently troublesome startup of Oram from nvme on RPI 5.
I will try to replicate the listed steps, and see what happens with my Argon Neo Pi5 + Crucial nvme.
Nice, finally I can run it from a usb stick!
The dd command seems to be failing for me. I get:
dd writing to '/dev/nvme0" : Invalid argument
Harry
Thanks @harrylnorris. I had written the wrong path to NVMe drive. I have edited the post to correct this.
Just checking - were you able to boot and establish root with no SD card inserted?
Thanks,
Harry
Yes! My RPi5 has no uSD, only NMVe. I can reboot it and it boots to ZynthianOS and works fine. Root partition on the NMVe is used.
What is the boot time? How much faster is booting from NVME compared to your SD card?
1 Like
Boot time is just a few seconds faster, maybe 15s compared with 18s on a RPi5, so it is marginal. The boot time in Oram and on RPi5 has improved greatly so these few extra seconds are less of a concern. Some other operations are faster though, particularly disc access. I might expect better read/write performance such as recording / playback of multitrack audio, but that isn’t tested yet.
3 Likes
Thanks!
I thought NVMe would be faster than SD. So I will give Oram a try…
Hi @all!
FYI, i’ve been testing this NVMe expander for the RPi5:
It fits perfectly the V5 case! Like designed for it!! 
Off topic
BTW, note the new position of the SD-card connector in the main board. I had to short the distance and improve the wiring so the sdcard synchronous signal could travel the distance in less than half period at the faster frequencies supported by the Pi5. FYI, RPI5 supports SDR104 cards at full speed, what means the bus frequency is 208MHz, compared with the RPI4 that only supports DDR50 with the data bus running at 48MHz. If you do some calculations, you can see how close to the physical limit we are, so every mm counts and i had to deploy “best practices” for routing high frequency signals. Much fun when it finally worked! 
This is the detail of routing:
Note the track-length matching, to keep the signal synced and the “big” separation between tracks to avoid cross-talking.
Regards!
7 Likes
Hey @jofemodo, I really appreciate this kind of technical post 
I’m glad to see there’s enough room in the case for lying the SSD drive in contact with the case.
This is a 2242NVME drive I guess. They are not extremly rare and really expensive as before (thank you Steam Deck), but the 2280 format is still cheaper. As is (based on photos look), I would say, a 2280 can fit if one can find the right expansion board.
Regarding the high speed tracks routing: thank you for the explanation of the basic principles you have followed.
For the PCIe lines, I believe it’s even more delicate.
[HS]
For the CM4, RaspberryPi gives the track length difference on each PCIe pair at the output (the 100 pins Hirose connector), then up to the designer to draw the carrier board with these infos.
For RBPi5, I didn’t found any similar info. But it looks like some official partners have it, so that they are able to sell this kind of NVMe drive board. Ok, it’s not that expensive +/- 15 bucks. But a M2-M connector + a couple of passive components could be cheaper and better integrated (on a V6?).
I see this like a sort of obfuscation coming from the more and more big buisness orientation of RBPi (now quoted in London).
conclusion/question: how could a project, like Zynthian, create its own board build around RBPi5 without these fundamentals ?
[/HS]
1 Like
I wondered whether the Pimoroni NVMe base would not fit between the Pi and the controller board. Maybe some standoffs could be used smaller than the ones provided? (7mm seems more than necessary to me) But I suppose someone already considered this possibility and there is just not enough space for the board even without the standoffs.
I have sandwiched a Pimoroni NVMe Base between a 5" DSI screen and a Raspberry Pi 5 using 5mm standoffs. This is the minimum space. The uSD slot is touching the NMVe socket. I would prefer a large gap (but these are the standoffs I had).
A key advantage of @jofemodo’s suggestion is that it can provide thermal dissipation from the NMVe. We could also cut a door in the bottom of the case to access the M.2 slot (although this isn’t planned).
I see. But I wondered whether this could possibly fit into the current V5 kit.
I have not taken my V5 apart to see if there is space. I initially suggested this but was worried it may be too close to the screen. I have not tested that. The RPi5 does not fit the V5 case so I could not install to test (without cutting the case apart - which I don’t want to do).
Hello @zynthianers, @jofemodo, @riban
You might like to know that I have been able to istall and run consistenty Oram from nvme on Pi5 (Argon Neo 5 M.2 enclosure kit), with stable reboot from nvme0n1p2 partition.
I suspect that it may have come as a sort of fortunate mismatch, since I had to fully format my previous Oram burn on nvme using the Gparted app for RaspiOS. Not being sure as of the thoroughness of the new Oram clean install, I prudentially erased all existing nvme0n1p1 and nvme0n1p2 partitions, then recreated artificially an nvme0n1p1 partition.
At that point, I wasn’t allowed to dd the Oram img directly from CLI to nvme, as per the @riban’s steps (nvme partition 1 resulted not accessible), therefore I simply burned Oram 2024-06-26 on nvme with Imager.
Once correctly set the boot order via sudo raspi-config with nvme priority, I was finally able to startup Zynthian/Oram from nvme. The boot sequence presented the usual IP: Audio/Midi ERROR cycle, but I managed to connect from an external PC through webconf (Zynthian.local, pw: opensynth) and finally overcome the startup lock, setting audio to Generic USB and display to Generic HDMI with appropriate X-Y resolution, all of which worked perflecly with my Presonus Studio 26c USB audio and Arzopa Full-HD portable monitor.
Still wrapping my head around the different GUI usage through keyboard and mouse, but for now Oram works in a fantastic way on Pi5 +nvme. It is fast, responsive, clean and sharp in passing between windows, and the sampler section (Sfizz) feels like a huge step forward. It is solid, reliable, and with minimal latency changing samples in the library audition process. It affords overall a completely different and drammatically improved Linux rompler experience.
What is even more important, with my casual/improvised workaround, cmdline.txt remains true to the raspi-config settings, once the root drive has been edited with nano, and it does not revert to booting from SD when a change is made in webconf.
There is a strange but apparently useful Oram behaviour that I noticed so far, but I have just started to scratch the surface with a simple snapshot: if I plug an USB peripheral into the Raspi5, Zynthian self-reboots and restarts with the new added USB device available.
Greetings to everybody!
2 Likes
This should not happen. If I plug in a USB keyboard then the keyboard works without any restart. I wonder whether the peripheral you plug in triggers a power surge? What is this mystery peripheral?
My RPi5 has been running fine with NVMe for a while now. I have changed the boot order to set uSD first which allows me to plug in a uSD for testing, e.g. new Oram image - and then return to my NVMe installation. This could be a good way to allow testing and stable on the same machine.
Hi! 
As a matter of fact, I did not expect Oram to successfully load at the first attempt, so I first set audio to dummy in webconf in order to complete the startup.
Thereafter, I set general HDMI and USB audio in hardware, then plugged-in the Presonus board with an ensuing reboot in mind, but Zynthian immediately self-rebooted without any further issues, with the new audio peripheral and correct display resolution readily available.
The same thing happened when I connected an USB midi keyboard: self-restart with fully working reboot.
It is indeed a clever idea to have both stable and testing versions, or two Oram development stages, on SD and nvme. I guess that in order to switch OS I would have to SSH into the Zynthian from the external PC, and perform raspi-config to change the boot sequence, right? (unless there is a keyboard shortcut at the Raspi startup to switch on-the-fly between different drives…).
It looks like a power issue. I can freely connect and disconnect USB devices without the system restarting.
I just insert and remove the uSD. If I want to test, I put it in and if I want to use my stable NVMe, I remove the uSD. Simple! (Except the way I have mounted it makes access to the uSD slot awkward.)
1 Like
This is actually a practical and clever solution for a double boot Zynthian @riban. Not particularly convenient for me either, because my Argon Neo Pi5 box, for how sleek and sturdy it is, is practically a sort of impregnable aluminium bunker. I have to leave it unscrewed, and thus structurally unstable, if I want to easily access the SD holder!