高通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

相关文章

Redis主从/哨兵机制原理分析

《Redis主从/哨兵机制原理分析》本文介绍了Redis的主从复制和哨兵机制,主从复制实现了数据的热备份和负载均衡,而哨兵机制可以监控Redis集群,实现自动故障转移,哨兵机制通过监控、下线、选举和故... 目录一、主从复制1.1 什么是主从复制1.2 主从复制的作用1.3 主从复制原理1.3.1 全量复制

Redis主从复制的原理分析

《Redis主从复制的原理分析》Redis主从复制通过将数据镜像到多个从节点,实现高可用性和扩展性,主从复制包括初次全量同步和增量同步两个阶段,为优化复制性能,可以采用AOF持久化、调整复制超时时间、... 目录Redis主从复制的原理主从复制概述配置主从复制数据同步过程复制一致性与延迟故障转移机制监控与维

SpringCloud配置动态更新原理解析

《SpringCloud配置动态更新原理解析》在微服务架构的浩瀚星海中,服务配置的动态更新如同魔法一般,能够让应用在不重启的情况下,实时响应配置的变更,SpringCloud作为微服务架构中的佼佼者,... 目录一、SpringBoot、Cloud配置的读取二、SpringCloud配置动态刷新三、更新@R

Redis主从复制实现原理分析

《Redis主从复制实现原理分析》Redis主从复制通过Sync和CommandPropagate阶段实现数据同步,2.8版本后引入Psync指令,根据复制偏移量进行全量或部分同步,优化了数据传输效率... 目录Redis主DodMIK从复制实现原理实现原理Psync: 2.8版本后总结Redis主从复制实

深入探索协同过滤:从原理到推荐模块案例

文章目录 前言一、协同过滤1. 基于用户的协同过滤(UserCF)2. 基于物品的协同过滤(ItemCF)3. 相似度计算方法 二、相似度计算方法1. 欧氏距离2. 皮尔逊相关系数3. 杰卡德相似系数4. 余弦相似度 三、推荐模块案例1.基于文章的协同过滤推荐功能2.基于用户的协同过滤推荐功能 前言     在信息过载的时代,推荐系统成为连接用户与内容的桥梁。本文聚焦于

hdu4407(容斥原理)

题意:给一串数字1,2,......n,两个操作:1、修改第k个数字,2、查询区间[l,r]中与n互质的数之和。 解题思路:咱一看,像线段树,但是如果用线段树做,那么每个区间一定要记录所有的素因子,这样会超内存。然后我就做不来了。后来看了题解,原来是用容斥原理来做的。还记得这道题目吗?求区间[1,r]中与p互质的数的个数,如果不会的话就先去做那题吧。现在这题是求区间[l,r]中与n互质的数的和

maven 编译构建可以执行的jar包

💝💝💝欢迎莅临我的博客,很高兴能够在这里和您见面!希望您在这里可以感受到一份轻松愉快的氛围,不仅可以获得有趣的内容和知识,也可以畅所欲言、分享您的想法和见解。 推荐:「stormsha的主页」👈,「stormsha的知识库」👈持续学习,不断总结,共同进步,为了踏实,做好当下事儿~ 专栏导航 Python系列: Python面试题合集,剑指大厂Git系列: Git操作技巧GO

hdu4407容斥原理

题意: 有一个元素为 1~n 的数列{An},有2种操作(1000次): 1、求某段区间 [a,b] 中与 p 互质的数的和。 2、将数列中某个位置元素的值改变。 import java.io.BufferedInputStream;import java.io.BufferedReader;import java.io.IOException;import java.io.Inpu

hdu4059容斥原理

求1-n中与n互质的数的4次方之和 import java.io.BufferedInputStream;import java.io.BufferedReader;import java.io.IOException;import java.io.InputStream;import java.io.InputStreamReader;import java.io.PrintWrit

寻迹模块TCRT5000的应用原理和功能实现(基于STM32)

目录 概述 1 认识TCRT5000 1.1 模块介绍 1.2 电气特性 2 系统应用 2.1 系统架构 2.2 STM32Cube创建工程 3 功能实现 3.1 代码实现 3.2 源代码文件 4 功能测试 4.1 检测黑线状态 4.2 未检测黑线状态 概述 本文主要介绍TCRT5000模块的使用原理,包括该模块的硬件实现方式,电路实现原理,还使用STM32类