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