pcie-32bit-dma overlay breaks I2S and (likely) other RP1 peripherals on Pi 5

[YanqiHe03]

Describe the bug

The pcie-32bit-dma overlay targets pcie1 (RP1 south bridge at /axi/pcie@1000120000), restricting DMA ranges for all RP1 peripherals. This breaks I2S audio. the PCM device appears in arecord -l but cannot be opened (EINVAL at the syscall level). The overlay does make FireWire work on the external PCIe port (pciex1), but more like a side effect rather than a targeted fix. A custom overlay targeting pciex1 directly resolves both FireWire and I2S. Detailed writeup: geerlingguy/raspberry-pi-pcie-devices#811

Steps to reproduce the behaviour

1. Add dtparam=pciex1, dtoverlay=pcie-32bit-dma, and dtoverlay=adau7002-simple to /boot/firmware/config.txt
2. Reboot
3. Run arecord -l — I2S card shows up as card 0: adau7002
4. Run arecord -D hw:0,0 -c2 -r 48000 -f S32_LE -t wav -d 1 test.wav — fails with audio open error: Invalid argument
5. Remove dtoverlay=pcie-32bit-dma, reboot — I2S works, but FireWire fails with error -12 (ENOMEM)
6. Replace with a custom overlay targeting pciex1 instead of pcie1 — both work

Device (s)

Raspberry Pi 5

System

https://pastebin.com/vSRL06nC

Logs

# With pcie-32bit-dma (I2S broken):
$ arecord -D hw:0,0 -c2 -r 48000 -f S32_LE -t wav -d 1 test.wav
arecord: main:850: audio open error: Invalid argument
 
# Without pcie-32bit-dma (FireWire broken):
$ dmesg | grep firewire
firewire_ohci 0001:02:00.0: probe with driver firewire_ohci failed with error -12
 
# With pciex1-targeted overlay (both working):
$ dmesg | grep -iE "firewire|adau"
adau7002 adau7002-codec: supply IOVDD not found, using dummy regulator
firewire_ohci 0001:02:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x2
firewire_core 0001:02:00.0: created device fw0: GUID 7856341278563412, S800

Additional context

Proposed fix — overlay targeting pciex1 directly:

/dts-v1/;
/plugin/;
 
/ {
    compatible = "brcm,bcm2712";
 
    fragment@0 {
        target = <&pciex1>;
        __overlay__ {
            #address-cells = <0x03>;
            #size-cells = <0x02>;
            dma-ranges = <0x03000000 0x00 0x00 0x00 0x00 0x00 0x80000000>;
        };
    };
};

It would be useful to have this as an official overlay (e.g. pciex1-32bit-dma) for users who need 32-bit DMA on the external PCIe port without affecting RP1 peripherals.
Hardware: 52Pi P02 PCIe x1 board, SYBA SY-PEX30016 FireWire card (TI XIO2213B), INMP441 I2S MEMS microphone. Custom kernel with CONFIG_FIREWIRE=m, CONFIG_FIREWIRE_OHCI=m.

[pelwell]

It's possible that your modified overlay makes a positive difference that isn't just placebo effect, but I'm certain that it isn't for the reason you state.

This is the standard Pi 5 version of the pcie-32bit-dma overlay:

/dts-v1/;
/plugin/;

/ {
	compatible = "brcm,bcm2712";

	fragment@0 {
		target = <&pcie1>;
		__overlay__ {
			/*
			 * The size of the range is rounded up to a power of 2,
			 * so the range ends up being 0-4GB, and the MSI vector
			 * gets pushed beyond 4GB.
			 */
			#address-cells = <3>;
			#size-cells = <2>;
			msi-parent = <&pciex1>;
			dma-ranges = <0x02000000 0x0 0x00000000 0x0 0x00000000
				      0x0 0x80000000>;
		};
	};
};

You (or your AI friend) are asserting that the &pcie1 should be &pciex1, because pcie1 is the label on the RC dedicated to the onboard RP1 I/O adaptor.

The RP1 is connected to the 4-lane PCIe Root Complex, the label for which is pcie2:

linux/arch/arm64/boot/dts/broadcom/bcm2712.dtsi

Lines 526 to 532 in bc0c440

	pcie2: pcie@1000120000 {
	compatible = "brcm,bcm2712-pcie";
	reg = <0x10 0x00120000 0x00 0x9310>;
	device_type = "pci";
	linux,pci-domain = <2>;
	max-link-speed = <2>;
	num-lanes = <4>;

The assignment of RP1 to pcie2 is established here:

linux/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b.dts

Lines 124 to 127 in bc0c440

	rp1_target: &pcie2 {
	aspm-no-l0s;
	status = "okay";
	};

This next dts fragment shows that pcie1 is the label on the 1-lane RC that is made available via the external connector:

linux/arch/arm64/boot/dts/broadcom/bcm2712.dtsi

Lines 487 to 493 in bc0c440

	pcie1: pcie@1000110000 {
	compatible = "brcm,bcm2712-pcie";
	reg = <0x10 0x00110000 0x00 0x9310>;
	device_type = "pci";
	linux,pci-domain = <1>;
	max-link-speed = <2>;
	num-lanes = <1>;

And here you'll see that pciex1 is an alias for pcie1, and pciex4 is an alias for pcie2.

linux/arch/arm64/boot/dts/broadcom/bcm2712-rpi.dtsi

Lines 258 to 259 in bc0c440

	pciex1: &pcie1 { };
	pciex4: &pcie2 { };

Assuming that your modified overlay does something useful, what are other differences could account for this?

1. Your version of the overlay lacks the change of the MSI parent from mip0 (

   linux/arch/arm64/boot/dts/broadcom/bcm2712.dtsi

   Line 548 in bc0c440

   msi-parent = <&mip0>;

   ) to pciex1 a.k.a. pcie1.
2. Your dma-ranges declaration is for a 64-bit address range (the first byte of the address is 0x03 compared to the standard one's 0x02).

I suggest the following:
i. Change the &pciex1 in your overlay to &pcie1 and verify that nothing changes.
ii. Try adding the msi-parent = <&pciex1>; line to your overlay - does that make it worse?
iii. Try changing the dma-ranges declaration to dma-ranges = <0x02000000 0x0 0x00000000 0x0 0x00000000 0x0 0x80000000>; - any difference?

[eccgecko]

Tangentially related to this, is there an actual functional difference between

dtoverlay=pcie-32bit-dma
and
dtoverlay=pcie-32bit-dma-pi5?

I'm assuming on a pi5 it is recommended to use the pi5 specific overlay, but I was just curious as to what actually is the technical difference, if any, between them?

[pelwell]

On a Pi 5 there is no difference - the firmware will treat the former as if it were the latter, always loading the -pi5 variant.

[YanqiHe03]

I just brought the Pi back from school and tried to run these tests, but after switching back to the stock pcie-32bit-dma overlay with the same config,

[all]
dtparam=pciex1
dtoverlay=pcie-32bit-dma
dtparam=i2s=on
dtoverlay=adau7002-simple

for some weird reason... Both FireWire and I2S are working fine now. The EINVAL error is completely gone.

At the time of the original report, the failure was reproducible across multiple reboots, enabling pcie-32bit-dma would break I2S every time, removing it would restore I2S but break FireWire. I don't really know why this happened and what has changed. It is the same kernel (6.12.78-v8-16k+), same overlay file (verified via dtc -I dtb -O dts, identical to the version from March 25), and the same hardware:( So can't really do the tests... Sorry