【任务3】Linux kernel的配置、编译、加载与启动
本文是原「蜗窝讨论区」的历史存档（2016-08-05），来自版块「X Project」，共 16 帖。讨论区已停止服务，此处仅供查阅。
任务说明 通过“【任务2】启动到u-boot command line”，已经成功初始化了板子的DRAM，并将u-boot加载到DRAM中运行至命令行。基于此，我们可以展开第三个任务：加载并启动Linux kernel（可以以点亮一个LED 灯作为任务的验收标准）。完成该任务的基本步骤包括：
配置并编译一个最简单的Linux kernel，使其可以在具体的板子上执行。编译成功后，将生成uImage和对应的dtb文件。[/*]
为了便于验证，可以在linux kernel运行的第一时间，点亮一个LED灯，以标识任务的完成[/*]
根据板子的实际情况，通过dfu，将uImage和dtb文件，分别下载到DRAM的指定位置[/*]
根据板子的实际情况，使用指定的参数，通过u-boot的bootm命令，执行linux kernel[/*]
涉及的知识点 该任务主要涉及如下知识点：
Linux kernel的启动流程（和具体的平台有关，我们会先以ARM64为例）[/*]
Linux kernel的配置（只需要掌握并理解最基本的即可）[/*]
Linux kernel最简单的移植（包括物理地址、虚拟地址等概念，device tree移植等）[/*]
Linux kernel的编译，以及uImage的生成[/*]
u-boot中boot linux kernel的要求、流程以及操作步骤[/*]
完成任务的思路 该任务可以拆分为几个独立的部分：
Linux kernel启动流程中和平台相关部分的分析，针对不同的平台，可以写一系列的文章。我们已经完成了ARM64的分析，具体可参考博客中“ARM64的启动过程”系列文章[/*]
linux kernel的配置解析，这是观察linux kernel的另外一个视角。可以以具体的平台为单位，写一系列的分析文章[/*]
linux kernel平台相关部分的移植说明，根据实际的硬件情况，写一篇文章即可[/*]
linux kernel device tree的移植说明，结合博客上device tree的分析文章，从实践的角度，加深对device的理解[/*]
u-boot boot linux kernel的流程及步骤说明[/*]
另外，由于该任务涉及到u-boot和linux kernel的权利交接，任何一方出现问题，任务都无法完成。因此，遇到问题时的debug思路和手段，显得尤为重要，到时我们会尽量详细的记录和总结。
最后，还是老话，感兴趣的同学可以认领任务 4. 任务总结 到目前为止（2016/09/10），该任务在bubblegum 96boards上基本完成，共有如下的文档产出：
(/u-boot/fit_image_overview.html)[/*]
可以通过如下步骤在板子上验证： 1）代码下载（具体可参考“X-003-UBOOT-基于Bubblegum-96平台的u-boot移植说明”）
[== Undefined ==]
mkidr -p ~/work/xprj
cd ~/work/xprj
git clone https://github.com/wowotechX/build
git clone https://github.com/wowotechX/u-boot
git clone https://github.com/wowotechX/tools
git clone https://github.com/wowotechX/linux
git clone https://github.com/wowotechX/doc #包含有说明文档
2）代码编译
[== Undefined ==]
cd build
make env_prepare #下载交叉编译工具，只需要执行一次，之前任务有下载过的，请忽略该步骤
make libusb #只需要执行一次
make dfu #只需要执行一次
make uboot kernel uImage
3）按住Bubblegum-96的ADFU键，使板子进入DFU模式
4）按住Bubblegum-96的ADFU键不松开，将splboot.bin（就是我们的SPL image）下载到SRAM并执行
[== Undefined ==]
sudo ../tools/dfu/dfu bubblegum 0xe406b200 ../tools/actions/splboot.bin 1
5）执行完毕后，会重新进入DFU模式，进入后，可以松开ADFU按键。
6）将包含Kernel Image和dtb文件的FIT uImage下载DDR中（不执行）
[== Undefined ==]
sudo ../tools/dfu/dfu bubblegum 0x6400000 ./out/xprj_uImage.itb 0
7）将u-boot下载到DDR并执行
[== Undefined ==]
sudo ../tools/dfu/dfu bubblegum 0x11000000 out/u-boot/u-boot-dtb.bin 1
8）使用串口连接开发板，进入命令行后，以FIT uImage在memory中的位置为参数，执行bootm命令
[== Undefined ==]
bootm 0x6400000
即可成功启动linux kernel。
注：github上的kernel仓库，没有点亮LED的代码，如果需要确定kernel是否启动成功，请按照X-010-UBOOT-使用booti命令启动kernel(Bubblegum-96平台)中的相关说明，修改kernel的source code。
:D 目前tiny210的uboot根据你写的文章的指导已经跑到command line了。已经把《移植进度》更新了。 虽然整个uboot很糙，没实现什么功能，但觉得还是先把kernel跑起来才是大事，哈哈。
“linux kernel启动流程中和平台相关部分的分析，针对不同的平台，可以写一系列的文章。” 这个任务刚好s5pv210是armv7的，我就写个ARM的，不过因为本身不是很熟悉，需要多查资料多理解多看代码，所以时间可能会比较久。
在这里谢谢wowo前面的指导啦~后面还会多多麻烦你的~
ooonebook 写道： 目前tiny210的uboot根据你写的文章的指导已经跑到command line了。已经把《移植进度》更新了。 虽然整个uboot很糙，没实现什么功能，但觉得还是先把kernel跑起来才是大事，哈哈。
“linux kernel启动流程中和平台相关部分的分析，针对不同的平台，可以写一系列的文章。” 这个任务刚好s5pv210是armv7的，我就写个ARM的，不过因为本身不是很熟悉，需要多查资料多理解多看代码，所以时间可能会比较久。
在这里谢谢wowo前面的指导啦~后面还会多多麻烦你的~
不用客气啦，大家一起来做，慢慢就熟悉了（其实我也是边看代码、资料变整理~~）
hi,wowo,目前我这边kernel已经在tiny210上可以跑起来了（虽然开机过程中会crash），但是rootfs不知道怎么规划，要放在哪个目录下？ 另外生成uImage的参数会根据板子有所不同，make uImage这个命令的话要放在Makefile的kernel命令里面吗？
ooonebook 写道： hi,wowo,目前我这边kernel已经在tiny210上可以跑起来了（虽然开机过程中会crash），但是rootfs不知道怎么规划，要放在哪个目录下？ 另外生成uImage的参数会根据板子有所不同，make uImage这个命令的话要放在Makefile的kernel命令里面吗？
你这边动作真快阿，我还在整理文档。 arm架构的kernel Makefile里面有make uImgae这个命令，但arm64就没有了。 因此我们应该把生成uImgae的动作，独立出来，输入是kernel的image，输出是uImage。 后续我们尽量使用FIT image（u-boot的一些信特性）。
对于rootfs，你可以现考虑用ramdisk，u-boot已经支持，而且不依赖外部存储器的驱动。可以放在tools目录下，所有的板子用相同的。
wowo 写道：
ooonebook 写道： hi,wowo,目前我这边kernel已经在tiny210上可以跑起来了（虽然开机过程中会crash），但是rootfs不知道怎么规划，要放在哪个目录下？ 另外生成uImage的参数会根据板子有所不同，make uImage这个命令的话要放在Makefile的kernel命令里面吗？
你这边动作真快阿，我还在整理文档。 arm架构的kernel Makefile里面有make uImgae这个命令，但arm64就没有了。 因此我们应该把生成uImgae的动作，独立出来，输入是kernel的image，输出是uImage。 后续我们尽量使用FIT image（u-boot的一些信特性）。
对于rootfs，你可以现考虑用ramdisk，u-boot已经支持，而且不依赖外部存储器的驱动。可以放在tools目录下，所有的板子用相同的。
这个版本的kernel对s5pv210的cpu支持比较好，复制个defconfig、做个uImage、规划一下地址，bootm命令后就直接可以起来了哈哈。 我有看到代码中有FIT支持的部分，好像uImage的方式是可以被FIT image代替，但是我实在不明白这个FIT到底是怎么工作的，网上资料也少得可怜，所以直接看代码也有点晕乎乎的。希望wowo后面能出一篇FIT的文章。 在此之前，只能先用老的uImage的东西来用了。
嗯嗯，是打算用ramdisk，之前被initrd和initramfs给绕晕了。 但是roofs里面的一些东西是编译busybox编出来的，不同平台用不同编译器出生成出来的应该不一样。要放在/tools/samsung目录下面吗？
ooonebook 写道：
wowo 写道：
ooonebook 写道： hi,wowo,目前我这边kernel已经在tiny210上可以跑起来了（虽然开机过程中会crash），但是rootfs不知道怎么规划，要放在哪个目录下？ 另外生成uImage的参数会根据板子有所不同，make uImage这个命令的话要放在Makefile的kernel命令里面吗？
你这边动作真快阿，我还在整理文档。 arm架构的kernel Makefile里面有make uImgae这个命令，但arm64就没有了。 因此我们应该把生成uImgae的动作，独立出来，输入是kernel的image，输出是uImage。 后续我们尽量使用FIT image（u-boot的一些信特性）。
对于rootfs，你可以现考虑用ramdisk，u-boot已经支持，而且不依赖外部存储器的驱动。可以放在tools目录下，所有的板子用相同的。
这个版本的kernel对s5pv210的cpu支持比较好，复制个defconfig、做个uImage、规划一下地址，bootm命令后就直接可以起来了哈哈。 我有看到代码中有FIT支持的部分，好像uImage的方式是可以被FIT image代替，但是我实在不明白这个FIT到底是怎么工作的，网上资料也少得可怜，所以直接看代码也有点晕乎乎的。希望wowo后面能出一篇FIT的文章。 在此之前，只能先用老的uImage的东西来用了。
嗯嗯，是打算用ramdisk，之前被initrd和initramfs给绕晕了。 但是roofs里面的一些东西是编译busybox编出来的，不同平台用不同编译器出生成出来的应该不一样。要放在/tools/samsung目录下面吗？
我觉得我们可以用类似make libusb的方式，生成特定编译器、特定平台的initrd，但是源头应该是一样的。 另外，如果可以的话，可以帮忙写一篇ramdisk有关的文章，给大家普及一下。先谢谢了
好,等后续把ramdisk的做rootfs的任务完成之后尝试学wowo写一篇，刚好把ramdisk学习得更明白些~
ooonebook 写道： 好,等后续把ramdisk的做rootfs的任务完成之后尝试学wowo写一篇，刚好把ramdisk学习得更明白些~
:cool:
hi,wowo,我把编译uImage的命令加上去了，在build的tiny210分支上，你有空的话帮忙看下可行不?谢谢~
ooonebook 写道： hi,wowo,我把编译uImage的命令加上去了，在build的tiny210分支上，你有空的话帮忙看下可行不?谢谢~
看到了，关于uImage，我的思路是这样的，不知道你觉得如何： 1. 我们的编译脚本（现在的Makefile），只负责单纯的Linux kernel、u-boot等代码级的东西。因此，执行make kernel之后，只生成标准的kernel image，例如：arm的zImage、arm64的Image。 2. 然后，我们可能会要为不同的bootloader，制作该bootloader喜欢的、特殊格式的image，这个image包含了kernel image，但不限于此，例如：
** 写道：**
可以包含一个或者多个dtb文件; 可以包含一个或者多个kernel image文件; 可以包含ramdisk、rootfs等等。
因此，我倾向于把这个制作的过程，独立出来，例如可以抽象为make image，具体image的类型以及所需的参数，可以在config.mk中指定。另外，如果制作image的过程比较复杂，可以写一个脚本，然后在make image中调用。 3. 按照这个思路，以tiny210分支的改动为例，所需的改动应该是： 3-1) 在config.mk中增加相应的内容，例如：
[== Undefined ==]
BOARD_IMAGE_TYPE=uImage
UIMAGE_LOADADDR=...
UIMAGE_ENTRYADDR=...
...
3-2) 在Makefile中，增加make image的编译项目，根据config.mk中的配置想，生成所需的image。
wowo 写道：
ooonebook 写道： hi,wowo,我把编译uImage的命令加上去了，在build的tiny210分支上，你有空的话帮忙看下可行不?谢谢~
看到了，关于uImage，我的思路是这样的，不知道你觉得如何： 1. 我们的编译脚本（现在的Makefile），只负责单纯的Linux kernel、u-boot等代码级的东西。因此，执行make kernel之后，只生成标准的kernel image，例如：arm的zImage、arm64的Image。 2. 然后，我们可能会要为不同的bootloader，制作该bootloader喜欢的、特殊格式的image，这个image包含了kernel image，但不限于此，例如：
** 写道：**
可以包含一个或者多个dtb文件; 可以包含一个或者多个kernel image文件; 可以包含ramdisk、rootfs等等。
因此，我倾向于把这个制作的过程，独立出来，例如可以抽象为make image，具体image的类型以及所需的参数，可以在config.mk中指定。另外，如果制作image的过程比较复杂，可以写一个脚本，然后在make image中调用。 3. 按照这个思路，以tiny210分支的改动为例，所需的改动应该是： 3-1) 在config.mk中增加相应的内容，例如：
[== Undefined ==]
BOARD_IMAGE_TYPE=uImage
UIMAGE_LOADADDR=...
UIMAGE_ENTRYADDR=...
...
3-2) 在Makefile中，增加make image的编译项目，根据config.mk中的配置想，生成所需的image。
OK,明白了，谢谢wowo，我这边先自己改着。等你在主分支上实现了大体的框架之后我再merge进来。
hi,wowo,参照你的意见，我把编译busybox和生成rootfs镜像的命令加上去了，在build的tiny210分支上， 其中生成rootfs镜像的方法感觉和编译uImage的方法应该差不多。测试过了是OK的，可以正常使用，tiny210可以挂载rootfs进到命令提示符中。 你有空的话帮忙看下有什么地方需要改进的。谢谢~
我把rootfs和busybox按照你说的，放在tools/common下面了，但是传一半就死活传不上去了，明天再传试试看。 smile
ooonebook 写道： hi,wowo,参照你的意见，我把编译busybox和生成rootfs镜像的命令加上去了，在build的tiny210分支上， 其中生成rootfs镜像的方法感觉和编译uImage的方法应该差不多。测试过了是OK的，可以正常使用，tiny210可以挂载rootfs进到命令提示符中。 你有空的话帮忙看下有什么地方需要改进的。谢谢~
我把rootfs和busybox按照你说的，放在tools/common下面了，但是传一半就死活传不上去了，明天再传试试看。 smile
你的动作真快啊，羡慕嫉妒恨啊，哈哈
按理说busybox、rootfs的事情，应该是任务5（rootfs的移植），中间还隔一个任务4（启动到kernel命令行），可惜我时间太少，进展太慢。辛亏你已经try过一遍了，后面我直接整理一下就行了（前人栽树后人乘凉哈~~~）。
如果可以的话，你可以先把这个任务列出来，我们可以再任务5里面讨论。
关于rootfs，我有一个疑问：需要上传吗？
编译出来的rootfs，是二进制的，因此是平台相关的，因此要么不上传，每次都自己编译出来，要么上传到具体的verndor的目录下，例如tools/samsung/tiny210。
wowo 写道：
ooonebook 写道： hi,wowo,参照你的意见，我把编译busybox和生成rootfs镜像的命令加上去了，在build的tiny210分支上， 其中生成rootfs镜像的方法感觉和编译uImage的方法应该差不多。测试过了是OK的，可以正常使用，tiny210可以挂载rootfs进到命令提示符中。 你有空的话帮忙看下有什么地方需要改进的。谢谢~
我把rootfs和busybox按照你说的，放在tools/common下面了，但是传一半就死活传不上去了，明天再传试试看。 smile
你的动作真快啊，羡慕嫉妒恨啊，哈哈
按理说busybox、rootfs的事情，应该是任务5（rootfs的移植），中间还隔一个任务4（启动到kernel命令行），可惜我时间太少，进展太慢。辛亏你已经try过一遍了，后面我直接整理一下就行了（前人栽树后人乘凉哈~~~）。
如果可以的话，你可以先把这个任务列出来，我们可以再任务5里面讨论。
关于rootfs，我有一个疑问：需要上传吗？
编译出来的rootfs，是二进制的，因此是平台相关的，因此要么不上传，每次都自己编译出来，要么上传到具体的verndor的目录下，例如tools/samsung/tiny210。
因为对s5pv210这个平台的支持太好了，就复制几个配置，小修改几个东西，就直接起来了。 后面还是要跟着wowo的脚步自己整一遍，不然感觉收获不是很大。
我这里说的rootfs是根文件系统的目录，里面必须存在一些有必要的目录的（我发现github空目录传不上去），各个平台应该是一样的。 因为根文件系统的镜像有所不同，可以是ramdisk也可以是yaffs或者其他的吧，所以我的设计是这样。 把rootfs的目录放在tools/common下面（但是不包含bin文件，在make busybox才安装进去）， 在build下“make busybox”之后，会根据编译器来编译busybox然后把对应的bin文件安装到rootfs目录下。 在build下的config.mk中配置要生成的rootfs的镜像的类型为ramdisk。 在build下“make rootfs”之后，就会把rootfs制作成ramdisk类型的img，然后放到build/out/rootfs下。 如果后续需要把rootfs制作成其他类型的img，可以直接在config.mk修改要生成的rootfs的镜像，然后在mkrootfs.sh中添加一下支持，make rootfs就可以了。
ooonebook 写道：
wowo 写道：
ooonebook 写道： hi,wowo,参照你的意见，我把编译busybox和生成rootfs镜像的命令加上去了，在build的tiny210分支上， 其中生成rootfs镜像的方法感觉和编译uImage的方法应该差不多。测试过了是OK的，可以正常使用，tiny210可以挂载rootfs进到命令提示符中。 你有空的话帮忙看下有什么地方需要改进的。谢谢~
我把rootfs和busybox按照你说的，放在tools/common下面了，但是传一半就死活传不上去了，明天再传试试看。 smile
你的动作真快啊，羡慕嫉妒恨啊，哈哈
按理说busybox、rootfs的事情，应该是任务5（rootfs的移植），中间还隔一个任务4（启动到kernel命令行），可惜我时间太少，进展太慢。辛亏你已经try过一遍了，后面我直接整理一下就行了（前人栽树后人乘凉哈~~~）。
如果可以的话，你可以先把这个任务列出来，我们可以再任务5里面讨论。
关于rootfs，我有一个疑问：需要上传吗？
编译出来的rootfs，是二进制的，因此是平台相关的，因此要么不上传，每次都自己编译出来，要么上传到具体的verndor的目录下，例如tools/samsung/tiny210。
因为对s5pv210这个平台的支持太好了，就复制几个配置，小修改几个东西，就直接起来了。 后面还是要跟着wowo的脚步自己整一遍，不然感觉收获不是很大。
我这里说的rootfs是根文件系统的目录，里面必须存在一些有必要的目录的（我发现github空目录传不上去），各个平台应该是一样的。 因为根文件系统的镜像有所不同，可以是ramdisk也可以是yaffs或者其他的吧，所以我的设计是这样。 把rootfs的目录放在tools/common下面（但是不包含bin文件，在make busybox才安装进去）， 在build下“make busybox”之后，会根据编译器来编译busybox然后把对应的bin文件安装到rootfs目录下。 在build下的config.mk中配置要生成的rootfs的镜像的类型为ramdisk。 在build下“make rootfs”之后，就会把rootfs制作成ramdisk类型的img，然后放到build/out/rootfs下。 如果后续需要把rootfs制作成其他类型的img，可以直接在config.mk修改要生成的rootfs的镜像，然后在mkrootfs.sh中添加一下支持，make rootfs就可以了。
如果是公共的东西，确实应该放在那里面，你是对的
是的，git不允许上传空目录。