Is it possible to increase the M4 Memory in the VF61?

Technical Support
, ,
1

Hi,

According to the Memory Areas for the M4 core in the VF61, presented in the page “FreeRTOS on the Cortex-M4 of a Colibri VF61 | Toradex Developer Center”, the maximum memory the M4 could have is 2048MB, mapped in the DDR memory.

In this same page, you wrote an observation of “less for M4”, in this amount of memory using DDR.

So… Here are my questions:

-Could I remap the memory used by the M4 to the DDR memory, and alloc to it an amount of 10MB of memory, for example?
(In this scenario, my “freertos-rpmsg.elf” file would be something in MBs of size)

-Could you provide me with an example of how would be the vf610.dtsi file for this kind of configuration?

Thanks,
Andre Curvello

2

It is possible to use DDR memory to run the Cortex-M4 firmware. You need to make sure to reserve (carve-out) main memory from Linux. The simplest way to do this is using the mem kernel argument (set it using setenv defargs mem=<memory_used_in_linux> in U-Boot). You need to alter/create a new FreeRTOS linker file (see ./platform/devices/VF6XX/linker/gcc/vf6xx_tcm.ld) which links to the freed memory area (e.g. 0x80000000 is the RAM base address, assuming you add mem=248M, this would mean that Linux uses 0x80000000-0x8F800000. 0x8F800000-0x8FFFFFFF is free for the Cortex-M4. Use the system bus/code bus address aliases as documented in the [FreeRTOS on the Cortex-M4 of a Colibri VF61][1] article). [1]: FreeRTOS on the Cortex-M4 of a Colibri VF61 | Toradex Developer Center

3

Hi Stefan,

Thanks for your return.

I have one more question, and it is about the vf610.dtsi file.

I would need to change the “reg-names” from the element cortexm4core, node CM4?

In the default configuration, they are “pc_ocram” and “ps_ocram”.
Should they be kept this way?

According to your explanation, I’ve wrote this sample code below. Is it ok for the device-tree setup?

   CM4: cortexm4 {
                compatible = "simple-bus";
                ranges = <0x1f000000 0x8F800000 0x80000
                          0x8F800000 0x8F800000 0x80000>;
                #address-cells = <1>;
                #size-cells = <1>;

                cortexm4core {
                        compatible = "fsl,vf610-m4";
                        reg = <0x1f000000 0x80000>,
                                <0x8F800000 0x80000>;
                        reg-names = "pc_ocram", "ps_ocram";
                        fsl,firmware = "freertos-rpmsg.elf";
                };
        };
4

This part is used for the rpmsg driver. The reg names are fixed, and only those two are currently understood by the driver (see drivers/remoteproc/vf610_cm4_rproc.c). The node is used by the remoteproc driver, do you plan to use remoteproc method to load the firmware?

I guess it should work if you just re-purpose the two entries for DDR. The first entry ( pc_ocram) is meant for code, the code bus has DDR memory mapped at 0x00800000-0x0fffffff, so I guess it should look like this:

                     reg = <0x0f800000 0x80000>,
                             <0x8f800000 0x80000>;
                     reg-names = "pc_ocram", "ps_ocram";

This assumes a linker file which links code to that area too… see also the memory map documented in the article FreeRTOS on the Cortex-M4 of a Colibri VF61.

5

Hi @stefan.tx,

Yes, I intend to use the rpmsg driver.

So I’ll test here, changing the related addresses for DDR space in the Device-Tree, vf610_cm4_rproc.c driver, and in the Linker File taking for example the “vf6xx_sysram-sram.ld” in the “freertos-toradex/platform/devices/VF6XX/linker/gcc” directory:

MEMORY
{
        /*
         * Note: 0x1f000000 is an alias for code bus to the same memory
         * located at 0x3f000000, hence start with the data section
         * at an offset of 256KiB. One can define this section lenghts
         * freely
         */
        pc_ram (rwx) : ORIGIN = 0x1f000000, LENGTH = 256K
        ps_ram (rwx) : ORIGIN = 0x3f040000, LENGTH = 256K
}
6

Note that the rpmsg and remoteproc drivers are related, but not the same:

  • remoteproc is about firmware loading
  • rpmsg is about communication

You can use rpmsg driver without making use of remoteproc (e.g. by loading the firmware in U-Boot…).

I assume the snipped you posted from the linker file is before you made the changes (since it is still using the OCRAM addresses 0x3f... and 0x1f...…

7

Hi @stefan.tx,

Yes, that snipped was taken before the changes, just to show the “proper” part of the linker I’d change.

Thanks about the explanation about remoteproc and rpmsg.