SSD + Cable Only works on 1 USB 2.0 Port

[DrizzutoJr]

For general boot questions please check the read the Boot Problems sticky post on the forums.

N.B The bootloader does not persist in memory and if the rainbow splash screen has been displayed the issue is likely to be in the firmware or Linux. If so, it's better to target the bug in the Firmware or Linux repositories first e.g. NFS, USB or dmesg logs would be Linux issues.

Describe the bug
A clear and concise description of what the bug is.

I have purchased an SSD Card:
Crucial P2 500GB 3D NAND NVMe PCIe M.2 SSD - CT500P2SSD8
and Enclosure:
TDBT M.2 NVMe SSD Enclosure with Heat Sink - via Amazon
to boot Raspberry Pi from SSD. I followed the Toms Hardware Guide and am unable to boot via either USB 3.0 and one of the USB 2.0. The boot does work on one of the USB 2.0 ports.

When I boot from USB 3.0, I either get stuck in a loop of:

Failed to open devices 'sdcard' (cmd 371a0010 status 1fff0001)
Reset USB port-power 500 ms
root Hub port 1 init
root Hub port 3 init
MSD [2:00] 3.32 000000:03 register MSD
MSD [2:00] 3.32 000000:03 LUN 0
MSD [1:00] 2.16 000000:03 init port 3 speed 1
MSD [1:00] 2.16 000000:03 init port 4 speed 1
MSD [2:00] 3.32 000000:03 LUN 0 timeout 2000ms

OR

I get the screen with 3 raspberries and see

[sda] Asking for cache data failed
[sda] Assuming drive cache: write through

then hangs

To Reproduce
Steps to reproduce the behavior:

Plug in SSD to raspberry Pi (in enclosure) and plug into any USB port other than Bus 001 Device 003. Boot up Raspberry Pi.
Bus 001 Device 003 boots up successfully.

Expected behaviour
A clear and concise description of what you expected to happen.

To boot successfully to Raspian.

Screenshots
If applicable, add a photograph of the bootloader HDMI diagnostics screen.

Bootloader version and configuration
If you have modified the default bootloader release or configuration then please attach the bootloader configuration (vcgencmd bootloader_config) and version (vcgencmd bootloader_version)

vcgencmd bootloader_version:
Jul 6 2020 12:48:15
version 2139c00d5e0f370b707d6c50a738943a7e0cae95 (release)
timestamp 1594036095

vcgencmd bootloader_config
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
ENABLE_SELF_UPDATE=1
DISABLE_HDMI=0
BOOT_ORDER=0xf41

USB boot (please complete the following information):
For issues booting with specific USB devices please verify that the system boots from an SD-card with the same devices connected and attach the results of 'lsusb -vvv'. This helps to rule out USB HUB power issues.
In the beta release it's likely that a UART or NetConsole boot trace will be required.

lsusb_vvv.txt

attached is lsusb -vvv output when booted from SD card

Additional context
The drive is mounted when I boot from an SD Card and readable by the OS.

[timg236]

It might be worth increasing the USB_MSD_LUN_TIMEOUT to 5 seconds in-case the NVME enclosure if very slow to initialise.

Once the kernel has started that's the regular Linux USB stack, it might be a UASP issue so try disabling that to run in MSD mode to see if that will boot reliably first
https://www.raspberrypi.org/forums/viewtopic.php?t=245931

[DrizzutoJr]

Steps to increase USB_MSD_LUN_TIMEOUT to 5 seconds:

Booted the Pi from an SD card (one I used to setup SSD Boot)

cp /lib/firmware/raspberrypi/bootloader/beta/pieeprom-2020-07-06.bin pieeprom.bin
rpi-eeprom-config pieeprom.bin > bootconf.txt
# added USB_MD_LUN_TIMEOUT=5000 to bottom of bootconf.txt
rpi-eeprom-config --out pieeprom-new.bin --config bootconf.txt pieeprom.bin
rpi-eeprom-update -d -f ./pieeprom-new.bin
reboot

At this point I then copied the *.dat and *.elf files from my SD /boot folder to SSD /boot folder

cp /boot/*.dat /media/pi/boot
cp /boot*.elf /media/pi/boot

At this point I turned off the device, took out the SD Card and turned on the Device with the SSD in a 3.0 USB slot.

It worked!

Thank you for your help. Is there a blog somewhere that keeps track of SSDs and Enclosures. Would like to help anyone else who may have this issue.

[DrizzutoJr]

Gah, i spoke too soon. The first boot worked, but now the subsequent boots are not working. I am getting a similar error from before:

[sda] Asking for cache data failed
[sda] Assuming drive cache: write through

[DrizzutoJr]

Steps taken from attached link to disable UASP using provided link:

Booted int Raspberry Pi with SD Card and SSD attached.

edited /media/pi/boot/cmdline.txt and added usb-storage=idVendor:idProduct:u to front of file

Rebooted after this with SD card still in

I Checked dmesg again and find

[  151.056442] sd 0:0:0:0: [sda] Spinning up disk...
[  153.288999] .not responding...
[  153.354161] sd 0:0:0:0: [sda] Read Capacity(16) failed: Result: hostbyte=0x00 driverbyte=0x08
[  153.354179] sd 0:0:0:0: [sda] Sense Key : 0x4 [current]
[  153.354194] sd 0:0:0:0: [sda] ASC=0x44 <<vendor>>ASCQ=0x81
[  153.355760] sd 0:0:0:0: [sda] Read Capacity(10) failed: Result: hostbyte=0x00 driverbyte=0x08
[  153.355775] sd 0:0:0:0: [sda] Sense Key : 0x4 [current]
[  153.355791] sd 0:0:0:0: [sda] ASC=0x44 <<vendor>>ASCQ=0x81
[  153.356573] sd 0:0:0:0: [sda] 0 512-byte logical blocks: (0 B/0 B)
[  153.356589] sd 0:0:0:0: [sda] 0-byte physical blocks
[  153.358091] sd 0:0:0:0: [sda] Test WP failed, assume Write Enabled
[  153.358622] sd 0:0:0:0: [sda] Asking for cache data failed
[  153.358642] sd 0:0:0:0: [sda] Assuming drive cache: write through
[  153.360224] sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of physical block size (0 bytes)
[  153.361783] sd 0:0:0:0: [sda] Unit Not Ready
[  153.361799] sd 0:0:0:0: [sda] Sense Key : 0x4 [current]
[  153.361814] sd 0:0:0:0: [sda] ASC=0x44 <<vendor>>ASCQ=0x81
[  153.363357] sd 0:0:0:0: [sda] Read Capacity(16) failed: Result: hostbyte=0x00 driverbyte=0x08
[  153.363373] sd 0:0:0:0: [sda] Sense Key : 0x4 [current]
[  153.363387] sd 0:0:0:0: [sda] ASC=0x44 <<vendor>>ASCQ=0x81
[  153.365095] sd 0:0:0:0: [sda] Read Capacity(10) failed: Result: hostbyte=0x00 driverbyte=0x08
[  153.365120] sd 0:0:0:0: [sda] Sense Key : 0x4 [current]
[  153.365137] sd 0:0:0:0: [sda] ASC=0x44 <<vendor>>ASCQ=0x81
[  153.369814] sd 0:0:0:0: [sda] Attached SCSI disk
[  156.339286] usb 2-2: USB disconnect, device number 4
[  157.839450] usb 2-1: new SuperSpeed Gen 1 USB device number 5 using xhci_hcd
[  157.870637] usb 2-1: New USB device found, idVendor=152d, idProduct=0562, bcdDevice= 2.08
[  157.870652] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  157.870665] usb 2-1: Product: JMS583
[  157.870678] usb 2-1: Manufacturer: JMicron
[  157.870690] usb 2-1: SerialNumber: DD564198838A6
[  157.881650] scsi host0: uas
[  157.883113] scsi 0:0:0:0: Direct-Access     CT500P2S SD8              0208 PQ: 0 ANSI: 6
[  157.884509] sd 0:0:0:0: Attached scsi generic sg0 type 0
[  159.865305] sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/466 GiB)
[  159.865323] sd 0:0:0:0: [sda] 4096-byte physical blocks
[  159.865506] sd 0:0:0:0: [sda] Write Protect is off
[  159.865523] sd 0:0:0:0: [sda] Mode Sense: 5f 00 00 08
[  159.866221] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[  159.866972] sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
[  159.869963]  sda: sda1 sda2
[  159.872972] sd 0:0:0:0: [sda] Attached SCSI disk
[  160.177522] FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[  160.217801] EXT4-fs (sda2): recovery complete
[  160.217816] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)

When I do below command I get:

dmesg | grep usb-storage
# output = usbcore: registered new interface driver usb-strorage

this makes me think the quirk was not setup correctly.

Below is setup of quirk:

pi@raspberrypi:/media/pi/boot $ cat cmdline.txt
usb-storage.quirks=152d:0562:u console=serial0,115200 console=tty1 root=PARTUUID=afa0444e-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
pi@raspberrypi:/media/pi/boot $ sudo dmesg -C
pi@raspberrypi:/media/pi/boot $ dmesg
[  138.209540] usb 2-1: new SuperSpeed Gen 1 USB device number 3 using xhci_hcd
[  138.240742] usb 2-1: New USB device found, idVendor=152d, idProduct=0562, bcdDevice= 2.08
[  138.240757] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  138.240769] usb 2-1: Product: JMS583
[  138.240782] usb 2-1: Manufacturer: JMicron
[  138.240794] usb 2-1: SerialNumber: DD564198838A6
[  138.260606] scsi host1: uas
[  138.263971] scsi 1:0:0:0: Direct-Access     CT500P2S SD8              0208 PQ: 0 ANSI: 6
[  138.266926] sd 1:0:0:0: Attached scsi generic sg0 type 0

Regardless I tried booting from SSD. The boot process ended up hanging on the three raspberry screen. I then went back and undid the above steps to return to the error reported in my previous comment when booting from USB 3.0.

[timg236]

If the raspberries are visible then this sounds like a Linux driver issue at that point the bootloader no longer exists and PCI has been reset. You could try a 5.4 kernel from rpi-update or the latest nightly build http://downloads.raspberrypi.org/nightlies/

[wiz]

One thing I noticed when booting from USB vs booting from SD card, is that when booting from USB the USB devices are powered on at the same time as the RPI, which I has a feeling causes a voltage drop, and may cause random issues. I can only boot once out of every 10 times because of this.

[Ruffio]

@DrizzutoJr have you tried some of the later eeproms regarding boiting from SSD?

[timg236]

@DrizzutoJr It would be worth trying the 2021-01-16 latest image, other users have had success with NVMe enclosures using the same chipset

[timg236]

Closed due to inactivity