TDA4VM: Arago taking 2 minutes to be loaded

Hi,

May I know what is the procedure you are following to load vision_apps using SBL?

Regards,
Nikhil

This iwaiting s happening before load vision_apps. System is booting from SD card, using SBL compiled for HLOs ("make sbl_mmcsd_img_hlos") and prepared one app multiimage with CAN_profile to be running in MC1_0. DTB in linux rootfs is changed to disable MCAN_0 and MCU_UART avoiding conflicts.

With all changes applied, CAN_profile (lighly adapted and recompiled) works without issues,

Arago is finally executed (after 2 minutes), and I can launch "source ./vision_apps_init.sh":

And after launcheing some vision apps, I get segmetation faults (not present when I use SPL booting):

BR

Hi,

From the screenshot shared for the logs of "./vision_apps_init.sh", I see that the MCU2_0 and MCU2_1 logs are waiting for HLOS to be ready and is stuck there. 

This could be the reason why you are seeing the errors while running the application.

Could you confirm if you have integrated vision_apps dts changes and rtos_memory_map changes in Linux with the common proc board dtsi file?

Since I believe we use only common-proc-board.dtb file here, these changes should be present.

Also, regarding your usecase, is it possible to use the combined_appimage tool in SBL instead of the boot app?

If you are not looking for an early can response, I would suggest you use the combined_appimage tool instead of the boot app.

Regards,
Nikhil

Hello.

About "

Nikhil Dasan said:

Could you confirm if you have integrated vision_apps dts changes and rtos_memory_map changes in Linux with the common proc board dtsi file?

This is done automatically by "make linux_fs_install_sd", is not? I know that some info is created for uboot_env, pointting to different dtb present in rootfs/boot

But not clear about rtos_memory_map....

Nikhil Dasan said:

Since I believe we use only common-proc-board.dtb file here, these changes should be present.

Then do you suspect that common-proc-board.dtb is not changed in my sd card and should after running "make linux_fs_install_sd"?

Nikhil Dasan said:

Also, regarding your usecase, is it possible to use the combined_appimage tool in SBL instead of the boot app?

This is what I am using, app generated in combined_appimage.

I attach tiboot3.bin (SBL for HLOS created form pdk_8_04) and app (combined_appimage with CAN_profile demo adaped and ATF OPTEE SPL etc needed for A72):

Hi,

Could you please share the config.mk file in combined_appimage tool?

Here, have you made the relevant changes such as providing the path to common_proc.dtb and adding IMG1, IMG2 etc with binaries of MCU1_0, MCU2_0 etc?

If yes, since you have pointed here only to common_proc.dtb, it cannot fetch vision_apps.dtbo. 

In this case, you would have to integrate the contents of vision_apps.dtsi and rtos_memory_map.dtsi into common_proc.dtsi in Linux SDK and build a vision_app integrated common_proc.dtb.

This way the reserved section for vision_apps could be reflected on the RTOS side. 

Could you also share the full logs (linux + RTOS ) in a text file ?

Regards,
Nikhil

Hello Nikhil

Nikhil Dasan said:

Could you please share the config.mk file in combined_appimage tool?

#################################################################################
# Path Configuration
#################################################################################
# Get directory of makefile (RELATIVE)
mkfile_path := $(abspath $(lastword $(MAKEFILE_LIST)))
mkfile_dir := $(dir $(mkfile_path))

# Setup build variables relative to makefile folder
ifeq ($(SDK_INSTALL_PATH),)
PDK_INSTALL_PATH ?= $(abspath $(mkfile_dir)../../../../..)
SDK_INSTALL_PATH ?= $(abspath $(PDK_INSTALL_PATH)../../..)
else
PDK_INSTALL_PATH ?= $(mkfile_dir)../../../../..
endif

GCC_ARCH64_BIN_PREFIX ?= aarch64-none-elf

include $(PDK_INSTALL_PATH)/ti/build/Rules.make

#################################################################################
# General Configuration
#################################################################################
# Output Configuration
#
# OUT_DIR defines the output directory for the combined appimage.
# OUT_IMG defines the name of the combined appimage
#
OUT_DIR ?= $(mkfile_dir)bin/$(BOARD)
OUT_IMG ?= combined.appimage

# Raw Binary Extensions
#
# Each of the extensions in this list will be treated as a binary blob, thus
# indicating that these formats must be converted into ELF prior to RPRC
# generation. ALL OTHER EXTENSIONS WILL BE CONSIDERED AS EXECUTABLE.
#
RAW_EXTENSIONS ?= .bin .dtb

# Consider extensionless files as raw binary or executable?
#
# Some files do not have extensions, we can either consider them as raw
# binary or as executables, but not as both.
#
# Choices:
# - raw: raw binary
# - exe: executable
#
EXTENSIONLESS_TYPE ?= raw

#################################################################################
# HLOS Configuration
#################################################################################

# HLOS Boot Profile
#
# This setting configures the method by which the HLOS is "booted". In all
# cases, SBL will technically bring up the board, and then kick off an HLOS
# "boot" as configured here.
#
# Choices are as follows:
# - "optimized" : ATF/OPTEE start the HLOS kernel directly
# - "development" : ATF/OPTEE start SPL, which uses U-Boot to boot HLOS
# - <NULL> : No HLOS boot
#
#pvarela
#HLOS_BOOT ?= optimized
HLOS_BOOT ?= development

# Path which contains all HLOS binaries
#pvarela
#HLOS_BIN_PATH ?= $(SDK_INSTALL_PATH)/ti-processor-sdk-linux/board-support/prebuilt-images/$(BOARD)
HLOS_BIN_PATH ?= /home/fn5pva0/ti-processor-sdk-linux-j7-evm-08_04_00_11/board-support/prebuilt-images/

# GCC PATH
#GCC_LINUX_ARM_PATH ?= $(SDK_INSTALL_PATH)/gcc-arm-$(GCC_ARCH64_VERSION)-x86_64-$(GCC_ARCH64_BIN_PREFIX)
GCC_LINUX_ARM_PATH ?= /home/fn5pva0/FicosaTools/compilers/gcc-arm-9.2-2019.12-x86_64-aarch64-none-elf

# HLOS Images
#
# Each HLOS component needs to be converted to an ELF prior to RPRC/appimage
# generation. So a Load Address will be needed, and if the image is intended to
# be started by SBL (i.e. ATF), then an Entry Point must also be provided.
#
# Each image configuration should be formatted as follows:
#
# <Device ID>,<Binary File>,<Load Address>,[Entry Point]
#
# NOTE: Device ID's are defined in <ti/build/makerules/platform.mk>
#
ATF_IMG ?= mpu1_0,$(HLOS_BIN_PATH)/bl31.bin,0x70000000,0x70000000
OPTEE_IMG ?= load_only,$(HLOS_BIN_PATH)/bl32.bin,0x9e800000,0x9e800000
KERNEL_IMG ?= load_only,$(HLOS_BIN_PATH)/Image,0x80080000,0x80080000
# Use board-specific pre-built DTBs to ensure SD card filesystem is used for Linux boot
DTB_IMG ?= load_only,$(mkfile_dir)bin/$(BOARD)/base-board.dtb,0x82000000,0x82000000
#pvarela
#SPL_IMG ?= load_only,$(HLOS_BIN_PATH)/u-boot-spl.bin,0x80080000,0x80080000
SPL_IMG ?= load_only,/home/fn5pva0/ti-processor-sdk-linux-j7-evm-08_04_00_11/board-support/u-boot_build/a72/spl/u-boot-spl.bin,0x80080000,0x80080000

#################################################################################
# RTOS/Baremetal Configuration
#################################################################################

# Path which contains all RTOS binaries
RTOS_BIN_PATH ?= $(PDK_INSTALL_PATH)/ti/boot/sbl/example/k3MulticoreApp/binary/$(SOC)

# RTOS/Baremetal Images
#
# Each image here is expected to be in an executable format (e.g. xer5f (ELF),
# ELF, COFF, etc). These images will be covnerted to RPRC before combined into
# an appimage.
#
# A finite number of image variables has been provided below, but users may
# add as many as needed. The load-order of these images is determined in
# $IMG_LIST below.
#
# Each image configuration here should be formatted as follows:
#
# <Device ID>,<RTOS/Baremetal Binary>
#
# NOTE: Device ID's are defined in <ti/build/makerules/platform.mk>
#
# NOTE: images configured to run on the same device as SBL will be started
# last. For example, on AM65xx SBL runs on MCU1_0, so any images
# configured to run on MCU1 will be started when SBL is finished.
#
# Example:
# IMG1 ?= mcu1_0,$(RTOS_BIN_PATH)/sbl_baremetal_boot_test_$(SOC)_idk_mcu1_0TestApp_release.xer5f
#
#pvarela
IMG1 ?= mcu1_0,/home/fn5pva0/ti-processor-sdk-rtos-j721e-evm-08_04_00_06/mcusw/binary/can_profile_app_freertos/bin/j721e/can_profile_app_freertos_mcu1_0_debug.xer5f
IMG2 ?=
IMG3 ?=
IMG4 ?=
IMG5 ?=
IMG6 ?=
IMG7 ?=
IMG8 ?=

#################################################################################
# Final Image Configuration
#################################################################################

# ATF is last on purpose, as it is only image that will be executed, thus it is
# important that the other HLOS images get loaded first.
ifeq ($(HLOS_BOOT),optimized)
HLOS_IMGS = $(OPTEE_IMG) $(KERNEL_IMG) $(DTB_IMG) $(ATF_IMG)
else ifeq ($(HLOS_BOOT),development)
HLOS_IMGS = $(OPTEE_IMG) $(SPL_IMG) $(ATF_IMG)
else
HLOS_IMGS =
endif

# The final list of images, listed in inteded load/boot order
# (please see note above in "RTOS/Baremetal Configuration" regarding boot order)
IMG_LIST ?= $(IMG1) $(IMG2) $(IMG3) $(IMG4) $(IMG5) $(IMG6) $(IMG7) $(IMG8) $(HLOS_IMGS)

NOTE: The SPL by default is obtained from "$(HLOS_BIN_PATH)/u-boot-spl.bin" but in HLOS_BIN_PATH only "u-boot-spl.bin-j7-evm" is present. Should the name of this prebuilt file changed manually to "u-boot-spl.bin"?. Anyway, I am linking to the one is generated when u-boot is rebuilt. Is this correct?

Nikhil Dasan said:

Here, have you made the relevant changes such as providing the path to common_proc.dtb and adding IMG1, IMG2 etc with binaries of MCU1_0, MCU2_0 etc?

I only point to CAN_profile that I built. This is done in IMG1. 

Nikhil Dasan said:

If yes, since you have pointed here only to common_proc.dtb, it cannot fetch vision_apps.dtbo. 

In this case, you would have to integrate the contents of vision_apps.dtsi and rtos_memory_map.dtsi into common_proc.dtsi in Linux SDK and build a vision_app integrated common_proc.dtb.

This way the reserved section for vision_apps could be reflected on the RTOS side.

I don't know how to integrate that into dtsi. I though all changes needed would be done with "make linux_fs_install_sd" described in documentation.

With that make script (according to described in docuemntation), uenv.txt is repalced in bootfs and that file applies the dtbo k3-j721e-vision-apps.dtbo, that I understood adjust the memory map based on vision_apps requirements, and also:

• disables display on A72 so that R5F can control display
• disables i2c1 on A72 which is used for HDMI display control by R5F
• disables i2c6 on A72 which is used for CSI2RX sensor control by R5F
• enables DMA Buf contigous memory allocator and reserves a heap for DMA Buf
• reserves memory for shared memory between different CPUs

That make creates uEnv_j721e_vision_apps.txt and put it into BOOT partition. Then is renamed uEnv.txt.  In that file, is referred name_overlays=k3-j721e-vision-apps.dtbo

Not clear how all this stuff are used, but it seems that u-boot is properly adapted to load different DTB to allow vision apps working.

Nikhil Dasan said:

Could you also share the full logs (linux + RTOS ) in a text file ?

It seems that I can not attach files. COuld you show me how to provide you those files?

Thanks 

Hi,

As discussed in the debug call, The issue is not seen anymore on SDK 8.4.

Ficosa to test further and try to reproduce this issue.

Regards,
Nikhil

Hello Nikhil,

Here is Pablo's last update as he could create combined_image optimized with SBL in debug mode. It looks like his path was not correctly handled for make. Then he copied DTB to same path on combined_image make is. This DTB is the one is created with patch when u-boot built (done this morning).

After that, combined image is created (parsing 5 files as expected), and after copying to SD card, SBL is loading all properly. In this scenario, time is longer because of loading kernel image is done by SBL. But this is acceptable for the customer.

However he observed that kernel is stuck at 2.524527s.

(attached log files UART0_MAIN_ttyUSB2_115200.log and UART_MCU_ttyUSB1_115200.log)

CAN_profile remains active.

Pointing to DTB_IMG provided in SDK (base-board.dtb), also copied to same path,

I observe crashing MCU1_0 CAN_profile (that has sense as the dts has no patch applied, then MCU UART and MCAN is referred in DTB and when used by A72 crashes can_profile). On the other hand, kenel panic appears in A72 because rootfs is not mounted.

(attached logs: UART0_MAIN_ttyUSB2_115200_base_board_dtb.log & UART_MCU_ttyUSB1_115200_base_board_dtb.log)

I guess behavior would be better if MCU1_0 image would have  changes/patches that are needed and suggested in post https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1003429/faq-tda4vm-mcusw-demo-on-can-along-side-linux-on-a72 to be provided by TI for 8.5.

Could you advise on how to go ahead on optimized solution?

In parallel, I will investigate why during the debug session I was able to see vision_app run finally when 8.4 is used, so I did not have Arago stuck for 2 minutes. The current behavior is what is expected, but I have to double check all the steps I did and what versions and build configurations I have in that second SD card.

Note: also attached conf.mk

Thank you.

2806.attachments.zip

Hello, here are some clarifications, sorry for not be clear enough:

Francois Charlot said:

This DTB is the one is created with patch when u-boot built (done this morning).

DTB pointed ton DTB_IMG is not the one created this morning after applying linux patch to U-boot's DTS. The dtb used is the one compiled for linux ("make linux-dtbs"), and located in "ti-processor-sdk-linux-j7-evm-08_05_00_08/board-support/linux-5.10.153+gitAUTOINC+90c3a58fd2-g90c3a58fd2/arch/arm64/boot/dts/ti". Sorry for my mistake

Francois Charlot said:

In this scenario, time is longer because of loading kernel image is done by SBL. But this is acceptable for the customer.

We have internally chatted and we realized that this restriction is not assumable. We must use a solution with SPL-UBOT in combined_image, so that, development in HLOS_BOOT. Thus, we should solve issue observed in:

RE: PROCESSOR-SDK-J721E: SBL for HLOS sd card fails in SCI client

Thanks a lot 

Hello Nikhil,

Nikhil Dasan said:

As discussed in the debug call, The issue is not seen anymore on SDK 8.4.

Ficosa to test further and try to reproduce this issue.

it is appearing again. On every powerUp.I did not chage SD card. Neither I did not execute any uboot command, so I did not intentionally change uboot environment...

I don't know why this is appearing again.

I attach Zip file with BOOT partition content and DTB for boot folder in rootfs partition. Just in case someone can test and check what is the root cause. Let me

know if you need something more.

Arago_delay_SD_content.zip

Hi Pablo,

This is with the development flow where u-boot in involved right?

During the boot, could you halt at u-boot (Press Enter when the count occurs at u-boot) and give the below commands?

env default –a –f
saveenv

Reboot the board after this and please check if you still see the issue?

Regards,
Nikhil