高通編譯環境

『壹』 如何編譯高通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組件運行時的一系列狀況，是分析故障的利器。