the method that you provide did not work. What i did was to purchase a NVMe Encloseure and used a Windows PC to Reformat it. My Linux PC also cannot get it formated. After that I just follow your method to copy the image into the NVMe Drive and removed my MMc module. It just boot up as usual. This time round I will not re-write the Boot sect when I do Update & Upgrade.
SPI + NVMe booting(beta)
I am pretty certain you will get it perfect but yeah current design is likely to always give problems.
There are two things in action as the nvme drivers in u-boot are just basic compared to the kernel drivers.
So in boot from nvme there are compatibility problems due yo u-boot but kernel wise any nvme should work as long as it is nvme and not a sata ssd.
I have a Integral 120gb which is a Phison controller and it works. Never did the spi boot just sd card boot to root on nvme.
With ADT its just that cable there is more insulation between tracers and the better cable is also emi shielded (think its foil wrapped or outer is conductive and grounded).
You can always tell by color for some reason as the better is darker grey or black.
Dunno where your source it from but it is just better quality and removes 2 connectors out of the chain by soldering direct.
Then I think they just a a DC capacitor on vcc as close to the extender m.2 connector as possible to mitigate volt drop.
I think also its low oxygen high grade copper to stop volt drop with the usual gold plated connectors.
my own fault
SATA M.2 card have three connector notches while PCIe M.2 cards have only two.
Kingston 240GB A1000 SSD = two notches, does not work
M.2 module keying and provided interfaces
Key Notched Provided
ID Pins Interfaces
A 8–15 PCIe ×2, USB 2.0, I2C and DP ×4
B 12–19 PCIe ×2, SATA, USB 2.0 and 3.0, audio, UIM, HSIC, SSIC, I2C and SMBus
C 16–23 Reserved for future use
D 20–27 Reserved for future use
E 24–31 PCIe ×2, USB 2.0, I2C, SDIO, UART and PCM
F 28–35 Future Memory Interface (FMI)
G 39–46 Reserved for custom use (unused in the M.2 specification)
H 43–50 Reserved for future use
J 47–54 Reserved for future use
K 51–58 Reserved for future use
L 55–62 Reserved for future use
M 59–66 PCIe ×4, SATA and SMBus
M single key are pciex4
B+M key are pciex2
To confuse matters sata & nvme pciex2 both can have b+m keys
Also with single M key the is also a thing called a AHCI ssd m.2
The e key are for smaller wifi cards and such which the rockpi4 is not.
Yours is a Phison Pcie x2 nvme that may not uboot boot but is perfectly capable of being kernel compatible.
I am unsure to what work and what doesn’t with uboot but know it only has basic nvme drivers.
What you must not do is dd the image from install media do exactly as jack said copy the image to the rockpi4 and unpigz it in section 3.
Not sure about the compatibility problem but with some ssd due to the gpt layout of the image it gets corrupted if you image copy the original media device rather than take a fresh image and apply direct.
It prob got more to do with the tools that made the partition layout and gpt without backup gpt.
Prob better to use gdisk then write back or its some sort of block size mismatch or offset with the controller type.
Haven’t really worked it out as didn’t a nvme until the rockpi
A notch is the hole not the protruding bit.
sorry my very bad enlish, its been copy from wiki “connector notches”
XPG GAMMIX S5 PCIe Gen3x4 M.2 2280 512
https://www.adata.com/jo/specification/587
boot well when other pc flash .img to ssd
if try flash ssd in rockpi = kernel error
Works fine without SDcard, I am now happy, thanks for the code
…
Kingston 240GB A1000 SSD = PHISON PS5008-E8-10
does not read the kernel SPI (works with sdcard)
Samsung 250GB 970 EVO Plus SSD-levy, M.2 2280, PCIe 3.0 x4, NVMe, 3500/2300 MB/s
does not read the kernel SPI (works with sdcard)
when all works in NVME, can i modify hw_intfc.conf
-intfc:uart4=on
-intfc:spi1=off
-#intfc:dtoverlay=spi1-flash
yes, it woks…but uart4 is lost
both serial ports are really lost, uart2 do something in the boot even though fiq has been removed
edit:
pin 23, 24 ground and boot from sdcard, uart4 works
What are benefits of booting from SPI and not from uSD or eMMC?
From my point of view, the only benefit is saving some cost for the eMMC/uSD and maybe cooler. Actually spi booting is much slower than eMMC.
But I guess it is possible to purchase quite cheap, fast, little capacity SD + quite big NVMe SSD and boot from SD. And it would be pretty reliable and easier to maintain than flashing SPI with possibility of bricking Pi. Or am I wrong and SPI has some big-big advantages in particular cases?
The SPI flash is easy to manage since we can disable it on the GPIO header, so actually you can not brick the PI because of software.
Are there sources available somewhere for PCIe support in u-boot?
I tested the u-boot on my Rock Pi 4B, and noticed that my 16GB Optane drive
crashes the u-boot. I wonder if I could find a way to fix it. The same drive
works fine on every linux distro.
Hi ayufanpl! I’m your fun from Pine64 community and enjoying your custom build rom, welcome to radxa forum.
I’m surprised you can use Optane ssd in ARM64 SBC, I thought Optane only supported in Intel chipset. But I’m looking forward someone can make it work in RK3399
It behaves exactly the same as regular nvme drive. I bought this el cheapo (sometimes it is possible to find them for like 5$ when on discount) to try have something to test easily, and do not use Samsungs P961 and maybe brick it
These Optanes are x2 only, so max around 600MB/s. Still quite good.
That’s great, optane has very low latency and high durability, I’ll trying to get one for test. And FYI Optane M15 will be out soon, and it’s PCIE 4x and much higher IOPS.
The source code is not public yet since it’s buggy. We will push it to github after some cleaning if it’s helpful to you.
Thanks, this would be awesome. I could cross check that with other PCIE implementations. I think pushing additional branch on https://github.com/radxa/u-boot would be helpful.
I hope that we switch as well to mainline u-boot.
Hi, @ayufanpl
We have pushed one additional branch that supports SPI NVME booting. See
repository: https://github.com/radxa/u-boot.git
branch : rk3399-pie-gms-express-baseline
Thanks. This is awesome. I will not have time to look at this, this week, but will look next one.
Cool! I’ll try to build my own u-boot!
In the meantime I can report the Intel 660p 1TB NVMe SSD as working for SPI + NVMe boot.
(Yes, I’m 2 months late ;))
Update: It seem’s I’m having issues rebooting. After I type:
root@localhost:~# reboot
systemd does its thing and then the machine hangs at:
[ OK ] Stopped LVM2 metadata daemon.
[ 34.280526] dw_wdt: unexpected close, system will reboot soon
[ 34.563789] reboot: Restarting system
But it does not actually reboot. This worked before (with eMMC-boot). I don’t know if this an issue from the new u-boot or something else.