Help with OpenAMP setup

[Simon Brummer]

Hi Everybody,

I am working in a small company and we are using OpenAMP on Hardware
based on the Xilinx
ZED Board (with a Xilinx Zynq®-7000 All Programmable SoC on Board).

We are using Xilinx SDK (Release Version 2016.2) with OpenAMP (v 1.0)
in a setup running Linux as Master on CPU1 and a Baremetal Application
via remoteproc on CPU0.

Our setup is very similar to the examples delivered with the Xilinx SDK.

Currently our baremetal application crashes without any obvious reason
(probably a non-deterministic memory corruption)
and we think the source of this behavior might be a faulty OpenAMP
setup.

We took the setup from the supplied 'echo test' example, however our
bare metal application is much larger in size.
So things like the resource_table might be mis-configured (its hard to
find documentation on doing it right).

I hope somebody on the Mailing list could help me solving this issue.

Your Memory Map is divided into the following areas (ZED Board, 521 MB):

DDR_BASEADDR: 0x00100000 to 0x0EFFFFF (The baremetal
application resides here)
SHARED_MEMORY: 0x0F000000 to 0x0FFFFFF (Shared Memory between
Linux and the baremetal application)
LINUX_BASEADDR: 0x10000000 to 0x1FFFFFF (Linux Memory)

Here is our OpenAMP related section of our device tree:

openamp.dts:

/dts-v1/;
/include/ "system-conf.dtsi"
/ {
};

&flash0 {
compatible = "spansion,s25fl256s1";
};

/{
usb_phy0: usb_phy@0 {
compatible = "ulpi-phy";
#phy-cells = <0>;
reg = <0xe0002000 0x1000>;
view-port = <0x0170>;
drv-vbus;
};
};

&usb0 {
dr_mode = "otg";
usb-phy = <&usb_phy0>;
} ;

/include/ "openamp-overlay.dtsi"

openamp.dtsi

/ {
amba {
remoteproc0: remoteproc@0 {
compatible = "xlnx,zynq_remoteproc";
reg = < 0x00000000 0x10000000 >;
firmware = "firmware";
vring0 = <15>;
vring1 = <14>;
};
};
};

Here is our configured resource table:

rsc_table.h:

#ifndef RSC_TABLE_H
#define RSC_TABLE_H

#include <stddef.h>
#include "openamp/open_amp.h"

#define NO_RESOURCE_ENTRIES 8

/* Resource table for the given remote */
struct remote_resource_table {
unsigned int version;
unsigned int num;
unsigned int reserved[2];
unsigned int offset[NO_RESOURCE_ENTRIES];
/* text carveout entry */

struct fw_rsc_carveout elf_cout;

/* rpmsg vdev entry */
struct fw_rsc_vdev rpmsg_vdev;
struct fw_rsc_vdev_vring rpmsg_vring0;
struct fw_rsc_vdev_vring rpmsg_vring1;
};

#endif

rsc_table.c:

#include "../openamp/rsc_table.h"

/* Place resource table in special ELF section */
#define __rsc_section(S) __attribute__((__section__(#S)))
#define __resource __rsc_section(.resource_table)

#define RPMSG_IPU_C0_FEATURES 1

/* VirtIO rpmsg device id */
#define VIRTIO_ID_RPMSG_ 7

/* Remote supports Name Service announcement */
#define VIRTIO_RPMSG_F_NS 0


/* Resource table entries */
#define ELF_START 0x00000000
#define ELF_END 0x08000000
#define NUM_VRINGS 0x02
#define VRING_ALIGN 0x1000
#define RING_TX 0x08000000
#define RING_RX 0x08004000
#define VRING_SIZE 256

#define NUM_TABLE_ENTRIES 2
#define CARVEOUT_SRC_OFFSETS offsetof(struct
remote_resource_table, elf_cout),
#define CARVEOUT_SRC { RSC_CARVEOUT, ELF_START,
ELF_START, ELF_END, 0, 0, "ELF_COUT", },


extern const struct remote_resource_table __resource k_resources =
{
/* Version */
1,

/* NUmber of table entries */
NUM_TABLE_ENTRIES,
/* reserved fields */
{ 0, 0,},

/* Offsets of rsc entries */
{
CARVEOUT_SRC_OFFSETS
offsetof(struct remote_resource_table, rpmsg_vdev),
},

/* End of ELF file */
CARVEOUT_SRC

/* Virtio device entry */
{ RSC_VDEV, VIRTIO_ID_RPMSG_, 0, RPMSG_IPU_C0_FEATURES, 0, 0, 0,
NUM_VRINGS, {0, 0},
},

/* Vring rsc entry - part of vdev rsc entry */
{
RING_TX, VRING_ALIGN, VRING_SIZE, 1, 0
},
{
RING_RX, VRING_ALIGN, VRING_SIZE, 2, 0
},
};

And here is our Linker Script:

_STACK_SIZE = DEFINED(_STACK_SIZE) ? _STACK_SIZE : 0x2000000;
_HEAP_SIZE = DEFINED(_HEAP_SIZE) ? _HEAP_SIZE : 0x4000000;

_ABORT_STACK_SIZE = DEFINED(_ABORT_STACK_SIZE) ? _ABORT_STACK_SIZE :
1024;
_SUPERVISOR_STACK_SIZE = DEFINED(_SUPERVISOR_STACK_SIZE) ?
_SUPERVISOR_STACK_SIZE : 2048;
_IRQ_STACK_SIZE = DEFINED(_IRQ_STACK_SIZE) ? _IRQ_STACK_SIZE : 4096;
_FIQ_STACK_SIZE = DEFINED(_FIQ_STACK_SIZE) ? _FIQ_STACK_SIZE : 1024;
_UNDEF_STACK_SIZE = DEFINED(_UNDEF_STACK_SIZE) ? _UNDEF_STACK_SIZE :
1024;

/* Define Memories in the system */

MEMORY
{
/* 0x0 -> 0xfffff(1MByte) = OCM(128KByte) + ROM(128KByte) + Reserved
space */
OCM_LOW_BASEADDR : ORIGIN = 0x00000000, LENGTH = 0x00030000
/* 0x00100000 -> 0xEFFFFFF (240Mbyte) RT Application memory */
DDR_BASEADDR : ORIGIN = 0x00100000, LENGTH = 0x0EF00000
/* 0xF000000 -> 0xFF00000 (15Mbyte) */
SH_MEM_BASEADDR : ORIGIN = 0x0F000000, LENGTH = 0x00EFFFFF
/* 0x10000000 -> 0xFFFFFFF (256Mbyte) LINUX */
LINUX_BASEADDR : ORIGIN = 0x10000000, LENGTH = 0x0FFFFFFF
/* mappen by MMU (TRM) register */
OCM_HIGH_BASEADDR : ORIGIN = 0xFFFF0000, LENGTH = 0x0000FE00
}

/* Specify the default entry point to the program */

ENTRY(_vector_table)

/* Define the sections, and where they are mapped in memory */

SECTIONS
{
.text : {

_binary_firmware1_start = 0;
_binary_firmware1_end = 0;
_binary_firmware2_start = 0;
_binary_firmware2_end = 0;

*(.vectors)
*(.boot)
*(.text)
*(.text.*)
*(.gnu.linkonce.t.*)
*(.plt)
*(.gnu_warning)
*(.gcc_execpt_table)
*(.glue_7)
*(.glue_7t)
*(.vfp11_veneer)
*(.ARM.extab)
*(.gnu.linkonce.armextab.*)
} > DDR_BASEADDR

.init : {
KEEP (*(.init))
} > DDR_BASEADDR

.fini : {
KEEP (*(.fini))
} > DDR_BASEADDR

.rodata : {
__rodata_start = .;
*(.rodata)
*(.rodata.*)
*(.gnu.linkonce.r.*)
__rodata_end = .;
} > DDR_BASEADDR

.rodata1 : {
__rodata1_start = .;
*(.rodata1)
*(.rodata1.*)
__rodata1_end = .;
} > DDR_BASEADDR

.sdata2 : {
__sdata2_start = .;
*(.sdata2)
*(.sdata2.*)
*(.gnu.linkonce.s2.*)
__sdata2_end = .;
} > DDR_BASEADDR

.sbss2 : {
__sbss2_start = .;
*(.sbss2)
*(.sbss2.*)
*(.gnu.linkonce.sb2.*)
__sbss2_end = .;
} > DDR_BASEADDR

.data : {
__data_start = .;
*(.data)
*(.data.*)
*(.gnu.linkonce.d.*)
*(.jcr)
*(.got)
*(.got.plt)
__data_end = .;
} > DDR_BASEADDR

.data1 : {
__data1_start = .;
*(.data1)
*(.data1.*)
__data1_end = .;
} > DDR_BASEADDR

.got : {
*(.got)
} > DDR_BASEADDR

.ctors : {
__CTOR_LIST__ = .;
___CTORS_LIST___ = .;
KEEP (*crtbegin.o(.ctors))
KEEP (*(EXCLUDE_FILE(*crtend.o) .ctors))
KEEP (*(SORT(.ctors.*)))
KEEP (*(.ctors))
__CTOR_END__ = .;
___CTORS_END___ = .;
} > DDR_BASEADDR

.dtors : {
__DTOR_LIST__ = .;
___DTORS_LIST___ = .;
KEEP (*crtbegin.o(.dtors))
KEEP (*(EXCLUDE_FILE(*crtend.o) .dtors))
KEEP (*(SORT(.dtors.*)))
KEEP (*(.dtors))
__DTOR_END__ = .;
___DTORS_END___ = .;
} > DDR_BASEADDR

.fixup : {
__fixup_start = .;
*(.fixup)
__fixup_end = .;
} > DDR_BASEADDR

.eh_frame : {
*(.eh_frame)
} > DDR_BASEADDR

.eh_framehdr : {
__eh_framehdr_start = .;
*(.eh_framehdr)
__eh_framehdr_end = .;
} > DDR_BASEADDR

.gcc_except_table : {
*(.gcc_except_table)
} > DDR_BASEADDR

.mmu_tbl (ALIGN(16384)) : {
__mmu_tbl_start = .;
*(.mmu_tbl)
__mmu_tbl_end = .;
} > DDR_BASEADDR

.ARM.exidx : {
__exidx_start = .;
*(.ARM.exidx*)
*(.gnu.linkonce.armexidix.*.*)
__exidx_end = .;
} > DDR_BASEADDR

.preinit_array : {
__preinit_array_start = .;
KEEP (*(SORT(.preinit_array.*)))
KEEP (*(.preinit_array))
__preinit_array_end = .;
} > DDR_BASEADDR

.init_array : {
__init_array_start = .;
KEEP (*(SORT(.init_array.*)))
KEEP (*(.init_array))
__init_array_end = .;
} > DDR_BASEADDR

.fini_array : {
__fini_array_start = .;
KEEP (*(SORT(.fini_array.*)))
KEEP (*(.fini_array))
__fini_array_end = .;
} > DDR_BASEADDR

.ARM.attributes : {
__ARM.attributes_start = .;
*(.ARM.attributes)
__ARM.attributes_end = .;
} > DDR_BASEADDR

.sdata : {
__sdata_start = .;
*(.sdata)
*(.sdata.*)
*(.gnu.linkonce.s.*)
__sdata_end = .;
} > DDR_BASEADDR

.sbss (NOLOAD) : {
__sbss_start = .;
*(.sbss)
*(.sbss.*)
*(.gnu.linkonce.sb.*)
__sbss_end = .;
} > DDR_BASEADDR

.tdata : {
__tdata_start = .;
*(.tdata)
*(.tdata.*)
*(.gnu.linkonce.td.*)
__tdata_end = .;
} > DDR_BASEADDR

.tbss : {
__tbss_start = .;
*(.tbss)
*(.tbss.*)
*(.gnu.linkonce.tb.*)
__tbss_end = .;
} > DDR_BASEADDR

.bss (NOLOAD) : {
__bss_start = .;
*(.bss)
*(.bss.*)
*(.gnu.linkonce.b.*)
*(COMMON)
__bss_end = .;
} > DDR_BASEADDR

_SDA_BASE_ = __sdata_start + ((__sbss_end - __sdata_start) / 2 );

_SDA2_BASE_ = __sdata2_start + ((__sbss2_end - __sdata2_start) / 2 );

/* Generate Stack and Heap definitions */

.heap (NOLOAD) : {
. = ALIGN(16);
_heap = .;
HeapBase = .;
_heap_start = .;
. += _HEAP_SIZE;
_heap_end = .;
HeapLimit = .;
} > DDR_BASEADDR

.stack (NOLOAD) : {
. = ALIGN(16);
_stack_end = .;
. += _STACK_SIZE;
_stack = .;
__stack = _stack;
. = ALIGN(16);
_irq_stack_end = .;
. += _IRQ_STACK_SIZE;
__irq_stack = .;
_supervisor_stack_end = .;
. += _SUPERVISOR_STACK_SIZE;
. = ALIGN(16);
__supervisor_stack = .;
_abort_stack_end = .;
. += _ABORT_STACK_SIZE;
. = ALIGN(16);
__abort_stack = .;
_fiq_stack_end = .;
. += _FIQ_STACK_SIZE;
. = ALIGN(16);
__fiq_stack = .;
_undef_stack_end = .;
. += _UNDEF_STACK_SIZE;
. = ALIGN(16);
__undef_stack = .;
} > DDR_BASEADDR

_end = .;
}


I'll hope this is enough information to solve the issue. If anything
else is needed don't hesitate to contact me.
Is there documentation available that explains the entire setup process?
Most documentation shows how the
examples are used they don't go into details.

Thanks for your time, I'll looking forward reading the replies.

Kind Regards
Simon

[Jiaying Liang]

Hi Simon,

As you are using a different memory map to the default example, here is the stuff you can consider.
* Do you have to use CPU1 for Linux and CPU0 for baremetal? zynq remoteproc driver assumes Linux boots in SMP mode, and it will shutdown CPU1 first and then boot it with the specified firmware. If Linux boots in AMP mode, you made need to change the zynq remoteproc driver for it.
* which kernel do you use? If possible, you can consider to switch to Xilinx 2017.1 kernel, and if possible, you can try 2017.1 SDK.
* If you are using Xilinx v2016.2 kernel, you should consider the following issues:
* the virtio rpmsg failed to give the correct physical address to vrings, and on the rpmsg side, the 2016.2 version, it just mask out the most significant bits of the address got from the vring to work around it.
https://gitenterprise.xilinx.com/embeddedsw/embeddedsw/blob/master-vless-rel-2016.2/ThirdParty/sw_services/openamp/src/open-amp/lib/system/generic/machine/zynq7/machine_system.c
This is fixed in the Xilinx 2017.1 kernel and SDK
* zynq remoteproc driver will declare memory specified in the "reg = <>" attribute as DMA memory. It will allocate memory from this range for carveout (which is for firmware memory), vrings and rpmsg buffers. In your linker script, you specify "= 0x00100000, LENGTH = 0x0EF00000" for your firmware, and you put "reg = < 0x00000000 0x10000000 >" in your zynq remoteproc device node, it is not likely for Linux to put your firmware in the location specified in your linker script. In 2017.1 kernel, it provides an option to use mmio-sram for the firmware memory, if you need to make sure your firmware to be located in the exact memory as described in the linkerscript, you can specify mmio-sram for those memory but not using carveout. You can check the documentation in the kernel for the zynq remoteproc device tree bindings.

Best Regards,
Wendy

> --
> You received this message because you are subscribed to the Google Groups
> "open-amp" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to open-amp+u...@googlegroups.com.
> To post to this group, send an email to open...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

[brumme...@googlemail.com]

Hi Wendy,

I made a mistake before: CPU0 is used for Linux and CPU1 for the baremetal application. Our Linux boots in SMP mode so no problem there right?

In our setup we run a v4.4.0 linux kernel.

Our Memory layout should be as defined in the linker script, placing the baremetal application including vrings and anything needed for open amp operation into the address range between 0x00 10 00 00 and 0x0f 00 00 00.

Do I need to change the linker script (it is not aware of any vrings, so should the memory range used be less than 0x0f 00 00 00, to squeeze the vrings on top of that)? What to I need to write into the device tree? What values should the additional entries (_binary_firmware1_start, _binary_firmware1_end, _binary_firmware2_start, _binary_firmware2_end) in the linker script .text section have?

And what must be configured in the resource table?

Is there any documentation how to set it all up that goes beyond the simple examples?

Updating a new Xilinx SDK version is currently not an option because we have to show a internal prototype soon and we can't overview implications an update would have.

Thanks for your help :).

Best Regards,

Simon

[Jiaying Liang]

Hi Simon,

> -----Original Message-----
> From: brummer.simon via open-amp [mailto:open...@googlegroups.com]
> Sent: Thursday, May 04, 2017 12:18 AM
> To: open-amp <open...@googlegroups.com>
> Subject: Re: [open-amp] Help with OpenAMP setup
>
> Hi Wendy,
>
> I made a mistake before: CPU0 is used for Linux and CPU1 for the baremetal
> application. Our Linux boots in SMP mode so no problem there right?

[Wendy] Yes, it looks OK.

>
> In our setup we run a v4.4.0 linux kernel.
>
> Our Memory layout should be as defined in the linker script, placing the
> baremetal application including vrings and anything needed for open amp
> operation into the address range between 0x00 10 00 00 and 0x0f 00 00 00.

[Wendy] You may need to change "reg" of your zynq_remoteproc device node
to be <0x100000 size>, including vrings(0x8000 for both sides) and rpmsg buffers (256KB for both sides).

Because you use 2017.2 SDK openamp and Linux kernel, it is better to specify the possible memory
Range for the vrings and rpmsg buffers. It is because there is rpmsg DMA address issue in this version
Of kernel, you may also need to adjust the address mapping in OpenAMP code for that. Please see the
Pervious email.

>
> Do I need to change the linker script (it is not aware of any vrings, so should
> the memory range used be less than 0x0f 00 00 00, to squeeze the vrings on
> top of that)? What to I need to write into the device tree? What values
> should the additional entries (_binary_firmware1_start,
> _binary_firmware1_end, _binary_firmware2_start, _binary_firmware2_end)
> in the linker script .text section have?

[Wendy] That's for remoteproc master on baremetal to load firmware for remote,
I don't think you need those, but you will need to reverse them to pass compilation.

>
> And what must be configured in the resource table?

[Wendy] carve out memory and vdev including vrings.

>
> Is there any documentation how to set it all up that goes beyond the simple
> examples?

[Wendy] Please check the wiki of the openamp repo

Best Regards,
Wendy

>
> Updating a new Xilinx SDK version is currently not an option because we
> have to show a internal prototype soon and we can't overview implications
> an update would have.
>
> Thanks for your help :).
>
> Best Regards,
>
> Simon
>

[gaeap...@gmail.com]

> > Hi Everybody ,
> >
> > i'm using Vivado SDK 2017.4 and Petalinux 2017.4.
> >
> > I'm doing a custom application in UG1186 OpenAMP.
> >
> > The demo matrix_multiply in FreeRTOS set for default ps7_ddr0 as :
> >
> > base addr : 0x3e000000
> > size : 0x00400000
> >
> > Now , i'm adding code in FreeRTOS matrix_multiply.c and there is an error in SDK
> > based on overflow of ps7_ddr0.
> >
> > I increase size of ps7_ddr0 in lscript.ld as :
> >
> > base addr : 0x3e000000
> > size : 0x02C10000
> >
> > Now , what do I change in file .dtsi in Petalinux , to correspond this memory in SDK ?
> >
> > ( PS :
> > if I not change .dtsi file , there is output error in terminal :
> > truncated fw : 0x300000 avail ..... and FreeRTOS not run )
> >
> > ( if i change remoteproc node -> error memory Linux )
> > ( if i change elf_ddr node -> truncated fw error or bad phdr error )
> >
> >
> > I want to resolve this problem please , how do I change these nodes in openamp-overlay.dtsi ?
> >
> > Actually :
> >
> > / {
> > reserved-memory {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > ranges;
> > rproc_0_reserved: rproc@3e000000 {
> > no-map;
> > reg = <0x3e000000 0x01000000>;
> > };
> > };
> > amba {
> > elf_ddr_0: ddr@0 {
> > compatible = "mmio-sram";
> > reg = <0x3e000000 0x400000>;
> > };
> > };

> > remoteproc0: remoteproc@0 {
> > compatible = "xlnx,zynq_remoteproc";

> > firmware = "firmware";
> > vring0 = <15>;
> > vring1 = <14>;

> > srams = <&elf_ddr_0>;
> > }
>
>
> PS : ( Do I change rcs_table.c , too ? )

Actually :

//#include "openamp/open_amp.h"
#include "rsc_table.h"

/* Place resource table in special ELF section */
#define __rsc_section(S) __attribute__((__section__(#S)))
#define __resource __rsc_section(.resource_table)

#define RPMSG_IPU_C0_FEATURES 1

/* VirtIO rpmsg device id */
#define VIRTIO_ID_RPMSG_ 7

/* Remote supports Name Service announcement */
#define VIRTIO_RPMSG_F_NS 0

/* Resource table entries */
#define ELF_START 0x00000000
#define ELF_END 0x08000000
#define NUM_VRINGS 0x02
#define VRING_ALIGN 0x1000
#define RING_TX 0x08000000
#define RING_RX 0x08004000
#define VRING_SIZE 256

#define NUM_TABLE_ENTRIES 2
#define CARVEOUT_SRC_OFFSETS offsetof(struct remote_resource_table, elf_cout),
#define CARVEOUT_SRC { RSC_CARVEOUT, ELF_START, ELF_START, ELF_END, 0, 0, "ELF_COUT", },

const struct remote_resource_table __resource resources =

[Jiaying Liang]

> -----Original Message-----
> From: open...@googlegroups.com [mailto:open...@googlegroups.com]

> On Behalf Of gaeap...@gmail.com
> Sent: Thursday, August 16, 2018 8:47 AM
> To: open-amp <open...@googlegroups.com>
> Subject: Re: [open-amp] Help with OpenAMP setup
>
>

> > > Hi Everybody ,
> > >
> > > i'm using Vivado SDK 2017.4 and Petalinux 2017.4.
> > >
> > > I'm doing a custom application in UG1186 OpenAMP.
> > >
> > > The demo matrix_multiply in FreeRTOS set for default ps7_ddr0 as :
> > >
> > > base addr : 0x3e000000
> > > size : 0x00400000
> > >
> > > Now , i'm adding code in FreeRTOS matrix_multiply.c and there is an
> > > error in SDK based on overflow of ps7_ddr0.
> > >
> > > I increase size of ps7_ddr0 in lscript.ld as :
> > >
> > > base addr : 0x3e000000
> > > size : 0x02C10000
> > >
> > > Now , what do I change in file .dtsi in Petalinux , to correspond this
> memory in SDK ?
> > >
> > > ( PS :
> > > if I not change .dtsi file , there is output error in terminal :
> > > truncated fw : 0x300000 avail ..... and FreeRTOS not run )
> > >
> > > ( if i change remoteproc node -> error memory Linux ) ( if i change
> > > elf_ddr node -> truncated fw error or bad phdr error )

[Wendy] if there is "truncated fw" error, it is due to the segment described in your ELF exceeds the ELF file size.
The offset of your segment + segment file size(size of segment data in the ELF file) described in the segment is larger than the ELF file size.
It is due how your generate your ELF. You can use readelf to check details.

If it is "bad phdr" issue, do you have "bad phdr filesz ...." or "bad phdr da ...."?
If it is the first issue, it is due to your ELF, it means the size of the segment data in the ELF is larger than the size of the segment in the target memory.
If it is the 2nd one, you can change the reserved_memory node and the elf_ddr_0 to adjust the executable size.

Best Regards,
Wendy

[gaeap...@gmail.com]

OK ,so I execute command readelf -l FreeRTOS :

Elf file type is EXEC (Executable file)
Entry point 0x3e000000
There are 3 program headers, starting at offset 52

Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
EXIDX 0x208000 0x3e208000 0x3e208000 0x00008 0x00008 R 0x4
LOAD 0x010000 0x3e000000 0x3e000000 0x2339c 0x2339c RWE 0x10000
LOAD 0x100000 0x3e100000 0x3e100000 0x108010 0x123e20 RW 0x10000

Section to Segment mapping:
Segment Sections...
00 .ARM.exidx
01 .text .init .fini .rodata .data
02 .resource_table .eh_frame .mmu_tbl .ARM.exidx .init_array .fini_array .bss .heap .stack


I see that to the second segment LOAD , there is 0x00100000 offset > size of elf

in fact :

executing size FeeeRTOS :

text data bss dec hex filename
156248 1053012 114192 1323452 1431bc FreeRTOS

there is size of elf : 0x001431bc < 0x00100000

OK.


Now , I change start address and size of ps7_ddr0 in lscript.ld :

from :

base addr : 0x3e000000
size : 0x00040000

to :

base addr : 0x3e000000
size : 0x02C10000

I'm increasing only size of ps7_ddr0. Start Address is the same.


now , do I change node in openamp-overlay.dtsi , to adjust ?

where do I have to change in this file , in which number ?

This is actually default file .dtsi :

/ {
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;

rproc_0_reserved: rproc@3ed00000 {
no-map;
reg = < 0x3e000000 0x10000000 >;

};
};

amba {
elf_ddr_0: ddr@0 {
compatible = "mmio-sram";
reg = <0x3e000000 0x400000>;
};
};
remoteproc0: remoteproc@0 {
compatible = "xlnx,zynq_remoteproc";

firmware = "FreeRTOS";

};
};

[Jiaying Liang]

> -----Original Message-----
> From: open...@googlegroups.com [mailto:open...@googlegroups.com]
> On Behalf Of gaeap...@gmail.com
> Sent: Friday, August 17, 2018 10:11 AM
> To: open-amp <open...@googlegroups.com>
> Subject: Re: [open-amp] Help with OpenAMP setup
>

[Wendy] you can get the size of the ELF file itself with ls -l command, the size command is the binary data size within the ELF

[gaeap...@gmail.com]

OK , now if I have in lscript.ld

base addr 0x3e000000
size 0x02C100000

How do I have to configure these nodes to correspond firmware memory ?

rproc_0_reserved: rproc@3ed00000 {
no-map;
reg = < 0x3e000000 0x10000000 >;

elf_ddr_0: ddr@0 {
compatible = "mmio-sram";
reg = <0x3e000000 0x400000>;
};

Do I change 0x400000 in elf_ddr or 0x10000000 in reserved rproc ?
Do I have to change something in rcs_table.c in SDK ?

[Jiaying Liang]

> -----Original Message-----
> From: open...@googlegroups.com [mailto:open...@googlegroups.com]
> On Behalf Of gaeap...@gmail.com
> Sent: Saturday, August 18, 2018 6:21 AM
> To: open-amp <open...@googlegroups.com>
> Subject: Re: [open-amp] Help with OpenAMP setup
>

> > > > > To post to this group, send an email to open-
> a...@googlegroups.com.

[Wendy] reg = < 0x3e000000 0x02C100000 >;

>
>
> elf_ddr_0: ddr@0 {
> compatible = "mmio-sram";
> reg = <0x3e000000 0x400000>;
> };

[Wendy] reg = < 0x3e000000 0x02C100000 >;

>
> Do I change 0x400000 in elf_ddr or 0x10000000 in reserved rproc ?
> Do I have to change something in rcs_table.c in SDK ?

[Wendy] Remove the RPROC_MEM fields in the rsc_table

[gaeap...@gmail.com]

OK , Where do I have to remove ? What RPROC_MEM fields , in particular ?

rsc_table.h

#define NO_RESOURCE_ENTRIES 8

/* Resource table for the given remote */
struct remote_resource_table {
unsigned int version;
unsigned int num;
unsigned int reserved[2];
unsigned int offset[NO_RESOURCE_ENTRIES];

/* rproc memory entry */
struct fw_rsc_rproc_mem rproc_mem;

/* rpmsg vdev entry */
struct fw_rsc_vdev rpmsg_vdev;
struct fw_rsc_vdev_vring rpmsg_vring0;
struct fw_rsc_vdev_vring rpmsg_vring1;

}__attribute__((packed, aligned(0x100000)));


rsc_table.c

/* Resource table entries */

#define NUM_VRINGS 0x02
#define VRING_ALIGN 0x1000

#define RING_TX 0x3e600000
#define RING_RX 0x3e604000

#define VRING_SIZE 256

#define NUM_TABLE_ENTRIES 2

struct remote_resource_table __resource resources = {
/* Version */
1,

/* NUmber of table entries */
NUM_TABLE_ENTRIES,
/* reserved fields */
{0, 0,},

/* Offsets of rsc entries */
{

offsetof(struct remote_resource_table, rproc_mem),
offsetof(struct remote_resource_table, rpmsg_vdev),
},

{RSC_RPROC_MEM, 0x3e600000, 0x3e600000, 0x100000, 0},

[Jiaying Liang]

> -----Original Message-----
> From: open...@googlegroups.com [mailto:open...@googlegroups.com]
> On Behalf Of gaeap...@gmail.com
> Sent: Monday, August 20, 2018 5:33 AM
> To: open-amp <open...@googlegroups.com>
> Subject: Re: [open-amp] Help with OpenAMP setup
>

> amp+uns...@googlegroups.com.

[Wendy] This rproc_mem field. The reason is
* you have changed the remote application size, if you want to
Use this field, you will move the base of this field so that it will
Not overlap with the firmware memory of your application.
* Linux kernel upstream is not going to support this attribute.
It only exists in the current version of Xilinx kernel. Better not to
use it. unless you want to use predefined shared memory (defined at compilation time)

Best Regards,
Wendy

[gaeap...@gmail.com]

OK , so in rsc_table.h , in the struct remote_resource_table , I remove only field :

struct fw_rsc_rproc_mem rproc_mem;

Then , I have to change something else ?


So , to recap , the changes are :

1 ) openamp-overlay.dtsi ( to copy in system-user.dtsi ) :


rproc_0_reserved: rproc@3ed00000 {
no-map;
reg = < 0x3e000000 0x02C10000 >;

};


amba {
elf_ddr_0: ddr@0 {
compatible = "mmio-sram";

reg = <0x3e000000 0x02C10000>;
};


2) rcs_table.h :


#define NO_RESOURCE_ENTRIES 8

struct remote_resource_table {
unsigned int version;
unsigned int num;
unsigned int reserved[2];
unsigned int offset[NO_RESOURCE_ENTRIES];
/* rproc memory entry */

// struct fw_rsc_rproc_mem rproc_mem; // commented rproc_mem struct variable

/* rpmsg vdev entry */
struct fw_rsc_vdev rpmsg_vdev;
struct fw_rsc_vdev_vring rpmsg_vring0;
struct fw_rsc_vdev_vring rpmsg_vring1;
}__attribute__((packed, aligned(0x100000)));

Are there other changes to correspond firmware size in SDK with firmware memory nodes in Petalinux ?

That's enough ?

[Jiaying Liang]

> -----Original Message-----
> From: open...@googlegroups.com [mailto:open...@googlegroups.com]
> On Behalf Of gaeap...@gmail.com
> Sent: Monday, August 20, 2018 10:13 AM
> To: open-amp <open...@googlegroups.com>
> Subject: Re: [open-amp] Help with OpenAMP setup
>

[Wendy] you will also need to update the rsc_table.c file.
>
> That's enough ?
[Wendy] Try the above changes to see if you can load the firmware that is no loading
Firmware error reported from the remoteproc kernel driver first.

[gaeap...@gmail.com]

Hi Jiaying Liang ,


Ok ,

what do I need to update in rsc_table.c ?


Actually rsc_table.c :




/* This file populates resource table for BM remote
* for use by the Linux Master */

#include "openamp/open_amp.h"
#include "rsc_table.h"

/* Place resource table in special ELF section */

/* Redefine __section for section name with token */
#define __section_t(S) __attribute__((__section__(#S)))
#define __resource __section_t(.resource_table)

#define RPMSG_IPU_C0_FEATURES 1

/* VirtIO rpmsg device id */
#define VIRTIO_ID_RPMSG_ 7

/* Remote supports Name Service announcement */
#define VIRTIO_RPMSG_F_NS 0


/* Resource table entries */

#define NUM_VRINGS 0x02
#define VRING_ALIGN 0x1000
#define RING_TX 0x3e600000
#define RING_RX 0x3e604000
#define VRING_SIZE 256

#define NUM_TABLE_ENTRIES 2


struct remote_resource_table __resource resources = {
/* Version */
1,

/* NUmber of table entries */
NUM_TABLE_ENTRIES,
/* reserved fields */
{0, 0,},

/* Offsets of rsc entries */
{
offsetof(struct remote_resource_table, rproc_mem),
offsetof(struct remote_resource_table, rpmsg_vdev),
},

{RSC_RPROC_MEM, 0x3e600000, 0x3e600000, 0x100000, 0},

- nascondi testo citato -

/* Virtio device entry */
{
RSC_VDEV, VIRTIO_ID_RPMSG_, 0, RPMSG_IPU_C0_FEATURES, 0, 0,

0,
NUM_VRINGS, {0, 0},
},

/* Vring rsc entry - part of vdev rsc entry */
{RING_TX, VRING_ALIGN, VRING_SIZE, 1, 0},
{RING_RX, VRING_ALIGN, VRING_SIZE, 2, 0},
};

void *get_resource_table (int rsc_id, int *len)
{
(void) rsc_id;
*len = sizeof(resources);
return &resources;
}

[Jiaying Liang]

> -----Original Message-----
> From: open...@googlegroups.com [mailto:open...@googlegroups.com]
> On Behalf Of gaeap...@gmail.com
> Sent: Wednesday, August 22, 2018 8:31 AM
> To: open-amp <open...@googlegroups.com>
> Subject: Re: [open-amp] Help with OpenAMP setup
>

> > > > > > > OK , now if I have in lscript.ld
> > > > > > >
> > > > > > > base addr 0x3e000000
> > > > > > > size 0x02C100000
> > > > > > >
> > > > > > > How do I have to configure these nodes to correspond
> > > > > > > firmware
> > > memory ?
> > > > > > >
> > > > > > >
> > > > > > > rproc_0_reserved: rproc@3ed00000 {
> > > > > > > no-map;
> > > > > > > reg = < 0x3e000000 0x10000000 >;
> > > > > > [Wendy] reg = < 0x3e000000 0x02C100000 >;
> > > > > > >
> > > > > > >
> > > > > > > elf_ddr_0: ddr@0 {
> > > > > > > compatible = "mmio-sram";
> > > > > > > reg = <0x3e000000 0x400000>;
> > > > > > > };
> > > > > > [Wendy] reg = < 0x3e000000 0x02C100000 >;
> > > > > > >
> > > > > > > Do I change 0x400000 in elf_ddr or 0x10000000 in reserved rproc ?
> > > > > > > Do I have to change something in rcs_table.c in SDK ?
> > > > > > [Wendy] Remove the RPROC_MEM fields in the rsc_table
> > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > You received this message because you are subscribed to the
> > > > > > > Google Groups "open-amp" group.
> > > > > > > To unsubscribe from this group and stop receiving emails

> > > > > > > from it, send an email to open-
> amp+uns...@googlegroups.com.
> > > > > > > To post to this group, send an email to open-
> > > a...@googlegroups.com.
> > > > > > > For more options, visit https://groups.google.com/d/optout.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >

> > > > > To post to this group, send an email to open-
> a...@googlegroups.com.
> > > > > For more options, visit https://groups.google.com/d/optout.
> > >
> > >
> > >

[Wendy] remove this line first to see if you can at least load the application.
If you just remove the rproc_mem from the .h but keep this line, you will have
Compilation issue

Best Regards,
Wendy

>
> /* Virtio device entry */
> {
> RSC_VDEV, VIRTIO_ID_RPMSG_, 0, RPMSG_IPU_C0_FEATURES, 0, 0,
>
> 0,
> NUM_VRINGS, {0, 0},
> },
>
> /* Vring rsc entry - part of vdev rsc entry */
> {RING_TX, VRING_ALIGN, VRING_SIZE, 1, 0},
> {RING_RX, VRING_ALIGN, VRING_SIZE, 2, 0}, };
>
> void *get_resource_table (int rsc_id, int *len) {
> (void) rsc_id;
> *len = sizeof(resources);
> return &resources;
> }
>

[gaeap...@gmail.com]

Hi , Jiaying Liang

I change these nodes in openamp-overlay.dtsi :



rproc_0_reserved: rproc@3e000000 {
no-map;
reg = < 0x3e000000 0x02c10000 >;

elf_ddr_0: ddr@0 {
compatible = "mmio-sram";

reg = <0x3e000000 0x02c10000>;
};


I have deleted rproc_mem fileds in rsc_table.c:

// offsetof(struct remote_resource_table, rproc_mem),

// {RSC_RPROC_MEM, 0x3e600000, 0x3e640000, 0x100000, 0},



I have deleted rproc_mem fileds in rsc_table.h:

// struct fw_rsc_rproc_mem rproc_mem;


Now , loading UG1186 OpenAMP , there is this error :


remoteproc remoteproc0 : Failed to process resources: -22
remoteproc remoteproc0 : Boot failed: -22
-sh: echo: write error: Invalid argument

[Jiaying Liang]

> -----Original Message-----
> From: open...@googlegroups.com [mailto:open...@googlegroups.com]
> On Behalf Of gaeap...@gmail.com
> Sent: Tuesday, August 28, 2018 3:21 AM
> To: open-amp <open...@googlegroups.com>
> Subject: Re: [open-amp] Help with OpenAMP setup
>

[Wendy] You can turns out the DEBUG in drivers/remoteproc/remoteproc_core.c in the Linux kernel to get more output on and you can also add print to rproc_handle_resources() to figure out it failed on which resource.

Best Regards,
Wendy

[gaeap...@gmail.com]

Hi , Jiaying Liang

Do you have an example petalinux directory or documentation described to solve the changes of ddr in linker script and rsc_table and file dtsi ad other changes to large ddr0 in SDK ?

I'm blocked in error :

remoteproc remoteproc0 : Failed to process resources: -22 remoteproc
remoteproc0 : Boot failed: -22

Never Do you try to solve this problem with Petalinux 2017.4 ?

In all documentation UG1186 of Xilinx there is only this note :

"Firmware memory needs to correspond to the firmware's linker script"

, but there isn't example of changes ddr memory.

[Jiaying Liang]

Did u see other message above that one? As you remove one resource, did you also decrease the number of resources in the resource table?

Best Regards,

Wendy

[hello...@gmail.com]

I'm trying XAPP1079 with ZC706 Zynq.

The application on CPU1 is set for default in lscript.ld

with baseaddr 0x02000000 and size 0x01000000.

I'm using SOCKET API in bsp and LWIP function in the code.

There is a problem of overflow in region .bss of app_cpu1.elf

I changed linker script size from 0x01000000 to 0x03000000

so this problem in SDK there isn.t.

But in the run of app_cpu1 , lwip_init() and other function of SOCKET API don't run.

How can I solve this problem of ddr memory and use of LWIP ?

[sunnyl...@gmail.com]

On Friday, September 28, 2018 at 2:19:43 PM UTC-7, hello...@gmail.com wrote:
> I'm trying XAPP1079 with ZC706 Zynq.

Please use Xilinx support https://www.xilinx.com/support.html for the Xilinx example application questions/issues.

>
>
>
> The application on CPU1 is set for default in lscript.ld
>
> with baseaddr 0x02000000 and size 0x01000000.
>
>
>
> I'm using SOCKET API in bsp and LWIP function in the code.
>
> There is a problem of overflow in region .bss of app_cpu1.elf
>
>
>
> I changed linker script size from 0x01000000 to 0x03000000
>
> so this problem in SDK there isn.t.
>
>
>
> But in the run of app_cpu1 , lwip_init() and other function of SOCKET API don't run.

Not sure if your application make use of 0x01000000 address.
You can tried to keep baseaddress as 0x02000000 and just increase the size. But you will need to make sure the memory is not overlapped with other usage.

Best Regards,
Wendy

[vsan...@gmail.com]

Hi , Wendy

I'm using XAPP1079 Standalone - Standalone for a project with FreeRTOS - FreeRTOS on CPU0 and CPU1 with sys_thread_new and lwip.


When execute on CPU0 sys_thread_new , ok run.
If execute also on CPU1 another sys_thread_new , only sys_thread_new on <CPU0 run , never toghether.

I need to run on CPU0 and CPU1 independent sys_thread_new in parallel.

[vsan...@gmail.com]

I'm using XAPP1079 with two FreeRTOS Projects on both cpu.
I have to use LWIP and SOCKET_API , but there is the problem that cpu0 don't wake up with reset and start CPU1 when use LWIP_INIT() function and SYS_THREAD_NEW function in CPU0 , so run only CPU0 code.

How can I solve this problem ?

[sunnyl...@gmail.com]

As this example is provided by Xilinx, please use Xilinx support portal to the questions/issues related to this demo. https://www.xilinx.com/support.html#serviceportal

Best Regards,
Wendy