1. linux 内核 镜像 工具 哪些 yocto
linux内核镜像格式
一、Linux内核镜像格式
Linux内核有多种格式的镜像，包括vmlinux、Image、zImage、bzImage、uImage、xipImage、bootpImage等.
(1)kernel镜像格式:vmlinux
vmlinuz是可引导的、可压缩的内核镜像，vm代表Virtual Memory.Linux支持虚拟内存，因此得名vm.它是由用户对内核源码编译得到，实质是elf格式的文件.也就是说，vmlinux是编译出来的最原始的内核文件，未压缩.这种格式的镜像文件多存放在PC机上.
【 attention】elf格式文件
ELF，Executable and Linkable Format，可执行可链接格式，是UNIX实验室作为应用程序二进制接口而发布的，扩展名为elf.可以简单的认为，在elf格式的文件中，除二进制代 码外，还包括该可执行文件的某些信息，比如符号表等.
(2)kernel镜像格式:Image
Image是经过obj处理的只包含二进制数据的内核代码，它已经不是elf格式了，但这种格式的内核镜像还没有经过压缩.
【 attention】obj
GNU使用工具程序obj作用是拷贝一个目标文件的内容到另一个目标文件中，也就是说，可以将一种格式的目标文件转换成另一种格式的目标文件. 通过使用binary作为输出目标(-o binary)，可产生一个原始的二进制文件，实质上是将所有的符号和重定位信息都将被抛弃，只剩下二进制数据.
(3)kernel镜像格式:zImage
zImage是ARM linux常用的一种压缩镜像文件，它是由vmlinux加上解压代码经gzip压缩而成，命令格式是#make zImage.这种格式的Linux镜像文件多存放在NAND上.
(4)kernel镜像格式:bzImage
bz表示big zImage,其格式与zImage类似，但采用了不同的压缩算法，注意，bzImage的压缩率更高.
(5)kernel镜像格式:uImage
uImage是uboot专用的镜像文件，它是在zImage之前加上一个长度为0x40的头信息(tag)，在头信息内说明了该镜像文件的类型、加载 位置、生成时间、大小等信息.换句话说，若直接从uImage的0x40位置开始执行，则zImage和uImage没有任何区别.命令格式是#make uImage.这种格式的Linux镜像文件多存放在NAND上.
(6)kernel镜像格式:xipImage
这种格式的Linux镜像文件多存放在NorFlash上，且运行时不需要拷贝到内存SDRAM中，可以直接在NorFlash中运行.
二、Linux内核镜像的产生过程
在嵌入式Linux中，内核的启动过程分为两个阶段.其中，第一阶段启动代码放在arch/arm/kernel/head.S文件中，该文件与体系 结果相关，与用户的开发板无关，主要是初始化ARM内核等.第二阶段启动代码是init目录下的main.c.现以执行命令#make zImage为例来说明，arm-linux内核镜像的产生过程.
(1)当用户对Linux内核源码进行编译时，kernel的第1/2阶段代码会生成可执行文件vmlinux，该文件是未被压缩的镜像文件，非常大，不能直接下载到NAND中，通常放在PC机上，这也是最原始的Linux镜像文件.试验时该文件约50M.
(2)镜像文件vmlinux由于很大，肯定不能直接烧入NAND中，因此需要进行二进制化，即经过obj处理，使之只包含二进制数据的内核代 码，去除不需要的文件信息等，这样就制作成了image镜像文件.该镜像文件也是未压缩，只是经过了二进制化而变小.试验时该文件约5M.
(3) 一般来说，内存SDRAM中的内核镜像是经过压缩的，只是在运行时再将其解压.所以，编译时会先使用gzip将镜像文件image进行压缩(压缩比约为 2:1),再将压缩后的镜像文件和源码中的两个文件arch/arm/boot/compressed/head.S、arch/arm/boot /compressed/misc.c一起链接生成压缩后的镜像文件compress/vmlinux.试验时该文件约为2.5M.注意，这两个源码文件 是解压程序，用于将内存SDRAM中的压缩镜像zImage进行解压.
(4)压缩后的镜像文件compress/vmlinux经过二进制化，最终生成镜像文件zImage，试验时该文件约为2.5M.当然，在内存 SDRAM中运行压缩镜像文件zImage时，会首先调用两个解压程序arch/arm /boot/compressed/head.S、arch/arm/boot/compressed/misc.c将自身解压，然后再执行kernel 的第一阶段启动代码arch/arm/kernel/head.S.简而言之，在内存中运行内核时，kernel先自身解压，再执行第一阶段启动代码.试 验时运行在内存中的镜像文件约为5M，与image镜像文件大小相同.
(
2. 如何安装yocto
1.Yocto简介：
Yocto 是一个开源社区，它通过提供模版、工具和方法帮助开发者创建基于linux内核的定制系统，支持ARM, PPC, MIPS, x86 (32 & 64 bit)硬件体系架构。
2.Yocto定制准备工作
（1）确保电脑能联网，并且有100G的空闲，电脑配置不低于4核
（2）获取yocto脚本：$git clone git://git.yoctoproject.org/poky
（3）获取硬件相关层：$git clone git://git.yoctoproject.org/meta-intel.git
（4）关于yocto的帮助：http://www.yoctoproject.org/documentation
3.开始搭建环境
（1）$source poky/oe-init-build-env xxx
xxx$cd conf
xxx/conf$ vim bblayers.conf
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "4"
BBFILES ?= ""
BBLAYERS ?= " \
/hda5/hmi/x86/yocto/poky/meta \
/hda5/hmi/x86/yocto/poky/meta-yocto \
/hda5/hmi/x86/yocto/poky/meta-intel \
/hda5/hmi/x86/yocto/poky/meta-intel/meta-crownbay \
（2）修改local.conf
xxx/conf$ vim local.conf
#MACHINE ??= "qemux86"
MACHINE ??= "crownbay"
4.开始编译
注：(官方下载的只是脚本，yocto一边下载一边编译所以很慢而且还受资源下载限制和电脑配置，下载的文件在工作目录中的downloads中，第一次下载后保存好downloads以后就方便了)
（1）配置内核
xxx$ bitbake linux_yocto -c menuconfig
（2）定制微型yocto
xxx$ bitbake core-image-minimal
（3）定制桌面型yocto
xxx$ bitbake coure-image-sato
（4） hob config
xxx$ hob
可以在图形化界面中方便的定制系统。
3. Yocto编译杰发或MTK的linux或android时的几个问题
编译问题1（audiomanager_7.0.bb的do_configure报错）：
错误：CMake Error at Plugins/PluginCommandInterfaceCAPI/cmake/CommonAPI.cmake:352 (message):
| Failed to generate files from FIDL:
手动执行一下：
$ commonapi-generator-linux-x86 -ll verbose -sk Default -d . /data/linux/hz_rs28_bm/sources/神燃build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/audiomanager/7.0-r1/audiomanager-7.0/Plugins/PluginCommandInterfaceCAPI/fidl/CommandInterface.fidl
-bash: /data/linux/hz_rs28_bm/sources/src/build/tools/commonapi_tool/commonapi-generator/commonapi-generator-linux-x86: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
解决（需要安装32位的glibc库和32位java jre环境）：
$ sudo yum install glibc.i686
$ sudo yum install java-1.8.0-openjdk.i686
$ sudo ln -s /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.191.b12-1.el7_6.i386/jre/bin/java /bin/java
$ java -version （保证是32位的java）
编译问题2（perl_5.20.0.bb的do_package报错）：
错误：ERROR: obj failed with exit code 256 (cmd was ‘arm-poky-linux-gnueabi-obj’ –only-keep-debug
… generate_uudmap: File format not recognized
解决（tar在1.29版本之后需要exclude在路径的前面）：
sources/meta/poky/bitbake/lib/bb/fetch2/bzr.py
tar_flags = “–exclude ‘.bzr’ –exclude ‘.bzrtags'”
修改成：
tar_flags = “–exclude=’.bzr’ –exclude=’.bzrtags'”
sources/meta/poky/bitbake/lib/bb/fetch2/cvs.py
tar_flags = “–exclude ‘CVS'”
修改成：
tar_flags = “–exclude=’CVS'”
sources/meta/poky/bitbake/游轮虚lib/bb/fetch2/repo.py
tar_flags = “–exclude ‘.repo’ –exclude ‘.git'”
修改成：
tar_flags = “–exclude=’.repo’ –exclude=’.git'”
sources/meta/poky/bitbake/lib/bb/fetch2/svn.py
tar_flags = “–exclude ‘桐颤.svn'”
修改成：
tar_flags = “–exclude=’.svn'”
sources/meta/poky/meta/recipes-devtools/quilt/quilt-0.63.inc
tar -cf – bin/ –exclude \*.in | ( cd ${D}${PTEST_PATH} && tar -xf – )
tar -cf – compat/ –exclude \*.in | ( cd ${D}${PTEST_PATH} && tar -xf – )
tar -cf – quilt/ –exclude \*.in | ( cd ${D}${PTEST_PATH} && tar -xf – )
tar -cf – test/ –exclude mail.test –exclude delete.test | ( cd ${D}${PTEST_PATH} && tar -xf – )
修改成：
tar -c –exclude=\*.in bin/ | ( cd ${D}${PTEST_PATH} && tar -xf – )
tar -c –exclude=\*.in compat/ | ( cd ${D}${PTEST_PATH} && tar -xf – )
tar -c –exclude=\*.in quilt/ | ( cd ${D}${PTEST_PATH} && tar -xf – )
tar -c –exclude=mail.test –exclude=delete.test test/ | ( cd ${D}${PTEST_PATH} && tar -xf – && chmod 777 test)
sources/meta/poky/meta/recipes-extended/sed/sed-4.2.2/sed-add-ptest.patch
+ cd $(BUILDDIR); tar -cf – $(TESTDIR) –exclude *.o | ( cd $(DESTDIR) && tar -xf – )
修改成：
+ cd $(BUILDDIR); tar -c –exclude=*.o $(TESTDIR) | ( cd $(DESTDIR) && tar -xf – )
sources/meta/poky/meta/recipes-support/attr/acl.inc
tar -cf – test/ –exclude nfs | ( cd ${D}${PTEST_PATH} && tar -xf – )
修改成：
tar -c –exclude=nfs test/ | ( cd ${D}${PTEST_PATH} && tar -xf – )
sources/meta/poky/meta/recipes-support/attr/attr.inc
tar -cf – test/ –exclude ext | ( cd ${D}${PTEST_PATH} && tar -xf – )
修改成：
tar -c –exclude=ext test/ | ( cd ${D}${PTEST_PATH} && tar -xf – )
sources/meta/poky/meta/recipes-devtools/perl/perl-ptest.inc
tar -cf – * –exclude \*.o –exclude libperl.so –exclude Makefile –exclude makefile –exclude hostperl \
–exclude miniperl –exclude generate_uudmap –exclude patches | ( cd ${D}${PTEST_PATH} && tar -xf – )
修改成：
tar -c –exclude=\*.o –exclude=libperl.so –exclude=Makefile –exclude=makefile –exclude=hostperl \
–exclude=miniperl –exclude=generate_uudmap –exclude=patches * | ( cd ${D}${PTEST_PATH} && tar -x )
编译问题3（libunwind_1.1.bb的do_compile报错）：
错误：make[1]: latex2man: Command not found
解决：
$ sudo yum install texlive-tetex
$ sudo rpm -ivh ~/latex2man-1.18-2.noarch.rpm
编译问题3（qt5-app_1.0.bb的do_compile报错）：
错误（有一批类似的错误）：ld: cannot find -lgtest
解决：
$ vi atc_linux/application/btate/btate.pro
equals(MY_BUILD_SYSTEM, atc) {
LIBS += -L $(DA_LIBDIR)/lib -lgtest -lpthread -lbluetoothclient -lglobalbus -lappobj -lapputils
} else {
LIBS += -L$(DA_TOP)/application/lib -L$(DA_TOP)/../../sources/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/atc-binarys/1.0-r0/image/usr/lib -lgtest -lpthread -lbluetoothclient -l
globalbus -lappobj -lapputils
}
$ vi atc_linux/application/gps/gps_bin.pro
equals(MY_BUILD_SYSTEM, atc) {
LIBS += -L $(DA_LIBDIR)/lib -lapputils -lglobalbus -lappobj -lgps
} else {
LIBS += -L$(DA_TOP)/application/lib -L$(DA_TOP)/../../sources/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/gpsd/3.10-r0/gpsd-3.10/ -lapputils -lglobalbus -lappobj -lgps
}
$ vi atc_linux/application/dvr/dvr_bin.pro
equals(MY_BUILD_SYSTEM, atc) {
LIBS += -L${DA_TOP}/lib/lib/ -ldvr -ludev -lsurface_atc -lglobalbus -lappobj -lapputils -lstorage_atc -lgps
} else {
LIBS += -L${DA_TOP}/application/lib -L$(DA_TOP)/../../sources/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/gpsd/3.10-r0/gpsd-3.10/ -ldvr -ludev -lsurface_atc -lglobalbus –
lappobj -lapputils -lstorage_atc -lgps
}
$ vi atc_linux/application/dvr/dvr_bin.pro
INCLUDEPATH += ${DA_TOP}/kernel/kernel-3.18/drivers/ \
../common/ \
../utils/ \
../appobj/include/ \
../globalbus/include/ \
../appcommon/include/ \
../storage_atc/ \
../dvr/gps/ \
../gps/include/ \
../gps/includeex/ \
编译问题4（makall报错）：
报错：./makall: line 169: mkisofs: command not found
解决：$ sudo yum install mkisofs
编译问题5（修改ac83xx_systemd_defconfig再编译时报错）：
报错：Applying patch remove-selinux-android.patch
patching file system/extras/ext4_utils/make_ext4fs.c
Hunk #1 FAILED at 62.
1 out of 1 hunk FAILED — rejects in file system/extras/ext4_utils/make_ext4fs.c
解决：
$ vi sources/meta/meta-atc/recipes-devtools/android-tools/android-tools_5.1.1.r37.bb
在里面做个假的do_patch()，bitbake会优先使用本bb文件的do_patch()函数。
do_patch(){
}
编译问题6（修改ac83xx_systemd_defconfig再编译时报错）：
报错：sources/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/qtbase/5.5.0+gitAUTOINC+c619d2daac-r0/git/src/corelib/tools/qregexp.cpp:3947:1: internal compiler error: in add_stores, at var-tracking.c:6000
解决：
$ cd sources/meta/poky/meta/recipes-devtools/gcc/gcc-4.9/
$ wget http://openlinux.windriver.com/overc/sources/core2_64/gcc-4.9.2-r0.1/0062-gcc-var-tracking.c-backport-from-gcc-trunk-r212178.patch
$ vi sources/meta/poky/meta/recipes-devtools/gcc/gcc-4.9.inc
file://0058-gcc-r212171.patch \
file://0059-gcc-PR-rtl-optimization-63348.patch \
file://target-gcc-includedir.patch \
file://0062-gcc-var-tracking.c-backport-from-gcc-trunk-r212178.patch \
其实就是这个文件：
$ cat 0062-gcc-var-tracking.c-backport-from-gcc-trunk-r212178.patch
From Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20M=C3=BCller-Klieser?= <[email protected]>
Date: Tue, 7 Apr 2015 16:15:11 +0200
Subject: [PATCH] gcc/var-tracking.c: backport from gcc trunk r212178
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
resolves a bug seen on cortexa8 building qt5 libraries.
2014-06-30 Joseph Myers <[email protected]>
* var-tracking.c (add_stores): Return instead of asserting if old
and new values for conditional store are the same.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@212178 138bc75d-0d04-0410-961f-82ee72b054a4
Signed-off-by: Stefan Müller-Klieser <[email protected]>
---
gcc/var-tracking.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/var-tracking.c b/gcc/var-tracking.c
index 65d8285..7c38910 100644
--- a/gcc/var-tracking.c
+++ b/gcc/var-tracking.c
@@ -5997,7 +5997,8 @@ add_stores (rtx loc, const_rtx expr, void *cuip)
{
cselib_val *oval = cselib_lookup (oloc, GET_MODE (oloc), 0, VOIDmode);
- gcc_assert (oval != v);
+ if (oval == v)
+ return;
gcc_assert (REG_P (oloc) || MEM_P (oloc));
if (oval && !cselib_preserved_value_p (oval))
--
1.9.1
编译问题7（修改ac83xx_systemd_defconfig再编译时报错）：
报错：libevdev/1.2.2-r0/libevdev-1.2.2/test/test-main.c:24:19: fatal error: check.h: No such file or directory
解决：
$ vi meta/poky/meta/recipes-support/libevdev/libevdev_1.2.2.bb
LIC_FILES_CHKSUM = “file://COPYING;md5= \
file://libevdev/libevdev.h;endline=21;md5=″
DEPENDS += “libcheck”
SRC_URI = “ http://www.freedesktop.org/software/libevdev/ ${BP}.tar.xz”
编译问题8（修改ac83xx_systemd_defconfig再编译时报错）：
报错：python报错： ‘do_rootfs’, lineno: 17, function
Exception: CalledProcessError: Command ‘[‘’, ‘-ks’, …
解决： 没有实际问题，重新编译一次即可，可能是机器太忙导致超时，或者某个命令执行不成功。
编译问题9（preuboot编译工具问题）：
报错：make: armv7a-mediatek451_001_vfp-linux-gnueabi-gcc: Command not found
解决：
$ vi atc_linux/bootloader/preuboot/Makefile
#CROSS_COMPILE :=armv7a-mediatek451_001_vfp-linux-gnueabi-
CROSS_COMPILE :=arm-poky-linux-gnueabi-
$ vi ../../atc_linux/bootloader/preuboot/driver/mmc/include/linux/list.h
#ifndef NULL
#define NULL 0
#endif
4. Linux嵌入式交叉编译工具链问题 浅谈
交叉编译工具链是一个由编译器、连接器和解释器组成的综合开发环境，交叉编译工具链主要由binutils、gcc和glibc 3个部分组成。有时出于减小libc库大小的考虑，也可以用别的c库来代替glibc，例如uClibc、dietlibc和newlib。交叉编译工具链主要包括针对目标系统的编译器gcc、目标系统的二进制工具binutils、目标系统的标准c库glibc和目标系统的Linux内核头文件。第一个步骤就是确定目标平台。每个目标平台都有一个明确的格式，这些信息用于在构建过程中识别要使用的不同工具的正确版本。因此，当在一个特定目标机下运行GCC时，GCC便在目录路径中查找包含该目标规范的应用程序路径。GNU的目标规范格式为CPU-PLATFORM-OS。例如，建立基于ARM平台的交叉工具链，目标平台名为arm-linux-gnu。
分步编译和安装交叉编译工具链所需要的库和源代码，最终生成交叉编译工具链。
通过Crosstool脚本工具来实现一次编译生成交叉编译工具链。
直接通过网上（ftp.arm.kernel.org.uk）下载已经制作好的交叉编译工具链。
方法1相对比较困难，适合想深入学习构建交叉工具链的读者。如果只是想使用交叉工具链，建议使用方法2或方法3构建交叉工具链。方法3的优点不用多说，当然是简单省事，但与此同时该方法有一定的弊端就是局限性太大，因为毕竟是别人构建好的，也就是固定的没有灵活性，所以构建所用的库以及编译器的版本也许并不适合你要编译的程序，同时也许会在使用时出现许多莫名的错误，建议你慎用此方法。
方法1：分步构建交叉编译工具链
下载所需的源代码包
建立工作目录
建立环境变量
编译、安装Binutils
获取内核头文件
编译gcc的辅助编译器
编译生成glibc库
编译生成完整的gcc
由于在问答中的篇幅，我不能细述具体的步骤，兴趣的同学请自行阅读开源共创协议的《Linux from scratch》，网址是：linuxfromscratch dot org
。
Crosstool是一组脚本工具集，可构建和测试不同版本的gcc和glibc，用于那些支持glibc的体系结构。它也是一个开源项目，下载地址是kegel dot com/crosstool。用Crosstool构建交叉工具链要比上述的分步编译容易得多，并且也方便许多，对于仅仅为了工作需要构建交叉编译工具链的你，建议使用此方法。
运行which makeinfo，如果不能找见该命令，在解压texinfo-4.11.tar.bz2，进入texinfo-4.11目录，执行./configure&&make&&make install完成makeinfo工具的安装
下载所需资源文件linux-2.4.20.tar.gz、binutils-2.19.tar.bz2、gcc-3.3.6.tar.gz、glibc- 2.3.2.tar.gz、glibc-linuxthreads-2.3.2.tar.gz和gdb-6.5.tar.bz2。然后将这些工具包文件放在新建的$HOME/downloads目录下，最后在$HOME/目录下解压crosstool-0.43.tar.gz，命
令如下：
#cd$HOME/
#tar–xvzfcrosstool-0.43.tar.gz
建立脚本文件
接着需要建立自己的编译脚本，起名为arm.sh，为了简化编写arm.sh，寻找一个最接近的脚本文件demo-arm.sh作为模板，然后将该脚本的内容复制到arm.sh，修改arm.sh脚本，具体操作如下：
# cd crosstool-0.43
# cp demo-arm.sh arm.sh
# vi arm.sh
修改后的arm.sh脚本内容如下：
#!/bin/sh
set-ex
TARBALLS_DIR=$HOME/downloads#定义工具链源码所存放位置。
RESULT_TOP=$HOME/arm-bin#定义工具链的安装目录
exportTARBALLS_DIRRESULT_TOP
GCC_LANGUAGES="c,c++"#定义支持C,C++语言
exportGCC_LANGUAGES
#创建/opt/crosstool目录
mkdir-p$RESULT_TOP
#编译工具链，该过程需要数小时完成。
eval'catarm.datgcc-3.3.6-glibc-2.3.2.dat'shall.sh--notest
echoDone.
在arm.sh脚本文件中需要注意arm-xscale.dat和gcc-3.3.6-glibc-2.3.2.dat两个文件，这两个文件是作为Crosstool的编译的配置文件。其中arm.dat文件内容如下，主要用于定义配置文件、定义生成编译工具链的名称以及定义编译选项等。
KERNELCONFIG='pwd'/arm.config#内核的配置
TARGET=arm-linux#编译生成的工具链名称
TARGET_CFLAGS="-O"#编译选项
gcc-3.3.6-glibc-2.3.2.dat文件内容如下，该文件主要定义编译过程中所需要的库以及它定义的版本，如果在编译过程中发现有些库不存在时，Crosstool会自动在相关网站上下载，该工具在这点上相对比较智能，也非常有用。
BINUTILS_DIR=binutils-2.19
GCC_DIR=gcc-3.3.6
GLIBC_DIR=glibc-2.3.2
LINUX_DIR=linux-2.6.10-8(根据实际情况填写)
GDB_DIR=gdb-6.5
执行脚本
将Crosstool的脚本文件和配置文件准备好之后，开始执行arm.sh脚本来编译交叉编译工具。具体执行命令如下：
#cdcrosstool-0.43
#./arm.sh
经过数小时的漫长编译之后，会在/opt/crosstool目录下生成新的交叉编译工具，其中包括以下内容：
arm-linux-addr2linearm-linux-g++arm-linux-ldarm-linux-size
arm-linux-ararm-linux-gccarm-linux-nmarm-linux-strings
arm-linux-asarm-linux-gcc-3.3.6arm-linux-objarm-linux-strip
arm-linux-c++arm-linux-gccbugarm-linux-objmpfix-embedded-paths
arm-linux-c++filtarm-linux-gcovarm-linux-ranlib
arm-linux-cpparm-linux-gprofarm-linux-readelf
然后将生成的编译工具链路径添加到环境变量PATH上去，添加的方法是在系统/etc/ bashrc文件的最后添加下面一行，在bashrc文件中添加环境变量
export PATH=/home/jiabing/gcc-3.3.6-glibc-2.3.2/arm-linux-bin/bin:$PATH
至此，arm-linux下的交叉编译工具链已经完成，现在就可以使用arm-linux-gcc来生成试验箱上的程序了！