U-Boot 之四 构建过程（Kconfig 配置 + Kbuild 编译）详解
??在之前的博文 Linux 之八 完整嵌入式 Linux 環境介紹及搭建過程詳解 中我們說了要一步步搭建整個嵌入式 Linux 運行環境，今天繼續介紹 U-Boot 相關的內容。我所使用的硬件平臺及整個要搭建的嵌入式 Linux 環境見博文 Linux 之八 完整嵌入式 Linux 環境介紹及搭建過程詳解，沒有特殊說明都是在以上環境中進行驗證的，就不過多說明了。
??這篇博文我們僅僅關注 U-Boot 構建過程本身，想要吃透 U-Boot，有太多東西需要學習！最開始我想放到一篇文章中，寫著寫著內容越來越多，最終超過了 CSDN 編輯器的限制。。。最終決定把內容拆分成多篇文章。你可能需要：
Kbuild && Kconfig
??Kbuild && Kconfig 隸屬于 Linux Kernel Build System。在宏觀上，Kbuild && Kconfig 可以統稱為 Kbuild，從微觀上來說，Kbuild 指的是編譯的過程，而 Kconfig 指的在編譯之前對內核進行配置的過程（該過程中會編譯一些工具來實現配置過程）。關于詳細的可以查看 Linux Kernel 的官方文檔 The Linux Kernel Documentation 中的 Kernel Build System 章節的介紹。
??Kbuild && Kconfig 這套構建系統一個顯著的特點就是每一級目錄都會有單獨的相關文件，然后會被上一級相同的文件引用。這樣就保證了每一級目錄都是相互獨立的。尤其是對于源碼的維護者來說，這個是至關重要。每個維護者可以只關心他所負責的代碼部分，任何更改只需要變更它自己的 Kbuild && Kconfig 相關文件即可。它本身主要包含以下幾類文件：
-
Makefile： Kbuild && Kconfig 這套構建系統本身屬于 make 功能的擴展，因此，整個工作過程就是一些列 Makefile 文件的調用。其中入口就是根目錄下的 Makefile 文件，Makefile 中會調用各種工具以實現不同的功能。
??注意，為了區分不同的功能，在源碼中對于 Makefile 的命名有時候會加一個后綴。例如，config.mk、Makefile.build、Makefile.clean 等這些都屬于 Makefile 文件。
??Makefile 文件無法在線調試，對于理解一個復雜的 Makefile 很不友好。一般我們可以使用 --debug 參數讓 make 打印詳細的信息來協助理解。或者是在 Makefile 中添加一些打印信息，常用打印方式有兩種： - 使用 $(info, xxxx$(xxx))、$(warning, xxxx$(xxx))、$(error, xxxx$(xxx))，其中，$(xxx) 表示某個變量。這三個命令可以加到 Makefile 的任意地方，注意 $(error, xxxx$(xxx)) 會終止 Make 過程。
- 使用 @echo "xxxx $xx xxxx"，其中，$(xxx) 表示某個變量。這個命令只能用在目標后邊，且前面是個TAB。這個就是標準 Makefile 語法中的一個命令。
- 如果給出了參數，則 make 優先去找匹配的規則（匹配規則：完整匹配 > 通配符半匹配 > 完全通配符匹配）去執行；如果沒有給出參數，make 會自動找到 Makefile 中第一個目標中沒有通配符的規則執行。
- 如果中間遇到 include 其他文件，就會緊接著執行 include 的文件，完成后再繼續執行本文件。
- make 總是從 Makefile 的開頭開始解析，并不是找到匹配目標之后僅執行匹配目標的命令。也就是說，在匹配之前，Make 可能已經解析了很多判斷條件。
- 對于匹配的規則如果有依賴，優先解析依賴。注意，依賴的匹配也符合 1 中所說的規則。
- 命令前面加了 @ 字符，則不顯示命令本身而只顯示它的結果。命令前面加了 - 號，即使這條命令出錯，make 也會繼續執行后續命令。
- 如果 Makefile 中存在多條同名規則，則 make 程序會嘗試將他們合并。但是如果這些同名規則都有命令的話，make 會給出警告，并用后面的命令代替前面的命令。
-
Kconfig 文件： 這個文件就是 Kconfig 系統的菜單項，當我們使用命令：make menuconfig 時，Kconfig 系統讀取該文件，根據該文件的內容生成各級菜單。U-Boot 源碼根目錄下的 Kconfig 就是頂級的配置菜單，其中會在引入其他目錄下的 Kconfig 作為二級菜單，依次類推。
-
.config 文件： 這個文件記錄了我們菜單項中的配置的具體值，我們所有對于構建的配置的存放在這個文件中，我們在，Kconfig 系統菜單中的更改，最終都會改寫該文件。注意：該文件默認是個隱藏文件，可以使用 ls -al 查看。
-
xxxx_defconfig 文件： xxxx_defconfig 文件就為 Kconfig 系統的菜單項提供一個默認值。不過，Kconfig 系統不會直接讀取 xxxx_defconfig 文件，而是需要使用方式是通過 make xxx_deconfig 生成帶默認值的 .config。這樣，在加載 Kconfig 時，就可以同時加載 .config 以提供默認值。
??簡單來說，xxxx_defconfig 就是為了方便支持更多個性化配置，從而可以盡可能少的改動源代碼。 -
Kbuild 文件： 這個是 Kbuild 系統使用的文件，該文件用于定義一些源碼使用的需要根據編譯環境產生的中間文件。
-
config.mk 文件： 用來處理一些編譯過程中的環境變量。Linux Kernel 沒有這個文件，U-Boot 需要使用它。
再順帶說一句 make 的工作的一些機制：
??U-Boot 從 v2014.10 版本開始也引入 Kbuild && Kconfig 這套構建系統，相比于原來應該是復雜了不少。但是對于屬性 Linux Kernel 的人來說確實是一個好消息！今天我們就來學習一下 U-Boot 中這套系統的具體工作流程。
??Kbuild && Kconfig 這套構建系統中定義了很多命令，我們可以使用 make help 來進行查看（就在根目錄的 Makefile 文件中），其中經常用到命令如下圖所示：
構建過程
??在 Kbuild && Kconfig 這套構建系統中，源碼中使用的有些文件是要靠 Kbuild && Kconfig 這套系統來生成的，直接在源碼中是找不到。這就要求我們必須要了解 Kbuild && Kconfig 是如何工作的，更重要的是要知道 Kbuild && Kconfig 會產生哪些源碼使用的文件。
??整個構建過程的這個入口就是源碼根目錄下的 Makefile 文件。下面我們先來整體看一下這個文件的總體結構，并且對其中的規則進行一下說明。其大體可以分為三部分：
整個文件的前半部分就是定義一堆符號，檢測工作環境、處理各種參數，基本沒有實際與編譯源碼相關的命令。下面重點介紹一些（注意，由于我在其中添加了一些打印信息，導致行號與原文件有區別）：
- 給 HOST_ARCH 賦值。HOST_ARCH 代表我們當前指定的 主機 的類型。當我們沒有指定的時候，它就是我們的 PC 架構（例如我的 HOST_ARCH_X86_64），指定 交叉編譯器 后（例如，我們編譯時 CROSS_COMPILE=arm-none-eabi- ARCH=arm make -j4），他就是我們指定的架構（HOST_ARCH_ARM）。
- 處理 make 參數：make V=1、make -s 等。這里導出了 quiet、Q、KBUILD_VERBOSE，用以指示編譯過程的顯示方式。
- 處理編譯的當前目錄以及編譯輸出目錄。其中，我們可以使用環境變量 KBUILD_OUTPUT 或者 指定 make O=xxx 的方式指定輸出目錄。而編譯的源目錄 KBUILD_SRC 根據注釋僅用于在 OBJ 目錄時，而且一般不給使用者使用。代碼可以簡化為以下邏輯：if `KBUILD_SRC` 為空檢查 O=xxx 參數，如果有指定，則賦值給 `KBUILD_OUTPUT`定義偽目標_all ,且 _all 為空目標，避免后面include其余文件的時候尋找隱含的第一個目標。后面肯定還會定義 _all, 而且肯定不為空if `KBUILD_OUTPUT` 不為空`KBUILD_OUTPUT` = 創建并指定的目錄到 `KBUILD_OUTPUT` 繼續執行 make （其中需要過濾掉一些內容，防止無限嵌套）。因為 在 `KBUILD_OUTPUT` 中執行的 Makefile 就是當前這個 Makefileskip-makefile 賦值為 1endif endifif skip-makefile 為空。不空表示上面已經在 `KBUILD_OUTPUT` 中執行過了執行其他各種操作 endif整個makefie 結束 ??這里需要注意的就是，如果指定了輸出目錄，將轉到 輸出目錄中去執行 Makefile，本 Makefile 的執行就結束了。skip-makefile 被賦值為 1，此后只有在 skip-makefile 不為 1 時才會繼續執行。
- 再接下來就是判斷 make C=x 參數以及處理是編譯整個 U-Boot 還是編譯的模塊（由環境變量 SUBDIRS 或 make M=xxx 執行），如果是模塊，賦值給 KBUILD_EXTMOD（賦值厚就不空）。
??前面有說過，開始定義了一個空的目標 _all，這里再次定義目標 _all。這里的 _all 根據 KBUILD_EXTMOD 的值依賴于 all 或者是 modules，但是命令還是為空。這里我們不關心模塊，重點關注 all。all 又依賴 .binman_stmp 和 inputs，如下圖所示：
關于 all 后文會有詳細的介紹。 - 繼續下來就是檢查編譯工具鏈。并做了一些重命名以統一編譯時的顯示。
- 再繼續就是 kconfig 和 kbuild 共用的一些規則 scripts_basic、outputmakefile 的定義。然后檢查要執行的操作是否需要 .config 文件，最終出現以下邏輯：if 是多個目標（mixed-targets=1）一個一個處理 else if 配置（config-targets=1），即我們執行的 make xxxconfig 時的處理config: scripts_basic outputmakefile FORCE$(Q)$(MAKE) $(build)=scripts/kconfig $@%config: scripts_basic outputmakefile FORCE$(Q)$(MAKE) $(build)=scripts/kconfig $@ else 這里就是 編譯過程以及 非 config（例如 clean） 的處理了scripts: scripts_basic scripts_dtc include/config/auto.conf$(Q)$(MAKE) $(build)=$(@)if 需要 .confg 檢查 .confg 文件elseinclude/config/auto.conf: ;endifall 的定義（實際編譯文件等等）非 config（例如 clean、check）等的定義 endifMakefile 結束 也就是在此之前的內容，無論給出啥命令，都會被 make 解析，然后從這里開始分道揚鑣！
??至此，就開始根據給出的目標的不同開始區分具體操作類型了，后續我們單獨章節來介紹！***注意，由于我在 Makefile 中添加了一些打印信息，導致行號與原文件有區別！***下面是我大體整理的一個流程圖：
Kconfig
??在 Kbuild && Kconfig 這套構建系統中，當我們使用 make xxxconfg 類似的命令時，就會執行 Kconfig 流程。例如，當執行 make menuconfig 時會出現一個配置界面，允許開發者通過類似于 UI 的方式來對內核進行配置，之所為我們可以看到這個類似于 UI 的界面，就是因為 Kconfig 從中產生了多個文件和工具來實現的。
Kconfig 語法可以從 https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html 里來學習。
??當我們在 U-Boot 根目錄執行 make menuconfig 或者 make xxx_deconfig 時，make 命令便會讀取 U-Boot 根目錄下的 Makefile 文件，然后解析并匹配 Makefile 文件中的規則 。而 xxxconfig 就會匹配根目錄下 Makefile 文件中的如下圖示的規則（% 可以匹配任意非空字符串，所以 menuconfig、xxx_deconfig 都匹配）：
- Q 是否顯示信息信息，在 Makefile 前面有賦值為 @ 或 空
- MAKE： 就是指的可執行程序 make
- $(build)： 定義在 ./scripts/Kbuild.include 中：181行
那么將以上命令展開之后就是：make -f $(srctree)/scripts/Makefile.build obj=scripts/kconfig menuconfig 或者 $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.build obj=scripts/kconfig xxx_defconfig - $(srctree)： 在 Makefile 前面有賦值為 . 或 $(KBUILD_SRC)
- scripts_basic： 就定義在 U-Boot 根目錄的 Makefile 中
那么將以上命令第一句規則展開之后就是：make -f $(srctree)/scripts/Makefile.build obj=scripts/basic ，第二句規則沒啥可說的，就是移除個文件。 - outputmakefile： 就定義在 U-Boot 根目錄的 Makefile 中，如下所示：
從規則代碼可以看出只有當 KBUILD_SRC 不為空時才有效，而對于 KBUILD_SRC 一般都是空，非空的情況下一般也不使用。因此，這里的依賴 outputmakefile 這里就是空。對于具體見如下說明：
- FORCE 是沒有規則和依賴的，所以每次都會重新生成 FORCE。當 FORCE 作為其他目標的依賴時，由于 FORCE 總是被更新過的，因此依賴所在的規則總是會執行的。
??經過上面的分析，最終由兩條語句 make -f $(srctree)/scripts/Makefile.build obj=scripts/basic 和 make -f $(srctree)/scripts/Makefile.build obj=scripts/kconfig menuconfig 或者 make -f $(srctree)/scripts/Makefile.build obj=scripts/kconfig xxx_defconfig 是我們需要進一步來解析的。接下來就要進入 /scripts/Makefile.build 這個文件了。
Makefile.build
??對于 Makefile.build 文件，目前我們只需要關注下圖所示的兩部分（說明見注釋）：
接下就是進一步處理 scripts/basic/Makefile 或者 scripts/kconfig/Makefile 了。
make xxx_deconfig
??經過上面的分析，當我執行 make xxx_defconfig 時（例如，我這里的 make stm32f769-disco_defconfig），最終會執行以下兩句：make -f $(srctree)/scripts/Makefile.build obj=scripts/basic 和 make -f $(srctree)/scripts/Makefile.build obj=scripts/kconfig xxx_defconfig 。
- make -f $(srctree)/scripts/Makefile.build obj=scripts/basic 展開后是 cc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu11 -o scripts/basic/fixdep scripts/basic/fixdep.c 最終在 scripts/basic/ 目錄下生成了可執行工具 fixdep。
- make -f $(srctree)/scripts/Makefile.build obj=scripts/kconfig xxx_defconfig 展開后是： cc -Wp,-MD,scripts/kconfig/.conf.o.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu11 -c -o scripts/kconfig/conf.o scripts/kconfig/conf.cbison -oscripts/kconfig/zconf.tab.c -t -l scripts/kconfig/zconf.yflex -oscripts/kconfig/zconf.lex.c -L scripts/kconfig/zconf.lcc -Wp,-MD,scripts/kconfig/.zconf.tab.o.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu11 -Iscripts/kconfig -c -o scripts/kconfig/zconf.tab.o scripts/kconfig/zconf.tab.ccc -o scripts/kconfig/conf scripts/kconfig/conf.o scripts/kconfig/zconf.tab.o scripts/kconfig/conf --defconfig=arch/../configs/stm32f769-eval_defconfig Kconfig 最終在 scripts/kconfig/ 目錄下生成了可執行工具 conf，緊接著使用剛生成的 scripts/kconfig/conf 工具根據我們指定的 stm32f769-eval_defconfig 生成 .config 文件。
make menuconfig
??經過上面的分析，當我執行 make menuconfig 時，最終會執行以下兩句：make -f $(srctree)/scripts/Makefile.build obj=scripts/basic 和 make -f $(srctree)/scripts/Makefile.build obj=scripts/kconfig menuconfig 。
- make -f $(srctree)/scripts/Makefile.build obj=scripts/basic 與 make xxx_deconfig 時的語句是一樣的。如果在執行 make menuconfig 之前沒有使用 make xxx_deconfig，那么這句就會和 make xxx_deconfig 時一樣去執行來生成 scripts/basic/fixdep。
- make -f $(srctree)/scripts/Makefile.build obj=scripts/kconfig menuconfig 展開后是：make -f ./scripts/Makefile.build obj=scripts/basic rm -f .tmp_quiet_recordmcount make -f ./scripts/Makefile.build obj=scripts/kconfig menuconfig set -e; mkdir -p scripts/kconfig/; /bin/bash scripts/kconfig/mconf-cfg.sh < scripts/kconfig/mconf-cfg.sh > scripts/kconfig/.mconf-cfg.tmp; if [ -r scripts/kconfig/.mconf-cfg ] && cmp -s scripts/kconfig/.mconf-cfg scripts/kconfig/.mconf-cfg.tmp; then rm -f scripts/kconfig/.mconf-cfg.tmp; else : ' UPD scripts/kconfig/.mconf-cfg'; mv -f scripts/kconfig/.mconf-cfg.tmp scripts/kconfig/.mconf-cfg; ficc -Wp,-MD,scripts/kconfig/.mconf.o.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu11 -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -c -o scripts/kconfig/mconf.o scripts/kconfig/mconf.ccc -Wp,-MD,scripts/kconfig/lxdialog/.checklist.o.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu11 -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -c -o scripts/kconfig/lxdialog/checklist.o scripts/kconfig/lxdialog/checklist.ccc -Wp,-MD,scripts/kconfig/lxdialog/.inputbox.o.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu11 -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -c -o scripts/kconfig/lxdialog/inputbox.o scripts/kconfig/lxdialog/inputbox.ccc -Wp,-MD,scripts/kconfig/lxdialog/.menubox.o.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu11 -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -c -o scripts/kconfig/lxdialog/menubox.o scripts/kconfig/lxdialog/menubox.ccc -Wp,-MD,scripts/kconfig/lxdialog/.textbox.o.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu11 -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -c -o scripts/kconfig/lxdialog/textbox.o scripts/kconfig/lxdialog/textbox.ccc -Wp,-MD,scripts/kconfig/lxdialog/.util.o.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu11 -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -c -o scripts/kconfig/lxdialog/util.o scripts/kconfig/lxdialog/util.ccc -Wp,-MD,scripts/kconfig/lxdialog/.yesno.o.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu11 -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -c -o scripts/kconfig/lxdialog/yesno.o scripts/kconfig/lxdialog/yesno.ccc -o scripts/kconfig/mconf scripts/kconfig/mconf.o scripts/kconfig/zconf.tab.o scripts/kconfig/lxdialog/checklist.o scripts/kconfig/lxdialog/inputbox.o scripts/kconfig/lxdialog/menubox.o scripts/kconfig/lxdialog/textbox.o scripts/kconfig/lxdialog/util.o scripts/kconfig/lxdialog/yesno.o -Wl,-Bsymbolic-functions -lncursesw -ltinfo scripts/kconfig/mconf Kconfig 最終生成 scripts/kconfig/mconf，緊接著使用剛生成的 scripts/kconfig/mconf 工具讀取根目錄的 Kconfig 文件，隨之出現配置界面。
??make xxx_deconfig之后，Kconfig 系統會在 U-Boot 源碼根目錄下生成 .config 文件，當我們使用 make menuconfig 修改了相關配置之后，Kconfig 系統最終也是修改根目錄下的 .config 文件（注意，該文件默認是個隱藏文件，可使用 ls -al 查看），而 .config 文件就記錄了我們當前對于 U-Boot 的配置，后續構建時便會讀取該文件。
Kbuild
??這里說的 Kbuild 是微觀上的 Kbuild，指的是編譯的過程。在經過上面 Kconfig 之后，接下來就是真正的編譯過程，這個過程采用的就是 Kbuild 系統。Linux 官方文檔地址：https://www.kernel.org/doc/html/latest/kbuild/index.html。
??編譯使用的命令是 CROSS_COMPILE=arm-none-eabi- ARCH=arm make -j8，當我們使用該命令之后，make 程序就會讀取 U-Boot 根目錄的 Makefile 文件，然后解析并匹配 Makefile 文件中的規則。由于這里沒有指明目標，Make 會自動找到 makefile 中第一個目標中沒有通配符的規則執行，這里就是 _all。
??注意，這里的 _all 并不是第一個定義的 _all。第一個定義的 _all 是個空命令目標，空命令行可以防止 make 在執行時試圖為重建這個目標去查找隱含命令（包括了使用隱含規則中的命令和“ .DEFAULT”指定的命令）。后面重新定義的 _all 才是最終生效的 _all
??如果 KBUILD_EXTMOD 為空的話 _all 依賴于 all。我們不編譯模塊（沒有指定 KBUILD_EXTMOD），所以 KBUILD_EXTMOD 就是空 ，_all 依賴于 all 的。 all 又依賴 .binman_stmp 和 inputs，如下圖所示：
注意，如果使用的命令是 CROSS_COMPILE=arm-none-eabi- ARCH=arm make all -j8，則直接就會匹配到 all 這條規則，就不會有 _all 啥事了！
??.binman_stamp這個比較簡單，就是通過使用 touch 命令更新 .binman_stamp 文件（不存在時會新建）的時間戳保證 binman 總是會被執行。然后檢查一些定義，給出提示。
??重點就在 inputs，而 inputs 又是依賴于 $(INPUTS-y)。通過將 $(INPUTS-y) 展開后就是 checkarmreloc u-boot.srec u-boot.bin u-boot.sym System.map binary_size_check spl/u-boot-spl.bin u-boot.img u-boot.dtb u-boot-dtb.img 再進一步就是展開及處理各個依賴項了，下面我們重點來介紹一下 checkarmreloc 和 u-boot.srec，其他的大家自行解析。
-
checkarmreloc
將 u-boot 的各項依賴展開就是：u-boot: arch/arm/cpu/armv7m/start.o arch/arm/cpu/built-in.o arch/arm/cpu/armv7m/built-in.o arch/arm/lib/built-in.o arch/arm/mach-stm32/built-in.o board/st/common/built-in.o board/st/stm32f769-eval/built-in.o cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/dma/built-in.o drivers/gpio/built-in.o drivers/net/built-in.o drivers/net/phy/built-in.o drivers/power/built-in.o drivers/power/battery/built-in.o drivers/power/domain/built-in.o drivers/power/fuel_gauge/built-in.o drivers/power/mfd/built-in.o drivers/power/pmic/built-in.o drivers/power/regulator/built-in.o drivers/serial/built-in.o drivers/spi/built-in.o drivers/usb/cdns3/built-in.o drivers/usb/common/built-in.o drivers/usb/dwc3/built-in.o drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o drivers/usb/host/built-in.o drivers/usb/mtu3/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o env/built-in.o fs/built-in.o lib/built-in.o net/built-in.o u-boot.lds FORCE，其中：- $(u-boot-init)：arch/arm/cpu/armv7m/start.o
- $(u-boot-main)：后面一大串 built-in.o
- $(u-boot-keep-syms-lto)：空，不包含任何內容
因此，我們需要重點來關注 u-boot.lds 這個依賴：
其中，$(LDSCRIPT) 就是我們使用的鏈接腳本文件，這里就是 ./arch/arm/cpu/u-boot.lds。而 prepare 的內容就比價多了，如下圖所示：
中間各種依賴，最終會到 include/config/%.conf: 這條規則。 -
u-boot.srec 這個比較簡單，至于它依賴的 u-boot 在上面已經說了。
其實到這里基本就可以了，解析來就不繼續深入了！下面來一張圖：
clean、mrproper、distclean
??介紹了以上的工作過程之后，我們再介紹一下三個與清理相關的命令：clean、mrproper、distclean。至于支持的其他命令基本都差不多，大家感興趣可以自己分析即可。這三個命令的清理程度是逐漸增加，后者包含前者，如下圖所示：
我們就以 distclean 為例來說明。當我們執行 make distclean 這條命令時，make 讀取根目錄的 Makefile，然后開始解析，最終匹配到規則 distclean: mrproper，如下所示：
-
命令部分：第一個 find 命令查找上面指定的文件并刪除。其中的 “|” 表示管道，即左邊的輸出作為右邊的輸入。rm 命令刪除 boards.cfg 和 CHANGELOG。
關于 find 命令：https://www.cnblogs.com/shenqidu/p/10615593.html
關于 xargs 命令：https://www.runoob.com/linux/linux-comm-xargs.html -
依賴 mrproper：接下來重點看他的依賴 mrproper，由于 mrproper 也有依賴，我把它們整理到一個圖中，如下所示：
從中可以看出，mrproper 先執行了 clean，然后執行 $(mrproper-dirs)。綜合來看，clean和 mrproper 結構基本一致，我們將里面各變量展開，其中： -
先看 clean：
- 依賴 rm-dirs：展開后就是 .tmp_versions、spl/*
- 依賴 rm-files：展開后就是include/bmp_logo.h include/bmp_logo_data.h tools/version.h boot* u-boot* MLO* SPL System.map fit-dtb.blob* u-boot-ivt.img.log u-boot-dtb.imx.log SPL.log u-boot.imx.log lpc32xx-* bl31.c bl31.elf bl31_*.bin image.map tispl.bin* idbloader.img flash.bin flash.log defconfig keep-syms-lto.c
- 依賴 $(clean-dirs)：
- $(clean)：定義在 Kbuild.include 文件中： clean := -f $(srctree)/scripts/Makefile.clean obj
- cmd：定義在 Kbuild.include 文件中： cmd = @$(echo-cmd) $(cmd_$(1))，進一步 $(echo-cmd)就在之上：echo-cmd = $(if $($(quiet)cmd_$(1)),echo ' $(call escsq,$($(quiet)cmd_$(1)))$(echo-why)';)
- 命令部分：
- $(call cmd,rmdirs)：
- $(call cmd,rmfiles)：
- find xxx | xargs rm -f：在以上清理的基礎上再清理一些符號文件，臨時文件、腳本文件等
-
mrproper：
- 依賴 rm-dirs：include/config、include/generated spl
- 依賴 rm-files：.config、.config.old、include/autoconf.mk、include/autoconf.mk.dep、include/config.h
- 依賴 clean：就是上面的 clean
- 依賴 $(mrproper-dirs)：
- 命令部分：
- $(clean)：同上
- cmd：同上
參考
總結
以上是生活随笔為你收集整理的U-Boot 之四 构建过程（Kconfig 配置 + Kbuild 编译）详解的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Linux 之十二 Makefile 从
- 下一篇： U-Boot 之五 详解 U-Boot