Board: Xunlong Orange Pi RV (StarFive JH7110, 8GB)
Goal: Fedora 43 riscv64 on NVMe via OpenSBI + mainline U-Boot v2026.01 (EFI) + systemd-boot + BLS
The board has no mainline DTS in 6.18, so I authored one from the VF2 v1.3B DTS as template and the decompiled vendor DTB as hardware ground truth. U-Boot EEPROM matching needed a two-part patch to spl.c to prevent the VF2 v1.3B entry (7-char match) from shadowing the Orange Pi RV entry (13-char match on VF7110B1-2228) — that is resolved and working.
Boot chain target:
SPI NOR → U-Boot SPL → OpenSBI fw_dynamic → U-Boot proper (Orange Pi RV DTB)
→ bootefi → systemd-boot → kernel 6.18.0 + jh7110-orangepi-rv.dtb → Fedora 43 rootfs on nvme0n1p2
U-Boot, OpenSBI, kernel handoff, DRAM, serial, ethernet, MMC, and systemd are all working. The kernel boots cleanly into Fedora 43 userspace when the rootfs is on the SD card. The remaining blocker is PCIe — which lives entirely in the kernel, not in U-Boot.
The problem
Kernel never initializes PCIe. At the 10-second deferred-probe deadline:
jh71xx-pmu 17010000.syscon: sync_state() pending due to 19820000.phy
jh71xx-pmu 17030000.power-controller: sync_state() pending due to 19810000.clock-controller
jh71xx-pmu 17030000.power-controller: sync_state() pending due to 295c0000.clock-controller
platform 16050000.dma-controller: deferred probe pending: (reason unknown)
No pcie-starfive lines appear at all. The PHY at 19820000 never probes, the power domain never satisfies sync_state, and the PCIe controllers (940000000.pcie, 9c0000000.pcie) never initialize.
What I know
PCIe works — confirmed in two scenarios:
-
The initial successful boot (Mar 03, anomalous): U-Boot was inadvertently running the VF2 DTB for itself but passing the Orange Pi RV DTB to the kernel via
fdtfile. PCIe came up fully, NVMe enumerated correctly. Not reproducible since U-Boot was corrected. -
Boot to SD card rootfs (
root=/dev/mmcblk1p2) with the same kernel, same DTB, same U-Boot sequence: PCIe comes up fully and NVMe is visible alongside the SD card. Reproducible.
PCIe fails when the kernel command line targets NVMe rootfs (root=/dev/nvme0n1p2) — same kernel, same DTB, same U-Boot.
The root= target should not affect PCIe initialization. I’m aware that root=/dev/nvme0n1p2 causes the kernel to hold at Waiting for root device which keeps the initcall machinery running longer — but the deferred probe timeout is fixed at 10 seconds regardless, and the PHY never appears in dmesg even before the timeout fires.
Attempts made
| What I tried | Result |
|---|---|
| Remove SD card entirely | PCIe still fails |
Replace bootefi bootmgr with direct bootefi addr addr |
Still fails |
Remove nvme scan from bootcmd |
Still fails |
sleep 5 before kernel load |
Still fails |
pci enum at U-Boot prompt before booting |
Still fails |
| Manual boot sequence (same commands as bootcmd, typed interactively) | Still fails |
| Boot to SD card rootfs, otherwise identical | PCIe works  |
The question
What does the 19820000.phy (PCIe PHY) require from the DTS power/clock domain graph that the VF2 DTS satisfies and my Orange Pi RV DTS may not? The VF2 DTS and my DTS use the same jh7110-common.dtsi include — the PCIe nodes, PHY bindings, clock/reset references, and power domains are structurally identical to my eye. The AXP15060 PMIC is detected and initialized on every boot; I suspect the difference may be in how PCIe power rails are described relative to the PMIC, but I haven’t found it.
DTS posted as a gist for reference (no upstream ambitions yet — sharing for diagnosis): gist:4c0eba65e4c86ed627df34befd4f5765 · GitHub
Any pointer to what the probe framework needs to see in the DTS to let 19820000.phy satisfy sync_state is what I’m after.