[DRA829]Some questions about early can start

Hi Xie,

A few clarifications:

1. When you try to run the dio_app_mcu1_0_release.appimage what all files do you flash to the NOR flash?

2. Do you use CUST SBL or OSPI SBL?

Regards,

Karan

Hi,Karan

2.At the same time, I also compiled the dio_app_mcu1_0_release.appimage file, using the same method to download the inside with Nor flash, using OSPI mode to start, the file does not run normally, the phenomenon is that uart does not print any log。

In the second article, I said to use the same method, namely sbl_cust_img and dio_app_mcu1_0_release.appimage, use uart mode to download to nor flash, and then use OSPI startup mode, no successful startup。

The reason why I tried this is because our Bootloader does not use RTOS. And my current progress is that the partition of the *.lds file of our Bootloader project and the *.lds file of the can_boot_app_mcu_rtos_mcu1_0_release.appimage project are exactly the same, but our own bootloader cannot run normally, so I want to find this What is the difference between the two projects (can_boot_app_mcu_rtos_mcu1_0_release.appimage and dio_app_mcu1_0_release.appimage)?

Regards,

Xie

Hi，Karan

Thank you for your great help！

1.Then I still have a problem, that is, in the psdk_rtos_auto_j7_06_02_00_21/pdk/packages/ti/boot/sbl/sbl_component.mk file, I see that CUST defines the -DSBL_ENABLE_DEV_GRP_MCU compilation option, which can then be found in the psdk_rtos_auto_j7_06_02_00/21/ti/sbl/soc/k3/sbl_soc_cfg.h(line :407) see the #define SBL_DEVGRP       (DEVGRP_00) 

2.and in psdk_rtos_auto_j7_06_02_00_21/pdk/packages/ti/drv/sciclient/sciclient.h （line:243-258）We can see that different DEVGRP_XX are defined, what do these mean?

3.For example, if we only want to start MCU_1_0, and some peripherals in the main domain, such as MCAN, GPT, and several GPIOs, which parameter should we choose?

Regards,

Xie

Hi Xie,

Xie Linda said:

3.For example, if we only want to start MCU_1_0, and some peripherals in the main domain, such as MCAN, GPT, and several GPIOs, which parameter should we choose?

When you say you want yo start only MCU_1_0, is there a specific reason for that? Like an early use-case?

If not then you can just use the default SBL builds OSPI/MMCSD.

Xie Linda said:

1.Then I still have a problem, that is, in the psdk_rtos_auto_j7_06_02_00_21/pdk/packages/ti/boot/sbl/sbl_component.mk file, I see that CUST defines the -DSBL_ENABLE_DEV_GRP_MCU compilation option, which can then be found in the psdk_rtos_auto_j7_06_02_00/21/ti/sbl/soc/k3/sbl_soc_cfg.h(line :407) see the #define SBL_DEVGRP       (DEVGRP_00) 

2.and in psdk_rtos_auto_j7_06_02_00_21/pdk/packages/ti/drv/sciclient/sciclient.h （line:243-258）We can see that different DEVGRP_XX are defined, what do these mean?

I can check and get back on these details.

Regards,

Karan

Hi,Karan

Karan Saxena said:

When you say you want yo start only MCU_1_0, is there a specific reason for that? Like an early use-case?

We only want to start MCU1_0 because the start-up time for downloading DRA829 is a bit long. We are trying to shorten the start-up time as much as possible. All we want to use the functions of Earlycan. At the same time, we also use some peripherals of the Main domain.

And At present, my progress is:

1. Modify some configuration of the cust project. In sbl_soc_cgh.h (line: 630) I modified DEVGRP_00 to DEVGRP_ALL, so that he will initialize the entire DRA829, so it seems that the time has not been shortened much, so We want to initialize only part of the function.

2. Can we use the two functions sciclient_RM/sciclient_PM to customize some peripherals to initialize the Main domain?

3. When I modified sbl_soc_cgh.h (line: 630) and I changed DEVGRP_00 to DEVGRP_ALL, I used OSPI boot mode, using sbl_cust_img->sysfw->Bootloader (here I will initialize DDR4)->OwnApp, can start Success, so I was thinking that if we can customize some peripherals of the Main domain, this time can continue to be shortened

Regards,

Xie

Hi Xie,

Xie Linda said:

We only want to start MCU1_0 because the start-up time for downloading DRA829 is a bit long. We are trying to shorten the start-up time as much as possible. All we want to use the functions of Earlycan. At the same time, we also use some peripherals of the Main domain.

Now I get the end use-case. I would think that looking at psdk_rtos_auto_j7_06_02_00_21/mcusw/mcuss_demos/boot_app_mcu_rtos/ will give you some insight. You can look at the documentation at http://downloads.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/latest/exports/docs/mcusw/mcal_drv/docs/drv_docs/demo_boot_app_mcu_rtos_top.html

This app is loaded by the SBL and this in turn boots other cores.

Xie Linda said:

Modify some configuration of the cust project. In sbl_soc_cgh.h (line: 630) I modified DEVGRP_00 to DEVGRP_ALL, so that he will initialize the entire DRA829, so it seems that the time has not been shortened much, so We want to initialize only part of the function.

This is correct, so when the entire DRA829 will be initialized in terms of peripherals across MCU and MAIN domain then it will take more time.

Xie Linda said:

Can we use the two functions sciclient_RM/sciclient_PM to customize some peripherals to initialize the Main domain?

You can look at how this is being done in the board library. Refer Board_init() at psdk_rtos_auto_j7_06_02_00_21/pdk/packages/ti/board/src/j721e_evm/board_init.c for specific functions.

Xie Linda said:

When I modified sbl_soc_cgh.h (line: 630) and I changed DEVGRP_00 to DEVGRP_ALL, I used OSPI boot mode, using sbl_cust_img->sysfw->Bootloader (here I will initialize DDR4)->OwnApp, can start Success, so I was thinking that if we can customize some peripherals of the Main domain, this time can continue to be shortened

You use the board library as reference and the application I pointed to.

Some additional questions:

1. Are you trying XIP mode of execution?

2. If 1. is no, then what boot mode are you using?

3. The only task the app1 (SBL->sysfw->app1->app2) will do is load app2 and do some additional initiallizations?

Xie Linda said:

sbl_cust_img->sysfw->Bootloader (here I will initialize DDR4)->OwnApp

I'm considering that "Bootloader" you say is your bootloader/app1 (xer5f format) and the "OwnApp" is another app2 (xer5f format  EDIT: I meant *.appimage). Please correct me if this is wrong.

Regards,

Karan

Hi,Karan

[[quote user="Karan Saxena"]1. Are you trying XIP mode of execution?[/quote]

I haven't started debugging XIP mode yet, but I will start work in this area soon, because OSPI + XIP can achieve faster startup.So the boot mode I use now is OSPI mode, copy the code from Nor flash to DDR4 to execute the code.

Karan Saxena said:

I'm considering that "Bootloader" you say is your bootloader/app1 (xer5f format) and the "OwnApp" is another app2 (xer5f format). Please correct me if this is wrong.

Bootloader/app1(*.tiimage format) and the "OwnApp" is another app2 is HEX format,so the bootloader is a small piece of code to upgrade the app in the traditional sense. The MEX communication method is used to burn the HEX file into Nor flash.

At last, these days I will try gagin to sart in the early can mode.

Reagrds,

Xie

Hi Xie,

Xie Linda said:

Bootloader/app1(*.tiimage format) and the "OwnApp" is another app2 is HEX format,so the bootloader is a small piece of code to upgrade the app in the traditional sense. The MEX communication method is used to burn the HEX file into Nor flash.

So the SBL (provided by TI) is the *.tiimage, this would load an *.appimage - So I would have expected the app1 to be *.appimage (SBL -> sysfw -> app1 (your Bootloader) -> app2 (OwnApp) ). Is that not the case?

Regards,

Karan

Hi,Karan

Yes,you are right,Bootloader(app1) is *.appimage format, it's my fault.

And, we double check the flow is SBL(*.tiimage format)->sysfw->app1(*.appimage format)->app2(HEX format).

By the way,I want to ask another quention about MCAL-MCAN in SDK7.0, we can see the MCAN driver's AUTOSAR version is 4.2,1 or 4.3.1, 

Our AUTOSAR Davinci tool version is 4.2.1(for some reason we will not upgrade the version of this tool for the time being),When I was porting, I defined AUTOSAR_421 in the compile options, but some error messages will be reported when I compile，for example Can_GetControllerMode and Can_GetControllerErrorState are new function and will be reported error.

Does the SDK 7.0 code need to be modified elsewhere to adapt to AUTOSAR 4.2.1? SDK6.01 is AUTOSAR4.2.1 so we have been using version 6.01。

Regards,

Xie

Hi Xie,

Xie Linda said:

I want to ask another quention about MCAL-MCAN in SDK7.0, we can see the MCAN driver's AUTOSAR version is 4.2,1 or 4.3.1, 

The SDK 7.0 is 4.3.1 and has drivers and applications ported for that. Please raise a new query in case you need some support related to that.

Regards,

Karan

Hi,Karan

2.and in psdk_rtos_auto_j7_06_02_00_21/pdk/packages/ti/drv/sciclient/sciclient.h （line:243-258）We can see that different DEVGRP_XX are defined, what do these mean?

You have not answered this question for me，

Regards,

Xie