Cortex-M4 issue on IMX8QM Stuck boot

CoM Model: Toradex Apalis iMX8 QuadMax 8GB Wi-Fi / BT IT V1.1A
Board : Ixora Carrier Board

dear support team,
I have an issue when running Cortex-M4 and Cortex-A simultaneously. the initial condition I tried was using BSP 7.1.0 and running FreeRTOS_hello example. I followed the following guide freertos-on-the-cortex-m4-of-an-apalis-imx8 to run FreeRTOS and hello-world-cortexM to customize devicetree overlays for imx8. Then I setup u-boot to run cortex-m4_1 automatically (because on the ixora board only uart on core 1 is supported by default).

but there is no error at all during booting but there is inconsistency when booting. sometimes when rebooted cortex-A can boot immediately and the most common case is infinite booting. In both cases, the Cortex-M stops operating when cortex-A boots and the kernel repeats booting at the position like the following message (most cases).
loop_booting_when_load_M4 (71.2 KB)

and the following image is the condition of the Cortex-M4_1 serial repeating the counting I did with a 200ms delay

is there any issue related to load cortex-M4 in BSP 7? or for imx8qm it can only run in BSP 5 like the source I read below?
apalis-imx8qm-rpmsg-issue-on-bsp-5-0

but after I tried BSP 5.7.6, I also still have problems with adding overlays. whereas in BSP 7 it works fine.

Applying Overlay: apalis-imx8_M4-Core-0_UART_overlay.dtbo
1543 bytes read in 21 ms (71.3 KiB/s)
Applying Overlay: apalis-imx8_M4-Core-1_UART_overlay.dtbo
593 bytes read in 23 ms (24.4 KiB/s)
failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND
10432345 bytes read in 327 ms (30.4 MiB/s)
Uncompressed size: 24695296 = 0x178D200
Bootargs: pci=nomsi root=PARTUUID=59ccb610-02 ro rootwait
ERROR: Did not find a cmdline Flattened Device Tree
FDT and ATAGS support not compiled in - hanging
### ERROR ### Please RESET the board ###

and here I attach the device tree overlays that I use

  • Core 0
/dts-v1/;
/plugin/;

/* Disable UART1 Control Pins to use M4 Core 0 and 1 UART */

/ {
    compatible = "toradex,apalis-imx8";
};

&iomuxc {
    pinctrl-0 = <&pinctrl_cam1_gpios>, <&pinctrl_dap1_gpios>,
            <&pinctrl_esai0_gpios>, <&pinctrl_fec2_gpios>,
            <&pinctrl_gpio3>, <&pinctrl_gpio4>, <&pinctrl_gpio_keys>,
            <&pinctrl_gpio_usbh_oc_n>,
            <&pinctrl_lvds0_i2c0_gpio>, <&pinctrl_lvds1_i2c0_gpios>,
            <&pinctrl_mipi_dsi_0_1_en>, <&pinctrl_mipi_dsi1_gpios>,
            <&pinctrl_mlb_gpios>, <&pinctrl_qspi1a_gpios>,
            <&pinctrl_sata1_act>, <&pinctrl_sim0_gpios>,
            <&pinctrl_usdhc1_gpios>;
};
  • Core 1
/dts-v1/;
/plugin/;

/* Disable PWM0 and PMW1 to use M4 Core 1 UART */

/ {
    compatible = "toradex,apalis-imx8-v1.1-eval",
             "toradex,apalis-imx8-eval",
             "toradex,apalis-imx8",
             "fsl,imx8qm";
};

&lsio_pwm0 {
    status = "disabled";
};

&lsio_pwm1 {
    status = "disabled";
};

&lpuart2 {
    status = "disabled";
};

apalis-imx8_M4-Core-1_UART_overlay.dts (357 Bytes)
apalis-imx8_M4-Core-0_UART_overlay.dts (664 Bytes)

Best Regards,
Azka

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


Hello Azka,

Thank you for reaching out with your concerns about running FreeRTOS on the Cortex-M4 core of your Apalis iMX8 QuadMax module. Let’s address the issues you’re experiencing:

  1. Booting Inconsistencies:

    • The inconsistent boot behavior might be due to incorrect device tree configurations or BSP version compatibility issues. Please ensure that your device tree overlays are correctly applied and match the hardware configuration of your Ixora Carrier Board.
    • Double-check your U-Boot environment settings to ensure the Cortex-M4 firmware is loaded correctly. Misconfigurations here can lead to boot issues.
  2. Device Tree Overlay Errors:

    • The error failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND indicates that the overlay is not being applied correctly. This could be due to a mismatch between the overlay and the base device tree or an incorrect path or filename.
    • Verify that your overlays are compatible with the BSP version you are using. Sometimes, overlays require adjustments when switching between BSP versions.
    • Carefully review the syntax and structure of your device tree overlays, as even minor errors can prevent them from being applied correctly.
  3. BSP Version Compatibility:

    • While BSP 7 should generally support the Apalis iMX8 QuadMax, specific issues or bugs might exist. If BSP 5.7.6 also presents problems, consider checking for any known issues or updates related to these versions.
    • Testing with the latest stable BSP version, if available, might help resolve some of the issues you’re facing.

By focusing on these areas, you should be able to address the booting inconsistencies and overlay application errors. If you continue to experience issues, further investigation into your specific configurations and logs may be necessary.

Best regards,
Toradex AI Assistant

Please, also check if these links can help you solve your problem:

Controlling the peripheral in IMX8 with M4 core.

I’m sorry, I didn’t know that the overlays on core 1 are different from BSP 7 and the overlays for core 1 were added successfully after I changed them.

/dts-v1/;
/plugin/;

/* Disable PWM0 and PMW1 to use M4 Core 1 UART */

/ {
    compatible = "toradex,apalis-imx8-v1.1-eval",
             "toradex,apalis-imx8-eval",
             "toradex,apalis-imx8",
             "fsl,imx8qm";
};

&pwm0 {
    status = "disabled";
};

&pwm1 {
    status = "disabled";
};

&lpuart2 {
    status = "disabled";
};

but still, even though my kernel booted successfully. but the RTOS program that I run on the cortex-M4 is stuck. I don’t know if this is normal or not. because in my knowledge the cortex-M should still work even though it boots with Cortex-A.

Is the problem related to the UART that I use that conflicts with the cortex-A? But this should have been resolved from the overlays that I added. Or is there a problem with the application I created on the cortex-M4.

/*!
 * @brief Application entry point.
 */
int main(void)
{
    /* Init board hardware. */
    sc_ipc_t ipc = BOARD_InitRpc();

    BOARD_InitPins(ipc);
    BOARD_BootClockRUN();
    BOARD_InitMemory();
    BOARD_InitDebugConsole();
    if (xTaskCreate(hello_task, "Hello_task", configMINIMAL_STACK_SIZE + 100, NULL, hello_task_PRIORITY, NULL) !=
        pdPASS)
    {
        PRINTF("Task creation failed!.\r\n");
        while (1)
            ;
    }
    vTaskStartScheduler();
    for (;;)
        ;
}

/*!
 * @brief Task responsible for printing of "Hello world." message.
 */
static void hello_task(void *pvParameters)
{
    const int delay_ms = 200;
    uint8_t count = 0;
    for (;;)
    {
        vTaskDelay(pdMS_TO_TICKS(delay_ms));
        PRINTF("Hello world. %d \r\n", count);
        count++;
    }
}

Here’s an example of the output generated and stopped right after the message “starting kernel…”

I was wrong about the cortex-M4 on BSP 5. now it worked fine. I wasn’t careful enough to include the core 0 overlay when booting because the overlay removes uart1 on pinctrl which is actually used for the linux kernel on ixora board(maybe it’s different with eval board). so I disabled it on the overlay and it worked.

In addition, I need to set the compatible value on the overlay that I use because I use the ixora board and device tree imx8qm-apalis-v1.1-ixora-v1.2.dtb. so I changed the overlay a little to be like this:

/dts-v1/;
/plugin/;

/* Disable PWM0 and PMW1 to use M4 Core 1 UART */

/ {
    compatible = "toradex,apalis-imx8qm-ixora-v1.2",
		 "toradex,apalis-imx8-ixora-v1.2",
		 "toradex,apalis-imx8qm-ixora",
		 "toradex,apalis-imx8-ixora",
		 "toradex,apalis-imx8qm",
		 "toradex,apalis-imx8",
		 "fsl,imx8qm";
};

&pwm0 {
    status = "disabled";
};

&pwm1 {
    status = "disabled";
};

&lpuart2 {
    status = "disabled";
};

with these results, I think it will work also in BSP 7 but I still get the same infinite booting as before. i still don’t know what the issue is that makes this happen. is there a problem with the 6.6 kernel used in BSP 7 or is there an interrupt problem that I don’t know about so that booting continues to occur in the same position? please give me clue about this issue.

best regards,
azka

Hi Azka, I am looking into this issue and will get back to you soon.

Hi Benjamin, thank you for your attention and I look forward to support from you soon.

Hi @Azkaaa , This issue can be reproduced on Apalis iMX8 with BSP7. It keeps rebooting when both the Linux kernel and M4 firmware are launched. The reset cause is SCFW fault. I haven’t found the reason why it happened. The same issue was also reported on NXP community . I tried to create separate partitions for M4_1 and A72/53 cores without luck. I will let you know once I get update.

Hi @benjamin.tx ,

Thank you for the information. I am relieved that the problem is not from the kernel version. So is the latest kirkstone or BSP 6.x.y (which I know has the same kernel version as BSP 7) able to run M4 and linux together safely? or is it because the scfw version adjusts the kernel version so that for scfw with kernel 6.6 there are still some faults?

please give me advice, which bsp version is the most robust and newest for M4 development core with linux because I want to try rpmsg communication on apalis imx8qm.

Best regards,
Azka

BSP 6 has Linux 5.15 which is different from BSP7. For M4 development on Apalis iMX8, I suggest BSP5 though it shouldn’t be chosen for a new design due to its lifetime cycle. If your application doesn’t heavily rely on Linux 6.6 itself, it will be not difficult to migrate from BSP5. This is a device tree patch for BSP5 supporting M4.
0004-apalis-imx8-add-rpmsg-support_v5.3.patch (2.9 KB)

well thanks for the advice. it runs normally on BSP 6 or kernel 5.15 and also on BSP 5 which I used before. But on BSP 5, when I enable the “CONFIG_RPMSG_CTRL” config on the kernel it causes it to fail to load the imx_rpmsg_tty module. that’s what I just realized from my failure so far in rpmsg on BSP 5 but it runs normally on the BSP 6 that I am using.

overall the problem is solved but if there is any update regarding the problem in BSP 7 or kernel 6.6 I will be very much looking forward to it.

best regards,
Azka

Hi @Azkaaa , Here is a workaround for launching M4 on BSP7. As suggested by NXP community, M4 firmware will be loaded from SCFW instead of U-boot.

Disable kernel_comp_addr_r checking in u-boot/cmd/booti.c and rebuild U-Boot.

    if (dest < gd->ram_base || dest > gd->ram_top) {
        puts("kernel_comp_addr_r is outside of DRAM range!\n");
        //return -EINVAL;
    }

To load M4 firmware from SCFW, you have to custom the boot container according to the guide from this page. The built u-boot.bin is copied to imx-mkimage/iMX8QM. M4 firmware is copied to the same destination. Rename firmware file name to m4_image.bin for M4_1 and m4_1_image.bin for M4_1.

Assemble the boot container using the following command. It is make SOC=iMX8QM flash_b0 by default which doesn’t include M4 firmware in boot container.

 make SOC=iMX8QM flash_regression_linux_m4

The boot container file iMX8QM/flash.bin can be renamed to imx-boot and replace the one from BSP 7 image. Toradex Easy Installer will update the image including the boot container. You can also update the boot container from U-Boot. So that you don’t have to reinstall the entire image.

A tftp server is required to update boot container file from U-Boot. Copy iMX8QM/flash.bin to the tftp directory.

Set tftp server and Apalis iMX8 IPs in U-Boot.

Apalis iMX8 # setenv ipaddr 192.168.3.181
Apalis iMX8 # setenv serverip 192.168.3.196

Apalis iMX8 # tftpboot $loadaddr flash.bin
Using ethernet@5b040000 device
TFTP from server 192.168.3.196; our IP address is 192.168.3.181
Filename 'flash.bin'.
Load address: 0x95400000
Loading: ##################################################  1.2 MiB
	 3.4 MiB/s
done
Bytes transferred = 1238016 (12e400 hex)

Apalis iMX8 # mmc dev 0 1
Apalis iMX8 # mmc write $loadaddr 0 0x973

Here 0x973 is calculated from (1238016+511)/512 and rounds the number up to the nearest integer. This number is the amount of blocks needs to be written for flash.bin.

This is a patch for imx8qm-apalis-v1.1-ixora-v1.2.dts.
rpmsg_bsp7.patch (4.1 KB)

Apalis iMX8 # setenv fdtfile imx8qm-apalis-v1.1-ixora-v1.2.dtb
Apalis iMX8 # saveenv

is there any spesific version in u-boot build that I need to have for this to work? because the bsp I’m using is 7.1.0.

It is toradex_imx_lf_v2024.04 for BSP 7.

for other version needs such as scfw, imx-atf, etc. do I only need to follow what is in this guide?
u-boot from source code for imx8

SCFW upgrades to 1.17.0 in BSP 7.1.0. Our developer page will be updated soon. Since no change is needed from SCFW. Our prebuilt SCFW binary from GitHub - toradex/i.MX-System-Controller-Firmware can be used for assembling boot container. You can follow the guide on Specifics: Build U-Boot for NXP i.MX 8/8X-based SoMs.

thanks for the help, now my M4 and rpmsg can work fine. but there is an unusual message appears like kernel_comp_addr_r is outside of DRAM range!. Is it normal when changing booti.c as you suggested before and also why is there an effect of disabling CAN and clock-controller? because when I run a normal image without modification it does not appear like that.

do the things done before have anything to do with it? because it happens before the kernel boot so it’s not caused by driver problems.

Bootargs: root=PARTUUID=aa7e5777-02 ro rootwait console=tty1 console=ttyLP1,115200
kernel_comp_addr_r is outside of DRAM range!
   Uncompressing Kernel Image to 0
## Flattened Device Tree blob at 9d400000
   Booting using the fdt blob at 0x9d400000
Working FDT set to 9d400000
   Loading Device Tree to 0000000083fb1000, end 0000000083ffffff ... OK
Working FDT set to 83fb1000
Disable clock-controller@5a480000 rsrc 59 not owned
Disable can@5a8d0000 rsrc 105 not owned
Disable can@5a8e0000 rsrc 106 not owned
Disable clock-controller@5acd0000 rsrc 105 not owned
Disable clock-controller@5ace0000 rsrc 106 not owned
Disable clock-controller@5acf0000 rsrc 107 not owned
Disable clock-controller@37630000 rsrc 288 not owned
Disable clock-controller@37620000 rsrc 287 not owned
Disable clock-controller@3b630000 rsrc 308 not owned
/bus@5a000000/dma-controller@5a1f0000, 59044
/bus@5a000000/dma-controller@5a9f0000, 60276
/bus@59000000/dma-controller@591f0000, 24500
/bus@59000000/dma-controller@591f0000, 24500
/bus@59000000/dma-controller@599f0000, 25852

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]

then after the evaluation that I did after changing the firmware. I can’t access GPIO from the linux side such as gpioset and also use /sys/class/gpio/gpioxxx/value to change the gpio state. is this related to the previous disable problem?

Hi @Azkaaa , Which GPIO is inaccessible from the Linux side? And what is the SCFW version?

HI @benjamin.tx, I used scfw version 1.17 as you suggested. and I tried using GPIO1 and GPIO2 which did not change state when I changed the value. I think other GPIOs also have the same condition. are you not encountering the same thing?

from my next experiment with blink led with RTOS on cortex-M4 also get the same result that GPIO does not respond anything.