Date: Thu, 24 Sep 2020 23:33:44 -0700 From: Mark Millard <marklmi@yahoo.com> To: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: dtb pcie content for RPi4B: older vs. newer Message-ID: <4498F94F-6E23-4988-9564-DA3CF87A46A7@yahoo.com> In-Reply-To: <6954779B-E31D-45A1-AEAB-5FE82D02D47E@yahoo.com> References: <6954779B-E31D-45A1-AEAB-5FE82D02D47E@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Sep-24, at 22:10, Mark Millard <marklmi at yahoo.com> wrote: > Basically just some notes from my looking around . . . >=20 > I've used dtc -O dtb -s -I dts on the .dtb file from the rpi4-uefi-dev > v1.20 and on the .dtb file from downloading: >=20 > = https://sourceforge.net/projects/rpi4-8gb-uboot-bcm2711-backup/files/bcm27= 11-rpi-4-b.dtb/download >=20 > Looking at explicit mentions of pci I find: >=20 > # diff -u999 ~/rpi4-ub.dts ~/rpi4-uefi.dts | grep -i pci | more > - pcie_0 =3D "/scb/pcie@7d500000"; > + pcie0 =3D "/scb/pcie@7d500000"; > + pcie0 =3D "/scb/pcie@7d500000"; > pcie@7d500000 { > - compatible =3D "brcm,bcm7211-pcie", = "brcm,bcm7445-pcie", "brcm,pci-plat-dev"; > + compatible =3D "brcm,bcm2711-pcie"; > + device_type =3D "pci"; > interrupt-names =3D "pcie", "msi"; > - linux,pci-domain =3D <0x0>; > - tot-num-pcie =3D <0x1>; >=20 > The main place in more detail: >=20 > pcie@7d500000 { >=20 > #address-cells =3D <0x3>; > #interrupt-cells =3D <0x1>; > #size-cells =3D <0x2>; > - bus-range =3D <0x0 0x1>; > - compatible =3D "brcm,bcm7211-pcie", = "brcm,bcm7445-pcie", "brcm,pci-plat-dev"; > - dma-ranges =3D <0x2000000 0x0 0x0 0x0 0x0 0x1 = 0x0>; > - interrupt-map =3D <0x0 0x0 0x0 0x1 0x1 0x0 = 0x8f 0x4 0x0 0x0 0x0 0x2 0x1 0x0 0x90 0x4 0x0 0x0 0x0 0x3 0x1 0x0 0x91 = 0x4 0x0 0x0 0x0 0x4 0x1 0x0 0x92 0x4>; > + brcm,enable-ssc; > + compatible =3D "brcm,bcm2711-pcie"; > + device_type =3D "pci"; > + dma-ranges =3D <0x2000000 0x0 0x0 0x0 0x0 0x0 = 0xc0000000>; > + interrupt-map =3D <0x0 0x0 0x0 0x1 0x1 0x0 = 0x8f 0x4>; > interrupt-map-mask =3D <0x0 0x0 0x0 0x7>; > interrupt-names =3D "pcie", "msi"; > interrupts =3D <0x0 0x94 0x4 0x0 0x94 0x4>; > - linux,pci-domain =3D <0x0>; > - max-link-speed =3D <0x2>; > msi-controller; > - msi-parent =3D <0x22>; > - phandle =3D <0x22>; > + msi-parent =3D <0x2a>; > + phandle =3D <0x2a>; > ranges =3D <0x2000000 0x0 0xf8000000 0x6 0x0 = 0x0 0x4000000>; > - reg =3D <0x0 0x7d500000 0x9310 0x0 0x7e00f300 = 0x20>; > - status =3D "okay"; > - tot-num-pcie =3D <0x1>; > + reg =3D <0x0 0x7d500000 0x0 0x9310>; > }; >=20 >=20 > What I get out of: >=20 > - dma-ranges =3D <0x2000000 0x0 0x0 0x0 0x0 0x1 = 0x0>; > vs: > + dma-ranges =3D <0x2000000 0x0 0x0 0x0 0x0 0x0 = 0xc0000000>; >=20 > is that the older one (-) sets a 4 GiByte dma-range > and the modern one (+) sets a 3 GiByte dma-range. >=20 > The modern one also has: >=20 > + emmc2bus { > + > + #address-cells =3D <0x2>; > + #size-cells =3D <0x1>; > + compatible =3D "simple-bus"; > + dma-ranges =3D <0x0 0xc0000000 0x0 0x0 0x40000000>; > + phandle =3D <0xce>; > + ranges =3D <0x0 0x7e000000 0x0 0xfe000000 0x1800000>; >=20 > that spans the last 1 GiByte for 32-bits that it omitted above. ["last 1 GiByte of the 4 GiByte space for 32-bit addressing" would have been better wording.] emmc2bus is not the only modern dtb thing that does: soc does. In ACPI, soc's usb@7e980000 does, not soc generally and there is no emmc2bus via ACPI. See notes added at the bottom. > Based on a filtered/edited egrep = '(address-cells|size-cells|dma-range)' > of the differences output there is: >=20 > / { > #address-cells =3D <0x2>; > #size-cells =3D <0x1>; > . . . > + emmc2bus { > + #address-cells =3D <0x2>; > + #size-cells =3D <0x1>; > + dma-ranges =3D <0x0 0xc0000000 0x0 0x0 0x40000000>; > . . . > scb { > - #address-cells =3D <0x2>; > - #size-cells =3D <0x1>; > - dma-ranges =3D <0x0 0x0 0x0 0x0 0xfc000000>; > + #address-cells =3D <0x2>; > + #size-cells =3D <0x2>; > + dma-ranges =3D <0x0 0x0 0x0 0x0 0x4 0x0>; > . . . > pcie@7d500000 { > #address-cells =3D <0x3>; > #size-cells =3D <0x2>; > - dma-ranges =3D <0x2000000 0x0 0x0 0x0 0x0 0x1 = 0x0>; > + dma-ranges =3D <0x2000000 0x0 0x0 0x0 0x0 0x0 = 0xc0000000>; > soc { > #address-cells =3D <0x1>; > #size-cells =3D <0x1>; > - dma-ranges =3D <0xc0000000 0x0 0x0 0x3c000000>; > + dma-ranges =3D <0xc0000000 0x0 0x0 0x40000000>; > . . . > firmware { > #address-cells =3D <0x1>; > #size-cells =3D <0x0>; > + dma-ranges; > . . . > v3dbus { > #address-cells =3D <0x1>; > - #size-cells =3D <0x1>; > + #size-cells =3D <0x2>; > - dma-ranges =3D <0x0 0x0 0x0 0x3c000000>; > + dma-ranges =3D <0x0 0x0 0x0 0x4 0x0>; >=20 > So the older one has smaller scb, soc, and v3dbus ranges. >=20 > Looking at acpi dump information (modern based) there is: >=20 > . . . > Name (_DMA, ResourceTemplate () // _DMA: Direct Memory = Access > { > QWordMemory (ResourceConsumer, PosDecode, MinFixed, = MaxFixed, NonCacheable, ReadWrite, > 0x0000000000000000, // Granularity > 0x0000000000000000, // Range Minimum > 0x00000000BFFFFFFF, // Range Maximum > 0x0000000000000000, // Translation Offset > 0x00000000C0000000, // Length > ,, , AddressRangeMemory, TypeStatic) > }) > Device (XHC0) > . . . > Name (_DMA, ResourceTemplate () // _DMA: Direct Memory = Access > { > QWordMemory (ResourceConsumer, PosDecode, MinFixed, = MaxFixed, NonCacheable, ReadWrite, > 0x0000000000000000, // Granularity > 0x00000000C0000000, // Range Minimum > 0x00000000FFFFFFFF, // Range Maximum > 0xFFFFFFFF40000000, // Translation Offset > 0x0000000040000000, // Length > ,, , AddressRangeMemory, TypeStatic) > }) > Device (USB0) > . . . >=20 > So it appears that: > XHC0 matches up with modern pcie@7d500000 > USB0 matches up with modern emmc2bus > scb, soc, v3dbus, and possibly firmware, do not have dma ranges = described by ACPI. Actually USB0 could match either modern emmc2bus or modern soc based on the dma-ranges. Looking at other notation, I'd guess it is really tied to soc via: soc { . . . usb@7e980000 { where the 7e980000 matches up with the RBAS 0xFE980000 in the ACPI: Device (USB0) { . . . Method (_CRS, 0, Serialized) // _CRS: Current Resource = Settings { CreateDWordField (RBUF, \_SB.GDV0.USB0._Y18._BAS, = RBAS) // _BAS: Base Address RBAS =3D 0xFE980000 Return (RBUF) /* \_SB_.GDV0.USB0.RBUF */ } } So it appears that: XHC0 matches up with modern pcie@7d500000 . USB0 matches up with usb@7e980000 under modern soc . scb, soc (generally), emmc2bus, v3dbus, and possibly firmware, each modern, do not have dma ranges described by ACPI. NOTE: the older dtb has emmc2@7e340000 under soc instead of the modern style of emmc2bus being separate, outside soc . =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4498F94F-6E23-4988-9564-DA3CF87A46A7>