On Mon, 2023-04-03 at 14:17 +0100, Russell King (Oracle) wrote: > On Mon, Apr 03, 2023 at 12:11:40PM +0200, Christoph Fritz wrote: > > > > > > The ARM PL330 DMA driver in kernel only relate to: > > > > > > - DTS kernel used, can be check in /proc/device-tree/ > > > > > > - kernel driver which should mach the compatible name. > > > > drivers/dma/pl330.c needs also a successfully matched amba, but this > > fails when using mainline TF-A and U-Boot SPL. > > > > I'm using the same kernel and devicetree on both tests, the only thing > > changed is TF-A and U-Boot SPL vs mini-loader and rk3399_bl31. > > > > > This driver should has nothing to do with U-Boot SPL or TF-A, because we > > > don't have any special setting for PL330 in loader stage. > > > > It is drivers/amba/bus.c, which is unable to find an AMBA_CID on the > > ARM bus. The DMA driver not loading is just a symptom of this issue. > > That brings up the obvious question: why is it unable to find the AMBA > CID? Is that because some resource needed to read it hasn't been > enabled yet?
That's my guess too, and that's why I'm asking Kever from Rockchip. To me, it seems that their closed-source BL31 and/or mini-loader is enabling something that is missing in upstream TF-A and/or U-Boot SPL. On top of that, the registers responsible for that are undocumented. But I could be wrong, and it's possible that I'm missing something else. Maybe dumping the syscon-registers and comparing them might help, but as far as I can see, it's a bit of an effort because they require special treatment to be accessed. > If the AMBA CID is not accessible, presumably the rest of > the PL330 also isn't accessible, so even if we could bind the driver, > it still wouldn't work? The PL330 driver attempted to probe, but was deferred due to a missing AMBA_CID. It's in the bootlog that I attached in my first email in this thread. Thanks -- Christoph
