CodeSys runtime内核移植和驱动开发

转载

mob64ca1406d617 2025-01-06 21:17:35

文章标签 makefile module 文档 flash linux内核 文章分类 架构后端开发

linux内核中Kconfig文档的作用

2.6内核的源码树目录下一般都会有两个文文：Kconfig和Makefile。分布在各目录下的Kconfig构成了一个分布式的内核配置数据库，每个Kconfig分别描述了所属目录源文件相关的内核配置菜单。在内核配置make menuconfig(或xconfig等)时，从Kconfig中读出配置菜单，用户配置完后保存到.config(在顶层目录下生成)中。在内核编译时，主Makefile调用这个.config，就知道了用户对内核的配置情况。

上面的内容说明：Kconfig就是对应着内核的配置菜单。假如要想添加新的驱动到内核的源码中，可以通过修改Kconfig来增加对我们驱动的配置菜单，这样就有途径选择我们的驱动，假如想使这个驱动被编译，还要修改该驱动所在目录下的Makefile。

因此，一般添加新的驱动时需要修改的文件有两种（注意不只是两个）

*Kconfig
*Makefile

要想知道怎么修改这两种文件，就要知道两种文档的语法结构。

First: Kconfig

每个菜单项都有一个关键字标识，最常见的就是config。

语法：
config symbol

options

symbol就是新的菜单项，options是在这个新的菜单项下的属性和选项

其中options部分有：

1、类型定义：
每个config菜单项都要有类型定义，bool：布尔类型， tristate三态：内建、模块、移除， string：字符串， hex：十六进制， integer：整型

例如config HELLO_MODULE
bool "hello test module"

bool类型的只能选中或不选中，tristate类型的菜单项多了编译成内核模块的选项，假如选择编译成内核模块，则会在.config中生成一个CONFIG_HELLO_MODULE=m的配置，假如选择内建，就是直接编译成内核影响，就会在.config中生成一个CONFIG_HELLO_MODULE=y的配置.

2、依赖型定义depends on或requires
指此菜单的出现是否依赖于另一个定义

config HELLO_MODULE
bool "hello test module"
depends on ARCH_PXA
这个例子表明HELLO_MODULE这个菜单项只对XScale处理器有效，即只有在选择了ARCH_PXA，该菜单才可见(可配置)。

3、帮助性定义
只是增加帮助用关键字help或---help---

更多详细的Kconfigconfig语法可参考：

Second: 内核的Makefile

内核的Makefile分为5个组成部分：
Makefile    最顶层的Makefile
.config       内核的当前配置文档，编译时成为顶层Makefile的一部分
arch/$(ARCH)/Makefile 和体系结构相关的Makefile
s/ Makefile.* 一些Makefile的通用规则
kbuild Makefile    各级目录下的大概约500个文档，编译时根据上层Makefile传下来的宏定义和其他编译规则，将源代码编译成模块或编入内核。

顶层的Makefile文档读取 .config文档的内容，并总体上负责build内核和模块。Arch Makefile则提供补充体系结构相关的信息。 s目录下的Makefile文档包含了任何用来根据kbuild Makefile 构建内核所需的定义和规则。

（其中.config的内容是在make menuconfig的时候，通过Kconfig文档配置的结果）

在linux2.6.x/Documentation/kbuild目录下有详细的介绍有关kernel makefile的知识。

最后举个例子：
假设想把自己写的一个flash的驱动程式加载到工程中，而且能够通过menuconfig配置内核时选择该驱动该怎么办呢？能够分三步：

第一：将您写的flashtest.c 文档添加到/driver/mtd/maps/ 目录下。

第二：修改/driver/mtd/maps目录下的kconfig文档：
config MTD_flashtest
tristate “ap71 flash"

这样当make menuconfig时，将会出现 ap71 flash选项。

第三：修改该目录下makefile文档。
添加如下内容：obj-$(CONFIG_MTD_flashtest) += flashtest.o

这样，当您运行make menucofnig时，您将发现ap71 flash选项，假如您选择了此项。该选择就会保存在.config文档中。当您编译内核时，将会读取.config文档，当发现ap71 flash 选项为yes 时，系统在调用/driver/mtd/maps/下的makefile 时，将会把 flashtest.o 加入到内核中。即可达到您的目的。

我们都知道驱动可以编译成module和直接编译进内核，那么这两者到底有什么区别？

从驱动的入口函数来看，两者都是一样的，都是module_init（）；

在linux/init.h中可以看到，以下代码：

 
    
1. #ifndef MODULE 
2. 
3. #ifndef __ASSEMBLY__ 
4.   
5. /* initcalls are now grouped by functionality into separate 
6.  * subsections. Ordering inside the subsections is determined
7.  * by link order. 
8.  * For backwards compatibility, initcall() puts the call in 
9.  * the device init subsection.
10.  *
11.  * The `id' arg to __define_initcall() is needed so that multiple initcalls
12.  * can point at the same handler without causing duplicate-symbol build errors.
13.  */
14. 
15. #define __define_initcall(level,fn,id) /
16. static
17. ".initcall" level ".init"))) = fn  
18. ....................  
19. .................... 
20. #define __initcall(fn) device_initcall(fn)  
21. 
22. #define __exitcall(fn) / 
23. static
24. ..................... 
25. #else /* MODULE */ 
26. /* Each module must use one module_init(), or one no_module_init */
27. #define module_init(initfn)                 /
28. static inline initcall_t __inittest(void)       /  
29. return
30. int init_module(void) __attribute__((alias(#initfn)));  
31.   
32. /* This is only required if you want to be unloadable. */
33. #define module_exit(exitfn)                 /
34. static inline exitcall_t __exittest(void)       /  
35. return
36. void cleanup_module(void) __attribute__((alias(#exitfn)));

如果没有定义MODULE宏，那么驱动初始化函数就会带有.initcall6.init属性，那么在其编译时将会被安排到__initcall_start和__initcall_end范围之间（可以参考内核源码目录下的内核链接脚本arch/cpu-type/kernel/vmlinux.lds.S，其中cpu-type可以是mips、arm、i386等），

__initcall_start = .;   
 
 
 
1.   .initcall.init : {   
2.     INITCALLS   
3.   }   
4.   __initcall_end = .;   
5.    
6. 而INITCALLS宏定义在include/asm-generic/Vmlinux.lds.h中： 
7. #define INITCALLS                           /
8.     *(.initcall0.init)                      /   
9.     *(.initcall0s.init)                     /   
10.     *(.initcall1.init)                      /   
11.     *(.initcall1s.init)                     /   
12.     *(.initcall2.init)                      /   
13.     *(.initcall2s.init)                     /   
14.     *(.initcall3.init)                      /   
15.     *(.initcall3s.init)                     /   
16.     *(.initcall4.init)                      /   
17.     *(.initcall4s.init)                     /   
18.     *(.initcall5.init)                      /   
19.     *(.initcall5s.init)                     /   
20.     *(.initcallrootfs.init)                     /   
21.     *(.initcall6.init)                      /   
22.     *(.initcall6s.init)                     /   
23.     *(.initcall7.init)                      /   
24.     *(.initcall7s.init)

在kernel启动时，会执行如下函数：

init->do_basic_setup->do_initcalls
do_initcalls中会把.initcall.init中的函数依次执行一遍
for (call = __initcall_start; call < __initcall_end; call++) {
 
...
 
(*call)();
 
...
 
}

于是在内核启动过程中执行了module_init(fn)函数，也就实现了自动加载模块的目的；

这类似于pmon中带有constructor属性的函数，都是在编译时统一将其安排到某一连续的地址范围内，然后再启动时，遍历执行这些函数。

***编译成模块时，模块也有版本号！在模块的Makefile中有编译该模块使用的内核版本号。或者在当前编译这个模块的内核源代码中也可以看到内核版本号。这个版本号即为所编译的模块的版本号！
当用insmod将模块加载进某个内核时，模块版本号必须要与该内核版本号一致，当然也可以用modprobe命令来强行插入。
注意前后两个内核版本号是针对不同的内核的，前者是针对编译模块时用的内核，后者是模块加载进内核时的内核（即利用该模块的某个内核）。

***字符设备和块设备跟文件系统打交道，他们服务于文件系统，所以只需要关心文件系统。

***网络设备和协议栈打交道，他们服务于协议栈，所以只需要关心协议栈。

linux内核中Kconfig文档的作用

*Kconfig
 *Makefile

要想知道怎么修改这两种文件，就要知道两种文档的语法结构。

First: Kconfig

每个菜单项都有一个关键字标识，最常见的就是config。

语法：

config symbol
options
 <!--[if !supportLineBreakNewLine]-->
 <!--[endif]-->

config HELLO_MODULE
 bool "hello test module"
 depends on ARCH_PXA

这个例子表明HELLO_MODULE这个菜单项只对XScale处理器有效，即只有在选择了ARCH_PXA，该菜单才可见(可配置)。

3、帮助性定义
只是增加帮助用关键字help或---help---

<!--[if !supportLineBreakNewLine]-->
 <!--[endif]-->

更多详细的Kconfigconfig语法可参考：

（其中.config的内容是在make menuconfig的时候，通过Kconfig文档配置的结果）

config MTD_flashtest
 tristate “ap71 flash"

这样当make menuconfig时，将会出现 ap71 flash选项。

第三：修改该目录下makefile文档。
添加如下内容：obj-$(CONFIG_MTD_flashtest) += flashtest.o

这样，当您运行make menucofnig时，您将发现ap71 flash选项，假如您选择了此项。该选择就会保存在.config文档中。当您编译内核时，将会读取.config文档，当发现ap71 flash 选项为yes 时，系统在调用/driver/mtd/maps/下的makefile 时，将会把 flashtest.o 加入到内核中。即可达到您的目的。

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。