ZYNQ嵌入式Linux驱动挂载解决方案记录

以下内容综合了引用多个博主问题分析，自己实践总结

侵权删

问题：

由于驱动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如何不依赖于内核版本-优快云博客

这个在Xilinx提供的编译的内核文件中目录include/generated 提供了UTS_RELEASE定义，

引用https://blog.youkuaiyun.com/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加载不报错，成功加载

能在挂在的设备中找到

具体代码修改的是一个博客的分享，目前忘记出处，暂不贴出来。