请移步到这里：
第一部分、章节目录
2.17.1.内核移植初体验
2.17.2.初步移植以看到启动信息
2.17.3.内核中机器码的确定
2.17.4.解决内核启动中的错误
2.17.5.iNand的问题和安排
2.17.6.网卡驱动的移植和添加实验
2.17.7.内核启动第一阶段的调试方法
2.17.1.内核移植初体验
2.17.1.1、三星官方移植版内核获取
(1)从网盘下载源码包。
(2)这个文件最初是来自于三星的SMDKV210开发板附带的光盘资料
删除：
删除和三星无关的mach 和 plat
2.17.1.2、构建移植环境
(1)Windows下建立SI工程
(2)ubuntu下解压
2.17.1.3、配置编译下载尝试
(1)检查Makefile中ARCH和CROSS_COMPILE
(2)make smdkv210_android_defonfig
(3)make menuconfig
(4)make -j4
默认情况下直接make则会直接单线程编译。但是如果make -j4则会4线程编译。
2.17.1.4、后续要做的事情：
(1)编译得到的zImage去下载运行，看结果
(2)根据结果去分析问题原因，然后去尝试解决这些问题。
2.17.2.初步移植以看到启动信息
2.17.2.1、分析问题
(1)根据运行结果，分析发现：linux内核的自解压代码都没有运行（因为没有看到：Uncompressing Linux... done, booting the kernel.）
(2)说明zImage根本没有被解压成功，内核代码根本就没有被运行，当然没有输出信息了。所以问题出在解压相关的部分。
(3)问题出在内核配置的解压后代码放置的内存地址处。
(4)内核配置的解压地址应该等于连接地址，否则自解压之后内核无法运行。
现在问题变成：
第一，内核的连接地址等于多少？
第二，内核中配置的解压地址是多少？
(5)这里面还有个问题：
内核的连接地址是一个虚拟地址，而自解压代码解压内核时需要物理地址，
因此上面说的等于，其实是连接地址对应的物理地址等于自解压地址。
(6)连接地址和他对应的物理地址在head.S中可以查到，分别是0xC0008000和0x30008000。那么自解压代码配置的解压地址应该是30008000.
(7)自解压代码对应的自解压地址在mach/Makefile.boot文件中。在其中修改，加入两行：
# override for SMDKV210
zreladdr-$(CONFIG_MACH_SMDKV210) := 0x30008000
params_phys-$(CONFIG_MACH_SMDKV210) := 0x30000100
(8)同步代码，并且编译，得到的zImage复制到/tftpboot，然后重新下载运行查看结果。
(9)结果就是：还是没运行，但是有效果。自解压代码解压打印信息已经出来了。但是内核还没运行
2.17.2.2、问题分析
(1)定义的物理地址不对，从20000000改到30000000即可
\arch\arm\mach-s5pv210\include\mach\memory.h
2.17.3.内核中机器码的确定
2.17.3.1、MACHINE_START宏
(1)这个宏用来定义一个机器码的数据结构的。这个宏的使用其实是用来定义一个结构体类型为machine_desc类型的结构体变量，名为__mach_desc_SMDKV210。这个结构体变量会被定义到一个特定段.arch.info.init，因此这个结构体变量将来会被链接器链接到这个.arch.info.init段中。
static const struct machine_desc __mach_desc_SMDKV210 \
__used \
__attribute__((__section__(".arch.info.init"))) = { \
.nr = MACH_TYPE_SMDKV210, \
.name = "SMDKV210",
.phys_io = S3C_PA_UART & 0xfff00000,
.io_pg_offst = (((u32)S3C_VA_UART) >> 18) & 0xfffc,
.boot_params = S5P_PA_SDRAM + 0x100,
.init_irq = s5pv210_init_irq,
.map_io = smdkv210_map_io,
.init_machine = smdkv210_machine_init,
.timer = &s5p_systimer,
};
(2)经过分析，发现一个mach-xxx.c文件中定义了一个机器码的开发板的machine_desc结构体变量，这个结构体变量放到.arch.info.init段中后，那么就表示当前内核可以支持这个机器码的开发板。
(3)落实到当前开发板和当前内核中来分析，当前我们移植的目标开发板使用S5PV210的CPU，开发板名字叫X210.我们在三星官方版本的内核中是找不到mach-x210.c的，所以我们又不想从零开始去移植，因此我们的思路是在三星移植的mach-s5pv210目录下找一个mach-xx.c，这个开发板和我们的X210开发板最为接近，然后以此为基础来移植。
(4)经过查看，发现mach-s5pc110.c和mach-s5pv210.c和我们的X210开发板最为接近。
我们一般确定的一个原则是：看我们的开发板和三星官方的哪个开发板最为相似。我们的X210开发板抄的是三星的SMDKV210，因此要找这个对应的那个文件。
(5)结合mach-s5pv210目录下的Makefile来分析，
得知.config中定义了 CONFIG_MACH_SMDKV210 = y 后，实际绑定的是mach-smdkc110.c这个文件。所以实际上mach-smdkv210.c这个文件根本没用到。启示就是不要光看名字。
2.17.3.2、硬件驱动的加载和初始化函数执行
(1).init_machine = smdkc110_machine_init,
(2)这个元素定义了一个机器硬件初始化函数，这个函数非常重要，这个函数中绑定了我们这个开发板linux内核启动过程中会初始化的各种硬件的信息。
2.17.4.解决内核启动中的错误
2.17.4.1、认识内核启动OOPS
(1)内核启动后会有打印信息，打印信息中隐藏了问题所在。认真的去分析这个打印信息，从中找到对的或者错误的一些信息片段，才能帮助我们找到问题，从而解决问题。
正确找到机器码
(2)内核启动中的错误信息有一些特征：
1.Unable to handle kernel NULL pointer dereference at virtual address 00000060
2.Internal error: Oops: 5 [#1] PREEMPT
oops就表示内核已经产生严重错误，会马上停止运行，且在附近有错误信息
3.PC is at dev_driver_string+0xc/0x44
Pc停止在这个字符串
4.LR is at max8698_pmic_probe+0x150/0x32c
LR停止在这里
(3)从以上错误信息中的PC和LR的值可以看出，
程序是执行到dev_driver_string或者max8698_pmic_probe（这两个是函数或者汇编中的标号）符号部分的时候出错了。
我们就从这两个符号出发去寻找、思考可能出错的地方然后试图去解决。
2.17.4.2、错误追溯及问题解决
(1)max8698_pmic_probe看名字是max8698这个电源管理IC的驱动安装函数部分出错了，
应该是我们的开发板系统中配置了支持这个电源管理IC，于是乎启动时去加载他的驱动，结果驱动在加载执行的过程中出错了OOPS了。
(2)我们为什么要配置支持这个驱动？这个驱动加载为什么要出错？
(3)结合我们X210开发板的硬件实际情况来分析：我们X210开发板上根本就没有max8698这个电源管理IC，既然硬件都没有驱动执行了肯定会出错。
(4)回忆当时从三星版本的uboot移植的时候，在uboot的lowlevel_init.S中也有调用个电源管理IC初始化函数（PMIC_init），后来解决的办法就是屏蔽掉了这个函数的调用，uboot就成功运行下去了。
(5)为什么我们的uboot和内核中默认都调用了这个电源管理IC的初始化代码？
原因就是三星的SMDKV210开发板中是用了max8698这个电源管理IC的，所以三星的uboot和kernel中都有默认支持这个。但是X210中是没用的，因此都需要去掉。
(6)怎么解决？
在uboot中是直接改源代码屏蔽掉那个初始化函数解决的；在内核中不能这么干？因为linux kernel是高度模块化高度可配置的，内核中每一个模块都是被配置项条件编译了的，因此要去掉某个模块的支持，只需要重新配置去掉选项即可，不用改源代码。所以我们的关键就是要找它对应的配置项。
(7)我们做法：make menuconfig，然后/搜索"MAX8698"这几个关键字，然后看到这个配置项的路径，然后到路径下去按N键去掉这个模块的支持，保存，重新编译即可。
(8)实践证明问题被解决了，而且内核再次启动后直接运行到挂载rootfs才出错。
2.17.4.3、分析及总结
(1)分析：问题究竟是怎么被解决的？涉及哪几个方面
根本原因在于CONFIG_MFD_MAX8698这个配置宏。这个配置宏决定了很多东西
第一：这个配置宏决定了drivers目录下的max8698对应的驱动程序源代码是否被编译
第二：这个配置宏决定了kernel启动过程中是否会调用一些max8698的相关的代码
(2)总结：
kernel是高度模块化和可配置化的，所以在内核中做任何事情（添加一个模块、更改一个模块、去掉一个模块）都必须按照内核设定的方案和流程来走。
2.17.5.iNand的问题和安排
2.17.5.1、错误分析
(1)得到的内核错误信息：
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)。
从错误信息字面意思来分析，就是内核试图挂载根文件系统时失败，失败的原因是unknown-block（不能识别的块设备）
(2)backstrace分析，就是逆向分析，（牛逼）
可以得知错误信息的来源，再结合之前的内核启动流程分析，就更加确定了出错的地方。
[ 1.689158] [<c0031fb8>] (dump_backtrace+0x0/0x110) from [<c0394240>] (dump_stack+0x18/0x1c)
[ 1.697561] r6:00008000 r5:dfdc9000 r4:c051f084 r3:00000002
[ 1.703180] [<c0394228>] (dump_stack+0x0/0x1c) from [<c03942bc>] (panic+0x78/0xf8)
[ 1.710738] [<c0394244>] (panic+0x0/0xf8) from [<c000904c>] (mount_block_root+0x25c/0x2ac)
[ 1.718963] r3:00000000 r2:00000001 r1:dfc2ff60 r0:c049ced5
[ 1.724585] [<c0008df0>] (mount_block_root+0x0/0x2ac) from [<c00090f0>] (mount_root+0x54/0x68)
[ 1.733181] [<c000909c>] (mount_root+0x0/0x68) from [<c0009274>] (prepare_namespace+0x170/0x1c8)
[ 1.741927] r5:c0027a39 r4:c054d200
[ 1.745482] [<c0009104>] (prepare_namespace+0x0/0x1c8) from [<c00084fc>] (kernel_init+0x128/0x170)
[ 1.754406] r5:c00083d4 r4:c054cfc0
[ 1.757949] [<c00083d4>] (kernel_init+0x0/0x170) from [<c0054b10>] (do_exit+0x0/0x5f0)
[ 1.765841] r4:00000000 r3:00000000
(3)下一个问题：分析这个错误出现的原因。unknown-block(0,0)。
在kernel启动时uboot会传给内核一个cmdline，其中用root=xx来指定了rootfs在哪个设备上，内核就会到相应的地方去挂载rootfs。
譬如我们传参中：root=/dev/mmcblk0p2，这里的/dev/mmcblk0p2就是rootfs的设备地址，这个设备文件编号的含义就是mmc设备0的第2个分区（设备0就是在SD0通道上的设备，也就是iNand），这里的问题就是没找到mmc设备0的第2分区。
(4)下一步问题：为什么没找到mmc设备0的第2分区。
一定是因为kernel启动过程中加载mmc驱动的时候有问题，驱动没有发现mmc设备0.问题定位在MMC相关的驱动方面。
(5)对比九鼎版本的内核启动信息，
即可发现我们的内核启动并没有找到MMC设备（内置的iNand和外置的SD卡都没找到），没找到肯定是驱动的问题，这就要去移植MMC驱动了。
我们的kernel启动，没有这两个信息
2.17.5.2、问题阐述
(1)SD/iNand本身都是由一个一个的扇区组成的，回忆裸机中讲到的210的启动时，BL1在SD卡的1扇区开始往后存放，SD卡的0扇区是不用的。SD卡的0扇区是用来放置MBR的。
(2)MBR就是用来描述块设备的分区信息的，事先定义了一个通用的数据结构来描述块设备的分区，我们只要按照这个标准将分区信息写入MBR中即可对该设备完成分区。MBR默认就是在块设备的第0个扇区上存放的。
(3)我们内核中读到iNand分4个分区，我们哪里分区的？
uboot中有一个命令 fdisk -c 0 时就对iNand进行了分区。
uboot的fdisk命令内部已经写死了iNand的分区表，到内核中时内核直接读取MBR就知道了分区。
所以在uboot和内核之间iNand设备的分区信息是靠iNand自己传递的，所以uboot不用给内核传参时传递分区表信息。
(4)如果开发板用的是nandFlash的话，
分区表一般是在内核中自己用代码构建的。所以nand版本的内核移植的时候一般都需要去移植更改nand分区表。
2.17.5.3、解决安排
(1)暂时解决不了这个问题。
2.17.5.4、后续课程安排
(1)一节课搞定网卡驱动的移植，一节课讲述一些内核移植的小方法和技巧，然后课程结束
(2)整体移植的课程结束，进入根文件系统部分。
2.17.6.网卡驱动的移植和添加实验
2.17.6.1、移植标准
(1)网卡驱动移植ok时，启动信息为：
[ 1.452008] dm9000 Ethernet Driver, V1.31
[ 1.455870] eth0: dm9000c at e08f4300,e08f8304 IRQ 42 MAC: 00:09:c0:ff:ec:48 (platform data)
(2)当前内核中网卡驱动尚未移植，因此内核启动时有错误的打印信息：
[ 1.130308] dm9000 Ethernet Driver, V1.31
[ 1.133113] ERROR : resetting
[ 1.135700] dm9000 dm9000.0: read wrong id 0x2b2a2928
[ 1.140915] dm9000 dm9000.0: read wrong id 0x2b2a2928
[ 1.145941] dm9000 dm9000.0: read wrong id 0x2b2a2928
[ 1.150963] dm9000 dm9000.0: read wrong id 0x2b2a2928
[ 1.155992] dm9000 dm9000.0: read wrong id 0x2b2a2928
[ 1.161018] dm9000 dm9000.0: read wrong id 0x2b2a2928
[ 1.166041] dm9000 dm9000.0: read wrong id 0x2b2a2928
[ 1.171070] dm9000 dm9000.0: read wrong id 0x2b2a2928
[ 1.176092] dm9000 dm9000.0: wrong id: 0x2b2a2928
[ 1.180774] dm9000 dm9000.0: not found (-19).
(3)移植的目标就是让我们的版本的内核可以打印出正确情况下的启动信息，那我们就相信内核启动后网卡是可以工作的。
2.17.6.2、make menuconfig中添加DM9000支持
(1)menuconfig中选择Y
(2)其实这一步本来就是Y，所以在我们这里是不用管的。但是你自己遇到的一个内核可能默认不是Y，因此要设置。
2.17.6.3、mach-smdkc110.c中逻辑分析
(1)mach-smdkc110.c 中的 smdkc110_machine_init
这是整个开发板的所有硬件的初始化函数，
在这里加载了的硬件将来启动时就会被初始化，在这里没有的将来启动时就不管。
(2)smdkc110_devices 和 smdkc110_dm9000_set()
这两个地方是和DM9000有关的，要分别去做移植。
(3)smdkc110_dm9000_set
这个函数就是DM9000相关的SROM bank的寄存器设置，相当于uboot中dm9000移植时的dm9000_pre_init函数。只是读写寄存器的函数名称不同了。
uboot的：
九鼎的：
\kernel\kernel\arch\arm\mach-s5pv210\mach-smdkc110.c
用这个替换三星的
2.17.6.4、修改相应的配置参数
(1)DM9000相关的数据配置在arch/arm/plat-s5p/devs.c中更改
(2)在arch/arm/mach-s5pv210/include/mach/map.h中定义了DM9000的IO基地址，和DM9000接在哪个bank有关。
(3)还有+2改成+4，
(4)中断号IRQ_EINT9改成10即可。
2.17.6.5、代码实践
(1)同步代码、编译生成zImage
(2)下载启动后看启动信息。
2.17.7.内核启动第一阶段的调试方法
2.17.7.1、问题点描述
(1)内核启动在head.S中首先进行了三个校验（CPU id的校验、机器码的校验、tag的校验），然后创建页表，然后做了一些不太会出错的事情，然后b start_kernel。基本上能运行到start_kernel内核移植就不太会出问题了。
(2)有时候移植的内核启动后的现象是：根本没有启动信息出来。这时候有可能是内核启动运行了但是运行出错了没启动起来所以没有打印信息；
也有可能是内核根本没得以运行。都有可能但是没法确定。我们希望能有一种调试手段来确定问题所在。
2.17.7.2、调试方法和原理
(1)调试方法就是在内核启动的第一阶段添加汇编操作led点亮/熄灭的方法来标明代码运行的轨迹。
(2)我们找之前裸机中汇编操作led点亮/熄灭的代码过来，复制粘贴到head.S中合适位置。然后内核启动后根据led的表现来标明代码有无运行。
2.17.7.3、动手测试
(1)整理好led操作的代码段，在head.S中合适的地方添加led这个函数，然后在head.S的内核起始运行阶段添加调用led函数，然后重新编译内核，运行内核看这段代码有无被运行。
(2)如果被运行了，证明在这个调用led的步骤之前的部分都是没问题的，那么如果有错肯定错误在后边；如果没有被运行则证明错误在之前，那么就要去之前的部分debug。
2.17.7.4、实验验证