UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
807 Views
Registered: ‎02-13-2019

libmetal demo simultaneously on R5_0 and R5_1: problems

Jump to solution

Hi everyone!

I hope this branch is the most appropriate for libmetal - related question.

I have a problem starting application on second R5_1 core while I run some application in the first R5_0 core. I used libmetal demo application from UG1186 as example application for R5.

Problem: libmetal demo configures only one /sys/class/remoteproc/remoteproc0

So I can start one demo application on the first core R5_0 and do not have possibility to start the demo application on the second R5_1 core, because I need /sys/class/remoteproc/remoteproc1 for this.

What I attempted to resolve: Updated Device Tree adding components for the second core.

I took example from: https://github.com/Xilinx/meta-openamp/blob/rel-v2017.4/recipes-bsp/device-tree/files/zynqmp/openamp-overlay-split.dtsi

Problem: The updated Device Tree did not help. Petalinux starts only remoteproc0, and does not create remoteproc1.

What have I missed? Thank you.

My environment: Zynq UltraScale++, Petalinux 2017.4, Vivado/SDK 2018.1

I attached my system-user.dtsi to this post

Here the exstract of the system-user.dtsi related to libmetal:

	reserved-memory {
		#address-cells = <2>;
		#size-cells = <2>;
		ranges;
		rproc_0_reserved: rproc@3ed000000 {
		no-map;
		reg = <0x0 0x3ed00000 0x0 0x2000000>;
		};
	};

	amba {
	/* Shared memory */
		shm0: shm@0 {
		compatible = "shm_uio";
		reg = <0x0 0x3ed80000 0x0 0x1000000>;
	};
	/* IPI device */
		ipi_amp: ipi@ff340000 {
		compatible = "ipi_uio";
		reg = <0x0 0xff340000 0x0 0x1000>;
		interrupt-parent = <&gic>;
		interrupts = <0 29 4>;
		};

	/* firmware memory nodes */
		r5_0_tcm_a: tcm@ffe00000 {
			compatible = "mmio-sram";
			reg = <0x0 0xFFE00000 0x0 0x10000>;
			pd-handle = <&pd_tcm_0_a>;
		};
		r5_0_tcm_b: tcm@ffe20000 {
			compatible = "mmio-sram";
			reg = <0x0 0xFFE20000 0x0 0x10000>;
			pd-handle = <&pd_tcm_0_b>;
		};
		r5_1_tcm_a: tcm@ffe90000 {
			compatible = "mmio-sram";
			reg = <0 0xFFE90000 0x0 0x10000>;
			pd-handle = <&pd_tcm_1_a>;
		};
		r5_1_tcm_b: tcm@ffe92000 {
			compatible = "mmio-sram";
			reg = <0 0xFFEB0000 0x0 0x10000>;
			pd-handle = <&pd_tcm_1_b>;
		};		
		elf_ddr_0: ddr@3ed00000 {
			compatible = "mmio-sram";
			reg = <0x0 0x3ed00000 0x0 0x100000>;
		};
		elf_ddr_1: ddr@3ed40000 {
			compatible = "mmio-sram";
			reg = <0 0x3ed40000 0x0 0x40000>;
		};
		test_r5_0: zynqmp_r5_rproc@0 {
			compatible = "xlnx,zynqmp-r5-remoteproc-1.0";
			reg = <0x0 0xff9a0100 0 0x100>, <0x0 0xff340000 0 0x100>, <0x0 0xff9a0000 0 0x100>;
			reg-names = "rpu_base", "ipi", "rpu_glbl_base";
			dma-ranges;
			core_conf = "split0";
			srams = <&r5_0_tcm_a &r5_0_tcm_b &elf_ddr_0>;
			pd-handle = <&pd_r5_0>;
			interrupt-parent = <&gic>;
			interrupts = <0 29 4>;
		};
		test_r5_1: zynqmp_r5_rproc@1 {
			compatible = "xlnx,zynqmp-r5-remoteproc-1.0";
			reg =<0x0 0xff9a0200 0 0x100>, <0x0 0xff340000 0 0x100>, <0x0 0xff9a0000 0 0x100>;
			reg-names = "rpu_base", "ipi", "rpu_glbl_base";
			dma-ranges;
			core_conf = "split1";
			srams = <&r5_1_tcm_a &r5_1_tcm_b &elf_ddr_1>;
			pd-handle = <&pd_r5_1>;
			interrupt-parent = <&gic>;
			interrupts = <0 29 4>;			
		} ;
	};

	power-domains {
		pd_r5_0: pd_r5_0 {
			#power-domain-cells = <0x0>;
			pd-id = <0x7>;
		pd_r5_1: pd_r5_1 {
			#power-domain-cells = <0x0>;
			pd-id = <0x8>;
		};
		pd_tcm_0_a: pd_tcm_0_a {
			#power-domain-cells = <0x0>;
			pd-id = <0xf>;
		};
		pd_tcm_0_b: pd_tcm_0_b {
			#power-domain-cells = <0x0>;
			pd-id = <0x10>;
		};
		pd_tcm_1_a: pd_tcm_1_a {
			#power-domain-cells = <0x0>;
			pd-id = <0x11>;
		};
		pd_tcm_1_b: pd_tcm_1_b {
			#power-domain-cells = <0x0>;
			pd-id = <0x12>;
		};
	};

 

0 Kudos
1 Solution

Accepted Solutions
Moderator
Moderator
766 Views
Registered: ‎05-10-2017

Re: libmetal demo simultaneously on R5_0 and R5_1: problems

Jump to solution

Hi, 

Please use same versions of Petalinux, Vivado/SDK. I would suggest building a Petalinux project for 2018.1

In order to run the Libmetal application on both RPU cores simultaneously, you will need 

1. Linux application (say linux-app-r5-0) and a r5-0 firmware application

2. Linux application (say linux-app-r5-1) and a r5-1 firmware application

3. This requires you to have 2 shared memory, ipi and ttc nodes defined in the device-tree for each of the rpu firmware applications

4. Your linux application, that talks to R5-1 must also be modified. The IPI mask will be change in this case

#define IPI_MASK        0x200 /* IPI mask for kick from RPU. */

Make sure you have no overlapping addresses.

Attached is an example system-user.dtsi. Make sure you make the necessary changes in the linux and the rpu applications as well.

 

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

View solution in original post

3 Replies
Moderator
Moderator
767 Views
Registered: ‎05-10-2017

Re: libmetal demo simultaneously on R5_0 and R5_1: problems

Jump to solution

Hi, 

Please use same versions of Petalinux, Vivado/SDK. I would suggest building a Petalinux project for 2018.1

In order to run the Libmetal application on both RPU cores simultaneously, you will need 

1. Linux application (say linux-app-r5-0) and a r5-0 firmware application

2. Linux application (say linux-app-r5-1) and a r5-1 firmware application

3. This requires you to have 2 shared memory, ipi and ttc nodes defined in the device-tree for each of the rpu firmware applications

4. Your linux application, that talks to R5-1 must also be modified. The IPI mask will be change in this case

#define IPI_MASK        0x200 /* IPI mask for kick from RPU. */

Make sure you have no overlapping addresses.

Attached is an example system-user.dtsi. Make sure you make the necessary changes in the linux and the rpu applications as well.

 

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

View solution in original post

739 Views
Registered: ‎02-13-2019

Re: libmetal demo simultaneously on R5_0 and R5_1: problems

Jump to solution

Dear jovitac,

Thank you very much for the explanation and detailed example system-user.dtsi !

May I ask you to confirm or comment the boundaries of shm@ and shm@1 ?

The example system-user.dtsi you kindly provided contains the following boundaries for the above shared memory regions:

shm0: shm@0
reg = <0x0 0x3ed80000 0x0 0x1000000>;

shm1: shm@1
reg = <0x0 0x3fd90000 0x0 0x1000000>;

This means that shm@1 ends at 0x3fd9 0000 + 0x100 0000 = 0x40d9 0000

This is beyond of the declared reserved memory region which ends at 0x3ed0 0000 + 0x200 0000 = 0x40d0 0000:

rproc_0_reserved: rproc@3ed000000
reg = <0x0 0x3ed00000 0x0 0x2000000>;

Does this mean that shm@1 in the proposed system-user.dtsi lays partially outside of the reserved memory? Is it what we suppose to do or shall we adjust either shm@1 or reserved memory to fit?

 

Thank you.

 

0 Kudos
Moderator
Moderator
734 Views
Registered: ‎05-10-2017

Re: libmetal demo simultaneously on R5_0 and R5_1: problems

Jump to solution

Yes. Please change either the shared memory or the reserved memory region.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------