I have some questions regarding the RAM layout of the "openPOWERLINK MN on Zynq Hybrid design" (Xilinx ZC702).
As far as my understanding goes, the use of the RAM is divided into 4 main regions.
The address editor in Vivado shows that 512 MiB of ram is mapped onto the PCP (0x2000_0000 - 0x3FFF_FFFF). This region is further divided into "Common Memory" (0x2C00_0000 - 0x2FFF_FFFF) and "Shared Memory" (0x3000_0000 - 0x3FFF_FFFF) as can be seen in openPOWERLINK_V2-master/hardware/boards/xilinx-z702/mn-dual-shmem-gpio/include/dualprocshm-mem.h.
Another look into openPOWERLINK_V2-master/hardware/boards/xilinx-z702/mn-dual-shmem-gpio/sdk/handoff/system.dts gives the following pieces of information:
where mem=524M corresponds to a range of 0x20C0_0000 (0x0000_0000 - 0x20BF_FFFF).
The memory node shows a range of 0x2FFF_FFFF (0x0000_0000 - 0x2FFF_FFFE) which corresponds to about 768 MiB.
My questions are:
Why are the mem parameter and the range of the memory node set this way?
What is the range starting from 0x2000_0000 and ending with 0x2BFF_FFFF used for? As it is neither used for common nor shared memory but is still visible to the PCP.
Why isn't the shared memory made visible to the kernel but the common memory?
Best regards
Steph
Last edit: Steph 2021-01-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello, we are also looking to optimize this design for a lower footprint deployment. Anyone has worked on it, or can point us to any material where we can find any reference ?
Regards,
Tomas
Last edit: Tomas Th 2021-02-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry for the delay in getting back. The Zynq hybrid design is based on the Zc702 which has a 1GB shared DDR3 between ARM Linux (PS) and Microblaze (PL). For the hybrid master design, this entire memory is divided into 3 sections, as it uses the dual-processor-shared-memory interface library for communication between the OPLK application (on Linux) and communication stack (PCP or Microblaze).
The 3 sections are :
- Memory visible to Linux (kernel),
- Common memory
- PCP application memory
The shared memory is later allocated dynamically by the PCP (in PCP memory) and made accessible to Linux.
Both common and shared memory are not accessible to kernel by default, rather both these are remapped into the kernel as Linux peripheral device registers, by the kernel driver.
PCP app can access the common memory and shared memory but not the Linux app memory.
Linux app and PCP exchange control information and data via common memory and shared memory, using the dual-processor-shared-memory interface library.
Apart from this, there is a chunk of memory reserved by the bootloader/system, due to which you see the bootargs memory limited to 524 MB i.e. kernel does not map the entire 0x0 to 2BFF_FFFF region as is. The memory node in the device tree is used by the bootloader/uboot to initialize the RAM segment.
Hope this helps you in getting some insight. If you are looking for optimizing this into a smaller memory footprint, please share some details about the platform (via message is also fine) so that we can help with specific suggestions.
Thank you for explaining. We are trying to port to a smaller Zynq variation : Z-7010 and it is for a slave instead of master. But we are starting on the ZC702 kit and working our way down from there. to make our work simpler. First, we are analysing how much of logic and memory we can optimize. We will move to the new board, after we get a smaller working design. Could you share your email to share the details ?
Regards,
Tomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have one follow-up question: Why isn't the entire RAM available on the ZC702 specified in the device tree i. e. 0x0 - 0x3FFF_FFFF? Would this make any difference?
I will DM you for more specific quesions :).
Best regards
Steph
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I have some questions regarding the RAM layout of the "openPOWERLINK MN on Zynq Hybrid design" (Xilinx ZC702).
As far as my understanding goes, the use of the RAM is divided into 4 main regions.
The address editor in Vivado shows that 512 MiB of ram is mapped onto the PCP (0x2000_0000 - 0x3FFF_FFFF). This region is further divided into "Common Memory" (0x2C00_0000 - 0x2FFF_FFFF) and "Shared Memory" (0x3000_0000 - 0x3FFF_FFFF) as can be seen in
openPOWERLINK_V2-master/hardware/boards/xilinx-z702/mn-dual-shmem-gpio/include/dualprocshm-mem.h
.Another look into
openPOWERLINK_V2-master/hardware/boards/xilinx-z702/mn-dual-shmem-gpio/sdk/handoff/system.dts
gives the following pieces of information:and
where mem=524M corresponds to a range of 0x20C0_0000 (0x0000_0000 - 0x20BF_FFFF).
The memory node shows a range of 0x2FFF_FFFF (0x0000_0000 - 0x2FFF_FFFE) which corresponds to about 768 MiB.
My questions are:
Best regards
Steph
Last edit: Steph 2021-01-25
Hello, we are also looking to optimize this design for a lower footprint deployment. Anyone has worked on it, or can point us to any material where we can find any reference ?
Regards,
Tomas
Last edit: Tomas Th 2021-02-02
Hi Steph, Tomas,
Sorry for the delay in getting back. The Zynq hybrid design is based on the Zc702 which has a 1GB shared DDR3 between ARM Linux (PS) and Microblaze (PL). For the hybrid master design, this entire memory is divided into 3 sections, as it uses the dual-processor-shared-memory interface library for communication between the OPLK application (on Linux) and communication stack (PCP or Microblaze).
The 3 sections are :
- Memory visible to Linux (kernel),
- Common memory
- PCP application memory
Linux app and PCP exchange control information and data via common memory and shared memory, using the dual-processor-shared-memory interface library.
Apart from this, there is a chunk of memory reserved by the bootloader/system, due to which you see the bootargs memory limited to 524 MB i.e. kernel does not map the entire 0x0 to 2BFF_FFFF region as is. The memory node in the device tree is used by the bootloader/uboot to initialize the RAM segment.
Hope this helps you in getting some insight. If you are looking for optimizing this into a smaller memory footprint, please share some details about the platform (via message is also fine) so that we can help with specific suggestions.
Best Regards,
#aeicoriiotteam
Hello AEICOR IIoT Team,
Thank you for explaining. We are trying to port to a smaller Zynq variation : Z-7010 and it is for a slave instead of master. But we are starting on the ZC702 kit and working our way down from there. to make our work simpler. First, we are analysing how much of logic and memory we can optimize. We will move to the new board, after we get a smaller working design. Could you share your email to share the details ?
Regards,
Tomas
Many thanks for your reply!
I have one follow-up question: Why isn't the entire RAM available on the ZC702 specified in the device tree i. e. 0x0 - 0x3FFF_FFFF? Would this make any difference?
I will DM you for more specific quesions :).
Best regards
Steph