Date: Thu, 8 Oct 2020 10:49:11 -0700 From: Mark Millard <marklmi@yahoo.com> To: Kyle Evans <kevans@freebsd.org> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) Message-ID: <C894CEA8-5BE6-4E02-A3C5-3C469AB28B2E@yahoo.com> In-Reply-To: <CACNAnaG3CKTiXdXNUO1Jgr34=XGF4wYRuUnuiJRhNb1J9XaGbw@mail.gmail.com> References: <D8BDF95A-D6A8-4E95-A0CE-D53068E8355B.ref@yahoo.com> <D8BDF95A-D6A8-4E95-A0CE-D53068E8355B@yahoo.com> <CACNAnaG3CKTiXdXNUO1Jgr34=XGF4wYRuUnuiJRhNb1J9XaGbw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Oct-8, at 09:33, Kyle Evans <kevans at freebsd.org> wrote: > On Thu, Oct 8, 2020 at 4:01 AM Mark Millard via freebsd-arm > <freebsd-arm@freebsd.org> wrote: >>=20 >> sys/gnu/dts/arm/bcm2711.dtsi reports: >>=20 >> /* >> * emmc2 has different DMA constraints based on SoC revisions. = It was >> * moved into its own bus, so as for RPi4's firmware to update = them. >> * The firmware will find whether the emmc2bus alias is = defined, and if >> * so, it'll edit the dma-ranges property below accordingly. >> */ >> [... snip ...] >=20 > I have no words for how annoying this is. The linux kernel drivers/pci/controller/pcie-brcmstb.c has a comment mentioning another dynamic edit of dma-ranges for the RPi4, suggesting that there is or will be revisions that do not have the 3 GiByte PCIe oddity. The following is a code-comment from:=20 = https://elixir.bootlin.com/linux/v5.8.14/source/drivers/pci/controller/pci= e-brcmstb.c#L646 * We validate the inbound memory view even though we should = trust * whatever the device-tree provides. This is because of an HW = issue on * early Raspberry Pi 4's revisions (bcm2711). It turns out its * firmware has to dynamically edit dma-ranges due to a bug on = the * PCIe controller integration, which prohibits any access above = the * lower 3GB of memory. Given this, we decided to keep the = dma-ranges * in check, avoiding hard to debug device-tree related issues = in the * future: * * The PCIe host controller by design must set the inbound = viewport to * be a contiguous arrangement of all of the system's memory. = In * addition, its size mut be a power of two. To further = complicate * matters, the viewport must start on a pcie-address that is = aligned * on a multiple of its size. If a portion of the viewport does = not * represent system memory -- e.g. 3GB of memory requires a 4GB * viewport -- we can map the outbound memory in or after 3GB = and even * though the viewport will overlap the outbound memory the = controller * will know to send outbound memory downstream and everything = else * upstream. * * For example: * * - The best-case scenario, memory up to 3GB, is to place the = inbound * region in the first 4GB of pcie-space, as some legacy = devices can * only address 32bits. We would also like to put the MSI = under 4GB * as well, since some devices require a 32bit MSI target = address. * * - If the system memory is 4GB or larger we cannot start the = inbound * region at location 0 (since we have to allow some space for * outbound memory @ 3GB). So instead it will start at the 1x * multiple of its 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?C894CEA8-5BE6-4E02-A3C5-3C469AB28B2E>