Hi Torsten, On Mon, Mar 02, 2026 at 04:42:56PM +0100, Torsten Duwe wrote: > 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: >
Say I wanted to test NVMe booting on the pi5 (which I actually do). I would need: 1) this patch 2) one of the two BUS_ADDR() related diffs 3) the fixes posted in https://lore.kernel.org/u-boot/[email protected]/ 4) anything else? Thanks, Pedro > 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
