TDA4VM: add application on MCU domain

hi,Nikhil

     Thanks for your support. we want use MCU only mode to realize the duty function, and wake up with CAN. On active mode to  run vision_apps demo.  Now we have implemented the CAN wake up program.But we don't know much about the whole system startup process.

1.Whether the MCU only mode can use SPL to start linux

2.The DM is locate MCU domain MCU1_0. But in CAN demo, there is no DM. 

3.The demo need to flash both OSPI flash and SD card. Whether it can be implemented by only using EMMC

Hi Davied

Can you please explain your overall use case? If there is a flowchart which can make things clear?

davied zhang said:

1.Whether the MCU only mode can use SPL to start linux

Do you mean you will be using SPL to boot Linux (in ACTIVE mode) and then after some time you will transition to the MCU only mode. Once this is done the ECU will operate in MCU Only mode until the CAN wakeup is triggered, finally taking the ECU back to full ACTIVE mode?

davied zhang said:

2.The DM is locate MCU domain MCU1_0. But in CAN demo, there is no DM. 

I'm assuming you now have a standalone MCU1_0 application which uses CAN and you want to integrate this in the overall system with all cores running? If so, then you need to integrate the DM into the CAN demo, details for this can be found here - https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/09_00_01_01/exports/docs/psdk_rtos/docs/user_guide/developer_notes_mcu1_0_sysfw.html 

davied zhang said:

3.The demo need to flash both OSPI flash and SD card. Whether it can be implemented by only using EMMC

Can you please clarify this question? Do you only want to use eMMC? If so, this is possible but will impact boot time as eMMC's initialization time is higher than OSPI NOR flashes.

Regards

Karan

Hi，Karan

     Thanks for your support. All three of the things you said above are correct. We are trying to add low-power functions to the app_multi_cam_codec  demo of vision_apps , and we only use EMMC.

    we run vision_apps in default environment of SDK, as we think it's boot by spl. and the boot flow as follows:3.1.1.1. General Information — Processor SDK Linux for J721e Documentation

      Now we try to add application in ../ti-processor-sdk-rtos-j721e-evm-08_06_00_12/vision_apps/platform/j721e/rtos/mcu1_0/main.c to achieve low power consumption.Is this feasible?

     We have another puzzle, the MCU1_0 is already running by using tiboot3.bin when TDA4 start.  How MCU1_0 can  run /lib/firmware/j7-mcu-r5f0_0-fw agian？

Regards
Zhang   

Hi,Karan

     Thanks for your support. We alreadly know how to do.

     As we think,  MCU1_0's application is started through SPL/uboot.  About ten seconds after powering on，it can start work successfully. It's too slow for us. We understand that MCU boot later in order to make MPU/Linux boot faster. Can we boot the MCU1_0 faster by SPL/uboot? If so, what should we do.

Regards

Zhang

Hi Zhang

In the SPL/u-boot flow, the MCU1_0 is actually the first firmware to be booted.

R5 SPL boots A72 with A72 SPL and branches to the MCU1_0 application. Before you hit the A72 SPL or u-boot, the MCU1_0 is already running your application. In the documentation here, if you see the "Load R5 firmware, this is where the MCU1_0 application gets loaded which is much earlier than any other thing in the boot sequence.

Probably there is something in your MCU1_0 firmware which is delaying the functionality?

Regards

Karan

HI，Karan

      Thanks for your support.  we can MCU1_0 firmware load error because MCU1_0 is alreadly running in SPL/uboot.

k3_r5f_rproc r5f@41000000: Core 1 is already in use. No rproc commands work
k3_r5f_rproc r5f@41400000: Core 2 is already in use. No rproc commands work
1424760 bytes read in 69 ms (19.7 MiB/s)
Load Remote Processor 2 with data@addr=0x82000000 1424760 bytes: Success!
301996 bytes read in 22 ms (13.1 MiB/s)
Load Remote Processor 3 with data@addr=0x82000000 301996 bytes: Success!
191416 bytes read in 18 ms (10.1 MiB/s)
Load Remote Processor 4 with data@addr=0x82000000 191416 bytes: Success!
191416 bytes read in 18 ms (10.1 MiB/s)
Load Remote Processor 5 with data@addr=0x82000000 191416 bytes: Success!
1334036 bytes read in 64 ms (19.9 MiB/s)
Load Remote Processor 6 with data@addr=0x82000000 1334036 bytes: Success!
1334036 bytes read in 65 ms (19.6 MiB/s)
Load Remote Processor 7 with data@addr=0x82000000 1334036 bytes: Success!
12849048 bytes read in 213 ms (57.5 MiB/s)
Load Remote Processor 8 with data@addr=0x82000000 12849048 bytes: Success!
19079680 bytes read in 792 ms (23 MiB/s)
111903 bytes read in 12 ms (8.9 MiB/s)
11789 bytes read in 9 ms (1.2 MiB/s)

     In kernel start, we can get remoteproc start MCU1_0(41000000.r5f). What do these states of mcu1_0 mean?

                              ->  remoteproc remoteproc1: 41000000.r5f is available

                             ->remoteproc remoteproc1: attaching to 41000000.r5f

                             ->remoteproc remoteproc1: remote processor 41000000.r5f is now attached

root@j7-evm:~# dmesg |grep remoteproc
[    5.738803] remoteproc remoteproc0: 4d80800000.dsp is available
[    5.780871] remoteproc remoteproc0: attaching to 4d80800000.dsp
[    5.812271]  remoteproc0#vdev0buffer: assigned reserved memory node vision-apps-c66-dma-memory@a9000000
[    5.850785]  remoteproc0#vdev0buffer: registered virtio0 (type 7)
[    5.890607] remoteproc remoteproc0: remote processor 4d80800000.dsp is now attached
[    5.934669] remoteproc remoteproc1: 41000000.r5f is available
[    5.942132] remoteproc remoteproc2: 4d81800000.dsp is available
[    5.948158] remoteproc remoteproc1: attaching to 41000000.r5f
[    5.960947] remoteproc remoteproc2: attaching to 4d81800000.dsp
[    5.974093]  remoteproc1#vdev0buffer: assigned reserved memory node vision-apps-r5f-dma-memory@a0000000
[    5.983544]  remoteproc2#vdev0buffer: assigned reserved memory node vision-apps-c66-dma-memory@a8000000
[    6.046219]  remoteproc1#vdev0buffer: registered virtio1 (type 7)
[    6.058288]  remoteproc2#vdev0buffer: registered virtio2 (type 7)
[    6.075640] remoteproc remoteproc1: remote processor 41000000.r5f is now attached
[    6.085851] remoteproc remoteproc2: remote processor 4d81800000.dsp is now attached
[    6.202913] remoteproc remoteproc3: 5c00000.r5f is available
[    6.217741] remoteproc remoteproc3: attaching to 5c00000.r5f
[    6.231458]  remoteproc3#vdev0buffer: assigned reserved memory node vision-apps-r5f-dma-memory@a2000000
[    6.251492]  remoteproc3#vdev0buffer: registered virtio3 (type 7)
[    6.261488] remoteproc remoteproc3: remote processor 5c00000.r5f is now attached
[    6.270573] remoteproc remoteproc4: 64800000.dsp is available
[    6.299516] remoteproc remoteproc5: 5d00000.r5f is available
[    6.307277] remoteproc remoteproc5: attaching to 5d00000.r5f
[    6.322039]  remoteproc5#vdev0buffer: assigned reserved memory node vision-apps-r5f-dma-memory@a4000000
[    6.340473]  remoteproc5#vdev0buffer: registered virtio4 (type 7)
[    6.349219] remoteproc remoteproc5: remote processor 5d00000.r5f is now attached
[    6.367344] remoteproc remoteproc4: attaching to 64800000.dsp
[    6.390415] remoteproc remoteproc4: unsupported resource 65538
[    6.403850] remoteproc remoteproc6: 5e00000.r5f is available
[    6.409576]  remoteproc4#vdev0buffer: assigned reserved memory node vision-apps-c71-dma-memory@b2000000
[    6.419060] remoteproc remoteproc6: attaching to 5e00000.r5f
[    6.444689]  remoteproc6#vdev0buffer: assigned reserved memory node vision-apps-r5f-dma-memory@a6000000
[    6.454921]  remoteproc4#vdev0buffer: registered virtio5 (type 7)
[    6.461600] remoteproc remoteproc4: remote processor 64800000.dsp is now attached
[    6.476895]  remoteproc6#vdev0buffer: registered virtio6 (type 7)
[    6.488443] remoteproc remoteproc6: remote processor 5e00000.r5f is now attached
[    6.547713] remoteproc remoteproc7: 5f00000.r5f is available
[    6.556425] remoteproc remoteproc7: attaching to 5f00000.r5f
[    6.574757]  remoteproc7#vdev0buffer: assigned reserved memory node vision-apps-r5f-dma-memory@a7000000
[    6.616579]  remoteproc7#vdev0buffer: registered virtio7 (type 7)
[    6.655638] remoteproc remoteproc7: remote processor 5f00000.r5f is now attached
[    7.915569] remoteproc remoteproc8: b034000.pru is available
[    7.969452] remoteproc remoteproc9: b004000.rtu is available
[    7.983030] remoteproc remoteproc10: b00a000.txpru is available
[    7.996883] remoteproc remoteproc11: b038000.pru is available
[    8.014593] remoteproc remoteproc12: b006000.rtu is available
[    8.023112] remoteproc remoteproc13: b00c000.txpru is available
[    8.038235] remoteproc remoteproc14: b134000.pru is available
[    8.068836] remoteproc remoteproc15: b104000.rtu is available
[    8.085372] remoteproc remoteproc16: b10a000.txpru is available
[    8.112314] remoteproc remoteproc17: b138000.pru is available
[    8.128782] remoteproc remoteproc18: b106000.rtu is available
[    8.151959] remoteproc remoteproc19: b10c000.txpru is available

        1.The MCU1_0 is actually the first firmware to be booted, and it's firmware includes DM and applications all started.

        2.The MCU2_0 MCU2_1 and other core  start  in kernel, but don't enable IPC.

        3.In vision_apps demo the script(vision_apps_init.sh) enable IPC for cores.

        Is that right?

Regards

Zhang

HI，Karan

     Thanks for your support. What role does /lib/firmware/j7-mcu-r5f0_0-fw play in the above process?

      We have a general understanding of the boot flow, but the results of our tests are inconsistent.

1. add uart driver to mcu1_0 and using function UART_printf to print log on mcu_uart0.(base on vision_apps, in ../ti-processor-sdk-rtos-j721e-evm-08_06_00_12/vision_apps/platform/j721e/rtos/mcu1_0/main.)

#include <ti/csl/csl_types.h>
#include <ti/csl/soc.h>
#include <ti/board/board.h>
#include <ti/drv/sciclient/sciclient.h>
#include <ti/drv/uart/UART.h>
#include <ti/drv/uart/UART_stdio.h>

static void appMain(void* arg0, void* arg1)
{
    TaskP_Handle sciserverInitTask;
    TaskP_Params sciserverInitTaskParams;

    appUtilsTaskInit();

    appSciserverSciclientInit();



    /* Initialize SCI Client Server */
    TaskP_Params_init(&sciserverInitTaskParams);
    sciserverInitTaskParams.priority     = INIT_SCISERVER_TASK_PRI;
    sciserverInitTaskParams.stack        = gSciserverInitTskStack;
    sciserverInitTaskParams.stacksize    = sizeof (gSciserverInitTskStack);

    sciserverInitTask = TaskP_create(&appSciserverInit, &sciserverInitTaskParams);
    if(NULL == sciserverInitTask)
    {
        OS_stop();
    }

    appInit();
    appRun();

    Board_initCfg     boardCfg;

    boardCfg =   BOARD_INIT_UART_STDIO;
    Board_init(boardCfg);
UART_printf("--------------------MCU1_0---------start-----------\n");
    #if 1
    while(1)
    {
        appLogWaitMsecs(100u);
    }
    #else
    appDeInit();
    #endif
}

2.rebuild vision_app and u-boot, flashing SDcard

3.Open the serial terminal of MCU_UART0 and MAIN_UART0

MCU_UART0 first print "--------------------MCU1_0---------start-----------\n", when MAIN_UART0 print "remoteproc remoteproc19: b10c000.txpru is available".

So we don't understand why is that.

Regards

Zhang

Hi

davied zhang said:

Thanks for your support. What role does /lib/firmware/j7-mcu-r5f0_0-fw play in the above process?

This used to be there for Linux to read the resource table from the firmware, now there is a design-by-contract approach where the resource table for the firmware is located at a fixed DDR location. So once the application is loaded by R5 SPL, the Linux Kernel can just read the resource table from the DDR and this /lib/firmware/j7-mcu-r5f0_0-fw is not needed.

I'll review your other questions shortly and respond.

Regards

Karan

Hi,Karan

      Thanks for your support.

      1.we see /lib/firmware/j7-mcu-r5f0_0-fw is a must in 8.3. MCU1_0 Application Development with SYSFW — Processor SDK RTOS J721E.Is this document  no timely updated?

         2.Remoteproc mode need a rebooting to make MCU work on it. Is it possible that remoteproc caused the restart of MCU1_0?

Regards,

Zhang

Zhang

davied zhang said:

    1.we see /lib/firmware/j7-mcu-r5f0_0-fw is a must in 8.3. MCU1_0 Application Development with SYSFW — Processor SDK RTOS J721E.Is this document  no timely updated?

This is no longer needed, seems like the document needs update.

davied zhang said:

         2.Remoteproc mode need a rebooting to make MCU work on it. Is it possible that remoteproc caused the restart of MCU1_0?

I'm not able to understand this, can you please elaborate?

Regards

Karan

Hi,Karan

      Thanks for your support.

This topic is our misunderstanding. After test we found appSciserverInit will causing obstruction, need to wait remoteproc service on linux kernel MCU1_0 can continue to run. The test process is as follows:

1.Enable MCU1_0 base on vision_apps demo, using function UART_printf to print log on mcu_uart0 in ../ti-processor-sdk-rtos-j721e-evm-08_06_00_12/vision_apps/platform/j721e/rtos/mcu1_0/main.

static void appMain(void* arg0, void* arg1)
{
    TaskP_Handle sciserverInitTask;
    TaskP_Params sciserverInitTaskParams;

    appUtilsTaskInit();

    appSciserverSciclientInit();



    /* Initialize SCI Client Server */
    TaskP_Params_init(&sciserverInitTaskParams);
    sciserverInitTaskParams.priority     = INIT_SCISERVER_TASK_PRI;
    sciserverInitTaskParams.stack        = gSciserverInitTskStack;
    sciserverInitTaskParams.stacksize    = sizeof (gSciserverInitTskStack);

    sciserverInitTask = TaskP_create(&appSciserverInit, &sciserverInitTaskParams);
    if(NULL == sciserverInitTask)
    {
        OS_stop();
    }

    appInit();
    appRun();

    Board_initCfg     boardCfg;
    boardCfg = BOARD_INIT_PINMUX_CONFIG|BOARD_INIT_UART_STDIO;
    Board_init(boardCfg);
UART_printf("--------------------MCU1_0---------start-----------0\n");
    #if 1
    while(1)
    {
        appLogWaitMsecs(1000u);
        UART_printf("--------------------MCU1_0---------start-----------\n");
    }
    #else
    appDeInit();
    #endif
}

2.rebuild vision_apps and u-boot,  flashing SDcard. Open the serial terminal of MCU_UART0 and MAIN_UART0

3.MCU_UART0 first print "--------------------MCU1_0---------start-----------0\n" after MAIN_UART0 print "remoteproc remoteproc19: b10c000.txpru is available". It is too later. the log of MCU_UART0 as fellow:

--------------------MCU1_0---------start-----------0
--------------------MCU1_0---------start-----------
--------------------MCU1_0---------start-----------
--------------------MCU1_0---------start-----------
--------------------MCU1_0---------start-----------
--------------------MCU1_0---------start-----------
--------------------MCU1_0---------start-----------

4.And we try to add board_init and UART_printf before  "sciserverInitTask = TaskP_create(&appSciserverInit, &sciserverInitTaskParams);"

static void appMain(void* arg0, void* arg1)
{
    TaskP_Handle sciserverInitTask;
    TaskP_Params sciserverInitTaskParams;

    appUtilsTaskInit();

    appSciserverSciclientInit();

    Board_initCfg     boardCfg;
    boardCfg = BOARD_INIT_PINMUX_CONFIG|BOARD_INIT_UART_STDIO;
    Board_init(boardCfg);
UART_printf("--------------------MCU1_0---------start-----------0\n");

    /* Initialize SCI Client Server */
    TaskP_Params_init(&sciserverInitTaskParams);
    sciserverInitTaskParams.priority     = INIT_SCISERVER_TASK_PRI;
    sciserverInitTaskParams.stack        = gSciserverInitTskStack;
    sciserverInitTaskParams.stacksize    = sizeof (gSciserverInitTskStack);

    sciserverInitTask = TaskP_create(&appSciserverInit, &sciserverInitTaskParams);
    if(NULL == sciserverInitTask)
    {
        OS_stop();
    }

    appInit();
    appRun();
UART_printf("--------------------MCU1_0---------start-----------1\n");
    #if 1
    while(1)
    {
        appLogWaitMsecs(100u);
        UART_printf("--------------------MCU1_0---------start\n");
    }
    #else
    appDeInit();
    #endif
}

5.MCU_UART0 print "--------------------MCU1_0---------start-----------0" at once after power on. 

After MAIN_UART0 print "remoteproc remoteproc19: b10c000.txpru is available", MCU_UART0 outputs garbled characters.the log of MCU_UART0 as fellow:

--------------------MCU1_0---------start-----------0
(about 10s later, after MAIN_UART0 print "remoteproc remoteproc19: b10c000.txpru is available")
--------------------MCU1_0---------start-----------1
--------------------MCU1_0---------start-----------
--------------------MCU1_0---------start-----------
--------------------MCU1_0---------start-----------
--------------------MCU1_0---------start-----------
--------------------MCU1_0---------start-----------
--------------------MCU1_0---------start-----------

So we think appSciserverInit will causing obstruction, need  to wait remoteproc service on linux kernel MCU1_0 can continue to run.But we can not found where to cause obstruction in source of SDK and PSDK.

Regards,

Zhang

Hi Zhang

The delay in the UART print is probably because the appInit() calls appIpcInit which calls Ipc_isRemoteReady() and this function waits for Linux to be ready for establishing IPC communication with it.

On the garbled characters, this can happen if two cores are trying to use the same UART instance to print. I'd suggest either using different UARTs for different cores or using some other kind of signalling.

Regards

Karan

Hi,Karan

      On the garbled characters, we have removed MCU_UART0 in dtsi/dts of linux, it work ok.

      On the delay in the UART print, We tried to disable ENABLE_IPC_MCU1_0 in ti-processor-sdk-rtos-j721e-evm-08_06_00_12/vision_apps/platform/j721e/rtos/common/app_cfg.h, but it doesn't work. If we want to remove delay in the UART, How do we do that？

If add application before appSciserverInit and appInit, whether the startup of main domain will be affected?

Regards,

Zhang

Hi Zhang

davied zhang said:

On the delay in the UART print, We tried to disable ENABLE_IPC_MCU1_0 in ti-processor-sdk-rtos-j721e-evm-08_06_00_12/vision_apps/platform/j721e/rtos/common/app_cfg.h, but it doesn't work. If we want to remove delay in the UART, How do we do that？

Is there no requirement for IPC between MCU1_0 and A72?

Also, please share the steps followed for disabling IPC, what all did you recompile after this change?

davied zhang said:

If add application before appSciserverInit and appInit, whether the startup of main domain will be affected?

You just need the UART initialization to happen before you can print, everything else is optional.

Regards

Karan

Hi，Karan

      We are tring two different ways to do remove delay in the UART. The first is by disabling IPC,  the other is create a new task for our application and set priority higher than default task. Now we are testing the impact of both approaches.

      Thank you very much for your support along the way, you are the most serious and responsible engineer we have met in E2E.

Regards,

Zhang

Hi Zhang

davied zhang said:

We are tring two different ways to do remove delay in the UART. The first is by disabling IPC,  the other is create a new task for our application and set priority higher than default task. Now we are testing the impact of both approaches.

Understood, please provide the feedback once the results are completed.

Regards

Karan