Hello,
we use shared memory to exchange data between the Cortex-A and Cortex-M cores. For that, the Cortex-M (running a bare-metal program) accesses the address 0x80000000 directly, whereas the Linux application (running on the Cortex-A) uses mmap to map 0x80000000 into its virtual address space. The Cortex-M program is started by the Linux application via remoteproc.
This worked fine with the previous release (Y2023.09), but not with the current release anymore. As long as the program on the Cortex-M is running, the access to the shared memory is apparently denied for the Cortex-A. Any write attempt has no effect, and all reads return just the value 0. Interestingly, after the Cortex-M program gets stopped (again via remoteproc), the access to the memory becomes possible again. Thus, with pseusocode, the situation looks like this for the Cortex-A:
write 42 into 0x80000000
read 0x80000000 -> 42
start Cortex-M
read 0x80000000 -> 0
write 123 into 0x80000000
read 0x80000000 -> 0
stop Cortex-M
read 0x80000000 -> 42
As a side note - in the given example the Cortex-M program correctly reads "42" from the address 0x80000000, which proves that the Cortex-A wrote to the correct address, and that this worked until the Cortex-M was started.
In the devicetree, I enabled the Cortex-M with "#define SUPPORT_M7". In addition to that, I had to adjust the dtsi file in the previous release, to reserve the memory region for the M7 ("m4_reserved..."). This adjustment became part of the current Y2024.07 release, so there is no change in the dtsi file anymore.
The M7 toolchain has been updated to the current freertos-fsimx8mp-V2024.09 release. Shared memory still works when the Cortex-A runs with the Y2023.09 Yocto release, but not with Y2024.07.
I tried several things (e.g. mmap before/after the Cortex-M has started), but all failed. Now I'm running out of ideas. Can you help?
