Decrease the size of the IPC buffer and put M4 cod... - STMicroelectronics Community

Hello community,

we have the problem, that we need more code space for the M4 application and try now to get code area in SRAM2 (IPC area).

What we've done so far:

Decreased the number of vring buffers to the half:
- #define VRING_NUM_BUFFS 8 /* number of rpmsg buffer */
Adapted the M4 linker file from 32K to 24K
- RAM2_ipc_shm (xrw) : ORIGIN = 0x10040000, LENGTH = 0x00006000 /* Length := 24K*/

For the linux DT part we were not sure what exactly to do:

First variant: vdev0 ring buffer to the half

vdev0vring0: vdev0vring0@10040000 {

compatible = "shared-dma-pool";

reg = <0x10040000 0x1000>;

no-map;

};

vdev0vring1: vdev0vring1@10042000 {

compatible = "shared-dma-pool";

reg = <0x10041000 0x1000>;

no-map;

};

vdev0buffer: vdev0buffer@10044000 {

compatible = "shared-dma-pool";

reg = <0x10042000 0x4000>;

no-map;

};

};

Second variant: vdev0 buffer itself to the half

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 0x2000>;

no-map;

};

};

So, now all works fine after testing (without linking code to the new 8K region) but we are not sure, how to test this change?

Why do both variants work or not harm the startup nor the application running. One of them should be wrong?

Furthermore, how to find out how much more we can decrease this area and find out how much space really is used for the vring buffers and for what exact the .vdev is used in the ressource table?

Maybe, there is also a way to take some of the DMA buffers (SRAM4) from Linux and use this for M4 code as well?

Here is also the question, how to find out what area is used and what space is free (what space has to be mandatory there to have the IPC work correctly)?

So many questions but maybe we can clarify step by step.

Best regards,

Jan-Otto

6 REPLIES 6

Hello community,

actually, we still need here some help. Our problem is, that the ST Wiki describes only, how to completely remove areas to have them free for code but there is no explicit example how to reduce areas used by Linux in a correct way.

Looking forward for you answers.

Best regards,

Jan-Otto

Hi @JMein.1,

First and to avoid any confusion the IPC region is in SRAM3 @0x10040000.

SRAM2 is typo right ?

I understand your M4 firmware exceed 320kB size( Retram + SRAM1 + SRAM2)

So you want to gain 8kB in the SRAM3 reducing IPC buffer footprint.

So far you gain the last 8kB and you plan to manage to link some code or data in it.

Free the first 8kB can be an alternative also which simplify link operation.

Anyway you modification looks correct but you need also to reserve the memory to M4 code in reserved-memory node and m4-rproc

See :

Linux remoteproc framework overview - stm32mpu

>>Furthermore, how to find out how much more we can decrease this area and find out how much >>space really is used for the vring buffers and for what exact the .vdev is used in the ressource table?

I cannot answer as such. Will dig further. But probably probably depends of your need of communication between A7 and M4 at runtime?

Do you use OpenAMP and which data rate do you expect ?

Olivier

Olivier GALLIEN
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

Hello Olivier,

sorry, I thought I removed the typo. I mean SRAM3 @0x10040000.

Yes, we actually use now 360 KBytes and want to find out, how much IPC RAM we can take from the A7/M4 buffers without damaging the communication channels we use togehter with OpenAMP.

Freeing the first 8kB will of course also be an option.

Is there also a way to take some SRAM4 space (from the A7 DMAs)? Or is there no access from M4 possible? Here is also the same question how to check, if everything is then sill working fine.

Thanks a lot for your support.

Best regards,

Jan-Otto

Hi @JMein.1

SRAMx usage and potential modification is well explain in wiki page https://wiki.st.com/stm32mpu/wiki/STM32MP15_RAM_mapping

MCU SRAM4 (DMA) can be used for other purpose if DMA1 and/or DMA2 is not used in chained mode (using MDMA)

moreover

STM32MP15 MCU SRAM internal memory - stm32mpu

SRAM4 is sharable as SRAM3

-> If no usage of MDMA, I think you can then shift IPC buffers in SRAM4 in order to benefit of a single 384KB block of memory for the M4 firmware

In DT you can then expand the region mcuram and alias mcuram2 to include whole SRAM3

I don't see specific test beyond normal functional validation of your application after the change.

Olivier

Olivier GALLIEN
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

Hello Olivier,

ok, we are using Linux with DMA but I am not sure, if we are using the "chained" mode in combination with MDMA. CubeMX looks like this.

So in the article of the WIKI if find only the DMA buffers to be removed:

&sram {

dma_pool: dma_pool@0 {

reg = <0x50000 0x10000>;

pool;

};

But can I also reduce this area by the half e.g. in the device tree and then use a part of it for M4 code? Will Linux still work correctly when I reserve the area for the M4?

Best regards,

Jan-Otto

Hello Olivier,

we now managed to decrease the DMA buffers and to link M4 code in that area.

Still one question is open regarding the vdev OpenAMP buffers.

Did you get in the meantime some more information that might help us?

Best regards,

Jan-Otto

>>Furthermore, how to find out how much more we can decrease this area and find out how much >>space really is used for the vring buffers and for what exact the .vdev is used in the ressource table?

>>I cannot answer as such. Will dig further. But probably probably depends of your need of >>communication between A7 and M4 at runtime?

>>Do you use OpenAMP and which data rate do you expect ?