Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Development Strategy of DM8127 for Image recognition-- Analysis and compilation of RDK Software Architecture

2025-01-15 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

Shulou(Shulou.com)06/03 Report--

The previous article "Image recognition DM8127 Development Strategy-Development Environment Building" introduced the construction of the development environment of DM8127, so this article begins to describe the architecture of the entire IPNC RDK. If you are not familiar with this IPNC RDK, the migration work can not be carried out, nor can you learn and master the development process of DM8127 in depth. To be familiar with the APPRO DM8127 software architecture, first look at IPNC_RDK_InstallGuide.pdf, and then look at the two important files in the Collaterals file directory in the RDK package: IPNC_RDK_McFW_UserGuide.pdf and IPNC_RDK_Application_DesignGuide.pdf, which are mentioned in the following introduction.

The contents of the Source folder of the software package in IPNC_RDK, it is more appropriate to understand the software architecture of DM8127 by screenshot.

The image above is the core of the RDK package, ipnc_rdk and ti_tools.

Among them, ipnc_rdk mainly has 4 folders, as well as the most important total Makefile and total Rules.make, those build_xx_xx.sh scripts are added by myself.

There are many TI toolkits in the ti_tools directory, as shown in the following figure:

1. Introduction of ti_tools

Let's start with ti_tools, which contains many compilation kits and LIB files provided by TI

1. Ipnc_psp_arago stores the u-boot (u-boot-2010.06) and kernel (linux-2.6.37) source code that we need to transplant. The compilation and migration of u-boot, the compilation and migration of kernel will be introduced in later articles. There is also a docs folder under this folder, which contains a lot of documentation related to driver migration.

2. Iss_03_80_00_00: it is also a software package that needs to be transplanted. All debugging CMOS SENSOR drivers (such as adding a new SONY IMX, OV, ON, etc. CMOS SENSOR) need to be debugged in this software package, including LVDS interface acquisition RAW DATA, parallel port driver acquisition RAW DATA,BT656 interface acquisition YUV422 DATA,BT1120 interface acquisition YC DATA, etc., as well as CMOS 2A (automatic white balance, automatic exposure) algorithm, noise reduction processing. All transplant and debug in this iss_03_80_00_00 directory, focusing on the source code in the iss_03_80_00_00/packages/ti/psp/ directory, which is completely different from the previous drivers such as DM6446, DM3730, and V4L2 added to the kernel. The difference between DM8127 and DM8147-8148-8168 lies in this iss module. DM8127 has ISP function and can be connected to CMOS in RAW DATA format.

3. Linux_devkit is the ARM cross-compilation tool of the DM8127 platform, and APPRO is integrated into this ti_tools.

4, other ti_tools software packages are ready-made LIB or DSP compilation tools, the two ARM CORTEX-M3 core compilation tools are also here, these tools do not need us to port development, you can go to the corresponding folder to understand.

II. Introduction to ipnc_rdk

1. Under the ipnc_rdk/ipnc_app directory:

The above pictures are all top-level linux app applications, in which ty_app is added by myself, in which there are self-written gpio applications, rs232 test programs, rs485 test programs, and so on. For other APP introductions, please take a look at IPNC_RDK_Application_DesignGuide.pdf, which has a detailed description. When DM8127 RDK runs a DEMO program, it usually starts with the sys_server source code. We might as well learn from the NFS file system, that is, the script of ipnc_rdk/target/filesys/etc/init.d/finish_ubifs.sh:

Cd / opt/ipnc

. / init.sh

. / system_server

Sleep 7

. / autorun_ipnc.sh

Executing system_server is the application that performs sys_server compilation.

Other web server programs, network programs (including boa and live555, which we are very familiar with) do not need to be introduced. You can understand these functions at a glance. When you run system_server, you can also run these applications at the same time and execute them in autorun_ipnc.sh.

2. Target directory

The filesys in this directory is the NFS file system we used when developing, which was introduced in the previous article "Image recognition DM8127-- Development Environment Building".

3 、 tftp

We don't use this file, and it can also be used as a folder to temporarily save BIN files. Our TFTP SERVER is placed in the linux ubuntu host / tftpboot directory.

4. The most important ipnc_mcfw

Mcfw: Multi Channel Framework multi-channel frame synchronization mechanism. We need to work with IPNC_RDK_McFW_UserGuide.pdf to analyze this mcfw, mainly to understand how the video data stream works synchronously among VPSS CORTEX-M3, VIDEO CORTEX-M3, CORTEX-A8 and C674X DSP.

A 、 ipnc_mcfw/bin

Ipnc_mcfw/bin/ti814x has compiled mcfw module out of some of the corresponding executable files, LIB, driver file KO, in addition, scripts has the corresponding running script, you can go in and see. The compiled executable, LIB, driver file KO, running scripts in scripts, and init.sh scripts are all COPY to the NFS file system target/filesys/opt/ipnc directory, which will be mentioned later in the compilation description.

B 、 ipnc_mcfw/build

This folder holds most of the temporary files for compiling mcfw, .obj files, as well as some LIB files, driver temporary files. Four core compiled temporary files are placed in this directory, this management I prefer, unlike UBOOT and KERNEL these compiled temporary files are put under the same file, it is difficult to back up.

C 、 ipnc_mcfw/demos/

Focus on the source code under the mcfw_api_demos/ multich_usecase and stream folders, which are IPNC DEMO applications.

D 、 ipnc_mcfw/makerules/

The compilation rule-level compilation scripts with four cores are very important. I spent some time studying how these four cores are compiled, and how to support the compilation of .cpp source files when porting C++ algorithm on the DSP side, all of which need to be modified under these scripts. If you are afraid of correcting errors, back up the bk first and then modify them. Some parameters of these compilation rules scripts do not understand. You can look at the makerules_spec.doc of the docs folder in the same directory.

E 、 ipnc_mcfw/mcfw

The most useful core part of the whole DM8127 RDK is this mcfw. Four cores work together with the source code, of which M3 VPSS, M3 VIDEO and C674X DSP are all compiled using BIOS, so their code is placed in src_bios6, while CORTEX-A8 is placed in src_linux. For example, if you add your own DSP algorithm, you can put it in the links_c6xdsp/alg directory. If you want to do some CMOS SENSOR front-end collection in M3 VPSS, you can process it in links_m3vpss. If you want to do some code migration before H264 compression and decoding, you can work in M3 VIDEO, that is, links_m3video directory. For example, we add our own company's (ty) tasks in M3 VPSS core: links_m3vpss/tyLink/tyLink_tsk.c and tyLink_priv.h. Then modify the SRC_FILES.MK of the previous directory so that tyLink_tsk.c is compiled to. The source code in links_common can be shared by DSP core, M3 VPSS core and M3 VIDEO core, which requires attention. On the Internet, there has been an article by other netizens on how to add an example of running algorithms on the DSP side in this mcfw directory (http://blog.csdn.net/guo8113/article/details/20149191), which is mainly implemented on the DM8148/DM8168 platform. In fact, it is exactly the same as DM8127 and can be used for reference directly. There is also a direct use of TI off-the-shelf links_common/null/nullLink_tsk.c to add the DSP interface, so that nullLink_tsk.c is compiled separately by DSP, rather than as an M3 program, and then go to src_linux/mcfw_api/usecases/xxxx.c to System_linkCreate () this task.

We can use the following figure to learn more:

The picture above shows a classic video data stream communicating between four cores.

A) first, the RAW DATA image data of 1080p is collected from CMOS SENSOR, and the CAMERA LINK is established in the core of M3 VPSS to process the image data. First, the RGB format is converted to YUV format.

B), then ISS uses two Resizer, Resizer An and Resizer B, to further process the YUV format. Resizer-A converts the 1080p data into YUV420SP (Y component independent storage, UV cross independent storage), which is uniformly saved to the cache queue dup [0] (which is actually a large independent memory space). Resizer-B is also Resizer the original YUV format to reduce the standard definition image to 720480, which is also YUV420SP (Y component independent storage, UV cross independent preservation), and uniformly saved to dup [1] another independent cache queue, which is separate from the above dup [0]. In other words, the 1080p data of dup [0] is taken to M3 VIDEO core to H264 coding, and the 720480 data of dup [1] is taken to DSP core for video analysis.

C), through a link mechanism, the M3 VPSS core outputs data to the M3 VIDEO core, and the M3 VIDEO core gets the data of dup [0] (in fact, a pointer queue, shared memory), and then encodes it with H264. At the same time, it also outputs the dup [0] data directly to the HDMI interface through the link mechanism. Another piece of data dup [1] passes the pointer to DSP TSK through the link mechanism. For example, we use the nullLink_tsk.c interface to call our algorithm, or we use the link mechanism to output SD 720Secret480 to the CVBS interface for display. Of course, the format of CVBS is YUV422, which should be noted.

D), the data of Dup [0] is encoded by H264 Enc and transmitted to CORTEX-A8 in the form of BIT stream through link mechanism, so that applications running by A8, such as live555, can get this bit stream for WEB playback.

For the link mechanism mentioned above, you need to see the TI MCFW user manual and cooperate with the program to analyze. In short, after understanding the explanation of the above figure, you should have a preliminary understanding of the architecture of DM8127 MCFW, not confused. My ability is average, just got the APPRO board, also do not know how to learn, even if read many times that a lot of documents, still did not grasp the essence of the picture above, and then to engage in the product design of big customers, this one is suspended. Later, when I had time to cooperate with the program analysis, and after a superficial explanation, I got a good understanding of the data flow of this MCFW. In particular, I hired a project manager who had done DM385 with a high salary. He was quite familiar with this mcfw and related link mechanism, and helped me solve a lot of problems. We cooperated with each other, and we quickly transplanted the previous DM3730 video analysis algorithm, and ran relatively stable. Of course, the running efficiency of the algorithm is much higher than DM3730 fixed-point DSP. DM8127 floating-point DSP is good. Many floating-point operations do not consider optimization at all. The entire floating-point DSP specializes in video analysis algorithms, transmitting the analyzed target coordinates and other parameters to other cores on OK, and there is no need to do redundant tasks at all.

General introduction of Rules.make and Makefile

Ipnc_rdk/Rules.make and ipnc_rdk/Makefile are the most important compilation scripts for the entire RDK package and must be thoroughly eaten.

1. Let's first introduce Rules.make:

SYSTEM_PLATFORM: = IPNC (APPRO IPNC_RDK is designed for high-definition webcam products, not DM8148's EVM development kit for TI's own development board)

APP_BUILD_CFG: = release (indicates that the program compiled when compiling RDK is in product release mode, and a lot of debugging information can be removed. If debug is used, it is needed when programming, compiling, debugging and running)

BINARY_MODE: = nand (indicates that the compiled uboot min is in NAND FLASH mode, and the compiled uboot min and uboot are to be burned into NAND. If it is: = sd means that the compiled uboot min is a MLO file, which is put into the SD card and used for factory production and NAND debugging when there is no program)

IPNC_DEVICE: = DM8127 (choose DM8127 platform, which of course also supports DM385 and DM388 platforms without DSP)

IPNC_CONFIG: = FULL_FEATURE (we use DSP and must CORETEX-A8 run 1G frequency, DSP run 750MHz mode)

MEMORY_CONFIG: = 512MB (we Tongye Technology DM8127 core board uses 512MB bytes of DDR3 memory, 256MB is simply not enough, because we have DSP)

MTD_UTILS_MODE: = 32bit (for the compilation problem of ipnc_rdk / target/ mtd-utils, if your linux development host is 64bit, then choose 64bit here, and our virtual machine here still uses 32bit, so choose 32bit here, make no mistake)

IMGS_ID: = IMGS_MICRON_AR0330 (for example, if you use the cheap AR0330 2 million CMOS SENSOR, this macro definition is defined here. Some header files of the source code in RDK need to be added to this macro definition, and the iss_03_80_00_00/packages/ti/psp/devices/ ar0330 driver will be compiled in the iss module.)

WDR_ON: = YES (enable this if your CMOS SENSOR supports wide dynamics)

LOW_POWER_OPP100_MODE: = NO (this choice of NO means that the power management mode uses full speed, non-low power consumption, similar to the FULL_FEATURE above, if you choose YES,DM8127 CORTEX-A8 to run 600m and DSP to run 500MHz)

AES_MODULE_MODE: = OFF (indicates whether the various program modules in the compiled RDK package need to be published in AES encryption)

BUILD_WARNINGS_AS_ERROR: = NO (here our company chooses NO because when compiling RDK, if you choose YES, some defined variables are not used, the compiler will regard this warning as an error and stop compiling, which is very annoying)

CAPTURE_DISPLAY_MODE_ON: = YES

RAMES_TO_A8: = NO

(here is the program of what mode the user wants to use to use this IPNC RDK. The selection here corresponds to the example of src_linux/mcfw_api/usecases/multich_capturedisplay.c, which supports this IPNC device to collect CMOS SENSOR 1080p and 1080p HDMI display output.)

Other globally compiled macro definitions can be directly used by RDK default, and it is important to note those path macro definitions, such as:

BASE_INSTALL_DIR: = $(shell pwd) /..

# Defining the install base directory for IPNC RDK

IPNC_INSTALL_DIR: = $(BASE_INSTALL_DIR) / ipnc_rdk

TOOLS_INSTALL_DIR: = $(BASE_INSTALL_DIR) / ti_tools

# The directory that points to the Linux Support Package

Lsp_PATH: = $(TOOLS_INSTALL_DIR) / ipnc_psp_arago

KERNELDIR: = $(lsp_PATH) / kernel

UBOOTDIR: = $(lsp_PATH) / u-boot

# The directory that points to where filesystem is mounted

FILESYS_INSTALL_DIR: = $(IPNC_INSTALL_DIR) / target

TARGET_FS: = $(FILESYS_INSTALL_DIR) / filesys / / NFS file system path

TARGET_APP: = $(FILESYS_INSTALL_DIR) / ipnc

TARGET_FS_DIR: = $(TARGET_FS)

MTD_UTILS: = $(FILESYS_INSTALL_DIR) / mtd-utils/$ (MTD_UTILS_MODE)

# The directory that points IPNC RDK source code

MCFW_ROOT_PATH: = $(IPNC_INSTALL_DIR) / ipnc_mcfw

IPNC_DIR: = $(IPNC_INSTALL_DIR) / ipnc_app

# The directory to root file system

ROOT_FILE_SYS:= $(TARGET_FS)

# target filesystem.

EXEC_DIR:=$ (TARGET_FS) / opt/ipnc / / NFS file system corresponds to the executable file save path

The definitions behind Rules.make are easy to understand, defining paths to some global variables, and macro definitions.

2. Introduce the general Makefile

The total Makefile starts by include the scripts under the general Rules.make and ipnc_mcfw/makerules/ introduced above.

Then there are many compilation modules (targets) below, and the program compilations of the four cores are all in this total Makefile to define compilation. Each module is compiled as follows:

Xxxx:

Xxxx_clean:

Xxxx_all:

Pattern

If you are not familiar with some script definitions, you can insert them in Makefile:

For example: echo "Hardware Platform: $(IPNC_DEVICE) $(SYSTEM_PLATFORM)"

To print the compilation information in this way, note that the tab key is required before echo.

The total Makefile compilation needs to be viewed in conjunction with the IPNC_RDK_InstallGuide.pdf file.

In fact, a general: make sysall, you can compile all the modules to be developed, but it is impossible to go to make sysall during development, which is a waste of time and no need to develop software at all. We have to compile all the modules involved in make sysall separately, so that we need to develop which module to compile. After make sysall, you will COPY the compiled applications, BIN files, LIB, etc., to the corresponding folders of the NFS file system. See:

Fsupdate:

Cp-R $(TARGET_MCFW_DIR) / $(EXEC_DIR) /.

Chmod 755 $(EXEC_DIR) / .sh

Here we need to mention a script made by APPRO itself, which will execute inpc_app/ root_filesys/Makefile when compiling ipnc_app (that is, make app). First of all, we can ask him to execute the Makefile, as shown in the figure below, it will COPY the corresponding files to the corresponding folder of our NFS file system. But when we debug some NFS scripts, we make changes, such as target/ filesys/etc/ init.d/ finish_ubifs.sh, target/ filesys/opt/ipnc/init.sh and other script modifications, if we execute make sysall again, if we do not back up, we will overwrite the script contents of our modified NFS file system, which is very annoying. We have done this inpc_app/ root_filesys/Makefile once, and after that, we will directly block the contents of the inpc_app/ root_filesys/Makefile, so that we do not need to overwrite it many times. The following figure is inpc_app/ root_filesys/Makefile, which can block the install operations in it after one execution.

IV. SDK compilation process

The above picture is I according to the general Makefile, I separately do the compilation script, separate each module, so that it is convenient for each module to develop and compile, compile build plus 1-2-3-4-5-6-7 and other figures, let you know at a glance how to compile and develop the entire RDK software. The hardware startup process of DM8127 has been described in the previous "Image recognition DM8127 Development Guide-Board Boot process", and the compilation process here also corresponds to that article. All of these build scripts must be compiled under the corresponding path in the figure above, that is:

/ home/davinci/dm8127/v3.8.0/Source/ipnc_rdk/

Including the manual use of make xxxxx, the compilation is performed under this path.

Build_1_uboot-min-nand.sh script content: make ubootmin

Is to compile ubootmin, as the name implies, specifically used to burn BIN files written to NAND FLASH.

The corresponding total Makefile content is:

Ubootmin:

$(MAKE) ubootclean

$(MAKE) ubootbuild MAKE_TARGET=$ (PLATFORMCFG) $(SYSTEM_CFG) min$ (BINARY_MODE)

$(MAKE) ubootbuild MAKE_TARGET=u-boot.ti

Ifeq ($(BINARY_MODE) sd)

Cp $(UBOOTDIR) / umurboot.min.$ (BINARY_MODE) $(TFTP_HOME) / MLO

Cp $(UBOOTDIR) / umurboot.min.$ (BINARY_MODE) $(UBOOTDIR) / MLO

Else

Cp-f $(UBOOTDIR) / umurboot.min.$ (BINARY_MODE) $(TFTP_HOME) / umurboot.min.$ (BINARY_MODE)

Cp-f $(UBOOTDIR) / umurboot.min.$ (BINARY_MODE) $(UBOOTDIR) / umurboot.min.$ (BINARY_MODE) .bk

Cp-f $(UBOOTDIR) / umurboot.min.$ (BINARY_MODE) / tftpboot/dm8127_min.bin

Endif

Build_1_uboot-min-sd.sh script content: make uboot_ty_sd

Compiling ubootmin and uboot at the same time, only compiling MLO and u-boot.bin files, COPY to SD card, using SD card BOOT board.

The corresponding total Makefile content is (added and modified by yourself):

Uboot_ty_sd:

$(MAKE) ubootclean

$(MAKE) ubootbuild MAKE_TARGET=$ (PLATFORMCFG) $(SYSTEM_CFG) _ min_sd

$(MAKE) ubootbuild MAKE_TARGET=u-boot.ti

Cp-f $(UBOOTDIR) / u-boot.min.sd $(IPNC_INSTALL_DIR) / tftp/$ (IPNC_DEVICE) / sd/MLO

Cp-f $(UBOOTDIR) / u-boot.min.sd $(UBOOTDIR) / MLO

$(MAKE) ubootclean

$(MAKE) ubootbuild MAKE_TARGET=$ (PLATFORMCFG) $(SYSTEM_CFG) _ config_nand

$(MAKE) ubootbuild MAKE_TARGET=u-boot.ti

Cp-f $(UBOOTDIR) / u-boot.bin $(IPNC_INSTALL_DIR) / tftp/$ (IPNC_DEVICE) / sd/

Build_2_uboot-all.sh script content: make ubootbin

Compile uboot to get dm8127_uboot.bin for burning to NAND FLASH.

Ubootbin:

$(MAKE) ubootclean

$(MAKE) ubootbuild MAKE_TARGET=$ (PLATFORMCFG) $(SYSTEM_CFG) config$ (BINARY_MODE)

$(MAKE) ubootbuild MAKE_TARGET=u-boot.ti

Cp-f $(UBOOTDIR) / u-boot.bin $(TFTP_HOME) / u-boot.bin

Cp-f $(UBOOTDIR) / u-boot.bin $(UBOOTDIR) / dm8127_uboot.bin.bk

Cp-f $(UBOOTDIR) / u-boot.bin / tftpboot/dm8127_uboot.bin

Build_2_uboot-tmp.sh script content: make uboot_ty

Also compile uboot to get dm8127_uboot.bin for burning to NAND FLASH. Only when porting and developing UBOOT, only modify a .c or .h file, then when compiling, there is no need to use ubootclean to empty all OBJ and compile again, which is too time-consuming.

The corresponding total Makefile content is:

Uboot_ty:

$(MAKE) ubootbuild MAKE_TARGET=$ (PLATFORMCFG) $(SYSTEM_CFG) config$ (BINARY_MODE)

$(MAKE) ubootbuild MAKE_TARGET=u-boot.ti

Cp-f $(UBOOTDIR) / u-boot.bin $(TFTP_HOME) / u-boot.bin

Cp-f $(UBOOTDIR) / u-boot.bin $(UBOOTDIR) / dm8127_uboot.bin.bk

Cp-f $(UBOOTDIR) / u-boot.bin / tftpboot/dm8127_uboot.bin

Build_3_kernel-menuconfig.sh script content: make lspmenu

The corresponding total Makefile content is:

Lspbuild:

Make-C $(KERNELDIR) ARCH=arm CROSS_COMPILE=$ (BUILD_TOOL_PREFIX) $(MAKE_TARGET)

Lspmenu:

Make lspbuild MAKE_TARGET=menuconfig

I won't say much about the familiar interface for configuring kernel options. After selecting some features and modules, the save configuration file will get the .config file under the kernel folder. I like to back up:

Cp-f $(KERNELDIR) / .config $(KERNELDIR) / dm8127_2017xxxxaaa.config

Then overwrite the backup file with the file $(KERNELDIR) / arch/arm/configs/ti8148_ipnc_ubifs_defconfig:

Cp-f $(KERNELDIR) / dm8127_2017xxxx.config $(KERNELDIR) / arch/arm/configs/ti8148_ipnc_ubifs_defconfig

Subsequent kernel compilations use this ti8148_ipnc_ubifs_defconfig configuration file.

Build_3_kernel-all.sh script content: make lsp_ty

The corresponding total Makefile content is:

Cmem:

Make-C $(linuxutils_PATH) / packages/ti/sdo/linuxutils/cmem/src/interface\

LINUXKERNEL_INSTALL_DIR=$ (KERNELDIR) MVTOOL_PREFIX=$ (BUILD_TOOL_PREFIX)

Make-C $(linuxutils_PATH) / packages/ti/sdo/linuxutils/cmem/src/module\

LINUXKERNEL_INSTALL_DIR=$ (KERNELDIR) MVTOOL_PREFIX=$ (BUILD_TOOL_PREFIX)

Cmemclean:

Make-C $(linuxutils_PATH) / packages/ti/sdo/linuxutils/cmem/src/module clean

Make-C $(linuxutils_PATH) / packages/ti/sdo/linuxutils/cmem/src/interface clean

Lspcfg:

Make lspbuild MAKE_TARGET=$ (PLATFORMCFG) $(SYSTEMCFG) $(FS_CFG) _ defconfig

Lsp:

Cp $(linuxutils_PATH) / packages/ti/sdo/linuxutils/cmem/src/module/cmemk.o $(KERNELDIR) / drivers/char/

Make lspcfg

Make lspbuild MAKE_TARGET=uImage

Make lspbuild MAKE_TARGET=modules

Cp $(KERNELDIR) / arch/arm/boot/uImage $(TFTP_HOME) / uImage

Cp $(KERNELDIR) / arch/arm/boot/uImage $(KERNELDIR) / dm8127_kernel.bin.bk (added by myself)

Cp-f $(KERNELDIR) / arch/arm/boot/uImage / tftpboot/dm8127_kernel.bin (added by myself)

-mkdir-p $(TARGET_MCFW_DIR) / kermod

Cp $(KERNELDIR) / drivers/video/ti81xx/vpss/vpss.ko $(TARGET_MCFW_DIR) / kermod/.

Cp $(KERNELDIR) / drivers/video/ti81xx/ti81xxfb/ti81xxfb.ko $(TARGET_MCFW_DIR) / kermod/.

Cp $(KERNELDIR) / drivers/video/ti81xx/ti81xxhdmi/ti81xxhdmi.ko $(TARGET_MCFW_DIR) / kermod/.

Cp $(KERNELDIR) / drivers/usb/gadget/g_file_storage.ko $(EXEC_DIR)

Cp $(KERNELDIR) / block/sbull/sbull.ko $(EXEC_DIR)

Lspclean:

Make lspbuild MAKE_TARGET=distclean

Lsp_ty:

# make binariesclean

Make cmemclean

Make lspclean

Make lspcfg

Make-C $(KERNELDIR) ARCH=arm CROSS_COMPILE=$ (BUILD_TOOL_PREFIX) prepare

Make-C $(KERNELDIR) ARCH=arm CROSS_COMPILE=$ (BUILD_TOOL_PREFIX) modules_prepare

Make cmem

Make lsp

As you can see from the above script, the cmem module (the most important shared memory mechanism of ARM+DSP) must be compiled before compiling the kernel, which is the same as DM6446-DM3730, except that those are compiled independently, and kernel compilation is also independent, and now DM8127 integrates this cmem to compile. There are also kernel driver modules with option (M), which are also integrated into a script to compile, and then COPY the corresponding .ko file to the corresponding path. Also note that before compiling kernel, you must compile UBOOT, because using an image tool in UBOOT, if uboot is finished with temporary files by clean, the final steps of compiling the kernel will not pass here.

Build_3_kernel-tmp.sh script content: make lsp

The corresponding total Makefile content is: see the description above. That is, compiling a source file, then recompiling the entire kernel clean without compilation, is a waste of your life time.

Build_4_syslink.sh script content: make syslinkall

The corresponding total Makefile content is:

Syslinkbuild:

Cp $(MCFW_ROOT_PATH) / makerules/syslink_products.mak $(syslink_PATH) / products.mak

Make-C $(syslink_PATH) $(TARGET)

Syslink:

Make syslinkbuild DEVICE=$ (syslink_DEVICE) TARGET=syslink

-mkdir-p $(TARGET_MCFW_DIR) / kermod

Cp $(syslink_OUT_DIR) / syslink.ko $(TARGET_MCFW_DIR) / kermod/.

Syslinkclean:

Make syslinkbuild DEVICE=$ (syslink_DEVICE) TARGET=clean

Syslinkall: syslinkclean syslink

DM8127 four cores need link mechanism to coordinate work, this module is the underlying source code, but TI shields these underlying things, we just need to compile, there is no need to modify the source code of such a complex module.

Build_5_ipncapp-all.sh script content: make all

The corresponding total Makefile content is:

Ipncapp: app hdvpss iss mcfw fsupdate

Clean: appclean hdvpssclean issclean mcfwclean

All: clean ipncapp

Applibs:

Ifneq ($(MAKE_TARGET) depend)

$(MAKE)-C $(IPNC_DIR) ARCH=arm CROSS_COMPILE=$ (BUILD_TOOL_PREFIX) $(MAKE_TARGET)

Endif

Appclean:

$(MAKE) applibs MAKE_TARGET=clean

Appdepend:

$(MAKE) applibs MAKE_TARGET=depend

Appinstall:

$(MAKE) applibs MAKE_TARGET=install

App: appdepend applibs appinstall

Hdvpss:

$(MAKE)-C $(hdvpss_PATH) / packages/ti/psp/vps $(TARGET) CORE=m3vpss

$(MAKE)-C $(hdvpss_PATH) / packages/ti/psp/i2c $(TARGET) CORE=m3vpss

$(MAKE)-C $(hdvpss_PATH) / packages/ti/psp/devices $(TARGET) CORE=m3vpss

$(MAKE)-C $(hdvpss_PATH) / packages/ti/psp/platforms $(TARGET) CORE=m3vpss

$(MAKE)-C $(hdvpss_PATH) / packages/ti/psp/proxyServer $(TARGET) CORE=m3vpss

Hdvpssclean:

$(MAKE) hdvpss TARGET=clean

Hdvpssall: hdvpssclean hdvpss

Iss:

$(MAKE)-C $(iss_PATH) / packages/ti/psp/iss $(TARGET) CORE=m3vpss

Issclean:

$(MAKE) iss TARGET=clean

Issall: issclean iss

Mcfw_linux:

Make-fMAKEFILE.MK-C $(MCFW_ROOT_PATH) / mcfw/src_linux

Make-fMAKEFILE.MK-C $(MCFW_ROOT_PATH) / demos

Mcfw_linux_clean:

Make-fMAKEFILE.MK-C $(MCFW_ROOT_PATH) / mcfw/src_linux clean

Make-fMAKEFILE.MK-C $(MCFW_ROOT_PATH) / demos clean

Mcfw_linux_all: mcfw_linux_clean mcfw_linux

Mcfw_bios6:

$(MAKE)-fMAKEFILE.MK-C $(MCFW_ROOT_PATH) / mcfw/src_bios6 $(TARGET)

Mcfw_bios6_clean:

$(MAKE)-fMAKEFILE.MK-C $(MCFW_ROOT_PATH) / mcfw/src_bios6 clean

Mcfw_bios6_all: mcfw_bios6_clean mcfw_bios6

Mcfw: mcfw_linux mcfw_bios6

Mcfwclean: mcfw_linux_clean mcfw_bios6_clean

Mcfwall: mcfwclean mcfw

Fsupdate:

Cp-R $(TARGET_MCFW_DIR) / $(EXEC_DIR) /.

Chmod 755 $(EXEC_DIR) / .sh

Ifeq ($(APP_BUILD_CFG) release)

(STRIP470) $(TARGET_FS) / opt/ipnc/firmware/ipnc_rdk_fw_m3video.xem3

(STRIP470) $(TARGET_FS) / opt/ipnc/firmware/ipnc_rdk_fw_m3vpss.xem3

Ifeq ($(PLATFORM) ti814x-evm)

(STRIP6x) $(TARGET_FS) / opt/ipnc/firmware/ipnc_rdk_fw_c6xdsp.xe674

Endif

Chmod 755 $(TARGET_FS) / opt/ipnc/firmware/.

Endif

The MCFW module of compiling RDK involves app,hdvpss, iss, mcfw_linux, mcfw_bios6 designed by APPRO and finally putting the compiled executable files APP, BIN, LIB and other COPY to the file system path. Note that the above mcfw_bios6 compiles M3 VPSS and M3 VIDEO in addition to the familiar DSP algorithm. The Iss module compiles the CMOS interface driver. When the algorithm engineer only modifies the algorithm, he can directly use mcfw_bios6_clean and mcfw_bios6 alone, and other modules can be integrated and compiled later.

Build_5_ipncapp-tmp.sh script content: make ipncapp

The corresponding total Makefile content is:

See the same content in build_5_ipncapp-all.sh above. Also is to modify a module a source file, only need to compile the corresponding module, there is no need to recompile all clean, this good computer all need to compile all take more than 40 minutes.

Build_6_ty_app.sh script content: make ty_app_all

The corresponding total Makefile content is:

Ty_app_clean:

$(MAKE)-C $(IPNC_DIR) / ty_app/ ARCH=arm CROSS_COMPILE=$ (BUILD_TOOL_PREFIX) clean

Ty_app_build:

$(MAKE)-C $(IPNC_DIR) / ty_app/ ARCH=arm CROSS_COMPILE=$ (BUILD_TOOL_PREFIX)

Ty_app_install:

$(MAKE)-C $(IPNC_DIR) / ty_app/ ARCH=arm CROSS_COMPILE=$ (BUILD_TOOL_PREFIX) install

Ty_app_all: ty_app_clean ty_app_build ty_app_install

Compile each application in ipnc_rdk/ipnc_app.

Build_7_ubifs.sh script content: make ubifs_ty

The corresponding total Makefile content is:

Ubifs_ty:

Rm-f $(TFTP_HOME) / dm8127_ubifs.bin

Mkdir-p $(IPNC_INSTALL_DIR) / tmp

$(MTD_UTILS) / mkfs.ubifs-r $(FILESYS_INSTALL_DIR) / filesys-F-o. / tmp/ubifs.img-m 2048-e 126976-c 2047

$(MTD_UTILS) / ubinize-o $(TFTP_HOME) / dm8127_ubifs.bin-m 2048-p 128KiB-s 2048-O 2048 $(IPNC_INSTALL_DIR) / ubinize.cfg

Rm-rf $(IPNC_INSTALL_DIR) / tmp

Cp-f $(TFTP_HOME) / dm8127_ubifs.bin / tftpboot/dm8127_ubifs.bin

Debug the NFS file system, use the script to make ubifs bin files and write them to the board NAND FLASH. Of course, in addition to the ubifs file system, the company also supports the migration of squashfs file system, that is, build_7_squashfs.sh.

After coming back from the 16th Anbo Expo of Shenzhen Convention and Exhibition Center from October 29 to November 1, we are busy with the revision of the company's website these days, the old website of the company has stopped running, the new website has been launched again, and the original domain name (URL remains the same). The video-related products of almost every booth of Anbo have to add the word "smart", and it is difficult to display without the word "smart". It can be seen that the market competition is so fierce now. But in fact, the effect and accuracy of video analysis are mixed. Many booths claim to use deep learning algorithms on embedded platforms, but it is estimated that some of them are also deceiving people. after all, there are not many embedded platforms that can run complex deep learning algorithms, such as NVIDIA's Jetson TX1 and Jetson TX2 (about 2800 yuan for a single core board, which is not suitable for embedded mass production in these two years), and ARM+FPGA, both of which are expensive. As for TI's DSP, some companies also use TDAx or DM505M for deep learning, but the complexity of this deep learning is not very high. Considering that several booths of Shenzhen Security Exhibition in 2015 use DM3730 boards produced by Tongye, we feel a lot of pressure because of the crazy display of in-depth learning concepts in 2017, and there are not many traditional video analysis products. Both TI TDAx and DM505M come with multiple C66X floating-point DSP+ and multiple EYE (Embedded Vision Engine), an EYE similar to the Israeli self-driving car technology company Mobileye EyeQ, which has been acquired by Intel. In addition to using these platforms for autopilot, TI can also be used for deep learning. Individual companies also use AM5728 (CORTEX-A15+ double C66X DSP) to do simple deep learning algorithms, but from an algorithm point of view, AM5728 is definitely not as good as TDAx and DM505M. TI is planning to support deep learning algorithms in the next generation of TDAx hardware upgrades (2018?) . Our company's DM8127 platform can only be used in traditional machine vision algorithms, deep learning algorithm platform companies are now more tangled, because we have not found a cost-effective embedded platform, too expensive and too complex we can not do. Buy a set of NVIDIA Jetson TX2 to play for a while and then stop playing. All the core boards have to be imported from NVIDIA, which is too expensive. It does not matter that the embedded front end does not have a good platform to run complex deep learning algorithms. In fact, people who are moving can be analyzed through traditional machine vision, and then snapshots are sent back to the server background through wired and wireless networks to do deep learning. Big data servers in the background, these super CPU+GPU are enough to deal with complex deep learning algorithms, and can still be done with this idea on some occasions.

(QQ: 2505133162, netizens who need development boards or cooperative exchanges can communicate through QQ or technical blogs.)

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report