5.3. Boot App¶
Boot App is a tertiary bootloader which is booted by the SBL. It runs on mcu1_0, from mcu1_0 it boots other cores in different stages. It can boot high level OS like Linux or QNX on A72 cores via MMCSD or OSPI. This is supported on HS devices as well.
5.3.1. Boot stages¶
5.3.2. Steps to Boot Different OS via Different Boot Media¶
Booting lateapps via MMCSD
Booting QNX via MMCSD
Booting Linux via MMCSD
Booting lateapps via OSPI
Booting QNX via OSPI
Booting Linux via OSPI
Booting lateapps via EMMC UDA
Booting QNX via EMMC UDA
Booting Linux via EMMC UDA
Booting lateapps via MMCSD
Generate lateapps by using the following commands
goto <PDK>/packages/ti/boot/sbl/example/boot_app/scripts
Run ./make_multicore_appimages.sh <board_name>
Multicore images(lateapps) will be generated in <PDK>/packages/ti/boot/sbl/example/boot_app/multicore_images/$BOARD/.
Stage1 image corresponds to lateapp1, stage2 image corresponds to lateapp2 and stage3 image corresponds to lateapp3.
Copy sbl_mmcsd_img_mcu1_0_release.tiimage as tiboot3.bin to the boot partition of SD card
Copy tifs.bin to the boot partition of SD card
Build boot_app_mmcsd by using the following command
make BOARD=<board_name> CORE=mcu1_0 boot_app_mmcsd -sj
Copy sbl_boot_app_mmcsd_<board_name>_mcu1_0_freertos_TestApp_release.appimage image as app to the boot partition of SD card
Copy stage1 image as lateapp1, stage2 image as lateapp2 and stage3 image as lateapp3 to the boot partition of SD card
Booting QNX via MMCSD
Generate lateapps by using the following commands
goto <PDK>/packages/ti/boot/sbl/example/boot_app/scripts
Run ./make_multicore_appimages.sh <board_name>
Multicore images(lateapps) will be generated in <PDK>/packages/ti/boot/sbl/example/boot_app/multicore_images/$BOARD/.
Stage1 image corresponds to lateapp1, stage2 image corresponds to lateapp2 and stage3 image corresponds to lateapp3.
Copy sbl_mmcsd_img_mcu1_0_release.tiimage as tiboot3.bin to the boot partition of SD card
Copy tifs.bin to the boot partition of SD card
Build boot_app_mmcsd by using the following command
make BOARD=<board_name> CORE=mcu1_0 boot_app_mmcsd_qnx -sj
Copy sbl_boot_app_mmcsd_qnx_<board_name>_mcu1_0_freertos_TestApp_release.appimage image as app to the boot partition of SD card
Copy stage1 image as lateapp1, stage2 image as lateapp2 to the boot partition of SD card
Copy ifs_qnx.appimage, atf_optee.appimage to the boot partition of SD card. Please find these images in the QNX daily build here
Booting Linux via MMCSD
Generate lateapps by using the following commands
goto <PDK>/packages/ti/boot/sbl/example/boot_app/scripts
Run ./make_multicore_appimages.sh <board_name>
Multicore images(lateapps) will be generated in <PDK>/packages/ti/boot/sbl/example/boot_app/multicore_images/$BOARD/.
Stage1 image corresponds to lateapp1, stage2 image corresponds to lateapp2 and stage3 image corresponds to lateapp3.
Copy sbl_mmcsd_img_mcu1_0_release.tiimage as tiboot3.bin to the boot partition of SD card
Copy tifs.bin to the boot partition of SD card
Build boot_app_mmcsd_linux by using the following command
make BOARD=<board_name> CORE=mcu1_0 boot_app_mmcsd_linux -sj
Copy sbl_boot_app_mmcsd_linux_<board_name>_mcu1_0_freertos_TestApp_release.appimage image as app to the boot partition of SD card
Copy stage1 image as lateapp1, stage2 image as lateapp2 to the boot partition of SD card
Copy atf_optee.appimage, tidtb_linux.appimage, tikernelimage_linux.appimage to the boot partition of SD card.
Booting lateapps via OSPI
Generate lateapps by using the following commands
goto <PDK>/packages/ti/boot/sbl/example/boot_app/scripts
Run ./make_multicore_appimages.sh <board_name>
Multicore images(lateapps) will be generated in <PDK>/packages/ti/boot/sbl/example/boot_app/multicore_images/$BOARD/.
Stage1 image corresponds to lateapp1, stage2 image corresponds to lateapp2 and stage3 image corresponds to lateapp3.
Build boot_app_ospi by using the following command
make BOARD=<board_name> CORE=mcu1_0 boot_app_mmcsd_linux -sj
Flash images to ospi flash memory at specified address using uniflash tool
sbl_cust_img_mcu1_0_release.tiimage at an offset of 0x0
tifs.bin at an offset of 0x8000
boot_app_ospi_<board_name>_mcu1_0_freertos_TestApp_release.appimage at an offset of 0x100000
stage1 image at an offset of 0x1fc0000
stage2 image at an offset of 0x27c0000
stage3 image at an offset of 0x37c0000
Booting QNX via OSPI
Generate lateapps by using the following commands
goto <PDK>/packages/ti/boot/sbl/example/boot_app/scripts
Run ./make_multicore_appimages.sh <board_name>
Multicore images(lateapps) will be generated in <PDK>/packages/ti/boot/sbl/example/boot_app/binary/$BOARD/. Stage1 image corresponds to lateapp1, stage2 image corresponds to lateapp2 and so on.
Build boot_app_ospi_qnx by using the following command
make BOARD=<board_name> CORE=mcu1_0 boot_app_mmcsd_qnx -sj
Flash images to ospi flash memory at specified address using uniflash tool
sbl_cust_img_mcu1_0_release.tiimage at an offset of 0x0
tifs.bin at an offset of 8000
boot_app_ospi_qnx_<board_name>_mcu1_0_freertos_TestApp_release.appimage at an offset of 0x100000
stage1 image at an offset of 0x1fc0000
stage2 image at an offset of 0x27c0000
atf_optee.appimage at an offset of 0x1c0000
ifs_qnx.appimage at an offset of 0x7c0000
Booting Linux via OSPI
Generate lateapps by using the following commands
goto <PDK>/packages/ti/boot/sbl/example/boot_app/scripts
Run ./make_multicore_appimages.sh <board_name>
Multicore images(lateapps) will be generated in <PDK>/packages/ti/boot/sbl/example/boot_app/binary/$BOARD/. Stage1 image corresponds to lateapp1, stage2 image corresponds to lateapp2 and so on.
Build boot_app_ospi by using the following command
make BOARD=<board_name> CORE=mcu1_0 boot_app_mmcsd_linux -sj
Flash images to ospi flash memory at specified address using uniflash tool
sbl_cust_img_mcu1_0_release.tiimage at an offset of 0x0
tifs.bin at an offset of 0x8000
boot_app_ospi_linux_<board_name>_mcu1_0_freertos_TestApp_release.appimage at an offset of 0x100000
stage1 image at an offset of 0x1fc0000
stage2 image at an offset of 0x27c0000
atf_optee.appimage at an offset of 0x1c0000
tidtb_linux.appimage at an offset of 0x7c0000
tikernelimage_linux.appimage at an offset of 0x1ec0000
Booting lateapps via EMMC UDA
Generate lateapps by using the following commands
goto <PDK>/packages/ti/boot/sbl/example/boot_app/scripts
Run ./make_multicore_appimages.sh <board_name>
Multicore images(lateapps) will be generated in <PDK>/packages/ti/boot/sbl/example/boot_app/multicore_images/$BOARD/.
Stage1 image corresponds to lateapp1, stage2 image corresponds to lateapp2 and stage3 image corresponds to lateapp3.
Copy sbl_emmc_uda_img_mcu1_0_release.tiimage as tiboot3.bin to /media/$USER/rootfs/home/root in the SD card
Copy tifs.bin to /media/$USER/rootfs/home/root in the SD card
Build boot_app_emmc_uda by using the following command
make BOARD=<board_name> CORE=mcu1_0 boot_app_emmc_uda -sj
Copy sbl_boot_app_emmc_uda_<board_name>_mcu1_0_freertos_TestApp_release.appimage image as app to /media/$USER/rootfs/home/root in the SD card.
Copy stage1 image as lateapp1, stage2 image as lateapp2 and stage3 image as lateapp3 to /media/$USER/rootfs/home/root in the SD card.
Copy mksdboot.sh from <Linux_SDK_Install_Directory>/bin to /media/$USER/rootfs/home/root
Put the SD Card back to board and boot in SD boot mode: SW8: 1000 0010 SW9: 0000 0000
Login as root
Run the script: ./mksdboot.sh –device /dev/mmcblk0
Copy the images to eMMC partition
mkdir eMMC
mount /dev/mmcblk0p1 eMMC
cp tiboot3.bin eMMC
cp tifs.bin eMMC
cp app eMMC
cp lateapp1 eMMC
cp lateapp2 eMMC
cp lateapp3 eMMC
Change boot mode to eMMC UDA partition and boot the board: SW8: 1000 0000 SW9: 0000 0000
Booting QNX via EMMC UDA
Generate lateapps by using the following commands
goto <PDK>/packages/ti/boot/sbl/example/boot_app/scripts
Run ./make_multicore_appimages.sh <board_name>
Multicore images(lateapps) will be generated in <PDK>/packages/ti/boot/sbl/example/boot_app/multicore_images/$BOARD/.
Stage1 image corresponds to lateapp1, stage2 image corresponds to lateapp2 and stage3 image corresponds to lateapp3.
Copy sbl_emmc_uda_img_mcu1_0_release.tiimage as tiboot3.bin to /media/$USER/rootfs/home/root in the SD card
Copy tifs.bin to /media/$USER/rootfs/home/root in the SD card
Build boot_app_emmc_uda_qnx by using the following command
make BOARD=<board_name> CORE=mcu1_0 boot_app_emmc_uda_qnx -sj
Copy sbl_boot_app_emmc_uda_qnx_<board_name>_mcu1_0_freertos_TestApp_release.appimage image as app to /media/$USER/rootfs/home/root in the SD card.
Copy stage1 image as lateapp1, stage2 image as lateapp2 to /media/$USER/rootfs/home/root in the SD card.
Copy ifs_qnx.appimage, atf_optee.appimage to /media/$USER/rootfs/home/root in the SD card. Please find these images in the QNX daily build here
Copy mksdboot.sh from <Linux_SDK_Install_Directory>/bin to /media/$USER/rootfs/home/root
Put the SD Card back to board and boot in SD boot mode: SW8: 1000 0010 SW9: 0000 0000
Login as root
Run the script: ./mksdboot.sh –device /dev/mmcblk0
Copy the images to eMMC partition
mkdir eMMC
mount /dev/mmcblk0p1 eMMC
cp tiboot3.bin eMMC
cp tifs.bin eMMC
cp app eMMC
cp lateapp1 eMMC
cp lateapp2 eMMC
cp ifs_qnx.appimage eMMC
cp atf_optee.appimage eMMC
Change boot mode to eMMC UDA partition and boot the board: SW8: 1000 0000 SW9: 0000 0000
Booting Linux via EMMC UDA
Generate lateapps by using the following commands
goto <PDK>/packages/ti/boot/sbl/example/boot_app/scripts
Run ./make_multicore_appimages.sh <board_name>
Multicore images(lateapps) will be generated in <PDK>/packages/ti/boot/sbl/example/boot_app/multicore_images/$BOARD/.
Stage1 image corresponds to lateapp1, stage2 image corresponds to lateapp2 and stage3 image corresponds to lateapp3.
Copy sbl_emmc_uda_img_mcu1_0_release.tiimage as tiboot3.bin to /media/$USER/rootfs/home/root in the SD card
Copy tifs.bin to /media/$USER/rootfs/home/root in the SD card
Build boot_app_emmc_uda_linux by using the following command
make BOARD=<board_name> CORE=mcu1_0 boot_app_emmc_uda_linux -sj
Copy sbl_boot_app_emmc_uda_linux_<board_name>_mcu1_0_freertos_TestApp_release.appimage image as app to /media/$USER/rootfs/home/root in the SD card.
Copy stage1 image as lateapp1, stage2 image as lateapp2 to /media/$USER/rootfs/home/root in the SD card.
Copy atf_optee.appimage, tidtb_linux.appimage, tikernelimage_linux.appimage to the boot partition of SD card.
Copy mksdboot.sh from <Linux_SDK_Install_Directory>/bin to /media/$USER/rootfs/home/root
Put the SD Card back to board and boot in SD boot mode: SW8: 1000 0010 SW9: 0000 0000
Login as root
Run the script: ./mksdboot.sh –device /dev/mmcblk0
Copy the images to eMMC partition
mkdir eMMC
mount /dev/mmcblk0p1 eMMC
cp tiboot3.bin eMMC
cp tifs.bin eMMC
cp app eMMC
cp lateapp1 eMMC
cp lateapp2 eMMC
cp tidtb_linux.appimage eMMC
cp tikernelimage_linux.appimage eMMC
cp atf_optee.appimage eMMC
Change boot mode to eMMC UDA partition and boot the board: SW8: 1000 0000 SW9: 0000 0000
5.3.3. Booting in HS devices¶
To boot the boot app on HS devices add _hs while building boot app image i.e boot_app_mmcsd_hs or boot_app_ospi_hs.
Use .appimage.signed images instead of .appimage for HS devices.
5.3.4. Integration of Functional Safety with Bootapp¶
TI Automotive and Industrial customers who select a Jacinto 7 device, often require a safety solution. To meet the safety diagnostics outlined in the TI Device Safety Manual, modifications must be made to the SDK boot flow. This section outlines the most effective way to leverage TI’s SDL offering in a customised boot flow using the BootApp.
Functional Safety using SDL
The J784S4 family of SoC’s provides various safety mechanisms and features, as well as recommendations for usage of these safety mechanisms and features to customers who wish to make their device safety compliant. The Software Diagnostics Library (SDL) which is provided as apart of our SDK, provides interfaces to these safety mechanisms and features. Using SDL can assist in the development of software applications involving Functional Safety. For more information on the Software Diagnostics Library (SDL), refer “https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-j784s4/08_06_00_14/exports/docs/sdl/sdl_docs/userguide/j784s4/index_j784s4.html”
Integration of BIST with BootApp
Built-in self test (BIST), is a feature that allows self testing of the memory areas and logic circuitry in an Integrated Circuit (IC) without any external test equipment. In an embedded system, these tests are typically used during boot time or shutdown of the system to check the health of an SoC.
PBIST is used to test the memory regions in the SoC and provides detection for permanent faults. The primary use case for PBIST is when it is invoked at start-up providing valuable information on any stuck-at bits in the memory.
LBIST is used to test the logic circuitry in an SoC associated with the CPU cores.
BIST must be initiated from a different core than is being tested. BIST is executed by hardware for MCU and DMSC automatically at boot up as part of HW POST. Note, that BIST is destructive to the core/IP on which it is run. If it is executed after the IP under test is already in use in the system, it is the application’s responsibility to perform any necessary context save/restore necessary for the core/IP. Also, it is not supported to run the BIST test for a core on itself, as it will be self destructive.
SW Integration Details
Compile Time Configurations for Boot Application to enable/disable BIST task - Update SAFETY_TASK_ENABLED=yes in <pdk_install_path>/pdk/packages/ti/boot/sbl/sbl_component.mk
Build the required SDL libraries present in <sdk_install_path>/sdl/ using the commands -
make sdl_ip SOC=j784s4 PROFILE=release
make sdl_api SOC=j784s4 PROFILE=release
make sdl_osal SOC=j784s4 PROFILE=release
The following files have been included from the Software Diagnostics Library (SDL) to test the BIST functionality:
bist.c/bist.h - These files implement BootApp_bistFxn() API that runs LBIST and PBIST prior to boot stages.
lbist_utils.c/lbist_utils.h - These files define the LBIST utility functions such as - BootApp_lbistRunTest() and BootApp_lbistHwPostStatusPrint()
pbist_utils.c/pbist_utils.h - These files define the PBIST utility functions such as - BootApp_pbistRunTest(), BootApp_pbistCommonInit() and BootApp_pbistClecConfig()
power_seq.c/ power_seq.h - These files provide core-specific power sequence functions such as BootApp_customPrepareForPowerUpSequence() and BootApp_customPowerDownSequence()
bist_core_defs.c/bist_core_defs.h, lbist_defs.c/lbist_defs.h, pbist_defs.c/pbist_defs.h - These files are SOC specific and contain the BIST instance definitons corresponding to a specific SOC
osal_wrap.c - This file provide the SDL OSAL wrapper required by the internal SDL source APIs.
BIST instances being tested as a part of the PDK BootApp
The list of instances being tested for PBIST and LBIST are as follows:
PBIST Instances:
HWPOST_MCU_INDEX
PBIST_INSTANCE_MAINR5F0
PBIST_INSTANCE_MAINR5F1
PBIST_INSTANCE_MAINR5F2
PBIST_INSTANCE_C7X_0
PBIST_INSTANCE_C7X_1
PBIST_INSTANCE_C7X_2
PBIST_INSTANCE_C7X_3
PBIST_INSTANCE_ANA_0
PBIST_INSTANCE_ANA_1
PBIST_INSTANCE_ANA_2
PBIST_INSTANCE_ANA_3
LBIST Instances:
LBIST_HWPOST_INST_SMS_INDEX
LBIST_HWPOST_INST_MCU_INDEX
LBIST_INST_MAINR5F0_INDEX
LBIST_INST_MAINR5F1_INDEX
LBIST_INST_C7X0_INDEX
LBIST_INST_C7X1_INDEX
LBIST_INST_A72_0_INDEX
LBIST_INST_A72_1_INDEX
LBIST_INST_C7X2_INDEX
LBIST_INST_C7X3_INDEX
LBIST_INST_A72SS0_CORE0_INDEX
LBIST_INST_A72SS0_CORE1_INDEX
LBIST_INST_A72SS0_CORE2_INDEX
LBIST_INST_A72SS0_CORE3_INDEX
LBIST_INST_A72SS1_CORE0_INDEX
LBIST_INST_A72SS1_CORE1_INDEX
LBIST_INST_A72SS1_CORE2_INDEX
LBIST_INST_A72SS1_CORE3_INDEX
LBIST_INST_MAINR5F2_INDEX
BIST instances not being tested as a part of the PDK BootApp
The list of instances not being tested for PBIST and LBIST are as follows:
Impacts general Main Domain functionality from Boot App as BIST is destructive
PBIST_INSTANCE_MAININFRA_0
PBIST_INSTANCE_MAININFRA_1
PBIST_INSTANCE_NAVSS
PBIST_INSTANCE_HC
PBIST_INSTANCE_MSMC
PBIST_INSTANCE_A72_0_0
PBIST_INSTANCE_A72_0_1
PBIST_INSTANCE_A72_1_0
PBIST_INSTANCE_A72_1_1
MCU PBIST functionality tests are not supported by SW
PBIST_INSTANCE_MCU_PSROM
PBIST_INSTANCE_MCU_1
PBIST_INSTANCE_MCU_PULSAR
Instances not used during the flow of BootApp, can be included based on specific customer usecases
PBIST_INSTANCE_CODEC
PBIST_INSTANCE_CODEC_1
PBIST_INSTANCE_VPAC_0
PBIST_INSTANCE_VPAC_1
PBIST_INSTANCE_DSS
PBIST_INSTANCE_DMPAC
PBIST_INSTANCE_GPU
LBIST_INST_VPAC0_INDEX
LBIST_INST_VPAC1_INDEX
LBIST_INST_DMPAC_INDEX
Note that this BIST integration with the BootApp is meant to be a template to be followed for ease of use and contains only the main functionality tests. If the customer wishes to add/remove any instances or tests, it can be done refering to this integration.
Integration of VTM with BootApp
The Voltage and Thermal Management (VTM) controls the temperature monitors in the die. VTM provides the application to initialize the VTM modules, check the status of the temparature sensor based on an alert temperature and to clear and control any VTM event that occurs.
SW Integration Details
Compile Time Configurations for Boot Application to enable/disable VTM task - Update SAFETY_TASK_ENABLED=yes in <pdk_install_path>/pdk/packages/ti/boot/sbl/sbl_component.mk
Build the required SDL libraries present in <sdk_install_path>/sdl/ using the commands -
make sdl_ip SOC=j784s4 PROFILE=release
make sdl_api SOC=j784s4 PROFILE=release
make sdl_osal SOC=j784s4 PROFILE=release
The following files have been included from the Software Diagnostics Library (SDL) to test the VTM functionality:
vtm.c/vtm.h - These files implement BootApp_vtmFxn() API that demonstrates the usage of the VTM to detect overtemperature events and signal the events through the ESM.
event_trigger.c - This file contains functions that provide input event triggers for the Voltage and Thermal Monitor (VTM) application.
osal_wrap.c - This file provide the SDL OSAL wrapper required by the internal SDL source APIs.
The example demonstrates:
Configuring the VTM thresholds
Early alert event detection
Critial threshold event detection
Follow-up event notification when temperature has dropped to a safe level
Integration of POK with BootApp
This device has several internal voltage monitors called Power OK (POK). These monitors can be configured to detect undervoltage (UV) or overvoltage (OV) conditions, and to report errors via ESM. POK modules are responsible for monitoring and accurately detecting voltage levels. POK modules are capable of monitoring a range of supplies and indicating a failure within the programmable upper and lower threshold limits for the supply being monitored.
SW Integration Details
Compile Time Configurations for Boot Application to enable/disable POK task - Update SAFETY_TASK_ENABLED=yes in <pdk_install_path>/pdk/packages/ti/boot/sbl/sbl_component.mk
Build the required SDL libraries present in <sdk_install_path>/sdl/ using the commands -
make sdl_ip SOC=j784s4 PROFILE=release
make sdl_api SOC=j784s4 PROFILE=release
make sdl_osal SOC=j784s4 PROFILE=release
The following files have been included from the Software Diagnostics Library (SDL) to test the POK functionality:
pok.c/pok.h - These files implement BootApp_pokFxn() API that demonstrates the usage of the POK modules. It shows how to listen for POK error events using the ESM, and also forcing an error in order to demonstrate application notification of overvoltage and undervoltage events.
osal_wrap.c - This file provide the SDL OSAL wrapper required by the internal SDL source APIs.
The example demonstrates:
Undervoltage Event Detection
Overvoltage Event Detection
Integration of TOG with BootApp
The Timeout Gasket (TOG) is a TI proprietary IP that is used to prevent a hang caused by slave, which can hold up the interconnect and terminate such a transaction safely. It tracks transactions, and times out if outstanding too long, and reports the error via interrupt that can be monitored.
SW Integration Details
Compile Time Configurations for Boot Application to enable/disable TOG task - Update SAFETY_TASK_ENABLED=yes in <pdk_install_path>/pdk/packages/ti/boot/sbl/sbl_component.mk
Build the required SDL libraries present in <sdk_install_path>/sdl/ using the commands -
make sdl_ip SOC=j784s4 PROFILE=release
make sdl_api SOC=j784s4 PROFILE=release
make sdl_osal SOC=j784s4 PROFILE=release
The following files have been included from the Software Diagnostics Library (SDL) to test the TOG functionality:
tog.c/tog.h - These files implement BootApp_togFxn() API that demonstrates demonstrates the usage of the TOG module. It shows how to listen for TOG error events using the ESM, and also forcing an error in order to demonstrate application notification of a timeout event.
tog_utils.asm - These files define the TOG utility functions
osal_wrap.c - This file provide the SDL OSAL wrapper required by the internal SDL source APIs.
The example demonstrates:
Setting a timeout for a TOG instance
Error injection for a TOG instance
Error event detection for a timeout event