Not able to start mcu1_0 application binary from SBL in SD_Boot mode

jeyaseelan kirubaharan

Other Parts Discussed in Thread: DRA829

Hi All,

I am trying to start a demo application under mcusw_demos in psdk from SD card (Boot mode is set to SD_Boot in the boot dip switch) in mcu1_0 core. So built this application (can_profiling ) and renamed the binary generated (mcal_ti_rtos_aptiv_mcu1_0_debug_BE.appimage) from the build as "app". Then kept both tiboot3(SBL from default evm prebuilt image) and "app" binary in the boot partition.of the SD card.

I expect tiboot3.bin to start the app binary. But looks it is not starting the application binary on power up. A72 is properly booting the Linux. but not the mcu1_0 I have a few questions on the same.

1.Is the procedure i followed is correct or not for starting the mcu1_0 from SBL?

2.Since SBL also runs in mcu1_0 , is it possible for it to start another binary on the same core or it has to be built for other cores like mcu1_1 or main domain cores.?

3. Do i need to any device tree changes on linux side to reserve memory for r5f cores according to the memory map generated by the compiler or the linker.ld file?

4. Does the renamed image to "app" (mcal_ti_rtos_aptiv_mcu1_0_debug_BE.appimage) is the right one ?

*This application runs perfectly when i run the same through JTAG and could see the traces coming from one of the mcu domain uarts and the evm used is EVM_J721E( Soc DRA829).

Can you let me know the way of resolving this issue?

With regards,

Jeyaseelan

over 5 years ago

0 Karan Saxena over 5 years ago

TI__Guru* 77954 points

Hi Jeyaseelan,

I think I know the problem.

Take the binary from - psdk_rtos_auto_j7_06_02_00_21\mcusw\binary\can_profile_app\bin\j721e_evm\can_profile_app_mcu1_0_release.appimage and rename this to app.

Put the app, tiboot3.bin and sysfw.bin in the SD card. Change the boot pins for SD boot and you should be good to go.

The *BE* binary which you use is for a different use case.

jeyaseelan kirubaharan said:
2.Since SBL also runs in mcu1_0 , is it possible for it to start another binary on the same core or it has to be built for other cores like mcu1_1 or main domain cores.?

>> Yes it is possible, the SBL runs first and then resets the core and runs the app.

jeyaseelan kirubaharan said:
3. Do i need to any device tree changes on linux side to reserve memory for r5f cores according to the memory map generated by the compiler or the linker.ld file?

>> No, currently you use the standalone applivation with SBL and it would not need any other changes.

Let me know you are not able to solve this. This should be a quick setup issue to fix.

Regards,

Karan

0 jeyaseelan kirubaharan over 5 years ago in reply to Karan Saxena

Expert 1330 points

Hi Karan,

Thanks for your reply. One progress is , mcu1_0 is booting if i change the tiboot3.bin generated from from psdk

(pdk/packages/ti/boot/sbl/binary/j721e_evm/mmcsd/bin/sbl_mmcsd_img_mcu1_0_release.tiimage) but this image is not booting uboot of A72.

The old tiboot3.bin (provided in the default prebuilt images for evm ) does start u_boot in a72 but not the mcu1_0 image. I like to have the SBL boots both mcu1_0 and linux (later mcu2_1 as well) as well . Can you let me know what changes need to be done in SBL code to boot both the mcu1_0 / a72 -uboot images together?

With regards,

Jeyaseelan

0 Karan Saxena over 5 years ago in reply to jeyaseelan kirubaharan

TI__Guru* 77954 points

Hi Jeyaseelan,

I think there is a little confusion around the tiboot3.bin and what it does.

Let me try to explain-

1. The tiboot3.bin is the application which the ROM looks for - anything by the name tiboot3.bin, ROM will load it.

2. The pre-built image which you pointed to, is that the one which comes in the Linux SDK? If yes then that tiboot3.bin will load linux, provided you have the other images in place too.

3. The tiboot3.bin which you get from (pdk/packages/ti/boot/sbl/binary/j721e_evm/mmcsd/bin/sbl_mmcsd_img_mcu1_0_release.tiimage) is the one which is written to load the "app" (provided you have sysfw.bin too).

So loading the u-boot and "app" using the same tiboot3.bin is not the use-case. We can although use u-boot or R5 SPL to load the "app" as a firmware when we put it in the /lib/firmware of the linux filesystem. (this has a lot of other details to it, I can explain if you want).

Regards,

Karan

0 jeyaseelan kirubaharan over 5 years ago in reply to Karan Saxena

Expert 1330 points

Hi Karan,

Our use case is we need all mcu1_0,mcu2_0/1 and a72 to boot at once ,along with DSMC firmware from SD now and later from oSPI or other flash device.

So what is the best way to do it .Our thought was based on the the attached diagram where R5_SPL/SBL boots all core images. Kindly share the links or details on achieving the above use case.

With regards,

Jeyaseelan

EDIT by Karan (TI) : deleted the bootflow diagram (as that was NDA info)

0 Karan Saxena over 5 years ago in reply to jeyaseelan kirubaharan

TI__Guru* 77954 points

Hi Jeyaseelan,

jeyaseelan kirubaharan said:
Our thought was based on the the attached diagram where R5_SPL/SBL boots all core images. Kindly share the links or details on

The R5 SPL and u-boot/kernel can/do load the remote cores. Please look at https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-jacinto7/latest/exports/docs/linux/Foundational_Components_U-Boot.html#remoteproc for details on how to load using u-boot.

So mcu1_0 and mcu2_0 will be loaded by R5 SPL and mcu2_1 can be loaded by either u-boot or kernel (the mapping is for R5 SPL is hard coded, i.e. it can will load only mcu1_0 and mcu2_0 provided the applications/firmwares to be loaded on them are present in the /lib/firmware in the filesystem by an "appropriate name")

So you can load any application using the combination of R5 SPL + u-boot/kernel but one thing to note is that not all applications can co-exist with Linux. That means that the application needs to be a "cooperative" application to co-exist with linux. It should have a certain memory map and should not try to use resources used by linux. That being said, the can_profile_app you are trying to load is intended for standalone testing/profiling of CAN driver and is not verified to run with linux. There is a plan to support this application running with Linux in near future, and I can update you with that once completed.

Regards,

Karan

0 jeyaseelan kirubaharan over 5 years ago in reply to Karan Saxena

Expert 1330 points

Hi Kiran,

A.Regarding booting from R5-SPL

As per the above link shared, R5 compilation should be done with the below commands in the linux sdk to produce the r5 out binaries in out directory.

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- j721e_evm_r5_defconfig O=<output directory>/r5
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=<output directory>/r5

1.But ,j721e_evm_r5_defconfig is not present in the available linux sdk (Have attached list of defconfig files present).So where to take the files from ,also if an changes are req?

2.Which source files or config files needed to be changed to alter the behaviour of R5-SPL(sysfw.itb) to load both R5F and (ATF-OPTEE-> U_boot)

3.As per the boot diagram above R5_SPL can boot R5F0 and A72 as well but your comment says it can boot only mcu0_0/1 only.Share your comments

B.Regarding U_Boot

1. We need to load the R5F binaries in normal boot (without stopping at u_boot) , and not through command line.Kindly let us know how to do it

2. But still executed the commands in command line for starting the rproc, but getting the below error

=> rproc init 0
=> load mmc 1:2 0x90000000 /lib/firmware/mcal_ti_rtos_aptiv_mcu1_0_debug.rprc
204076 bytes read in 16 ms (12.2 MiB/s)
=> rproc load 0 0x90000000 0x3E800
Invalid op: Trying to load/start on already running core 1
Load Remote Processor 0 with data@addr=0x90000000 256000 bytes: Failed!
=>
Invalid op: Trying to load/start on already running core 1
Load Remote Processor 0 with data@addr=0x90000000 256000 bytes: Failed!
=> rproc list
0 - Name:'r5f@41000000' type:'internal memory mapped' supports: load start stop reset

Can you share your comments on the same?

With regards,

Jeyaseelan

0 Karan Saxena over 5 years ago in reply to jeyaseelan kirubaharan

TI__Guru* 77954 points

Hi Jeyaseelan,

jeyaseelan kirubaharan said:
As per the boot diagram above R5_SPL can boot R5F0 and A72 as well but your comment says it can boot only mcu0_0/1 only.Share your comments

I was talking about the remote core firmware load. It will load firmwares on to mcu1_0 and mcu2_0. u-boot will be loaded by it.

If you need to load your firmware by R5 SPL, you need to place it in /lib/firmware directory by a specific name. R5 SPL will look for j7-mcu-r5f0_0-fw for mcu1_0 and j7-main-r5f0_0-fw for mcu2_0. No change needed to R5 SPL to load these.

If you want to load the firmware to other cores using u-boot, you can follow the link - https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-jacinto7/latest/exports/docs/linux/Foundational_Components_U-Boot.html#remoteproc

If you don't want to load the firmware from R5 SPL to mcu1_0 and mcu2_0, just don't have it by the names mentioned above and SPL will not load them and then you can use the same u-boot method to load these too.

jeyaseelan kirubaharan said:
We need to load the R5F binaries in normal boot (without stopping at u_boot) , and not through command line.Kindly let us know how to do it

You need to modify some environment variables for that.

For the first time, halt at u-boot and run "print". This will list the environment variables. You should have an environment variable by the name "rproc_fw_binaries" and "dorprocboot". Modify the "rproc_fw_binaries" by the following command:

setenv rproc_fw_binaries '<core_id> <firmware_path>'

#core_id can be 0:8
#firmware_path is something like /lib/firmware/j7-main_r5f0_1-fw

Next step is to change the "dorprocboot" to 1 by the following and then saving the environment.

setenv dorprocboot 0
saveenv

Reboot and the firmware(s) you listed will be booted by u-boot.

jeyaseelan kirubaharan said:
But still executed the commands in command line for starting the rproc, but getting the below error

As mentioned before, if you are using the unchanged filesystem, there are applications linked to the j7-mcu-r5f0_0-fw and hence the R5 SPL is loading them and starting the core. When you try to load mcu1_0 with the application it is already running, and you can not load a running core.

You can either stop the core by running "rproc stop 0" after the "rproc init" and then load and start the core.

But I see one more problem here, you should be loading the *.xer5f image (i.e. the elf format), you are loading the *.rprc (this might not work).

I mentioned before that I was working on loading the can_profile_app from u-boot. I was able to make modifications to the app and make it work with linux (both the mcu1_0 app and mcu2_1 app). Let me know if you need that, I can send you the patch set for that.

Regards,

Karan

0 jeyaseelan kirubaharan over 5 years ago in reply to Karan Saxena

Expert 1330 points

Hi Karan,

Thanks for the detailed answer . I will check on them and provide feedback and share to you in couple of days. Meantime as mentioned kindly share the can_profiling_app patches needed for to run along with linux .

With regards,

Jeyaseelan

0 jeyaseelan kirubaharan over 5 years ago in reply to jeyaseelan kirubaharan

Expert 1330 points

Hi Kiran,

I tried running the methods you have mentioned for both R5-SPL and u_boot loading of mcu1_0 core with the custom_app(the one works in SBL) based on can_profiling demo app

R5_SPL:

1.Rename the mcal_ti_rtos_aptiv_mcu1_0_debug.xer5f file to "j7-mcu-r5f0_0-fw" and kept the renamed image in /lib/firmware/ path.

2.Powered on board and found no UART traces in the mcu debug port

Looks R5_SPL is not booting the binary

U_Boot - Method-1:

1. Renamed the binary to "j7-mcu-r5f0_0-fw_jeya"

2. set the environmental variable rproc_fw_binaries to below

rproc_fw_binaries=rproc_fw_bbinaries=0 /lib/firmware/j7-mcu-r5f0_1-fw_jeya 4 /lib/firmware/j7-main-r5f1_0-fw 6 /lib/firmware/j7-c66_0-fw 7 /lib/firmware/j7-c66_1-fw 8 /lib/firmware/j7-c71_0-fw 0

3.setenv dorprocboot to 1

4.saveenv

5.restart the board

Looks u_boot is not the mcu1_0 binary

Then i tried another method with symbolic links to the actual .xerf image after copying it to target, as i saw other R5F binaries are used with symbolic links only by default (attached the log snippet of it )

U_Boot-Method-2:

1.Transferred the mcal_ti_rtos_aptiv_mcu1_0_debug.xer5f binary to /lib/firmware/ folder of rootfs

2.Created symbolic label to this binary by same name "j7-mcu-r5f0_0-fw_jeya" using ln command (ln -s j7-mcu-r5f0_0-fw_jeya /lib/firmware/mcal_ti_rtos_aptiv_mcu1_0_debug.xer5f)

3.Then followed steps 2,3,4,5 of Method 1

Still the image is not booting in mcu1_0 . I have the below questions

1.Is it because of the patch you mentioned in the previous post has to be applied to the application?

2.Is the procedure followed for R5-SPL loading is correct , or do i have to use symbolic link as other default R5F images present in default ?

3. For U_boot booting , which method i have to follow , method-1 or Method-2 ?

Kindly provide answer for the same.

With regards,

Jeyaseelan

0 Karan Saxena over 5 years ago in reply to jeyaseelan kirubaharan

TI__Guru* 77954 points

Hi Jeyaseelan,

jeyaseelan kirubaharan said:
R5_SPL:

When an application is loaded by R5 SPL it should have a proper memory map, by proper mem map I mean that it should 1. Not use ATCM (as ATCM is disabled in R5 SPL) and 2. Not use memory/resources used by either R5 SPL, u-boot or kernel. You should also see a print saying "Remoteproc <core_id> started successfully" in case the loading is successful.

If your application doesn't load we need to check points 1. and 2.

jeyaseelan kirubaharan said:
U_Boot - Method-1:

Now in u-boot the ATCM is enabled, so to load your firmware from u-boot you need to have reset vectors in ATCM (and not BTCM or any other place).

One problem I see with your u-boot env variable rproc_fw_binaries is that you I think have a wrong name for the binary (j7-mcu-r5f0_1-fw_jeya instead of j7-mcu-r5f0_0-fw_jeya as you mentioned in 1.). The core_id's are as follows:

0 - Name:'r5f@41000000' - mcu1_0
1 - Name:'r5f@41400000' - mcu1_1
2 - Name:'r5f@5c00000' - mcu2_0
3 - Name:'r5f@5d00000' - mcu2_1
4 - Name:'r5f@5e00000' - mcu3_0
5 - Name:'r5f@5f00000' - mcu3_1

jeyaseelan kirubaharan said:

Still the image is not booting in mcu1_0 . I have the below questions

1.Is it because of the patch you mentioned in the previous post has to be applied to the application?

2.Is the procedure followed for R5-SPL loading is correct , or do i have to use symbolic link as other default R5F images present in default ?

3. For U_boot booting , which method i have to follow , method-1 or Method-2 ?

1. Modifications need to happen to applications not tested in an integrated linux environment for them to work this way. Almost always we can expect the standalone applications to NOT work straight away due to constrains I mentioned before. The firmwares already there can be treated as reference to develop applications/modify applications to work that way. The reason for this is that the standalone tests/examples/demos are meant for driver testing and they are generally supported with CCS or SBL boot flow, the conditions I mentioned above are no cares for such scenarios.

The patch I mentioned enables the can_profile_app (on mcu2_1) to work with Linux. can_profile_app (on mcu1_0) can work out of the box with linux. Just load it using u-boot (and not the R5 SPL).

2. The procedure is correct, a symbolic link or a file rename both work. It is because of other reasons that the load may fail.

3. I think both just have one difference where you either rename the file or link the file. I would suggest keep the environment same and just link different files.

On a side note, in case you want the default environment you can run the following ffrom the u-boot prompt:

env default –a –f
saveenv

Regards,

Karan

0 jeyaseelan kirubaharan over 5 years ago in reply to Karan Saxena

Expert 1330 points

Hi Karan,

Thanks for your reply. Have the below points regarding further boot testing of R5F

1. Actually i corrected the file_name change (to j7-mcu-r5f0_0-fw_jeya) and tried to run the can_app_profiling binary in mcu1_0 domain both from R5_SPL and using U_Boot env variables. Looks R5_SPL could start this binary and run for sometime and then after sometime there is a conflict is occurred with A72. (stops r5f prints and prints traces from A72). But U_boot not starting the binary at all even though file is properly read from SD card , refer below logs.

Also i tried to start the core manually from u_boot prompt using the command "remote proc start 0" at the u_boot terminal , but getting error " secondary core is not probed in this cluster " .Looks main domain can not start the mcu domain core as other cores in the main domain start properly using manual commands from u_boot. Below is the log snippet

Load Remote Processor 0 with data@addr=0x80080000 3951452 bytes: Success!

86984 bytes read in 7 ms (11.9 MiB/s)
Load Remote Processor 4 with data@addr=0x80080000 86984 bytes: Success!
147084 bytes read in 7 ms (20 MiB/s)

=> rproc start 0
Secondary core is not probed in this cluster
Operation Failed with error (-11)
=> rproc start 4
=> rproc start 6
=> rproc start 7
=> rproc start 8
=> rproc start 0
Secondary core is not probed in this cluster

2. Basically we want to run our application on(mcu1_0 |& mcu2_1) to run along with Linux apps with IPC in between the cores. R5F cores are used to interface with CAN controllers . So we may need a proper demo application which should run along with the linux both from mcu1_0 and main domain (mcu2_1)with proper IPC

3. I referred the linker file of CAN_Profiling_app which is mainly using the MCU1_0_SRAM for most of its section. This area is hardly 376KB. Our application may exceed this limit later. So it may need to use the external DDR area as well .Looks ATCM is not utilized here. What changes are required to include this app to use the external DDR memory without conflict with Linux. As per the kernel prints i see,,for R5F memory is reserved from 0x A0000000 . Is this the place to keep DDR area in the .ld file ?

Below is the memory utilized for this application as per the generated map file.

MEMORY CONFIGURATION

name origin length used unused attr fill
---------------------- -------- --------- -------- -------- ---- --------
MCU0_R5F_TCMA_SBL_RSV 00000000 00000100 00000000 00000100 X
MCU0_R5F_TCMA 00000100 00007f00 00000000 00007f00 X
MCU0_R5F0_ATCM 41000000 00008000 00000000 00008000 RWIX
MCU0_R5F0_BTCM 41010000 00008000 00000040 00007fc0 RWIX
MCU0_R5F1_ATCM 41400000 00008000 00000000 00008000 RWIX
MCU0_R5F1_BTCM 41410000 00008000 00000000 00008000 RWIX
VECTORS 41c3c100 00001000 00000000 00001000 X
RESET_VECTORS 41c40000 00000100 00000000 00000100 X
MCU1_0_MSRAM 41c40100 0005bf00 00059aa0 00002460 RWIX
MSMC3_ARM_FW 70000000 00040000 00000000 00040000 RWIX
MSMC3 70040000 007b0000 00000000 007b0000 RWIX
MSMC3_DMSC_FW 707f0000 00010000 00000000 00010000 RWIX
DDR0 80000000 08000000 00000000 08000000 RWIX
DDR0_MCU_1_0 97000000 01000000 00000000 01000000 RWIX

Kindly provide your answers for the same so that i can close this thread for application loading , as it loads from R5SPL . Points 2 & 3 ,if needed i can open a separate thread for further clarifictions.

With regards,

Jeyaseelan

0 jeyaseelan kirubaharan over 5 years ago in reply to Karan Saxena

Expert 1330 points

Hi ,

My previous reply to this post is not appearing. How long it takes for moderation to complete. Otherwise i can re post my complete report one more time.

With regards,

Jeyaseelan

0 Karan Saxena over 5 years ago in reply to jeyaseelan kirubaharan

TI__Guru* 77954 points

Hi Jeyaseelan,

I see two replies from you including the once I'm replying to now. If there was something else, please post that again.

Regards,

Karan

0 jeyaseelan kirubaharan over 5 years ago in reply to Karan Saxena

Expert 1330 points

Hi Karan,

The last reply i meant to the Admin as i did not see my post listed in forum for sometime. Kindly go through the last but one reply of mine and clarify those points.

With regards,

Jeyaseelan

0 Karan Saxena over 5 years ago in reply to jeyaseelan kirubaharan

TI__Guru* 77954 points

Hi Jeyaseelan,

jeyaseelan kirubaharan said:
Actually i corrected the file_name change (to j7-mcu-r5f0_0-fw_jeya) and tried to run the can_app_profiling binary in mcu1_0 domain both from R5_SPL and using U_Boot env variables. Looks R5_SPL could start this binary and run for sometime and then after sometime there is a conflict is occurred with A72. (stops r5f prints and prints traces from A72). But U_boot not starting the binary at all even though file is properly read from SD card , refer below logs.

I don't see any logs attached, can you please check? The conflict is most likely UART, both the firmware and Linux are pushing data to the MAIN UART instance 0.

jeyaseelan kirubaharan said:
Also i tried to start the core manually from u_boot prompt using the command "remote proc start 0" at the u_boot terminal , but getting error " secondary core is not probed in this cluster " .Looks main domain can not start the mcu domain core as other cores in the main domain start properly using manual commands from u_boot. Below is the log snippet

Did you disable the load of rproc id 0 i.e. MCU R5F0_0 in the R5 SPL?

Also, I think you missed the rproc init.

You need to follow the following:

# At u-boot prompt, run the following
Hit any key to stop autoboot:  0
=>
=> rproc init
=>
=> rproc list
0 - Name:'r5f@41000000' type:'internal memory mapped' supports: load start stop reset
1 - Name:'r5f@41400000' type:'internal memory mapped' supports: load start stop reset
2 - Name:'r5f@5c00000' type:'internal memory mapped' supports: load start stop reset
3 - Name:'r5f@5d00000' type:'internal memory mapped' supports: load start stop reset
4 - Name:'r5f@5e00000' type:'internal memory mapped' supports: load start stop reset
5 - Name:'r5f@5f00000' type:'internal memory mapped' supports: load start stop reset
6 - Name:'dsp@4d80800000' type:'internal memory mapped' supports: load start stop reset
7 - Name:'dsp@4d81800000' type:'internal memory mapped' supports: load start stop reset
8 - Name:'dsp@64800000' type:'internal memory mapped' supports: load start stop reset
=>
=> load mmc 1:2 0x90000000 /lib/firmware/j7-main-r5f0_1-fw
2600844 bytes read in 60 ms (41.3 MiB/s)
=> rproc load 3 0x90000000 0x${filesize}
Load Remote Processor 3 with data@addr=0x90000000 2600844 bytes: Success!
=>
=> boot

You should be able to load any core from here, provided you load and start the core0 of the Subsystem before core1.

jeyaseelan kirubaharan said:
Basically we want to run our application on(mcu1_0 |& mcu2_1) to run along with Linux apps with IPC in between the cores. R5F cores are used to interface with CAN controllers . So we may need a proper demo application which should run along with the linux both from mcu1_0 and main domain (mcu2_1)with proper IPC

We had validated the SDK6.02 can_profile_app with patches on top to run on mcu1_0 and mcu2_1. You can refer - https://e2e.ti.com/support/processors/f/791/p/906858/3371498#3371498 for the patches and some other detials.

jeyaseelan kirubaharan said:
I referred the linker file of CAN_Profiling_app which is mainly using the MCU1_0_SRAM for most of its section. This area is hardly 376KB. Our application may exceed this limit later. So it may need to use the external DDR area as well .Looks ATCM is not utilized here. What changes are required to include this app to use the external DDR memory without conflict with Linux. As per the kernel prints i see,,for R5F memory is reserved from 0x A0000000 . Is this the place to keep DDR area in the .ld file ?

Yes, you need to reserve the space in the DDR by mentioning in the DTB and then you can use that carved out section of the DDR from your application. Please refer the patch 0003 in the patchset - you can use the following.

+ /* DDR region carved out from kernel accessible DDR space, for MCU2_1 */
+ DDR0_MCU_2_1 (RWIX) : origin=0xA3100400 length=0x100000

I would recommend you run the existing apps (with patches on SDK 6.02) and make yourself comfortable. Then you can either build your applications on top of those apps or write your own applications.

Regards,

Karan

0 jeyaseelan kirubaharan over 5 years ago in reply to Karan Saxena

Expert 1330 points

Hi Karan,

Please find comments for your questions

1. I don't see any logs attached, can you please check?

Load Remote Processor 0 with data@addr=0x80080000 3951452 bytes: Success!

86984 bytes read in 7 ms (11.9 MiB/s)
Load Remote Processor 4 with data@addr=0x80080000 86984 bytes: Success!
147084 bytes read in 7 ms (20 MiB/s)

2.The conflict is most likely UART, both the firmware and Linux are pushing data to the MAIN UART instance 0.

May be ,, But mcu1_0 uses debug uart in mcu_domain (/dev/ttyUSB1) and the other ttyUSB0 is reserved for DMSC and Linux suppose to use only the main domain debug uart (/dev/ttyUSB2 -onwards). Not sure why linux pushes the data to mcu domain debug port

3.Did you disable the load of rproc id 0 i.e. MCU R5F0_0 in the R5 SPL?

I did not do any code change in the R5_SPL .But i removed the binary file of j7-mcu-r5f0_0-fw from the /lib/firmware path so that R5_SPL do not find the file when it searches for it. Let me know any changes to be done ,if so on which file.

4.Also, I think you missed the rproc init

I re-run the procedure once again which i have listed below for core-3 and core-0 . core-3 starts successfully but not core - 0 from u_boot prompt

=> rproc init 3
=> load mmc 1:2 0x90000000 /lib/firmware/j7-main-r5f0_0-fw
735916 bytes read in 28 ms (25.1 MiB/s)
=> rproc stop 3
=> rproc load 3 0x90000000 0x${filesize}
Load Remote Processor 3 with data@addr=0x90000000 735916 bytes: Success!
=> rproc start 3
=>

=> rproc init 0

=> load mmc 1:2 0x90000000 /lib/firmware/j7-mcu-r5f0_0-fw_jeya
735916 bytes read in 28 ms (25.1 MiB/s)

=> rproc load 0 0x90000000 0x${filesize}
Load Remote Processor 0 with data@addr=0x90000000 3951460 bytes: Failed!
=> rproc start

=> rproc stop 0 (Here this reset the complete core)
"Synchronous Abort" handler, esr 0x8600000d
elr: ffffffff80914000 lr : 0000000080830ec0 (reloc)
elr: 0000000000000000 lr : 00000000fff1cec0
x0 : 0000000000000000 x1 : 0000000000000000
x2 : 0000000000000000 x3 : 0000000000000008
x4 : 0000000000000000 x5 : 0000000032c0d004
x6 : 00000000fdec09e0 x7 : 000000000000000a
x8 : 0000000000000001 x9 : 0000000000000008
x10: 00000000ffffffd0 x11: 0000000000000006
x12: 000000000001869f x13: 000000000000000d
x14: 0000000000000000 x15: 00000000fffffffe
x16: 000000000000fffc x17: 0000000000000000
x18: 00000000fdecbde8 x19: 0000000000000001
x20: 0000000000000000 x21: 00000000fded8140
x22: 00000000fdedbd50 x23: 00000000fffd2180
x24: 0000000000000003 x25: 0000000000000000
x26: 0000000000000000 x27: 0000000000000000
x28: 00000000fdedb000 x29: 00000000fdec09f0

Resetting CPU ...

From the experiment i feel U_boot can start only main domain cores (from core 2 on wards) and R5_SPL starts both (0 &1) .Even the boot flow chart which i have attached in the beginning of this thread show ,u_boot starts the main_cores and not the mcu cores.Let me know if i miss anything otherwise.

5.Regarding memory space adjustments of can_profiling_app to external DDR ,i will try the same way as per the patches which you have provided and share you the feedback once completed.

Thanks for all the support.

With regards,

Jeyaseelan

0 jeyaseelan kirubaharan over 5 years ago in reply to jeyaseelan kirubaharan

Expert 1330 points

Hi Karan ,

If possible can you look into the below issue as well which is related to mcu2_1 uart that you have mentioned in one of the patches.

https://e2e.ti.com/support/tools/ccs/f/81/p/907950/3378080#3378080

With regards,

Jeyaseelan

0 Karan Saxena over 5 years ago in reply to jeyaseelan kirubaharan

TI__Guru* 77954 points

Hi Jeyaseelan,

jeyaseelan kirubaharan said:
I did not do any code change in the R5_SPL .But i removed the binary file of j7-mcu-r5f0_0-fw from the /lib/firmware path so that R5_SPL do not find the file when it searches for it. Let me know any changes to be done ,if so on which file.

No code changes in the SPL is needed. R5 SPL looks for names j7-mcu-r5f0_0-fw (to load on mcu1_0) and j7-main-r5f0_0-fw (to load on mcu2_0) in /lib/firmware and if it doesn't find these files it just skips the firmware load. So to disable the load you just need to delete/rename the files in the /lib/firmware.

jeyaseelan kirubaharan said:
I re-run the procedure once again which i have listed below for core-3 and core-0 . core-3 starts successfully but not core - 0 from u_boot prompt

I think there is a little bit of confusion here.

Core ID 0 -> mcu1_0

Core ID 1 -> mcu1_1

Core ID 2 -> mcu2_0

Core ID 3 -> mcu2_1

I see you loading j7-main-r5f0_0-fw on to mcu2_1. j7-main-r5f0_0-fw will be for mcu2_0. It might load successfully but it would fail in the startup.

jeyaseelan kirubaharan said:
core-3 starts successfully but not core - 0 from u_boot prompt

Core 0 as in mcu1_0 will not start as the application has it's reset vectors in BTCM (Reset vectors in BTCM is needed to load from R5 SPL while Reset Vectors in ATCM is needed to load from u-boot)

jeyaseelan kirubaharan said:
From the experiment i feel U_boot can start only main domain cores (from core 2 on wards) and R5_SPL starts both (0 &1) .Even the boot flow chart which i have attached in the beginning of this thread show ,u_boot starts the main_cores and not the mcu cores.Let me know if i miss anything otherwise.

By default the firmwares are like that mcu1_0 and mcu2_0 (i.e. the Core 0s of both MCU and MAIN R5Fs) are loaded by R5 SPL and Core1s i.e mcu1_1 and mcu2_1 (core1 of both MCU and MAIN r5fs) are loaded by U-boot. But in essence u-boot can load any firmware which has reset vectors in ATCM (provided there are no other conflicts)

I see you marked a reply as "Verify answer", can you please reiterate what else is needed.

This might need a little bit more explaination, please let me know if you want to understand more and I can help.

I have written an FAQ and you can see that, that might give you a better insight.

FAQ - https://e2e.ti.com/support/processors/f/791/t/915474

Regards,

Karan

0 jeyaseelan kirubaharan over 5 years ago in reply to Karan Saxena

Expert 1330 points

Hi Karan,

Thanks for the detailed info and shared my comments below of your observations.

1. I see you loading j7-main-r5f0_0-fw on to mcu2_1. j7-main-r5f0_0-fw will be for mcu2_0. It might load successfully but it would fail in the startup.

Yes it looks a mistake . I should have loaded "j7-main-r5f0_1-fw" for mcu2_1(Core id-3)

2 Core 0 as in mcu1_0 will not start as the application has it's reset vectors in BTCM (Reset vectors in BTCM is needed to load from R5 SPL while Reset Vectors in ATCM is needed to load from u-boot)

Yes, as discussed before mcu1_0 is loaded properly from R5_SPL as it does not use ATCM

3.By default the firmwares are like that mcu1_0 and mcu2_0 (i.e. the Core 0s of both MCU and MAIN R5Fs) are loaded by R5 SPL and Core1s i.e mcu1_1 and mcu2_1 (core1 of both MCU and MAIN r5fs) are loaded by U-boot.

Got it. As mentioned before by your comments , mcu1_0 and mcu2_0 does not need ATCM ,so it can be loaded by R5_SPL .If needed by U_boot , then reset vector section should be changed to ATCM. So any core firmware can be loaded either by R5_SPL or U_boot based on the reset vector memory allocation. I will try this change when i do changes for DDR. Will post on this same thread if observe any conflicts.

With regards,

Jeyaseelan

0 Karan Saxena over 5 years ago in reply to jeyaseelan kirubaharan

TI__Guru* 77954 points

Hi Jayaseelan,

jeyaseelan kirubaharan said:
Got it. As mentioned before by your comments , mcu1_0 and mcu2_0 does not need ATCM ,so it can be loaded by R5_SPL .If needed by U_boot , then reset vector section should be changed to ATCM. So any core firmware can be loaded either by R5_SPL or U_boot based on the reset vector memory allocation. I will try this change when i do changes for DDR. Will post on this same thread if observe any conflicts.

Slight corrections to this.

jeyaseelan kirubaharan said:
As mentioned before by your comments , mcu1_0 and mcu2_0 does not need ATCM ,so it can be loaded by R5_SPL

The requirement is on the firmware not the core. So a firmware which is using ATCM can not be loaded from R5 SPL as during that phase when R5 SPL is executing, the ATCM memory of the R5 core is not enabled.

To add some details - It is not specifically disabled. Default POR on all clusters is ATCM disabled. ATCM is enabled explicitly on all clusters in DTS to maximize the TCMs. R5 SPL is booted by ROM without turning on ATCM, and it does a branch only boot to application firmware, so ATCM remains disabled.

jeyaseelan kirubaharan said:
If needed by U_boot , then reset vector section should be changed to ATCM.

In R5F, by design, if ATCM is enabled then we need to boot from there. And as in u-boot we have ATCM enabled, we need to boot from there (have reset vectors in ATCM).

jeyaseelan kirubaharan said:
So any core firmware can be loaded either by R5_SPL

Not exactly. In the R5 SPL code we only try to look for j7-mcu-r5f0_0-fw and j7-mcu-r5f0_0-fw and load mcu1_0 and mcu2_0 only. We need to modify the SPL code to load other firmwares.

jeyaseelan kirubaharan said:
U_boot based on the reset vector memory allocation

Yes, we can load any core from u-boot. Provided not loaded by R5 SPL, if loaded by SPL we need to do a rproc stop and then load.

Regards,

Karan

0 Karan Saxena over 5 years ago in reply to Karan Saxena

TI__Guru* 77954 points

Hi Jeyaseelan,

Let me know, I can explain all this on a short call. This can be done before you drill deep on the problem, this way you will have a better understanding too.

Regards,

Karan

0 Karan Saxena over 5 years ago in reply to Karan Saxena

TI__Guru* 77954 points

Hi Jeyaseelan,

I've deleted the post with your email and personal mobile number, we don't encourage putting personal details on the public forum.

And I see you were able to resolve the issue, let me know in case you have further questions and then we can set-up some time for discussion.

Regards,

Karan

Processors

Processors forum

Not able to start mcu1_0 application binary from SBL in SD_Boot mode