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

On Thu, Oct 8, 2020 at 11:33 AM Kyle Evans <[email protected]> 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.
>

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
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"