高通QNX基线编译原理

2024-03-04 16:28
文章标签 编译 原理 高通 qnx 基线

本文主要是介绍高通QNX基线编译原理,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

 下面代码以高通智驾平台为例。

1 QNX应用程序编译原理

在高通提供的qnx开发包中,qnx的内核已经由qnx所提供,所以qnx的编译,其实就是大量应用程序的编译,以及最后利用buildfile文件,把内核,库文件以及应用程序打包在一起的过程。

1.1 qnx的工程目录

应用程序的编译,可以利用最常见的makefile规则,来指定生成目标所需要的依赖文件;也可以利用qnx提供的编译机制来生成对应的可执行文件或者库文件。文本着重介绍后者,如何利用qnx的编译机制来生成应用程序。

如果要利用qnx的编译机制,来生成可执行文件,首先要构建如下所示的文件目录结构:

qnx规则对文件目录进行了比较详细的规范,要求开发者尽量遵循上述规则来构建适应多os,多架构的构建。这样构建目录的好处是开发者可以尽可能把通用的代码放到上层目录,尽可能的减少代码的可重复性。同时,每一层级都会有makefile文件,用户可以在任何目录输入make命令,make 会递归每一级目录来编译相应的内容。根据开发经验,上述目录并不是必选的,但是CPU level和variant level是开发过程中需要构建的目录。

这边尤其要注意的是variant level目录的名字,决定着最后编译出来的文件是可执行文件,动态库,还是静态库。

该名字可以包含如下的一些组合,并用(.),(-)或者(/)来进行分割。

名字中包含a字符:说明该文件需要构建成静态库。

名字中包含so字符:说明该文件需要构建成动态库。

名字中包含g字符:说明该文件需要构建成debug的版本,该版本会包含调试信息,可以供gdb调试器使用。

名字中包含be, le字符:说明该目标文件是大端或者是小端。

比如说variant level的目录名为g.le,说明需要构建的目标文件是一个debug的版本的小端的可执行程序。不过有一点需要注意的是,向.a, .so, or .o这些选项最好不要放在名字的结尾,不然会和现有的文件类型产生混淆。

1.2 qnx的makefile

用qnx的规则来构建makefile,可以看到除了最底层variant level,其他层的makefile文件所包含的内容基本都是类似的:

LATE_DIRS=boards

include recurse.mk

recurse.mk 文件用来通知makefile向更底层的目录遍历。

在同级别如果有多个目录,并且不同目录中的文件构建有先后的依赖关系,我们可以使用EARLY_DIRS和LATE_DIRS来构建。需要更早构建的目录放在EARLY_DIRS,需要更晚构建的目录,放在LATE_DIRS中,EARLY_DIRS和LATE_DIRS中可以放置多个目录,但各个目录之间构建的时候没有先后关系。

而在最底层的variant level中,makefile文件的内容基本是这样的形式:

include ../../common.mk

common.mk文件通常放在project目录下面。common.mk文件中的内容是整个编译的核心,通常放着编译的标志,头文件位置,源文件位置,以及需要链接的库等。

common.mk中的内容大概如下:

ifndef QCONFIG

QCONFIG=qconfig.mk

endif

include $(QCONFIG)

# Preset make macros go here

include $(MKFILES_ROOT)/qtargets.mk

# Postset make macros go here

qconfig.mk宏通常包含着一些编译中使用的编译工具的宏定义,命令的宏定义,如(CP_HOST

,LN_HOST)qnx建议在编译的时候使用这些宏,而不是直接去引用某个绝对路径,或者某个host中的命令。在Preset 的位置,用户可以用来定义一些宏,比如如何进行链接,包含了哪些头文件或者源文件,以及目标文件的名字等。Postset可以用来定义一些哄,用来覆盖qtargets.mk中的定义。qtargets.mk用来包含安装路径以及文件链接。

qrules.mk用来放置编译过程中会用到的一些宏,如目标文件,源文件,编译标志,对于可写属性的宏,用户可以进行更改。

一些编译过程中会经常用到的宏:

INSTALLDIR:目标文件安装路径

CCFLAGS:编译标志位

LDFLAGS:链接标志位

LIBS:需要链接的库文件

NAME:指定目标文件的名字

EXTRA_INCVPATH:编译过程中需要搜索的头文件路径

EXTRA_SRCVPATH:编译过程中的源文件,通常源文件不在当前工程文件下时,需要设置该变量。

EXTRA_LIBVPATH:指定编译过程中搜索依赖库的路径

2 QNX image构建原理

在上述利用通用makefile规则或者qnx的makefile规则,编译出相应的可执行程序以后,就需要把这些应用程序打包,构建启动文件。qnx 利用buildfile文件来构建整个image。buildfile制定了qnx的启动文件,启动脚本,以及启动过程中需要打包的库文件以及应用程序。

可以先看一下qnx的启动时序:

最一开始的PLL是硬件相关的,这边不做讨论。

IPL阶段,全称是initial program loader,这是引导qnx系统的第一个阶段。通常用来做一些最基本的硬件初始化工作,当然也有可能会对startup程序进行内存拷贝(如果这一部分工作没有在bootloader完成的话)。

Startup阶段,完成后续的硬件初始化工作,包括内存页表映射,内核调用函数链接,然后把接下来的工作交给procnto(内核),拷贝os image到ram中。

Base system包含内核,以及系统启动的一些必要文件。

Boot script阶段,系统启动中优先级高的任务,可放在该阶段执行。

SLM阶段,一般的应用程序,可放在该阶段执行。

而由startup program,base system和boot script等组成的image,又称作Image Filesystem(IFS)

上述描述了整个qnx系统启动时的一个大概的时序,而buildfile所做的工作,基本能和上述所描述的元素所吻合。看一下buildfile的一些基本要素:

[virtual=x86_64,bios] .bootstrap = {

    startup-x86

    # PATH is the *safe* path for executables (confstr(_CS_PATH...))

    # LD_LIBRARY_PATH is the *safe* path for libraries

    # (confstr(_CS_LIBPATH)). That is, it's the path searched for libs

    # in setuid/setgid executables.

    # The module=aps enables the adaptive partitioning scheduler.

    [module=aps] PATH=/proc/boot:/bin:/usr/bin:/sbin:/usr/sbin \

        LD_LIBRARY_PATH=/proc/boot:/lib:/lib/dll:/usr/lib \

        procnto-smp-instr

}

# Start-up script

[+script] .script = {

    # Create some adaptive partitions during system startup:

    #   - IOPKT with a 20% budget

    #   - QCONN with a 20% budget

    # NOTE:  To specify a critical budget of 5 ms, use sched_aps as seen below

    #       when the filesystem on the disk is available.

    sched_aps IOPKT 20 5

    sched_aps QCONN 20 5

   。。。。。。。

    # Start the main shell

    reopen /dev/con1

    [+session] sh &

}

[perms=0777]

# Include the current "libc.so". It will be created as a real file

# using its internal "SONAME", with "libc.so" being a symlink to it.

# The symlink will point to the last "libc.so.*" so if an earlier

# libc is needed (e.g. libc.so.5) add it before the this line.

libc.so

libgcc_s.so.1

/usr/lib/ldqnx-64.so.2=ldqnx-64.so.2

libelfcore.so.1

libslog2.so

#libusbdi.so

devu-hcd-ehci.so

virtual=x86_64,bios描述的是IPL,startup-x86描述的是startup程序,procnto-smp-instr 是procnto程序,.script 中描述的是启动脚本需要完成的事情。最下面的内容是IFS中包含的一些系统启动所需要的库文件以及应用程序。通过buildfile文件,描述了整个IFS构建所需要的文件以及系统的启动流程。

3 以一个例子介绍高通基线应用程序的编译

这边以qcarcam_test为例,介绍一下高通如何利用qnx的规则,来生成对应的应用程序。

qcarcam_test 的目录结构如下所示:

源文件放在src目录中,build目录就是之前第一章所描述的,利用qnx的规则所创建的目录结构,build 目录可以理解为project level,aarch64目录和arm目录为cpu level,o-le和o-le-v7为variant level。

除了variant level的makefile中引用了common.mk:

其他的makefile文件都只是包含了recurse.mk,用来递归搜索下层目录:

目标文件编译规则由common.mk来描述:

ifndef QCONFIG

QCONFIG=qconfig.mk

endif

include $(QCONFIG)

include $(AMSS_ROOT)/amss_defs.mk

include ../../../../../build/qnx/overrides.mk

NAME=qcarcam_test

#===== INSTALLDIR - Subdirectory where the executable or library is to be installed.

INSTALLDIR=$(CAMERA_OUT_BIN)/$(NAME)

ifeq ($(CPULIST),aarch64)

cpulist=aarch64le

else

cpulist=armle-v7

endif

#===== USEFILE - the file containing the usage message for the application.

USEFILE=$(PROJECT_ROOT)/../src/qcarcam_test.use

#===== PINFO - the file containing the packaging information for the application.

define PINFO

PINFO DESCRIPTION=QCarCam test application

endef

#===== EXTRA_SRCVPATH - a space-separated list of directories to search for source files.

EXTRA_SRCVPATH+= \

        $(PROJECT_ROOT)/../src \

        $(PROJECT_ROOT)/../../test_util/src \

        $(PROJECT_ROOT)/../../test_util/src/qnx

#===== EXTRA_INCVPATH - a space-separated list of directories to search for include files.

EXTRA_INCVPATH+= \

        $(QCX_ROOT)/utils/inc \

        $(QCX_ROOT)/utils/inc/os \

        $(PROJECT_ROOT)/../../test_util/inc \

        $(AMSS_INC) \

这篇关于高通QNX基线编译原理的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/773757

相关文章

Java中流式并行操作parallelStream的原理和使用方法

《Java中流式并行操作parallelStream的原理和使用方法》本文详细介绍了Java中的并行流(parallelStream)的原理、正确使用方法以及在实际业务中的应用案例,并指出在使用并行流... 目录Java中流式并行操作parallelStream0. 问题的产生1. 什么是parallelS

Java中Redisson 的原理深度解析

《Java中Redisson的原理深度解析》Redisson是一个高性能的Redis客户端,它通过将Redis数据结构映射为Java对象和分布式对象,实现了在Java应用中方便地使用Redis,本文... 目录前言一、核心设计理念二、核心架构与通信层1. 基于 Netty 的异步非阻塞通信2. 编解码器三、

Java HashMap的底层实现原理深度解析

《JavaHashMap的底层实现原理深度解析》HashMap基于数组+链表+红黑树结构,通过哈希算法和扩容机制优化性能,负载因子与树化阈值平衡效率,是Java开发必备的高效数据结构,本文给大家介绍... 目录一、概述:HashMap的宏观结构二、核心数据结构解析1. 数组(桶数组)2. 链表节点(Node

Redis中Hash从使用过程到原理说明

《Redis中Hash从使用过程到原理说明》RedisHash结构用于存储字段-值对,适合对象数据,支持HSET、HGET等命令,采用ziplist或hashtable编码,通过渐进式rehash优化... 目录一、开篇:Hash就像超市的货架二、Hash的基本使用1. 常用命令示例2. Java操作示例三

Redis中Set结构使用过程与原理说明

《Redis中Set结构使用过程与原理说明》本文解析了RedisSet数据结构,涵盖其基本操作(如添加、查找)、集合运算(交并差)、底层实现(intset与hashtable自动切换机制)、典型应用场... 目录开篇:从购物车到Redis Set一、Redis Set的基本操作1.1 编程常用命令1.2 集

Redis中的有序集合zset从使用到原理分析

《Redis中的有序集合zset从使用到原理分析》Redis有序集合(zset)是字符串与分值的有序映射,通过跳跃表和哈希表结合实现高效有序性管理,适用于排行榜、延迟队列等场景,其时间复杂度低,内存占... 目录开篇:排行榜背后的秘密一、zset的基本使用1.1 常用命令1.2 Java客户端示例二、zse

Redis中的AOF原理及分析

《Redis中的AOF原理及分析》Redis的AOF通过记录所有写操作命令实现持久化,支持always/everysec/no三种同步策略,重写机制优化文件体积,与RDB结合可平衡数据安全与恢复效率... 目录开篇:从日记本到AOF一、AOF的基本执行流程1. 命令执行与记录2. AOF重写机制二、AOF的

java程序远程debug原理与配置全过程

《java程序远程debug原理与配置全过程》文章介绍了Java远程调试的JPDA体系,包含JVMTI监控JVM、JDWP传输调试命令、JDI提供调试接口,通过-Xdebug、-Xrunjdwp参数配... 目录背景组成模块间联系IBM对三个模块的详细介绍编程使用总结背景日常工作中,每个程序员都会遇到bu

Python中isinstance()函数原理解释及详细用法示例

《Python中isinstance()函数原理解释及详细用法示例》isinstance()是Python内置的一个非常有用的函数,用于检查一个对象是否属于指定的类型或类型元组中的某一个类型,它是Py... 目录python中isinstance()函数原理解释及详细用法指南一、isinstance()函数

java 恺撒加密/解密实现原理(附带源码)

《java恺撒加密/解密实现原理(附带源码)》本文介绍Java实现恺撒加密与解密,通过固定位移量对字母进行循环替换,保留大小写及非字母字符,由于其实现简单、易于理解,恺撒加密常被用作学习加密算法的入... 目录Java 恺撒加密/解密实现1. 项目背景与介绍2. 相关知识2.1 恺撒加密算法原理2.2 Ja