有道云笔记地址：
详情看这里链接，记录太多，就不一一排版了。
http://note.youdao.com/noteshare?id=4df8da7c54557abfe7089285917c65f9
一、内核移植初体验
(2)这个文件最初是来自于三星的SMDKV210开发板附带的光盘资料
(3)删除无关文件，一般都是在arch文件下的架构文件，需要删除其他的架构，只保留ARM相关的。
进入arch/arm文件下，删除mach-xx其他文件。只保留三星相关的。
(1)检查Makefile中ARCH和CROSS_COMPILE
所以，我们是执行： make smdkv210_android_defconfig
默认情况下直接make则会直接单线程编译。但是如果make -j4则会4线程编译。
将生成的zImage拷贝到tftp服务器目录文件下，方便使用TFTP下载运行
cp arch/arm/boot/zImage /tftpboot/ -f
(1)根据运行结果，分析发现：linux内核的自解压代码都没有运行（因为没有看到：Uncompressing Linux... done, booting the kernel.参考上节启动的内核，可以看出）
(2)说明zImage根本没有被解压成功，内核代码根本就没有被运行，当然没有输出信息了。所以问题出在解压相关的部分。
(4)内核配置的解压地址应该等于链接地址，否则自解压之后内核无法运行。现在问题变成：第一，内核的链接地址等于多少？第二，内核中配置的解压地址是多少？
(5)这里面还有个问题：内核的链接地址是一个虚拟地址，而自解压代码解压内核时需要物理地址，因此上面说的等于，其实是链接地址对应的物理地址等于自解压地址。
(6)由上节kernel配置分析可知，连接地址和他对应的物理地址通过head.S中可以查到，分别是0xC0008000和0x30008000。那么自解压代码配置的解压地址应该是30008000.
(7)自解压代码对应的自解压地址在mach-s5pv210/Makefile.boot文件中。在其中修改，加入两行：
zreladdr-$(CONFIG_MACH_SMDKV210) := 0x30008000
params_phys-$(CONFIG_MACH_SMDKV210) := 0x30000100
(8)新建cp.sh脚本，同步代码，并且编译，得到的zImage复制到/tftpboot，然后重新下载运行查看结果。
(9)结果就是：还是没运行，但是有效果。自解压代码解压打印信息已经出来了。但是内核还没运行
(1)定义的物理地址不对，从20000000改到30000000即可
static const struct machine_desc __mach_desc_SMDKV210 \
__attribute__((__section__(".arch.info.init"))) = { \
.phys_io = S3C_PA_UART & 0xfff00000,
.io_pg_offst = (((u32)S3C_VA_UART) >> 18) & 0xfffc,
.boot_params = S5P_PA_SDRAM + 0x100,
.init_machine = smdkv210_machine_init,
(1)这个宏用来定义一个机器码的数据结构的。这个宏的使用其实是用来定义一个结构体类型为machine_desc类型的结构体变量，名为__mach_desc_SMDKV210。这个结构体变量会被定义到一个特定段.arch.info.init，因此这个结构体变量将来会被链接器链接到这个.arch.info.init段中。
(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后，实际绑定的是mach-smdkc110.c这个文件。所以实际上mach-smdkv210.c这个文件根本没用到。启示就是不要光看名字。
(1).init_machine = smdkc110_machine_init,
(2)这个元素定义了一个机器硬件初始化函数，这个函数非常重要，这个函数中绑定了我们这个开发板linux内核启动过程中会初始化的各种硬件的信息。
(1)内核启动后会有打印信息，打印信息中隐藏了问题所在。认真的去分析这个打印信息，从中找到对的或者错误的一些信息片段，才能帮助我们找到问题，从而解决问题。
Unable to handle kernel NULL pointer dereference at virtual address 00000060
Internal error: Oops: 5 [#1] PREEMPT
PC is at dev_driver_string+0xc/0x44
LR is at max8698_pmic_probe+0x150/0x32c
Unable to handle kernel NULL pointer dereference at virtual address 00000060
Oops ：内核错误的致命信息，启动时看到Oops表示内核已经死了，死亡信息也在这附近
PC is at dev_driver_string+0xc/0x44
LR is at max8698_pmic_probe+0x150/0x32c
(3)从以上错误信息中的PC和LR的值可以看出，程序是执行到dev_driver_string或者max8698_pmic_probe（这两个是函数或者汇编中的标号）符号部分的时候出错了。我们就从这两个符号出发去寻找、思考可能出错的地方然后试图去解决。
(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键去掉这个模块的支持，保存，重新make编译即可。
保存后，从新make menuconfig，然后/搜索"MAX8698"，发现已经变成n了
(8)实践证明问题被解决了，而且内核再次启动后，下图中的错误是挂载rootfs出错了。
（1）我们这里本身就没有挂载根文件系统，所以，这里报错是正常的
（2）内核启动到根文件系统挂载，说明之前的初始化配置都是正确的。
根本原因在于CONFIG_MFD_MAX8698这个配置宏。这个配置宏决定了很多东西
第一：这个配置宏决定了drivers目录下的max8698对应的驱动程序源代码是否被编译
第二：这个配置宏决定了kernel启动过程中是否会调用一些max8698的相关的代码
(2)总结：kernel是高度模块化和可配置化的，所以在内核中做任何事情（添加一个模块、更改一个模块、去掉一个模块）都必须按照内核设定的方案和流程来走。
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)。
从错误信息字面意思来分析，就是内核试图挂载根文件系统时失败，失败的原因是unknown-block（不能识别的块设备）
通过上面的mount_block_root函数，再结合上节的内核启动流程分析，知道mount_block_root函数就是内核启动的第二阶段的挂载根文件系统函数，就更加确定了出错的地方：即在mount_block_root函数这里出错了。
(3)下一个问题：分析这个错误出现的原因。unknown-block(0,0)。
在kernel启动时uboot会传给内核一个cmdline，其中用root=xx来指定了rootfs在哪个设备上，内核就会到相应的地方去挂载rootfs。
这里的/dev/mmcblk0p2就是rootfs的设备地址，这个设备文件编号的含义就是mmc设备0的第2个分区（设备0就是在SD0通道上的设备，也就是iNand），这里的问题就是没找到mmc设备0的第2分区。
(5)对比九鼎版本的内核启动信息，即可发现我们的内核启动并没有找到MMC设备（内置的iNand和外置的SD卡都没找到），没找到肯定是驱动的问题，这就要去移植MMC驱动了。
(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分区表。
[ 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.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)其实这一步本来就是Y，所以在我们这里是不用管的。但是你自己遇到的一个内核可能默认不是Y，因此要设置。
(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函数。只是读写寄存器的函数名称不同了。我们直接将九鼎的smdkc110_dm9000_set函数cp到三星版本的此函数即可。
(1)DM9000相关的数据配置在arch/arm/plat-s5p/devs.c中更改
(2)在arch/arm/mach-s5pv210/include/mach/map.h中定义了DM9000的IO基地址，和DM9000接在哪个bank有关。
(3)可以看到，启动信息为：网卡驱动移植ok时的信息（即九鼎kernel版本一样的信息）
(1)内核启动在head.S中首先进行了三个校验（CPU id的校验、机器码的校验、tag的校验），然后创建页表，然后做了一些不太会出错的事情，然后b start_kernel。基本上能运行到start_kernel内核移植就不太会出问题了。
(2)有时候移植的内核启动后的现象是：根本没有启动信息出来。这时候有可能是内核启动运行了但是运行出错了没启动起来所以没有打印信息；也有可能是内核根本没得以运行。都有可能但是没法确定。我们希望能有一种调试手段来确定问题所在。
(1)调试方法就是在内核启动的第一阶段添加汇编操作led点亮/熄灭的方法来标明代码运行的轨迹。
(2)我们找之前裸机中汇编操作led点亮/熄灭的代码过来，复制粘贴到head.S中合适位置。然后内核启动后根据led的表现来标明代码有无运行。
(1)整理好led操作的代码段，在head.S中合适的地方添加led这个函数，然后在head.S的内核起始运行阶段添加调用led函数，然后重新编译内核，运行内核看这段代码有无被运行。
| /* LED 全部熄灭的汇编函数 */ led: ldr r3, =0x11111111 ldr r4, =0xE0200240 str r3, [r4]
ldr r3, =0xff ldr r4, =0xE0200244 str r3, [r4] mov pc, lr /* |
(2)如果被运行了，证明在这个调用led的步骤之前的部分都是没问题的，那么如果有错肯定错误在后边；如果没有被运行则证明错误在之前，那么就要去之前的部分debug。