Lichee (六) 优化配置的微内核

我们的分析《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
do
case $OPTION in
h) show_help
;;
p) PLATFORM=$OPTARG
;;
m) MODULE=$OPTARG
;;
v) VENDOR=$OPTARG
;;
*) show_help
;;
esac
done

这里我们就要对VENDOR的值进行推断了(如果我们另一款产品叫mt7xxx)

if [ "$VENDOR" = mt7332 ]; then
make ARCH=arm mt7332_defconfig
elif [ "$VENDOR" = mt7xxx ]; then
make ARCH=arm mt7xxx_defconfig
else
echo "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
else
printf "\nERROR: Invalid Platform\n"
show_help
exit 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

至此,我们就能够在同一套内核代码中。维护多款目标产品了


版权声明:本文博主原创文章,博客,未经同意不得转载。

上一篇:[LeetCode] 149. Max Points on a Line 共线点个数


下一篇:windows 创建和调用 动态库,静态库