Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)

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
> <[email protected]> wrote:
>> 
>> sys/gnu/dts/arm/bcm2711.dtsi reports:
>> 
>>        /*
>>         * 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 ...]
> 
> 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: 

https://elixir.bootlin.com/linux/v5.8.14/source/drivers/pci/controller/pcie-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

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"