Re: [Discuss OpenCPI] Zynq AXI Peripherals in Platform

From: Brian Padalino <bpadalino_at_gmail.com>
Date: Tue, 02 Mar 21 19:47:08 -0500

On Tue, Mar 2, 2021 at 2:18 PM James Kulp <jek_at_parera.com> wrote:

> On 3/2/21 10:44 AM, Brian Padalino wrote:
>
> On Tue, Mar 2, 2021 at 10:17 AM James Kulp <jek_at_parera.com> wrote:
>
>> On 3/2/21 10:04 AM, Brian Padalino wrote:
>> > I have some AXI peripherals that I want to use on the PL side of things
>> > along with OpenCPI. I want to use these in the form of a device tree
>> > overlay to load once the FPGA image has been loaded.
>>
>> Are these AXI slaves, like the OpenCPI control plane?
>>
>
> These are slaves that are used in the platform by a daemon that control
> other aspects of my system. I don't want to re-write the drivers/daemon or
> maintain two separate systems. They utilize sysfs entries for opening and
> interacting with the devices. I figured it is easier to make a daemon
> interface in OpenCPI than bring all the PL IP into it.
>
> So you can either make a worker that touches sysfs etc., or just a library
> if you are using the ACI.
> Making a worker is nicer since it enables ocpirun etc.
>
>
>
>>
>> One way to do this is to use the other AXI slave port (AXI_GP1).
>> That keeps everything separate.
>> Then attach your "other" logic to that AXI PS->PL port, in the platform
>> worker.
>>
>
> Is there an example of this somewhere in the OpenCPI code?
>
> Unfortunately the example we have is proprietary, but basically it is a
> module in the platform worker that is attached directly to the GP1
> interface from the zynq_ps module in the platform worker.
>

So this is a use case that OpenCPI wants to support, but the example that
shows this use case isn't open for the OpenCPI project?

Are you able to remove any proprietary aspect and post the example to the
OpenCPI project? Preferably it would be a BD instantiation with multiple
devices using the same AXI interface and the Xilinx Smart Interconnect?


> I.e.:
>
> ps_m_axi_gp_in(1).ar.ready <= mymodule.arready;...
>
> mymodule.araddr <= ps_m_axi_gp_out(1).ar.addr
>
> This assumes you can make your other drivers/devices accessed at GP1.
>
> It is also possible to run opencpi using GP1 and leave GP0 for the other
> stuff.
>
> The zed platform has this GP0 vs. GP1 option.
>
>
>
>>
>> But that has nothing to do with device trees and overlays - which can
>> get into some pretty complicated scenarios, depending on how much you
>> want to deal with dynamic loading and probing of other linux device
>> drivers. Not to mention that the whole DTO system only works on pretty
>> recent Linux kernels.
>>
>
> Understandable about the recent nature of this feature. I am worried
> about keeping the drivers instantiated when the FPGA image is being
> reprogrammed underneath it all, hence the overlays.
>
> Yes, that is something to worry about. The other drivers would need to be
> told something in order to "reinitialize the hardware". Perhaps you could
> do that in your "worker".
>

This doesn't necessarily work since the daemon typically handles loading
the FPGA and overlay.

I guess let me ask the question differently - when will OpenCPI support
device tree overlays and loading FPGA images via that mechanism?

Thanks,
Brian


Received on Wed Mar 03 2021 - 00:47:08 CST