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