Zynq7 rpmsg-echo does not work with Petalinux 2024.1

[jdolanTW]

While testing rpmsg-echo on a Zynq7 based design the rpmsg-echo test fails an assert.

assertion "physaddr == (void *)pa" failed: file "/build/plnx-dtc/components/yocto/workspace/sources/openamp-fw-echo-testd/openamp-fw-echo-testd/openamp_echo_test_bsp/ps7_cortexa9_1/libsrc/libmetal_v2_7/src/libmetal/lib/system/generic/xlnx/sys.c", line 137, function: metal_machine_io_mem_map

I was able to get it to work by changing platform_info.c

- static metal_phys_addr_t scugic_phys_addr = SCUGIC_DIST_BASE;
+static metal_phys_addr_t scugic_phys_addr = SCUGIC_PERIPH_BASE;

With this change the echo_test will now run successfully, but the change was mostly a guess. Is this a bug in the platform_info.c or is something else configured incorrectly by Petalinux?

-- Jay

[github-actions]

This issue has been marked as a stale issue because it has been open (more than) 45 days with no activity.

[arnopo]

@tnmysh Any advice on this issue?

[tnmysh]

Actually issue is in Xlnx BSP file and following is correct fix:

diff --git a/lib/bsp/standalone/src/arm/cortexa9/xil_mmu.c b/lib/bsp/standalone/src/arm/cortexa9/xil_mmu.c
index 9e15c6aff4..14944794ba 100644
--- a/lib/bsp/standalone/src/arm/cortexa9/xil_mmu.c
+++ b/lib/bsp/standalone/src/arm/cortexa9/xil_mmu.c
@@ -192,7 +192,7 @@ void* Xil_MemMap(UINTPTR PhysAddr, size_t size, u32 flags)
        return (void*)PhysAddr;
 
    /* Ensure alignment on a section boundary */
-   PhysAddr &= ARM_AR_MEM_TTB_SECT_SIZE_MASK;
+   Ttbaddr = PhysAddr & ARM_AR_MEM_TTB_SECT_SIZE_MASK;
 
    /* Loop through entire region of memory (one MMU section at a time).
       Each section requires a TTB entry. */
**
 

Above mentioned fix in issue description is partially correct. Actual fix should be in xlnx BSP.

However, as OpenAMP support for Zynq7000 platform will be deprecated, and new fixes won't be issued in BSP.

@rajimoha please confirm above fix.

[rajimoha]

@tnmysh thats correct this change should resolve the issue

[github-actions]

This issue has been marked as a stale issue because it has been open (more than) 45 days with no activity.