Test Pineberry Pi's HatDrive! Top and Bottom NVMe HATs

[geerlingguy]

Pineberry Pi is a joint venture between Michał Gapiński and Mirosław Folejewski — both of whom have a history of making some pretty cool Pi products.

They just announced their "HatDrive!" Line of HATs (one for the top, one for the bottom) for the Raspberry Pi 5.

I have one of each and will be testing it, along with their impedance-controlled FFCs (they make two lengths):

• HatDrive! Top for 2230/2242 M.2 E-key
• HatDrive! Bottom for 2230/2242/2280 M.2 E-key

I should also redirect the page https://pipci.jeffgeerling.com/hats/mirko-hat5m1-hat.html to these new HAT pages. See #550

[darkmanlv]

Bought SN520 256gb, also not working. Don`t even boot with it installed.

So my not working list so far with Hat! Top, can be added to compatibility list on wiki.

WD SN740, size 2230, not detected after boot from sd card Union Memory, size 2242, not detected after boot from sd card WD SN520, size 2230, not booting from sd card at all, stay freezed with green led ON

PS: all of them working with usb to nvme adapter from aliexpress

[slagathor69]

@geerlingguy

How is the 5V power input on the 'Bottom' version of the board to be used? Will some sort of adapter cable be included?

@mikegapinski

1. We'll stock it but I have not found a device that needs it yet. We are playing it safe in case someone needs it, that is why we have power monitoring in the first place.

I can't get Samsung 990 PRO w/ Heatsink PCIe 4.0 NVMe SSD 4TB to work with HatDrive! Bottom. This may be the first drive that needs the additional power, where can I order this?

To be clear my Samsung 990 PRO w/ Heatsink PCIe 4.0 NVMe SSD 4TB works fine on my PC and even lights up when connected via HatDrive! Bottom but is never recognized by Pi even after changing dtparam settings. Formatting is ext4

[grching]

@geerlingguy

How is the 5V power input on the 'Bottom' version of the board to be used? Will some sort of adapter cable be included?

@mikegapinski

1. We'll stock it but I have not found a device that needs it yet. We are playing it safe in case someone needs it, that is why we have power monitoring in the first place.

I can't get Samsung 990 PRO w/ Heatsink PCIe 4.0 NVMe SSD 4TB to work with HatDrive! Bottom. This may be the first drive that needs the additional power, where can I order this?

I've tried the same device minus the heat sink. Same issue the drive works via m.2 USB interface and even with a USB SSD adapter. So the Samsung 990 Pro works just fine on with the RPI 5.

The issue with the Pineberry Pi bottom could be either power (amps) or it could be a timing issue. I am trying to find the TTR (Time To Ready) for this device but I haven't found it yet. So it would be nice to understand how Pineberry Pi handles long TTR. I was hoping also that the RPI 5 could adjust it's polling for longer TTR devices (if possible).

I would also be interested in the power adapter too. Where does it plug into? the RPI GPIO pins or another power supply?

Currently I am using a Samsung 980 Pro + Heatsink with the Pineberry Pi Bottom and dtparam=pciex1_gen=3.

 Category                  Test                      Result     

HDParm Disk Read 794.64 MB/sec
HDParm Cached Disk Read 799.82 MB/sec
DD Disk Write 393 MB/s
FIO 4k random read 208979 IOPS (835918 KB/s) FIO 4k random write 72624 IOPS (290496 KB/s) IOZone 4k read 250424 KB/s
IOZone 4k write 178752 KB/s
IOZone 4k random read 80246 KB/s
IOZone 4k random write 192946 KB/s

                      Score: 46442      

[codebuk]

Samsung 990 PRO 1T works intermittently for me with bottom hat. I have been testing external 5V on the bottom hat. The hat works with other drives.

Video output is also intermittent.

Unfortunately the 5V power connection on the PI hat also back powers the PI.

Any suggestions welcome.

Bad boot:

[14:43:12.200] RPi: BOOTLOADER release VERSION:e891ded6 DATE: 2024/01/22 TIME: 14:44:36 [14:43:12.207] BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1705934676 serial edc8bb12 boardrev c04170 stc 4530236 [14:43:12.216] AON_RESET: 00000003 PM_RSTS 00001000 [14:43:12.240] usb_pd_init status 3 [14:43:12.244] USB_PD CONFIG 0 41 [14:43:12.245] XHCI-STOP [14:43:12.247] xHC0 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d [14:43:12.253] USBSTS 11 [14:43:12.253] xHC0 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d [14:43:12.258] xHC0 ports 3 slots 64 intrs 4 [14:43:12.268] XHCI-STOP [14:43:12.270] xHC1 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d [14:43:12.274] USBSTS 11 [14:43:12.275] xHC1 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d [14:43:12.279] xHC1 ports 3 slots 64 intrs 4 [14:43:12.283] Boot mode: NVME (06) order f14 [14:43:12.465] USB2[2] 00020ae1 connected [14:43:12.496] USB2[1] 00020ae1 connected [14:43:12.526] USB-PD: src-cap PDO object1 0x0a11912c [14:43:12.530] Current 3000 mA [14:43:12.531] Voltage 5000 mV [14:43:12.533] USB-PD: src-cap PDO object2 0x0012d12c [14:43:12.536] Current 3000 mA [14:43:12.537] Voltage 9000 mV [14:43:12.540] USB-PD: src-cap PDO object3 0x0014b12c [14:43:12.542] Current 3000 mA [14:43:12.544] Voltage 15000 mV [14:43:12.545] USB-PD: src-cap PDO object4 0x00164145 [14:43:12.549] Current 3250 mA [14:43:12.552] Voltage 20000 mV [14:43:12.553] USB2[2] 00200a03 connected enabled [14:43:12.557] USB2 root HUB port 2 init [14:43:12.558] USB2[1] 00200a03 connected enabled [14:43:12.562] USB2 root HUB port 1 init [14:43:12.564] DEV [01:00] 2.00 000000:02 class 0 VID 17ef PID 6019 [14:43:12.568] DEV [01:00] 1.16 000000:01 class 0 VID 413c PID 2107 [14:43:12.577] HID [01:00] 2.00 000000:02 register HID [14:43:12.580] HID [01:00] 1.16 000000:01 register HID [14:43:13.049] PCI1 init [14:43:13.050] PCI1 reset [14:43:13.105] PCIe scan 0000144d:0000a80c [14:43:18.108] Timeout 00000000 00000000 00000000 00000000

Good example with a SAMSUNG MZVLB256HBHQ-000L7 :

[16:40:03.992] RPi: BOOTLOADER release VERSION:e891ded6 DATE: 2024/01/22 TIME: 14:44:36 [16:40:03.998] BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1705934676 serial edc8bb12 boardrev c04170 stc 4552407 [16:40:04.008] AON_RESET: 00000003 PM_RSTS 00001000 [16:40:04.032] usb_pd_init status 3 [16:40:04.033] USB_PD CONFIG 0 41 [16:40:04.038] XHCI-STOP [16:40:04.039] xHC0 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d [16:40:04.044] USBSTS 11 [16:40:04.044] xHC0 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d [16:40:04.050] xHC0 ports 3 slots 64 intrs 4 [16:40:04.059] XHCI-STOP [16:40:04.059] xHC1 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d [16:40:04.065] USBSTS 11 [16:40:04.066] xHC1 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d [16:40:04.071] xHC1 ports 3 slots 64 intrs 4 [16:40:04.075] Boot mode: NVME (06) order f14 [16:40:04.258] USB2[2] 00020ae1 connected [16:40:04.289] USB2[1] 00020ae1 connected [16:40:04.318] USB-PD: src-cap PDO object1 0x0a11912c [16:40:04.321] Current 3000 mA [16:40:04.322] Voltage 5000 mV [16:40:04.325] USB-PD: src-cap PDO object2 0x0012d12c [16:40:04.328] Current 3000 mA [16:40:04.329] Voltage 9000 mV [16:40:04.330] USB-PD: src-cap PDO object3 0x0014b12c [16:40:04.335] Current 3000 mA [16:40:04.336] Voltage 15000 mV [16:40:04.337] USB-PD: src-cap PDO object4 0x00164145 [16:40:04.341] Current 3250 mA [16:40:04.343] Voltage 20000 mV [16:40:04.344] USB2[2] 00200a03 connected enabled [16:40:04.347] USB2 root HUB port 2 init [16:40:04.349] USB2[1] 00200a03 connected enabled [16:40:04.352] USB2 root HUB port 1 init [16:40:04.355] DEV [01:00] 2.00 000000:02 class 0 VID 17ef PID 6019 [16:40:04.360] DEV [01:00] 1.16 000000:01 class 0 VID 413c PID 2107 [16:40:04.367] HID [01:00] 2.00 000000:02 register HID [16:40:04.373] HID [01:00] 1.16 000000:01 register HID [16:40:04.841] PCI1 init [16:40:04.842] PCI1 reset [16:40:04.899] PCIe scan 0000144d:0000a808 [16:40:04.965] VID 0x144d MN SAMSUNG MZVLB256HBHQ-000L7
[16:40:05.111] NVME on [16:40:05.112] MBR: 0x00002000, 1048576 type: 0x0c [16:40:05.115] MBR: 0x00102000,499061424 type: 0x83 [16:40:05.118] MBR: 0x00000000, 0 type: 0x00 [16:40:05.122] MBR: 0x00000000, 0 type: 0x00 [16:40:05.124] Trying partition: 0 [16:40:05.127] type: 32 lba: 8192 'mkfs.fat' ' bootfs ' clusters 261116 (4) [16:40:05.132] rsc 32 fat-sectors 2040 root dir cluster 2 sectors 0 entries 0 [16:40:05.138] FAT32 clusters 261116 [16:40:05.140] [nvme] autoboot.txt not found [16:40:05.143] Select partition rsts 0 C(boot_partition) 0 EEPROM config 0 result 0 [16:40:05.149] Trying partition: 0 [16:40:05.150] type: 32 lba: 8192 'mkfs.fat' ' bootfs ' clusters 261116 (4) [16:40:05.157] rsc 32 fat-sectors 2040 root dir cluster 2 sectors 0 entries 0 [16:40:05.162] FAT32 clusters 261116 [16:40:05.163] Read config.txt bytes 1213 hnd 0x126 [16:40:05.168] [nvme] pieeprom.upd not found [16:40:05.311] usb_max_current_enable default 0 max-current 3000 [16:40:05.319] Read bcm2712-rpi-5-b.dtb bytes 75197 hnd 0xc9d2 [16:40:05.323] dt-match: compatible: raspberrypi,5-model-b match: brcm,bcm2712 [16:40:05.330] dt-match: compatible: brcm,bcm2712 match: brcm,bcm2712 [16:40:05.334] Selecting USB low current limit

[16:40:10.985] NOTICE: BL31: v2.6(release):v2.6-239-g2a9ede0bd [16:40:10.990] NOTICE: BL31: Built : 14:26:57, Jun 22 2023

[16:40:22.330] Debian GNU/Linux 12 zbmvme ttyAMA10

[16:40:22.334] zbmvme login:

Successful boot with 5V power applied to bottom hat:

[17:05:44.681] RPi: BOOTLOADER release VERSION:e891ded6 DATE: 2024/01/22 TIME: 14:44:36 [17:05:44.688] BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1705934676 serial edc8bb12 boardrev c04170 stc 4530360 [17:05:44.698] AON_RESET: 00000003 PM_RSTS 00000020 [17:05:44.722] usb_pd_init status 3 [17:05:44.725] USB_PD CONFIG 0 43 [17:05:44.729] XHCI-STOP [17:05:44.730] xHC0 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d [17:05:44.735] USBSTS 11 [17:05:44.737] xHC0 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d [17:05:44.741] xHC0 ports 3 slots 64 intrs 4 [17:05:44.750] XHCI-STOP [17:05:44.750] xHC1 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d [17:05:44.756] USBSTS 11 [17:05:44.757] xHC1 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d [17:05:44.762] xHC1 ports 3 slots 64 intrs 4 [17:05:44.766] Boot mode: NVME (06) order f14 [17:05:44.949] USB2[2] 00020ae1 connected [17:05:44.979] USB2[1] 00020ae1 connected [17:05:45.009] USB2[2] 00200a03 connected enabled [17:05:45.012] USB2 root HUB port 2 init [17:05:45.015] DEV [01:00] 2.00 000000:02 class 0 VID 17ef PID 6019 [17:05:45.026] HID [01:00] 2.00 000000:02 register HID [17:05:45.030] USB2[1] 00200a03 connected enabled [17:05:45.032] USB2 root HUB port 1 init [17:05:45.035] DEV [01:00] 1.16 000000:01 class 0 VID 413c PID 2107 [17:05:45.047] HID [01:00] 1.16 000000:01 register HID [17:05:45.509] PCI1 init [17:05:45.510] PCI1 reset [17:05:45.566] PCIe scan 0000144d:0000a80c [17:05:45.568] VID 0x144d MN Samsung SSD 990 PRO 1TB
[17:05:45.713] NVME on [17:05:45.714] MBR: 0x00002000, 1048576 type: 0x0c [17:05:45.717] MBR: 0x00102000,1952468400 type: 0x83 [17:05:45.721] MBR: 0x00000000, 0 type: 0x00 [17:05:45.724] MBR: 0x00000000, 0 type: 0x00 [17:05:45.728] Trying partition: 0 [17:05:45.729] type: 32 lba: 8192 'mkfs.fat' ' bootfs ' clusters 261116 (4) [17:05:45.734] rsc 32 fat-sectors 2040 root dir cluster 2 sectors 0 entries 0 [17:05:45.741] FAT32 clusters 261116 [17:05:45.743] [nvme] autoboot.txt not found [17:05:45.745] Select partition rsts 0 C(boot_partition) 0 EEPROM config 0 result 0 [17:05:45.752] Trying partition: 0 [17:05:45.753] type: 32 lba: 8192 'mkfs.fat' ' bootfs ' clusters 261116 (4) [17:05:45.759] rsc 32 fat-sectors 2040 root dir cluster 2 sectors 0 entries 0 [17:05:45.764] FAT32 clusters 261116 [17:05:45.767] Read config.txt bytes 1213 hnd 0x126 [17:05:45.771] [nvme] pieeprom.upd not found [17:05:45.914] usb_max_current_enable default 0 max-current 3000 [17:05:45.922] Read bcm2712-rpi-5-b.dtb bytes 75197 hnd 0x1048f [17:05:45.926] dt-match: compatible: raspberrypi,5-model-b match: brcm,bcm2712 [17:05:45.933] dt-match: compatible: brcm,bcm2712 match: brcm,bcm2712 [17:05:45.937] Selecting USB low current limit

[17:05:51.614] NOTICE: BL31: v2.6(release):v2.6-239-g2a9ede0bd [17:05:51.618] NOTICE: BL31: Built : 14:26:57, Jun 22 2023

[17:06:03.185] Debian GNU/Linux 12 zbmvme990pro ttyAMA10

[17:06:03.189] zbmvme990pro login:

[mikegapinski]

The power connector on the bottom board is not meant to be used with an external power supply, it is meant to be wired to the 5V GPIO pins. We are removing it from a future revision - it is not necessary and we put it there before we had our hands on the first pi5

The Samsung 990 is also tricky on other HATs as far as I know

Wysyłane z aplikacji Outlook dla systemu iOShttps://aka.ms/o0ukef

---

Od: Dan Tyrrell @.> Wysłane: Sunday, January 28, 2024 2:25:06 AM Do: geerlingguy/raspberry-pi-pcie-devices @.> DW: Michał Gapiński @.>; Mention @.> Temat: Re: [geerlingguy/raspberry-pi-pcie-devices] Test Pineberry Pi's HatDrive! Top and Bottom NVMe HATs (Issue #559)

Samsung 990 PRO 1T works intermittently for me with bottom hat. I have been testing external 5V on the bottom hat. The hat works with other drives.

Video output is also intermittent.

Unfortunately the 5V power connection on the PI hat also back powers the PI.

Any suggestions welcome.

Bad boot:

[14:43:12.200] RPi: BOOTLOADER release VERSION:e891ded6 DATE: 2024/01/22 TIME: 14:44:36 [14:43:12.207] BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1705934676 serial edc8bb12 boardrev c04170 stc 4530236 [14:43:12.216] AON_RESET: 00000003 PM_RSTS 00001000 [14:43:12.240] usb_pd_init status 3 [14:43:12.244] USB_PD CONFIG 0 41 [14:43:12.245] XHCI-STOP [14:43:12.247] xHC0 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d [14:43:12.253] USBSTS 11 [14:43:12.253] xHC0 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d [14:43:12.258] xHC0 ports 3 slots 64 intrs 4 [14:43:12.268] XHCI-STOP [14:43:12.270] xHC1 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d [14:43:12.274] USBSTS 11 [14:43:12.275] xHC1 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d [14:43:12.279] xHC1 ports 3 slots 64 intrs 4 [14:43:12.283] Boot mode: NVME (06) order f14 [14:43:12.465] USB2[2] 00020ae1 connected [14:43:12.496] USB2[1] 00020ae1 connected [14:43:12.526] USB-PD: src-cap PDO object1 0x0a11912c [14:43:12.530] Current 3000 mA [14:43:12.531] Voltage 5000 mV [14:43:12.533] USB-PD: src-cap PDO object2 0x0012d12c [14:43:12.536] Current 3000 mA [14:43:12.537] Voltage 9000 mV [14:43:12.540] USB-PD: src-cap PDO object3 0x0014b12c [14:43:12.542] Current 3000 mA [14:43:12.544] Voltage 15000 mV [14:43:12.545] USB-PD: src-cap PDO object4 0x00164145 [14:43:12.549] Current 3250 mA [14:43:12.552] Voltage 20000 mV [14:43:12.553] USB2[2] 00200a03 connected enabled [14:43:12.557] USB2 root HUB port 2 init [14:43:12.558] USB2[1] 00200a03 connected enabled [14:43:12.562] USB2 root HUB port 1 init [14:43:12.564] DEV [01:00] 2.00 000000:02 class 0 VID 17ef PID 6019 [14:43:12.568] DEV [01:00] 1.16 000000:01 class 0 VID 413c PID 2107 [14:43:12.577] HID [01:00] 2.00 000000:02 register HID [14:43:12.580] HID [01:00] 1.16 000000:01 register HID [14:43:13.049] PCI1 init [14:43:13.050] PCI1 reset [14:43:13.105] PCIe scan 0000144d:0000a80c [14:43:18.108] Timeout 00000000 00000000 00000000 00000000

Good example with a SAMSUNG MZVLB256HBHQ-000L7 :

[16:40:03.992] RPi: BOOTLOADER release VERSION:e891ded6 DATE: 2024/01/22 TIME: 14:44:36 [16:40:03.998] BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1705934676 serial edc8bb12 boardrev c04170 stc 4552407 [16:40:04.008] AON_RESET: 00000003 PM_RSTS 00001000 [16:40:04.032] usb_pd_init status 3 [16:40:04.033] USB_PD CONFIG 0 41 [16:40:04.038] XHCI-STOP [16:40:04.039] xHC0 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d [16:40:04.044] USBSTS 11 [16:40:04.044] xHC0 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d [16:40:04.050] xHC0 ports 3 slots 64 intrs 4 [16:40:04.059] XHCI-STOP [16:40:04.059] xHC1 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d [16:40:04.065] USBSTS 11 [16:40:04.066] xHC1 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d [16:40:04.071] xHC1 ports 3 slots 64 intrs 4 [16:40:04.075] Boot mode: NVME (06) order f14 [16:40:04.258] USB2[2] 00020ae1 connected [16:40:04.289] USB2[1] 00020ae1 connected [16:40:04.318] USB-PD: src-cap PDO object1 0x0a11912c [16:40:04.321] Current 3000 mA [16:40:04.322] Voltage 5000 mV [16:40:04.325] USB-PD: src-cap PDO object2 0x0012d12c [16:40:04.328] Current 3000 mA [16:40:04.329] Voltage 9000 mV [16:40:04.330] USB-PD: src-cap PDO object3 0x0014b12c [16:40:04.335] Current 3000 mA [16:40:04.336] Voltage 15000 mV [16:40:04.337] USB-PD: src-cap PDO object4 0x00164145 [16:40:04.341] Current 3250 mA [16:40:04.343] Voltage 20000 mV [16:40:04.344] USB2[2] 00200a03 connected enabled [16:40:04.347] USB2 root HUB port 2 init [16:40:04.349] USB2[1] 00200a03 connected enabled [16:40:04.352] USB2 root HUB port 1 init [16:40:04.355] DEV [01:00] 2.00 000000:02 class 0 VID 17ef PID 6019 [16:40:04.360] DEV [01:00] 1.16 000000:01 class 0 VID 413c PID 2107 [16:40:04.367] HID [01:00] 2.00 000000:02 register HID [16:40:04.373] HID [01:00] 1.16 000000:01 register HID [16:40:04.841] PCI1 init [16:40:04.842] PCI1 reset [16:40:04.899] PCIe scan 0000144d:0000a808 [16:40:04.965] VID 0x144d MN SAMSUNG MZVLB256HBHQ-000L7 [16:40:05.111] NVME on [16:40:05.112] MBR: 0x00002000, 1048576 type: 0x0c [16:40:05.115] MBR: 0x00102000,499061424 type: 0x83 [16:40:05.118] MBR: 0x00000000, 0 type: 0x00 [16:40:05.122] MBR: 0x00000000, 0 type: 0x00 [16:40:05.124] Trying partition: 0 [16:40:05.127] type: 32 lba: 8192 'mkfs.fat' ' bootfs ' clusters 261116 (4) [16:40:05.132] rsc 32 fat-sectors 2040 root dir cluster 2 sectors 0 entries 0 [16:40:05.138] FAT32 clusters 261116 [16:40:05.140] [nvme] autoboot.txt not found [16:40:05.143] Select partition rsts 0 C(boot_partition) 0 EEPROM config 0 result 0 [16:40:05.149] Trying partition: 0 [16:40:05.150] type: 32 lba: 8192 'mkfs.fat' ' bootfs ' clusters 261116 (4) [16:40:05.157] rsc 32 fat-sectors 2040 root dir cluster 2 sectors 0 entries 0 [16:40:05.162] FAT32 clusters 261116 [16:40:05.163] Read config.txt bytes 1213 hnd 0x126 [16:40:05.168] [nvme] pieeprom.upd not found [16:40:05.311] usb_max_current_enable default 0 max-current 3000 [16:40:05.319] Read bcm2712-rpi-5-b.dtb bytes 75197 hnd 0xc9d2 [16:40:05.323] dt-match: compatible: raspberrypi,5-model-b match: brcm,bcm2712 [16:40:05.330] dt-match: compatible: brcm,bcm2712 match: brcm,bcm2712 [16:40:05.334] Selecting USB low current limit

[16:40:10.985] NOTICE: BL31: v2.6(release):v2.6-239-g2a9ede0bd [16:40:10.990] NOTICE: BL31: Built : 14:26:57, Jun 22 2023

[16:40:22.330] Debian GNU/Linux 12 zbmvme ttyAMA10

[16:40:22.334] zbmvme login:

Successful boot with 5V power applied to bottom hat:

[17:05:44.681] RPi: BOOTLOADER release VERSION:e891ded6 DATE: 2024/01/22 TIME: 14:44:36 [17:05:44.688] BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1705934676 serial edc8bb12 boardrev c04170 stc 4530360 [17:05:44.698] AON_RESET: 00000003 PM_RSTS 00000020 [17:05:44.722] usb_pd_init status 3 [17:05:44.725] USB_PD CONFIG 0 43 [17:05:44.729] XHCI-STOP [17:05:44.730] xHC0 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d [17:05:44.735] USBSTS 11 [17:05:44.737] xHC0 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d [17:05:44.741] xHC0 ports 3 slots 64 intrs 4 [17:05:44.750] XHCI-STOP [17:05:44.750] xHC1 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d [17:05:44.756] USBSTS 11 [17:05:44.757] xHC1 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d [17:05:44.762] xHC1 ports 3 slots 64 intrs 4 [17:05:44.766] Boot mode: NVME (06) order f14 [17:05:44.949] USB2[2] 00020ae1 connected [17:05:44.979] USB2[1] 00020ae1 connected [17:05:45.009] USB2[2] 00200a03 connected enabled [17:05:45.012] USB2 root HUB port 2 init [17:05:45.015] DEV [01:00] 2.00 000000:02 class 0 VID 17ef PID 6019 [17:05:45.026] HID [01:00] 2.00 000000:02 register HID [17:05:45.030] USB2[1] 00200a03 connected enabled [17:05:45.032] USB2 root HUB port 1 init [17:05:45.035] DEV [01:00] 1.16 000000:01 class 0 VID 413c PID 2107 [17:05:45.047] HID [01:00] 1.16 000000:01 register HID [17:05:45.509] PCI1 init [17:05:45.510] PCI1 reset [17:05:45.566] PCIe scan 0000144d:0000a80c [17:05:45.568] VID 0x144d MN Samsung SSD 990 PRO 1TB [17:05:45.713] NVME on [17:05:45.714] MBR: 0x00002000, 1048576 type: 0x0c [17:05:45.717] MBR: 0x00102000,1952468400 type: 0x83 [17:05:45.721] MBR: 0x00000000, 0 type: 0x00 [17:05:45.724] MBR: 0x00000000, 0 type: 0x00 [17:05:45.728] Trying partition: 0 [17:05:45.729] type: 32 lba: 8192 'mkfs.fat' ' bootfs ' clusters 261116 (4) [17:05:45.734] rsc 32 fat-sectors 2040 root dir cluster 2 sectors 0 entries 0 [17:05:45.741] FAT32 clusters 261116 [17:05:45.743] [nvme] autoboot.txt not found [17:05:45.745] Select partition rsts 0 C(boot_partition) 0 EEPROM config 0 result 0 [17:05:45.752] Trying partition: 0 [17:05:45.753] type: 32 lba: 8192 'mkfs.fat' ' bootfs ' clusters 261116 (4) [17:05:45.759] rsc 32 fat-sectors 2040 root dir cluster 2 sectors 0 entries 0 [17:05:45.764] FAT32 clusters 261116 [17:05:45.767] Read config.txt bytes 1213 hnd 0x126 [17:05:45.771] [nvme] pieeprom.upd not found [17:05:45.914] usb_max_current_enable default 0 max-current 3000 [17:05:45.922] Read bcm2712-rpi-5-b.dtb bytes 75197 hnd 0x1048f [17:05:45.926] dt-match: compatible: raspberrypi,5-model-b match: brcm,bcm2712 [17:05:45.933] dt-match: compatible: brcm,bcm2712 match: brcm,bcm2712 [17:05:45.937] Selecting USB low current limit

[17:05:51.614] NOTICE: BL31: v2.6(release):v2.6-239-g2a9ede0bd [17:05:51.618] NOTICE: BL31: Built : 14:26:57, Jun 22 2023

[17:06:03.185] Debian GNU/Linux 12 zbmvme990pro ttyAMA10

[17:06:03.189] zbmvme990pro login:

— Reply to this email directly, view it on GitHubhttps://github.com/geerlingguy/raspberry-pi-pcie-devices/issues/559#issuecomment-1913399894, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAHDCB6BIYJFHM3QPWXTAA3YQWSHFAVCNFSM6AAAAAA7NGHADKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTGM4TSOBZGQ. You are receiving this because you were mentioned.Message ID: @.***>

[codebuk]

Suggest you document your comments on the 5V connector somewhere on your site.....

[kitopopo]

Hi, dear friends.

I use a HatDrive! Bottom from Pineberry pi in a raspberry pi 5 8gb with a nvme lexar nm620 256Gb. The nvme boots correctly with dtparam=pciex1_gen=2 in config.txt. I can change the dtparm to dtparam=pciex1_gen=3 the first timeand the nvme boots correctly with gen 3 and i make a speed test with hdparm and i get 830 MB/s, but sometimes if i power off the raspberry pi 5 and after power on the nvme does not boot (HatDrive leds are on and rasp fan is with high speed), If I power off and power on again the raspberry the HatDrive leds are always off (unrecoverable). I can solve the problem but i need plug the nvme in a computer and change the dtparam from gen3 to gen 2 and all works correctly. Sometimes change again from gen2 to gen3 and sometimes boot and sometimes the boot crash.

I have the feeling that it could be a failure of the eeprom since the failure occurs just when the raspberry pi is turned on, at the same time I have opened an issue in rpi-eeprom to see if they can solve it. While doing tests to solve the problem, my previous Lexar nm620 hard drive broke and I had to buy another one. I have also tried with another HatDrive Bottom board but the same problem. Please does anyone have a solution? I've had this problem for weeks. Thanks in advance. a cordial greeting

[mikegapinski]

Hi, dear friends.

I use a HatDrive! Bottom from Pineberry pi in a raspberry pi 5 8gb with a nvme lexar nm620 256Gb. The nvme boots correctly with dtparam=pciex1_gen=2 in config.txt. I can change the dtparm to dtparam=pciex1_gen=3 the first timeand the nvme boots correctly with gen 3 and i make a speed test with hdparm and i get 830 MB/s, but sometimes if i power off the raspberry pi 5 and after power on the nvme does not boot (HatDrive leds are on and rasp fan is with high speed), If I power off and power on again the raspberry the HatDrive leds are always off (unrecoverable). I can solve the problem but i need plug the nvme in a computer and change the dtparam from gen3 to gen 2 and all works correctly. Sometimes change again from gen2 to gen3 and sometimes boot and sometimes the boot crash.

I have the feeling that it could be a failure of the eeprom since the failure occurs just when the raspberry pi is turned on, at the same time I have opened an issue in rpi-eeprom to see if they can solve it. While doing tests to solve the problem, my previous Lexar nm620 hard drive broke and I had to buy another one. I have also tried with another HatDrive Bottom board but the same problem. Please does anyone have a solution? I've had this problem for weeks. Thanks in advance. a cordial greeting

Lexar drives sometimes have issues under gen3(firmware?, it is OK in our testing), looks bootloader related - the controller times out the initialization in gen3. I can recommend removing other boot order entries. The pi should reboot and try to reinit the drive

[kitopopo]

¡El HatDrive! Top funciona perfectamente bien hasta que reinicio el pi. Una vez que reinicio o apago, la unidad Nvme ya no se reconoce hasta que desconecto el pi de la fuente de alimentación y lo inicio nuevamente. Esto ha sucedido con los 3 HatDrives que tengo. ¿Alguien más tiene este problema? Estoy usando unidades WD SN530 Nvme.

Hi dear friend, similar problem, please se my penultimate repply. Thanks

[mikegapinski]

¡El HatDrive! Top funciona perfectamente bien hasta que reinicio el pi. Una vez que reinicio o apago, la unidad Nvme ya no se reconoce hasta que desconecto el pi de la fuente de alimentación y lo inicio nuevamente. Esto ha sucedido con los 3 HatDrives que tengo. ¿Alguien más tiene este problema? Estoy usando unidades WD SN530 Nvme.

Hi dear friend, similar problem, please se my penultimate repply. Thanks

SN530 is listed as incompatible with NVMe boot on our docs page

[kitopopo]

I get an aswer in the rpi-eeprom issue: For reasons I don't recall, BCM2712's PCIE1 can't quite manage gen3 timing. You can get away with for some devices under some circumstances - which is why there is a parameter to enable it - but it isn't safe to enable by default. In other words, this is expected behaviour.

I am really disappointed since the pineberri documentation does not warn of problems using gen3

[kitopopo]

Hi, dear friends. I use a HatDrive! Bottom from Pineberry pi in a raspberry pi 5 8gb with a nvme lexar nm620 256Gb. The nvme boots correctly with dtparam=pciex1_gen=2 in config.txt. I can change the dtparm to dtparam=pciex1_gen=3 the first timeand the nvme boots correctly with gen 3 and i make a speed test with hdparm and i get 830 MB/s, but sometimes if i power off the raspberry pi 5 and after power on the nvme does not boot (HatDrive leds are on and rasp fan is with high speed), If I power off and power on again the raspberry the HatDrive leds are always off (unrecoverable). I can solve the problem but i need plug the nvme in a computer and change the dtparam from gen3 to gen 2 and all works correctly. Sometimes change again from gen2 to gen3 and sometimes boot and sometimes the boot crash. I have the feeling that it could be a failure of the eeprom since the failure occurs just when the raspberry pi is turned on, at the same time I have opened an issue in rpi-eeprom to see if they can solve it. While doing tests to solve the problem, my previous Lexar nm620 hard drive broke and I had to buy another one. I have also tried with another HatDrive Bottom board but the same problem. Please does anyone have a solution? I've had this problem for weeks. Thanks in advance. a cordial greeting

Lexar drives sometimes have issues under gen3(firmware?, it is OK in our testing), looks bootloader related - the controller times out the initialization in gen3. I can recommend removing other boot order entries. The pi should reboot and try to reinit the drive

Thanks for your answer, can you explain how i can removing other boot order entries? I don't understand what I can eliminate to solve the problem. In any case, the Lexar nm620 appears on the list of full compatibility, which is why I bought this model. Thank you

I am really disappointed since the pineberri documentation does not warn of problems using gen3 and the lexar nvme620 is inside the compatibility nvme list

[kitopopo]

Dear friends and dear @geerlingguy @mikegapinski , my issue opened today in rpi-eeprom has just been closed: This also isn't under the control of the firmware.

I don't understand how they can put in the documentation on the Pineberry website that the hatdrive botton board is fully compatible with gen3 and also ensure that the list of hard drives is also fully compatible when it appears that the lexar nm620 is not. Is the problem with lexar? Is it from the hatdrive? Please, someone should take responsibility for what happened and try to solve the problems and not make many people spend money on several hatdrive, m.2 nvme boards and waste time when the project really doesn't work and is totally misleading advertising. If any solution is not found, the next Monday i will return several hatdrive pcbs to the supplier because they do not meet my expectations. I am waiting for a possible solution since changing the boot order has not worked for me - Sorry for the inconvenience. Kind regards

[mikegapinski]

Dear friends and dear @geerlingguy @mikegapinski , my issue opened today in rpi-eeprom has just been closed: This also isn't under the control of the firmware.

I don't understand how they can put in the documentation on the Pineberry website that the hatdrive botton board is fully compatible with gen3 and also ensure that the list of hard drives is also fully compatible when it appears that the lexar nm620 is not. Is the problem with lexar? Is it from the hatdrive? Please, someone should take responsibility for what happened and try to solve the problems and not make many people spend money on several hatdrive, m.2 nvme boards and waste time when the project really doesn't work and is totally misleading advertising. If any solution is not found, the next Monday i will return several hatdrive pcbs to the supplier because they do not meet my expectations. I am waiting for a possible solution since changing the boot order has not worked for me - Sorry for the inconvenience. Kind regards

Uff, this will be a longer post on my end so grab a bowl of popcorn and buckle up.

Generally speaking all PCIe HATs regardless of the brand (ours, pimoroni, geekworm etc) had nothing on the PCB that affects compatibility with drives in general. People have issues with some boards since they ship with low quality ribbon cables, that is why our boards and NVMe base generally have the best compatibility with most drives. Nobody says every drive from every brand will work without issues in every mode, both us and pimoroni went ahead and tested a number of drives to validate that our boards function correctly. Nobody says that drive X works in mode X on bootloader version X, you also can't say that that particular Lexar drive is not compatible - it works in Gen 2 mode. We also inform people that their mileage may vary since there are things constantly changing in the bootloader (example: PCIE_PROBE=1 was not a thing a while ago etc). This also aligns with what rpi told you in their repo:

For reasons I don't recall, BCM2712's PCIE1 can't quite manage gen3 timing. You can get away with for some devices under some circumstances - which is why there is a parameter to enable it - but it isn't safe to enable by default. In other words, this is expected behaviour.

Now you know the reason why things are not so black and white on the 2712 side, now I can tell you exactly why you have issues with your "Lexar" 620 drive. You might not know, but we started doing NVMe drives recently and it so happens that first versions of the 2280 Pinedrive were based on the same controller + nand + pcb combo that is used in your drive:

This drive uses a controller from a company named Maxio, it is not a bad product but the firmware quality is not very good - we decided against using it since we were not OK with their support. Our engineering sample had a different firmware version from Maxio and it worked fine, we even functionally tested every HatDrive board from the first batch with this NVMe since we had a few of them. I suspect the one you have from "Lexar" ships with older firmware. I put "Lexar" in quote since 95% of NVMe drives use layouts provided by the controller vendor and the manufacturer (Lexar, Samsung, Goodram, WD etc) is "just" responsible for putting the pieces together (NAND, controller and tons of QC to rule out issues similar to what you were facing).

So if you want to pick someone to blame for your drive not being happy in Gen3 mode you can roll the dice and pick:

• us, since we made a simple adapter that just powers the drive and carries the PCIe signal from your pi
• rpi, since their PCIe implementation is not 100%, it is better than on the CM4 but your mileage may vary
• Lexar (for not giving a damn about the firmware they flash on their drives, maybe their next batch will have this sorted out)
• Maxio (those are not top notch controllers)

There are more caveats like this, some drives don't work without the SUSCLK signal that is not required by the standard, some fail to function in X1 mode when they are rated for X4, others need to have their power disabled for a short while when the system reboots to init the controller.

The problem with consumer drives is that you never know what you are getting, vendors shuffle controllers and NAND on regular basis to cut cost and nobody is testing those things on systems like rpi5 that do not closely adhere to the PCIE standard. We can say that WD SN770 does not work (ours doesn't) and yet someone has one from an early revision with a Phison controller that works OK and those drives share the same SKU.

Going back to our struggles with the Pinedrive, there is 0 rocket science behind NVMe drives right now. We just wanted to have the comfort of knowing exactly what we are selling and a certainty that the next batch would have the same bill of materials. Doing so can be expensive (a drive manufactured next month can be 20% more expensive for no reason, that is why PC vendors play with their BOMs all the time). That is also why "industrial" or "semi-industrial" storage products cost more, they are predictable. Same thing applies to the RAM you put in your PC, in the days of XMP profiles and high speed memory sometimes a combination of one CPU with a particular chipset might not work.

I hope this clarifies things a bit for you.

BTW: We ended up with a Phison controller, those have decent firmware/support

[kitopopo]

Dear friends and dear @geerlingguy @mikegapinski , my issue opened today in rpi-eeprom has just been closed: This also isn't under the control of the firmware. I don't understand how they can put in the documentation on the Pineberry website that the hatdrive botton board is fully compatible with gen3 and also ensure that the list of hard drives is also fully compatible when it appears that the lexar nm620 is not. Is the problem with lexar? Is it from the hatdrive? Please, someone should take responsibility for what happened and try to solve the problems and not make many people spend money on several hatdrive, m.2 nvme boards and waste time when the project really doesn't work and is totally misleading advertising. If any solution is not found, the next Monday i will return several hatdrive pcbs to the supplier because they do not meet my expectations. I am waiting for a possible solution since changing the boot order has not worked for me - Sorry for the inconvenience. Kind regards

Uff, this will be a longer post on my end so grab a bowl of popcorn and buckle up.

Generally speaking all PCIe HATs regardless of the brand (ours, pimoroni, geekworm etc) had nothing on the PCB that affects compatibility with drives in general. People have issues with some boards since they ship with low quality ribbon cables, that is why our boards and NVMe base generally have the best compatibility with most drives. Nobody says every drive from every brand will work without issues in every mode, both us and pimoroni went ahead and tested a number of drives to validate that our boards function correctly. Nobody says that drive X works in mode X on bootloader version X, you also can't say that that particular Lexar drive is not compatible - it works in Gen 2 mode. We also inform people that their mileage may vary since there are things constantly changing in the bootloader (example: PCIE_PROBE=1 was not a thing a while ago etc). This also aligns with what rpi told you in their repo:

For reasons I don't recall, BCM2712's PCIE1 can't quite manage gen3 timing. You can get away with for some devices under some circumstances - which is why there is a parameter to enable it - but it isn't safe to enable by default. In other words, this is expected behaviour.

Now you know the reason why things are not so black and white on the 2712 side, now I can tell you exactly why you have issues with your "Lexar" 620 drive. You might not know, but we started doing NVMe drives recently and it so happens that first versions of the 2280 Pinedrive were based on the same controller + nand + pcb combo that is used in your drive:

This drive uses a controller from a company named Maxio, it is not a bad product but the firmware quality is not very good - we decided against using it since we were not OK with their support. Our engineering sample had a different firmware version from Maxio and it worked fine, we even functionally tested every HatDrive board from the first batch with this NVMe since we had a few of them. I suspect the one you have from "Lexar" ships with older firmware. I put "Lexar" in quote since 95% of NVMe drives use layouts provided by the controller vendor and the manufacturer (Lexar, Samsung, Goodram, WD etc) is "just" responsible for putting the pieces together (NAND, controller and tons of QC to rule out issues similar to what you were facing).

So if you want to pick someone to blame for your drive not being happy in Gen3 mode you can roll the dice and pick:

• us, since we made a simple adapter that just powers the drive and carries the PCIe signal from your pi
• rpi, since their PCIe implementation is not 100%, it is better than on the CM4 but your mileage may vary
• Lexar (for not giving a damn about the firmware they flash on their drives, maybe their next batch will have this sorted out)
• Maxio (those are not top notch controllers)

There are more caveats like this, some drives don't work without the SUSCLK signal that is not required by the standard, some fail to function in X1 mode when they are rated for X4, others need to have their power disabled for a short while when the system reboots to init the controller.

The problem with consumer drives is that you never know what you are getting, vendors shuffle controllers and NAND on regular basis to cut cost and nobody is testing those things on systems like rpi5 that do not closely adhere to the PCIE standard. We can say that WD SN770 does not work (ours doesn't) and yet someone has one from an early revision with a Phison controller that works OK and those drives share the same SKU.

Going back to our struggles with the Pinedrive, there is 0 rocket science behind NVMe drives right now. We just wanted to have the comfort of knowing exactly what we are selling and a certainty that the next batch would have the same bill of materials. Doing so can be expensive (a drive manufactured next month can be 20% more expensive for no reason, that is why PC vendors play with their BOMs all the time). That is also why "industrial" or "semi-industrial" storage products cost more, they are predictable. Same thing applies to the RAM you put in your PC, in the days of XMP profiles and high speed memory sometimes a combination of one CPU with a particular chipset might not work.

I hope this clarifies things a bit for you.

BTW: We ended up with a Phison controller, those have decent firmware/support

Hello dear friend @mikegapinski , thank you for your response and for all the explanation. First of all I wanted to apologize since I can't blame anyone, you are right. As you say, there is a mix between PCB boards, flexible cables, nvme manufacturers, nvme firmwares, eeprom firmware... I simply got my hopes up since my drive was included in the list and was supposed to have been tested and would work in the first time. It is a very recent project and maybe I was too hasty in buying too much material, 2 nvme, 2 pihats bottons, nvme adapters, dock stations... and I was angry that everything went wrong (currently I have a solid ssd and it runs at the same speed as gen2 If I had known that the gen3 was not guaranteed I would not have bought so much material). I am not going to return any material, I will continue testing and carrying out tests and if I find out anything I will publish it here. I hope people comment here about their experiences to see if we can find a combination that works with gen3 one day and hope that everything evolves, even the part that concerns raspberry pi 5. I reiterate my apologies. Thanks for all the information and dedication. Kind regards

[geerlingguy]

Just FYI I have been running mostly Kioxia XG6 and XG8 SSDs (mostly because I partnered with them a few years ago and so I have a bunch of them...), and have had no issues with Gen 3 speeds on either the Pineberry Bottom or Pimoroni NVMe BASE. I did have issues at Gen 3 from time to time with one of the other boards that doesn't have an impedance-controlled cable.

I have a feeling there will be some drives/manufacturers that are more consistently good, but Gen 3 is not and probably won't be guaranteed across all Pi 5 devices (and maybe not CM5 either, we'll see), and that's the reason Raspberry Pi has never advertised Gen 3 support (only made it possible to kind of 'overclock' the PCIe bus to that spec).

[mikegapinski]

Just FYI I have been running mostly Kioxia XG6 and XG8 SSDs (mostly because I partnered with them a few years ago and so I have a bunch of them...), and have had no issues with Gen 3 speeds on either the Pineberry Bottom or Pimoroni NVMe BASE. I did have issues at Gen 3 from time to time with one of the other boards that doesn't have an impedance-controlled cable.

I have a feeling there will be some drives/manufacturers that are more consistently good, but Gen 3 is not and probably won't be guaranteed across all Pi 5 devices (and maybe not CM5 either, we'll see), and that's the reason Raspberry Pi has never advertised Gen 3 support (only made it possible to kind of 'overclock' the PCIe bus to that spec).

I can pretty confidently say that some (if not most) of the drives that do have GEN 3 issues with impedance-controlled cables can be fixed in the firmware. It is a shame that most vendors do not provide updates even if they are available upstream (from Phison, Maxio, Kingston or others). You can add Transcend to the list of vendors selling drives with outdated firmware too, same story as Lexar.

In the early days of NVMe drives on PCs there were also issues like this and when a new shiny controller shows up (latest GEN 5 Samsung drives) they also don't work well on the Pi out of the box. People quickly blame the power delivery but it is not the case.

I know that the PCIe timings on BCM2712 are not perfect and up to spec but this is not something RPI can fix now, NVMe drive controller firmware on the other hand is a different story.

I don't know if you have contacts in the storage industry @geerlingguy but it might be worth bringing this to their attention. I was mind blown that we tested 3/4 drives from different vendors with the exact same PCB + controller + NAND combo and not all of them worked out of the box

[kitopopo]

Good evening dear friends,

I have discovered how to boot my nvme in gen 3 always successfully. It seems incredible but the tests work for me and in my particular case. I have performed 30 shutdowns and 30 startups and a 100% satisfactory result. I don't really understand the reason but the problem seems to be with the FFC cable. Simply putting your finger on top of the FFC cable without pressing and just touching. Just above the numbers 2349 (just the touch of my finger is enough for me). After putting my finger on the hose with the Raspberry off after turning it on, I get 100% success on all startups. It seems like an impedance problem since from what I see it is a special type of cable that works with controlled impedance, of which I am completely unaware of how this type of cable works, but perhaps when you put your finger on the cable, the impedance is altered, although that It's already slipping out of my hands. I don't understand nothing, it since it is an insulated cable and the outer film has no continuity, I don't know why it reacts to my finger (It is important to mention that performing the same test and touching the hose with a piece of plastic or some insulating material, the nvme boot does not work in most cases, so I rule out possible no good contact phases in the 2 connectors and the test reaffirms that it is of a variation of impedance) As you mentioned, perhaps the firmware of most nvms also has something to do with it, is possible but in my opinion, if on desktop computers or laptops these nvmes work perfectly and in this project, my opinion is that there could be another added cause. I encourage all of you who do not get a correct boot in gen3 to try it and I also encourage the development department to carry out tests, use other types of cables or cables without impedance control , using a cable 25mm, 50mm or 100mm in lenght. Currently I only have the Pineberri Pi cable, so I can carry out more tests but I hope and wish that they can find a solution and add it to some v2 revision of the board or FFC cable.

Note:

In my particular case, if the nvme boot fails 2 times in a row, it is necessary to connect the nvme to a computer using a dock or USB adapter to change to gen 2 in config.txt. In gen 2 it always starts correctly, once it starts, we have to change back to gen 3 and turn off the raspberry. Put your finger back on the cable every time you start (it's a shame we can't restart the raspberry remotely due to is impossible put my finger) I repeat that in my particular case it works with nvm lexar 620.

I hope it works for you and you will comment on the tests. I hope I have helped and I just wanted to share my experience . A cordial greeting and thank you all.

[mikegapinski]

Good evening dear friends,

I have discovered how to boot my nvme in gen 3 always successfully. It seems incredible but the tests work for me and in my particular case. I have performed 30 shutdowns and 30 startups and a 100% satisfactory result. I don't really understand the reason but the problem seems to be with the FFC cable. Simply putting your finger on top of the FFC cable without pressing and just touching. Just above the numbers 2349 (just the touch of my finger is enough for me). After putting my finger on the hose with the Raspberry off after turning it on, I get 100% success on all startups. It seems like an impedance problem since from what I see it is a special type of cable that works with controlled impedance, of which I am completely unaware of how this type of cable works, but perhaps when you put your finger on the cable, the impedance is altered, although that It's already slipping out of my hands. (It is important to mention that performing the same test and touching the hose with a piece of plastic or some insulating material, the nvme boot does not work in most cases, so I rule out possible no good contact phases in the 2 connectors and the test reaffirms that it is of a variation of impedance) As you mentioned, perhaps the firmware of most nvms also has something to do with it, is possible but in my opinion, if on desktop computers or laptops these nvmes work perfectly and in this project, my opinion is that there could be another added cause. I encourage all of you who do not get a correct boot in gen3 to try it and I also encourage the development department to carry out tests, use other types of cables or cables without impedance control , using a cable 25mm, 50mm or 100mm in lenght. Currently I only have the Pineberri Pi cable, so I can carry out more tests but I hope and wish that they can find a solution and add it to some v2 revision of the board or FFC cable.

Note:

In my particular case, if the nvme boot fails 2 times in a row, it is necessary to connect the nvme to a computer using a dock or USB adapter to change to gen 2 in config.txt. In gen 2 it always starts correctly, once it starts, we have to change back to gen 3 and turn off the raspberry. Put your finger back on the cable every time you start (it's a shame we can't restart the raspberry remotely due to is impossible put my finger) I repeat that in my particular case it works with nvm lexar 620.

I hope it works for you and you will comment on the tests. I hope I have helped and I just wanted to share my experience . A cordial greeting and thank you all.

Our ribbon cables are thick and you might have separated the ground plane when you tested the board repeatedly by bending them back and forth.

Please drop me an email with your order number - I will ship you some FPC bundles and an engineering sample of a different cable in the same length. Curious about your results - I don't know what revision your HatDrive is from but we are on a third one at the moment.

[mathiasscheurer]

I suspected the cable right from the start. If I bend the cable slightly downwards by hand, the NVMe-SSD sometimes boots. The whole thing described by kitopopo sounds logical to me. I can test with my equipment if You send me some ribbon cables - order #2124.

[kitopopo]

Good evening dear friends,

I have discovered how to boot my nvme in gen 3 always successfully. It seems incredible but the tests work for me and in my particular case. I have performed 30 shutdowns and 30 startups and a 100% satisfactory result. I don't really understand the reason but the problem seems to be with the FFC cable. Simply putting your finger on top of the FFC cable without pressing and just touching. Just above the numbers 2349 (just the touch of my finger is enough for me). After putting my finger on the hose with the Raspberry off after turning it on, I get 100% success on all startups. It seems like an impedance problem since from what I see it is a special type of cable that works with controlled impedance, of which I am completely unaware of how this type of cable works, but perhaps when you put your finger on the cable, the impedance is altered, although that It's already slipping out of my hands. (It is important to mention that performing the same test and touching the hose with a piece of plastic or some insulating material, the nvme boot does not work in most cases, so I rule out possible no good contact phases in the 2 connectors and the test reaffirms that it is of a variation of impedance) As you mentioned, perhaps the firmware of most nvms also has something to do with it, is possible but in my opinion, if on desktop computers or laptops these nvmes work perfectly and in this project, my opinion is that there could be another added cause. I encourage all of you who do not get a correct boot in gen3 to try it and I also encourage the development department to carry out tests, use other types of cables or cables without impedance control , using a cable 25mm, 50mm or 100mm in lenght. Currently I only have the Pineberri Pi cable, so I can carry out more tests but I hope and wish that they can find a solution and add it to some v2 revision of the board or FFC cable.

Note:

In my particular case, if the nvme boot fails 2 times in a row, it is necessary to connect the nvme to a computer using a dock or USB adapter to change to gen 2 in config.txt. In gen 2 it always starts correctly, once it starts, we have to change back to gen 3 and turn off the raspberry. Put your finger back on the cable every time you start (it's a shame we can't restart the raspberry remotely due to is impossible put my finger) I repeat that in my particular case it works with nvm lexar 620.

I hope it works for you and you will comment on the tests. I hope I have helped and I just wanted to share my experience . A cordial greeting and thank you all.

Our ribbon cables are thick and you might have separated the ground plane when you tested the board repeatedly by bending them back and forth.

Please drop me an email with your order number - I will ship you some FPC bundles and an engineering sample of a different cable in the same length. Curious about your results - I don't know what revision your HatDrive is from but we are on a third one at the moment.

Hi again, thanks for your response. The review of my two Pieberri Pi Botton boards and my two cables are both v1.

The cable is not damaged because as I mentioned previously, I bought 2 botton boards, one is damaged along with the first NVME (after doing so many tests they were damaged, it's a shame). Now I am using the other new botton board and the new cable and they are not damaged. I cannot provide you with the order number since I did not make the purchase on their website, but instead placed the order on a Spanish website since it arrived in 1 day and I got a slightly better price due to vat i prefer spain to spain shipment. I think I have found a cable 16pins without impedance control, as soon as I can and if it is the same pitch I will test it to see its behavior. I will report the results. greetings

[mathiasscheurer]

I discovered cables with impedance control on aliexpress and I will give them a try: https://de.aliexpress.com/item/1005006408515686.html

[kitopopo]

I discovered cables with impedance control on aliexpress and I will give them a try: https://de.aliexpress.com/item/1005006408515686.html

oh yeah, they're the same ones I just saw 30 minutes ago. I will also try them when I can financially. You can comment on how they work, I would appreciate it. thank you

[kitopopo]

Good afternoon dear friends, I have been carrying out tests and in my particular case with my 256gb lexar nm620 unit and using a normal 40mm cable (without impedance control) I get a correct boot 100% of the time in gen3 and with a speed of 840Mb/s . With another 70mm cable without impedance control I cannot get a correct boot. If the pineberry pi engineering department uses a cable with impedance control it must be more suitable for this board, I have also read that controlled impedance is crucial in high frequency applications, such as data transmission, to minimize loss signal and ensure optimal performance. I do not understand the results of my tests and I do not understand why it works correctly with a normal cable, perhaps communications errors occur. Let's see if Mr. @mikegapinski can transfer the results of my tests to the development or engineering department so that they can help us improve, explain this behavior or solve the boot problem in gen 3. Thanks in advance for your help and best regards.

[xBelladonna]

I have just spent all night losing sleep over this, and @kitopopo's trick with the finger (and only finger) touch really worked for me! It's incredible, and without some electrical testing I don't have the equipment for, I can't really confirm what is going on or why this works. The first thing that comes to mind is that the finger touch would increase the capacitance of the conductors by just a tiny amount, provide small (even variably transient) capacitance across them, perhaps enough to stabilize the signals during early boot. I will probably be trying to get a hold of another NVMe drive that is known to work with this (maybe one from Pineberry themselves) but I will continue experimenting with the Lexar and see what I can figure out/make it do.

[mikegapinski]

I have just spent all night losing sleep over this, and @kitopopo's trick with the finger (and only finger) touch really worked for me! It's incredible, and without some electrical testing I don't have the equipment for, I can't really confirm what is going on or why this works. The first thing that comes to mind is that the finger touch would increase the capacitance of the conductors by just a tiny amount, provide small (even variably transient) capacitance across them, perhaps enough to stabilize the signals during early boot. I will probably be trying to get a hold of another NVMe drive that is known to work with this (maybe one from Pineberry themselves) but I will continue experimenting with the Lexar and see what I can figure out/make it do.

I don't believe that this is the case - the ribbon on the side of the pi needs to be inserted all the way down and the latch needs to be secured all the way down. The connector on the Pi side is flimsy and it's actually easy to break it. Generally speaking there is a reason why they don't officially say it's gen 3, most of the drives are not that sensitive and I don't think it is hardware on the lexar too (since we have the same drive with a different firmware that is 100% OK.)

One thing I can check is the ribbon itself, we have two revisions - the one that is shipping currently is a little bit more thick and stiff. Maybe the OG ones were slightly better, no clue. I'll check the Lexar once again.

@geerlingguy you have both of them, the newer ones are slightly darker orange, the first ones and the 10cm we currently sell in the bundle are yellowish

@mfolejewski and I smiled when we read the capacitance theory, it's nuts

[kitopopo]

Hi dear friends,

1) my pcie connectors (raspberry side and pineberrypi board side are perfectly and without damage. If both connectors are not good, then explain to me the correct operation for 48 hours with a normal flat cable without impedance control. To this last test with simple cables You didn't mention it in my last post.

2) The impedance or capacitance of the impedance controlled cable is altered by touching it with your finger and without moving the cable. I reiterate again that the board performs a correct boot 100% of the time by touching the flat cable. Please do the test, it is very simple and it has worked for @xBelladonna . This is not a miracle or a crazy test. It just works and the engineers will know why. It is not my part to solve this.

3) I can also affirm that my Pineberry v1 revision flat cable is in perfect condition, I remind you that I bought 2 Pineberry boards and have a completely new hose. It is impossible for the ground part to be raised since if you look at the schematic diagram it has several pins for ground and not just one.

4) I'm a final user, I'm just looking for solutions to be able to enjoy gen 3 speed and I have simply commented here on the tests that work for me and those that don't, but at no time do I want to get into any type of discussion. or repeat the same thing over and over again.

5) I think you should forget about nvms firmwares since all models work correctly on Windows computers or laptops.

6) the community that has pineberripi boards with problems will come to this forum and perform these tests, it is just a matter of waiting to see results.

I attach the picture similar to my actual cable, this cable works and boot correctly with my hardware.

Thank you and greetings.

[mfolejewski]

@kitopopo and @xBelladonna

To answer your questions why regular 40mm FPC (without impedance control) tape works and 70mm tape doesn't: PCIe interface uses the Link Equalization technique (emphasis and de-emphasis circuits), which improves signal quality and transmission line loss ("signal loss"). This circuit performs very well even with quite large impedance mismatches/discontinuities in the transmission path and signal losses resulting from the use of a poor quality link (e.g. classic FPC tape).

What you have observed is that the 40mm FPC cable, despite signal losses, the PCIe interface can still correct the signal quality, but for the 70mm cable it cannot (too much signal attenuation and distortion).

It appears that the standard 40mm FPC cable causes minor signal loss and some incorrect PCIe frames, which cause longer to initialize the SSD and the PCIe interface on Gen3 (the PCIe link works stably, although with some unnoticeable initialization issues). It is possible that this delay for this SSD is necessary for proper initialization (Lexar).

This explains why touching the impedance controlled cable with your finger causes the cable to perform better on the Lexar NM620 and PCIe Gen3 drive (touching with your finger disrupts the signal quality of the PCIe interface to some extent).

Lexar NM620 has problems with booting in PCIe Gen3, several users have confirmed this and it is a generally known fact.

If the standard FPC cable was generally better than a dedicated impedance controlled cable, then a longer variant, e.g. 70mm, should also work. As you can see, standard long FPC cables do not work properly - because they disturb the signal quality so much that a link on the PCIe interface is not possible. Our 10cm PCIe cables work with all HAT boards on Gen3 - which is not possible with standard PCIe cables.

I would rather not jump to the conclusion that impedance controlled FPC cable is worse in some cases than the regular FPC cable. What you observed is a combination of the PCIe link stability, and specific SSD drive.

[kitopopo]

@kitopopo and @xBelladonna

To answer your questions why regular 40mm FPC (without impedance control) tape works and 70mm tape doesn't: PCIe interface uses the Link Equalization technique (emphasis and de-emphasis circuits), which improves signal quality and transmission line loss ("signal loss"). This circuit performs very well even with quite large impedance mismatches/discontinuities in the transmission path and signal losses resulting from the use of a poor quality link (e.g. classic FPC tape).

What you have observed is that the 40mm FPC cable, despite signal losses, the PCIe interface can still correct the signal quality, but for the 70mm cable it cannot (too much signal attenuation and distortion).

It appears that the standard 40mm FPC cable causes minor signal loss and some incorrect PCIe frames, which cause longer to initialize the SSD and the PCIe interface on Gen3 (the PCIe link works stably, although with some unnoticeable initialization issues). It is possible that this delay for this SSD is necessary for proper initialization (Lexar).

This explains why touching the impedance controlled cable with your finger causes the cable to perform better on the Lexar NM620 and PCIe Gen3 drive (touching with your finger disrupts the signal quality of the PCIe interface to some extent).

Lexar NM620 has problems with booting in PCIe Gen3, several users have confirmed this and it is a generally known fact.

If the standard FPC cable was generally better than a dedicated impedance controlled cable, then a longer variant, e.g. 70mm, should also work. As you can see, standard long FPC cables do not work properly - because they disturb the signal quality so much that a link on the PCIe interface is not possible. Our 10cm PCIe cables work with all HAT boards on Gen3 - which is not possible with standard PCIe cables.

I would rather not jump to the conclusion that impedance controlled FPC cable is worse in some cases than the regular FPC cable. What you observed is a combination of the PCIe link stability, and specific SSD drive.

Thank you for your response and explanation. I don't have other NVME units from other manufacturers to do more testing, it may work with my Lexar unit in particular, I can't confirm that anymore but the Pinebripi team can do more testing. @xBelladonna , also have a lexar nm620 unit? Thanks in advanced. Best regards

[xBelladonna]

After working at this and trying to figure out more all night, I think it's much more likely that the cable is fine and the problem is the SSD firmware. It took quite a lot of abuse (both electromagnetic and physical) to actually cause the PCIe link to become unstable. I'm waiting for more SSDs to test with, hopefully I can narrow this down.

[kitopopo]

Well, in my particular case with my new cable without impedance control already working correctly for more than 72 hours, I think the easiest thing is to try with another cable without impedance control since it only costs a few cents, I have not had problems or errors again. If more users carry out tests we will see it here soon. We will be in contact for more tests. greetings

[xBelladonna]

Thanks @mfolejewski for your explanation. My background is in electrical engineering but I have no idea how PCIe works in detail. With my limited knowledge I've found that it's really hard to get the signal across the impedance-controlled FPC to become unstable, requiring physical disturbance of the flex. Your explanation about the instability it causes when I do press on it at startup coinciding with some firmware bug necessitating some kind of initialization delay makes a lot of sense and explains why my results are so variable, sometimes working sometimes not (even failing during or after boot most of the time), but as far as I can see, no amount of messing with the capacitance makes any difference, so the finger couldn't be doing anything except causing the cable to physically move and the signal to bounce. The impedance is also by definition controlled, so I'm inclined to believe that it is indeed poor firmware design/bugs and that the FPC is completely fine. I can confirm everything is working perfectly at Gen2 speeds. Thanks again for shedding more light on the issue.

[kitopopo]

Hi again dear friends.,

I have continued testing and simply touching the flat cable (from pineberri) and without using any type of pressure I get a correct boot 100% of the time without room for errors. not a single mistake. 100% success in 50 continuous boots. If I stop touching the flat cable with my finger, the correct boot is not performed even once (perhaps very occasionally it performs a correct boot). I repeat that changing the flat cable for a normal 40mm cable and without impedance control, I get a correct boot also 100% of the time and with this cable it is not necessary to touch it with your finger, which confirms that I do not have false contacts in my connectors and that the cable from pineberry is altered with the human touch (I don't know the reason but it works for me).

I am not going to continue explaining or discussing the same thing over and over again, my tests are reflected here and time will give or take away reasons with tests from other users. What is clear to me is that I have completely replaced the cable from Pineberry with my own (without impedance control) and so far everything works correctly and without problems in gen3 for me. I've been working for 3 days without problems. So far the performance meets my expectations and I am happy with my current performance of my pineberry pi botton and gen3.

I remember again what I explained previously in case any other user needs it, if the correct boot is not performed with the Pineberri flat cable, it is necessary to take the NVME to the computer, edit the file "/boot/firmware/config.txt" and replace gen3 with gen 2 to start the process again. Later you can return to gen 3 and perform a new boot by touching the cable or replacing the cable with one without impedance control. ( These test and the despair is what led me to damage my other lexar unit and my other pineberry botton board, until I found out the reason)

I also reiterate that all these tests work with my current hardware (board from pineberry rev1, cable from pineberry rev1 and nvme lexar nm620 256gb and raspberry pi 5), I do not know the behavior with other nvme's and/or other pcb revs.

For my part, I leave this matter parked here, I wish you luck with your tests.

Best regards, have a nice day

[arekm]

If I see correctly "top" hat can be easily used at bottom after connecting 5v, 3.3v, GND (and optionally pin27 (GPiP0/I2C)) rails.

[mikegapinski]

If I see correctly "top" hat can be easily used at bottom after connecting 5v, 3.3v, GND (and optionally pin27 (GPiP0/I2C)) rails.

You can just mount it on the bottom with shorter standoffs. No need to connect anything else, the ribbon is the only required thing

[arekm]

Thanks. M2.5x6mm standoffs worked with original "top hat" cable but barely (for example with sdcard inserted cable will be too short). Replacing cable with longer variant will be better, for nvme cooling, too.

[mikegapinski]

The short cable is not really meant for BOT mounting; people went crazy with the FPC bundle recently and it's out of stock. We should have them shortly, together with complete accessory kits (standoffs, new m.2 mount etc)

[arekm]

What's the standard length of "bottom" hat standoffs? (trying to fit this my small "monster" into unmodified cases designed for pi5+bottom hat).

Edit: Remixed one nice case. Works great with top hat (mounted at bottom) ! https://www.printables.com/model/777582-pi-hat-drive-top-variant-of-great-rpi5-enclosure

[mikegapinski]

We use M2.5 at 6mm, you can use the step files on our GitHub as reference to see if it'll fit

[kitopopo]

Good evening dear friends,

I have discovered how to boot my nvme in gen 3 always successfully. It seems incredible but the tests work for me and in my particular case. I have performed 30 shutdowns and 30 startups and a 100% satisfactory result. I don't really understand the reason but the problem seems to be with the FFC cable. Simply putting your finger on top of the FFC cable without pressing and just touching. Just above the numbers 2349 (just the touch of my finger is enough for me). After putting my finger on the hose with the Raspberry off after turning it on, I get 100% success on all startups. It seems like an impedance problem since from what I see it is a special type of cable that works with controlled impedance, of which I am completely unaware of how this type of cable works, but perhaps when you put your finger on the cable, the impedance is altered, although that It's already slipping out of my hands. (It is important to mention that performing the same test and touching the hose with a piece of plastic or some insulating material, the nvme boot does not work in most cases, so I rule out possible no good contact phases in the 2 connectors and the test reaffirms that it is of a variation of impedance) As you mentioned, perhaps the firmware of most nvms also has something to do with it, is possible but in my opinion, if on desktop computers or laptops these nvmes work perfectly and in this project, my opinion is that there could be another added cause. I encourage all of you who do not get a correct boot in gen3 to try it and I also encourage the development department to carry out tests, use other types of cables or cables without impedance control , using a cable 25mm, 50mm or 100mm in lenght. Currently I only have the Pineberri Pi cable, so I can carry out more tests but I hope and wish that they can find a solution and add it to some v2 revision of the board or FFC cable.

Note:

In my particular case, if the nvme boot fails 2 times in a row, it is necessary to connect the nvme to a computer using a dock or USB adapter to change to gen 2 in config.txt. In gen 2 it always starts correctly, once it starts, we have to change back to gen 3 and turn off the raspberry. Put your finger back on the cable every time you start (it's a shame we can't restart the raspberry remotely due to is impossible put my finger) I repeat that in my particular case it works with nvm lexar 620.

I hope it works for you and you will comment on the tests. I hope I have helped and I just wanted to share my experience . A cordial greeting and thank you all.

Our ribbon cables are thick and you might have separated the ground plane when you tested the board repeatedly by bending them back and forth.

Please drop me an email with your order number - I will ship you some FPC bundles and an engineering sample of a different cable in the same length. Curious about your results - I don't know what revision your HatDrive is from but we are on a third one at the moment.

Dear friend @mikegapinski , I have been doing tests these weeks and I get perfect boot with flat cables without impedance control less than 4cm, but with my v1 flat cables supplied with the pineberri board (impedance control) I can never start unless I touch it with my finger (just like I mentioned before) but I am very happy with my pineberri botton board and gen 3 work. I would like to take this opportunity to comment that in the raspberry pi 5 log an error occurs, PCIe Bus Error: severity=Corrected, which is solved by adding pcie_aspm=off to cmdline.txt. This parameter solves almost 99% of the errors in gen 3 but from time to time a sporadic error appears. Is there a way to test the new v2 or v3 cables or those that you told me about to test if the errors disappear completely? When I bought the boards I did not place the order directly to Pineberrybut place it with a Spanish Pineberri supplier. how could we do? Can I buy a cable in pineberry and can you send me the rest for testing? do you have any other ideas for that i can receive this cables test? thanks in advance, receive a cordial greeting

[bmoss706]

Pimoroni Base + RPi5. Bookworm has ASPM turned on.

Netac NV2000 Maxio MAP1202 controller

• $ sudo lspci -vvv shows that ASPM is not supported.
• Gen 3 ASPM on: System Journals show AER error counts as high as 46069 causing kernel panics.
• Gen 3 ASPM off at command line. No AER errors except when using the Pimoroni microSD extension which interferes with the FFC.
• ASPM off does not suppress error reporting. It shuts down the system causing the errors. This is a firmware issue.
• Pibenchmarks score average around 50000.

Lexar NM790 Maxio MAP1602 controller.

• Max power 3.7W, within the RPi5 PCIe FFC 1A, 5W limitation.
• Supports ASPM mode L1.
• Gen 3 no AER errors except when using the Pimoroni microSD extension.
• Pibenchmarks score average around 58500.

Recommendation: If you have issues with your NVMe drive and it does not support ASPM, turn it off.

[kitopopo]

Pimoroni Base + RPi5. Bookworm has ASPM turned on.

Netac NV2000 Maxio MAP1202 controller

• $ sudo lspci -vvv shows that ASPM is not supported.
• Gen 3 ASPM on: System Journals show AER error counts as high as 46069 causing kernel panics.
• Gen 3 ASPM off at command line. No AER errors except when using the Pimoroni microSD extension which interferes with the FFC.
• ASPM off does not suppress error reporting. It shuts down the system causing the errors. This is a firmware issue.
• Pibenchmarks score average around 50000.

Lexar NM790 Maxio MAP1602 controller.

• Max power 3.7W, within the RPi5 PCIe FFC 1A, 5W limitation.
• Supports ASPM mode L1.
• Gen 3 no AER errors except when using the Pimoroni microSD extension.
• Pibenchmarks score average around 58500.

Recommendation: If you have issues with your NVMe drive and it does not support ASPM, turn it off.

Thanks for your anwer. I have added pcie_aspm=off to cmdline.txt but some times the error appear. Plugin off an plugin off the raspberry several times the pcie error corrected appesr in my raspberry pi 5. The "pcie_aspm=off" seems to have no effect for me. I suspect my fpc cable without shielding and without impedance control since with the original v1 from pineberry the nvm never doesn't boot correctly.

[kitopopo]

Hi dear friends,

For those who are interested, I have discovered a way how we can completely eliminate the error "PCIe Bus Error: severity=Corrected" in the raspberry pi 5 log without having to add "pcie_aspm=off" in cmdline.txt. So far in 70 boots I have achieved 100% success with my hardware. I'm doing more shutdowns and restarts before publishing the temporary solution that works for me. I will contact here again soon if I get 100% success, I need to do more tests. Thank you. Best regards

[mikegapinski]

I'd suggest moving the discussing about that Lexar drive elsewhere since it is not strictly related to the board itself.

I can share a small update from us about drive compatibility:

• All HatDrive variants ordered after 11.03 include with HAT+ power management (HatDrive! Top and Top Lite boards are launching now, they also have an updated footprint)
• We updated the HatDrive! Bottom in January but have not mentioned it since there were 3 revisions in circulation. V2 had SUSCLK that we determined was not necessary moving forward. V3 has HAT+ power management and we ditched the HAT ID / INA power monitoring IC since I2C on the FPC connector did not make it to the final spec
• Upcoming HatDrive! Bottom revision will ditch the 5V power plug, we honestly could not find a use case for it - both the spec and our testing show that the FPC connector can deliver enough power for everything we throw at it
• Current bootloader does not require PCIE_PROBE and changing the boot order, it will boot from NVMe if something is connected. Even V0 prototypes we made in October work, since Mirko figured out how auto detection could work. For a second we thought EEPROM would need to be connected to the GPIO header but it is not the case.
• Power management control on the bootloader level and recent bootloader updates resolved issues that we had with WD Drives. Your mileage may vary, but we are not getting any reports from customers that purchase the boards at the moment. Most of people don't read the docs and ignore the warnings we gave before. SN530 is very popular since it is cheap on Amazon (OEM variant)

Some other news that could mean something for the future: the embedded version of the Raspberry Pi Imager that boots up if no bootable media is present now recognizes and flashes NVMe drives connected behind a PCIe switch. This could mean booting from them may start working at some point @geerlingguy. It seems like RPI has solved most of the problems with the bootloader now and it aligns perfectly with their release schedule for the official M.2 HAT :)

[geerlingguy]

@mikegapinski good news indeed!

[kitopopo]

Sorry @mikegapinski , but it is not a problem with lexar unit or the nvme firmwares, it is a problem with the v1 flat cable. Many people with both Pineberry Pi and the competition have a PCIe Corrected error with other nvme brands. My nvme works correctly and without errors with another flat cable and without errors. But if no one is interested in knowing the solution, I will no longer continue explaining the solution. kind regards

[mightymos]

I have a Kioxia KBG40ZNS256G NVMe drive that boots on 2/16/2024 bootloader with the Hatdrive Top (ordered 2/5/2024). However, I am also getting PCIe corrected errors. I was having freezes previously but this was on alternative OSes so I am not sure if that is a coincidence.

I ordered a 3cm cable from Hangzhou WildChip Tech Co., Ltd. Store to try out which is linked in the thread. @kitopopo Is that a cable you've tried out with your drive(s)?

[mikegapinski]

I’ve seen some reports about this drive being inconsistent on the NVMe Base in the past. Try Gen 2 or disabling aspm. Switching cables to something without impedance control is not a good idea

Wysyłane z aplikacji Outlook dla systemu iOShttps://aka.ms/o0ukef

---

Od: Jonathan Armstrong @.> Wysłane: Sunday, March 10, 2024 4:29:08 AM Do: geerlingguy/raspberry-pi-pcie-devices @.> DW: Michał Gapiński @.>; Mention @.> Temat: Re: [geerlingguy/raspberry-pi-pcie-devices] Test Pineberry Pi's HatDrive! Top and Bottom NVMe HATs (Issue #559)

I have a Kioxia KBG40ZNS256G NVMe drive that boots on 2/16/2024 bootloader with the Hatdrive Top (ordered 2/5/2024). However, I am also getting PCIe corrected errors. I was having freezes previously but this was on alternative OSes so I am not sure if that is a coincidence.

I ordered a 3cm cable from Hangzhou WildChip Tech Co., Ltd. Store to try out which is linked in the thread. @kitopopohttps://github.com/kitopopo Is that a cable you've tried out with your drive(s)?

— Reply to this email directly, view it on GitHubhttps://github.com/geerlingguy/raspberry-pi-pcie-devices/issues/559#issuecomment-1987055946, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAHDCBZV4EC4CTZFR7IL6ATYXPHQJAVCNFSM6AAAAAA7NGHADKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBXGA2TKOJUGY. You are receiving this because you were mentioned.Message ID: @.***>

[kitopopo]

Dear @mightymos ,

I have tried those 3cm cables from that store, with those cables I get a correct boot with my nvme but I get too many pcie severity:corrected errors. The title of those cables gave me the final idea to eliminate the pcie corrected errors mentioned above. If you look closely it says "shielding FPC cable".

I use normal white cables without impedance control and 40mm, perfect start but with errors in gen 3.

So a week ago it occurred to me to shield my 40mm cable with aluminum foil or silver paper, the kitchen paper of the entire life. After giving a few layers of paper to the cable, I inserted a cable in the middle to connect gnd to the gpio connectors of the raspberry, and to cover this cable I gave it more layers of paper which I finally wrapped with tape so that it does not move.

Attention, you have to be careful because if the aluminum foil is not perfectly fixed, it can move and short circuit the cable pins on both sides. If you do the test, do it at your own risk.

After this procedure I get 0 PCI corrected errors working in gen3 for more than a week, testing every day and powering off the raspberry pi 5 more of 200 times, rebooting... these errors have disappeared. You can also eliminate the pcie_aspm=off line from cmdline.txt since in my case it does not work since I kept getting errors.

Note: My experiment only works with 40mm cables, I have tested 50mm but again errors. My opinion is that the problem has always been in the FPC cable.

Now I just have to buy new cables to pineberry pi revisions v2 or v3 and verify these errors with new cables since my experiment is provisional. For this reason, several messages ago, I asked @mikegapinski for several test cables but he ignored my message.

I don't reject @mikegapinski advice and it is most likely that it is convenient to use cables with impedance control, they are engineers and it is their project, I simply explain how in my particular case I have managed to eliminate all the PCI errors and start my NVME correctly . If someone tries it, we will discuss the results. It is difficult to get normal 40mm fpc cables, I think there is only one seller in the Asian store.

Kind regards

[mikegapinski]

@kitopopo

The cables we ship with the FPC bundle on the website are the same that you got with the board. We have a few thousand of them. Every HatDrive we ever shipped to customers has the same FPC. There are no revisions of those other than a few dozen prototypes from 2023/10 that never made it out of our lab.

The 100mm one currently comes from a new production batch (2024). We also have 60mm and 80mm for the HatBrick Commander and they could be potentially available separately soon.

60mm cable is currently only shipping with our Ethernet boards.