Hi,
I can’t recognize SATA NVMe M.2 disk.
I added the module on U-boot defconfig:
- CONFIG_NVME=y
- CONFIG_NVME_PCI=y
Marvell>> nvme info
Marvell>> nvme scan
Marvell>> nvme
nvme - NVM Express sub-system
Usage:
nvme scan - scan NVMe devices
nvme detail - show details of current NVMe device
nvme info - show all available NVMe devices
nvme device [dev] - show or set current NVMe device
nvme part [dev] - print partition table of one or all NVMe devices
nvme read addr blk# cnt - read `cnt' blocks starting at block
`blk#' to memory address `addr'
nvme write addr blk# cnt - write `cnt' blocks starting at block
`blk#' from memory address `addr'
what should I do to see the sata disk M.2 NVMe connected to the ClearFog-Pro card?
the sata disk is NVMe M.2
Obviously if connected to other PCs it works correctly
Thanks for your help
The nvme commands in u-boot are only for PCIe NVMe devices. For SATA based m.2 SSDs you need to use the scsi commands.
Thanks Jnettlet,
although scsi is enabled by default in u-boot and finding the relative commands the disk is not detected.
DRAM: 4 GiB
Running in RAM - U-Boot at: 0x7feee000
Env at: 0x7ff9b5d7
Comphy chip #0:
Comphy-0: SATA1
Comphy-1: USB3_HOST0
Comphy-2: SFI0 10.3125 Gbps
Comphy-3: SGMII1 1.25 Gbps
Comphy-4: PEX1
Comphy-5: PEX2
UTMI PHY 0 initialized to USB Host0
UTMI PHY 1 initialized to USB Host1
PCIE-0: Link down
PCIE-2: Link down
NAND: 0 MiB
MMC: sdhci@6e0000: 0, sdhci@780000: 1
Loading Environment from MMC... *** Warning - bad CRC, using default environment
Net:
Warning: mvpp2-0 (eth0) using random MAC address - 32:f6:f4:34:c8:f6
eth0: mvpp2-0 [PRIME]
Warning: mvpp2-1 (eth1) using random MAC address - a2:cc:97:e5:7a:a1
, eth1: mvpp2-1
Warning: mvpp2-2 (eth2) using random MAC address - 0e:d6:be:97:51:73
, eth2: mvpp2-2
Hit any key to stop autoboot: 0
Marvell>> scsi
scsi - SCSI sub-system
Usage:
scsi reset - reset SCSI controller
scsi info - show available SCSI devices
scsi scan - (re-)scan SCSI bus
scsi device [dev] - show or set current device
scsi part [dev] - print partition table of one or all SCSI devices
scsi read addr blk# cnt - read `cnt' blocks starting at block `blk#'
to memory address `addr'
scsi write addr blk# cnt - write `cnt' blocks starting at block
`blk#' from memory address `addr'
Marvell>> scsi scan
scanning bus for devices...
Marvell>> scsi info
Marvell>> scsi device
no scsi devices available
Do I have to check some specific module in the u-boot defconfig?
It should just require CONFIG_AHCI_MVEBU and DM_SCSI should be selected automatically.
the first was enabled by default, the second I enabled:
CONFIG_DM_SCSI=y
but nothing, I added:
CONFIG_SCSI=y
CONFIG_SCSI_AHCI=y
but nothing, it is not recognized any further ideas?
in Linux i find this:
root@localhost:~# journalctl -k | grep -i scsi
Feb 13 17:29:03 localhost kernel: SCSI subsystem initialized
Feb 13 17:29:03 localhost kernel: Block layer SCSI generic (bsg) driver version 0.4 loaded (major 244)
Feb 13 17:29:03 localhost kernel: scsi host0: ahci
Feb 13 17:29:03 localhost kernel: scsi host1: ahci
Unfortunately I got the wrong product (PCIe NVMe M.2).
I tried with a new SATA M.2 SSD disk and it is correctly recognized with command:
scsi scan
thanks for the quick reply!
What gave you the idea that a PCIe NVMe M.2 drive would be, “the wrong type” ? I am also having trouble recognizing NVMe drives, and esp given your situation, it seems to me that the difference between SATA and NVMe support would be in software, as both are protocols on top of PCIe.
CONFIG_NVME should be y by default in Linux, but I’ve been meaning to dig into the build code and see if that is the case for the default CN913x image.
NOTE: I am on CN9132, but I think that mostly just means I have more M.2 slots than your CN9130.
One of the failures of the m.2 “keying” system to determine the signal layout but no standardized mechanism for detecting the actual type of medium installed in the slot. There is a hack workaround that some manufacturers use for attempting to detect between PCIe and SATA storage devices by trying to distinguish a PIN that is usually not populated on the SATA drives and is usually pulled low on PCIe NVMe devices, but that is not a 100% thing.
On the CN913x and others all the low level signalling is actually SERDES not PCIe. The question is whether the SOC can connect either a SATA controller port or PCIe controller port to the specific SERDES that is routed to the specific connector. Not every set of SERDES lanes can necessarily be one or the other (although sometimes they can) which is why some m.2 slots can only use SATA SSDs.
1 Like
Interesting! Does this mean it might be worth trying an NVMe device in different m.2 slots on the CN9132?
Yes, or test the SystemReady ES edk2 based firmware that was done for the board. I know that was configured to use all the slots as PCIe NVMe. It could also just be a device-tree change that needs to be done.
Thanks, that makes sense.
Can you provide a pointer to the SystemReady ES edk2 firmware? I found source for building it for LX2K on SolidRun github, but there doesn’t seem to be a branch or config for CN9132.
Also seeing those branches are years out of date, I’m happy to try rebasing and getting a more modern build if I can get breadcrumbs into a known good build. 
Best,
J