Xavier is not detecting FPGA, while same FPGA is being detected on Windows PC.
1. XDMA Driver — Installed Successfully
Built and installed the Xilinx DMA IP driver (xdma.ko) from source against the 5.10.216-tegra kernel headers. The module loads cleanly but creates no /dev/xdma* device nodes because the FPGA is never enumerated.
2. Xavier Max Mode — Set
sudo nvpmodel -m 0
sudo jetson_clocks
3. PCIe Controller Status at Boot
The Xavier has 6 PCIe controllers. Only C1 (14100000) links up (to the onboard Marvell SATA controller). The x16 slot controllers C5 (14180000) and C0 (141a0000) both report:
tegra194-pcie 14180000.pcie: Phy link never came up
tegra194-pcie 141a0000.pcie: Phy link never came up
C0 also reports:
tegra194-pcie 141a0000.pcie: Failed to get slot regulators: -517
This is a deferred probe (EPROBE_DEFER) — C0 eventually probes but still fails link training.
4. Boot Race Condition
A timing problem exists at boot:
-
C5 probes at t=4.3s and gives up at t=5.4s
-
C0 doesn’t even start probing until t=6.9s
-
C0 controls the slot power regulators (
vpcie3v3,vpcie12v) for the M.2 slot and has a PERST# GPIO (nvidia,plat-gpios) -
This means C5 attempts link training before C0 has initialized
5. PCIe Pinmux — All Unclaimed
pin 197 (PEX_L5_CLKREQ_N_PGG0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 198 (PEX_L5_RST_N_PGG1): (MUX UNCLAIMED) (GPIO UNCLAIMED)
PEX_L5_RST_N (PERST# for the x16 slot) was found as input LOW in the GPIO debug output — meaning the FPGA was being held in reset. The tegra194-pcie driver controls this internally during its probe sequence.
6. DTB Modifications Made
All changes made to /boot/dtb/kernel_tegra194-p2888-0001-p2822-0000.dtb:
a) PCIe regulators — added regulator-always-on
regulator@115 {
regulator-name = "vdd-3v3-pcie";
regulator-boot-on;
regulator-always-on; /* ADDED */
};
regulator@116 {
regulator-name = "vdd-12v-pcie";
regulator-boot-on;
regulator-always-on; /* ADDED */
};
b) PEXCLK pad controller — enabled
pinctrl@3790000 {
compatible = "nvidia,tegra194-pexclk-padctl";
status = "okay"; /* was: "disabled" */
};
Note: Even though the node is now okay in the live device tree, there is no tegra194-pexclk-padctl driver in the L4T 5.10 kernel — the device registers but never binds to a driver.
c) nvidia,max-speed — reduced from Gen4 to Gen3
This is our current/latest change, not yet tested:
/* C5 (14180000) — x16 slot */
nvidia,max-speed = <0x03>; /* was: 0x04 (Gen4 / 16GT/s) */
/* C0 (141a0000) */
nvidia,max-speed = <0x03>; /* was: 0x04 (Gen4 / 16GT/s) */
The key observation: C1 (the only working controller) has nvidia,max-speed = 2 (Gen2). C5 and C0 both had nvidia,max-speed = 4 (Gen4 / 16GT/s). The ZU47DR only supports Gen3 (8GT/s) maximum. We believe the Tegra194 PCIe driver pre-configures the PHY equalization settings based on nvidia,max-speed before starting link training, and Gen4 PHY configuration is electrically incompatible with a Gen3-only endpoint causing the PHY to never achieve link even at the physical layer.
