Issues with Ventuno Q (m.2, tmp, App Lab)

Official Hardware VENTUNO Q
10

Adding another data point: Fikwot FX953 1TB (M.2 2230, NVMe PCIe Gen4 x4) is never detected on my VENTUNO Q. It doesn't help to cold boot, warm reboot, re-seat the drive, or force ASPM off. Unlike the KingSpec report above, a warm reboot does not bring it up.

Setup

  • Arduino VENTUNO Q, stock Ubuntu 24.04.5 LTS image
  • Kernel 6.8.0-1084-qcom #89-Ubuntu (latest in noble-updates; the qcom PPA only has 1079)
  • DT: monaco-monza.dtb + monaco-addons-monza.dtb + overlay, from /lib/firmware/6.8.0-1084-qcom/device-tree/qcom/
  • Drive: Fikwot FX953 1TB, 2230, NVMe Gen4 x4, single M-key. It's seated fully and held with the 2230 standoff screw.

What the kernel reports (identical on every boot)

qcom-pcie 1c10000.pci: supply vddpe-3v3 not found, using dummy regulator
qcom-pcie 1c10000.pci: host bridge /soc@0/pci@1c10000 ranges:
qcom-pcie 1c10000.pci: iATU: unroll T, 32 ob, 8 ib, align 4K, limit 1024G
qcom-pcie 1c10000.pci: Phy link never came up
qcom-pcie 1c10000.pci: PCI host bridge to bus 0001:00
pci 0001:00:00.0: [17cb:0115] type 01 class 0x060400 PCIe Root Port
  • lspci shows only the root port 0001:00:00.0, with nothing behind it. There's no /dev/nvme*.
  • AER on 0001:00:00.0: 0 fatal, 0 correctable. The link never trains, so it never errors either.
  • PCIe0 (1c00000.pci) comes up fine as Gen2 x1 to the Pericom switch / Wi-Fi.

PCIe1 / M.2 configuration as seen at runtime

  • pci@1c10000: status = "okay", num-lanes = 4, root port max 16.0 GT/s x4
  • perst-gpios = <&tlmm 23 GPIO_ACTIVE_LOW>, wake-gpios = <&tlmm 21 ...>
  • vdda-supply → fixed regulator nvme_vreg_en (enable GPIO tlmm 51, active-high, enable-ramp-delay 10000 µs). Its state is enabled, it has 1 user (1c10000.pci-vdda), and it reports 1.8 V.
  • vddpe-3v3 isn't defined, so the driver uses a dummy regulator.
  • The nvme driver is available (nvme.ko).

Question for Arduino: the enable for the M.2 slot's power (nvme_vreg_en) is hooked up as the PCIe PHY's vdda-supply and not as vddpe-3v3. Is that intended? If it only controls slot 3.3 V, its timing relative to PERST# may differ from what the driver does for vddpe-3v3. With a 10 ms ramp, some drives may not be ready before link training times out. I'm only guessing at this from the DT; I don't have the schematic.

What I tried

Attempt Result
Re-seat drive (full power-off and unplug first) Phy link never came up
Cold boot (power cycle) Phy link never came up
Warm reboot (sudo reboot) Not detected (no nvme0 in that boot)
pcie_aspm.policy=performance added via /etc/default/grub.d/99-dragonwing-defaults.cfg + update-grub (confirmed in /proc/cmdline and /sys/module/pcie_aspm/parameters/policy = [performance]) No change. Still not detected

Full cmdline during the ASPM test:

BOOT_IMAGE=/boot/vmlinuz-6.8.0-1084-qcom root=UUID=... ro console=ttyMSM0,115200n8 pcie_pme=nomsi earlycon pcie_aspm.policy=performance video=LVDS-1:d

Side observations that may matter

  1. Kernel log flooding hides the PCIe1 messages. Every boot, Pericom switch port 0000:02:02.0 (the onboard TI TUSB73x0 USB 3 controller, pci104c,8241) throws hundreds to thousands of Uncorrectable (Fatal) AER errors (Transaction Layer, status 0x1/0x2001 = Undefined + FCP). That overwrites the early boot log in dmesg, so you need journalctl -k to see the M.2 lines. The count was 369–1,699 per boot before the ASPM change and 3,750 with pcie_aspm.policy=performance. Separate topic: VENTUNO Q: onboard TI USB 3 controller (PCIe 104c:8241) never enumerates — 1,699 fatal AER errors on Pericom switch port 0000:02:02.0 at boot
  2. Both USB-A ports are dead on this image, because they sit behind that TI controller. A SanDisk Extreme 2TB, a mouse and a keyboard produce no USB events. Plugging a device in triggers a new fatal AER on 02:02.0. So with this image, the only way to attach an NVMe through a USB enclosure is the USB-C port.
  3. One unexplained hard reset or hang about 4 minutes after a warm reboot (the journal just stops; no panic logged). It happened only once, so it may be unrelated.

Next steps on my side

  • Test the Fikwot in a USB-C NVMe enclosure on another machine to rule out a bad drive.
  • I'm happy to test a candidate kernel or DT (e.g. qcom-6.18.y with the VENTUNO Q series from qualcomm-linux/kernel PR #1013) or run any diagnostic you suggest.

Is there an Ubuntu kernel/DT update planned for VENTUNO Q that covers PCIe1 / M.2 bring-up, or a list of drives Arduino has validated?