Understanding the flow between Cortex-A7 and Cortex-M4. Got some queries

I’m trying to understand the flow between FreeRTOS and linux.
Got following queries.

1] How much DDR memory is available between Cortext-A7 and cortext-M4. I tried with rpmsg_tty example i could able to send 216 charterers. If I send more it is taking in next cycle

2] My understanding is that 216 bytes of data can be transferred/received is it correct ?

3] How to run application from ocram.

4] If i want to increase buffer size from 512 → 1024 what all changes need to do in Linux side and freeRTOS side

Thanks for the support!!.

Dear @Yasir_NL

  1. I assume you are asking how much memory is reserved to be used for RpMsg communication?
    There’s 256 message buffers, 512 bytes each (= 128kB), and 4 VRING storage areas, 4kB each.
    So it sums up to 144kB.

  2. The 216 byte “limitation” is coming from the Linux ttyRPMSG driver. This driver converts a continous stream of data into packets. It is in the algorithm of the driver how it splits up the stream into packets. On the RpMsg level, packets have a fixed length (of 512 bytes, by default) which is fully usable for user data.

  3. The location where an M4 application runs, is defined at build time. The linker script describes, at which memory address (and thus in which memory type) code, variables etc. will be stored and executed. So you need to modify the linker script (or choose a different linker script) to change this.

  4. There’s a description on the developer page, where you can modify these parameters.

    Please be aware, that the settings on the A7 and M4 side must match, otherwise there will be no communication possible!

Regards, Andy

Thank you for replying.

As seen 2MiB of memory at the end of the first 256MiB in u-boot. u-boot-toradex.git - U-Boot bootloader for Apalis and Colibri modules

My question is if I want to increase memory size 2MiB to 5MiB then modification has to be done in u-boot ??

Dear @Yasir_NL

To reserve more DRAM for the M4, it is sufficient to modify the linux source colibri_imx7.c, as you found it alrady in the git commit:

However, you should make sure that the start of the carveout memory is aligned to a 2MB boundary. So you might want to reserve 6MB instead of 5MB.

Regards, Andy

Thank you for quick reply.

Please can tell how can i check the total available for M4 and what is the maximum range of memory we can allocate for M4 ?

How m4 will come to know about the memory which is allocated in u-boot ?

Thanks, Yasir

Dear @Yasir_NL

For your understanding: The change in the Linux source code does not really allocate DRAM to the M4, it only prevents the DRAM from being used as generic RAM by Linux.

The M4 can address a maximum of 255MB, as documented in our developer page article:

There’s no way for the M4 to query the amount of allocated DRAM. There’s no marker or anything to report the assignment of the DRAM.
What you need to do is to manually adjust the M4 linker script to define this DRAM to be used by the M4.

Regards, Andy

There’s 256 message buffers, 512 bytes each (= 128kB), and 4 VRING storage areas, 4kB each.So it sums up to 144kB.

I’m using linux kernel 4.14. In device tree I have seen 64Kb memory is reserved. But 512*256 = 128K. Where is remaining 64kb of memory will be allocated/reserved.?

&rpmsg{
        vdev-nums = <1>;
        reg = <0xbfff0000 0x10000>; //0x10000 -> 64kb
        status = "okay";
};

What is the use of VRING0_BASE/VRING1_BASE. Is it for send and receive ??

If i see memory diff of bfff000 - bff8000 it is 32kb. My understand is that 64kb of total memory will be allocated for VRING0_BASE/VRING1_BASE will it be divided between each 32kb?

If I change the memory location 0xbfff000 → 0x8fff000, 0xbff8000 → 0x8ff8000 in A7 and M4 side application is working fine. I didn’t understood the difference.? will 0x8fff0000 - 0x8ff80000 address allocate more memory ?

Thank you,

Dear @Yasir_NL

I explained the memory regions in your follow-up question

This should answer some of your questions. For the remaining ones:

  • Yes, the allocated 64kB are shared for VRING0 and VRING1, 32kB each.
  • I didn’t understand your last question. Changing the memory location should not have any impact in the first place, and this is what you observed, right?

Regards, Andy