首页 > 代码库 > Lichee(二) 在sun4i_crane平台下的编译
Lichee(二) 在sun4i_crane平台下的编译
让我们先来回顾一下编译命令
$ cd workdir/lichee
$ ./build.sh -p sun4i_crane -k 3.0
lichee目录下的build.sh
#!/bin/bash set -e buildroot/scripts/common.sh $@
build.sh的内容就是这么简单,有效内容就2行,先看第一行 set -e
set命令的-e参数,linux自带的说明如下:
"Exit immediately if a simple command exits with a non-zero status."
也就是说,在"set -e"之后出现的代码,一旦出现了返回值非零,整个脚本就会立即退出。
也就是说,在"set -e"之后出现的代码,一旦出现了返回值非零,整个脚本就会立即退出。
1. 执行buildroot目录下的build.sh
在buildroot/scripts/common.sh中,由于我们没有带MODULE参数,就表示并不是只编译单个模块,而是buildroot linux3.0 u-boot这3个会被一次性都编译
buildroot/scripts/common.sh中的编译buildroot的关键内容如下:
BR_DIR = buildroot PLATFORM = sun4i_crane cd ${BR_DIR} && ./build.sh -p ${PLATFORM}
buildroot/build.sh的核心内容是
if [ -x ./scripts/build_${PLATFORM}.sh ]; then ./scripts/build_${PLATFORM}.sh $MODULE else …… fi
实际上就是执行
./buildroot/scripts/build_sun4i_crane.sh
有效代码如下
export PATH=${CUR_DIR}/output/external-toolchain/bin:$PATH if [ ! -e output/external-toolchain ];then cd output tar -jxf ../dl/arm-2010.09-50-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 mv arm-2010.09 external-toolchain fi
到这里就很明显了,buildroot的前期工作就是根据 ${PLATFORM}的值来使用交叉编译工具链 而arm-2010.09-50-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 就是Android的交叉编译工具链
至此在SUN4I平台下的Android版本的builtroot的工作就完成了
2. 编译内核
buildroot/scripts/common.sh中的编译linux-3.0的关键内容如下:
export PATH=${BR_OUT_DIR}/external-toolchain/bin:$PATH cd ${KERN_DIR} && ./build.sh -p ${PLATFORM} -v ${VENDOR}
接下来就是将buildroot解压好的Android toolchain设置到PATH中,紧接着就是执行linux3.0中的build.sh脚本了
./.linux-3.0/build.sh
......... if [ -x ./scripts/build_${PLATFORM}.sh ]; then ./scripts/build_${PLATFORM}.sh $MODULE else printf "\nERROR: Invalid Platform\n" show_help exit 1 fi .........
同样地,linux-3.0/build.sh的重点也是执行linux/script/build_sun4i_crane.sh,我们找到了这个脚本文件
./linux/script/build_sun4i_crane.sh
经过简单分析,我们发现,编译内核最重要的2个shell函数就是build_kernel() build_modules(),通过我们对《Lichee(一)--—— lichee目录结构介绍和编译命令》一文的分析,内核编译主要是对标准内核 已经 提供给制造商的module模块来一直编译
小贴士:
这里来谈谈modules模块的意义,把SUN4I平台非常常见的驱动或者自己比较独特的驱动列入单独的modules下面来,可以大大降低耦合性,甚至不用修改原有内核的配置或代码,就可以完成一款新产品的移植
由于比较关键,接下来通篇分析build_kernel()这个函数
由于比较关键,接下来通篇分析build_kernel()这个函数
build_kernel() { #如果没有配置过kernel 就执行cp arch/arm/configs/sun4i_crane_defconfig .config,就使用预设的配置 if [ ! -e .config ]; then echo -e "\n\t\tUsing default config... ...!\n" cp arch/arm/configs/sun4i_crane_defconfig .config fi #编译standby模块 build_standby #指定buildroot的工具链来make uImage make ARCH=${ARCH} CROSS_COMPILE=${CROSS_COMPILE} -j8 uImage modules update_kern_ver if [ -d output ]; then rm -rf output fi mkdir -p $LICHEE_MOD_DIR #通过 buildroot/output/external-toolchain/bin/arm-none-linux-gnueabi-objcopy 命令生成 bImage文件 ${OBJCOPY} -R .note.gnu.build-id -S -O binary vmlinux output/bImage cp -vf arch/arm/boot/[zu]Image output/ cp .config output/ #拷贝关键目录下的模块文件*.ko 到 ${LICHEE_MOD_DIR} lichee/modules目录 for file in $(find drivers sound crypto block fs security net -name "*.ko"); do cp $file ${LICHEE_MOD_DIR} done cp -f Module.symvers ${LICHEE_MOD_DIR} #cp -f modules.* ${LICHEE_MOD_DIR} #copy bcm4330 firmware and nvram.txt cp drivers/net/wireless/bcm4330/firmware/bcm4330.bin ${LICHEE_MOD_DIR} cp drivers/net/wireless/bcm4330/firmware/bcm4330.hcd ${LICHEE_MOD_DIR} cp drivers/net/wireless/bcm4330/firmware/nvram.txt ${LICHEE_MOD_DIR}/bcm4330_nvram.txt cp drivers/net/wireless/bcm4330/firmware/mw269v3_fw.bin ${LICHEE_MOD_DIR} cp drivers/net/wireless/bcm4330/firmware/mw269v3_nvram.txt ${LICHEE_MOD_DIR} cp drivers/net/wireless/rtxx7x/RT2870STA.dat ${LICHEE_MOD_DIR} cp drivers/net/wireless/rtxx7x/RT2870STACard.dat ${LICHEE_MOD_DIR} }
而build_modules()函数就是将modules目录下的各个模块,如果是源码就通过make -C的方式编译并拷贝,如果是.ko文件就直接拷贝
3. 编译uboot
buildroot/scripts/common.sh中的编译u-boot的关键内容如下:
echo "build uboot for ${PLATFORM}" cd ${U_BOOT_DIR} && ./build.sh -p sun4i -v ${VENDOR}
相对于kernel而言,uboot目录下的build.sh就简单多了
if [ "$PLATFORM" = "sun4i_crane" ]; then
make distclean && make -j4 sun4i CROSS_COMPILE=arm-none-linux-gnueabi- else make distclean && make -j4 $PLATFORM CROSS_COMPILE=arm-none-linux-gnueabi- fi
仅仅是简单的clean后,再重新编译罢了
至此看起来复杂的lichee,通过一条主脉络走下来,我们就非常清晰了,我们也大致了解了lichee这个项目的主要构成,作为一个合格的BSP工程师,实现编译打包的自动化是一个起码要求,这也可以给我们今后的编译打包设计提供一个参考。
声明:以上内容来自用户投稿及互联网公开渠道收集整理发布,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任,若内容有误或涉及侵权可进行投诉: 投诉/举报 工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。