流云疏影

Linux物理内存管理三大结构体之struct zone

Wed, 23 Aug 2023 00:00:00 GMT

一、Zone type

因此Linux内核对不同区域的内存需要采用不同的管理方式和映射方式

为了解决这些制约条件，Linux使用了三种区：

ZONE_DMA : 这个区包含的页用来执行DMA操作

ZONE_NOMAL : 这个区包含的都是能正常映射的页

ZONE_HIGHEM : 这个区包"高端内存"，其中的页能不永久地映射到内核地址空间

而为了兼容一些设备的热插拔支持以及内存碎片化的处理, 内核也引入一些逻辑上的内存区

ZONE_MOVABLE : 内核定义了一个伪内存域ZONE_MOVABLE, 在防止物理内存碎片的机制memory migration中需要使用该内存域. 供防止物理内存碎片的极致使用

ZONE_DEVICE : 为支持热插拔设备而分配的Non Volatile Memory非易失性内存

这部分的定义可以在mmzone.h中的enum zone_type中得到

二、struct zone结构体

内核将每个簇所对应的node又被分成的称为管理区(zone)的块，它们各自描述在内存中的范围。一个管理区(zone)由struct zone结构体来描述

下面详细介绍一下这个结构体的知识点：

2.1 watermark

每个zone都有三个水线标准，如下enum定义，分别叫做WMARK_MIN，WMARK_LOW，WMARK_HIGH，借助水线值与zone的free pages对比，可以知道当前zone的内存压力有多大。这三个值在系统启动阶段memory init时会计算得出，首先是通过init_per_zone_wmark_min函数计算出min_free_kbytes，后面根据这个值，计算出这三个水线标准值，这块后面会细讲。这三个水线标准在内存分配和kswapd线程进行内存回收时会用到。

💡

我们可以通过 cat /proc/vmstat,其中的"pageoutrun"和"allocstall_(dma/dma32/normal/movable)"，分别查看kswapd和各个zone的direct reclaim启动的次数。

2.1.1 __setup_per_zone_wmarks

现在开始讲是如何设置这三个水线值的。函数的调用关系是：init_per_zone_wmark_min->setup_per_zone_wmarks->__setup_per_zone_wmarks

init_per_zone_wmark_min

calculate_min_free_kbytes

总结：

lowmem_kbytes：代表的意思是lowmem中超过高水位的页的总和，这里的单位是kbytes, 这就是lowmem中超过high水位的页乘以4这就是lowmem_kbytes

new_min_free_kbytes = sqrt(lowmem_kbytes * 16) = √(lowmem_kbytes * 16)

min_free_kbytes最小不能小于128K，最大不能超过65536K

setup_per_zone_wmarks

一个zone的"low"和"high"的值都是根据它的"min"值算出来的，"low"比"min"的值大1/4左右，"high"比"min"的值大1/2左右，三者的比例关系大致是4:5:6。

下面以一个项目来验证

2.1.2 实例计算水位

首先明确几点：

WATERMARK_MIN是由min_free_kbytes计算出

WATERMARK_LOW和WATERMARK_HIGH由WATERMARK_MIN计算得来

min_free_kbytes是在calculate_min_free_kbytes函数中得到

根据calculate_min_free_kbytes函数，

计算min_free_kbytes

lowmem_kbytes = 949265*(PAGE_SIZE>>10) = 3797060 min_free_kbytes = 4 * int_sqrt(lowmem_kbytes) = 7794

计算值与设备查询的值相近

计算watermark[WMARK_MIN]

pages_min = min_free_kbytes >> (PAGE_SHIFT - 10)=7794/4=1948 watermark[WMARK_MIN]=pages_min*zone_managed_pages(zone)/lowmem_pages= 1948

由于当前手机只有ZONE_NORMAL，所以zone_managed_pages(zone)=lowmem_pages，

所以watermark[WMARK_MIN] = 1948

计算watermark[WMARK_LOW]和计算watermark[WMARK_HIGH]

tmp=max_t(u64, 1948>>2, 949265*60/10000)=5695 watermark[WMARK_LOW]=watermark[WMARK_MIN]+tmp=1948+5695=7643 watermark[WMARK_HIGH]=watermark[WMARK_MIN]+tmp*2=1948+5695*2=13338

由此我们计算出三条水位为：

watermark[WMARK_MIN]=1948

watermark[WMARK_LOW]=7643

watermark[WMARK_HIGH]=13338

这与我们从设备中查询到的也是符合的！

引入watermark_scale_factor这个参数原因：避免突然遇到网络流量增大，需要短时间内申请大量的内存来存放网络请求数据，导致 kswapd 回收内存的速度可能赶不上内存分配的速度，从而达到watermark min，造成直接内存回收 direct reclaim，影响系统性能，解决直接内存回收导致的性能抖动问题

2.1.3 watermark_boost

该参数通过细粒度控制内存回收的尺度，使系统可动态提升三个watermark的值，使kswapd线程提前开始回收内存而且也可以回收更多内存。这样一方面可以减少内存规整（memory compact）的次数，另一方面发生内存规整，也可以更快的整合出大的连续物理内存，从而优化内存碎片对内存分配的影响。

对于watermark_boost，在boost_watermark()函数中，会对其设置，可以临时修改该值。跟其直接相关的参数是watermark_boost_factor，位于/proc/sys/vm下面。

Android编译原理之make编译过程

Fri, 18 Aug 2023 00:00:00 GMT

一、make

以高通的代码为例，高通在编译时使用如下的指令进行编译，实质是对make的封装

在执行一系列check的函数后，最终调用make执行执行编译。而make函数是在build/envsetup.sh时声明。

从get_make_command函数可知，make后，真正然后执行编译的入口是：build/soong/soong_ui.bash

二、soong_ui.bash

source microfactory.bash，得到一些函数命令，例如：soong_build_go

编译/build/soong/cmd/soong_ui/main.go，生成 out/soong_ui这个可执行程序

执行命令：out/soong_ui --make-mode ，执行了make命令，会把"build/make/core/main.mk" 加到构建环境中，同时启动kati、blueprint-soong、ninja的编译。

2.1 build/soong/scripts/microfactory.bash

build/soong/scripts/microfactory.bash

microfactory.bash得到build_go的函数命令,并提供 soong_build_go的函数执行方法并继续调用

build/blueprint/microfactory/microfactory.bash

GOROOT=prebuilts/go/linux-x86

2.2 build/blueprint/microfactory/microfactory.bash

build_go函数做了以下事情：

第一次执行编译时调用go run out/.microfactory_Linux/intermediates/src/microfactory.go编译出

microfactory_linux，第二次执行会执行检查，如果已编译则跳过go run

通过microfactory_Linux编译出soong_ui

soong_build_go soong_ui android/soong/cmd/soong_ui

> build_go soong_ui android/soong/cmd/soong_ui

实际调用逻辑为：

从这儿可以知道soong_build_go soong_ui android/soong/cmd/soong_ui的意思就是从soong/cmd/soong_ui/下的go文件编译生成soong_ui

2.3 soong_ui的源文件main.go

soong_ui 是通过编译 build/soong/cmd/soong_ui/main.go得来

主要执行soong/ui/build/build.go，从build.go就可以看到执行soong的大体流程。

main.go中配置的toBuild为 BuildProductConfig | BuildSoong | BuildKati | BuildNinja，支持productconfig\soong\kati\ninja的构建

2.4 build.go流程

runMakeProductConfig 主要配置编译参数

runSoong 对工具进行编译，编译出blueprint等编译工具, 把*.bp 编译成 out/soong/build.ninja

runKatiBuild, 加载 build/make/core/main.mk，搜集所有的Android.mk文件生成ninja文件:out/build-${product}.ninja

runKatiPackage, 加载build/make/packaging/main.mk, 编译生成out/build-aosp_arm-package.ninja

createCombinedBuildNinjaFile,将out/soong/build.ninja 、out/build-aosp_arm.ninja和out/build-aosp_arm-package.ninja，合成为out/combined-aosp_arm.ninja

runNinja，运行Ninja命令，解析combined-aosp_arm.ninja，执行编译过程

2.4.1 runMakeProductConfig

build/soong/ui/build/dumpvars.go

只是配置编译需要的参数

2.4.2 runSoong

主要功能：

对工具进行编译，编译出blueprint等编译工具

把*.bp 编译成 out/soong/build.ninja

2.4.2.1 Android R版本

runSoong()的执行过程：

执行build/blueprint/bootstrap.bash 生成.minibootstrap/build.ninja 和.bootstrap/build.ninja

生成minibp\bpglob

通过ninja来编译.minibootstrap/build.ninja 和.bootstrap/build.ninja

首先执行build/blueprint/bootstrap.bash

bootstrap.bash的作用：

它可以引导独立的blueprint来生成minibp二进制文件，可以直接运行 ./build/blueprint/bootstrap.bash。

也可以从另一个脚本调用它来引导基于Bleprint的自定义构建系统。

2.4.2.2 Android T版本

2.4.3 runKatiBuild

主要功能：

加载 build/make/core/main.mk

所有的Android.mk文件生成ninja文件:out/build-aosp_arm.ninja

runKati中会启动Kati程序，开始解析main.mk

最终是调用系统准备好的prebuilts/build-tools/linux-x86/bin/ckati参与编译，其中传入的参数有 --ninja\ --regen\--detect_android_echo 等，kati解析完build/make/core/main.mk后，就会⽣成相应的ninja编译规则，runKatiBuild()函数最后⽣成out/build-{product}.ninja⽂件

2.4.4 runKatiPackage

也是运行runKati，只不过携带的参数不同，runKatiPackage函数最后会生成out/build-{product}-package.ninja

2.4.5 createCombinedBuildNinjaFile

会将kati和soong_build两个程序⽣成的ninja⽂件都包含进来，再⽣成⼀个out/combined-${product}.ninja⽂件

2.4.6 runNinja

启动ninja程序解析out/combined-${product}.ninja⽂件，得到我们执⾏的命令⾥指定target-files-package模块的依赖⽂件,最后只要按照拓扑顺序挨个执⾏他们的rule去⽣成他们就可以了

Android编译原理之编译步骤

Fri, 18 Aug 2023 00:00:00 GMT

一、概述

在 Android 7.0 之前，Android 编译系统使用 GNU Make 描述和shell来构建编译规则，模块定义都使用Android.mk进行定义，Android.mk的本质就是Makefile，但是随着Android的工程越来越大，模块越来越多，Makefile组织的项目编译时间越来越长。这样下去Google工程师觉得不行，得要优化。

因此，在Android7.0开始，Google采用ninja来代取代之前使用的make，由于之前的Android.mk数据实在巨大，因此Google加入了一个kati工具，用于将Android.mk转换成ninja的构建规则文件buildxxx.ninja,再使用ninja来进行构建工作。

编译速度快了一些，但是既然要干，那就干个大的，最终目标要把make都取代，于是从Android8.0开始，Google为了进一步淘汰Makefile，因此引入了Android.bp文件来替换之前的Android.mk。

Android.bp只是一个纯粹的配置文件，不包括分支、循环语句等控制流程，本质上就是一个json配置文件。Android.bp 通过Blueprint+soong转换成ninja的构建规则文件build.ninja，再使用ninja来进行构建工作。

Android10.0上，mk和bp编译的列表可以从 out/.module_paths中的Android.bp.list、Android.mk.list中看到，Android10.0还有400多个mk文件没有被替换完，Google任重道远。

Android编译演进过程：

Android7.0之前使用GNU Make

Android7.0 引入ninja、kati、Android.bp和soong构建系统

Android8.0 默认打开Android.bp

Android9.0 强制使用Android.bp

Google在 Android 7.0之后，引入了Soong构建系统，旨在取代make，它利用 Kati GNU Make 克隆工具和 Ninja 构建系统组件来加速 Android 的构建。

Make 构建系统得到了广泛的支持和使用，但在 Android 层面变得缓慢、容易出错、无法扩展且难以测试。Soong 构建系统正好提供了 Android build 所需的灵活性。

二、编译流程

2.1 编译构成

Android的编译目录在build 中，看一下源码中的build目录，现在是这个样子

这个目录中可以看到core文件夹被link到了make/core，envsetup.sh被link到make/envsetup.sh，这主要是为了对使用者屏蔽切换编译系统的差异。

这里重点看四个文件夹：blueprint、kati、make、soong

blueprint	用于处理Android.bp，编译生成*.ninja文件，用于做ninja的处理
kati	用于处理Android.mk，编译生成*.ninja文件，用于做ninja的处理
make	文件夹还是原始的make那一套流程，比如envsetup.sh
soong	构建系统，核心编译为soong_ui.bash

Soong编译系统家族成员及各自关系如下图所示：

在编译过程中，Android.bp会被收集到out/soong/build.ninja.d,blueprint以此为基础，生成out/soong/build.ninja

Android.mk会由kati/ckati生成为out/build-aosp_arm.ninja

两个ninja文件会被整合进入out/combined-aosp_arm.ninja

2.2 编译步骤

三、编译工具链

编译系统中，涉及以下一些工具链，由这些工具链相辅相成，才最终编译出了我们所需要的镜像版本。

prebuilts/build_tools/linux-x86/bin/ninja

3.1 soong说明

Soong 构建系统是在 Android 7.0 (Nougat) 中引入的，旨在取代 Make。它利用 Kati GNU Make 克隆工具和 Ninja 构建系统组件来加速 Android 的构建。

Soong是由Go语言写的一个项目，从Android 7.0开始，在prebuilts/go/目录下新增了Go语言所需的运行环境，Soong在编译时使用，解析Android.bp，将之转化为Ninja文件，完成Android的选择编译，解析配置工作等。故Soong相当于Makefile编译系统的核心，即build/make/core下面的内容。

另外Soong还会编译产生一个androidmk命令，可以用来手动将Android.mk转换成Android.bp文件。不过这只对无选择、循环等复杂流程控制的Android.mk生效。

soong脚本和代码目录：/build/soong

3.2 kati说明

kati是一个基于Makefile来生成ninja.build的小项目。主要用于把Makefiel转成成ninja file，自身没有编译能力，转换后使用Ninja编译。

在编译过程中，kati负责把既有的Makefile、Android.mk文件，转换成Ninja文件。在Android 8.0以后，它与Soong一起，成为Ninja文件的两大来源。Kati更像是Google过渡使用的一个工具，等所有Android.mk都被替换成Android.bp之后，Kati有可能退出Android编译过程.

在单独使用时，它对普通的小项目还能勉强生效。面对复杂的、多嵌套的Makefile时，它往往无法支持，会出现各种各样的问题。当然，也可以理解为，它只为Android而设计。

kati脚本和代码目录：/build/kati

3.3 blueprint说明

Blueprint由Go语言编写，是生成、解析Android.bp的工具，是Soong的一部分。Soong则是专为Android编译而设计的工具，Blueprint只是解析文件的形式，而Soong则解释内容的含义。

在Android编译最开始的准备阶段，会执行build/soong/soong_ui.bash进行环境准备。

对blueprint项目编译完成之后会在out/soong/host/linux-x86/bin目录下生成soong编译需要的5个执行文件(bpfix,bpfmt,bpmodify,microfatory,bpmodify)。

Soong是与Android强关联的一个项目，而Blueprint则相对比较独立，可以单独编译、使用。

blueprint代码目录：/build/blueprint

3.4 ninja说明

Ninja是一个致力于速度的小型编译系统（类似于Make），如果把其他编译系统比做高级语言的话，Ninja就是汇编语言。通常使用Kati或soong把makefile转换成Ninja files，然后用Ninja编译。

主要两个特点：

1)可以通过其他高级的编译系统生成其输入文件；

2)它的设计就是为了更快的编译；

ninja核心是由C/C++编写的，同时有一部分辅助功能由python和shell实现。由于其开源性，所以可以利用ninja的开源代码进行各种个性化的编译定制。

从Android 7开始，编译时默认使用Ninja。但是，Android项目里是没有.ninja文件的。遵循Ninja的设计哲学，编译时，会先把Makefile通过kati转换成.ninja文件，然后使用ninja命令进行编译。这些.ninja文件，都产生在out/目录下，共有三类：

build-*.ninja文件，通常非常大，几十到几百MB。对make全编译，命名是build-.ninja。如果Makefile发生修改，需要重新产生Ninja文件。

mm、mma的Ninja文件，命名是build--.ninja。而mmm、mmma的Ninja文件，命名是build--_.ninja。

combined-*.ninja文件。在使用了Soong后，除了build-*.ninja之外，还会产生对应的combined-*.ninja，二者的*内容相同。这类是组合文件，是把build-*.ninja和out/soong/build.ninja组合起来。所以，使用Soong后，combined-*.ninja是编译执行的真正入口。

out/soong/build.ninja文件，它是从所有的Android.bp转换过来的

build-*.ninja是从所有的Makefile，用Kati转换过来的，包括build/core/*.mk和所有的Android.mk。所以，在不使用Soong时，它是唯一入口。在使用了Soong以后，会新增源于Android.bp的out/soong/build.ninja，所以需要combined-*.ninja来组合一下。

3.5 工具链的关系

Android.mk文件、Android.bp、kati、Soong、Blueprint、Ninja之间的关系如下：

四、编译步骤之envsetup.sh

4.1 validate_current_shell

确定当前的shell环境，建立shell命令

4.2 source_vendorsetup

4.3 addcompletions

五、编译步骤之lunch

5.1 lunch说明

环境变量初始化完成后，我们需要选择一个编译目标。lunch 主要作用是根据用户输入或者选择的产品名来设置与具体产品相关的环境变量。

如果你不知道想要编译的目标是什么，直接执行一个lunch命令，会列出所有的目标，直接回车，会默认使用aosp_arm-eng这个目标。

参数	说明
PLATFORM_VERSION_CODENAME=REL	表示平台版本的名称
PLATFORM_VERSION=13	Android平台的版本号
TARGET_PRODUCT=miodm_topaz_native	所编译的产品名称
TARGET_BUILD_VARIANT=userdebug	所编译产品的类型
TARGET_BUILD_TYPE=release	编译的类型，debug和release
TARGET_ARCH=arm64	表示编译目标的CPU架构
TARGET_ARCH_VARIANT=armv8-a	表示编译目标的CPU架构版本
TARGET_CPU_VARIANT=generic	表示编译目标的CPU代号
HOST_ARCH=x86_64	表示编译平台的架构
HOST_2ND_ARCH=x86	ㅤ
HOST_OS=linux	表示编译平台的操作系统
HOST_OS_EXTRA=linux-5.4.0-124-generic-x86_64-Ubuntu-18.04.6-LTS	编译系统之外的额外信息
HOST_CROSS_OS=windows	ㅤ
HOST_CROSS_ARCH=x86	ㅤ
HOST_BUILD_TYPE=release	ㅤ
BUILD_ID=TKQ1.220710.001	BUILD_ID会出现在版本信息中，可以利用
OUT_DIR=out	编译结果输出的路径

5.2 lunch

lunch指令是在envsetup.sh中被定义的。主要就是用来设置 TARGET_PRODUCT、TARGET_BUILD_VARIANT、TARGET_PLATFORM_VERSION、TARGET_BUILD_TYPE、TARGET_BUILD_APPS等环境变量

lunch操作流程如下：

获取lunch操作的参数，如果参数不为空，参数则为指定要编译的设备型号和编译类型；如果参数为空，会调用print_lunch_menu来显示Lunch菜单项，读取用户的输入，存入answer

如果answer为空，即之前在lunch菜单用，用户只敲了一个回车。会将默认选项改为aosp_arm-eng，结果存入selection

如果lunch操作得到的输入是数字，则将数字转换为LUNCH_MENU_CHOICES中的字符串，结果存入selection

解析selection的值，得到product = aosp_arm 和variant = eng, 把他们分别保存到TARGET_PRODUCT 和 TARGET_BUILD_VARIANT 中

根据前面的设置，调用build_build_var_cache 来更新编译环境相关变量

export 编译选项TARGET_PRODUCT, TARGET_BUILD_VARIANT和TARGET_BUILD_TYPE三元组

调用set_stuff_for_environment 来设置其他环境变量，如PROMPT_COMMAND，编译toolchain和tools相关的路径等

调用printconfig 来输出当前的设置选项

5.3 build_build_var_cache

根据前面的设置，更新编译环境相关变量

主要通过执行 "build/soong/soong_ui.bash --dumpvars-mode" 完成

最终执行的是 "./out/soog_ui --dumpvars-mode"

soong_ui 由build/soong/cmd/soong_ui/main.go编译生成

最后调用到了ckati执行-f build/make/core/config.mk

下面我们单独研究一下config.mk。

5.4 config.mk

说明：config.mk首先加载了build/make/common 中的core.mk、math.mk、strings.mk、json.mk 用来配置一些shell环境、math函数、string和json的一些支持函数。最主要的操作还是加载build/make/core中的envsetup.mk和dumpvar.mk

5.4.1 build/make/core/envsetup.mk

envsetup.mk 主要加载了product_config.mk和board_config.mk，用来得到TARGET_DEVICE和其他变量。

5.4.2 build/make/core/product_config.mk

5.4.3 build/make/core/board_config.mk

板级可以在$（SRC_TARGET_DIR）/board/$（TARGET_DEVICE）下定义，也可以在vendor/*/$（TARGET_DEVICE）下定义。

在这两个地方搜索，但要确保只存在一个。真正的板级应始终与OEM vendor相关联。``

六、总结

至此，envsetup.sh 和lunch()的初始化流程基本上理清了，主要就是加载了环境变量，并选择了编译目标，后面只要执行一下make就能够进行启动编译，下一节让我们一起看看敲下make后到底发生了什么。

Android系统中各image文件解压缩

Fri, 18 Aug 2023 00:00:00 GMT

Android系统编译之后的打包阶段，会将所有编译出来的有需要的执行文件，库文件以及各种配置文件等打包到各个镜像文件中。有时候我们需要看一下镜像文件中都打包了什么东西，那就可以通过一些方法将其挂载到一个目录，然后进行查看。

一、所用到的工具

1.1 simg2img

简述：将sparse格式的image文件转化为raw格式的image文件。编译android源码默认会生成。

路径：out/host/linux-x86/bin/simg2img

如果没有请用如下的指令编出

source build/envsetup.sh
lunch miodm_topaz_native-userdebug
export OUT_DIR=out && nj simg2img

1.2 lpunpack

简述：这个工具可以将system.img，product.img，vendor.img等文件从super.img解析出来。

路径：out/host/linux-x86/bin/lpunpack

如果没有请用如下的指令编出

source build/envsetup.sh
lunch miodm_topaz_native-userdebug
export OUT_DIR=out && nj lpunpack

1.3 unpack_bootimg

简述：专门用于解析boot.img的工具。

路径：out/host/linux-x86/bin/unpack_bootimg system/core/mkbootimg/unpack_bootimg.py

如果没有请用如下的指令编出

source build/envsetup.sh
lunch miodm_topaz_native-userdebug
export OUT_DIR=out && nj unpack_bootimg

1.4 mkdtimg

简述：将dtbo.img文件转化为dtb文件，一个dtbo.img会包含多个dtb文件；编译android源码默认会生成。

路径：out/host/linux-x86/bin/mkdtimg

如果没有请用如下的指令编出

source build/envsetup.sh
lunch miodm_topaz_native-userdebug
export OUT_DIR=out && nj mkdtimg

1.5 dtc

简述：将dtb文件转化为可阅读的dts文件；编译android源码默认会生成。

路径：out/host/linux-x86/bin/dtc

二、解压缩各image文件

2.1 boot.img/recovery.img/vendor_boot.img

2.1.1 解压缩

指令如下：

boot.img

recovery.img

vendor_boot.img

2.2 dtbo.img

先从dtbo.img中解析出dtb文件

将上一步的dtb文件转化为可以阅读的dts文件

也可以使用fdtdump

fdtdump -sd dtbo.img > dtbo.txt

2.3 dtb.img

也可以使用fdtdump

fdtdump -sd dtb.img > dtb.txt

2.4 metadata.img/userdata.img

将sparse格式的metadata.img转化为raw格式的metadata_raw.img

将metadata_raw.img挂载到一个目录上，此时访问这个目录就可以访问镜像文件的内容了

2.5 super.img

sparse格式转化为raw格式

使用lpunpack解析super_raw.img

挂载解析出来的镜像文件

2.6 persist.img

这个镜像是linux ext4格式的，直接挂载即可

高通Android启动代码流程分析(SBL->ABL)

Fri, 18 Aug 2023 00:00:00 GMT

一、前言

在面对UEFI阶段代码移植以及开机故障问题，需要对开机启动流程有一定的了解

二、芯片的冷启动

Cold boot flow: 冷启动

可以看出，在设备上电后，先跑的是 APPS PBL，接着运行XBL SEC、XBL Loader，通过Loader引出XBL CORE APPSBL，最后进入HLOS

备注：

下面补充点arm架构的知识点，以便可以看懂上图

2.1 异常级别

异常级别	运行的软件
EL0	Application
EL1	Linux kernel- os
EL2	Hypervisor（可理解为上面跑多个虚拟OS）
EL3	Secure Monitor（ARM Trusted Firmware）

ELx(x<4)，x越大等级越高，执行特权越高

执行在EL0，称为非特权执行

EL2没有Secure state，只有Non-secure state

EL3 只有Secure state，支持EL0/EL1的Secure 和Non-secure之间的切换

EL0 & EL1 必须要实现，EL2/EL3则是可选实现

当接收到一个异常时，异常级别只能调高或保持；

当从异常返回时，异常级别只能调低或保持

在接收到异常将要切换或保持的异常级别称为目标异常级别

每个异常级别本身有一个默认固定的目标异常级别，还可以通过寄存器设置目标异常级别，目标异常级别不能为EL0

当PE运行在一个异常级别时，可以访问如下两种资源：1)当前异常级别和安全状态组合下的资源；2)低异常级别可访问的资源（要符合安全状态）

2.2 secure state

状态	特点
Non-secure	EL0/EL1/EL2, 只能访问Non-secure 物理地址空间
Secure	EL0/EL1/EL3, 可以访问Non-secure 物理地址空间 & Secure 物理地址空间,可起到物理屏障安全隔离作用

这几个涉及的模块大概功能

Application primary boot loader (APPS PBL)

PBL 启动时，CPU只开启了第一个核心 CPU Core 0，运行固件在ROM中，这部分是高通写死在芯片中的固件，外部开发人员是无法修改这部份的。

主要功能为：

（1）系统安全环境的初始化，以确保后续的XBL中的APPS 能够正常运行。

（2）根据boot gpio的配置选择从什么设备启动操作系统（如 Nand，USB等）。

（3）通过检测GPIO判断是否进入Emergency Download mode，用户可以通过QFIL来下载完整的系统镜像。

（4）通过L2 TCM来加载XBL1 ELF，OCIMEM 和 RPM CodeRAM 代码。

Extensible boot loader (XBL)

从XBL开始，跑的就是我们编译下载进eMMC/UFS的系统镜像了，在XBL中主要是初始化相关的硬件环境，及代码安全环境。

（1）初始化 Buses、DDR、Clocks、CDT，启动QSEE，QHEE,RPM_FW, XBL core images。

（2）使能memory dump through USB and Sahara（系统死机时memory dump），看门狗，RAM dump to SD support等功能。

（3）初始化 USB驱动，USB充电功能，温升检测，PMIC驱动初始化，和 DDR training模块。

XBL core (UEFI or LK，ABL)

XBL core，就是之前的bootloader，主要功能就是初始化display驱动，提供fastboot功能，引导进入HLOS kernel操作系统。注意，在ABL中，同样也只有CPU Core0在工作，其他的CPU核以是在进入HLOS Kernel后才开始初始化启用的。

三、代码目录架构

以前的lk相关代码移到了boot_images/QcomPkg路径下，编译方式和之前也不同了

代码位于：${BP_ROOT}/BOOT.XF.1.4/boot_images/

四、PBL->SBL

PBL是上电后芯片执行的第一行代码，位于ROM中，PBL代码未开源，无法查看，之后通过PBL启动SBL。SBL1负责初始化部分硬件以进行后续引导，初始化DDR内存，加载TrustZone,加载RPM固件，加载ABL

从SBL开始就进入了XBL中，而我们所说的SBL1也就是XBL REG#1，代码为

BOOT.XF.4.1/boot_images/QcomPkg/SocPkg/Library/XBLLoaderLib/sbl1_Aarch64.s

4.1 sbl1_main_ctl函数

主要工作：一些重要外设的初始化，如RAM的初始化，为下一步程序的运行做准备

在sbl1_main_ctl中使用了sbl1_boot_logger_init进行了logger的初始化，这其中就会调用boot_log_init_uart，将串口进行初始化

在这个阶段如果需要加log，有下面几种方式：

boot_log_dump(boot_log_ram_to_uart)将ram中的所有log从串口输出

boot_log_message，此函数是加log比较方便的方式，此函数会将需要打印的log同时写入ram以及输出到串口

上面分析的函数在开机串口log中的体现如下：

4.2 boot_config_process_bl函数

此函数为核心函数，形参包括sbl共享数据结构，SBL1镜像文件，和sbl1配置表。函数循环调用boot_config_process_entry对配置表中各项进行配置，配置列表中包含PMIC、APDP、QSEE (Qualcomm secure execution environment）、QHEE( Qualcomm secure execution environment）、RPM、STI、ABL、APPSBL等子系统。

在sbl1_config_table结构体数组中，每个数组按照对应顺序对应PMIC、RPM等子系统，在子系统中的load_..._pre_procs函数和load...post_procs，两个函数中分别对应相应系统加载前要做的初始化和配置操作以及加载后操作。

这部分的代码有点难以理解：

对应的串口如下：

在串口中对应的打印信息Image load Start，APDP Image Loaded,Delta；Image_Load,Start......就是对应函数boot_config_process_entry函数该阶段的image加载、验证与执行都是类似RPM、QSEE、这种子系统环境的搭建，之后在ABL部分会正式进行kernel的加载进而启动HLOS

五、SBL

其实第四节已经将SBL的流程梳理了，本章节独立出来是希望能更加细节的研究一下这部分的代码

5.1 sbl1_xblconfig_init

5.2 sbl1_hw_pre_ddr_init

5.2.1 boot_pm_device_init

PMIC相关的逻辑不扩展，可查看这一系列文章SBL PMIC 流程分析

https://wiki.n.miui.com/pages/viewpage.action?pageId=610308677

5.2.2 sbl1_hw_reset_platform_type和sbl1_hw_reset_platform_version

这部分涉及高通平台boardid的设计，详细可查看小米古明涛大神的文章

https://wiki.n.miui.com/pages/viewpage.action?pageId=135269079

https://wiki.n.miui.com/display/~gumingtao/2018/12/18/How+to+select+Dtb

六、UEFI背景介绍

要详细了解UEFI，还得从BIOS讲起。我们都知道，每一台普通的电脑都会有一个BIOS，用于加载电脑最基本的程式码，担负着初始化硬件，检测硬件功能以及引导操作系统的任务。UEFI就是与BIOS相对的概念，这种接口用于操作系统自动从预启动的操作环境，加载到一种操作系统上，从而达到开机程序化繁为简节省时间的目的。传统BIOS技术正在逐步被UEFI取而代之，在最近新出厂的电脑中，很多已经使用UEFI，使用UEFI模式安装操作系统是趋势所在。

主要是由于安腾处理器芯片组的创新，64位架构的处理器已经不再适用于传统BIOS的16运行模式，因此intel将系统固件和OS的接口完全重新定义成一个可扩展、标准化的固件接口规范。

优化项	UEFI	BIOS	描述
开发效率	• 开源 • 标准接口 • 绝大部分是c代码	• 闭源 • 接口混乱 • 主要采用汇编	正是由于BIOS的闭源以及混乱的接口导致其停滞不前，并最终无法适用于新架构的芯片。UEFI的开源且指定了标准的接口规范，并且也同提供接口，将大部分代码替换成c进行编写，不再使用晦涩的汇编进行开发，这样大大降低了开发的难度，这也是其迅速发展的根本原因。
性能	异步+时钟中断	中断机制	UEFI舍弃了硬件外部中断的低效方式，只保留了时钟中断机制，然后通过异步+事件来实现对外部设备的操作，性能由此得到了极大的提升。
扩展和兼容性	模块化驱动设计	静态链接	UEFI采用了规范的模块化设计，在扩展功能的时候只需要动态链接其模块就可以实现，这样的扩展十分方便便捷。而传统的BIOS必须运行在16位的指令模式之下，寻址范围也十分有限，而UEFI支持64位程序，并兼容32位，这也是为什么老古董windows XP出现这么久了，稍微改改就可以安装在新的设备上。
安全性	安全	未考虑安全性问题	UEFI安装的驱动设备是需要经过签名验证才可以安装的，并且还采用了一定的加密机制进行验证，这样的安全机制一定程度上可以保障我们设备的安全。
驱动器容量	支持容量>2TB的驱动器	不支持容量>2TB的驱动器	• 传统的BIOS只支持容量不超过2TB的驱动器，因为常见的512Byte扇区的分区表的单个分区的第13-16字节是用来进行LAB寻址的，也就是以扇区为单位进行寻址。总共4个字节，也就是48 = 32位，也就是2^32个单位空间，以扇区为单位进行寻址，也就是每次512Byte，那么： 2^32512 = 2^41B = 2^31KB = 2^21MB = 2^11GB = 2TB. 所以传统的BIOS支持的最大容量的驱动器不超过2TB，以硬件厂商1000：1024的计算方式，实际容量是小于2TB的。 • UEFI支持64位的地址空间，所以其寻址偏移刚好为一个机器长度——64位，即8Byte，还是按照LAB寻址方式进行计算：2^64*512 = 2^73B = 2^13EB = 8ZB但是，微软官方给的资料显示是18EB（按照硬件厂商1000：1024计算）(10^60)/(10^60) = 18EB
文件系统	拥有文件系统的支持	无	由于UEFI本身已经相当于一个微型的OS了，具备了文件系统的支持，能够直接读取FAT分区中的文件。
应用程序	可以开发出直接在UEFI下运行的应用程序	无	这类程序文件通常以efi结尾。既然，UEFI既可以直接识别FAT分区中的文件，又可以直接在其中运行应用程序，那么完全可以将win安装程序做成efi类型的应用程序，然后放在任意的FAT分区中，直接运行即可。这样一来，原来安装win操作系统这个过去看起来有些许小复杂的事情忽然变得异常简单，就像在win中打开一个qq一样简单。而这在BIOS上是无法做到，因为BIOS下启动OS之前，必须从硬盘上指定扇区读取系统的启动代码（包含在主引导记录中），然后从活动分区中引导OS的启动。对扇区的操作远远比不上对分区中的文件的操作来得直观和简单，所以在BIOS上安装win这类的OS，不得不使用一些工具对设备进行配置以达到启动要求。

6.1 Android的bootloader

UEFI的出道是在PC领域，UEFI+gpt以其自身优点干翻了传统bios+mbr，UEFI也成为了未来bootloader的发展方向，计算机软件界有一个名言，计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决（抽象），UEFI也不例外，之所以bios不行一个重要的点就是因为他的兼容性，UEFI为固件和操作系统提供了统一的接口，打通了PC固件之间的鸿沟；安卓bootloader从最初使用uboot，到lk（目前大多数依然是lk），一直到现在选择使用uefi，也足以证明UEFI的优势；原来的安卓启动是采用boot loader这种引导启动方式。在有的文章中，会将bootloader进行比较，有的又会说现在的安卓bootloader是使用UEFI，而且在查找有关Android启动流程或者说开机流程的文章里，大部分还是在loader层以bootloader作为启动流程中的一部分。这里，算是给自己统一下说法，早期的bootloader是一种引导程序的名称，后来采用了LK、UEFI之后，bootloader就是代指某种的引导程序的统称，换句话说，UEFI、LK都是安卓bootloader采用的一种引导方式。所以，在学习安卓开机流程的时候，如果不关注loader层，完全可以忽略这里的bootloader采用的是哪种方式。这里说的有点绕，简单来说bootloader可以理解为一种过时的引导程序（古早且已经被时代淘汰了），也可以理解为引导程序的统称（比如，UEFI是一种bootloader、LK是一种bootloader，甚至可以说BIOS是一种bootloader），现在我们讲bootloader就是在第二种理解。

6.2 UEFI概述

UEFI: 统一可扩展固件接口（Unified Extensible Firmware Interface，UEFI），是一种详细描述全新类型接口的标准，是适用于电脑的标准固件接口，旨在代替BIOS（基本输入/输出系统）。此标准由UEFI联盟中的140多个技术公司共同创建，如intel、IBM、Microsoft、AMI等等。UEFI旨在提高软件互操作性和解决BIOS的局限性。它用来定义操作系统和系统固件之间的软件界面，作为BIOS的替代方案，其主要目的是为了提供一组在 OS 加载之前（启动前）在所有平台上一致的、正确指定的启动服务，被看做是有近20多年历史的 BIOS 的继任者，并且UEFI的security有所加强，在手机这个微型PC，或者说在android系统启动之中替代了bootloader和litter kernel，是新时代系统启动引导程序。

总的来说，UEFI是一个规范，被定义为一个软件接口，用于连接OS和遵守这个规范的平台固件platform firmware。

七、UEFI流程分析

7.1 XBL Loader Architecture

7.2 xbl代码运行流程

从图中可以看出，UEFI代码运行流程为：

SEC(安全验证)--->PEI(EFI前期初始化)--->DXE(驱动执行环境)--->BDS(启动设备选择)--->UEFI Loader(操作系统加载前期)--->RT(Run Time)

。

7.2.1 SEC(安全验证)

SEC的汇编代码入口位于：BOOT.XF.4.1/boot_images/QcomPkg/XBLCore/ModuleEntryPoint.masm的_ModuleEntryPoint

7.2.1.1 ModuleEntryPoint.masm 代码分析

该汇编代码中，主要工作为：

关闭所有中断

关闭MMU和Caches

关闭TLB缓存表

获得当前运行的安全环境：EL1、EL2、EL3

初始化ELX 安全环境

使能 Cache

初始化栈

调用 CEntryPoint，传参 _StackBase、_StackSize

7.2.1.2 XBLCore\Sec.c 代码分析

前面汇编代码中主要目的是初始化C运行环境，初始化栈，以便可以调C代码运行。

SEC的C代码入口位于：BOOT.XF.4.1/boot_images/QcomPkg/XBLCore/Sec.c

主要就是main函数

lib源码位置：BOOT.XF.4.1/boot_images/QcomPkg/SocPkg/DivarPkg/LAA/Core.dsc

至于dsc、inf、fdf之间的关系可以查看文章：UEFI学习

7.2.1.2.1 LoadAndParsePlatformCfg

主要工作流程如下：

初始化相关全局变量

加载并解析 uefiplat.cfg 配置文件 #define UEFIPLATCFG_FILE "uefiplat.cfg",文件内容保存在 CfgBuffer 中，解析器描述符保存在MemParserDesc 中。在cfg文件中包含了内存相关的信息及系统相关的配置，BOOT.XF.4.1/boot_images/QcomPkg/SocPkg/DivarPkg/LAA/uefiplat.cfg

解析 uefiplat.cfg 中的 [Config] 区域

解析 uefiplat.cfg 中的 [MemoryMap] 区域

解析 uefiplat.cfg 中的 [RegisterMap] 区域，内容保存在mMemRegions中

解析 uefiplat.cfg 中的 [ConfigParameters] 区域，内容保存在 ConfigTable 中，ConfigTableEntryCount表示其内容的数量

解析 uefiplat.cfg 中的 [ChipIDConfig] 区域

7.2.1.2.2 UefiBootContinue

DisplayEarlyInfo() 显示模块早期初始化

在 DisplayEarlyInfo 中主要工作就是解析 UEFI version 版本号，然后根据版本号加载对应的镜像，接着打印系统启动的路径。

主要流程为：

获取UefiPlatCfg.c中的UEFI CORE字段信息，PlatConfigFileName="uefiplatLA.cfg"

获取固件版本号，定义在boot_images\QcomPkg\Sdm660Pkg\LA\Sdm660Pkg_Core.dsc中

gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"4.2"

根据固件版本号查找对应的image镜像 Append Image version string component

打印UEFI固件版本号

选UEFI启动类型，判断顺序为 UFS > EMMC > SPI

7.2.2 DXE(驱动执行环境)

从上一章分析后，代码将进入DXE继续执行，函数入口为 LoadDxeCoreFromFv()

先查找DXE_CORE的文件地址，接着调用LoadDxeCoreFromFfsFile 加载 EntryPoint函数

之后CPU跳转到了ENTRY_POINT函数 DxeMain()中

代码路径：BOOT.XF.1.4/boot_images/MdeModulePkg/Core/Dxe/DxeMain.inf

这段代码比较复杂，基本看不懂

主要工作流程如下：

初始化CPU异常处理

初始化内存等，初始化UEFI代码基础环境

初始化DXE调度器

7.2.3 BDS (启动设备选择)

代码路径：BOOT.XF.4.1/boot_images/QcomPkg/Drivers/BdsDxe/BdsDxe.inf

其主要工作为：

注册按键事件，按下按键后会回调到HotkeyEvent() 函数，最终调用到HotkeyCallback()函数中，解析其中的key scancode

平台BDS初始化

在其中会打印显示版本号，平台版本信息等等

调用LaunchDefaultBDSApps ()加载默认APP

调用SetupPlatformSecurity()初始化secureboot安全环境

挂载efisp分区

调用ReadAnyKey() 循环检测音量下键是否按下，从而更新对应的启动项

初始化所有 DriverOptionList 上的驱动协议。

根据选择的启动方式，启动对应的的系统

7.2.4 RT(Run Time)

代码位于BOOT.XF.4.1/boot_images/MdeModulePkg/Core/RuntimeDxe/Runtime

看不懂，和我们关系也不大

7.3 如何创建 UEFI DXE_DRIVER 驱动及UEFI_APPLICATION 应用程序

本章可查看：第一个UEFI程序

此篇文章以hello world的Dxe driver以及Application为例，在串口输出打印log

7.4 UEFI XBL QcomChargerApp充电流程代码分析

系统开机过程中，初始化 BDS 时，会调用LaunchDefaultBDSApps()函数，在该函数中，会实现对上述两个默认app 的调用。

解析 uefiplat.cfg 中的 DefaultChargerApp，字符串保存在 DefaultApp 数组中。

加载 QcomCharger App 应用程序，传参gMainFvGuid 和 “DefaultChargerApp”

解析 uefiplat.cfg 中的 DefaultBDSBootApp，字符串保存在 DefaultApp 数组中

加载 DefaultBDSBootApp 应用程序，加载后不再返回

后续部分请查看文章QCOM UEFI QcomChargerApp充电流程代码分析

八、UEFI之ABL

BOOT.XF.4.1/boot_images/QcomPkg/QcomToolsPkg/MenuApp/Uefi_Menu.cfg中可以定制相关的option

在LaunchDefaultBDSApps函数中load uefiplat.cfg中定义的DefaultChargerApp和DefaultBDSBootApp

而LinuxLoader是属于UEFI Application，这个代码是在ap侧的abl中

[SWR0011671][Sensor][P2] 量产机型能够抓取子系统ramdump

Thu, 07 Nov 2024 00:00:00 GMT

机器硬件损坏会触发子系统重启，一直产生ramdump文件，最终占满手机内存，严重影响用户使用；本地需要多次手动重启子系统，查看对应目录下是否有ramdump文件疯狂增长的情况；