Date: Fri, 25 Sep 2020 14:06:22 -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: <3B00D4C4-1765-4B91-8D1E-1080799A46DE@yahoo.com> In-Reply-To: <4498F94F-6E23-4988-9564-DA3CF87A46A7@yahoo.com> References: <6954779B-E31D-45A1-AEAB-5FE82D02D47E@yahoo.com> <4498F94F-6E23-4988-9564-DA3CF87A46A7@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Sep-24, at 23:33, Mark Millard <marklmi zt yahoo.com> wrote: > On 2020-Sep-24, at 22:10, Mark Millard <marklmi at yahoo.com> wrote: >=20 >> 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. >=20 > ["last 1 GiByte of the 4 GiByte space for 32-bit addressing" would = have > been better wording.] >=20 > 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. >=20 >> 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. >=20 > 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: >=20 > soc { > . . . > usb@7e980000 { >=20 > where the 7e980000 matches up with the RBAS 0xFE980000 > in the ACPI: >=20 > 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 */ > } > } >=20 > So it appears that: > XHC0 matches up with modern pcie@7d500000 . > USB0 matches up with usb@7e980000 under modern soc . >=20 > scb, soc (generally), emmc2bus, v3dbus, and possibly firmware, > each modern, do not have dma ranges described by ACPI. >=20 > NOTE: the older dtb has emmc2@7e340000 under soc instead > of the modern style of emmc2bus being separate, outside soc . Another potentially interesting oddity for old vs. new is easier shown by consolidating some old vs. new separately. Old: scb { - #address-cells =3D <0x2>; - #size-cells =3D <0x1>; - dma-ranges =3D <0x0 0x0 0x0 0x0 0xfc000000>; . . . pcie@7d500000 { #address-cells =3D <0x3>; #size-cells =3D <0x2>; - dma-ranges =3D <0x2000000 0x0 0x0 0x0 0x0 0x1 = 0x0>; So scb size < pcie@7d500000 size. New: scb { + #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 0x0 = 0xc0000000>; so pcie@7d500000 size < scb size . =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?3B00D4C4-1765-4B91-8D1E-1080799A46DE>