More RAM for M4

This is a follow-up to this question. I need more RAM for my M4 firmware (like 32MB). Now i tried to understand how to change the memory layout and encountered some problems:

  1. According to the answer 2MiB are reserved for the M4 in colibri_imx7.c. I am a little confused because the comment at line 515 states that 1MB is used. Maybe this is a typo?
  2. The linker file MCIMX7D_M4_ddr.ld specifies the memory areas in the middle of those specified at here. What could be the reason for that?
  3. Where is the heap size defined? In MCIMX7D_M4_ddr.ld the HEAP_SIZE is set to 0x400 which is 1024 but i do not know if this means bytes or words.
  4. What steps have to be done to increase the available M4 data memory section? Maybe you could give an example?
  5. Related to question 1. When i want to increase the M4 RAM from 1MB to 32MB, would it be sufficient to change “SZ_256M - SZ_2M” into “SZ_256M - SZ_32M - SZ_1M” in colibri_imx7.c?
  6. I noticed that some of the FreeeRTOS demo applications define configCPU_CLOCK_HZ as 240000000ul but the M4 is specified to run at 200MHz? How could this work out?

Thanks in advance.

I don’t want to push and prod but i really need some help on that. Do you need some additional information about my question? I need to know how to configure the linker file so that the M4 can use more than 1MB RAM and of course i need to configure Linux (via u-boot) which RAM section is reserved for the M4 so that the M4 can safely use this section.

The linker file for DDR specifies the data section from 0x8ff80000 to 0x8fff0000 which makes sense because the rpsmg message buffer rings start at 0x8fff0000 and 0x8fff8000. Again i cannot find the counter part which prevents Linux from using this area for OS operation. And another question arised as the documentation states that each message ring consists of 256 buffers with 512 bytes… this would require a range of 0x20000 (128k) RAM addresses, so would this mean both buffers overlap (0x8fff0000 → 0x8fff8000 = 32k addresses << 128k)?

And one more question: In colibri_imx7.c 2MB of RAM is carved out which means 0x8FDF_FFFF - 0x8FFF_FFFF. This region would include the rpmsg buffers and the M4 code. Is this the purpose of this 2MB space? Will the kernel be able to access the rpmsg counterpart within this region?

Dear @qojote

  1. The comment is wrong. it should read
    /* Reserve last 2MiB for M4 on modules with 256MiB RAM */
  2. The idea was to keep the memory reserved by the bootloader at a constant phyical address. We have chosen the location to be towards the end of a 256MB range, because there are modules featuring only 256MB of RAM.
  3. All sizes are given in bytes, so 0x400 reserves 1024 bytes for the .heap section.
    Make sure that you choose an appropriate algorithm for the heap management. I recommend to read the documentation about FreeRTOS - Memory management.
  4. It should be sufficient to increase the size reserved in the bootloader. The following git commit shows the two locations which need adjustment:
  5. See answer (4.) above
  6. The M4 core actually runs at 240MHz (by default), so the #define configCPU_CLOCK_HZ (240000000ul) is correct.

Best Regards


  1. Ok.
  2. So the u-boot carves out some RAM from the fdt dynamically at a constant address. Could this be done in the dtb file directly?
  3. How does this heap section correlate to the FreeRTOS heap? The documentation says that i can easily increase configTOTAL_HEAP_SIZE which is ((size_t)(20 * 1024)) in the examples. This value seems to exceed the 0x400 bytes specified in the linker file. I am using heap_4.c for heap management.
  4. Understood. I want to carve out 32MB instead of 1MB → 0x8DFF_FFFF - 0x8FFF_FFFF. This should not interfer with u-boot? What do you exactly mean by heap region?

Thanks in advance

Dear @qojote

  1. (done)
  2. U-boot loads the device tree and then dynamically adjust the memory based on whether the M4 is started or not.
    Any modification of the carved-out memory in the dtb file would be overwritten by this algorithm, unless you disable the dynamic adjustment feature in u-boot.
  3. There are two independent heaps:
  • The heap defined in the linker file ( HEAP_SIZE = DEFINED(__heap_size__) ? __heap_size__ : 0x0400;) is used by the C standard library malloc function, which is usually not used in FreeRTOS. I assume you can reduce this size to 0. The __heap_size__ itself is defined in the file CMakeLists.txt.
  • The heap_4.c implementation uses a regular variable ucHeap to implement the stack, its size is defined by configTOTAL_HEAP_SIZE. Please look at the source code of heap_4.c for more details.
  1. With heap region I referred to the .heap : section in MCIMX7D_M4.ld.
    Adjusting the two patches to 32MB (colibri_imx7: carve out PMD aligned amount of memory) to build u-boot is sufficient to avoid any inference.

Regards, Andy