Ok, ive tried raspbian, and ubuntu, latest updates for both. Ive tried a rocket and an mp33 pro. Started with a nicer usbc power supply, switched to the 5.1v 5a official.
After waiting for an update one night, on ubuntu, was super surprised to see the mp33 show up in gnome drive utiility. But i was 3 days into trying to get the base working. 6 hours that night. I woke up the next day and came back to it and it was not showing up, again.
Ive read that power seems to be an issue for some. What im considering is adding more power too it. I have a usb c pigtail i want to solder to it to give it the power it needs to run the nvme drive properly. I see what looks like a smd barrel plug pattern on the board, would this be acceptable to throw extra power onto via a usb pigtail?
I strongly suspect that the ribbon cable can handle the data just fine but maybe not the power.
The answer to your power via those pads, is in there. It doesn’t say which one is 5V and which one is ground though? My NVMe base doesn’t have those holes, it has surface mount pads. 4 pads which makes me think mine is setup for something like this.
Yes, this a standard JST-PH2 connector. And this one is easy to hand-solder.
Nevertheless, I would not bet on power as the problem. You might have power-problems during very heavy use, but your real problem is that the drive is not showing up. This sounds more like a timeout problem.
Can you please post the output of the following commands:
sudo rpi-eeprom-config
sudo rpi-eeprom-update
And if your nvme is visible, also post the output of
sudo journalctl -b -g pcie
Note that the last command will probably be of no help if the nvme does not show up in the first place.
Ahhh yeah, sorry, i had kinda gathered some of this in my reading already. Im after someone from pimoroni to confirm. I suspect we will find out what goes on those pads when that answer is provided.
The biggest reason i posted the question, is because idk if using a secondary power on the nvme base would cause problems. Or even if it would get power to the right places.
cowboy@RaspberryPi5:~$ sudo rpi-eeprom-config
[sudo] password for cowboy:
[all]
BOOT_UART=1
POWER_OFF_ON_HALT=0
BOOT_ORDER=0xf416
PCIE_PROBE=1
cowboy@RaspberryPi5:~$ sudo rpi-eeprom-update
BOOTLOADER: up to date
CURRENT: Mon Sep 25 10:44:03 UTC 2023 (1695638643)
LATEST: Mon Sep 25 10:44:03 UTC 2023 (1695638643)
RELEASE: default (/lib/firmware/raspberrypi/bootloader-2712/default)
Use raspi-config to change the release.
This is a really old EEPROM/Firmware version. I’d recommend downloading a recent version of RPi Imager, installing a recent RPi OS fresh to an SD card, then updating the RPi 5 EEPROM from there until the EEPROM/firmware shows Dec 6 2023 or later. Then you might have more success, or at least rule out software issues.
I would really recommend that you update your instructions in the shop: running sudo rpi-eeprom-update is not sufficient, you must also run sudo raspi-config and select the newest firmware.
@bablokb The default firmware is now Jan 5th, so vanilla update should get you something that works. I’ve added the extra step on the product page anyway to help people get to a good place :-)
Ive tried to run the update in both os. Not updateing. Though in raspbian it shows that 1/5/24 update is there. I tried runnung the update via usb, but i have to dig out another microsd to do ot thst way. My 3d printer ate up all my sd cards. I think i have a few old ones stashed in a drawer. Will try in a few hours. I guess the biggest issue is for me, i thought that i was up to date, cause it kept showing that 1.5.24 and i didnt understand that the thing was not actually pushing the update to me.
Another thing to try: take out the SD-card and reboot. With your BOOT_ORDER=0xf416 setting, it should try the NVME, then the (non-existent SD), then USB, then loop. This should give you some time to see the messages on the screen. For a screenshot, you need a camera/smartphone.
Ok… Last try: add PCIE_PROBE=1 to your eeprom-configuration (sudo rpi-eeprom-config --edit). This should not be necessary, but I am long enough in IT to know that theory and practice are two different things.
If this does not work, you have one of these combinations of Pi5, cable, NVME-base, SSD that just don’t communicate.
I just got nvme base and I have exact same problem, followed all the steps above with no results.
My setup RPI 8GB
pimoroni base
Patriot 300 - 256GB nvme drive
or another 1TB WD don’t know which one as it is missing the label
I did update the kernel to the latest and selected the latest in sudo rpi-eeprom-config --edit
Original RPI 27W power supply
sudo lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
mmcblk0 179:0 0 29.1G 0 disk
├─mmcblk0p1 179:1 0 512M 0 part /boot/firmware
└─mmcblk0p2 179:2 0 28.6G 0 part /
-----------------------------------
sudo rpi-eeprom-config
[all]
BOOT_UART=1
POWER_OFF_ON_HALT=0
BOOT_ORDER=0xf461
PCIE_PROBE=1
-----------------------------------
sudo rpi-eeprom-update
BOOTLOADER: up to date
CURRENT: Fri 5 Jan 15:57:40 UTC 2024 (1704470260)
LATEST: Fri 5 Jan 15:57:40 UTC 2024 (1704470260)
RELEASE: latest (/lib/firmware/raspberrypi/bootloader-2712/latest)
Use raspi-config to change the release.
---------------------------------------------------------
sudo journalctl -b -g pcie
Jan 24 19:07:10 rpi kernel: Kernel command line: coherent_pool=1M 8250.nr_uarts=1 pci=pcie_bus_safe snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 smsc95xx.macaddr=D8:3A:DD:D1:82:CC vc_mem.mem_base=0x3fc00000 vc_mem.mem_size=0x40000000 console=ttyAMA10,115200 console=tty1 root=P>
Jan 24 19:07:10 rpi kernel: brcm-pcie 1000110000.pcie: host bridge /axi/pcie@110000 ranges:
Jan 24 19:07:10 rpi kernel: brcm-pcie 1000110000.pcie: No bus range found for /axi/pcie@110000, using [bus 00-ff]
Jan 24 19:07:10 rpi kernel: brcm-pcie 1000110000.pcie: MEM 0x1b00000000..0x1bfffffffb -> 0x0000000000
Jan 24 19:07:10 rpi kernel: brcm-pcie 1000110000.pcie: MEM 0x1800000000..0x1affffffff -> 0x0400000000
Jan 24 19:07:10 rpi kernel: brcm-pcie 1000110000.pcie: IB MEM 0x0000000000..0x0fffffffff -> 0x1000000000
Jan 24 19:07:10 rpi kernel: brcm-pcie 1000110000.pcie: setting SCB_ACCESS_EN, READ_UR_MODE, MAX_BURST_SIZE
Jan 24 19:07:10 rpi kernel: brcm-pcie 1000110000.pcie: Forcing gen 2
Jan 24 19:07:10 rpi kernel: brcm-pcie 1000110000.pcie: PCI host bridge to bus 0000:00
Jan 24 19:07:10 rpi kernel: brcm-pcie 1000110000.pcie: link down
Jan 24 19:07:10 rpi kernel: pcieport 0000:00:00.0: PME: Signaling with IRQ 39
Jan 24 19:07:10 rpi kernel: pcieport 0000:00:00.0: AER: enabled with IRQ 39
Jan 24 19:07:10 rpi kernel: brcm-pcie 1000120000.pcie: host bridge /axi/pcie@120000 ranges:
Jan 24 19:07:10 rpi kernel: brcm-pcie 1000120000.pcie: No bus range found for /axi/pcie@120000, using [bus 00-ff]
Jan 24 19:07:10 rpi kernel: brcm-pcie 1000120000.pcie: MEM 0x1f00000000..0x1ffffffffb -> 0x0000000000
Jan 24 19:07:10 rpi kernel: brcm-pcie 1000120000.pcie: MEM 0x1c00000000..0x1effffffff -> 0x0400000000
Jan 24 19:07:10 rpi kernel: brcm-pcie 1000120000.pcie: IB MEM 0x1f00000000..0x1f003fffff -> 0x0000000000
Jan 24 19:07:10 rpi kernel: brcm-pcie 1000120000.pcie: IB MEM 0x0000000000..0x0fffffffff -> 0x1000000000
Jan 24 19:07:10 rpi kernel: brcm-pcie 1000120000.pcie: setting SCB_ACCESS_EN, READ_UR_MODE, MAX_BURST_SIZE
Jan 24 19:07:10 rpi kernel: brcm-pcie 1000120000.pcie: Forcing gen 2
Jan 24 19:07:10 rpi kernel: brcm-pcie 1000120000.pcie: PCI host bridge to bus 0001:00
Jan 24 19:07:10 rpi kernel: brcm-pcie 1000120000.pcie: link up, 5.0 GT/s PCIe x4 (!SSC)
Jan 24 19:07:10 rpi kernel: pcieport 0001:00:00.0: enabling device (0000 -> 0002)
Jan 24 19:07:10 rpi kernel: pcieport 0001:00:00.0: PME: Signaling with IRQ 40
Jan 24 19:07:10 rpi kernel: pcieport 0001:00:00.0: AER: enabled with IRQ 40
Jan 24 19:07:10 rpi kernel: input: MOSART Semi. 2.4G Keyboard Mouse as /devices/platform/axi/1000120000.pcie/1f00300000.usb/xhci-hcd.1/usb3/3-1/3-1:1.0/0003:062A:4101.0001/input/input1
Jan 24 19:07:10 rpi kernel: input: MOSART Semi. 2.4G Keyboard Mouse as /devices/platform/axi/1000120000.pcie/1f00300000.usb/xhci-hcd.1/usb3/3-1/3-1:1.1/0003:062A:4101.0002/input/input4
Jan 24 19:07:10 rpi kernel: input: MOSART Semi. 2.4G Keyboard Mouse Consumer Control as /devices/platform/axi/1000120000.pcie/1f00300000.usb/xhci-hcd.1/usb3/3-1/3-1:1.1/0003:062A:4101.0002/input/input5
Jan 24 19:07:10 rpi kernel: input: MOSART Semi. 2.4G Keyboard Mouse System Control as /devices/platform/axi/1000120000.pcie/1f00300000.usb/xhci-hcd.1/usb3/3-1/3-1:1.1/0003:062A:4101.0002/input/input6
Jan 24 19:07:10 rpi kernel: input: MOSART Semi. 2.4G Keyboard Mouse as /devices/platform/axi/1000120000.pcie/1f00300000.usb/xhci-hcd.1/usb3/3-1/3-1:1.1/0003:062A:4101.0002/input/input7
Jan 24 19:07:11 rpi mtp-probe[392]: checking bus 3, device 2: "/sys/devices/platform/axi/1000120000.pcie/1f00300000.usb/xhci-hcd.1/usb3/3-1"
Jan 24 19:07:16 rpi ModemManager[859]: <info> [base-manager] couldn't check support for device '/sys/devices/platform/axi/1000120000.pcie/1f00100000.ethernet': not supported by any plugin
Jan 24 19:09:45 rpi sudo[5475]: alex : TTY=pts/0 ; PWD=/home/alex ; USER=root ; COMMAND=/usr/bin/journalctl -b -g pcie
@alex049
It must be frustrating I know. So far I have been pretty lucky, the only outright failures I have had, have been on the WD drives, so as @guru suggests best to stay clear of them.
So far I have been initializing my drives on the PC using RPI Imager and then moving to the PI setup as the boot drive (verifies the drive is working at least). Not tried initializing a drive while plugged into the pi.
While setting things up the first time I found it helped to have the PI and NVMe base side by side to check orientation of cable and if the cable is seated (it took me a few goes to get right first time) . Also allows changing the drive easy.
Regards
