cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
philipmolloy
Observer
Observer
1,049 Views
Registered: ‎06-28-2018

NVMe M.2 drive not discovered on PCIe bus

I'm trying to bring up a NVMe M.2 drive on a custom board:

# lspci                                                                                                                       
00:00.0 Class 0604: 10ee:d011 

 

Relevant boot output in dmesg:

 

[    0.400658] nwl-pcie fd0e0000.pcie: Link is DOWN
[    0.405119] OF: PCI: host bridge /amba/pcie@fd0e0000 ranges:
[    0.410736] OF: PCI:   MEM 0xe0000000..0xefffffff -> 0xe0000000
[    0.416593] OF: PCI:   MEM 0x600000000..0x7ffffffff -> 0x600000000
[    0.422845] nwl-pcie fd0e0000.pcie: PCI host bridge to bus 0000:00
[    0.428877] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.434323] pci_bus 0000:00: root bus resource [mem 0xe0000000-0xefffffff]
[    0.441156] pci_bus 0000:00: root bus resource [mem 0x600000000-0x7ffffffff p
ref]
[    0.448610] pci 0000:00:00.0: [10ee:d011] type 01 class 0x060400
[    0.448664] pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot
[    0.448833] pci 0000:00:00.0: PCI bridge to [bus 01-0c]

 

 

There's a active low reset line to the SSD that is high. The clock frequency in Vivado and the device tree look correct.

 

I'm not really sure what the best next steps are.

 

  • Check PCIe controller registers to see the state after boot? There are a lot of AXIPCIE_* registers
  • Review the many PCIe ARs?
  • Add debugging statements to the scanning code in the generic Linux PCIe driver code?
  • Look-up the NVMe M.2 pinout and try to rescan in Linux to see if the scan makes it's way to the drive and if the drive responds?
0 Kudos
Reply
2 Replies
philipmolloy
Observer
Observer
1,000 Views
Registered: ‎06-28-2018

Also worth noting we started with 2017.4 before moving to 2018.2. As a result I've been using `zynqmp-clk.dtsi` as opposed to `zynqmp-clk-ccf.dtsi` in our device tree. Switching to the CCF caused a bunch of drivers to fail to find their respective clocks (e.g. serial, ethernet, emmc). I've added the following to our device tree at least temporarily and continued to use `zynqmp-clk.dtsi`.

 

&pcie {
    status = "okay";
    clocks = <&clk125>;
    clocks-names = "pcie_ref";
};

 

0 Kudos
Reply
electrodev99
Observer
Observer
795 Views
Registered: ‎05-07-2018

Any progress on this? Thanks!

0 Kudos
Reply