VisionSDK_NetworkTools_UserGuide Vision SDK User Guide Build System
User Manual:
Open the PDF directly: View PDF .
Page Count: 30
Download | |
Open PDF In Browser | View PDF |
Vision SDK Build System User Guide Page 1 of 30 IMPORTANT NOTICE Texas Instruments and its subsidiaries (TI) reserve the right to make changes to their products or to discontinue any product or service without notice, and advise customers to obtain the latest version of relevant information to verify, before placing orders, that information being relied on is current and complete. All products are sold subject to the terms and conditions of sale supplied at the time of order acknowledgment, including those pertaining to warranty, patent infringement, and limitation of liability. TI warrants performance of its products to the specifications applicable at the time of sale in accordance with TI’s standard warranty. Testing and other quality control techniques are utilized to the extent TI deems necessary to support this warranty. Specific testing of all parameters of each device is not necessarily performed, except those mandated by government requirements. Customers are responsible for their applications using TI components. In order to minimize risks associated with the customer’s applications, adequate design and operating safeguards ought to be provided by the customer so as to minimize inherent or procedural hazards. TI assumes no liability for applications assistance or customer product design. TI does not warrant or represent that any license, either express or implied, is granted under any patent right, copyright, mask work right, or other intellectual property right of TI covering or relating to any combination, machine, or process in which such products or services might be or are used. TI’s publication of information regarding any third party’s products or services does not constitute TI’s approval, license, warranty or endorsement thereof. Reproduction of information in TI data books or data sheets is permissible only if reproduction is without alteration and is accompanied by all associated warranties, conditions, limitations and notices. Representation or reproduction of this information with alteration voids all warranties provided for an associated TI product or service, is an unfair and deceptive business practice, and TI is neither responsible nor liable for any such use. Resale of TI’s products or services with statements different from or beyond the parameters stated by TI for that product or service voids all express and any implied warranties for the associated TI product or service, is an unfair and deceptive business practice, and TI is not responsible nor liable for any such use. Also see: Standard Terms and Conditions of Sale for Semiconductor Products. www.ti.com/sc/docs/stdterms.htm Mailing Address: Texas Instruments Post Office Box 655303 Dallas, Texas 75265 Copyright © 2017, Texas Instruments Incorporated Page 2 of 30 TABLE OF CONTENTS 1 Introduction ................................................................................................. 4 2 Basic Usage .................................................................................................. 5 3 Fast Builds ................................................................................................... 6 4 4.1 4.2 4.3 Build Configuration ...................................................................................... 7 Modifying Build Configuration Files .....................................................................7 Build Configuration Options ...............................................................................9 Adding user specific build config ....................................................................... 13 5 5.1 5.2 Make Targets and Command Line Options .................................................. 15 Make Targets ................................................................................................. 15 Command Line Options ................................................................................... 16 6 6.1 6.2 6.3 6.4 6.5 Adding new use-cases, algplugins to build ................................................. 17 Adding new use-cases to build (BIOS ONLY mode) ............................................. 17 Adding new use-cases to build (Linux + BIOS mode) .......................................... 20 Adding new alg plugins to build (BIOS side) ...................................................... 22 Adding new alg plugins to build (Linux side) ...................................................... 22 Building Algorithm plugins for individual cores ................................................... 23 7 Adding new system config parameters to build config ............................... 25 8 Adding new library to application ............................................................... 26 9 Changing compiler, linker options .............................................................. 26 10 10.1 10.2 Build Config Implementation Details (Advanced Users) ............................. 27 Build config generated .h file ........................................................................... 27 Build config makefiles ..................................................................................... 27 11 11.1 11.2 Add and Delete links into links framework ................................................. 28 Adding a link ................................................................................................. 28 Deleting a link ............................................................................................... 29 12 Revision History ......................................................................................... 30 Page 3 of 30 1 Introduction This document describes how to use the Vision SDK “make” based build system. It explains the basic’s on how to compile and link Vision SDK binaries and it also explains various methods by which build can be customized and made faster for advanced users. Section 2 Basic Usage explains the steps first time users or basic users need to follow to get started Section 3 Fast Builds gives tips to enable fast builds. Subsequent sections explain more details about different aspects of build system. This can be useful for basic and advanced users to help customize their build based on their specific requirements. Page 4 of 30 2 Basic Usage Follow below steps if you are a first time user and are trying to build Vision SDK 1. Identify the build config for which you want to build. Ex, if you want build for TDA2xx SoC on TI EVM with BIOS on all CPUs with all default demos, use build config as “tda2xx_evm_bios_all” TIP: Default build config names are the folder names that are present in “vision_sdk/$(MAKEAPPNAME)/configs/” 2. Set required build config in “vision_sdk/build/Rules.make” at below line MAKECONFIG?=tda2xx_evm_bios_all 3. Or alternatively pass the value of make variable MAKECONFIG via command line when invoking make as shown below > make –s –j MAKEAPPNAME=apps MAKECONFIG=tda2xx_evm_bios_all All subsequent discussion will assume MAKEAPPNAME and MAKECONFIG value is set in Rules.make 4. When building for first time do below on command prompt. This will setup the build environment based on selected MAKEAPPNAME and MAKECONFIG, it will build the drivers in PDK and EDMA3LLD. > make –s –j depend TIP: DON’T do this step every time application needs to be built. This affects build time of the application in next step. This needs to be done only when building for first time or when there is change in any drivers (PDK, EDMA3LLD) or when config that is used or parameter values of current config are changed. 5. To build the Vision SDK link framework and apps do below. This will build the complete framework, links, algplugins, usecases and finally it will generate the “CCS” loadable binaries in folder “vision_sdk/binaries/$( MAKEAPPNAME)/$(MAKECONFIG)/vision_sdk/bin/$(PLATFORM)/” > make –s –j 6. To make the SD card loadable application image do below. This will create the “AppImage” and put it in folder “vision_sdk/binaries/$( MAKEAPPNAME)/$(MAKECONFIG)/vision_sdk/bin/$(PLATFORM)/sbl_boot” > make –s –j appimage NOTE: This step is applicable when BIOS runs on all CPUs 7. Refer respective platform userguide on steps to generate the SD card bootloader and steps to run the generated AppImage on the EVM. 8. In order to “clean” current configuration delete below folder “vision_sdk/binaries/$( MAKEAPPNAME)/$(MAKECONFIG)/” Ex, > rm –rf vision_sdk/binaries/apps/tda2xx_evm_bios_all 9. TIP: To see current config parameters do below > make showconfig Page 5 of 30 3 Fast Builds This section lists some tips to enable faster builds in the Vision SDK build system. It gives the top level tips and refers to relevant sections in this document for exact details 1. It is recommend to create your own build config (section 4.3 Adding user specific build config) 2. Customize the build based on your requirements (refer section 4 Build Configuration for details). Specifically do the below in the config folder a. Modify PROC__INCLUDE to mark as “no” the CPUs that are not needed (vision_sdk/config/$(MAKECONFIG)/cfg.mk) b. Modify vision_sdk/config/$(MAKECONFIG)/uc_cfg.mk to keep only use-cases you are interested in c. Use “make showconfig” to confirm the config options that are being used for the build 3. Use “-s –j” option when invoking make in command line (section 5.1 Make Targets) 4. When doing incremental build, only invoke make for the targets that are required. Refer section 5.1 Make Targets for the available make targets which allow granular compilation of modules 5. When doing incremental build, only build for CPUs that have modifications (see section 5.2.1 Selecting CPU to build via command line) 6. When one is not sure which modules are modified do “make –s –j depend” followed by “make –s –j” to allow build system to scan and build all modified modules. Page 6 of 30 4 Build Configuration Build configuration is the means by which various build level parameters are set depending on SOC, Board, OS, application. General guidelines used by TI for naming a build config is below _ _ _ o , can be TI TDA SoC like TDA2x, TDA2Ex, TDA3x o , can be name for a board built using one of SoC, eg, “evm” for TI EVM or “rvp” for RVP board or “mc” for xCAM board o , can be “bios” for BIOS ONLY OS used on all CPUs or “linux” for Linux+BIOS OS used across different CPUs o , can be “all” for all demos in Vision SDK package or “opencx” for all OpenCV, OpenCL demos. TIP: User defined build configs can follow naming convenient and logical for the user 4.1 Modifying Build Configuration Files Build configuration files are present in folder “vision_sdk/$( MAKEAPPNAME)/configs/$(MAKECONFIG)”, i.e the name of the build config is the folder name under “vision_sdk/$( MAKEAPPNAME)/configs” All subsequent discussion assumes MAKECONFIG=tda2xx_evm_bios_all Build config conists on one mandatory file “cfg.mk” which the build system expects o Ex, vision_sdk/apps/configs/tda2xx_evm_bios_all/cfg.mk In this folder this is also a uc_cfg.mk file, this file is inturn included by cfg.mk, so in this sense uc_cfg.mk is not required by the build system but is created to allow modularity in specifying different build options cfg.mk lists all the selected parameter values for this config. o Ex, PROC_xxx_INCLUDE application o Ex, VSDK_BOARD_TYPE specifies the HW board for which this config is valid. This indirectly selects the SoC for which this config is valid Users can customize the config based on their requirements o TIP: make the CPUs not required for your application to “no”. Ex, if IPU1-1 is not required, removed it from build as modifying cfg.mk as below PROC_IPU1_1_INCLUDE=no Uc_cfg.mk specifies the use-cases that are included in the final application. Use-cases inturn invoke different algplugins. Algplugins that are excluded in the build if none of the selected use-cases need the algplugin o specifies if a given CPU is included in this Ex, if application needs only framecopy and capture-display usecase it can comment all lines except the ones shown below in uc_cfg.mk UC_vip_single_cam_frame_copy=yes UC_vip_single_cam_view=yes TIP: Removing use-cases that are not required and CPUs that are not required will help reduce overall build time as well binary size Page 7 of 30 When values in cfg.mk or uc_cfg.mk are changed, the build environment needs to be updated to reflect updated values. This can be done by doing TIP: To see what config options are selected by current config do below o o > make –s –j depend > make showconfig Page 8 of 30 4.2 Build Configuration Options Build configuration options are divided into below categories System level config parameters Use-case selection config parameters Alg-plugin selection config parameters TIP: To see current selected list of config values do “make showconfig” 4.2.1 System level config parameters The list of currently supported system level config parameters are given in below table. NOTE: Parameter values are case sensitive. NOTE: Parameter which take values of “yes” or “no”. All values other than “yes” are considered as “no”. Parameter Valid Values Description PROC_IPU1_0_INCLUDE yes, no “yes” means the CPU is included in application and will be built TDA2EX_EVM Used to select, the board for which the SDK needs to be built, PROC_IPU1_1_INCLUDE PROC_IPU2_INCLUDE PROC_A15_0_INCLUDE PROC_DSP1_INCLUDE PROC_DSP2_INCLUDE PROC_EVE1_INCLUDE PROC_EVE2_INCLUDE PROC_EVE3_INCLUDE PROC_EVE4_INCLUDE VSDK_BOARD_TYPE TDA2XX_EVM TDA3XX_EVM TDA3XX_RVP TDA2XX_MC TDA2EX_EVM selects TDA2Ex SoC TI EVM board TDA2XX_EVM selects TDA2xx SoC TI EVM board TDA3XX_EVM selects TDA3xx SoC TI EVM board TDA3XX_RVP selects TDA3xx SoC D3 RVP board TDA2XX_MC selects TDA2xx SoC xCAM board DUAL_A15_SMP_BIOS yes, no “yes” means A15 runs BIOS in SMP mode. DDR_MEM DDR_MEM_512M Selects the memory map to use for application. DDR_MEM_128M DDR_MEM_512M means 512MB memory map Only valid for TDA2x SoC DDR_MEM_128M means 128MB memory map (only valid for TDA3x SoC) Page 9 of 30 NDK_PROC_TO_USE ipu1_0 Selects the CPU on which NDK runs. a15_0 “none” means NDK is disabled. ipu1_1 On TDA3x SoC due to pinmux conflict when MMCSD is enabled (FATFS_PROC_TO_USE != none) NDK is disabled automatically by build system. ipu2 none Recommended values, On TDA3x, ipu1_0 On TDA2x, TDA2Ex - BIOS ONLY mode and AVB is enabled, ipu1_1 - BIOS ONLY mode and AVB is disabled, a15_0 - Linux+BIOS mode and AVB is enabled, ipu2 - Linux+BIOS mode and AVB is disabled, none FATFS_PROC_TO_USE ipu1_0 a15_0 none Selects the CPU on which FAT filesystem using MMCSD runs. “none” means FAT FS and MMCSD is disabled. On TDA3x SoC due to pinmux conflict when MMCSD is enabled (FATFS_PROC_TO_USE != none) NDK is disabled automatically by build system. Recommended values, On TDA3x, ipu1_0 On TDA2x, TDA2Ex, - BIOS ONLY mode, ipu1_0 - Linux+BIOS mode, none BUILD_ALGORITHMS yes, no TI Internal option should be set to “no” by users BUILD_INFOADAS yes, no “yes” means Info ADAS application will be run. KW_BUILD yes, no CPLUSPLUS_BUILD yes, no IPU_PRIMARY_CORE ipu1_0 IPU_SECONDARY_CORE ipu2 Only valid for TDA2x, TDA2Ex with A15 running Linux TI Internal option should be set to “no” by users Selects the IPU which is “primary” core and the IPU which is secondary core. “primary” means the IPU on which drivers like VIP, VPE, DSS etc run “secondary” means IPU which can be used as general purpose CPU to run user SW IPU_PRIMARY_CORE and IPU_SECONDARY_CORE values cannot be same. The CPU which is selected as IPU_PRIMARY_CORE MUST be enabled via PROC_ _INCLUDE=yes Recommended values, TDA3x, IPU_PRIMARY_CORE=ipu1_0 IPU_SECONDARY_CORE=ipu2 [has no effect] TDA2x, TDA2Ex, - BIOS ONLY mode, IPU_PRIMARY_CORE=ipu1_0 IPU_SECONDARY_CORE=ipu2 - Linux+BIOS Mode, IPU_PRIMARY_CORE=ipu2 IPU_SECONDARY_CORE=ipu1_0 A15_TARGET_OS Linux Bios Selects the OS which runs on A15. Indirectly this selects BIOS ONLY mode or BIOS+Linux mode. In BIOS ONLY mode set this to “Bios” even if PROC_A15_)_INCLUDE=no IVAHD_INCLUDE yes, no “yes” means IVAHD HWA is included in application VPE_INCLUDE yes, no “yes” means VPE HWA is included in application DSS_INCLUDE yes, no “yes” means DSS HWA is included in application ISS_INCLUDE yes, no “yes” means ISS HWA is included in application ISS_ENABLE_DEBUG_TAPS yes, no “yes” means ISS Debug taps to dump intermediate ISS otuputs is enabled Page 10 of 30 WDR_LDC_INCLUDE yes, no “yes” means WDR, LDC feature of ISS is enabled RTI_INCLUDE yes, no “yes” means RTI features are enabled. ECC_FFI_INCLUDE yes, no “yes” means EFF, FFI features are enabled DCC_ESM_INCLUDE yes, no “yes” means DCC, ESM features are enabled. AVBRX_INCLUDE yes, no DCAN_INCLUDE yes, no “yes” means DCAN features are enabled RADAR_INCLUDE yes, no “yes” means Radar related algplugins and use-cases are enabled. This is top level flag to include or exclude Radar features. RADAR_BOARD none, TDA3XX_AR12_ALPS, Defines what is the board connected to the set up. Only valid for TDA3x SoC. Only valid for TDA3x SoC. “yes” means AVBRX features are enabled. Only valid for TDA2x, TDA2Ex SoC. TDA3XX_AR12_VIB_DAB_B OOSTER, TDA3XX_RADAR_RVP FAST_BOOT_INCLUDE yes, no “yes” means rear view camera fast boot features are enabled. SRV_FAST_BOOT_INCLUDE yes, no CPU_IDLE_ENABLED yes, no “yes” means, CPU will go to low power state when it is IDLE. DATA_VIS_INCLUDE yes, no “yes” means, Data Visualization feature is enabled OPENCL_INCLUDE yes, no “yes” means, OpenCL framework is included in application. ENABLE_OPENCV yes, no HS_DEVICE yes, no “yes” means “High Security” mode of application is enabled. DEFAULT_UBOOT_CONFIG dra7xx_evm_vision_config Config file used to build Linux uboot DEFAULT_KERNEL_CONFIG omap2plus_defconfig DEFAULT_DTB dra72-evm-infoadas.dtb Device tree file used dra7-evm-infoadas.dtb dra72-evm-infoadas.dtb is DTB file for TDA2Ex EVM Only valid for TDA3x SoC. “yes” means TDA3x surround view fast boot features are enabled Only valid for TDA3x SoC. Only valid for TDA2x SoC “yes” means, application. OpenCV framework is included in Only valid for TDA2x SoC Only valid when A15_TARGET_OS=Linux Config file used to build Linux kernel Only valid when A15_TARGET_OS=Linux dra7-evm-infoadas.dtb is DTB file for TDA2x EVM IPUMM_INCLUDE yes, no “yes” means IPUMM framework is included in application. Only valid when A15_TARGET_OS=Linux MUST set IVAHD_INCLUDE=no when this is enabled. IPC_LIB_INCLUDE yes, no ULTRASONIC_INCLUDE yes, no “yes” means the framework will use IPCLib in the PDK drivers. “no” (default) will use the SYSBIOS IPC libraries. “yes” means Ultrasonic support is included in application. Valid for TDA2xx Bios only build configuration. 4.2.2 Use-case selection config parameters These are typically specified in uc_cfg.mk which is included by cfg.mk These parameters have the format of o UC_ =yes Page 11 of 30 If a use-case is not required then comment the line or make the value as “no” or remove the line completely. o #UC_ =yes OR o UC_ =no is the name of the folder in which the use-case code is present o The folders where use-cases are located in Vision SDK are 4.2.3 “vision_sdk\apps\src\rtos\usecases” “vision_sdk\apps\src\rtos\radar\src\usecases” Linux+BIOS mode use-cases “vision_sdk\apps\src\hlos\adas\src\usecases” “vision_sdk\apps\src\hlos\infoadas\src\chains” Algplugin selection config parameters Algplugins are included based on use-case that is selected Every use-case folder has a cfg.mk file in which algplugins that are required for the use-case are marked as “yes” o Ex, “vision_sdk/apps/src/rtos/usecases/ /cfg.mk” These algplugin parameters have the format of If algplugin is not required then comment the line or remove the line completely. IMPORTANT: Do mark a ALG_ =no if it is not required by a usecase since some other use-case may need it is the name of the folder in which the algplugin code is present o o o ALG_ =yes #ALG_ =yes The folders where use-cases are located in Vision SDK are 4.2.4 BIOS ONLY mode use-cases BIOS ONLY mode use-cases “vision_sdk\apps\src\rtos\alg_plugins” “vision_sdk\apps\src\rtos\radar\src\alg_plugins” Linux+BIOS mode use-cases “vsdk_dev\vision_sdk\apps\src\hlos\adas\src\alg_plugins” CPUs required in application Users selected the CPUs they want in their application by marking the CPU as “yes” via the variable PROC_ _INCLUDE=yes The build system gives a hint to user if CPUs selected by user do match the CPUs required by the use-cases and config options selected by the user o In this case if user continues, the use-case or application may not run o The user should enabled these CPUs in their config Page 12 of 30 The build system also gives a hint to user if the CPUs selected by users are not used by the use-cases and config options selected by the user o In this case user can disable these CPUs in their config to save build time and application size These hints are told by the build system when “make showconfig” is done. It is also shown at the beginning of “make –s –j depend” As example log is shown below, in this log o it says IPU1_1 is not required in build and can be disabled from build. o It also EVE1 is required from the build and should be enabled in the build # # CPUs that are NOT required but included in config [ tda2xx_evm_bios_all ], # # WARNING: IPU1_1 can be excluded from application # # CPUs that are required but NOT included in config [ tda2xx_evm_bios_all ], # # ERROR: EVE1 MUST be included in application # # Edit D:/vision_sdk/build/configs/tda2xx_evm_bios_all/cfg.mk to include or exclude CPUs in an application # 4.3 Adding user specific build config Other than default build configs users can add their own build configs and give their own name to it. This is useful in scenario’s like below o Scenario 1: User is working on a subset of features and needs only few use-cases of alg-plugins o Scenario 2: User is working on features not enabled in default configs o Scenario 3: User is adding their own algplugin/use-case/feature to Vision SDK and needs specific features o Scenario 4: User is working on custom board in which features needed are different from default features To add a user specific config, it recommended to first identify a default config which is closest to user required config, ex, on the same SoC or same OS, or same board Identify a name for user config, say, “my_config” Next create “my_config” Copy the cfg.mk and uc_cfg.mk files from the closest “my_config” Edit cfg.mk and uc_cfg.mk in user config folder based on user required features Set the user config name in vision_sdk/build/Rules.make o a folder in “vision_sdk/$( MAKEAPPNAME)/configs” called default config to NOTE: config name is the folder name within MAKEAPPNAME)/configs” i.e “my_config” in this case “vision_sdk/$( Page 13 of 30 It is recommended showconfig” to confirm the config settings by doing “make All output files .o, .lib, .out from build this config will be placed in folder “vision_sdk/binaries/$( MAKEAPPNAME)/ ” o This way outputs from multiple configs can co-exists simulatenously o Hence user could be working on multiple indepedant configs on the same codebase at the same time Page 14 of 30 5 Make Targets and Command Line Options 5.1 Make Targets Below table lists the top level makefile targets that can be used by basic and advanced users Make targets are invoked on command line as shown below > make –s –j TIP: It is recommended to use make options “–s –j” when specifying a target. “-j” ensures make invokes targets in parallel whenever possible. “-s” hides detailed info and only shows important info on the console window 5.1.1 Basic User Targets Target Description help Show targets that can be invoked from top level make. showconfig Show current build config. depend Generate config, Build PDK, EDMA3LLD, touch dependant files vision_sdk Incremental build, build links framework and application specific targets (alg plug ins, use cases and other necessary modules) based on the $(MAKEAPPNAME). When no target is specified this is the target that is invoked. 5.1.2 appimage Generate bootable application image sbl Generate SBL including SBL firmware for SD boot, QSPI_SD and NOR boot modes (TDA3x, TDA2x, TDA2Ex) Advanced Targets These targets give more granular control on the modules to build. Here users known what part of the system has changed and therefore will build only the required part. TIP: when in doubt do “make –s –j depend” followed by “make –s –j”. This may will more time to build but it will ensure all dependencies get built. Target Description makeconfig Generate config related files. Also invoked internally by “depend”. Also invoked internally by “depend”. Use this when it is required to only generate the config header files pdk Build PDK. Also invoked internally by “depend”. Use this to only build the PDK drivers. edma3lld Build EDMA3LLD. Also invoked internally by “depend”. Use this to only build the starterware drivers. algorithmslib Build Algorithm development. links_fw_libs Build Vision SDK link framework library app_alg_plugins Build Vision SDK algo plugins apps_libs Build Vision SDK use cases and other necessary modules. libraries. Used by TI for internal Page 15 of 30 5.1.3 Linux Related Targets These targets are used when Linux runs on A15. Target Description linux Build linux kernel, uboot, sgx drivers linux_install Install kernel, uboot, sgx files into filesystem. Typically called after “linux” to copy the output files to filesystem and boot folder. vision_sdk_linux Build Vision SDK linux side library and binaries. Invoked as part of “vision_sdk” target. Use this when BIOS side code is build earlier and not modified further. uboot Build uboot. Also invoked as part of “linux” kernel Build kernel. Also invoked as part of “linux” sgx Build sgx drivers. Also invoked as part of “linux” 5.2 Command Line Options 5.2.1 Selecting CPU to build via command line In many situation user knows which part of the code they have modified and they know the CPU that needs to built for the new changes to take effect. When “make –s –j” is invoked it checks against all CPUs included in the application and then generates the required binaries. This process of checking even though nothing is changed for the other CPUs takes non-trivial time on some systems. To solve this, the build system allows user to specify exact CPUs to build for in such cases. This is specified by passing the list of CPUs to build for via the command line variable BUILD_CPUS=” ..” NOTE: An application consists on multiple CPUs. This is specified via the PROC_ _INCLUDE=yes in the config file. “BUILD_CPUS” only control if the files associated with that CPU are built or not. “BUILD_CPUS” is useful in incremental build context when all CPUs included in application are built atleast once and further build is required for only select CPUs for which user had done some file modifications. Some examples are shown below. Wildcard names can be used to specify CPUs, multiple CPUs can be specified as shown below. Example make command CPUs that get built make –s –j BUILD_CPUS=”ipu1_0” Build a single CPU ipu1_0 make –s –j BUILD_CPUS=”dsp*” Build all DSPs that are included in build make –s –j BUILD_CPUS=”ipu1_0 eve*” Build ipu1_0 and all EVEs make –s –j BUILD_CPUS=”ipu1* dsp1 eve*” Build ipu1_0, ipu1_1, dsp1 and all EVEs The detailed list of CPU names that can be passed in the “BUILD_CPUS” string value are listed below CPU name Description Page 16 of 30 5.2.2 ipu1_0 Build IPU1_0 CPU ipu1_1 Build IPU1_1 CPU ipu1* Build IPU1_0, IPU1_1 CPU ipu2 Build IPU2 CPU ipu* Build IPU1_0, IPU1_1, IPU2 CPU dsp1 Build DSP1 CPU dsp2 Build DSP2 CPU dsp* Build DSP1, DSP2 CPU eve1 Build EVE1 CPU eve2 Build EVE2 CPU eve3 Build EVE3 CPU eve4 Build EVE4 CPU eve* Build EVE1, EVE2, EVE3, EVE4 CPUs a15_0 Build A15_0 CPU a15* Build for all A15 Core’s all Build all CPUs Additional Command Line Options Following additional command line options can be used to further control the build form the make command line Example Command line option Description make –s –j PROFILE=debug Overides PROFILE value specified on config file and uses the one specified at command line. Use this to quickly switch between “debug” and “release” mode without having to modify config file make –s –j MAKECONFIG=”abcd_config” 6 Overirides MAKECONFIG value specified in Rules.make. Use this to use user defined config without modifying Rules.make file Adding new use-cases, algplugins to build The below section assumes usecases are located in “vision_sdk\$( MAKEAPPNAME)\src\rtos\usecases” and alg plugins are located in “vision_sdk\$( MAKEAPPNAME)\src\rtos\alg_plugins” 6.1 Adding new use-cases to build (BIOS ONLY mode) Follow below steps to add a new use-case to the build system. Page 17 of 30 1. Create a folder for the use-case, “my_usecase” in folder “vision_sdk\$( MAKEAPPNAME)\src\rtos\usecases” 2. Add .c files related to this use-case in this folder 3. Create a file “SRC_FILES.MK” in “my_usecase” folder 4. Open file “SRC_FILES.MK” for editing a. Add below line to include folder name in make build SRCDIR += $(vision_sdk_PATH)/$( MAKEAPPNAME)/src/rtos/usecases /my_usecase b. Add below line to include .c files for this use-case in make build SRCS_$(IPU_PRIMARY_CORE) += \ file1.c \ file2.c \ 5. Create a file “cfg.mk” in “my_usecase” folder 6. Open file ”cfg.mk” for editing a. Add variables for each ALG plugin required by this use-case and set to value “yes”. Alg plugin variable name is ALG_ . i. is name of folder present under “vision_sdk\apps\src\rtos\alg_plugins” b. Add variables for CPUs that are needed inorder to run this use-case and set value to “yes”. The CPUs needed variable name is NEED_PROC_ i. can be IPU1_0, IPU1_1, IPU2, DSP1, DSP2, EVE1, EVE2, EVE3, EVE4, A15_0 7. Open file “vision_sdk\$( MAKEAPPNAME)\configs\cfg.mk” for editing a. Add new use-case variable to list of use-cases. UC variable name format is UC_ i. Ex, UC_LIST = \ UC_avbrx_dec_display \ … UC_my_usecase 8. Open build config file “vision_sdk\$( MAKEAPPNAME)\configs\$(MAKECONFIG)\uc_cfg.mk“ a. Enable newly added use-case in build by making usecase variable name as “yes” i. Ex, UC_my_usecase=yes 9. Confirm the use-case is added correctly to config by doing “make showconfig” a. You should see your use-case listed under # Use-cases included in build, b. You should see the alg plugins that the use-case needs under, # Alg plugins included in build, 10. Open file \ vision_sdk\apps\src\rtos\common\chains_main_bios_misc.c a. We assume use-case will be added to “misc” submenu as an example b. Add menu-item string as shown below char gChains_menuMiscTests[] = { Page 18 of 30 "\r\n " "\r\n Miscellaneous Test's" "\r\n --------------------" "\r\n 1: File IO using MMCSD" #ifdef UC_my_usecase “\r\n 2: My usecase” #endif "\r\n " "\r\n x: Exit " "\r\n " "\r\n Enter Choice: " "\r\n " }; c. Invoke usecase entry point Function: Void Chains_menuMiscTestRun() switch(ch) { case '1': Utils_fileTestRun(); break; #ifdef UC_my_usecase Case ‘2’: MY_usecase_run(&gChains_usecaseCfg); break #endif 11. Build and run the application which includes the new use-case. Page 19 of 30 6.2 Adding new use-cases to build (Linux + BIOS mode) Follow below steps to add a new use-case to the build system. 1. Create a folder for the use-case, “vision_sdk\apps\src\hlos\adas\src\usecases” “my_usecase” in folder 2. Add .c files related to this use-case in this folder 3. Copy “MAKEFILE.MK” in “my_usecase” folder from an existing usecase folder under “vision_sdk\apps\src\hlos\adas\src\usecases”. This will setup same make options as other use-cases. 4. Create a file “cfg.mk” in “my_usecase” folder 5. Open file ”cfg.mk” for editing a. Add variables for each ALG plugin required by this use-case and set to value “yes”. Alg plugin variable name is ALG_ . i. is name of folder present under “vision_sdk\apps\src\rtos\alg_plugins” or “vision_sdk\apps\src\hlos\adas\src\usecases” or b. Add variables for CPUs that are needed inorder to run this use-case and set value to “yes”. The CPUs needed variable name is NEED_PROC_ i. can be IPU1_0, IPU1_1, IPU2, DSP1, DSP2, EVE1, EVE2, EVE3, EVE4, A15_0 6. Open file “vision_sdk\$(MAKEAPPNAME)\configs\cfg.mk” for editing c. Add new use-case variable to list of use-cases. UC variable name format is UC_ i. Ex, LINUX_TDA2XX_UC_LIST = \ UC_avbrx_dec_display \ … UC_my_usecase 7. Open build config file “vision_sdk\$(MAKEAPPNAME)\configs\$(MAKECONFIG)\uc_cfg.mk“ d. Enable newly added use-case in build by making usecase variable name as “yes” i. Ex, UC_my_usecase=yes 8. Confirm the use-case is added correctly to config by doing “make showconfig” e. You should see your use-case listed under # Use-cases included in build, f. 9. You should see the alg plugins that the use-case needs under, # Alg plugins included in build, Open file \vision_sdk\apps\src\hlos\adas\src\common\chains_main.c g. Add menu-item string as shown below char gChains_testMenu [] = { #ifdef UC_my_usecase “\r\n u: My usecase” #endif "\r\n " Page 20 of 30 "\r\n x: Exit " "\r\n " "\r\n Enter Choice: " "\r\n " }; h. Invoke usecase entry point Function: main() switch(ch) { #ifdef UC_my_usecase Case ‘u’: MY_usecase_run(&gChains_usecaseCfg); break #endif 10. Build and run the application which includes the new use-case. Page 21 of 30 6.3 Adding new alg plugins to build (BIOS side) Follow below steps to add a new alg plugin to the build system. 1. Create a folder for the use-case, “vision_sdk\apps\src\rtos\alg_plugins” “my_algplugin” in folder 2. Add .c files related to this alg plugin in this folder 3. Create a file “SRC_FILES.MK” in “my_algplugin” folder 4. Open file “SRC_FILES.MK” for editing a. Add below line to include folder name in make build SRCDIR += my_algplugin b. Add below line to include .c files for this use-case in make build SRCS_ += \ file1.c \ file2.c \ c. , is the name of the CPU for which the .c file should be compiled. This depends on the CPU on which the algorithm is supposed to run. i. Valid CPU names are arp32_1, c66xdsp_1, ipu1_0, a15_0 ii. NOTE: Algplugins are build once for a given CPU type so CPU name should refer to first instance of the CPU only 5. Open “vision_sdk\$(MAKEAPPNAME)\configs\cfg.mk” for editing a. Add new alg plugin variable to list of alg plugins. Alg plugin variable name format is ALG_ i. Ex, ALG_LIST = \ ALG_autocalibration \ … ALG_my_algplugin 6. Enable algplug in a required use-case cfg.mk file (see section 6.1 Adding new use-cases to build (BIOS ONLY mode)) 7. Confirm the alg-plugins is added correctly to config by doing “make showconfig” a. You should see your use-case listed under # Use-cases included in build, b. You should see the alg plugins that the use-case needs under, # Alg plugins included in build 6.4 Adding new alg plugins to build (Linux side) Follow below steps to add a new alg plugin to the build system. a.1. Create a folder for the use-case, “vision_sdk\apps\src\hlos\adas\src\alg_plugins” b.2. “my_algplugin” in folder Add .c files related to this alg plugin in this folder c.3. Copy “MAKEFILE.MK” in “my_algplugin” folder from an existing algplugin folder under “vision_sdk\apps\src\hlos\adas\src\alg_plugins”. This will setup same make options as other algplugins. d.4. Alg plugins on Linux side are always compiled and granular compile and selection is not supported for Linux side algplugins. Page 22 of 30 Formatted: Bullets and Numbering 6.5 Building Algorithm plugins for individual cores In current build configuration for algorithm plugins, to optimize build time, the plugin libraries are built only for single core of core family when more than one core is enabled. For example – only library for DSP1 will be built when both DSP1 & DSP2 are enabled; only EVE1 library will be built when EVE1/2/3/4 are enabled. Once library is built it is linked to other enabled cores. If first core is not enabled then library for second core would be built and used for subsequent cores. ifeq ($(PROC_IPU_BUILD_INCLUDE),yes) ifeq ($(PROC_IPU1_0_INCLUDE),yes) $(MAKE) $(TARGET) CORE=ipu1_0 else ifeq ($(PROC_IPU1_1_INCLUDE),yes) $(MAKE) $(TARGET) CORE=ipu1_1 endif endififeq ($(PROC_DSP_BUILD_INCLUDE),yes) ifeq ($(PROC_DSP1_INCLUDE),yes) $(MAKE) $(TARGET) CORE=c66xdsp_1 else ifeq ($(PROC_DSP2_INCLUDE),yes) $(MAKE) $(TARGET) CORE=c66xdsp_2 endif endif ifeq ($(PROC_EVE_BUILD_INCLUDE),yes) ifeq ($(PROC_EVE1_INCLUDE),yes) $(MAKE) $(TARGET) CORE=arp32_1 else ifeq ($(PROC_EVE2_INCLUDE),yes) $(MAKE) $(TARGET) CORE=arp32_2 else ifeq ($(PROC_EVE3_INCLUDE),yes) $(MAKE) $(TARGET) CORE=arp32_3 else ifeq ($(PROC_EVE4_INCLUDE),yes) $(MAKE) $(TARGET) CORE=arp32_4 endif endif So in the algorithm plugins SRC_FILES.MK you would need to make sure to add your plugin sources to SRCS_c66xdsp_1, SRCS_arp32_1 and SRCS_$(IPU_PRIMARY_CORE). Adding to SRCS_c66xdsp_2 or SRCS_arp32_2/3/4 when first core is enabled would have no effect and plugin wouldn’t be build. As the main file for DSPs, EVEs is common the algorithm plugin initialization happens for all enabled cores. This arrangement is done to save build time as plugin library is built only for one core. But it has following tradeoffs w.r.t binary size and run-time. Page 23 of 30 a. The build system doesn’t allow sources to be added to second core but not one. Also sources should be added to each of cores like c66xdsp_1, c66xdsp_2. b. In case you want to build plugin only on one core, you can’t do that. c. Plugin initiation happens even if plugin is not used on core. If you want to optimize run-time/size or want to enable plugin only on specified core you need to change makefile (vision_sdk\apps\src\rtos\alg_plugins\MAKEFILE.MK) to enable build on each cores like below. In addition to changing makefile you would need to change individual SRC_FILES.MK to add/remove sources for cores. ifeq ($(PROC_IPU_BUILD_INCLUDE),yes) ifeq ($(PROC_IPU1_0_INCLUDE),yes) $(MAKE) $(TARGET) CORE=ipu1_0 endif ifeq ($(PROC_IPU1_1_INCLUDE),yes) $(MAKE) $(TARGET) CORE=ipu1_1 endif endif ifeq ($(PROC_DSP_BUILD_INCLUDE),yes) ifeq ($(PROC_DSP1_INCLUDE),yes) $(MAKE) $(TARGET) CORE=c66xdsp_1 endif ifeq ($(PROC_DSP2_INCLUDE),yes) $(MAKE) $(TARGET) CORE=c66xdsp_2 endif endif ifeq ($(PROC_EVE_BUILD_INCLUDE),yes) ifeq ($(PROC_EVE1_INCLUDE),yes) $(MAKE) $(TARGET) CORE=arp32_1 endif ifeq ($(PROC_EVE2_INCLUDE),yes) $(MAKE) $(TARGET) CORE=arp32_2 endif ifeq ($(PROC_EVE3_INCLUDE),yes) $(MAKE) $(TARGET) CORE=arp32_3 endif ifeq ($(PROC_EVE4_INCLUDE),yes) $(MAKE) $(TARGET) CORE=arp32_4 endif endif Page 24 of 30 7 Adding new system config parameters to build config In some situation users need to add new config parameters and export them throughput the make system as well within the .c, .h files. This can be done as shown below 1. Consider users wants to add a variable MY_CFG_VAR which can take value “CFG_A”, “CFG_B” 2. Make this config value visible to C code by doing below a. Open and edit file “\vision_sdk\build\rtos\makerules\component.mk” b. Add lines for each value the config option can take ifeq ($(MY_CFG_VAR), CFG_A) vision_sdk_CFLAGS += -DMY_CFG_VAR_CFG_A endif ifeq ($(MY_CFG_VAR), CFG_B) vision_sdk_CFLAGS += -DMY_CFG_VAR_CFG_B endif 3. Export this variable throughout the make system by doing below. a. Add export MY_CFG_VAR in file \vision_sdk\$(MAKEAPPNAME)\configs\autorules_footer_cfg.mk 4. Set default value for this \vision_sdk\$(MAKEAPPNAME)\configs\defaults.mk variable in file a. Ex, MY_CFG_VAR=CFG_A 5. Set value for this config variable in config required \vision_sdk\$(MAKEAPPNAME)\configs\$(MAKECONFIG)\cfg.mk file 6. Now #ifdef MY_CFG_VAR_CFG_A or #ifdef MY_CFG_VAR_CFG_B can be used in .c, .h file to control C code based on this config value 7. Now MY_CFG_VAR can be used in make system to control the make build Page 25 of 30 8 Adding new library to application User may have separate build system to compile and make libraries for a specific CPU. This section shows how to make the Vision SDK application link to these libraries 1. Identify the CPU type to which the library belongs. Assume name of the library is “mylib.lib” and is present in folder “vision_sdk/mylibs” 2. Open and edit file \vision_sdk\build\rtos\makerules\rules_ .mk a. , can be m4, a15, arp32 (for EVE), 66 (for DSP) b. Goto position file where LIB_PATHS += is used to link to libraries c. Add your library to this list LIB_PATHS += $(vision_sdk_PATH)/mylibs/mylib.lib” 9 Changing compiler, linker options User may want to add or check CPU specific compiler, linker options. This section shows how to do the same 1. Identify the CPU type for which compiler, linker options needs to be reviewed, modified. 2. Open and edit file \vision_sdk\build\rtos\makerules\rules_ .mk a. , can be m4, a15, arp32 (for EVE), 66 (for DSP) b. CFLAGS_INTERNAL variable holds the compiler flags. Modify this as required. c. LNKFLAGS_INTERNAL_PROFILE variables holds the linker flags. Modify this as required. Page 26 of 30 10 Build Config Implementation Details (Advanced Users) 10.1 Build config generated .h file 10.2 The process of applying make config generates a .h file at below location “vision_sdk\links_fw\include\config\$(MAKEAPPNAME)\$(MAKECONFIG)\syste m_cfg.h”. Users need to include the file #include < system_cfg.h > to get access to config options in their C code Build config makefiles Build config makefiles are located at path “vision_sdk\$(MAKEAPPNAME)\configs” and below table list the purpose of each file File Description cfg.mk Top level config file which further includes the user specified config file. Also lists all the possible algplugins, use-cases in the system. This list is used to pick the algplugins, usecases based on values set by user in config files defaults.mk Default values for config variables autorules_header_cfg.mk Derived variables or rules that are applied before including build tools autorules_footer_cfg.mk Derived variables or rules that are applied after including build tools build_makeconfig.mk Build config related make targets. Invoked from top level makefile via “makeconfig” and “showconfig” targets Page 27 of 30 11 Add and Delete links into links framework The links framework is highly modularized. Each link is treated as a module and a library is created for it. This makes addition and deletion of the links very convenient. 11.1 Adding a link Each link source folder has the following 3 files present along with the link source *.c files. component.mk makefile SRC_FILES.MK The ‘component.mk’ file defines the Module Name (MODNAME) for the link, the name of the library created will have the same name. It adds the link to the list of links framework libs (linksfw_LIB_LIST) and defines the following parameters for the link: $(MODNAME)_PATH : Absolute path of the link source $(MODNAME)_BOARD_DEPENDENCY : yes/no $(MODNAME)_CORE_DEPENDENCY : yes/no $(MODNAME)_PLATFORM_DEPENDENCY : yes/no $(MODNAME)_SOCLIST : list of supported SoCs $(MODNAME)_$(SOC)_CORELIST : list of supported Cores The ‘makefile’ includes the list of internal and external dependencies and includes the link’s SRC_FILES.MK file. The SRC_FILES.MK file populates the SRC_COMMON and SRC_$(CORE) make rules variables with the link’s *.c files which are required to be compiled. After the above files are created for the link an entry for the link should be made into the top level ‘linksfw_component.mk’ file: For eg, -include $(vision_sdk_PATH)/links_fw/src/rtos/links_common/algorithm/component.m k The ‘-include’ option doesn’t throw error even when the link folder is not present. Now open the ‘\vision_sdk\links_fw\src\rtos\links_common\system\system_initDeinitLinks.c’ file, add link init and deInit calls in the System_initLinks() and System_deInitLinks() functions respectively under ‘#define ’ as shown below: Void System_initLinks(void) { Vps_printf(" SYSTEM: Initializing Links !!! \r\n"); Page 28 of 30 /* Links init based on the links which are part of the build */ #ifdef links_common_avb_rx AvbRxLink_init(); #endif . . Vps_printf(" SYSTEM: Initializing Links ... DONE !!! \r\n"); } Void System_deInitLinks(void) { Vps_printf(" SYSTEM: De-Initializing Links !!! \r\n"); /* Links de init based on the links which are part of the build */ #ifdef links_common_avb_rx AvbRxLink_deInit(); #endif . . Vps_printf(" SYSTEM: De-Initializing Links ... DONE !!! \r\n"); } 11.2 Deleting a link The link can be deleted from the links framework by Deleting the link source code. Removing the entry for the link from the linksfw_component.mk file NOTE: Whenever a link is added or deleted ‘make –s –j depend’ should be run so that system cfg files are regenearated. Page 29 of 30 12 Revision History Version Date Revision History 0.1 02nd Oct 2016 First Draft th 0.2 05 July 2017 0.3 18 Dec 2017 th Updated for Vision SDK release 3.0 Updated with algorithm plugin build support for individual cores. Page 30 of 30
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.5 Linearized : No Page Count : 30 Language : en-US Tagged PDF : Yes Title : VisionSDK_NetworkTools_UserGuide Author : TI Creator : Microsoft® Word 2010 Create Date : 2017:12:22 14:31:45+05:30 Modify Date : 2017:12:22 14:31:45+05:30 Producer : Microsoft® Word 2010EXIF Metadata provided by EXIF.tools