高通编译环境

‘壹’ 如何编译高通kernal设备树

DTS （device tree source）
.dts文件是一种ASCII 文本格式的Device
Tree描述，此文本格式非常人性化，适合人类的阅读习惯。基本上，在ARM
linux在，一个。dts文件对应一个ARM的machine，一般放置在内核的arch/arm/boot/dts/目录。由于一个SoC可能对应多个machine（一个SoC可以对应多个产品和电路板），势必这些。dts文件需包含许多共同的部分，Linux内核为了简化，把SoC公用的部分或者多个machine共同的部分一般提炼为。dtsi，类似于c语言的头文件。其他的machine对应的。dts就include这个。dtsi。譬如，对于VEXPRESS而言，vexpress-v2m.dtsi就被vexpress-v2p-ca9.dts所引用，
vexpress-v2p-ca9.dts有如下一行：
/include/
“vexpress-v2m.dtsi”
当然，和C语言的头文件类似，。dtsi也可以include其他的。dtsi，譬如几乎所有的ARM
SoC的。dtsi都引用了skeleton.dtsi。
.dts（或者其include的。dtsi）基本元素即为前文所述的结点和属性：
[plain] view
plainprint?
/ {
node1 {
a-string-property = “A string”;
a-string-list-property = “first string”, “second string”;
a-byte-data-property = [0x01 0x23 0x34 0x56];
child-node1 {
first-child-property;
second-child-property = <1>;
a-string-property = “Hello, world”;
};
child-node2 {
};
};
node2 {
an-empty-property;
a-cell-property = <1 2 3 4>; /* each number （cell） is a uint32 */
child-node1 {
};
};
};
/ {
node1 {
a-string-property = “A string”;
a-string-list-property = “first string”, “second string”;
a-byte-data-property = [0x01 0x23 0x34 0x56];
child-node1 {
first-child-property;
second-child-property = <1>;
a-string-property = “Hello, world”;
};
child-node2 {
};
};
node2 {
an-empty-property;
a-cell-property = <1 2 3 4>; /* each number （cell） is a uint32 */
child-node1 {
};
};
};
上述。dts文件并没有什么真实的用途，但它基本表征了一个Device
Tree源文件的结构：
1个root结点“/”；
root结点下面含一系列子结点，本例中为“node1” 和
“node2”；
结点“node1”下又含有一系列子结点，本例中为“child-node1” 和
“child-node2”；
各结点都有一系列属性。这些属性可能为空，如“
an-empty-property”；可能为字符串，如“a-string-property”；可能为字符串数组，如“a-string-list-property”；可能为Cells（由u32整数组成），如“second-child-property”，可能为二进制数，如“a-byte-data-property”。
下面以一个最简单的machine为例来看如何写一个。dts文件。假设此machine的配置如下：
1个双核ARM
Cortex-A9 32位处理器；
ARM的local bus上的内存映射区域分布了2个串口（分别位于0x101F1000 和
0x101F2000）、GPIO控制器（位于0x101F3000）、SPI控制器（位于0x10170000）、中断控制器（位于0x10140000）和一个external
bus桥；
External bus桥上又连接了SMC SMC91111
Ethernet（位于0x10100000）、I2C控制器（位于0x10160000）、64MB NOR
Flash（位于0x30000000）；
External bus桥上连接的I2C控制器所对应的I2C总线上又连接了Maxim
DS1338实时钟（I2C地址为0x58）。
其对应的。dts文件为：
[plain] view
plainprint?
/ {
compatible = “acme,coyotes-revenge”;
#address-cells = <1>;
#size-cells = <1>;
interrupt-parent = <&intc>;
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
compatible = “arm,cortex-a9”;
reg = <0>;
};
cpu@1 {
compatible = “arm,cortex-a9”;
reg = <1>;
};
};
serial@101f0000 {
compatible = “arm,pl011”;
reg = <0x101f0000 0x1000 >;
interrupts = < 1 0 >;
};
serial@101f2000 {
compatible = “arm,pl011”;
reg = <0x101f2000 0x1000 >;
interrupts = < 2 0 >;
};
gpio@101f3000 {
compatible = “arm,pl061”;
reg = <0x101f3000 0x1000
0x101f4000 0x0010>;
interrupts = < 3 0 >;
};
intc: interrupt-controller@10140000 {
compatible = “arm,pl190”;
reg = <0x10140000 0x1000 >;
interrupt-controller;
#interrupt-cells = <2>;
};
spi@10115000 {
compatible = “arm,pl022”;
reg = <0x10115000 0x1000 >;
interrupts = < 4 0 >;
};
external-bus {
#address-cells = <2>
#size-cells = <1>;
ranges = <0 0 0x10100000 0x10000 // Chipselect 1, Ethernet
1 0 0x10160000 0x10000 // Chipselect 2, i2c controller
2 0 0x30000000 0x1000000>; // Chipselect 3, NOR Flash
ethernet@0,0 {
compatible = “smc,smc91c111”;
reg = <0 0 0x1000>;
interrupts = < 5 2 >;
};
i2c@1,0 {
compatible = “acme,a1234-i2c-bus”;
#address-cells = <1>;
#size-cells = <0>;
reg = <1 0 0x1000>;
interrupts = < 6 2 >;
rtc@58 {
compatible = “maxim,ds1338”;
reg = <58>;
interrupts = < 7 3 >;
};
};
flash@2,0 {
compatible = “samsung,k8f1315ebm”, “cfi-flash”;
reg = <2 0 0x4000000>;
};
};
};
/ {
compatible = “acme,coyotes-revenge”;
#address-cells = <1>;
#size-cells = <1>;
interrupt-parent = <&intc>;
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
compatible = “arm,cortex-a9”;
reg = <0>;
};
cpu@1 {
compatible = “arm,cortex-a9”;
reg = <1>;
};
};
serial@101f0000 {
compatible = “arm,pl011”;
reg = <0x101f0000 0x1000 >;
interrupts = < 1 0 >;
};
serial@101f2000 {
compatible = “arm,pl011”;
reg = <0x101f2000 0x1000 >;
interrupts = < 2 0 >;
};
gpio@101f3000 {
compatible = “arm,pl061”;
reg = <0x101f3000 0x1000
0x101f4000 0x0010>;
interrupts = < 3 0 >;
};
intc: interrupt-controller@10140000 {
compatible = “arm,pl190”;
reg = <0x10140000 0x1000 >;
interrupt-controller;
#interrupt-cells = <2>;
};
spi@10115000 {
compatible = “arm,pl022”;
reg = <0x10115000 0x1000 >;
interrupts = < 4 0 >;
};
external-bus {
#address-cells = <2>
#size-cells = <1>;
ranges = <0 0 0x10100000 0x10000 // Chipselect 1, Ethernet
1 0 0x10160000 0x10000 // Chipselect 2, i2c controller
2 0 0x30000000 0x1000000>; // Chipselect 3, NOR Flash
ethernet@0,0 {
compatible = “smc,smc91c111”;
reg = <0 0 0x1000>;
interrupts = < 5 2 >;
};
i2c@1,0 {
compatible = “acme,a1234-i2c-bus”;
#address-cells = <1>;
#size-cells = <0>;
reg = <1 0 0x1000>;
interrupts = < 6 2 >;
rtc@58 {
compatible = “maxim,ds1338”;
reg = <58>;
interrupts = < 7 3 >;
};
};
flash@2,0 {
compatible = “samsung,k8f1315ebm”, “cfi-flash”;
reg = <2 0 0x4000000>;
};
};
};
上述。dts文件中，root结点“/”的compatible 属性compatible =
“acme,coyotes-revenge”;定义了系统的名称，它的组织形式为：<manufacturer>,<model>。Linux内核透过root结点“/”的compatible
属性即可判断它启动的是什么machine。
在。dts文件的每个设备，都有一个compatible
属性，compatible属性用户驱动和设备的绑定。compatible
属性是一个字符串的列表，列表中的第一个字符串表征了结点代表的确切设备，形式为“<manufacturer>,<model>”，其后的字符串表征可兼容的其他设备。可以说前面的是特指，后面的则涵盖更广的范围。如在arch/arm/boot/dts/vexpress-v2m.dtsi中的Flash结点：
[plain] view
plainprint?
flash@0,00000000 {
compatible = “arm,vexpress-flash”, “cfi-flash”;
reg = <0 0x00000000 0x04000000>,
<1 0x00000000 0x04000000>;
bank-width = <4>;
};
flash@0,00000000 {
compatible = “arm,vexpress-flash”, “cfi-flash”;
reg = <0 0x00000000 0x04000000>,
<1 0x00000000 0x04000000>;
bank-width = <4>;
};
compatible属性的第2个字符串“cfi-flash”明显比第1个字符串“arm,vexpress-flash”涵盖的范围更广。
再比如，Freescale
MPC8349 SoC含一个串口设备，它实现了国家半导体（National Semiconctor）的ns16550
寄存器接口。则MPC8349串口设备的compatible属性为compatible = “fsl,mpc8349-uart”,
“ns16550”。其中，fsl,mpc8349-uart指代了确切的设备， ns16550代表该设备与National Semiconctor
的16550
UART保持了寄存器兼容。
接下来root结点“/”的cpus子结点下面又包含2个cpu子结点，描述了此machine上的2个CPU，并且二者的compatible
属性为“arm,cortex-a9”。
注意cpus和cpus的2个cpu子结点的命名，它们遵循的组织形式为：<name>[@<unit-address>]，<>中的内容是必选项，[]中的则为可选项。name是一个ASCII字符串，用于描述结点对应的设备类型，如3com
Ethernet适配器对应的结点name宜为ethernet，而不是3com509。如果一个结点描述的设备有地址，则应该给出@unit-address。多个相同类型设备结点的name可以一样，只要unit-address不同即可，如本例中含有cpu@0、cpu@1以及serial@101f0000与serial@101f2000这样的同名结点。设备的unit-address地址也经常在其对应结点的reg属性中给出。ePAPR标准给出了结点命名的规范。

‘贰’ ubuntu下怎么编译android源码

这个关键是要看你的电脑配置情况，以及代码的附加情况，有的平台软件会附加很多东西上去，编译就比较慢了。 我们这边使用的是四核八线程的电脑，32GB内存， 原生代码 4.4 八线程编译40分钟左右，5.1，一个半小时左右，6.0的大约一个小时，以上是原生代码编译模拟器的时间。 高通代码6.0编译一般需要两个小时左右，mtk的也是两个小时左右，

‘叁’ 高通mdm9607 mcfg_sw.mbn配置编译流程

1.未添加运营商mcfg_sw.mbn配置文件，存在设备找网速度慢的问题。

2.添加高通默认配置mcfg_sw.mbn，出现问题：
（1）设备插入移动卡，呼入会出现自动接听。
（2）设备插入电信4G卡，无法4G上网。
（3）设备插入特定物联网卡，UE无法正常切换对应运营商配置。默认切换至3GPP，导致无法正常上网。

3.使用QXDM 修改网络相关的nv参数，切换运营商卡后，nv参数配置失效。

1.设备搜网会根据对应运营商mcfg_sw.mbn中配置去搜寻相应的频段，未添加则会导致设备轮询所有频段，从而导致驻网速度慢。

2.高通通过nv项中的参数来设置设备一些定制功能。
（1）查看nv850（CT电信默认配置为cs only）从而导致电信卡4G无法上网
PS域(Packet SwitchedDomain)为分组（交换）域，CS域(Circuit SwitchedDomain)为电路（交换）域。
通俗的说，打电话语音信号走的是CS，上网等数据业务信号走PS。
（2）查看nv74（CMCC移动卡默认配置为enable）nv74是控制电话自动接听，因此出现移动卡设备呼入会出现自动接听。

3.UE会根据插入运营商卡的iccid来切换相应mcfg_sw.mbn配置。物联网卡采用专用号段，因此可能存在配置不支持导致无法正常切换运营商配置。
（由于这批移动物联网卡iccid前几位为898604，mbn未配置因此会导致UE无法正常切换mbn配置，导致无法上网。）
什么是物联网卡

4.使用QXDM修改参数后为何切换不同运营商卡后，nv配置参数会失效。
假设插入电信卡后，设备通过QXDM修改nv，改nv值并没有写入到mcfg_sw.mbn中，简单理解为临时参数。
当设备插入移动卡后，UE会根据iccid来切换mcfg_sw.mbn。它获取的参数依然是从该文件内部读取，修改的值未起到作用。

图为运营商mbn配置，CU CMCC CT 分别对应联通、移动、电信。其他为默认硬件软件配置。

1.修改XML源文件

（1）路径：modem_proc\mcfg\mcfg_gen\generic\china（有全球各个地区的运营商配置信息）

图为生成cmcc mcfg_sw.mbn各个xml配置文件

（2）修改内容
CT:

CMCC:

目前只在已有的NvItemData项中修改参数，还未测试自己添加新的nv配置。

2.编译流程

（1）编译参数说明

（2）实际测试命令

a.进入/modem_proc/mcfg/build

b.编译CT mbn命令：
perl build_mcfgs.pl --build_id=9607.genns.prod --configs=mcfg_sw:OpenMkt-Commercial --force-regenerate --force-rebuild --source-dir=generic/China/CT --xml
mbn文件生成路径：/modem_proc/mcfg/configs/mcfg_sw/generic/China/CT/Commercial/OpenMkt

c.编译CMCC mbn命令：
perl build_mcfgs.pl --build_id=9607.genns.prod --configs=mcfg_sw:Commercial-CSFB-SS-LocTech --force-regenerate --force-rebuild --source-dir=generic/China/CMCC --xml
mbn文件生成路径：/modem_proc/mcfg/configs/mcfg_sw/generic/China/CMCC/CSFB/SS

3.出现问题：
（1）现象
Building MBN for mcfg_sw:Commercial-CSFB-SS-LocTech...
Could not open or create temporary file '/media/root/exdisk/workspace/L170_4K/modem_proc/mcfg/mcfg_gen/scripts/data/efs_files/cmcc/profile4'
没有那个文件或目录 at ../mcfg_gen/scripts/mcfg_write.pm line 1242.

（2）原因
源码中该文件大小写存在差异，去源码中修改相应profile文件大小写，问题解决。

4.xml新增移动物联网卡支持

（1）找到移动对应的xml文件

（2）添加物联网卡iccid前6位数字。

(3)重新编译mcfg_sw.mbn文件，通过PDC tool重新load设备，测试成功。

‘肆’ 编译高通出现这个错误，哪位大神帮个忙 /bin/bash: jar: command not found

没有安装jdk，jar是jdk里包含的命令。下载安装jdk即可。注意，jre里没这个命令。

‘伍’ 小米8、一加6T可成功刷入 Windows11 系统

Windows 11已经来了，不少开发者也出手，将新系统移植到手机上。

来自中国武汉的大神 Xilin Wu 也成功将 Windows 11 系统移植到运行高通骁龙 845 的小米8、一加6T手机上。不过该操作系统的大部分内容是无法使用，例如开发者称目前并不支持通话。

为了在 Android 手机上运行 Windows 11 系统，开发者已经创建了自己的工具/驱动程序，并为骁龙845启用了自定义的UEFI环境。这是因为高通公司的xbl(UEFI固件)和abl(加载 Linux 内核所需)在零售设备上签名，它们不能被修改。因此，不可能使用库存引导程序启动 Windows。

需要注意的是，微软并没有计划将 Windows 11 引入到移动端。而正是这些充满热情、技术娴熟的达人，通过创建定制工具和驱动程序才成功在手机上运行这款桌面系统。

目前，Windows 11 只能在一加6T、小米8 和一些骁龙原型机上运行。

微软 Windows 11 Insider Preview 版本 Build 22000.51 镜像已流出，其中包括 Windows 11 ARM 预览版本，有开发者已经在 Lumia 950 XL 刷入了 Windows 11 ARM 预览版本。

高通845刷win11系统项目地址:

https://github.com/edk2-porting/edk2-sdm845

这个项目的作者对使用者进行了提醒，如果要编译这个项目，请确定你有一定的Linux常识，如果你看不懂教程，那么请离开。

骁龙845(sdm845)的EDK2 UEFI固件已支持的设备，此列表为能够启动进入UEFI Shell的设备。

小米MIX2S (polaris)

小米MIX3 (perseus)

小米8 (dipper)

小米PocoPhone F1 (beryllium)

一加6 (enchilada)

一加6T (fajita)

努比亚X (nx616j)

魅族16th (m1882)

黑鲨手机一代 (skr-a0)

LG G7 (judyln) (会自动重启)

三星S9+ (star2qltechn) (有可能会清空UFS)

小米7 (dipper-old)

OPPO Find X (pafm00)

锤子坚果R1 (trident)

诺基亚9 PureView(olympic)

警告

请勿尝试移植到任何索尼设备上，你的UFS会被清空!!!

高通845编译Win11系统视频：

https://www.bilibili.com/video/BV1ab4y197e7

小米8手机Windows11系统预览：

下面是小米 8 手机进入 Windows 11 ARM64 系统后的桌面，“开始”菜单等在任务栏居中显示。

微软官方此前早已经对 Windows 10 Mobile 停止支持，不过在 WoA 项目开发者的努力下，仍然会有开发者去为旧机型刷入新系统。

由于微软提供了 ARM 设备兼容的 Windows 10 版本，一群独立开发人员在过去几年里一直在维护一个非官方的 Lumia Windows on ARM 项目，这就是 Lumia WOA。现在微软发布了 Windows 11 ARM 预览版本，又有新的系统可以尝试了。

‘陆’ 高通selinux怎么单独编译

模块编译。selinux编译修改了*.te，可以选择模块编译，也可以全编译。makeselinux_policy，编译system/sepolicy/Android.mk中selinux_policy目标，也将Android.mk中大部分目标都编译了。

‘柒’ 高通 ap_standard_oem test_device的区别是什么

ap_standard_oem带源码，可以自己修改代码编译镜像；
test_device是高通发布的编译好的镜像。

‘捌’ 高通到底做错了什么

虽然曾经的高通以先进的自研架构碾压对手，但是目前高通已经越来越显出疲态，个人认为，从805发布以后，高通一直在犯错。

这次写一篇长文，聊聊高通到底做错了什么。

801发布才过去三个月，高通很明显并没有对801的2.45g高频满足，进一步改进架构并提频，推出了805，这款频率高达2.7g的32位Soc使用了krait450架构。在当时看来，这颗soc的所有参数都无可挑剔。为了尽可能挖掘性能，高通甚至给其配备了64bit双通道的豪华内存控制器规格，同时这也是高通首次推出支持4k显示输出的Soc。该Soc被国行三星note4等机型搭载，代表了当时最强的移动Soc性能，除了exynos5433可以与之一较高下外，其他Soc全部被它完全碾压。然而，谁也想不到，这是高通最后一次如此的风光了。

在春季度刚刚发布完32位绝唱805之后，高通总算进入了64位时代。支持64位的Android5.0的发布，给64位soc的性能发挥带来了极大的便利。在410上小尝64位甜头的高通，在秋季度一口气发布了数颗64位soc，这其中就包括了msm8994，也就是传说中的地狱炎龙810。

按照高通的传统，8系应该由自研架构撑起一片天。但是由于恰逢32位64位交接，krait是一个纯32位架构，不可能改改就强行上64位，加上留给高通的时间太过仓促，高通不得不拿公版强行顶上来。

如果说光用公版，那问题不会太大，三星在用，那时候麒麟也出现了麒麟也在用公版，老老实实做，不会出什么事。坏就坏在高通长时间不做公版旗舰了，对公版架构的发热一直缺乏一个理性的认识（高通在低端soc上使用公版，但是因为低端soc发热本身就不大，高通根本没意识到公版可以这么热）。作为旗舰，性能是必须要堆的，为了保证能相比805有足够的性能优势，高通选择了暴力堆到4xA57+4xA53。

然而，A57偏偏是历代公版里发热较为恐怖的，加上高通因为长期不用公版做旗舰，对公版最高频率的设定把握不准，加上801和805的高频大胜利，高通给A57设定了2.0g的高频。A57在频率突破1.4g后就会功耗直线上升，2.0g的高频，注定不会凉快。

如果说高频A57是认识不足，高通还干了更睿智的一件事情：选择了20nm制程。同样是A57+A53的exynos7420，借着14nm的东风，活得倒也不算差，而高通这次用的20nm，进一步推动了地狱炎龙的诞生。

过于老旧的制程，导致即使是低频，810的能效比也完全难以直视。琴梨梨手头有一台shv32，官方锁四个大核，然而四个A53的发热就已经足以令人恐惧。

虽然810的真实性能并不算太弱，尤其gpu甚至性能足够出色，可惜因为功耗翻车，凡是用了810的手机厂商甚至是和高通有关系的厂商，历史都被改写了。小米note顶配空有跑分，没有体验，葬送了小米冲击高端市场的机会。nexus6p成为nexus系列最后一款机型。oppo不得不推迟find系列新产品，这一推迟就是接近四年。夏普也在新机型上放弃了三边全面屏设计。一加不得不通过降频1.8g勉强维持体验。三星无奈只能在全球使用7420。

尽管高通尝试对810进行修正，但是到了v2.1版本，依然还是地狱炎龙，这颗参数豪华而体验崩盘的Soc，最终落得了epic fail的代号，火龙的名号，也在民间被广泛认可了。

在尝试修复810失败后，高通马上全力投入新架构的研发，这个新架构，就是kryo。

高通还是一如既往的发挥了在自研能力上的优势，但是高通此时做了一个非常不理智的决定：要和x86竞争。

高通开始和巨硬密谋win10arm，巨硬很显然对牙膏厂的挤牙膏行为并不满意，于是开始开发win10arm。

不同于移动平台重视整数运算能力，桌面平台对浮点运算能力要求更高。为了适应高浮点的需求，kryo在浮点性能上下了大功夫，直接做到乱序五发射。在810发布整整一年后，搭载四颗kryo自研的msm8996，也就是820问世了。

虽然浮点对于移动端并不是最重要的，给力的浮点性能让kryo的单核性能碾压了一众公版，820更是创下了一次次四核碾压八核的辉煌战绩。因为810实在太热了，使用14nm的820，发布之初广受好评，被广泛认为是高性能低发热的典范。

然而，820并不是一颗完全成功的Soc。四核本身就不适合分丛集，高通却硬生生做成了2+2，由于当时尚未诞生eas调度，hmp在双同架构丛集上经常表现出调度不合理，导致核心经常跑在不必要的高频。而更大的问题是高通给小核心缓存砍了一刀，加上尚不成熟的分支预测，导致小核心经常预测失效爆缓存。

这些问题直到后来推出的821，也就是820官超版，都没有解决（琴梨梨现在主力机就是821），谷歌后来自己看不下去出手写了eas调度，总算一定程度缓解了82x的效率问题。

设计失误还不至于说好牌打烂，更精彩的是，上面提到高通想要进军桌面端对吧，巨硬没有辜负高通的期望，很快就把win10arm搞出来了，并在820上测试成功。我们可以看一下当年的视频https://m.youtube.com/watch?v=A_GlGglbu1U

（油管视频，怎么打开自己想办法）

得益于浮点性能的强大，视频中820已经可以勉强运行PS，而系统应用的流畅度已经足够日用。

如果在此时推出820的win10设备，是完全合适的，因为820的设计考虑了桌面端的运算需求。然而高通没有这么做，白白浪费了这么好的机会，等到后来才推出835的win10设备，可是835的浮点性能根本不足以负担桌面端需求，结果体验还打不过n3450，加上牙膏厂被逼急了一屁股坐在了牙膏上，高通的危机更大了。

此时高通其实完全有对抗危机的方法。高通从600开始就内置了dsp（类似于npu），但是高通对于使用dsp的开发收取高额费用，导致仅有小部分厂家发挥了dsp的优势。如果在此时放开对dsp的限制，高通完全可以比麒麟抢先一步引领ai潮流，但是高通毕竟专利流氓做久了，没有这种意识。

82x错失了进入桌面端市场的良机，又在移动端因为设计失误并没有大红大紫，此时的高通，决定回归公版。但是高通毕竟还是有那么点骨气，不是像810那样迫不得已绝对不在旗舰上直接上公版，于是高通就只能选择魔改公版。

835的设计其实非常保守，不但单核性能相比821主动倒车，而且gpu相比821提升也极其有限，甚至连15%都不到。

但是因为使用了公版，835相比高通一直坚持的第三季度发布整整提前了一个季度发布。由于当代公版效率较高，加上首批试水10nm，835的发热控制异常的优秀，销量大涨。但是此时高通内部完全没有放弃全自研的想法。

与此同时，似乎820运行win10arm给了高通无比的自信，高通甚至想去服务器行业分一杯牙膏厂的羹。

临近17年底，Centriq出现了。使用Falkor自研架构，这个架构和前辈kryo一样使用了乱序五发射，但是计算能力和效率大大提升，在浮点性能爆炸的情况下依然保持了A75水平的能效比。

但是Centriq根本没能分到一点市场。高通的祖辈农企早就在推土机时代就折腾过arm服务器，最后还是放弃了。服务器市场的竞争比高通想的要困难的多。因为服务器传统应用大多使用x86编译，无法运行在arm上，针对arm服务器的应用少之又少。加上在牙膏厂志强屁和农企EPYC的夹击，Centriq成了一个失败的产物，再也没有下一代。负责其架构自研的技术总裁Dileep Bhandarkar也在今年7月离职。

服务器市场算是失败了，可是高通一直没有放弃分牙膏厂羹的想法。上文提到巨硬已经准备好了win10arm，服务器受挫的高通，转向了笔记本市场。

虽然835模拟x86效率损耗较大，但是因为牙膏厂多年以来一直在笔记本上一家独大以至于挤牙膏，按照道理高通本能凭借835出色的能耗比能在细分市场中站住脚，但是进军笔记本界远没高通想的那么顺利。

年初之时，农企发布了船新的ryzen架构，牙膏厂再也不能稳坐在宝座上。

835笔记本还没正式上市，感觉到农企杀气的牙膏厂，带来了史上最良心升级，全面进入四核时代，835的性能在牙膏厂8代低压面前瞬间显得苍白无力。这导致高通甚至只能把长续航作为835笔记本的唯一亮点，因为除了续航，高通实在拿不出什么应敌之策了。

2017年接近尾声，移动端ryzen带着史上最强核显横空出世，给笔记本界带来了巨大变革。因为价格便宜而性能相比牙膏厂的8代低压甚至有略微优势，一时在低端笔记本市场大红大紫。农企的此举，把牙膏厂逼急了，一屁股坐在牙膏上，带来了atom系列的后代-J4005/J5005，这两颗超低压入门U的性能相比前辈atom大有改观，J5005甚至上了真四核。N3450被取代，而在此之前，唯一在部分项目上略输给835的就是N3450（https://www.guru3d.com/news-story/qualcomm-snapdragon-835-vs-celeron-n3450-benchmarks-with-windows-10.html）。高通进军笔记本界的最后一丝希望破灭了。

在835打破高通传统的年货式迭代节奏后，高通的节奏越来越乱。今年第一季度，高通就急匆匆发布了845。太紧凑的时间导致高通没有时间去改良本可以解决的缺陷，845存在较为严重的缓存漏电问题。

如果说缓存漏电还不是大问题，更大的问题就是高通的霸主地位不保了。845的性能提升依然有限，而在大洋对岸某个号称琵琶源自于它的国家，一颗被称为“安卓之光”的Soc诞生了。六发射配上高达4M的独立L3，9810跑出了单核3500分的惊人战绩，而在同频浮点效率测试中，9810跑出了接近845的两倍效率。

在此之前，高通的地位从未被如此剧烈的动摇过，高通从来没有在跑分上遭遇过如此奇耻大辱，要知道，当年那颗epic fail，都没有在跑分上做出丝毫让步。

高通的节奏进一步被打乱了。

按照往常，高通会在一颗Soc发布2-4季度后推出官超版本，比如800和801，820和821，然而这次高通只隔了一个季度不到，845的官超版850就被急着生了出来。被逼急了的高通，一口气把大核心频率艹到了2.96g。然而频率再高，也难逃地位不保。

高通的地位一次次被攻击。三星自主研发基带成功，在CDMA上和高通拜拜了，cat18的上行，甚至把850给干掉了。牙膏厂在基带上持续推进，直接集成了完整的x86核心与高通竞争，并抢到了苹果新iPhone基带的订单。余大嘴的嘴里，传出了7nm和cat21。

845依然是能耗比最优秀的Soc，但是9810已经越追越近。

排除9810效率低下的公版gpu，9810的cpu效率甚至在845之上。

高通当然急，没有不急的理由。俗话说狗急跳墙，被逼急了的高通，w步伐越发混乱，甚至试图威胁牙膏厂，然而牙膏厂才没工夫打理这种小打小闹。

而与此同时，高通还要挣扎着避免被闭源流氓博通收购。

5G时代近在咫尺，各大运营商也在加急推进淘汰2G和3G，而高通的大部分专利都局限在2G和3G。靠卖基带维持生计的日子越来越不好过，技术部门离职的人越来越多...

节奏被打乱的高通，开始大量推出各种阉割版Soc细分市场。按照惯例，今年q4高通应该发布下一代旗舰，然而现在高通的官媒甚至都没有一点对新旗舰的预热宣传，675这种小打小闹倒是出的挺起劲。大洋彼岸的三星已经官宣9820要相比9810再来一次大提升，exynos已经从当初只会用公版的婴儿，长成了一个极具攻击性的成人。

一步步错失良机，一次次翻身失败。虽然835和845确实取得了不错的销量，但是高通手里的优势正在一点点失去。失去了自主技术，就等于把命送到别人手里，而如今的高通，正有这样的趋势。

8150已经成了高通唯一翻身的希望，而这仅剩的希望，还在一点点随着时间流逝。

写于2018/11/22，同步首发于知乎//B站

‘玖’ android 源码 怎么只编译 systemui

Google提供的Android包含了原始Android的目标机代码，主机编译工具、仿真环境，下载的代码包经过解压后(这里是Android2.2的源码包)，源代码的第一层目录结构如下： -- Makefile -- bionic （bionic C库） -- bootable （启动引导相关代码） -- build （存放系统编译规则及generic等基础开发包配置） -- cts （Android兼容性测试套件标准） -- dalvik （dalvik java虚拟机） -- development （应用程序开发相关） -- external （android使用的一些开源的模组） -- frameworks （核心框架——java及C++语言） -- hardware （主要保护硬解适配层HAL代码） -- libcore -- ndk -- device -- out （编译完成后的代码输出与此目录） -- packages （应用程序包） -- prebuilt （x86和arm架构下预编译的一些资源） -- sdk （sdk及模拟器） -- system （文件系统库、应用及组件——C语言） `-- vendor （厂商定制代码） bionic 目录 -- libc （C库） -- arch-arm （ARM架构，包含系统调用汇编实现） -- arch-x86 （x86架构，包含系统调用汇编实现） -- bionic （由C实现的功能，架构无关） -- docs （文档） -- include （头文件） -- inet -- kernel （Linux内核中的一些头文件） -- netbsd （？netbsd系统相关，具体作用不明） -- private （？一些私有的头文件） -- stdio （stdio实现） -- stdlib （stdlib实现） -- string （string函数实现） -- tools （几个工具） -- tzcode （时区相关代码） -- unistd （unistd实现） `-- zoneinfo （时区信息） -- libdl （libdl实现，dl是动态链接，提供访问动态链接库的功能） -- libm （libm数学库的实现，） -- alpha （apaha架构） -- amd64 （amd64架构） -- arm （arm架构） -- bsdsrc （？bsd的源码） -- i386 （i386架构） -- i387 （i387架构？） -- ia64 （ia64架构） -- include （头文件） -- man （数学函数，后缀名为.3，一些为freeBSD的库文件） -- powerpc （powerpc架构） -- sparc64 （sparc64架构） `-- src （源代码） -- libstdc++ （libstdc++ C++实现库） -- include （头文件） `-- src （源码） -- libthread_db （多线程程序的调试器库） `-- include （头文件） `-- linker （动态链接器） `-- arch （支持arm和x86两种架构） bootable 目录 -- bootloader （适合各种bootloader的通用代码） `-- legacy （估计不能直接使用，可以参考） -- arch_armv6 （V6架构，几个简单的汇编文件） -- arch_msm7k （高通7k处理器架构的几个基本驱动） -- include （通用头文件和高通7k架构头文件） -- libboot （启动库，都写得很简单） -- libc （一些常用的c函数） -- nandwrite （nandwirte函数实现） `-- usbloader （usbloader实现） -- diskinstaller （android镜像打包器，x86可生产iso） `-- recovery （系统恢复相关） -- edify （升级脚本使用的edify脚本语言） -- etc （init.rc恢复脚本） -- minui （一个简单的UI） -- minzip （一个简单的压缩工具） -- mttils （mtd工具） -- res （资源） `-- images （一些图片） -- tools （工具） `-- ota （OTA Over The Air Updates升级工具） `-- updater （升级器） build目录 -- core （核心编译规则） -- history （历史记录） -- libs `-- host （主机端库，有android “cp”功能替换） -- target （目标机编译对象） -- board （开发平台） -- emulator （模拟器） -- generic （通用） -- idea6410 （自己添加的） `-- sim （最简单） `-- proct （开发平台对应的编译规则） `-- security （密钥相关） `-- tools （编译中主机使用的工具及脚本） -- acp （Android "acp" Command） -- apicheck （api检查工具） -- applypatch （补丁工具） -- apriori （预链接工具） -- atree （tree工具） -- bin2asm （bin转换为asm工具） -- check_prereq （检查编译时间戳工具） -- dexpreopt （模拟器相关工具，具体功能不明） -- droiddoc （？作用不明，java语言，网上有人说和JDK5有关） -- fs_config （This program takes a list of files and directories） -- fs_get_stats （获取文件系统状态） -- iself （判断是否ELF格式） -- isprelinked （判断是否prelinked） -- kcm （按键相关） -- lsd （List symbol dependencies） -- releasetools （生成镜像的工具及脚本） -- rgb2565 （rgb转换为565） -- signapk （apk签名工具） -- soslim （strip工具） `-- zipalign （zip archive alignment tool） dalvik目录 dalvik虚拟机 . -- dalvikvm （main.c的目录） -- dexmp （dex反汇编） -- dexlist （List all methods in all concrete classes in a DEX file.） -- dexopt （预验证与优化） -- docs （文档） -- dvz （和zygote相关的一个命令） -- dx （dx工具，将多个java转换为dex） -- hit （？java语言写成） -- libcore （核心库） -- libcore-disabled （？禁用的库） -- libdex （dex的库） -- libnativehelper （Support functions for Android's class libraries） -- tests （测试代码） -- tools （工具） `-- vm （虚拟机实现） development 目录 （开发者需要的一些例程及工具） -- apps （一些核心应用程序） -- BluetoothDebug （蓝牙调试程序） -- CustomLocale （自定义区域设置） -- Development （开发） -- Fallback （和语言相关的一个程序） -- FontLab （字库） -- GestureBuilder （手势动作） -- NinePatchLab （？） -- OBJViewer （OBJ查看器） -- SdkSetup （SDK安装器） -- SpareParts （高级设置） -- Term （远程登录） `-- launchperf （？） -- build （编译脚本模板） -- cmds （有个monkey工具） -- data （配置数据） -- docs （文档） -- host （主机端USB驱动等） -- ide （集成开发环境） -- ndk （本地开发套件——c语言开发套件） -- pdk （Plug Development Kit） -- samples （演示程序） -- AliasActivity （） -- ApiDemos （API演示程序） -- BluetoothChat （蓝牙聊天） -- BrowserPlugin （浏览器插件） -- BusinessCard （商业卡） -- Compass （指南针） -- ContactManager （联系人管理器） -- CubeLiveWall** （动态壁纸的一个简单例程） -- FixedGridLayout （像是布局） -- GlobalTime （全球时间） -- HelloActivity （Hello） -- Home （Home） -- JetBoy （jetBoy游戏） -- LunarLander （貌似又是一个游戏） -- MailSync （邮件同步） -- MultiResolution （多分辨率） -- MySampleRss （RSS） -- NotePad （记事本） -- RSSReader （RSS阅读器） -- SearchableDictionary （目录搜索） -- **JNI （JNI例程） -- SkeletonApp （空壳APP） -- Snake （snake程序） -- SoftKeyboard （软键盘） -- Wiktionary （？维基） `-- Wiktionary**（？维基例程） -- scripts （脚本） -- sdk （sdk配置） -- simulator （？模拟器） -- testrunner （？测试用） `-- tools （一些工具）

‘拾’ 让TWRP支持解密高通data分区

现在新出品的手机，基本都加密了data分区，旨在保障用户数据的安全。其中高通方案的手机使用的加密方案是QSEE（高通安全执行环境，Qualcomm Security Executing Environment），每次启动设备时会有一个专门的过程来解密data分区。然而，TWRP Recovery默认并没有附带高通的加密组件，因此在启动时会无法解密和访问data分区，使得体验大打折扣。因此必须把高通的加密组件从Android系统中移植过来。

高通QSEE组件由本体 qseecomd 程序、Keystore及其依赖库组成。

首先是 qseecomd 。 加解密过程全由 qseecomd 完成， 因此移植过程相对比较简单。

Keystore是加解密过程所必需的“钥匙”，为一个 so 格式的库文件，每个高通方案设备有属于自己的Keystore，路径为 /system/vendor/lib64/hw/keystore.<高通方案型号>.so （32位处理器型号请将 lib64 改为 lib ）。

而 qseecomd 运行还需依赖其它库文件，查看依赖可使用 readelf -d qseecomd ：

值得注意的是，上述命令给出的依赖库，除了 libQSEEComAPI.so 与 libdrmfs.so 由高通提供外，其他的均为安卓公用的运行库，TWRP会提供它们。

另外， qseecomd 的运行还离不开解释器 linker ，使用 readelf -l qseecomd ，在输出中可以看到 qseecomd 所使用 linker 的绝对路径。

在上一步中，我们已经知道了加密需要用到哪些文件，那么它们位于安卓系统的哪一个路径？根据下面的表格，整理出它们所在的路径，以及放置到TWRP根文件系统中的路径。

Android设备配置文件（ /device/<厂商名>/<设备名> ）中，如果存在目录 recovery/root ，那么该目录中的内容就会在编译TWRP时，自动复制到TWRP的根文件系统中。因此，请将上一步中的文件，根据上表的路径复制到其中。

系统环境与TWRP的环境还是有所差别的。为了保证 qseecomd 能够正确地找到解释器 linker ，我们还需要使用 patchelf 工具，对 qseecomd 进行一番修改，否则运行时会提示“ qseecomd: not found ”，尽管 qseecomd 确实在指定的目录中。

qseecomd 默认的linker是 /system/bin/linker64 ，而TWRP的linker则是 /sbin/linker64 。因此，我们需要这样修改linker路径：

修改完成后，再使用 readelf -l qseecomd 进行检查，就可以发现修改成功了。

qseecomd 以服务的形式运行，它会在运行之时自动对data分区进行解密。想让 qseecomd 作为服务运行，需要修改 init.recovery.qcom.rc ，这是Android的init配置文件之一。

创建该文件，在其中写入如下内容：

TWRP本身有解密模块，并提供与 qseecomd 对接的接口，但默认没有启用。因此我们需要在 BoardConfig.mk 设置相应的选项：

TARGET_PROVIDES_KEYMASTER 指定设备是否具有用于解密的keymaster，keymaster正是解密必不可少的“钥匙”，高通方案的设备会提供。而 TARGET_KEYMASTER_WAIT_FOR_QSEE 则指定是否等待 qseecomd 解密完成。其中， TARGET_KEYMASTER_WAIT_FOR_QSEE 至关重要，它是 qseecomd 解密支持的重要开关，若不设置它，就和不带加密组件无异。

判断TWRP是否正常解密的依据，就是观察启动后会出现什么画面。如果启动非常快，且显示的是输入密码的窗口，而事实上手机并没有使用密码加密，而是保持默认加密状态，那么说明解密不成功，还需努力调试。如果启动时间延长（定格在splash画面），进入主界面后点击底部的“日志”按钮显示“Data successfully decrypted”，那么则说明解密成功。

并不是所有的设备都能遵照上述步骤成功为TWRP启用加密支持，各种各样的问题都有可能出现。显然，我们可以根据日志，来检查 qseecomd 的工作状态—— qseecomd 会同时往内核日志和logcat中写入日志。使用 dmesg 或 cat /proc/kmsg 来获取内核日志；而在 BoardConfig.mk 中启用logcat支持后，我们亦可以通过运行 logcat 来获取 qseecomd 输出的另一部分日志。

启用logcat支持的开关为：

除此之外，我们还可以从TWRP这一边展开分析。TWRP的解密过程也被记录在TWRP本身的日志中，阅读 /cache/recovery/last_log* 即可了解。

为TWRP加入解密组件，看似比较难，实则并不难，关键在于不断尝试。笔者能获得上面的成果，有赖于在反复失败后仍然能够反复尝试，最终取得成功。在整个过程当中，日志调试的作用举足轻重，它反馈了TWRP与qseecomd组件运行时的一系列状况，是分析故障的利器。