KStudio window上编译uclinux

 可能没有几个人能像我这样在Windows下编译Linux内核，甚至于同时进行内核调试。这种事情我不是第一个做到的，至少我们公司的原TKStudio部门已经做过。在TKStudio网站上，提供了一个Linux内核和ucLinux内核的编译和调试工程可供下载。

正因为TKStudio证明这种想法是可行的，所以我才有可能尝试去做这件事情。我做的仅仅是交叉编译ARM平台下的内核，我也只对此平台熟悉。TKStudio也只支持ARM等嵌入式平台。

在Windows下编译Linux内核步骤

上周，已经成功使用TKStudio编译UBoot，这次将Linux内核移植到TKStudio下也是借鉴移植UBoot的做法。

• 首先，先在Linux平台下配置并编译内核，注意保留生成的.o等目标该文件；
• 然后，将代码移植至Windows，删除内核源码中没有被编译的.c文件（没有对应的.o)；
• 接着，创建TKStudio工程，将剩余的源码导入到工程中；
• 其次，配置好GCC编译相关参数；
• 最后，编译，逐个排查编译问题，直至最后的编译成功。

我编译的内核为Linux-3.0.8，目标为友善之臂的mini210开发板(处理器为s5pv210, Cortex-A8)内核，内核源码为光盘自带。相关的编译参数如下：

C编译参数：-mabi=aapcs-linux -include .\include\generated\autoconf.h -D__LINUX_ARM_ARCH__=7 -march=armv7-a -marm -fno-dwarf2-cfi-asm -mabi=aapcs-linux -mno-thumb-interwork -funwind-tables -msoft-float -Uarm -Wframe-larger-than=1024 -fno-stack-protector -fomit-frame-pointer -g -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO  -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(sem)"  -D"KBUILD_MODNAME=KBUILD_STR(sem)" -mfpu=vfp  -pipe -DTEXT_OFFSET=0×00008000 -mcpu=cortex-a8 -D__KERNEL__

ASM编译参数：

-mabi=aapcs-linux -include .\include\generated\autoconf.h -D__LINUX_ARM_ARCH__=7 -mno-thumb-interwork -funwind-tables  -march=armv7-a  -include asm/unified.h -msoft-float -gdwarf-2  -D"KBUILD_STR(s)=\#s" -D"KBUILD_BASENAME=KBUILD_STR(sem)"  -D"KBUILD_MODNAME=KBUILD_STR(sem)"  -mfpu=vfp  -pipe -DTEXT_OFFSET=0×00008000 -mcpu=cortex-a8 -D__KERNEL__ –D__ASSEMBLY__

同时，还要设置好头文件包含路径：

C头文件包含路径：-s5pv210\include;.\arch\arm\plat-s5p\include;.\arch\arm\plat-samsung\include

ASM头文件包含路径：.\include;.\arch\arm\include;.\arch\arm\mach-s5pv210\include;.\arch\arm\plat-s5p\include;.\arch\arm\plat-samsung\include

以上的参数，有一些依据不同的平台有所不同。这些参数不用自己写，在Linux下编译内核时会生成一些类似于XXX.o.cmd的文件，打开这些文件就可以找到相应的参数设置，拷出来再适当地修改即可。

编译时要注意的事项：

• 编译参数尽量使用.o.cmd中自带的，适度地修改，不能删除太多，否则会出现很多莫名其妙的问题；
• 优化等级不能选不优化，最好是选-O，否则出现一些问题；
• 极少量的.c、.S文件虽然没有直接被编译，但是会被其它文件包含再编译，这些文件是不能删的。至于有哪些文件，不必一个个查，编译时如果提示找不到相应文件，恢复即可；
• Linux内核启动时会有个解压缩的过程，这部分代码由arch\arm\bootp实现。考虑调试问题，且编译错误不容易解决，删除之。

最小化系统漫谈

我做这个事情的动力绝大部分是因为兴趣。Linux平台下的工具用起来不爽，所以才想到了WIndows下的工具。在做UBoot和Linux内核在TKStudio编译时，虽然费时费力，但也收获不少。

编译UBoot时，由于源码量少，所以花了不是太多的时间和精力，并且获取了第一手经验。同时，在反复的折腾过程中，对UBoot主要的文件目标功能和组织已经掌握地比较清晰。再加通过TKScope仿真器连接目标板去跟踪调试，对UBoot的程序框架和运行流程也已经把握。

在编译Linux时，则首先尽量将其配置成功能最小的内核，以减少编译的文件数，同时保持功能简单以便于理解。之后便是加入TKStudio工程并逐个排查错误。这种过程也让我了解了Linux主要的文件功能及其相关件的依赖关系，同时对Linux内核的各个编译配置项也有深入理解。

无论是以上哪一个，让我深有受益的地方便是通过此种方式能够初步掌握这些源码的主要框架，有了绝对的控制权，可以想怎么改就怎么改，同时还能跟踪看改后的运行流程。这就是让它们处于自己的掌控之下。

其实，UBoot和Linux中的源码量虽然大，但很多都是可以去掉的。这些源码虽然增强了内核的功能，但是会影响到理解和阅读。所以，我在处理UBoot时，做了一件比较有意见的事情：尽可能地移植不必要的文件，保留一个最小的UBoot核心，这个核心主要包括目标平台、板级平台、命令行、必备的驱动程序。所涉及的源文件数不多。UBoot的其它文件只不过是功能上的添加或增强。而后，便是在这个核心的基础之上再将原有的文件加入一些进来，以获得更强的功能。

通过这样一个复杂->简化->复杂的过程，我对UBoot已经完全没有任何惧怕心理。虽然源码细节我没有仔细阅读；但是由于对整个框架把握的比较清楚，所以能很快定位相关部分。上图中的源码结构，看起来并不复杂：）

后续对Linux内核，我也会考虑这样干，尽可能地的简化，最后得到一个最最小的系统。只要弄懂这个核心，那就什么都不怕了。