我們的分析《Lichee（二） 在sun4i_crane平臺下的編譯?》的時候。竟然沒有一個步驟是在配置內核

make ARCH=arm menuconfig
細致的讀過的代碼的會發現，在build_kernel有這么一段話
?if [ ! -e .config ]; then ? echo -e "\n\t\tUsing default config... ...!\n" ? cp arch/arm/configs/sun4i_crane_defconfig .config ?fi
作用是，當不存在.config時，就將arch/arm/configs/sun4i_crane_defconfig復制到.config。這樣我們就不須要在編譯kernel的時候去運行make menuconfig來配置內核了。

但是我們在實際移植驅動的過程中，往往須要改動.config。

這時就不得不面臨一個問題了。到底什么時候不存在.config文件呢。當然是我們第一次從GIT 克隆下來代碼的時候。

隨之就有一個新的問題，當我們想給我們項目內部的人共享代碼的時候，他編譯的內核并非我們這邊配置好的.config文件，而是arch/arm/configs/sun4i_crane_defconfig，這樣非常有可能導致你和你的伙伴編譯的并非同一套配置產生的kernel。還有另外一個問題，比方我們有2個產品，方案基本同樣，僅僅是幾個外設不同。我們又認為弄多套代碼維護起來過于麻煩。就這樣的需求來說，我們有一種最簡單的解決方式，我們在內核文件夾arch/arm/configs/下，也創建一個新的defconfig文件。依據前面幾篇文章對于目標產品的命名，我們就叫mt7332_defconfig。

我們分析了這么多關于Lichee BSP自己主動化的過程。這些內容所有都是人家的。這次我們檢驗一下我們學習成果。弄一點咱們自己的東西。
就像我們在《Lichee（二） 在sun4i_crane平臺下的編譯?》中的分析。lichee中的build.sh直接指向了buildroot/scripts/common.sh，之前我們一直沒有分析以下的代碼段
while getopts hp:m:k: OPTION do case $OPTION in h) show_help exit 0 ;; p) PLATFORM=$OPTARG ;; m) MODULE=$OPTARG ;;? k) KERN_VER=$OPTARG update_kdir $KERN_VER ;; *) show_help exit 1 ;; esac done 非常明顯這段代碼是在接收腳本的參數。還記不記得我們編譯的命令 ./build.sh -p sun4i_crane -k 3.0 這里我們新加一個參數 -v 意思就是VERNDOR

修改后例如以下： VENDOR="" ..................
while getopts hp:m:k:v: OPTION do case $OPTION in h) show_help exit 0 ;; p) PLATFORM=$OPTARG ;; m) MODULE=$OPTARG ;; v) VENDOR=$OPTARG ;;? k) KERN_VER=$OPTARG update_kdir $KERN_VER ;; *) show_help exit 1 ;; esac done
這里我們的-v傳進來的值僅僅是在lichee文件夾下的build.sh, 經過《Lichee（二） 在sun4i_crane平臺下的編譯》的分析，我們須要將VENDOR的值傳入到lichee/linux-3.0/文件夾下的build.sh 相同地，在linux-3.0文件夾下也要新增-v參數
while getopts hp:m:v: OPTION docase $OPTION inh) show_help;;p) PLATFORM=$OPTARG;;m) MODULE=$OPTARG;;v) VENDOR=$OPTARG;;*) show_help;; esac done

這里我們就要對VENDOR的值進行推斷了(如果我們另一款產品叫mt7xxx)
if [ "$VENDOR" = mt7332 ]; thenmake ARCH=arm mt7332_defconfig elif [ "$VENDOR" = mt7xxx ]; thenmake ARCH=arm mt7xxx_defconfig elseecho "use current .config $VENDOR" fi
當我們-v傳進來的是mt7332的話，我們就用mt7332_defconfig這個配置。假設是mt7xxx的話，就用mt7xxx_defconfig，以此類推。

假設不帶-v參數。就代表用的是當前的.config文件

這段腳本一定要放在實際編譯之前，也就是要放在以下這段代碼之前
if [ -x ./scripts/build_${PLATFORM}.sh ]; then./scripts/build_${PLATFORM}.sh $MODULE elseprintf "\nERROR: Invalid Platform\n"show_helpexit 1 fi

怎樣創建mt7332_defconfig？這個問題事實上也非常easy，當我們在sun4i_crane_defconfig的基礎上進行make menuconfig結束的時候，將產生的.config文件復制到arch/arm/configs/文件夾下 如果。我們的mt7332產品，剛剛換了一款3G模，實比例如以下
# 配置自己的新增的驅動模塊 make ARCH=arm menuconfig? #將配置好的.config文件復制到mt7332_defconfig cp .config arch/arm/configs/mt7332_defconfig # 回到lichee文件夾 cd .. #編譯 ./build.sh -p sun4i_crane -k 3.0 -v mt7332
至此，我們就能夠在同一套內核代碼中。維護多款目標產品了

版權聲明：本文博主原創文章，博客，未經同意不得轉載。

轉載于:https://www.cnblogs.com/zfyouxi/p/4800399.html

總結

以上是生活随笔為你收集整理的Lichee （六） 优化配置的微内核的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。