[Raspberry Pi 5] SanDisk Ultra NVMe 3D 1TB not detected – Phison/WD controller incompatibility despite latest firmware

[tototomate123]

Describe the bug

My SanDisk Ultra M.2 NVMe 3D 1TB SSD is not detected at all on the Raspberry Pi 5, using the Geekworm X1001 PCIe to NVMe adapter. It does not appear in lspci, dmesg, or /dev/nvme*, even though it receives power and the adapter's ACT LED is on.

This seems related to known compatibility issues with certain Phison- or WD-based controllers which may not support PCIe Gen 2 fallback properly.

---

To reproduce

1. Connect SanDisk Ultra NVMe SSD to Geekworm X1001 adapter
2. Install latest EEPROM firmware (March 19, 2025)
3. Set the following configuration:

boot.conf:

[all]
BOOT_UART=1
BOOT_ORDER=0xf461
NET_INSTALL_AT_POWER_ON=1
POWER_OFF_ON_HALT=1
PCIE_PROBE=1

config.txt:

[all]
dtoverlay=pcie
dtparam=pciex1_gen=3

4. Remove SD card to attempt NVMe boot
5. Observe HDMI output or run lspci after fallback to SD boot

---

Expected behaviour

The NVMe SSD should be detected by the bootloader and accessible by Linux (either for boot or as a block device).

---

Actual behaviour

SSD is not detected by the bootloader or kernel at all. PCIe link seems active (adapter powered, ACT LED on & SSD gets warm), but no device is shown.

---

System

• Raspberry Pi 5 (8 GB)
• Raspberry Pi OS 64-bit (Bookworm)
• vcgencmd version: Mar 19 2025 17:10:37
• uname -a: Linux raspberrypi 6.6.20+rpt-rpi-v8 libilclient.a in hardffp not hardfp firmware#1 SMP PREEMPT Debian 1:6.6.20-1+rpt1 (2024-03-19) aarch64 GNU/Linux

---

Logs

Boot HDMI output:

Failed to open device: 'nvme'
PCIe timeout: 0x0001e08f

lspci output:

0002:00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2712 PCIe Bridge (rev 30)
0002:01:00.0 Ethernet controller: Raspberry Pi Ltd RP1 PCIe 2.0 South Bridge

---

Additional context

The SSD likely uses a Phison or rebranded WD controller. Based on other user reports (e.g. SN550/SN580/SN740), these controllers often fail Gen 2 fallback and require firmware quirks. Other users have reported success only after EEPROM fixes, which sadly doesnt work for me as of right now.

Would it be possible to add support or further compatibility workarounds for this type of SSD in future EEPROM updates?

Happy to test and provide more logs if needed. Thanks!

[timg236]

Moved to rpi-eeprom.

Keeping issue here for interop but at present I think implementing drive specific quirks is likely to be "won't fix" right now.

[tototomate123]

Thanks for the reply - totally understandable that adding per-drive quirks isnt something you want to maintain long-term.

That said, I figured I’d at least ask, since Ive basically tried everything:

I dont expect full support for my specific SanDisk model, but maybe there is some low-level option or experimental workaround I could try? Even just a delay, or debug flag, or more verbose logging?

If its truly out of scope, fair enough - but figured its worth asking before I give up on this SSD.

[lurch]

config.txt:

[all]
dtoverlay=pcie
dtparam=pciex1_gen=3

This may or may not help your problem, but looking at https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README#L365 suggests that the pcie option is for 2711 only (i.e. Raspberry Pi 4), and for 2712 (i.e. Raspberry Pi 5) you ought to be using pciex1 ? (See also https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#enable-pcie )

[tototomate123]

https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README#L365 suggests that the pcie option is for 2711 only (i.e. Raspberry Pi 4), and for 2712 (i.e. Raspberry Pi 5) you ought to be using pciex1 ?

Sadly, that did not fix it, but I bought a new SSD (Crucial P3 Plus), and that works great.
Thanks for all the help!

[timg236]

Thanks for the reply - totally understandable that adding per-drive quirks isnt something you want to maintain long-term.

That said, I figured I’d at least ask, since Ive basically tried everything:

I dont expect full support for my specific SanDisk model, but maybe there is some low-level option or experimental workaround I could try? Even just a delay, or debug flag, or more verbose logging?

If its truly out of scope, fair enough - but figured its worth asking before I give up on this SSD.

There's currently no configurable delays (bootcode_delay is after the file-system). You could force retries of NVMe by changing the boot-order e.g. 0xf1666 - try NVMe three times before SD