2013年03月05日

TQ2440的学习——LINUX移植（内核的初步分析及修改）

通过前面的UBOOT的移植，我们已经使TQ2440具备了网络功能，而且内存工作也正常。只要利用tftp命令我们就可以从服务器端下载内核到内存中，然后使用bootm命令进行内核的启动。所以现在开始就可以开始移植调试LINUX内核了。

LINUX操作系统的伟大之处这里就不再废话了。内核移植最让人头痛的往往是寻找相关设备驱动。由于不同的板子上所配置的硬件都有区别，如何精确的加载所需要的驱动模块且去掉不需要的部分是个劳神费力的事情。

LINUX内核对不同的架构支持的思想方法基本上和UBOOT是一样的。比如说用一个配置机制来管理不同架构的内核生成；不同的架构都有对应特性的启动文件；都会提供一定的设备驱动开发规范来驱动各类设备。所以不用担心内核配置不好，只要掌握好相关的移植规范，没有什么设备是不能被支持的。

LINUX的移植也可以像UBOOT那样自己从头创建一个对应自己板子硬件配置的板级支持包。比如说MINI2440，他们并不是只讲讲如何修改SMDK2410或者SMDK2440的板级支持包最后来创建一个内核。他们自己做了一个MINI2440的板级支持包，并永久的添加进入了LINUX内核中。OK，我们也来尝试这样干。

这里就用LINUX内核中的SMDK2440板级支持包为模板，创建一个类似的支持TQ2440的板级支持包。

ARM相关的支持配置主要在arch/arm目录下面实现，里面最醒目的文件夹有两类：一类是前缀为mach-xxx的文件夹；一类是前缀为plat-xxx的文件夹。前者多是具体某一类型的芯片特定设备的驱动配置放置的地方，一些利用该类型芯片设计的硬件板所写的板级设备驱动配置文件就存放在这个文件里。后者主要是一系列型号或者公司的芯片通用驱动配置存放的地方。

使用命令“make menuconfig ARCH=arm CROSS_COMPILE=arm-linux-”可以进入到ARM架构的内核配置界面。在主目录下选择“System Type”选项进入可以看见和X86不同的是，ARM的配置不光要确定CPU的类型（“ARM system type”选项），还可以确定具体所使用的板子，选择“S3C2440 and S3C2442 Machines”进去就可以看到里面提供的选项多是具体型号的设备，在这个选项下面可以看到“MINI2440 development board”这个选项，如果选择了这个选项，和mini2440相关的一些驱动就会被编译到内核中去。

从上面可以确定的是配置自己的板级支持选项就是将我们需要的驱动的更加精确的编译到内核中去，从而实现内核在尺寸大小方面的优化。

这里还是利用学习UBOOT的做法，先在菜单中添加一个自己板子的名字，然后使用复制粘贴的方法将SMDK2440的相关支持文件移植到自己的板子工程中。

首先查看Kconfig看看SMDK2440的菜单配置情况（arch/arm/mach-s3c2440）

 

这个配置的意思是：这个宏ARCH_S3C2440是一个bool型的配置；在菜单中它的名字是“SMDK2440”；如果选择这个选项，那么同时CPU_S3C2440、S3C2440_XTAL_1693440、MACH_SMDK、S3C_DEV_USB_HOST、S3C_DEV_NAND这几个选项都会被选上。

 

这个配置的意思是：如果ARCH_S3C2440这个宏的值是y，那么这个选项也会被选上。同时S3C2440_XTAL_16934400、CPU_S3C2440也会被选上。

这里再来看看TQ2440的配置，这个板卡外接晶振是12MHz，但是SMDK2440使用的是16.9344MHz的晶振。按照以前的方法就是直接修改SMDK2440的宏，但是这样就破坏了SMDK2440的板级支持包，而且某个细节修改的不对都可能会造成各种奇怪的问题。还有那个MACH_SMDK宏，如果要用在TQ2440里面，总感觉很别扭。所以，我们仿造上面的配置代码配置一个自己的配置选项。

 

当然这里也存在不完全的地方，不过这里还是遵循“先实现，再优化”的原则。免得让自己迷失方向。

上述修改内核配置菜单中的效果

 

当然光改菜单是没有用的，必须要把菜单中的宏绑定到Makefile中去才行。现在来复制mach-smdk2440.c并重命名为mach-fzb2440.c，然后修改里面的smdk2440_map_io函数中调用的s3c24xx_init_clocks函数所传入的参数为12000000。这个函数也是确定外接晶振频率的，要修改成12MHz才行。

修改Makefile里面仿照SMDK2440添加字段

 

 

编译的时候内核报错，这里就直接给出解决办法。问题出在mach-fzb2440.c里面有一个头文件common-smdk.h（该文件中有个函数需要调用该头文件中声明的一个函数）。搜索下这个文件，最终确定该文件在plat-s3c24xx/include/plat/目录下，将这个目录下的common-smdk.h文件到同一目录下并重命名为common-fzb.h文件，然后再修改mach-fzb2440.c中包含的头文件列表；还要修改plat-s3c24xx目录下的common-smdk.c（因为common-smdk.h中定义的函数在common-smdk.c文件中实现）其复制并重命名为common-fzb.c；最后还要指定编译依赖关系，将plat-s3c24xx目录下的Makefile文件打开查看可以发现控制common-smdk.c编译的宏为MACH_SMDK，这里还是仿造这个模式建立common-fzb.c编译控制条目，将控制的宏定义为MACH_FZB。同时还要修改plat-s3c24xx目录下的Kconfig将MACH_FZB的依赖关系指明。

Makefile的修改

 

Kconfig的修改

 

再次编译后顺利生成zImage映像文件，这个映像文件还要处理成uImage才能被uboot识别并执行启动过程。

zImage转换成为uImage

 

下载到TQ2440中0x30008000处然后使用“bootm 0x30008000”命令进行内核的启动，可以看到打印了一堆信息出来。

 

这样一个按照自己板子硬件初步配置的内核就跑起来了，不过由于没有移植文件系统，最后还是会报错。而且也仅仅是将SMDK2440的相关文件进行复制粘贴创造了自己板子的内核版本。不过从这个过程倒是可以看到一个事实，给特定的硬件做内核修改添加的地方并不多（当然，这得感谢开源社区那些前辈们的伟大工作）。移植的关键其实是帮助内核确定它到底要加载那些驱动，并在类似mach-fzb2440.c之类的文件中准确的利用设备描述结构体描述它们并添加到链表里面去。

所以通过前面的尝试这里也同时总结一个内核移植的初步基本思路：确定板子上的硬件设备，接着到内核drivers目录下寻找相关的驱动（如果不存在，就要写一个）；列出一个清单，表明内核到底有多少驱动可以直接用，有多少需要自己写；最后到CPU相关架构目录下建立配置文件并填写设备列表，以帮助内核在启动的时候按照这个设备列表加载相关驱动（如果你的CPU架构没有在内核中得到支持，那个应该是痛苦的事情）；最后当然是对各个部分进行优化完成内核的移植并启动到命令行界面下作应用平台的开发。