Cortex-M4 issue on IMX8QM Stuck boot

this is the output shown by the M4 side

/* Power on Peripherals. */
    if (sc_pm_set_resource_power_mode(ipc, SC_R_GPIO_3, SC_PM_PW_MODE_ON) != SC_ERR_NONE)
    {
        PRINTF("Error: Failed to power on GPIO\r\n");
    }

from the message, I’m a little confused where the problem is because according to the .c gpio example code snippet that I customized, it seems like there is a problem in the SC_R_GPIO_3 resource. Then after I checked also the ownership of the resource also has a false output.

sc_bool_t owned = sc_rm_is_resource_owned(ipc, SC_R_GPIO_3);
    if (!owned)
    {
        PRINTF("GPIO3 not owned...\r\n");
    }

Then on

$ dmesg

I found that there was a failure on pinctrl. But I still don’t know the cause why, because it’s not all gpio that doesn’t work but after I checked only gpio 1 - 6 are dead (because the UART that I use for serial debug and gpiofan is running properly).

[ 0.216244] imx8qm-pinctrl system-controller:pinctrl: initialized IMX pinctrl driver
[ 0.218176] imx8qm-pinctrl system-controller:pinctrl: pin_config_set op failed for pin 13
[ 0.218183] imx8qm-pinctrl system-controller:pinctrl: Error applying setting, reverse things back
[ 0.218198] imx8qm-pinctrl system-controller:pinctrl: failed to select default state

Hi @Azkaaa ,

Let’s take MXM3_3/GPIO2 as an example. MXM3_3 is in M4_0 partition in default SCFW. It has to be freed from the partition. According to sc_fw_api_qm_b0.pdf, the pad of MXM3_3 is SC_P_M40_GPIO0_01.

In platform/board/mx8qm_apalis/board.c, comment out //RM_RANGE(SC_P_M40_I2C0_SCL, SC_P_M40_GPIO0_01).

            /* List of pads */
            static const sc_pad_t pad_list[2U] =
            {
                //RM_RANGE(SC_P_M40_I2C0_SCL, SC_P_M40_GPIO0_01)
                SC_P_M40_I2C0_SCL
            };

Rebuild the SCFW and assemble the boot container again.
MXM3_3 can be set to high or low by the following command.

root@apalis-imx8-06494587:~# gpioset -c gpiochip2 9=0
^C
root@apalis-imx8-06494587:~# gpioset -c gpiochip2 9=1
^C

ohh i see, for the case of M4_0 and M4_1 partitions in SCFW already by default have authority in the resource. So to use gpio on the Linux side, I need to disable the resource on the M4 side first?

and also why when I access gpio 3 and 4 on M4_1 it is still not working? even though the sc_fw_api_qm_b0.pdf documentation and also from apalis_imx8 show that gpio 3 and 4 are on the M4_1 partition.
image

the result still :

is there also an adjustment if the GPIO is used in M4_1?

Hi @Azkaaa ,
MXM3_5 and MXM3_7 will be muxed to LSIO.GPIO0.IO12 and LSIO.GPIO0.IO13, and both pads belong to band 0. In SCFW source code, SC_R_GPIO_0 has to be assigned to M4_1 partition.

        /* Create M4 1 partition */
        if (rm_is_resource_avail(SC_R_M4_1_PID0) != SC_FALSE)
        {
            sc_rm_mr_t mr;

            /* List of resources */
            static const sc_rsrc_t rsrc_list[10U] =
            {
                SC_R_IRQSTR_M4_1,
                SC_R_UART_2,
                SC_R_MU_6B,
                SC_R_MU_7B,
                SC_R_MU_9B,
                SC_R_GPT_3,
                RM_RANGE(SC_R_CAN_0, SC_R_CAN_2),
                SC_R_FSPI_0,
                SC_R_GPIO_0
            };

In FreeRTOS project led_output, MXM3_5 and MXM3_7 will be defined. It was LSIO.GPIO3.IO7(MXM3_235) by default. gpio_led_output.c needs similar change as well. Here the project I test.
cm4_core1.tar.xz (83.6 KB)

#define BOARD_INITPINS_BB_M41_GPIO0_00_PIN_FUNCTION_ID                   SC_P_M41_GPIO0_00
#define BOARD_INITPINS_BB_M41_GPIO0_01_PIN_FUNCTION_ID                   SC_P_M41_GPIO0_01

In this project, both MXM3_5 and MXM3_7 toggle from the M4_1 core.

Hi @benjamin.tx ,
thanks for the help so far.
yes I also just realized that I have to add SC_R_GPIO_x to the resource list on the m4_1 partition that I am using. where can I find out which pad I am using is connected to which resource? because you said that and in the future I want to create a mapping of resources and pads on each partition and from what I will create later. or how to find out the resource used just by looking at the GPIO name? like LSIO.GPIO0.IO12 means I have to use the resource SC_R_GPIO_0. so SC_R_GPIO_xLSIO.GPIOx.IOy

Then, if I want to add the pads that I want, do I only need to add them to the scfw on the M4 partition that I am using or do I need to add them to the RTOS project that I will use like your example?

Hi @Azkaaa ,

how to find out the resource used just by looking at the GPIO name?

On the Apalis iMX8 datasheet, MXM3_5 is routed from ball M40_GPIO0_00 and it is LSIO.GPIO0.IO12 when muxed to GPIO functionality. GPIO0.IO12 means bank 0 and line 12.


Since the entire bank0 SC_R_GPIO_0 is moved to M4_1 partition, I have not tested whether the reset gpios from bank0 can be accessed from the Linux side.

Then, if I want to add the pads that I want, do I only need to add them to the scfw on the M4 partition that I am using, or do I need to add them to the RTOS project that I will use like your example?

You have to do both. SCFW only allocates resources. Peripheral configuration e.g. gpio muxing is done in the FreeRTOS project.

hi @benjamin.tx ,

It’s okay because I will do static partitioning of resources in Linux and Cortex-M4 in the future.

And also from the error that I showed earlier in Cortex-A53 side indicating the resource is not owned because it has been addressed to m4_1 (based on the scfw that I have traced).

From our many discussions, I’m finally starting to connect the dots to the problems I’ve been having on the Cortex-m4. If the allocation of resources and pads on the Cortex-M side is done in SCFW and the RTOS program. Then on the Linux side, can I just do it from the device tree without mapping to SCFW? because for resource allocation and pads I just found out when developing applications in this RTOS.

maybe this will be my last question. thank you for your help so far.

best regards,
azka

Hi @Azkaaa , SCFW allocates resources for all partitions, including the one where Linux runs. The BOOT partition contains all the memory and almost all the resources. Resources are not explicitly moved to M4_0, and M4_1 will stay in BOOT partition. It is renamed to AP0 by PARTITION_NAME(pt_boot, "AP0"); in the SCFW source code. Linux runs on A53/72 belongs to AP0 partition. The device tree doesn’t manage resource allocation. It only happens on SCFW.

    /* Name default partitions */
    PARTITION_NAME(SC_PT, "SCU");
    PARTITION_NAME(SECO_PT, "SECO");
    PARTITION_NAME(pt_boot, "BOOT");

    /* Configure initial resource allocation (note additional allocation
       and assignments can be made by the SCFW clients at run-time */
    if (alt_config != SC_FALSE)
    {
        sc_rm_pt_t pt_m4_0 = SC_RM_NUM_PARTITION;
        sc_rm_pt_t pt_m4_1 = SC_RM_NUM_PARTITION;

        #ifdef BOARD_RM_DUMP
            rm_dump(pt_boot);
        #endif

        /* Name boot partition */
        PARTITION_NAME(pt_boot, "AP0");

Hi @benjamin.tx , so are all the resources and pads on AP0 actually included without needing to be specified? so that if there is a resource allocation on the M4 partition, then it is explicitly mentioned. is that right?

so are all the resources and pads on AP0 actually included without needing to be specified?

Yes.

so that if there is a resource allocation on the M4 partition, then it is explicitly mentioned. is that right?

Correct.

Resources allocated to M4 partitions should not be accessed from Linux, including pin mixing in the device tree.

Well @benjamin.tx , thank you for your help so far. It’s all a bit clearer now.

Best Regards,
Azka