I’m working with rpmsg of Colibri imx7s module. I had compiled RPMsg Ping-Pong FreeRTOS Demo project, and load the bin file to tcm(0x7f8000), run ‘dcache flush && bootaux 0x7f8000’, and then boot linux, run ‘modprobe imx_rpmsg_pingpong’, it works. But when I changed LINK_FILE to MCIMX7D_M4_ocram.ld in CMakeLists.txt, and then compiled the project, load the bin file to ocram(0x910000), and then run ‘dcache flush && bootaux 0x910000’, boot linux and run ‘modprobe imx_rpmsg_pingpong’, it doesn’t works. Do I need to edit device tree file?
Can any one help comment on this please, I have just changed to run M4 code out of OCRAM, using rpmsg under ‘IMX_RPMSG_TTY’ driver loaded using modprobe and M4 Initialisation the same as your tty demo.
This is working but from comments above it shouldn’t, could you guys possibly help here and give some clarity to my self and Bing ( ? ).
I am interested in case I have just got lucky and about to shoot myself in the foot later
Hope this can help everyone
Liam Dowling
PS using IM7D 512, M$ code siaze about 34KB.
The location of the Cortex-M4 firmware and where the RPmsg stores its VirtIO descriptors are orthogonal issues. If you change the location of the firmware only using the OCRAM linker file, this should work fine… (note that we did not test the OCRAM linker file, so it might be an issue. But in theory, it should just work…).
If you plan to change the location of the RPmsg’s VirtIO queue descriptor, make sure to change the addresses coherently in FreeRTOS, Linux and (if you use a recent version, which you should due to issue # 21136) in U-Boot’s board file (board/toradex/colibri_imx7/colibri_imx7.c, function ft_board_setup). However, note that Linux allocates the actual VirtIO queue in DDR, so changing the VirtIO queue descriptor does not change much in practice.
