Alkaid Defconfig
REVISION HISTORY¶
| Revision No. | Description |
Date |
|---|---|---|
| 1.0 | 03/13/2024 |
1. 概述¶
1.1. 功能说明¶
alkaid defconfig是整个project编译环境的顶层配置文件，defconfig依托于menuconfig的形式提供了图形化配置界面。
为显示menuconfig界面请参照环境搭建文档设置好toolchain后在project目录执行：
sigmastar@ubuntu:~/sourcecode/project/$ make menuconfig
图1-1 alkaid defconfig对应的menuconfig图形界面
alkaid defconfig主要的配置项如下：
1.2. 文档格式约束¶
正体：用于文档正文内容的书写，其中代码段的书写需要用等宽字体。
正体 + 加粗：用于文档正文中重要内容的书写。
斜体：用于文档中Tips部分的书写。
斜体 + 加粗：用于文档中Tips部分重要内容的书写。
1.3. 关键字说明¶
NVR: 全称Network Video Recorder，即网络视频录像机。
DVR: 全称Digital Video Recorder，即数字视频录像机或数字硬盘录像机。
XVR: 全称X(代表任何一种或多种功能) Video Recorder，目前sstar实现是NVR+DVR。
IPC: 全称IP Camera，即网络摄像机。
USBCAM: 全称USB Camera, 即USB摄像头。
CARDV: 全称Car Digital Video, 即车载数字视频。
DISPCAM: 全称Display Camera，即摄像头屏显。
Android: 是一种基于Linux内核（不包含GNU组件）的自由及开放源代码的移动操作系统。
IPC-RTOS: Sigmastar 自研双系统，可同时运行Linux与RTOS系统，兼顾RTOS轻巧以及Linux的强大拓展性，具有快速启动的特性。
DualOs: 同IPC-RTOS。
2. Chip¶
芯片型号系列名称。以iFord系列为例，该系列芯片包含bga1、bga2、qfn128以及搭配不同DDR的组合。该参数在bringup阶段后一般不需要修改，新增defconfig只需要使用已有型号即可。该参数会影响project目录中的一些资源存放路径。
3. Product¶
产品形态，包含ipc、nvr、usbcam等多种不同的方案。不同方案默认场景不同所以打包的配置文件以及运行的bin各有不同，请参照不同产品形态使用不同软件方案配置。
4. Board¶
开发板相关软硬件配置。
4.1. Board 开发板型号¶
开发板型号一般在bringup阶段确定后几乎不会改变，与defconfig文件名字中的型号有差别属于正常现象。此参数会影响代码编译过程中的一些配置。以iFord为例，开机默认安装的ko配置就存在于:
project/release/chip/${CHIP}/${PRODUCT}/${BOARD}/bootscript/spinand/boot_sequence.mk
如果不同Board需要有不同的配置可参考该路径新增配置。
4.2. Board Name¶
开发板型号全称，一般不需要修改。此参数会影响image打包过程中使用到的一些配置脚本，以iFord为例：
project/board/${CHIP}/${BOARD_NAME}/config/
目录下会保存一些config.json文件。
如果不同Board需要有不同的配置可参考该路径新增配置。
5. Toolchain¶
工具链配置，一般在bringup前就已经确定，基本不会修改。除非一款chip支援多个工具链(在兼容性问题都被解决的情况下)。
5.1. LinuxArch¶
linux运行架构，与soc core方案有关，sigmastar目前主要采用arm方案。
5.2. Toolchain¶
工具链方案。sigmastar目前支援glibc、uclibc、llvm。Toolchain设置请参考环境搭建，方案确定后基本不会修改。该参数影响release安装路径，修改需慎重。以iFord为例：
project/release/chip/${CHIP}/${PRODUCT}/common/${TOOLCHAIN}/${TOOLCHAIN_VERSION}/
该目录会安装一些事先编译好的lib以及编译过程中产物以供后续image打包阶段使用。
5.3. Toolchain Version¶
工具链方案对应的软件版本。参数影响同上。
5.4. Toolchain Rel¶
工具链前缀，bringup时已经确定，一般不需要修改。以iFord为例:
CONFIG_TOOLCHAIN_REL="arm-linux-gnueabihf-sigmastar-11.1.0"
makefile中会使用该配置去组成gcc全称后进行使用，
sdk/verify/sample_code/mi_dep.mk 25:TOOLCHAIN_REL := $(CROSS_COMPILE) 26:TOOLCHAIN_VERSION := $(shell $(TOOLCHAIN_REL)gcc -dumpversion)
由于我们环境搭建时将工具链路径加入了PATH环境变量，所以我们可以直接使用名字调用到对应的指令。
$ which arm-linux-gnueabihf-sigmastar-11.1.0-gcc /tools/toolchain/gcc-11.1.0-20210608-sigmastar-glibc-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-sigmastar-11.1.0-gccc
6. Busybox¶
Busybox使用的是事先用环境搭建中的toolchain进行编译并打包的文件。对应文件的存放路径为：
project/image/busybox/busybox-1.17.2-arm-linux-gnueabihf-glibc-sigmastar-11.1.0-dynamic.tar.gz
使用者可根据自己需要进行添加修改busybox，该busybox压缩包会在alkaid image打包过程中安装到对应文件目录中。
7. Uboot¶
7.1. Uboot Build Config¶
uboot配置文件，用于编译uboot的config文件。由于硬件和软件配置不同，需要匹配开发板型号。对应config的路径为：
boot/configs/
7.2. Uboot Bin Name¶
uboot bin name，一般不需要修改。该参数会指定从boot目录软连接对应的img文件到project目录，供alkaid image打包使用。当开发板开机后ipl会加载uboot.bin并解压到ram中运行。所以不同压缩格式的uboot会影响uboot.bin的大小以及解压速度。
7.3. Uboot Version¶
uboot版本是跟随boot目录代码版本而定的，不会中途修改。由于不同uboot版本接受的参数有区别所以一些配置文件会很据此配置判断使用不同的uboot参数。
7.4. Uboot DTBO LIST¶
Android DTBO列表。目前此配置仅支持opera。
8. OPTEE¶
OPTEE OS make Option.
OPTEE编译选项，用于向其makefile传递make参数。
9. kernel¶
9.1. Kernel Version¶
kernel 版本，以souffle为例，kernel版本为5.10。一般bringup时就已确定，如需支援kernel其他版本请提市场需求。
9.2. Kernel Config¶
kernel配置文件，用于编译linux kernel的config文件。由于硬件和软件配置不同，需要匹配开发板型号。对应config的路径为：
kernel/arch/${ARCH}/configs/
9.3. Kernel Bin Name¶
kernel bin name，一般不需要修改
10. Image¶
10.1. Using Customize Image Config¶
是否使用customer自己的分区配置，image打包时将会从以下路径寻找customer自己的分区配置文件。
project/image/configs/customize/${IMAGE_CONFIG}
10.2. Image Partition Config¶
分区配置文件名称。该文件详细配置方法请参考系统分区。
不同flash类型、rootfs类型以及是否有使用pm_rtos等分区配置不同。请根据需求配置
10.3. IPL File Config¶
IPL文件名称，该文件的路径在Image Partition Config 分区配置文件中设置。
10.4. IPL_CUST File Config¶
IPL_CUST文件名称，该文件的路径在Image Partition Config 分区配置文件中设置。
10.5.IPLX File Config¶
IPLX文件名称，仅有emmc flash才会使用该文件。该文件的路径在Image Partition Config 分区配置文件中设置。
10.6. TF-A File Config¶
TF-A bin文件名称，该文件的路径在Image Partition Config 分区配置文件中设置。
10.7. OPTEE File Config¶
OPTEE bin文件名称，该文件的路径在Image Partition Config 分区配置文件中设置。配置后，编译时会编译optee并打包一些依赖文件到image中。
10.8. VMM File Config¶
VMM bin文件名称，该文件的路径在Image Partition Config 分区配置文件中设置。
如果LH or HYP of Dualos Type选用了HYP，此处必须填写正确的VMM bin名称。
10.9. Flash Size¶
仅当Flash类型为nor时，此配置才会生效。目前此配置已废弃。
10.10. EMMC BOOT_PART.bin support backups¶
emm boot.bin备份功能。
10.11 Support AOV Image¶
将 MI 模块打包到 dualos 中，编译成 AOV image。
10.12. pm51 Bin¶
pm固件名字，目前仅有opera使用。此配置在image打包过程中生效，文件路径在Image Partition Config对应文件中配置。
10.13. riscvfw Bin¶
riscv固件名字，目前仅有opera使用。此配置在image打包过程中生效，文件路径在Image Partition Config对应文件中配置。
10.14. USB_UPGRADE_IPL_CONFIG¶
用于创建 USB 工厂升级 image 的 IPL 文件名。
10.15. USB_UPGRADE_UBOOT_CONFIG¶
用于创建 USB 工厂升级 image 的 uboot 文件名。
11. Sensor¶
11.1. IQ¶
需要打包的IQ bin在project/board/${CHIP}/iqfile/下的路径，该文件会被安装到misc/iqfile目录下。
11.2. Sensor List¶
image 默认安装的Sensor driver列表。列表中的ko将会在开机时自动insmod。
使用dualos时不需要配置此项。
11.3. Sensor0 Opt¶
为Sensor0对应的ko设置insmod参数。
使用dualos时不需要配置此项。
11.4. IQ API Bin List¶
将 project/board/${chip}/iqfile/${IQ_API_LIST} 的 iq 文件打包到 image。
12. Customer_Options¶
12.1. Mi Dbg¶
mi debug log是否默认编译，此参数在mi ko/lib编译时生效。关闭后可减少code size，但是出问题后不方便定位问题，所以默认开启。
12.2. Yuv420/nv21 data is max align uv height to 16¶
Yuv420/nv21数据向上强制16byte对齐功能。此参数在mi ko/lib编译时生效。
12.3. MI suspend to RAM and standby¶
允许在sleep模式下将内容保存在不掉电的内存中，该模式称为STR。
12.4. MI runtime pm core functionality¶
允许mi模块在空闲时自动进入low power模式以达到省电目的，该模式称为runtime pm。
12.5. Merge all mi modules to a sstar_mi.ko¶
将所有mi模块集成打包为一个sstar_mi.ko，以达到节省内存的目的。
12.6. DEBUG_MODPARAM¶
image打包时是否使用debug版本的modparam.json。默认否。
12.7. PROC DEBUG¶
mi层proc debug功能，开启后可以通过对应模块的节点cat出一些debug信息。关闭后无法cat出信息。
13. Misc_Options¶
杂项功能配置。
13.1. Fpga Pz1 Bench¶
用于标记deconfig所处的内部芯片开发阶段。
13.2. TFTP Download Addr¶
在uboot 进行TFTP下载时文件的缓存地址。缺省值为0x21000000。
13.3. Kernel Boot Addr¶
kernel的启动地址，缺省值为0x23000000。此项作用于uboot，因此直接通过ipl load kernel/boot kernel不由此项控制，故此项对DualOs无效。
13.4. Init Ramfs Addr¶
Ramfs所在的内存起始地址，kernel启动时会通过此地址挂载rootfs，缺省值为0x21800000。
13.5. Split Each File Size¶
切分较大的分区bin，避免在烧录时使用过大的内存从而踩到后面的内存数据。缺省值为0x2000000。
13.6. upgrade_type¶
固件升级方式，影响进入uboot时的自动烧录命令。
13.7. which mmc device is the SD upgrade card¶
用于SD升级的mmc设备号，此配置仅当upgrade_type配置为sd时生效。
13.8. kernel module list that only packs into image but not insmod¶
自定义只打包到 image 但是不会在 demo.sh 进行 insmod 的 kernel modules，方便添加仅作调试的 ko。
13.9. customized linux modparam.json files¶
自定义 purelinux 的 modparam.json 文件，需要放到 board/$(CHIP)/json/$(PRODUCT)/ 目录下。
13.10. wifi config¶
默认安装对应wifi的ko驱动，如果你维护的产品不需要wifi那就不用关心此参数。
13.11. ADB¶
Android平台adb调试工具打包选项。此选项在image打包阶段生效。目前此配置仅支持opera。
13.12. SSH¶
SSH工具打包选项。此选项在image打包阶段生效。目前此配置仅支持opera。
14. DRAM_LAYOUT¶
14.1. RunTime Moudle Size 配置¶
调整各个runtime module 的size
make defconfig 之后会在project\configs 目录下生成dram_layout.txt
make image 之后会check 各个runtime module 的laod addr 是否有重叠。在project\image\output\images 目录生成laod_addr.txt
15. RTOS¶
15.1. Rtos enable¶
开启后则开启RTOS编译，此配置在编译时期和打包时期生效。
pure linux系统不需要配置此项，请确保各项功能关闭
15.1.1. RtosType¶
当RTOS编译开启时，可以编译打包系统类型选择，目前支援pure rtos和dualos两种选项。此配置在编译时期和打包时期生效。
15.1.2. LH or HYP of Dualos Type¶
当RtosType选择为dualos时需要配置Dualos方案。目前sigmastar支援light SMPLH(LH)和hypervisor(HYP)两种方案。此配置在编译时期和打包时期生效。
15.1.3. Rtos build toolchain¶
编译Rtos使用的工具链，与环境搭建保持一致。此配置在编译时期和打包时期生效。
15.1.4. Rtos build config¶
编译Rtos使用的config文件名字，此文件位于rtos目录。此配置在编译时期和打包时期生效。
15.1.5. RTOS Master HW core ID¶
指定RTOS运行在哪个物理核上。
15.1.6. Fast Demo¶
是否打包fast demo相关文件，并开机后自动运行。此参数是在image打包过程中生效的。
15.1.7. Sensor Type¶
Sensor型号，此参数会在打包过程中拷贝Sensor相关的资源文件到image对应的分区目录。例如：
cp -rf $(PROJ_ROOT)/board/$(CHIP)/iqfile/$(SENSOR_TYPE)/$(SENSOR_TYPE)_api.xml $(miscL$(RESOURCE))
15.1.8. RTOS Bin¶
Rtos image 的文件名，默认为 rtos.sz。
15.1.9. Config RTOS compile all Sensor Driver¶
是否在RTOS系统中对所有Sensor Driver进行编译，默认为n
15.2. Rtos use application¶
Rtos开机后自动运行的app名字。该参数配置在image打包过程中拷贝到misc/miscL分区的文件。
15.3. Preload Setting file¶
该参数配置在image打包过程中拷贝到misc/miscL分区的配置文件。与Rtos use application一同生效。
if [ "$(CONFIG_RTOS_APPLICATION)" = "rtos_preload" ]; then \ cp $(PROJ_ROOT)/board/rtos/$(PRELOAD_FILE) $(misc$(RESOURCE))/PreloadSetting.txt ; \ fi;\ if [ "$(CONFIG_RTOS_APPLICATION)" = "pipeline_tree" ]; then \ cp $(PROJ_ROOT)/../sdk/ptree/preload/resource/$(PRELOAD_FILE) $(misc$(RESOURCE))/ptree.json ; \ fi;\
15.4. dla firmware list¶
该参数配置在image打包过程中拷贝到misc/miscL分区的dla使用的固件文件列表。
if [ "$(DLA_FIRMWARE_LIST)" != "" ]; then \ cp -rf $(foreach n,$(DLA_FIRMWARE_LIST),$(PROJ_ROOT)/board/$(CHIP)/dla_file/$(n)) $(miscL$(RESOURCE))/; \
15.5. ipl earlyinit enable¶
开启ipl earlyinit功能。
16. pm_rtos¶
pm_rtos是为具有cm4硬件的CHIP配置的，其是独立于arm的另一套软硬件架构。
16.1. pm_rtos enable¶
pm_rtos功能开启配置。此配置在编译时期和打包时期生效。
16.2. pm_rtos Bin¶
打包image时拷贝的pm_rtos Bin名称。此配置在image打包过程中生效，文件路径在Image Partition Config对应文件中配置。
16.3. pm_rtos build toolchain¶
编译pm_rtos所使用的toolchain，请参考环境搭建。此配置在编译时期生效。
16.4. pm_rtos build config¶
编译pm_rtos所使用的config文件名称。此配置在编译时期生效。
17. Sdk_Config¶
sdk目录编译配置。
17.1. Verify Compile Config¶
sdk/verify目录编译配置。
17.1.1. mi_demo¶
是否编译和打包mi_demo目录内容。mi_demo为mi内部模块ut测试相关的应用和配置文件。
17.1.2. amigos¶
是否编译和打包amigos目录内容。amigos为mixer软件的项目目录，mixer是sigmastar自研的一套抽象模块化且能动态化创建修改pipleline的软件运行和测试框架。
17.1.3. pipeline_tree¶
Pipeline Tree(ptree)顾名思义是把Pipeline抽象成数据结构中树一种软件框架，通过树的构造和遍历即可实现Pipeline的初始化和去初始化功能，从而实现了Pipeline出流的目的。
17.1.4. sample_code¶
是否编译和打包sample_code目录内容。sample_code是sigmastar为客户提供的一套开源的场景演示项目。
17.1.5. bsp_demo¶
是否编译和打包bsp_demo目录内容。bsp_demo是sigmastar内部一套自动化测试bsp各个模块的测试框架。
17.2. Interface Compile Config¶
mi相关的编译配置。仅当sdk/interface目录存在时生效。此目录下配置均在编译时生效，故以下各项不再单独说明。
17.2.1. MI debug level for code size verify config¶
一些影响code size的编译配置。
17.2.1.1. Valid mi log level
选择需要编译的log等级。
17.2.1.2. MI USER LIB OPTIMAZITION
user lib编译时传递给编译器使用的代码优化等级。
17.2.1.3. enable mi kapi for mi interface called from kernel space
编译mi user api相应的kapi，这些kapi接口函数与参数和user api一致，但kapi是为了使用者在kernel mode调用的，因此ko在编译运行时会多导出一些符号，这将增加一定的code szie。
17.2.1.4. enable mi log _FUNCTION_ info
允许log中打印函数名。
17.2.1.5. enable mi log _FILE_ info
允许log中打印其所在文件。
17.2.2. aio¶
audio编译相关编译配置。启用ai或者ao模块则aio默认开启。
17.2.3. vcodec¶
编解码相关编译配置。启用venc或者vdec模块则此选项默认开启。
17.2.3.1. mhal_vcodec
编解码驱动的核心业务，若要使用venc或者vdec则此选项必须开启。
17.2.3.2. mhal_neon
mhal neon支持，iFord以后chip已经不再依赖此选项。
17.2.4. ai¶
audio in模块编译开关。编译产物为mi_ai.ko
17.2.5. ao¶
audio out模块编译开关。编译产物为mi_ao.ko
17.2.6. cipher¶
用于加解密的cipher模块。
17.2.7. common¶
mi common模块，为其他mi模块提供一些公有功能支持。所有mi ko要后于该模块被安装。
17.2.7.1. mi_common
为用户层调用提供接口。开启common后此选项默认开启。
17.2.7.2. mhal_cmdq
cmdq时sigmastar自有的一套寄存器同步服务，为所有mi模块提供寄存器设置和同步接口。如果需要使用mi模块则此项必须打开。
17.2.8. cus3a¶
cus3a算法模块。用户可自行开发AWB/AE/AF算法库透过注册AWB/AE/AF Interface与ISP连接。关闭后isp则不能使用该模块相关功能。
17.2.9. debug¶
mi_debug.ko编译开关。其功能设置请参考：PROC_DEBUG。
17.2.10. disp¶
DISP是一个视频显示单元，主要功能是对前端输出的图像做硬件拼图，并对硬件拼图后的图像进行颜色空间转换，最终通过HDMI/VGA/MIPI/TTL等接口输出到显示器或LCD。此模块依赖mhal_disp功能，故将会强制打开。disp功能为内部模块提供功能支持。mi fb模块依赖disp功能，故当mi fb打开时disp将会强制打开。mi disp为用户层调用提供接口。
17.2.11. divp¶
DIVP支持对一幅输入图像进行预处理，如裁剪、图像像素格式转换、旋转、镜像等，然后再对各通道分别进行缩放处理，最后输出多种不同分辨率的图像。
iFord不支持此模块。请使用scl模块。
17.2.12. gfx¶
GFX(Graphic Engine)硬件为画UI提供快速的图形绘制功能，主要有矩形色彩填充、位图搬移（支持缩放、旋转、镜像翻转、格式转换、alpha混合叠加、Color Key等操作）。目前仅Taiyaki、Takoyaki、Tiramisu、Ikayaki、Muffin、Mochi系列芯片支持GFX。mi gfx模块提供用户接口，编译产物为mi_gfx.ko
17.2.13. hdmi¶
HDMI (High Definition Multimedia Interface)，即高清多媒体接口，是一种全数字化视频和声音发送接口，可以同时发送未压缩的音频及视频信号。
HDMI可以分为TX 端与 RX端，TX即soure设备，用来将数据传输给RX（sink设备）。本模块目前只支持基于HDMI ver1.4 的HDMITx。mi hdmi模块为用户层提供该模块的操作接口。
17.2.14. ipu¶
MI IPU模块实现了AI模型的推演功能加速。通过channel支持多个AI模型的推演，支持模块内部分配input/output Tensor，也支持直接使用前一级模块out buffer 作为input Tensor。
17.2.15. iqserver¶
IQSERVER(Image Quality tuning Server)图像质量调校服务，用来完成调校工具（IQTool）和开发板之间的数据通信，包括ISP参数设置，获取图像，上传/下载相关文件等功能。
17.2.16. isp¶
图像信号处理（Image Signal Processing），实现HDR、3D/2D降噪、3A算法、WDR等相关功能。此模块编译同时依赖vif和sensor模块。isp子选项默认全开。
17.2.17. ispalgo¶
isp算法模块，为用户提供接口。此模块依赖于isp模块。
17.2.18. ive¶
IVE(Intelligent Video Engine)是处理芯片智能分析系统中的硬件加速模块。
17.2.19. jpd¶
JPD解码模块提供创建解码通道、控制解码及传送码流等功能。jpd开启时mhal_jdp默认开启，mi_jpd为用户层调用提供接口。
17.2.20. ldc¶
镜头畸变矫正(Lens distortion correction)，目前模块支持功能包括镜头畸变矫正、投影变换映射函数、图像拼接、图像拼接区域融合、防抖功能以及查找表功能。ldc开启时mhal_ldc默认开启，mi_ldc为用户层调用提供接口。
17.2.20.1. mhal_dis
dis防抖功能，dualos系统下不支持此功能，pure linux下可根据需求开关此功能。
17.2.20.1.1. mhal_dis_gme
基于gme图像运动估计算法的功能。根据需求开启。
17.2.20.1.2. mhal_dis_gyro
基于gyro硬件陀螺仪的dis功能。根据需求开启。要使用dis功能，则此功能与mhal_dis_gme至少二选一。
17.2.20.2. mhal_multiband
stitch拼接功能，dualos系统下不支持此功能，pure linux下可根据需求开关此功能。
17.2.21. mipitx¶
将Dram数据通过MIPI接口协议发送出去。mi_mipitx为用户层调用提供接口。
17.2.22. rgn¶
区域管理模块参与SCL模块的内部流处理的一个环节。底层硬件模块支持是GOP（Graphic output path）， 区域管理模块是利用 GOP 的特性抽象出来的一套软件接口，利用分时复用的原理使OSD(On-screen display)或者Cover贴到各个通道上。
fb功能依赖于此模块。此模块开启时mhal_rgn默认开启。mi_rgn为用户层调用提供接口。
17.2.22.1. sw_osd
OSD数超过gwin数之后会自动把距离近的OSD拼到一起以实现同一个通道上显示更多的OSD(128个)。可单独关闭。
17.2.22.2. cover_map
多边形cover功能。iFord芯片上使用多边形Cover时需要打开，其他情况可单独关闭。
17.2.23. sed¶
SED(Smart Encoder)主要提供智能编码通道的创建和销毁、开启和停止检测源图像、计算结果并关联到指定的编码通道等功能。
17.2.24. sensor¶
SNR(sensor)模块实现获取摄像头接口信息、调整分辨率和帧率等功能。isp依赖于此模块。此模块与vif相互依赖。mi_sensor为用户层调用提供接口。
17.2.24.1. mhal_sensorif
mhal层的sensor接口功能，sensor依赖此功能。默认开启。
17.2.24.2. mhal_csi
同样为sensor基本功能，默认开启。开启后则可支援mipi sensor串流功能了。
17.2.24.3. mhal_lvds
sensor lvds接口相关功能，如果不需要lvds接口，可单独关闭此项。
17.2.24.4. mhal_earlyinit
dualos场景下为快速启动增加的功能，与mhal_ipl_earlyinit一同开启。
17.2.24.5. mhal_ipl_earlyinit
dualos场景下为快速启动增加的功能，与mhal_earlyinit一同开启。
17.2.25. shadow¶
vdf模块依赖于此模块完成一些kernel mode的功能。不使用vdf模块功能的话，此模块也可以关闭。
17.2.26. sys¶
MI_SYS是整个MI系统的基础模块，它给其他MI模块的运行提供了基础环境。
17.2.27. sys_earlyinit¶
此模块在dualos快速启动场景下提供环境和功能支持。purelinux可以关闭此选项。
17.2.28. vdec¶
vdec为视频解码模块，提供解码通道创建、码流传送及控制、输出图像裁剪和缩放等功能。nvr/xvr场景需要此模块，ipc场景一般不需要此模块。
17.2.29. vdf¶
VDF实现MD，OD，VG视频通道的初始化，通道管理，视频检测结果的管理和通道销毁等功能。此模块依赖shadow模块。
17.2.30. vdisp¶
VDISP(virtual display)模块设计用来组合多份YUV/RGB等颜色空间的数据成一张全幅输出，并为每一个数据输入指定一个缩略图形式的显示窗口。特定缩略图窗口支持区域重叠。
17.2.31. venc¶
视频编码(video encoder)模块主要提供视频编码通道的创建和销毁、开启和停止接收图像、设置和获取编码通道属性、获取和释放码流等功能。此模块依赖vcode模块
17.2.32. vif¶
视频输入（video interface）实现启用视频输入设备、视频输入通道、绑定视频输入通道等功能。isp和sensor模块均依赖此模块。vif子选项均需要默认开启，可根据需求调整mhal_vif log level与mhal_ispscl_log_level。
17.2.33. scl¶
SCL将原始画面缩放到各个output port 指定分辨率。每个scl按照输入数据源的类型划分成不同的Device， 每一个output port 端口有crop/scaling/mirror/flip/pixel 转换功能。scl依赖于mhal_vpe功能，mi_scl为用户层调用提供接口。
17.2.34. wlan¶
无线局域网(wlan)，提供了简单的wifi信号的扫描。连接功能，提供了对AP以及STA模式的支持。
17.2.35. pcie¶
PCIe（Peripheral component interconnect express）是一种通用的高速串行总线接口标准，广泛用于PC、手持设备、工业等各个领域。 MI_PCIE具有MI通道（channel）和设备（device）的特性，通过其他MI模块与MI_PCIE模块的通道绑定的方式，可使MI内部的数据流经过PCIe的总线通讯传输到另外的SOC上。
MI_PCIE另外提供用户层直接操作PCIe总线DMA的接口用于用户自定义数据类型的传输，并且提供一套基于PCIe总线的消息同步机制---RPMSG，消息同步结合PCIe总线DMA可以使用户扩展基于PCIe的传输协议。目前仅Muffin平台支持。
17.2.36. dsp¶
数字信号处理模块，目前仅Muffin平台支持。
17.2.37. dpu¶
DPU通过对多对摄像头输入的左右图像，进行特定算法处理后，输出与输入图像对应的深度信息。根据深度信息，通过计算可获得图像中物体相对摄像头的距离。
17.2.38. dummy¶
dummy模块实现了将inputBuf拷贝为outputBuf的简单工作流程。用户可将其outputBuf使用sys接口inject给下一级模块的inputPort。由于dummy属于mi模块所以它也支持mi proc查看debug信息。方便掌控buffer和帧率信息。副作用是由于有拷贝动作将会增加带宽消耗。
17.2.39. fb¶
MI_FB是一个基于Linux Framebuff实现的图形层设备驱动。它将显示缓冲区抽象，屏蔽图像硬件的底层差异，允许上层应用程序在图形模式下直接对显示缓冲区进行读写操作，用户不必关心物理显示缓冲区的具体位置及存放方式，这些都由MI_FB模块驱动来完成。在提供Linux Framebuff基本功能的基础上，MI_FB还提供了一些扩展功能，如层间Alpha、ColorKey、设置显示区域等。fb依赖于mhal_rgn功能。
17.2.39.1. disp_path
MI_FB UI支持直接叠加到DISP模块上，只有DISP存在GOP硬件的chip支持该路径设置。disp_path依赖于disp模块。可根据需求单独关闭，节省code size。
17.2.39.2. video_path
MI_FB UI支持通过MI_RGN模块叠加到OSD可以attach的模块上。video_path依赖于rgn模块。可根据需求单独关闭，节省code size。
17.2.40. nir¶
在低照度环境下，可见光图像保留了图像的颜色信息，但信噪比差，细节丢失严重；红外图像有相对较高的信噪比，且细节表现较好，但丢失了图像的颜色信息。
NIR模块通过将上述可见光图像和红外图像进行融合，既保留颜色信息，同时提升图像细节和信噪比，从而提高低照度环境下的图像质量。
nir依赖于mhal_nir功能，mi_nir为用户层调用提供接口。
17.2.41. hvp¶
HVP用途主要是为了接入HDMIRX的video数据，经过简单的缩放、裁剪和帧率变换，向后传递给DISP或SCL；帧率变化通过控制内部DMA访问的buffer深度来实现，运行方式目前支持frame mode/realtime mode两种，realtime mode下数据不经过内部DMA、无法做帧率控制。hvp依赖于mhal_hvp功能，mi_hvp为用户层调用提供接口。目前仅opera支持。
17.2.42. pspi¶
通过PSPI从sensor获取图像数据，或将图像数据通过PSPI传输到panel。pspi依赖于mhal_pspi功能，mi_pspi为用户层调用提供接口。
17.2.43. hdmirx¶
HDMI 分为RX 端和 TX端，TX 即为source 设备，用来将数据传输给RX 设备（Sink设备）。RX 端就是接收端，接收TX发送过来的HDMI信号。
17.3. Osdk Compile Config¶
openSource sdk编译选项
17.3.1. drm¶
DRM模块是linux 原生支持的显示框架，在opera上用DRM模块替换DISP模块。DRM依赖mahl_rgn和mhal_disp功能。如需要实现hdmirx功能需要打开mhal_hdmitx选项开启功能。目前仅opera支持。
17.3.2. gles_ldc¶
基于OpenGLES实现的ldc畸变矫正模块。目前仅opera支持。
18. Android_Ndk¶
Android编译环境配置。目前此配置仅支持opera。
18.1. NDK API Version¶
Android NDK API版本。
18.2. NDK Clang Version¶
Android NDK使用的Clang编译器版本。
18.2.1. NDK Clang Target¶
Android NDK编译目标平台。
18.2.2. NDK Binutils Prefix¶
Android NDK编译工具前缀。
19. SECURE_BOOT¶
安全启动相关配置。
19.1. SECURE_BOOT¶
安全启动实现选用的具体算法。此选项在image编译时生效。
19.1.1. IMAGE_AES_DETAILS¶
安全启动时image aes配置。此选项仅在SECURE_BOOT选择aes相关算法是生效。此选项在image编译时生效。
19.1.2. Secureboot_debugmode¶
安全启动调试模式。将会增加一些信息打印。此选项在image编译时生效。
19.2. IPL_With_AES¶
IPL AES加密选项。
19.2.1. IPL_ENCRYPT¶
IPL是否加密。此选项在IPL编译时生效。