In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
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.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.