IMX93 M33 remoteproc TSTMR access from Linux

[mdeneen]

Hi!

I am trying to read a high resolution timer (in microseconds) using the TSTMR peripheral, and I'm following the example of the mcimx93evk_tstmr example.  If I load the code from u-boot and execute it there, it seems to work wonderfully.  However, when loading it from the remoteproc infrastructure, execution stops whenever it attempts to access registers in the TSTMR peripheral.  This is running on a board based on the IMX93 eval board.

static inline uint64_t xTSTMR_ReadTimeStamp(TSTMR_Type *base)
{
    uint32_t reg_l;
    uint32_t reg_h;
    PRINTF("\r\n test 1 (execution stops here)\r\n");
    reg_l = base->L;
    PRINTF("\r\n test 2 \r\n");
    __DMB();
    reg_h = base->H;
    return (uint64_t)reg_l | (((uint64_t)reg_h) << 32U);
}

Base is set to TSTMR1__TSTMRA.  Again, this works from u-boot, so this must be due to some sort of misconfiguration of the remoteproc interface in my device tree or because of resource contention between Linux and the M33 core.  The example is not marked as "can't run with Linux executing", as others are.  I am not currently using OP-TEE.

I feel like I'm making a simple mistake or overlooking something, and hopefully someone out there knows where I've gone awry!

[joanxie]

what's your test steps? pls share it, let me double check it

[mdeneen]

Hi,

I installed the MCUXpresso pieces (west, vscode extension, etc) and downloaded the SDK from NXP.  The example I was trying to run is in the boards/mcimx93evk/driver_examples/tstmr directory.

int main(void)
{
    uint64_t ts;

    /* Board pin, clock, debug console init */
    BOARD_InitBootPins();
    BOARD_BootClockRUN();
    BOARD_InitDebugConsole();

    ts = TSTMR_ReadTimeStamp(EXAMPLE_TSTMR);
    PRINTF("\r\n Timestamp1 = %x%x\r\n", (uint32_t)(ts >> 32), (uint32_t)ts);

    PRINTF("\r\n Test the delay function, delay for 1 second\r\n");

    ts = TSTMR_ReadTimeStamp(EXAMPLE_TSTMR);
    PRINTF("\r\n Start time = %x%x\r\n", (uint32_t)(ts >> 32), (uint32_t)ts);

    TSTMR_DelayUs(EXAMPLE_TSTMR, 1000000);

    ts = TSTMR_ReadTimeStamp(EXAMPLE_TSTMR);
    PRINTF("\r\n End time = %x%x\r\n", (uint32_t)(ts >> 32), (uint32_t)ts);
    while (1)
    {
    }
}

With the code above, no output will be seen on the debug port when loaded via the remoteproc interface in Linux.  Running it in u-boot produces the desired output.

To run from u-boot, I put the bin file on a mmc partition and do the following:

> fatload mmc 0:2 ${loadaddr} tstmr.bin
> cp.b ${loadaddr} 0x201e0000 ${filesize}
> bootaux 0x1ffe0000 0

(at this point, the output shows up on the debug port as expected)

I then copied TSTMR_ReadTimeStamp and renamed it to xTSTMR_ReadTimeStamp -- you can see the changes that I've made in my first message.

To load the firmware in Linux, I am doing the following:

# echo -n /data/firmware > /sys/module/firmware_class/parameters/path
# echo -n tstmr.elf > /sys/class/remoteproc/remoteproc0/firmware
# echo -n start > /sys/class/remoteproc/remoteproc0/state

At this point, execution stops as described in my first message, as soon as it tries to read TSTMR1__TSTMRA.

In my device tree the following things are set for the cm33:

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

                linux,cma {
                        compatible = "shared-dma-pool";
                        reusable;
                        alloc-ranges = <0 0x80000000 0 0x40000000>;
                        size = <0 0x10000000>;
                        linux,cma-default;
                };

                ethosu_mem: ethosu_region@C0000000 {
                        compatible = "shared-dma-pool";
                        reusable;
                        reg = <0x0 0xC0000000 0x0 0x10000000>;
                };

                vdev0vring0: vdev0vring0@a4000000 {
                        reg = <0 0xa4000000 0 0x8000>;
                        no-map;
                };

                vdev0vring1: vdev0vring1@a4008000 {
                        reg = <0 0xa4008000 0 0x8000>;
                        no-map;
                };

                vdev1vring0: vdev1vring0@a4000000 {
                        reg = <0 0xa4010000 0 0x8000>;
                        no-map;
                };

                vdev1vring1: vdev1vring1@a4018000 {
                        reg = <0 0xa4018000 0 0x8000>;
                        no-map;
                };

                rsc_table: rsc-table@2021e000 {
                        reg = <0 0x2021e000 0 0x1000>;
                        no-map;
                };

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

                ele_reserved: ele-reserved@a4120000 {
                        compatible = "shared-dma-pool";
                        reg = <0 0xa4120000 0 0x100000>;
                        no-map;
                };
        };

        cm33: imx93-cm33 {
                compatible = "fsl,imx93-cm33";
                mbox-names = "tx", "rx", "rxdb";
                mboxes = <&mu1 0 1
                          &mu1 1 1
                          &mu1 3 1>;
                memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
                                <&vdev1vring0>, <&vdev1vring1>, <&rsc_table>;
                fsl,startup-delay-ms = <500>;
        };

        ethosu {
                compatible = "arm,ethosu";
                fsl,cm33-proc = <&cm33>;
                memory-region = <&ethosu_mem>;
                power-domains = <&mlmix>;
        };

[joanxie]

did you set uboot as below? Pass clk_ignore_unused in bootargs when using bootaux to kick Arm Cortex-M33

u-boot=>run prepare_mcore; setenv mcore_clk clk-imx93.mcore_booted clk_ignore_unused

u-boot=>setenv fdtfile imx93-11x11-evk-rpmsg.dtb

[mdeneen]

Hey Joanxie,

There may have been some miscommunication -- I'm not trying to use bootaux to kickstart the m33.  I used it as an example to show that the code functions as expected outside of Linux.

[joanxie]

so what do you kickstart the M core, if you use the bootaux with the parameter I share before, is it ok?