RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Kyle Evans
kevans at freebsd.org
Thu Oct 8 17:38:29 UTC 2020
On Thu, Oct 8, 2020 at 11:33 AM Kyle Evans <kevans at freebsd.org> wrote:
>
> On Thu, Oct 8, 2020 at 4:01 AM Mark Millard via freebsd-arm
> <freebsd-arm at freebsd.org> 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.
>
For a slightly more helpful response:
We can fix this, and it ends up being much cleaner than my current
hack. Basically, in bcm2835_vcbus.c, we should eradicate the
busdma_lowaddr from bcm283x_memory_soc_cfg.
bcm283x_dmabus_peripheral_lowaddr should instead take a device_t and
grab the bus's dma-ranges. It /looks/ to be valid on all the DTS I see
for the RPi boards we support, so we can just unconditionally use that
and things will just work for the newer RPi4 models.
>From my discussion (with an assist Ian on address interpretation) on
IRC, so I don't forget:
dma-ranges is three-value: <dma_addr cpu_addr max_len>
We'll see 4 and 5 value variants of this because 64-bit addresses are
described with pairs of 32-bit values.
4-value variant: dma_addr will be 32-bit, cpu_addr will be 64-bit
5-value variant: both are 64-bit
Note that bcm283x_dmabus_peripheral_lowaddr() will be returning
cpu_addr + (max_len - 1)
This won't match perfectly with what we currently return, but it will
be more accurate.
Thanks,
Kyle Evans
More information about the freebsd-arm
mailing list