最新花了些时间进行Linux内核的移植。由于项目使用的Evb原生支持的是Linux－3.8，但项目需求要求我们在Linux－3.0.27上进行相关验证，所以进行内核版本的相关移植变得很有必要。
先来介绍下Evb的硬件配资：omap5432, cortex-A15 Dual-CPU,支持USB3.0，支持JTAG调试。
下面的我们移植的一些思路供大家参考： 首先，寻找到一个与Linux－3.0.27相近的内核版本，Linux－3.8还是太新，具有很多新的内核特性，其中针对arm架构主要是使用了全新的Device Tree的概念去替换之前很多的硬件资源硬编码工作（从Linux－3.5开始就很少看见非FDT方式的了），DTB（Device Tree Blob）的存在导致Linux和bootloader都有了很大的改变，u－boot为了支持DTB的启动方式，不再需要像传统方式那样传递给kernel atag结构体，直接给个DTB文件的内存地址就可以了。基于Linux－3.8到Linux－3.0的移植，我们开展了2个星期便放弃了，主要还是变化太大，OF接口的移植花费了太多的精力，并且各个方面的差距太大，导致最后改不下去。于是开始从omap的git tree上看看有没有不需要DTB的Linux版本，最终停留在omap的android Linux版本上，一个基于Linux－3.4的版本，并且提供了fastboot，一个比uboot轻量级的bootloader。于是基于Linux－3.4，我们开始向Linux－3.0的内核进行移植。
移植的一般步骤： 1.将Linux－3.4 arch/arm/mach-omap2和arch/arm/plat-omap替换Linux－3.0下相应目录，进行编译，一般花费半周到一周的时间应该能编译成功，生成zImae即可，可以适当减少相应的外设driver 2.JTAG调试，我们使用的是DS－5，先通过fastboot将zImage load到memory，然后挂上JTAG看下kernel在哪边挂掉，如果出现PC指针跑飞的情况，就用panic函数，挂在可能出错的地方，一般在arch/arm/kernel/setup.c 中的setup_arch()函数中，paging_init iomap这类关于io，mmu部分最容易导致上述情况了 3.使用Kernel early debug，在make menuconfig: kernel hacking-->Kernel debugging-->Kernel low-level debugging functions，它会用到arch/arm/kernel/debug.S中的printascii函数，之后就可以使用printk,printhex8...之类的函数插桩调试各个函数
函数调试的大体流程: init/main.c: start_kernel ｜ ｜ ｜ arch/arm/kernel/setup.c: setup_arch ｜ ｜ ｜ arch/arm/mm/mmu.c: paging_init ｜ ｜ ｜ arch/arm/mach-omap2/board-xxx.c: xxx_init_early ｜ ｜ ｜ init/main.c: rest_init ｜ ｜ init/main.c: kernel_init
上述函数是我们调试过程中出现问题的最多的几个地方。
其实内核的移植并非是高深的技术，需要的是耐心和细心，通过不断的对比和调试，我一贯认为内核的移植是入门Linux内核的最好的手段，后续还会不断更新相关心得 ToBeContinue