[PATCH v11 07/11] device-mapping: Introduce DMA range map, supplanting dma_pfn_offset
james.quinlan at broadcom.com
Thu Sep 3 17:32:43 UTC 2020
On Wed, Sep 2, 2020 at 8:52 PM Nathan Chancellor
<natechancellor at gmail.com> wrote:
> On Wed, Sep 02, 2020 at 05:36:29PM -0700, Florian Fainelli wrote:
> > On 9/2/2020 3:38 PM, Nathan Chancellor wrote:
> > [snip]
> > > > Hello Nathan,
> > > >
> > > > Can you tell me how much memory your RPI has and if all of it is
> > >
> > > This is the 4GB version.
> > >
> > > > accessible by the PCIe device? Could you also please include the DTS
> > > > of the PCIe node? IIRC, the RPI firmware does some mangling of the
> > > > PCIe DT before Linux boots -- could you describe what is going on
> > > > there?
> > >
> > > Unfortunately, I am not familiar with how to get this information. If
> > > you could provide some instructions for how to do so, I am more than
> > > happy to. I am not very knowleagable about the inner working of the Pi,
> > > I mainly use it as a test platform for making sure that LLVM does not
> > > cause problems on real devices.
> > Can you bring the dtc application to your Pi root filesystem, and if so, can
> > you run the following:
> > dtc -I fs -O dtb /proc/device-tree -f > /tmp/device.dtb
> Sure, the result is attached.
> > or cat /sys/firmware/fdt > device.dtb
> > and attach the resulting file?
> > >
> > > > Finally, can you attach the text of the full boot log?
> > >
> > > I have attached a working and broken boot log. Thank you for the quick
> > > response!
> > Is it possible for you to rebuild your kernel with CONFIG_MMC_DEBUG by any
> > chance?
> Of course. A new log is attached with the debug output from that config.
Can you please help us out here? It appears that your commit
3d2cbb644836 "ARM: dts: bcm2711: Move emmc2 into its own bus"
added the following line to the bcm2711.dtsi file:
+ dma-ranges = <0x0 0xc0000000 0x0 0x00000000 0x40000000>;
and for some reason the eMMC is not operating properly w/ my commit..
Regardless, the only difference that my commit should make is to
enforce the bounds of the dma_window (whereas the previous code
adds/subs the pfn_offset everywhere).
PS If you would like to talk, let me know and we can make arrangements.
> > I have a suspicion that this part of the DTS for the bcm2711.dtsi platform
> > is at fault:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/bcm2711.dtsi#n264
> > and the resulting dma-ranges parsing is just not working for reasons to be
> > determined.
> > --
> > Florian
> Let me know if you need anything else out of me.
More information about the devel