以下内容综合了引用多个博主问题分析,自己实践总结
侵权删
问题:
由于驱动ko在固定版本内核下编译形成,在不同的系统中加载时,会导致与内核不匹配而产生无法加载的问题。即在板子上的新产生的系统中使用命令insmod ./emio_sim_i2c.ko,会产生ERROR Invalid module forma,具体dmesg中的报错信息是disagree about version of symbol module_layout。
网上https://www.cnblogs.com/wanglouxiaozi/p/17767576.html
记录的查询方法:
查看emio_sim_i2c.ko的module_layout值:
modprobe --dump-modversions ./emio-sim-i2c.ko
0xa6966dff module_layout
然后查看利用本次创建系统的内核编译生成的驱动模块的module_layout值,
比如newchrled.ko:
modprobe --dump-modversions ./newchrled.ko
0x5a808186 module_layout
如上所示,模块加载报错的原因之一,是其它系统下编译的emio_sim-i2c模块 module_layout值不匹配导致模块加载时报错。
其中的主要原理如下
ko文件运行在Linux内核中,运行时会调用Linux内核提供的接口。
由于Linux内核版本演进非常快,内核提供的接口可能经常发生变动。
为了保持Linux内核运行稳定,Linux采用的策略是:
编译ko文件时,确定了它调用的所有Linux内核接口的版本。
装载ko文件时,检查它调用的Linux内核接口版本,如果与当前Linux内核提供的接口版本完全致,则可以装载,否则拒绝装载。
原文链接:Linux:如何突破内核模块验证的限制?_linux ko如何不依赖于内核版本-CSDN博客
这个在Xilinx提供的编译的内核文件中目录include/generated 提供了UTS_RELEASE定义,
引用https://blog.csdn.net/qq_44771694/article/details/129336145
它会被在inclue/linux下的vermagic,h引用,用来编译生成vermagic标记,在加载驱动的时候就会第一层校验这个vermagic的值,看看内核版本是否一致
查询板子系统的内核版本:uname -a
查询驱动文件的vermagic:modinfo ./emio_sim_i2c.ko;
在insmod报错vermagic不匹配时才考虑去修改vermgic
双校验
Linux加载内核驱动的在过了vermagic的校验后,还会进行CRC的校验,这是如果在当前内核文件中编译出驱动,CRC值是根据一系列计算,
Linux内核为每个接口计算一个CRC整数值
例如: t0xa6966dff module_layout
编译ko时,针对是某个内核版本,把每个接口的CRC值都记录在ko文件中,即接口的版本信息。
装载ko时,与当前内核的接口CRC值进行比较,即接口版本比较。
在内核文件中由Module.symvers这个文件提供导出的信息,来完成CRC计算和校验
解决方法
1.在有源文件的下,直接在指定在当前系统的文件路径下编译驱动模块,在Makefie里载入路径make KLIB=/path_to_kernel_source/ KLIB_BUILD=/path_to_kernel_source/
指定KLIB和KLIB_BUILD为当前内核源码的路径去编译,问题即可解决。
2.没有源文件则直接修改驱动KO文件里所有不匹配的crc的值
列出ko文件调用的所有内核接口
在记录CRC值的文件中,找到接口对应的CRC值
修改ko文件中接口的CRC值
用modprobe --dump-modversions <文件>
实际是修改了上面标黄的8个的值才通过了CRC的验证,成功加载
具体要修改哪些应该看在板子上加载时
修改后用insmod加载不报错,成功加载
能在挂在的设备中找到
具体代码修改的是一个博客的分享,目前忘记出处,暂不贴出来。