首页 > 代码库 > Lichee (六) 配置内核时的一点小优化
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?这个问题其实也很简单,当我们在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
至此,我们就可以在同一套内核代码中,维护多款目标产品了
声明:以上内容来自用户投稿及互联网公开渠道收集整理发布,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任,若内容有误或涉及侵权可进行投诉: 投诉/举报 工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。