On Mon, 2 Mar 2026 13:59:40 +0100
Torsten Duwe <[email protected]> wrote:
> This proposed patch uses the already existent dev_phys_to_bus(),
> which can dig up the correct offset from associated DT nodes and
> subtract it.
Just to make it clear, that patch is a necessary but not a sufficient
condition to boot the RPi5 from NVMe. The PCIe bus node above
the NVMe is generated dynamically has no DT node with dma-ranges and so
dev_phys_to_bus() still returns zero. In order to test NVMe on the
RPi5 you can either:
hard code the 64GiB value when building your private U-Boot binary:
-#define BUS_ADDR(a) dev_phys_to_bus(dev->udev, (a))
+#define BUS_ADDR(a) ((a)+0x1000000000LL)
OR use this tricky DT change Andrea has prepared:
--- a/dts/upstream/src/arm64/broadcom/bcm2712.dtsi
+++ b/dts/upstream/src/arm64/broadcom/bcm2712.dtsi
@@ -571,6 +571,15 @@
<0x03000000 0xff 0xfffff000 0x10 0x00131000
0x00 0x00001000>;
status = "disabled";
+
+ pci@0,0 {
+ reg = <0x00 0x00 0x00 0x00 0x00>;
+ device_type = "pci";
+ #address-cells = <0x03>;
+ #size-cells = <0x02>;
+ ranges;
+ dma-ranges;
+ };
};
pcie2: pcie@1000120000 {
This pci@0,0 node needs to be below the pcie@1000110000 RC node so it
can "bridge" dev_phys_to_bus() to the RC node when it climbs up the
device tree and so helps it find the correct value.
AFAICS the proper fix should be to add some dma-ranges property when
dynamic PCI devices are created during enumeration/scan or make
dev_phys_to_bus() skip those nodes for the lookup.
Torsten
