Hi BeagleBoard Community,
I am working with a BeagleY-AI board (which is based on the TI AM67A / J722S SoC). We are trying to establish an RPMsg IPC communication between Linux (running on the A53 core) and Zephyr RTOS. Since this community has extensive experience with the BeagleY-AI architecture and open-source RTOS integrations, I am hoping to find some guidance here. Important Context: Previously, our Zephyr application was running perfectly on the MAIN-R5F core, and RPMsg communication with Linux was fully functional. However, we recently activated the TI Edge AI SDK to run object detection models on the C7x. The Edge AI stack automatically loads its own vision apps firmware (vx_app_rtos_linux_mcu2_0.out) onto the MAIN-R5F core. Because MAIN-R5F is now occupied by the AI SDK, we had to migrate our Zephyr application to the MCU-R5F core. Ever since we moved the exact same Zephyr codebase to the MCU-R5F core, the RPMsg IPC consistently hangs during initialization. The specific symptom: Zephyr boots successfully on the MCU-R5F, GPIO and mailboxes work. It receives the first mailbox message from Linux (console outputs: platform_ipm_callback: msg received from mb 1), but then it gets stuck inside rproc_virtio_wait_remote_ready() while polling the vdev status. It never proceeds to print “Linux sample client responder started” or announce the channel. On the Linux side (A53), dmesg shows: remoteproc remoteproc2: powering up 79000000.r5f remoteproc remoteproc2: Booting fw image j722s-mcu-r5f0_0-fw, size 1115412 virtio_rpmsg_bus virtio2: rpmsg host is online Linux clearly writes DRIVER_OK (0x7) and prints that the host is online, but the “creating channel” message never appears for virtio2 (unlike when we were using MAIN-R5). What we have verified & tested so far: 1. Resource Table Status from Linux: We verified the .resource_table region from Linux via sysfs. Running “sudo od -A x -t x1 /sys/kernel/debug/remoteproc/remoteproc2/resource_table” correctly outputs “Status 0x7” (DRIVER_OK) at the 0xa1100000 offset, with Vring0 at 0xa1000000 and Vring1 at 0xa1001000. Linux is doing its job perfectly. 2. MPU Cache Coherency Hypothesis: We suspected that the MCU-R5F’s MPU was treating the IPC memory (ddr0 and rsc_table) as cacheable, preventing Zephyr from seeing the updated DRIVER_OK status written by Linux. In Zephyr’s soc/ti/k3/common/cortex_r/arm_mpu_regions.c, we modified the MPU configuration for the IPC_SHM chosen node to span 2MB (to cover both 0xa1000000 vrings and 0xa1100000 rsc_table) and set it as strongly-ordered / non-cacheable: MPU_REGION_ENTRY(“IPC_SHM”, DT_REG_ADDR(DT_CHOSEN(zephyr_ipc_shm)), REGION_2M, {MPU_RASR_S_Msk | NOT_EXEC | PERM_Msk}), Result: The fix compiled correctly and covered the sections, but the symptom did not change at all. Zephyr still hangs at the exact same callback. When we logged the status read by Zephyr inside wait_remote_ready, it reads 0x01 (ACKNOWLEDGE) once and then completely hangs (no further logs, no spinning, just silence). My Questions for the Community: - Is there a known issue or a specific MPU/cache initialization requirement for the MCU-R5F core on the BeagleY-AI when running Zephyr / OpenAMP that differs from the MAIN-R5F core? - Could this be related to a strict alignment fault caused by the strongly-ordered MPU attribute when reading the resource table, or is there a missing clock/power domain specific to the MCU domain IPC? - Since our code works flawlessly on MAIN-R5F, what is the recommended debugging step to figure out why the MCU-R5F fails to see the Linux status byte updates, or why it hard-hangs after the first mailbox interrupt? Any guidance or pointers regarding the MCU-R5F domain integration for the BeagleY-AI would be highly appreciated. Thanks in advance!
