dtb pcie content for RPi4B: older vs. newer
Mark Millard
marklmi at yahoo.com
Fri Sep 25 06:33:50 UTC 2020
On 2020-Sep-24, at 22:10, Mark Millard <marklmi at yahoo.com> wrote:
> Basically just some notes from my looking around . . .
>
> 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:
>
> https://sourceforge.net/projects/rpi4-8gb-uboot-bcm2711-backup/files/bcm2711-rpi-4-b.dtb/download
>
> Looking at explicit mentions of pci I find:
>
> # diff -u999 ~/rpi4-ub.dts ~/rpi4-uefi.dts | grep -i pci | more
> - pcie_0 = "/scb/pcie at 7d500000";
> + pcie0 = "/scb/pcie at 7d500000";
> + pcie0 = "/scb/pcie at 7d500000";
> pcie at 7d500000 {
> - compatible = "brcm,bcm7211-pcie", "brcm,bcm7445-pcie", "brcm,pci-plat-dev";
> + compatible = "brcm,bcm2711-pcie";
> + device_type = "pci";
> interrupt-names = "pcie", "msi";
> - linux,pci-domain = <0x0>;
> - tot-num-pcie = <0x1>;
>
> The main place in more detail:
>
> pcie at 7d500000 {
>
> #address-cells = <0x3>;
> #interrupt-cells = <0x1>;
> #size-cells = <0x2>;
> - bus-range = <0x0 0x1>;
> - compatible = "brcm,bcm7211-pcie", "brcm,bcm7445-pcie", "brcm,pci-plat-dev";
> - dma-ranges = <0x2000000 0x0 0x0 0x0 0x0 0x1 0x0>;
> - interrupt-map = <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 = "brcm,bcm2711-pcie";
> + device_type = "pci";
> + dma-ranges = <0x2000000 0x0 0x0 0x0 0x0 0x0 0xc0000000>;
> + interrupt-map = <0x0 0x0 0x0 0x1 0x1 0x0 0x8f 0x4>;
> interrupt-map-mask = <0x0 0x0 0x0 0x7>;
> interrupt-names = "pcie", "msi";
> interrupts = <0x0 0x94 0x4 0x0 0x94 0x4>;
> - linux,pci-domain = <0x0>;
> - max-link-speed = <0x2>;
> msi-controller;
> - msi-parent = <0x22>;
> - phandle = <0x22>;
> + msi-parent = <0x2a>;
> + phandle = <0x2a>;
> ranges = <0x2000000 0x0 0xf8000000 0x6 0x0 0x0 0x4000000>;
> - reg = <0x0 0x7d500000 0x9310 0x0 0x7e00f300 0x20>;
> - status = "okay";
> - tot-num-pcie = <0x1>;
> + reg = <0x0 0x7d500000 0x0 0x9310>;
> };
>
>
> What I get out of:
>
> - dma-ranges = <0x2000000 0x0 0x0 0x0 0x0 0x1 0x0>;
> vs:
> + dma-ranges = <0x2000000 0x0 0x0 0x0 0x0 0x0 0xc0000000>;
>
> is that the older one (-) sets a 4 GiByte dma-range
> and the modern one (+) sets a 3 GiByte dma-range.
>
> The modern one also has:
>
> + emmc2bus {
> +
> + #address-cells = <0x2>;
> + #size-cells = <0x1>;
> + compatible = "simple-bus";
> + dma-ranges = <0x0 0xc0000000 0x0 0x0 0x40000000>;
> + phandle = <0xce>;
> + ranges = <0x0 0x7e000000 0x0 0xfe000000 0x1800000>;
>
> 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 at 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:
>
> / {
> #address-cells = <0x2>;
> #size-cells = <0x1>;
> . . .
> + emmc2bus {
> + #address-cells = <0x2>;
> + #size-cells = <0x1>;
> + dma-ranges = <0x0 0xc0000000 0x0 0x0 0x40000000>;
> . . .
> scb {
> - #address-cells = <0x2>;
> - #size-cells = <0x1>;
> - dma-ranges = <0x0 0x0 0x0 0x0 0xfc000000>;
> + #address-cells = <0x2>;
> + #size-cells = <0x2>;
> + dma-ranges = <0x0 0x0 0x0 0x0 0x4 0x0>;
> . . .
> pcie at 7d500000 {
> #address-cells = <0x3>;
> #size-cells = <0x2>;
> - dma-ranges = <0x2000000 0x0 0x0 0x0 0x0 0x1 0x0>;
> + dma-ranges = <0x2000000 0x0 0x0 0x0 0x0 0x0 0xc0000000>;
> soc {
> #address-cells = <0x1>;
> #size-cells = <0x1>;
> - dma-ranges = <0xc0000000 0x0 0x0 0x3c000000>;
> + dma-ranges = <0xc0000000 0x0 0x0 0x40000000>;
> . . .
> firmware {
> #address-cells = <0x1>;
> #size-cells = <0x0>;
> + dma-ranges;
> . . .
> v3dbus {
> #address-cells = <0x1>;
> - #size-cells = <0x1>;
> + #size-cells = <0x2>;
> - dma-ranges = <0x0 0x0 0x0 0x3c000000>;
> + dma-ranges = <0x0 0x0 0x0 0x4 0x0>;
>
> So the older one has smaller scb, soc, and v3dbus ranges.
>
> Looking at acpi dump information (modern based) there is:
>
> . . .
> 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)
> . . .
>
> So it appears that:
> XHC0 matches up with modern pcie at 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 at 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 = 0xFE980000
Return (RBUF) /* \_SB_.GDV0.USB0.RBUF */
}
}
So it appears that:
XHC0 matches up with modern pcie at 7d500000 .
USB0 matches up with usb at 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 at 7e340000 under soc instead
of the modern style of emmc2bus being separate, outside soc .
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
More information about the freebsd-arm
mailing list