I've used earlier variations of D25219 for my occasional UEFI/ACPI RPi4B activity since my comments on D25219 not passing my large-file-copy-and-diff testing on RPi4B's with the B0T stepping, Rev 1.4, and >= 4 GiBytes of RAM while using https://github.com/pftf/RPi4 (EDK2 RPi4B UEFI/ACPI testing), tracking as I've updated FreeBSD. The intent vs. D25219 is to, for example, change 0xc0000000 for hw.busdma.zone0.lowaddr to the value shown in:

# sysctl hw.busdma.zone0.lowaddr
hw.busdma.zone0.lowaddr: 0xbfffffff

That matches the kind of values that I've seen in other contexts for hw.busdma.zoneN.lowaddr values. See my notes in D25219 and comments in the submitted code.

# ~/fbsd-based-on-what-commit.sh -C /usr/main-src/
f83db6441a2f (HEAD -> main, freebsd/main, freebsd/HEAD) sctp: minor changes due to upstreaming of Glebs recent changes
branch: main
merge-base: f83db6441a2f4f925a169c7ddf844589cb73c9b5
merge-base: CommitDate: 2022-11-06 22:06:40 +0000
n259064 (--first-parent --count for merge-base)

Beyond creating, say, huge tar files ( such as of /usr/ports/ ) on RPi4B's, duplicating them, and diff'ing the two copies and some normal-operation without noticing problems: good question. The modern cylinder related validations in UFS do make the failures of the existing FreeBSD code on 8 GiByte RPi4B's quickly obvious, unlike when I originally submitted material for this. I do boot a HoneyComb and a MACCHIATObin Double Shot that are ACPI based but do not have such odd DMA limitations.

Note: On RPi4B's with < 4 GiBytes of RAM, or EDK2 configured to limit themselves to 3 GiBytes, I've never seen problems, patched or not. Only 4 GiByte and 8 GiByte ones showed the problem, with or without D25219's patch. No other kind of system ever showed the problem in any configuration. I've never had access to Pi400's or such. I do now have access to one "C0T" RPi4B 8 GiByte.

I does turn out that the existing RPi4B EDK2 UEFI/ACPI (1.33) imposes the 3 GiByte DMA limit for XHCI use, even for "C0T" RPi4B's that do not need the limit. The EDK2 implementation has it hand coded to enforce that limit (or less) in its _DMA information and does not adjust. This somewhat constrains what testing RPi4B's can get.