cancel
Showing results for 
Search instead for 
Did you mean: 

Increased (1024) RPMSG Buffer Size will fail on Mailbox vdev declaration

KChar.1
Senior

Hey there, I am trying to increase the RPMSG buffer size to 1024 on the STM32MP1 for the last couple of days. The A7 side seems to be working fine but the M4 side seems to struggle with the vdev declaration on the device tree.

On the A7 side: virtio_rmpsg_buss.c

#define MAX_RPMSG_NUM_BUFS	(1024)
#define MAX_RPMSG_BUF_SIZE	(1024)
#define RPMSG_RESERVED_ADDRESSES	(2048)
#define RPMSG_NS_ADDR			(53)

stm32mp15xx-dkx.dtsi:

vdev0buffer: vdev0buffer@10044000 {
 
compatible = "shared-dma-pool";
 
reg = <0x10044000 0x10000>;
 
no-map;
 
};

On the M4 side: rpmsg_virtio.h

* Configurable parameters */
#ifndef RPMSG_BUFFER_SIZE
#define RPMSG_BUFFER_SIZE	(1024)
#endif

The user-space can see and send messages to the RPMSG channel but when debugging the M4 part I get what to seems to be a memory allocation error

(gdb) 0x1000b47e in MAILBOX_Poll (vdev=0x10020f70) at ../OPENAMP/mbox_ipcc.c:105

Any ideas or advice will be highly appreciated.

1 ACCEPTED SOLUTION

Accepted Solutions
ArnaudP
Senior

Hello,

As a first analysis look like a M4 firmware mapping issue.

2 points:

1) Regarding https://wiki.st.com/stm32mpu/wiki/STM32MP15_RAM_mapping#Zoom_in_the_Cortex-A7-2FCortex-M4_shared_memory

you have extended the rpmsg buffer region in the MCUSRAM4

Except if you are sure to not use the MCUSRAM4 for MDMA transfers you have to limit the size of vdev0buffer or to change the base address of the memory regions described here to redefine them in SRAM2 + SRAM3.

2) Do you update the size of the m_ipc_shm memory region in the M4 linker script?

m_ipc_shm should be aligned with vdev0vring0 + vdev0vring1 + vdev0buffer (Linux DT memory region) base adress and size.

if you have this in your DT:

		vdev0vring0: vdev0vring0@10040000 {
			compatible = "shared-dma-pool";
			reg = <0x10040000 0x2000>;
			no-map;
		};
 
		vdev0vring1: vdev0vring1@10042000 {
			compatible = "shared-dma-pool";
			reg = <0x10042000 0x2000>;
			no-map;
		};
 
		vdev0buffer: vdev0buffer@10044000 {
			compatible = "shared-dma-pool";
			reg = <0x10044000 0x10000>;
			no-map;
		}

you should have in your M4 firmware linker script:

m_ipc_shm  (RW) : ORIGIN = 0x10040000, LENGTH = 0x00014000

View solution in original post

2 REPLIES 2
ArnaudP
Senior

Hello,

As a first analysis look like a M4 firmware mapping issue.

2 points:

1) Regarding https://wiki.st.com/stm32mpu/wiki/STM32MP15_RAM_mapping#Zoom_in_the_Cortex-A7-2FCortex-M4_shared_memory

you have extended the rpmsg buffer region in the MCUSRAM4

Except if you are sure to not use the MCUSRAM4 for MDMA transfers you have to limit the size of vdev0buffer or to change the base address of the memory regions described here to redefine them in SRAM2 + SRAM3.

2) Do you update the size of the m_ipc_shm memory region in the M4 linker script?

m_ipc_shm should be aligned with vdev0vring0 + vdev0vring1 + vdev0buffer (Linux DT memory region) base adress and size.

if you have this in your DT:

		vdev0vring0: vdev0vring0@10040000 {
			compatible = "shared-dma-pool";
			reg = <0x10040000 0x2000>;
			no-map;
		};
 
		vdev0vring1: vdev0vring1@10042000 {
			compatible = "shared-dma-pool";
			reg = <0x10042000 0x2000>;
			no-map;
		};
 
		vdev0buffer: vdev0buffer@10044000 {
			compatible = "shared-dma-pool";
			reg = <0x10044000 0x10000>;
			no-map;
		}

you should have in your M4 firmware linker script:

m_ipc_shm  (RW) : ORIGIN = 0x10040000, LENGTH = 0x00014000

KChar.1
Senior

Hi @ArnaudP​. Thanks a lot for that. Indeed, it makes more sense to redefine the memory in SRAM2 and SRAM3 since I am planning to use MDMA transfers later in development. The RAM mapping article is really useful for that.

Thanks again.