cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
543 Views
Registered: ‎11-22-2019

UG1186 2019. OpenAMP failure on Zynq7000

Hello all, this is my first post here, so excuses if something/everything is done incorrectly

I am trying to verify the UG1186 documentation reference mapping a uZed card using Petalinux 2019.2. The majority of the note related with the ZynQMP and libmetal have been successfully tested with the QEMU framework using the U96 expression.

However... the ZynQ 7000 is not the case.

The reference note is quite dense so let's focus from here on the reference application rpmsg-echo.

I have successfully tested the feasibility using the PetaLinux firmware provided under the option openamp-fw-echo-test. The Linux device tree add-on system-user.dtsi supporting the amp application is below

 

 

/include/ "system-conf.dtsi"
/ {
SlaveBMA91 {
    	compatible = "xlnx,zynq_remoteproc";
    	vring0 = <15>;
    	vring1 = <14>;
        firmware="firmware";
    	memory-region = <&rproc_0_reserved>, <&rproc_0_dma>;
    	status="okay";
};
	
reserved-memory {
    	#address-cells = <1>;
    	#size-cells = <1>;
    	ranges;
    	rproc_0_reserved: rproc@3e000000 {
        	no-map;
        	reg = <0x3e000000 0x400000>;
    	};
    	rproc_0_dma: rproc@3e800000 {
        	no-map;
        	compatible = "shared-dma-pool";
        	reg = <0x3e800000 0x100000>;
    	};
 };
}

 

The PetaLinux tested kernel is deployed on the A9.0 core;  it successfully detects the device tree entries on the boot phase, below is a fragment of the /var/log/messages log file

 

[    2.099485] zynq_remoteproc SlaveBMA91: assigned reserved memory node rproc@3e800000
[    2.099597] remoteproc remoteproc0: SlaveBMA91 is available

 

On user space we can load on the remoteproc0(the A9.1) the Peta Linux firmware image_echo_test through the sys/class user interface. The logistics related with the RPM framework seems to be correctly threaded

 

[ 7033.733949] remoteproc remoteproc0: powering up SlaveBMA91
[ 7033.979787] remoteproc remoteproc0: Booting fw image pre-built/image_echo_test, size 2705004
[ 7034.080561] virtio_rpmsg_bus virtio0: rpmsg host is online
[ 7034.086088] virtio_rpmsg_bus virtio0: creating channel rpmsg-openamp-demo-channel addr 0x0
[ 7034.095488] remoteproc remoteproc0: registered virtio0 (type 7)
[ 7034.102866] remoteproc remoteproc0: remote processor SlaveBMA91 is now up

 

The application is loaded, the endpoint and the rpmsg openamp channel both created, so far so good. From here, we conclude that the tested Linux kernel is properly instrumented (modules, device tree and memory maps) since the RPM point of view.

The rpmsg end point is successfully tested from the Linux user space with this application. Our example mimics the git one, which verifies, for a dynamic value on the payload size, that the received and transmitted pattern value the same. The last column monitors the number of tries that we should wait before the read is available. The output is like this

 

root@popov:/lib/firmware# /opt/shared/bin/openAMP/echo_test.a9.662289b.x 
Tue Apr  7 11:10:37 2020

payload.id(   0)( ack.sized as    9 vs    9 )( 1 )
payload.id(   1)( ack.sized as   10 vs   10 )( 1 )
payload.id(   2)( ack.sized as   11 vs   11 )( 1 )
payload.id(   3)( ack.sized as   12 vs   12 )( 1 )
payload.id(   4)( ack.sized as   13 vs   13 )( 1 )
payload.id(   5)( ack.sized as   14 vs   14 )( 1 )
payload.id(   6)( ack.sized as   15 vs   15 )( 1 )
payload.id(   7)( ack.sized as   16 vs   16 )( 1 )
payload.id(   8)( ack.sized as   17 vs   17 )( 1 )
payload.id(   9)( ack.sized as   18 vs   18 )( 1 )
payload.id(  10)( ack.sized as   19 vs   19 )( 1 )
payload.id(  11)( ack.sized as   20 vs   20 )( 1 )
payload.id(  12)( ack.sized as   21 vs   21 )( 1 )
payload.id(  13)( ack.sized as   22 vs   22 )( 1 )
payload.id(  14)( ack.sized as   23 vs   23 )( 1 )
payload.id(  15)( ack.sized as   24 vs   24 )( 1 )
payload.id(  16)( ack.sized as   25 vs   25 )( 1 )
payload.id(  17)( ack.sized as   26 vs   26 )( 1 )
payload.id(  18)( ack.sized as   27 vs   27 )( 1 )
payload.id(  19)( ack.sized as   28 vs   28 )( 1 )
payload.id(  20)( ack.sized as   29 vs   29 )( 1 )
payload.id(  21)( ack.sized as   30 vs   30 )( 1 )
payload.id(  22)( ack.sized as   31 vs   31 )( 1 )
payload.id(  23)( ack.sized as   32 vs   32 )( 1 )
bool endPointTesting(int, int)Round 0 err_count(0)

 

Now, the issues..

Using the nm tool one can suspect that the PetaLinux firmware image_echo_test is assembled with FreeRTOS

 

petalinux@lepton:firmware (feature/device-trees)$ arm-none-eabi-gcc-nm image_echo_test | grep xTask
3e00430c T uxTaskGetNumberOfTasks
3e004e94 T uxTaskGetSystemState
3e004d08 T uxTaskGetTaskNumber
3e214218 b uxTaskNumber
3e003f1c T uxTaskPriorityGet
3e003f48 T uxTaskPriorityGetFromISR
3e00543c T uxTaskResetEventItemValue

 

So lets try to rebuild the A9 remote firmware with the Xilinx-SDK-2019.1. Following the proposed design flow on UG1186 , the example image_echo is selected and applied on core A9.1. The BSP compiled with -DUSE_AMP=1 and the openamp WITH_PROXY option valued as false. The linker section follows, it mimics the contains of the xilinx git sources

 

MEMORY
{
   ps7_ddr_0_S_AXI_BASEADDR : ORIGIN = 0x3e000000, LENGTH = 0x00400000
   ps7_ram_0_S_AXI_BASEADDR : ORIGIN = 0x00000000, LENGTH = 0x00030000
   ps7_ram_1_S_AXI_BASEADDR : ORIGIN = 0xFFFF0000, LENGTH = 0x0000FE00
}

 

Which is fully reasonable with the device tree pollution we have done, the ps7_ddr_0_S_AXI_BASEADDR origin and sized maps on the rproc_0_reserved area. The parameters related with the shared memory are defined on platform_info.h

 

/* Shared memory */
#define SHARED_MEM_PA  0x3e800000UL
#define SHARED_MEM_SIZE 0x80000UL
#define SHARED_BUF_OFFSET 0x80000UL

 

Which are also reasonable because they maps the rproc_0_dma Linux device tree entry. They are used on plaftorm_info.c when the memory is remapped on the platform_create_proc symbol

 

/* mmap shared memory */
	pa = SHARED_MEM_PA;
    (void *)remoteproc_mmap(&rproc_inst, &pa, NULL, SHARED_MEM_SIZE, NORM_NONCACHE | STRONG_ORDERED, NULL);

 

 and virtualised afterwards on the platform_create_rpmsg_vdev symbol

 

shbuf_io = remoteproc_get_io_with_pa(rproc, SHARED_MEM_PA );
if (!shbuf_io)
 return NULL;
shbuf = metal_io_phys_to_virt(shbuf_io, SHARED_MEM_PA + SHARED_BUF_OFFSET);

 

So, in summary a window of 512Kbyes is mapped between both processors from the 0x3e800000 system address, which corresponds with the DDR device and it's properly excluded from the Linux Kernel. We build the .elf and try to repeat the test on the Zed board

This is the output

 

[11451.165834] remoteproc remoteproc0: powering up SlaveBMA91
[11451.428043] remoteproc remoteproc0: Booting fw image xilinx-sdk/image_echo_test.elf, size 2856536
[11451.519684] virtio_rpmsg_bus virtio0: rpmsg host is online
[11451.526218] remoteproc remoteproc0: registered virtio0 (type 7)
[11451.532691] remoteproc remoteproc0: remote processor SlaveBMA91 is now up

 

Obviously... the user application now fails on the rpmsg binding phase

 

root@popov:/lib/firmware# /opt/shared/bin/openAMP/echo_test.a9.662289b.x 

Tue Apr  7 13:10:37 2020

int cRPEndPoint::binding(const string&)
/sys/bus/rpmsg/devices/virtio0.rpmsg-openamp-demo-channel.-1.0 errno(2)( No such file or directory )

 

My questions are:

  1. Why the rpmsg channel is NOT created ?
  2. Where are the SOURCES of the PetaLinux prebuilt image ?
  3. Looking at the Xilinx-SDK sources, one can realize that some output is projected on the xil_printf  symbol routed to the ps7_uart_1 it can be confirmed it running  .elf in standalone mode under Qemu.

 

juanba@lepton:CortexA53/CortexA9 (feature/device-trees *+)$ a91.qemu.startup.sh 

Tue Apr  7 15:42:21 CEST 2020
a91.qemu.startup.sh: Loading ZynQ.arquitecture CA9.1
gdb port(1440) ctrl-a c :interacts with QEMU console, ctrl-a x :quit emulation
a91.qemu.startup.sh:   Entry point address:               0x100000

Starting application...
Successfully intialize remoteproc.
Initialize remoteproc successfully.
creating remoteproc virtio

 

However the linux console is muted on that sense, how can i inspect those messages ?

Hints and Tips about how to solve this ?

Thanks in advance

Tags (3)
0 Kudos
1 Reply
Highlighted
Moderator
Moderator
435 Views
Registered: ‎05-10-2017

For 2019.2, Vitis should be used to build the OpenAMP application.

The source code for the application is here

https://github.com/Xilinx/meta-openamp/tree/rel-v2019.2/recipes-openamp/rpmsg-examples

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