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
