Hi, On Sun, Mar 12, 2023 at 09:13:12PM +0100, Mark Kettenis wrote: > [...] > > It seems translation isn't actually broken. At least I got it to work > with a slight twist. What seems to be happening is that reads (and > writes?) to the first 64 MB of the PCIe memory address space > (0x00000000-0x03ffffff) don't make it out to the PCIe device. I > suspect they are somehow claimed by the RC, maybe because the BAR for > the root complex isn't properly disabled. > > If I change the PCIe bus addess of the mmio window from 0x00000000 to > 0x40000000 like so: > > ranges = <0x01000000 0x0 0x3ef00000 0x3 0x3ef00000 0x0 0x00100000 > 0x02000000 0x0 0x40000000 0x3 0x00000000 0x0 0x3ef00000>; > > my NVMe drive seems to work just fine. I picked 0x40000000 here > because it is nicely aligned on a 1GB boundary, which matches the size > of the region. Diff against a recent linux-next at the end of this > mail. > > So what I think is happening is that Linux is allocating resources > from the top of the region. So only if you have a more complicated > PCIe hierarchy it ends up allocating from the low 64 MB and runs into > the issue. OpenBSD on the other hand allocates from the bottom, which > pretty much guarantees that I hit the issue. > > Now this could be a driver bug. As far as I can tell BAR0/1 is > properly disabled, but maybe there is some additional bit that we need > to set. But I don't think there are any downsides of my workaround. > We can still provide a ~1GB mmio range; it just starts at 0x40000000 > instead of 0x00000000. > > Maybe somebody can test this on Linux? There were other discussions and patches posted, and further testing happened since this discussion (just by looking at the dates...). The result was: https://lore.kernel.org/lkml/20221112114125.1637543-1-aholmes@xxxxxxxxx/ https://lore.kernel.org/lkml/20221112114125.1637543-2-aholmes@xxxxxxxxx/ The changes for pcie2x1 in that patch make PCIe work on Linux under many different device combinations, incl. with various combinations of devices behind PCIe switch, etc. That patch includes your change, too. (The patch is not correct for pcie3, see discussion.) kind regards, o. > > > b. We do in fact require IO and Config to be 32 bit addressable to be > > > fully compatible. > > > > > > These issues are compounded in rk3588 where we have much smaller > > > regions in the 32bit space for PCIe, so a definite answer on the true > > > requirements and limitations would be quite helpful. > > > > > > As always, thank you for your time, > > > Peter > > diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts/rockchip/rk356x.dtsi > index eed0059a68b8..218e51f41852 100644 > --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi > +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi > @@ -983,7 +983,7 @@ pcie2x1: pcie@fe260000 { > phy-names = "pcie-phy"; > power-domains = <&power RK3568_PD_PIPE>; > ranges = <0x01000000 0x0 0x3ef00000 0x3 0x3ef00000 0x0 0x00100000 > - 0x02000000 0x0 0x00000000 0x3 0x00000000 0x0 0x3ef00000>; > + 0x02000000 0x0 0x40000000 0x3 0x00000000 0x0 0x3ef00000>; > resets = <&cru SRST_PCIE20_POWERUP>; > reset-names = "pipe"; > #address-cells = <3>;
