element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • About Us
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Avnet Boards Forums
  • Products
  • Dev Tools
  • Avnet Boards Community
  • Avnet Boards Forums
  • More
  • Cancel
Avnet Boards Forums
Software Application Development ZynqMP PS UART 1 Polled Mode Example Issue with Remote Processor
  • Forum
  • Documents
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Avnet Boards Forums to participate - click to join for free!
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • Replies 14 replies
  • Subscribers 327 subscribers
  • Views 3378 views
  • Users 0 members are here
  • ultrazed-ev
  • ultrazed
  • zynqmpsoc
  • petalinux
  • uart
  • xilinx zynq
Related

ZynqMP PS UART 1 Polled Mode Example Issue with Remote Processor

fastian16
fastian16 over 2 years ago

Hi, 

I am working to test PS-UART1 in ZynqMP (UltraZed Som). I am running UART polled mode example to test PS-UART 1. 

When I run this example application via JTAG from SDK Debugger, it runs successfully. UART Self Test and UART Internal Loopback Passes Successfully. 

After that I generate a petalinux build to boot image from SD-Card in Ultrazed-Som. Then I run same application via following commands,

echo UARTSelfTest.elf > /sys/class/remoteproc/remoteproc0/firmware
echo start > /sys/class/remoteproc/remoteproc0/state

-In this case, the PS-UART1 goes to reset state when the following function is called in the application XUartPs_SetBaudRate(InstancePtr, BaudRate). 

The code for PS-UART Self Test is attached here. 

/******************************************************************************
*
* Copyright (C) 2010 - 2014 Xilinx, Inc. All rights reserved.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* XILINX BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
* WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
* OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*
* Except as contained in this notice, the name of the Xilinx shall not be used
* in advertising or otherwise to promote the sale, use or other dealings in
* this Software without prior written authorization from Xilinx.
*
******************************************************************************/
/****************************************************************************/
/**
*
* @file xuartps_polled_example.c
*
* This file contains an example using the XUartPs driver in polled mode.
*
* This function sends data and expects to receive the data thru the device
* using the local loopback mode.
*
* @note
* If the device does not work properly, the example may hang.
*
* MODIFICATION HISTORY:
* <pre>
* Ver Who Date Changes
* ----- ------ -------- -----------------------------------------------
* 1.00a drg/jz 01/13/10 First Release
* 1.03a sg 07/16/12 Modified the device ID to use the first Device Id
* Removed the printf at the start of the main
* </pre>
******************************************************************************/

/***************************** Include Files *********************************/

#include "xparameters.h"
#include "xuartps.h"
#include "xil_printf.h"

/************************** Constant Definitions *****************************/

/*
* The following constants map to the XPAR parameters created in the
* xparameters.h file. They are defined here such that a user can easily
* change all the needed parameters in one place.
*/
#define UART_DEVICE_ID XPAR_XUARTPS_1_DEVICE_ID

/*
* The following constant controls the length of the buffers to be sent
* and received with the device, this constant must be 32 bytes or less since
* only as much as FIFO size data can be sent or received in polled mode.
*/
#define TEST_BUFFER_SIZE 32

/**************************** Type Definitions *******************************/

/***************** Macros (Inline Functions) Definitions *********************/

/************************** Function Prototypes ******************************/

int UartPsPolledExample(u16 DeviceId);

/************************** Variable Definitions *****************************/

XUartPs Uart_PS; /* Instance of the UART Device */

/*
* The following buffers are used in this example to send and receive data
* with the UART.
*/
static u8 SendBuffer[TEST_BUFFER_SIZE]; /* Buffer for Transmitting Data */
static u8 RecvBuffer[TEST_BUFFER_SIZE]; /* Buffer for Receiving Data */


/*****************************************************************************/
/**
*
* Main function to call the Uart Polled mode example.
*
* @param None
*
* @return XST_SUCCESS if succesful, otherwise XST_FAILURE
*
* @note None
*
******************************************************************************/
#ifndef TESTAPP_GEN
int main(void)
{
int Status;

usleep(5000);

xil_printf("Hello World\r\n");

Status = UartPsPolledExample(UART_DEVICE_ID);

if (Status != XST_SUCCESS)
{
xil_printf("UART Polled Mode Example Test Failed\r\n");
return XST_FAILURE;
}


u32* uart_pll = 0xff5e0020;

// Release UART from reset state by clearing TXRST and RXRST bits
u32 control_reg_value = *uart_pll;
xil_printf("IO PLL Control Register = %x \r\n",control_reg_value);

xil_printf("Successfully ran UART Polled Mode Example Test\r\n");

return XST_SUCCESS;

}
#endif
/*****************************************************************************/
/**
*
* This function does a minimal test on the XUartPs device in polled mode.
*
* This function sends data and expects to receive the data thru the UART
* using the local loopback mode.
*
*
* @param DeviceId is the unique device id from hardware build.
*
* @return XST_SUCCESS if successful, XST_FAILURE if unsuccessful
*
* @note
* This function polls the UART, it may hang if the hardware is not
* working correctly.
*
****************************************************************************/
int UartPsPolledExample(u16 DeviceId)
{
int Status;
XUartPs_Config *Config;
unsigned int SentCount;
unsigned int ReceivedCount;
u16 Index;
u32 LoopCount = 0;

/*
* Initialize the UART driver so that it's ready to use.
* Look up the configuration in the config table, then initialize it.
*/


// Address of the UART PS control register
u32* uart_cr = (volatile u32*)(XPAR_PSU_UART_1_BASEADDR + XUARTPS_CR_OFFSET);

// Release UART from reset state by clearing TXRST and RXRST bits
u32 control_reg_value = *uart_cr;
xil_printf("UART Control Register Before LookUp = %x \r\n",control_reg_value);



Config = XUartPs_LookupConfig(DeviceId);
if (NULL == Config)
{
xil_printf("UART PS Lookup Config Failed\r\n");
return XST_FAILURE;
}
else
{
xil_printf("UART PS Lookup Config Success\r\n");
}



// Release UART from reset state by clearing TXRST and RXRST bits
control_reg_value = *uart_cr;
xil_printf("UART Control Register After Lookup = %x \r\n",control_reg_value);


Status = XUartPs_CfgInitialize(&Uart_PS, Config, Config->BaseAddress);
if (Status != XST_SUCCESS)
{
xil_printf("UART PS CFG Init Failed\r\n");
return XST_FAILURE;
}
{
xil_printf("UART PS CFG Init Success\r\n");
}


control_reg_value = *uart_cr;
xil_printf("UART Control Register After INIT = %x \r\n",control_reg_value);

/*
xil_printf("UART PS Before Reset\r\n");

XUartPs_ResetHw(XPAR_PSU_UART_1_BASEADDR);

xil_printf("UART PS After Reset\r\n");

usleep(5000);
*/

/* Check hardware build. */
Status = XUartPs_SelfTest(&Uart_PS);
if (Status != XST_SUCCESS)
{
xil_printf("UART PS Self Test Failed\r\n");
return XST_FAILURE;
}
else
{
xil_printf("UART PS Self Test Success\r\n");
}

/* Use local loopback mode. */
XUartPs_SetOperMode(&Uart_PS, XUARTPS_OPER_MODE_LOCAL_LOOP);

/*
* Initialize the send buffer bytes with a pattern and zero out
* the receive buffer.
*/
for (Index = 0; Index < TEST_BUFFER_SIZE; Index++)
{
SendBuffer[Index] = '0' + Index;
RecvBuffer[Index] = 0;
}

/* Block sending the buffer. */
SentCount = XUartPs_Send(&Uart_PS, SendBuffer, TEST_BUFFER_SIZE);
if (SentCount != TEST_BUFFER_SIZE)
{
xil_printf("UART PS Data Sent Failed\r\n");
return XST_FAILURE;
}
else
{
xil_printf("Sent Count = %d\r\n",SentCount);
}

/*
* Wait while the UART is sending the data so that we are guaranteed
* to get the data the 1st time we call receive, otherwise this function
* may enter receive before the data has arrived
*/
while (XUartPs_IsSending(&Uart_PS))
{
LoopCount++;
}

xil_printf("Data Sent Completed\r\n");

/* Block receiving the buffer. */
ReceivedCount = 0;
while (ReceivedCount < TEST_BUFFER_SIZE)
{
ReceivedCount +=
XUartPs_Recv(&Uart_PS, &RecvBuffer[ReceivedCount],
(TEST_BUFFER_SIZE - ReceivedCount));
}

xil_printf("Received Count = %d\r\n",ReceivedCount);
/*
* Check the receive buffer against the send buffer and verify the
* data was correctly received
*/
for (Index = 0; Index < TEST_BUFFER_SIZE; Index++)
{
xil_printf("Send Data = %d\r\n",SendBuffer[Index]);
xil_printf("Received Data = %d\r\n",RecvBuffer[Index]);

if (SendBuffer[Index] != RecvBuffer[Index])
{
return XST_FAILURE;
}
else
{
xil_printf("Data Matched Success\r\n");
}
}

xil_printf("Internal Loopback Tested Successfully\r\n");

/* Restore to normal mode. */
XUartPs_SetOperMode(&Uart_PS, XUARTPS_OPER_MODE_NORMAL);

return XST_SUCCESS;
}

  • Sign in to reply
  • Cancel

Top Replies

  • flyingbean
    flyingbean over 2 years ago in reply to fastian16 +1
    Hi fastian16: I will take a look of the issue this weekend. Hopefully, I can reproduce your issue. I don't have zynqMP ultrazed. I am going to use a zynq FPGA for the project.
  • saadtiwana_int
    saadtiwana_int over 2 years ago

    I believe the issue is that your executable (.elf) is built for baremetal OS, and not for Linux OS. 

    When running under Linux OS, I think you need to use the Linux drivers (and the Linux device).  To my knowledge, the baremetal code cannot simply be run on Linux.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • fastian16
    fastian16 over 2 years ago in reply to saadtiwana_int

    I have built executable (.elf) for baremetal OS and running it on R50 processor. It is not running on Linux OS.

    The issue is not with the application platform. The .elf file executes successfully on remote processor (R50) but PS-UART1 goes to reset state when configuring baud rate in the application.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • fastian16
    fastian16 over 2 years ago

    I am still facing the issue with PS-UART 1 in zynqMP ultrazed. The issue is that PS-UART1 goes to the reset state when it is access using linux image. Here, is the update regarding the debugging that is performed.

    1) I have ensured both PS-UARTs are enabled in the Vivado with baudrate 115200. Also, PS-UART 0 is used as debug Uart in petalinux. Confirmed it in petalinux configuration using petalinux-config command. 

    2) Verified Device Tree Parameters of both UARTs in the system.dtb file generated by petalinux. The device tree parameters related to PS UARTs are given below.

    aliases {
    ethernet0 = "/amba/ethernet@ff0e0000";
    i2c0 = "/amba/i2c@ff030000";
    serial0 = "/amba/serial@ff000000";
    serial1 = "/amba/serial@ff010000";
    spi0 = "/amba/spi@ff0f0000";
    };

    serial@ff000000 {
    u-boot,dm-pre-reloc;
    compatible = "cdns,uart-r1p12", "xlnx,xuartps";
    status = "okay";
    interrupt-parent = <0x4>;
    interrupts = <0x0 0x15 0x4>;
    reg = <0x0 0xff000000 0x0 0x1000>;
    clock-names = "uart_clk", "pclk";
    power-domains = <0xc 0x21>;
    clocks = <0x3 0x38 0x3 0x1f>;
    cts-override;
    device_type = "serial";
    port-number = <0x0>;
    current-speed = <0x1c200>;
    };

    serial@ff010000 {
    u-boot,dm-pre-reloc;
    compatible = "cdns,uart-r1p12", "xlnx,xuartps";
    status = "okay";
    interrupt-parent = <0x4>;
    interrupts = <0x0 0x16 0x4>;
    reg = <0x0 0xff010000 0x0 0x1000>;
    clock-names = "uart_clk", "pclk";
    power-domains = <0xc 0x22>;
    clocks = <0x3 0x39 0x3 0x1f>;
    cts-override;
    device_type = "serial";
    port-number = <0x1>;
    current-speed = <0x1c200>;
    };

    3) I have also checked the PS-UART driver information in the linux image using following commands.

    cat /proc/tty/driver/xuartps0 

    0: uart:xuartps mmio:0xFF000000 irq:48 tx:1266 rx:29 RTS|DTR

    cat /proc/tty/driver/xuartps1

    0: uart:xuartps mmio:0xFF010000 irq:49 tx:0 rx:0

    Here, my concern is that why UART ID is showing same (Zero) for both PS Uarts. 

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • flyingbean
    flyingbean over 2 years ago in reply to fastian16

    Hi fastian16: I will take a look of the issue this weekend. Hopefully, I can reproduce your issue. I don't have zynqMP ultrazed. I am going to use a zynq FPGA for the project.

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • Cancel
  • flyingbean
    flyingbean over 1 year ago in reply to fastian16
    fastian16 said:
    The issue is not with the application platform. The .elf file executes successfully on remote processor (R50) but PS-UART1 goes to reset state when configuring baud rate in the application.

    The issue is that PS does need Linux type UART1 API at the user space. The remote process routing from Xilinx is PS/APU to R5(baremetal) at Xilinx demo is as below :

    image

    So you did not have issue while you used bare-metal version's UART1 API for R5 processor. However, it does not means you can use the same UART1 bare-metal API on PS side. You do need different driver for UART1 on PS. It is not as simple as you thought.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • fastian16
    fastian16 over 1 year ago in reply to flyingbean

    I think I need to clear the problem with some more description. I have built an baremetal application for the R50 processor with the source code provided above to test PS-UART 1 in ZynqMP. There are two cases.

    Case # 1: 

    The application is run successfully when I run this baremetal application on the R50 processor in JTAG mode using SDK Debugger. In this case, there is no Linux involved. 

    Case # 2:

    Now, I have generated petalinux build for the PS side. The settings configured in the device tree of the petalinux related to UARTs are defined below. In petalinux, I have confirmed that PS-UART 0 is used as debug UART. When image is booted in the system, I have run the same (.elf) file generated for R50 processor in the previous step on the R50 processor using following command.

    echo UARTSelfTest.elf > /sys/class/remoteproc/remoteproc0/firmware
    echo start > /sys/class/remoteproc/remoteproc0/state

    But in this case, PS-UART 1 goes to reset state. I have confirmed it with its control register at address 0xff010000

    -In both cases, the baremetal application is run on the R50 processor. Why I need different driver in the second case?

     

    Device Tree Settings:

     

    aliases {
    ethernet0 = "/amba/ethernet@ff0e0000";
    i2c0 = "/amba/i2c@ff030000";
    serial0 = "/amba/serial@ff000000";
    serial1 = "/amba/serial@ff010000";
    spi0 = "/amba/spi@ff0f0000";
    };

    serial@ff000000 {
    u-boot,dm-pre-reloc;
    compatible = "cdns,uart-r1p12", "xlnx,xuartps";
    status = "okay";
    interrupt-parent = <0x4>;
    interrupts = <0x0 0x15 0x4>;
    reg = <0x0 0xff000000 0x0 0x1000>;
    clock-names = "uart_clk", "pclk";
    power-domains = <0xc 0x21>;
    clocks = <0x3 0x38 0x3 0x1f>;
    cts-override;
    device_type = "serial";
    port-number = <0x0>;
    current-speed = <0x1c200>;
    };

    serial@ff010000 {
    u-boot,dm-pre-reloc;
    compatible = "cdns,uart-r1p12", "xlnx,xuartps";
    status = "okay";
    interrupt-parent = <0x4>;
    interrupts = <0x0 0x16 0x4>;
    reg = <0x0 0xff010000 0x0 0x1000>;
    clock-names = "uart_clk", "pclk";
    power-domains = <0xc 0x22>;
    clocks = <0x3 0x39 0x3 0x1f>;
    cts-override;
    device_type = "serial";
    port-number = <0x1>;
    current-speed = <0x1c200>;
    };

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • flyingbean
    flyingbean over 1 year ago

    ZynqMP UART1 should work. However, the bare-metal BSP needs such configuration:

    image

    If you did not do it, please reconfigure the BSP for the UART1 API and build it again. If you did it as the graph shows, I think Linux OS might have issues.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • fastian16
    fastian16 over 1 year ago in reply to flyingbean

    -I have enabled openamp and libmetal libraries as you described in the previous comment in the BSP. but the issue still arises in the UART 1. 

    -What sort of issue can be in the Linux OS? 

    -I have also checked the PS-UART driver information in the linux image using following commands.

    cat /proc/tty/driver/xuartps0 

    0: uart:xuartps mmio:0xFF000000 irq:48 tx:1266 rx:29 RTS|DTR

    cat /proc/tty/driver/xuartps1

    0: uart:xuartps mmio:0xFF010000 irq:49 tx:0 rx:0

    Here, my concern is that why UART ID is showing same (Zero) for both PS Uarts. 

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • flyingbean
    flyingbean over 1 year ago

    For IPI running from a remote processor, zcu102 TRD is a good demo. If you read DM4 device tree files, you can find that R5_0 or R5_1 need a reserved DDR memory for the bear-metal API. zcu102 TRD used R5_1 for this case. I attached rpu1.dtsi for your reference.

    {
    	/*
    	 * Reserve DDR memory for RPU1 application toward the top of the
    	 * 1GB address range (DDR_LOW).
    	 */
    	reserved-memory {
    		#address-cells = <2>;
    		#size-cells = <2>;
    		ranges;
    		rpu1vdev0vring0: rpu0vdev0vring0@4ff40000 {
    			no-map;
    			reg = <0x0 0x4ff40000 0x0 0x4000>;
    
    		};
    
    		rpu1vdev0vring1: rpu0vdev0vring1@4ff44000 {
    			no-map;
    			reg = <0x0 0x4ff44000 0x0 0x4000>;
    
    		};
    
    		rpu1vdev0buffer: rpu0vdev0buffer@4ff48000 {
    			no-map;
    			reg = <0x0 0x4ff48000 0x0 0x100000>;
    		};
    
    		rproc_1_dma: rproc@4f000000 {
    			no-map;
    
    			reg = <0x0 0x4f000000 0x0 0x40000>;
    		};
    	};
    
    	zynqmp-rpu {
    		compatible = "xlnx,zynqmp-r5-remoteproc-1.0";
    		#address-cells = <2>;
    		#size-cells = <2>;
    		ranges;
    		core_conf = "split";
    		reg = <0x0 0xFF9A0000 0x0 0x10000>;
    		r5_1: r5@1 {
    			#address-cells = <2>;
    			#size-cells = <2>;
    			ranges;
    			memory-region = <&rproc_1_dma>, <&rpu1vdev0buffer>, <&rpu1vdev0vring0>, <&rpu1vdev0vring1>;
    			pnode-id = <0x8>;
    			mboxes = <&ipi_mailbox_rpu1 0>, <&ipi_mailbox_rpu1 1>;
    			mbox-names = "tx", "rx";
    			r5_1_tcm_a: tcm@ffe90000 {
    				reg = <0x0 0xFFE90000 0x0 0x10000>;
    				pnode-id = <0x11>;
    			};
    			r5_1_tcm_b: tcm@ffeb0000 {
    				reg = <0x0 0xFFEB0000 0x0 0x10000>;
    				pnode-id = <0x12>;
    			};
    		};
    	};
    
    	zynqmp_ipi1 {
    		compatible = "xlnx,zynqmp-ipi-mailbox";
    		interrupt-parent = <&gic>;
    		interrupts = <0 29 4>;
    		xlnx,ipi-id = <7>;
    		#address-cells = <1>;
    		#size-cells = <1>;
    		ranges;
    
    		/* APU<->RPU1 IPI mailbox controller */
    		ipi_mailbox_rpu1: mailbox@ff90600 {
    			reg = <0xff990600 0x20>,
    			<0xff990620 0x20>,
    			<0xff9900c0 0x20>,
    			<0xff9900e0 0x20>;
    			reg-names = "local_request_region",
    			"local_response_region",
    			"remote_request_region",
    			"remote_response_region";
    			#mbox-cells = <1>;
    			xlnx,ipi-id = <2>;
    		};
    	};
    };
    

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • fastian16
    fastian16 over 1 year ago in reply to flyingbean

    flyingbean The device tree settings you have mentioned in the previous comment are already set in my zynqMP device tree. The device tree parameters described in the system-user.dtsi are described below.

    memory {

    device-type = "memory";
    reg = <0x0 0x0 0x0 0x40000000>;
    };
    reserved-memory
    {
    #address-cells = <2>;
    #size-cells = <2>;
    ranges;

    rproc_0_dma_reserved: rproc@2ef00000
    {
    no-map;
    compatible = "shared-dma-pool";
    reg = <0x0 0x2ef00000 0x0 0x100000>;
    };

    rproc_0_fw_reserved: rproc@2ed00000
    {
    no-map;
    reg = <0x0 0x2ed00000 0x0 0x2000000>;
    };

    rproc_1_fw_reserved: rproc@3ed00000
    {
    no-map;
    reg = <0x0 0x3ed00000 0x0 0x200000>;
    };

    rproc_1_dma_reserved: rproc@3ef00000
    {
    compatible = "shared-dma-pool";
    no-map;
    reg = <0x0 0x3ef00000 0x0 0x100000>;
    };
    /*rproc_0_dma_reserved: rproc@3ef00000
    {
    no-map;
    compatible = "shared-dma-pool";
    reg = <0x0 0x3ef00000 0x0 0x100000>;
    };

    rproc_0_fw_reserved: rproc@3ed00000
    {
    no-map;
    reg = <0x0 0x3ed00000 0x0 0x2000000>;
    };

    rproc_1_fw_reserved: rproc@4ed00000
    {
    no-map;
    reg = <0x0 0x4ed00000 0x0 0x200000>;
    };

    rproc_1_dma_reserved: rproc@4ef00000
    {
    compatible = "shared-dma-pool";
    no-map;
    reg = <0x0 0x4ef00000 0x0 0x100000>;
    };
    fx3_reserved: buffer@0
    {
    no-map;
    reg = <0x0 0x20000000 0x0 0x10000000>;
    };*/
    };

    zynqmp-rpu
    {
    compatible = "xlnx,zynqmp-r5-remoteproc-1.0";
    #address-cells = <2>;
    #size-cells = <2>;
    ranges;
    core_conf = "split";

    r5_0: r5@0
    {
    #address-cells = <2>;
    #size-cells = <2>;
    ranges;
    memory-region = <&rproc_0_fw_reserved>, <&rproc_0_dma_reserved>;
    pnode-id = <0x7>;
    mboxes = <&ipi_mailbox_rpu0 0>, <&ipi_mailbox_rpu0 1>;
    mbox-names = "tx", "rx";

    tcm_0_a: tcm_0@0
    {
    reg = <0x0 0xFFE00000 0x0 0x10000>;
    pnode-id = <0xf>;
    };

    tcm_0_b: tcm_0@1
    {
    reg = <0x0 0xFFE20000 0x0 0x10000>;
    pnode-id = <0x10>;
    };
    };

    r5_1: r5@1
    {
    #address-cells = <2>;
    #size-cells = <2>;
    ranges;
    memory-region = <&rproc_1_fw_reserved>, <&rproc_1_dma_reserved>;
    pnode-id = <0x8>;
    mboxes = <&ipi_mailbox_rpu1 0>, <&ipi_mailbox_rpu1 1>;
    mbox-names = "tx", "rx";
    r5_1_tcm_a: tcm@ffe90000
    {
    reg = <0x0 0xFFE90000 0x0 0x10000>;
    pnode-id = <0x11>;
    };

    r5_1_tcm_b: tcm@ffeb0000
    {
    reg = <0x0 0xFFEB0000 0x0 0x10000>;
    pnode-id = <0x12>;
    };
    };

    };

    zynqmp_ipi1
    {
    compatible = "xlnx,zynqmp-ipi-mailbox";
    interrupt-parent = <&gic>;
    interrupts = <0 29 4>;
    xlnx,ipi-id = <7>;
    #address-cells = <1>;
    #size-cells = <1>;
    ranges;

    /* APU<->RPU0 IPI mailbox controller */
    ipi_mailbox_rpu0: mailbox@ff90600
    {
    reg = <0xff990600 0x20>,
    <0xff990620 0x20>,
    <0xff9900c0 0x20>,
    <0xff9900e0 0x20>;
    reg-names = "local_request_region",
    "local_response_region",
    "remote_request_region",
    "remote_response_region";
    #mbox-cells = <1>;
    xlnx,ipi-id = <1>;
    };
    };

    zynqmp_ipi2
    {
    compatible = "xlnx,zynqmp-ipi-mailbox";
    interrupt-parent = <&gic>;
    interrupts = <0 30 4>;
    xlnx,ipi-id = <8>;
    #address-cells = <1>;
    #size-cells = <1>;
    ranges;

    /* APU<->RPU1 IPI mailbox controller */
    ipi_mailbox_rpu1: mailbox@ff3f0b00
    {
    reg = <0xff3f0b00 0x20>,
    <0xff3f0b20 0x20>,
    <0xff3f0940 0x20>,
    <0xff3f0960 0x20>;
    reg-names = "local_request_region",
    "local_response_region",
    "remote_request_region",
    "remote_response_region";
    #mbox-cells = <1>;
    xlnx,ipi-id = <2>;
    };
    };

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
>
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube