Colibri iMX8X Torizon OS 7.3.0 - M4 memory issues

Hi All,
For Colibri iMX8X Torizon OS 7.3.0+build.18, we want to allocate some memory (in MB) for M4 Core
like it was done in Torizon OS 5.7.2+build.20 in device tree file imx8x-colibri.dtsi like below.
But in device tree created from toradex_6.6-2.2.x-imx for Torizon OS 7.3.0+build.18, does not have this section for M4
and after adding the below changes in device tree of Torizon OS 7.3.0+build.18, M4 stops after Linux is up

imx8x-colibri.dtsi →

  reserved-memory {
    #address-cells = <2>;
    #size-cells = <2>;
    ranges;

    /\*
     \* 0x8800_0000 \~ 0x8FFF_FFFF is reserved for M4
     \* Shouldn't be used at A core and Linux side.
     \*
     \*/
    m4_reserved: m4@0x88000000 {
      no-map;
      reg = <0 0x88000000 0 0x8000000>;
    };

    ...
  }

Thanks and regards,

Deepak.

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.


Memory Allocation for Cortex-M4 on Colibri iMX8X with Torizon OS 7.3.0

Understanding Reserved Memory Configuration

The /reserved-memory node you’re referencing is used to exclude specific memory regions from normal Linux usage, typically for dedicated hardware components like the Cortex-M4 core (1).

According to the Device Tree documentation, reserved memory regions are specified as nodes under the /reserved-memory node, and the operating system excludes this reserved memory from normal usage (1). Here’s the structure from the documentation:

reserved-memory {
    #address-cells = <2>;
    #size-cells = <2>;
    ranges;

    decoder_boot: decoder_boot@84000000 {
        no-map;
        reg = <0 0x84000000 0 0x2000000>;
    };
    ...
};

(1)

Device Tree Changes Between Versions

The differences you’re observing between Torizon OS 5.7.2 and 7.3.0 reflect changes in the underlying BSP and kernel versions. When working with different Torizon versions, the device tree branch corresponds to the Linux kernel branch name (2).

Recommended Approach

1. Verify Cortex-M4 Support

The Colibri iMX8X features heterogeneous multicore architecture that allows offloading critical real-time tasks to the Cortex-M4 processor (3). Toradex provides tooling and FreeRTOS to simplify development with this asymmetric multicore architecture (3).

2. Device Tree Customization Process

For device tree modifications, you should:

  • Choose the appropriate base device tree that matches your hardware platform (4)
  • Identify the specific hardware configurations your setup requires (4)
  • Follow the device tree customization workflow for compilation and deployment (4)

3. Memory Region Configuration

When regions within /reserved-memory need to be referenced by other device nodes, you can add a memory-region property to the relevant device node (1):

&vpu_core0 {
    memory-region = <&decoder_boot>, <&decoder_rpc>;
    reg = <0x2d080000 0x10000>;
    status = "okay";
};

(1)

Next Steps

Since the M4 core stops after Linux boot with your current configuration, I recommend:

  1. Check the current BSP documentation for Torizon OS 7.3.0 to understand the proper M4 memory allocation method
  2. Verify M4 firmware compatibility with the memory regions you’re trying to allocate
  3. Review the device tree binding documentation specific to your kernel version for the correct M4 configuration approach (4)

The device tree customization process involves selecting the base device tree, making modifications, compiling, and deploying the changes (4). Make sure your custom device tree reflects the specific hardware description and changes needed for your M4 memory allocation.

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

Hi @Deepak1,

Could you please send the output of tdx-info? It will help me understand the exact version of hardware and software you have.
Also, I need to know which SDK version and GCC toolchain you used. With that, I can try to reproduce this.

Hi @rudhi.tx ,

Please find the details below.

sudo tdx-info
Password:

**Software summary**

Bootloader:               U-Boot
Kernel version:         6.6.94-7.3.0-g5a62539de8f9 #1-Torizon SMP PREEMPT Wed Jun 25 09:14:55 UTC 2025
Kernel command line:      root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/a8ef035096168d87b1c075391a002d5e057454406405046201045768107954c8/0
Distro name:              NAME=“Torizon OS”
Distro version:           VERSION_ID=7.3.0-build.18
Distro variant:           VARIANT=“Docker”
Hostname:                 colibri-imx8x-07334613

Hardware info

HW model:                 Toradex Colibri iMX8QXP/DX on LVDS Embedded World Demo
Toradex version:          0050 V1.0D
Serial number:            07334613
Processor arch:           aarch64
**GCC Tool Chain:**
Linux version 6.6.94-7.3.0-g5a62539de8f9 (oe-user@oe-host) (aarch64-tdx-linux-gcc (GCC) 13.3.0, GNU ld (GNU Binutils) 2.42.0.20240723) #1-Torizon SMP PREEMPT Wed Jun 25 09:14:55 UTC 2025
**SDK Info:**
torizon-core-7.3.0+build.18

Regards,

Deepak.

Hi @rudhi.tx ,

I have updated the details for GCC Tool Chain and SDK Info used for building M4 and posting it again.

sudo tdx-info
Password:

Software summary

Bootloader: U-Boot
Kernel version: 6.6.94-7.3.0-g5a62539de8f9 #1-Torizon SMP PREEMPT Wed Jun 25 09:14:55 UTC 2025
Kernel command line: root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/a8ef035096168d87b1c075391a002d5e057454406405046201045768107954c8/0
Distro name: NAME=“Torizon OS”
Distro version: VERSION_ID=7.3.0-build.18
Distro variant: VARIANT=“Docker”
Hostname: colibri-imx8x-07334613

Hardware info

HW model: Toradex Colibri iMX8QXP/DX on LVDS Embedded World Demo
Toradex version: 0050 V1.0D
Serial number: 07334613
Processor arch: aarch64

GCC Tool Chain For Building M4:
Toolchain/IDE = ARM GCC / MCUXpresso for VS Code

SDK Info used for buiding M4:
We have build M4 from NXP SDK builder with following inputs:
Board(s):
MEK-MIMX8QX
Processor:
MIMX8QX6
Core Type / Max Freq:
Cortex-M4F / 264 MHz
SDK Version:
2.9.0 (released 2021-01-15)

Regards,

Deepak.

Hi @Deepak1,

I’m building the SDK and testing the hello world application. Will update you soon with my results. Thanks for your patience.

In the meantime, I helped a customer some time ago to work on RPMsg demo for Colibri iMX8X on Torizon OS 7.3.0. There are some patches and changes you need to apply for that. It is described here: /dev/ttyRPMSG30 not created in Torizon OS 7 on Colibri iMX8QXP - #30 by rudhi.tx

If you could try the same thing out for hello-world demo and test it, that would be nice. The SDK I used was SDK_2_9_0_MIMX8QX5xxxFZ and toolchain 14.3.

Hi @rudhi.tx
I have compiled the hello world program from the SDK_2_9_0_MIMX8QX5xxxFZ and toolchain 14.3. i tried with both build_debug and build_ddr_debug batch files and when both linux and M4 is booting at a time it will be rebooting continuously. And i observed that when booting only Linux or only M4 it is working fine.

Regards,

Deepak

Hi @Deepak1

You are right, I could reproduce the behavior that you are reporting. After checking with our R&D, I realized that this is a known issue, which can be solved by the attached device tree overlay. Could you please give it a try (you will have to compile and apply it) and let me know how it goes?
colibri-imx8x_hmp_overlay.dts (1.8 KB)

By the way, I tested the above overlay file on Torizon OS 7.4.0 and I can confirm that it works. It should work on 7.3.0 as well.

Hi @rudhi.tx

We have compiled and tested the hmp overlay you have send and now with build debug script both linux and M4 is working, and with ddr_debug again it have rebooting issue. The memory segment of ddr_debug what we have tried is as follows,

m_interrupts          (RX)  : ORIGIN = DEFINED(__STARTUP_CONFIG_DDR_ALIAS)?0x08000000:0x88000000, LENGTH = 0x00000A00
m_text                (RX)  : ORIGIN = DEFINED(__STARTUP_CONFIG_DDR_ALIAS)?0x08000A00:0x88000A00, LENGTH = 0x001FF600
m_data                (RW)  : ORIGIN = 0x88200000, LENGTH = 0x00200000
m_data2               (RW)  : ORIGIN = 0x88400000, LENGTH = 0x07C00000
m_tcml                (RW)  : ORIGIN = 0x1FFE0020, LENGTH = 0x0001FFE0
m_tcmu                (RW)  : ORIGIN = 0x20000000, LENGTH = 0x00020000
and in cmake __STARTUP_CONFIG_DDR_ALIAS=1 , 

Can you please guide us to boot M4 code from DDR RAM.

Regards,
Deepak.

Hello @Deepak1,

I have not tried out loading the firmware from the DDR RAM myself, but I can give you some pointers on how to do that.

From the file boards/mekmimx8qx/demo_apps/hello_world/armgcc/MIMX8QX6xxxxx_cm4_ddr_ram.ld in the SDK directory, you will find the memory addresses for the DDR RAM that you will need to add into the reserved-memory section in the device-tree overlay file. So you will have to add a memory for section m_data and m_data2 into the reserved-memory (either as two separate nodes or one node with the added lengths).

m_data                (RW)  : ORIGIN = 0x88200000, LENGTH = 0x00200000
m_data2               (RW)  : ORIGIN = 0x88400000, LENGTH = 0x07C00000

After that, you can compile and apply the device tree overlay. Then, build the firmware with the script build_ddr_debug.sh or build_ddr_release.sh in the armgcc directory.

You will have to change the load address for the firmware to this new starting address of the DDR RAM and also change the size of the memory to the size of the firmware binary. Here is an example for how to do this: Run simply Hello world" M4 application in DDR - #5 by bruno.tx

Let me know if this helps.

Hi @rudhi.tx ,

My M4 linker script is as follows,

m_interrupts          (RX)  : ORIGIN = 0x88000000, LENGTH = 0x00000A00
m_text                (RX)  : ORIGIN = 0x88000A00, LENGTH = 0x001FF600
m_data                (RW)  : ORIGIN = 0x88200000, LENGTH = 0x00200000
m_data2               (RW)  : ORIGIN = 0x88400000, LENGTH = 0x00100000

For reserving M4 memory we have included a m4_reserved node in HMP overlay,am attaching the colibri-imx8x_hmp_overlay.dts for reference.

colibri-imx8x_hmp_overlay.dts (1.7 KB)

We have set the below Uboot env variables.

load_cmd=ext4load mmc 0:1
loadaddr=0x88000000
m4_0_image=/ostree/deploy/torizon/var/hello_world.bin
m4boot_0=run loadm4image_0; dcache flush; bootaux ${loadaddr} 0
bootcmd=run m4boot_0; run bootcmd_mmc0;

With above changes and settings platform is restarting.

Below is the log,

flash target is MMC:0
Net:   eth0: ethernet@5b040000
Fastboot: Normal
Normal Boot
Hit any key to stop autoboot:  0
14972 bytes read in 6 ms (2.4 MiB/s)
Power on aux core 0
Copy image from 0x88000000 to 0x34fe0000
Start M4
bootaux complete
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1…
Found U-Boot script /boot.scr
969 bytes read in 3 ms (315.4 KiB/s)

Executing script at 9d480000

7747 bytes read in 5 ms (1.5 MiB/s)
120891 bytes read in 8 ms (14.4 MiB/s)
165 bytes read in 5 ms (32.2 KiB/s)
Working FDT set to 9d400000
Applying Overlay: colibri-imx8_goodix-gt928-ts_overlay.dtbo
398 bytes read in 6 ms (64.5 KiB/s)
Applying Overlay: colibri-imx8x_disable-cm40-uart_overlay.dtbo
412 bytes read in 6 ms (66.4 KiB/s)
Applying Overlay: colibri-imx8x_spidev_overlay.dtbo
585 bytes read in 6 ms (94.7 KiB/s)
Applying Overlay: colibri-imx8x_hmp_overlay.dtbo
2793 bytes read in 6 ms (454.1 KiB/s)
11497894 bytes read in 265 ms (41.4 MiB/s)
13895554 bytes read in 320 ms (41.4 MiB/s)
Bad Linux ARM64 Image magic!
SCRIPT FAILED: continuing…
Colibri iMX8X #

Regards,
Deepak.

Hello @Deepak1,

Since you have different addresses in the linker file: which version of SDK are you using? This is how it looks like for me (I have SDK_2_9_0_MIMX8QX5xxxFZ):

MEMORY
{
  m_interrupts          (RX)  : ORIGIN = DEFINED(__STARTUP_CONFIG_DDR_ALIAS)?0x08000000:0x88000000, LENGTH = 0x00000A00
  m_text                (RX)  : ORIGIN = DEFINED(__STARTUP_CONFIG_DDR_ALIAS)?0x08000A00:0x88000A00, LENGTH = 0x001FF600
  m_data                (RW)  : ORIGIN = 0x88200000, LENGTH = 0x00200000
  m_data2               (RW)  : ORIGIN = 0x88400000, LENGTH = 0x07C00000
  m_tcml                (RW)  : ORIGIN = 0x1FFE0020, LENGTH = 0x0001FFE0
  m_tcmu                (RW)  : ORIGIN = 0x20000000, LENGTH = 0x00020000
}

This is how I would add the memory regions in my device tree overlay:

reserved-memory {
		#address-cells = <2>;
		#size-cells = <2>;
		ranges;
  
       m4_reserved: m4@88200000 {
			//compatible = "shared-dma-pool";
			no-map;
			reg = <0 0x88200000 0 0x7E00000>;
		};

		vdev0vring0: vdev0vring0@90000000 {
			reg = <0 0x90000000 0 0x8000>;
			no-map;
		};

		vdev0vring1: vdev0vring1@90008000 {
			reg = <0 0x90008000 0 0x8000>;
			no-map;
		};

		vdev1vring0: vdev1vring0@90010000 {
			reg = <0 0x90010000 0 0x8000>;
			no-map;
		};

		vdev1vring1: vdev1vring1@90018000 {
			reg = <0 0x90018000 0 0x8000>;
			no-map;
		};

		vdevbuffer: vdevbuffer@90400000 {
                        compatible = "shared-dma-pool";
			reg = <0 0x90400000 0 0x100000>;
			no-map;
		};

		rsctable: rsctable@900ff000 {
			reg = <0 0x900ff000 0 0x1000>;
			no-map;
		};
	};

I think you are starting with a wrong address for the new reserved section you added - ie, 0x88000000. According to the addresses in your linker script, it should be 0x88200000. Also, that should be the loadaddr address in the uboot as well.

Hi @rudhi.tx

We have used the same SDK_2_9_0_MIMX8QX5xxxFZ,modified the device tree and changed the loadaddr as mentioned but still it is continuously rebooting.

Regards,
Deepak.

colibri-imx8x_hmp_overlay.dts (1.7 KB)

Hello @Deepak1,

Did the device start rebooting only after you applied the new overlay with the new memory regions?
I want to know if the hello-world demo worked properly before adding this memory region to load from DDR memory.

Please share the boot logs when the device is rebooting.

From my internal discussions, it appears that there was a known bug in the early versions of BSP 7 that could result in this boot failure. It is related to the remote proc driver. This is supposed to be fixed in BSP 7.3.0 but from your results it seems not. Please be patient until I can investigate this together with our R&D and I will come back to you with the working results.

Hi @rudhi.tx ,

We have applied HMP overlay that you have given here in forum, we have tried to flash M4 from both MIMX8QX6xxxxx_cm4_ram.ld and MIMX8QX6xxxxx_cm4_ddr_ram. What we have observed is

Before applying overlay,

→ with both the linker script system is getting continous reboot.

After applying overlay,

→ with MIMX8QX6xxxxx_cm4_ram.ld our helloworld works fine and with

MIMX8QX6xxxxx_cm4_ddr_ram.ld system is going for continuous reboot.

From this we got a conclusion that booting from TCM works fine,but our application demands more memory we need to use DDR RAM also. We tried a method that by introducing a bootloader that will runs from TCM memory and then switching to our application but this also was giving continuous reboot.

Regards,

Deepak

Could you please test it on the latest nightly release of Torizon 7.5.0? There have been some changes in this version that could make it work.