如何调整Linux内核启动中的驱动初始化顺序?

嵌入式ARM 2020-04-03 00:00



如何调整Linux内核启动中的驱动初始化顺序?

【问题】


此处我要实现的是将芯片的ID用于网卡MAC地址,网卡驱动是enc28j60_init。


但是,读取芯片ID的函数,在as352x_afe_init模块中,所以要先初始化as352x_afe_init。


此处,内核编译完之后,在生成的system.map中可以看到,
enc28j60_init在as352x_afe_init之前,所以,无法去读芯片ID。
所以我们的目标是,将as352x_afe_init驱动初始化放到enc28j60_init之前,


然后才能读取芯片ID,才能用于网卡初始化的时候的,将芯片ID设置成网卡MAC地址。

【解决过程】


【1】


最简单想到的,是内核里面的


arch\arm\mach-as352x\core.c


中,去改devices设备列表中的顺序。


enc28j60_init对应的是ssp_device,因为网卡初始化用到的是SPI驱动去进行和通讯的。


as352x_afe_init对应的是afe_device。


原先是:


static struct platform_device *devices[] ={ &uart_device, &nand_device, &afe_device, &audio_device, &usb_device, &as352xkbd_device, &ssp_device,};

把afe改到最前面:


static struct platform_device *devices[] ={ &afe_device, &uart_device, &nand_device, &audio_device, &usb_device, &as352xkbd_device, &ssp_device,};

但是,实际结果是,没有任何影响,连systemp.map生成的,那么模块初始化顺序,都没有任何变化。

也就说明,想要实现驱动加载顺序的改变,改core.c里面的设备列表顺序是没有用的。


【2】

在网上看到很多帖子,其说明的也很清楚了,就是:

Linux内核为不同驱动的加载顺序对应不同的优先级,定义了一些宏:
include\linux\init.h


#define pure_initcall(fn) __define_initcall("0",fn,1)
#define core_initcall(fn) __define_initcall("1",fn,1)#define core_initcall_sync(fn) __define_initcall("1s",fn,1s)#define postcore_initcall(fn) __define_initcall("2",fn,2)#define postcore_initcall_sync(fn) __define_initcall("2s",fn,2s)#define arch_initcall(fn) __define_initcall("3",fn,3)#define arch_initcall_sync(fn) __define_initcall("3s",fn,3s)#define subsys_initcall(fn) __define_initcall("4",fn,4)#define subsys_initcall_sync(fn) __define_initcall("4s",fn,4s)#define fs_initcall(fn) __define_initcall("5",fn,5)#define fs_initcall_sync(fn) __define_initcall("5s",fn,5s)#define rootfs_initcall(fn) __define_initcall("rootfs",fn,rootfs)#define device_initcall(fn) __define_initcall("6",fn,6)#define device_initcall_sync(fn) __define_initcall("6s",fn,6s)#define late_initcall(fn) __define_initcall("7",fn,7)#define late_initcall_sync(fn) __define_initcall("7s",fn,7s)
#define __initcall(fn) device_initcall(fn)


把自己的驱动的函数名用这些宏去定义之后,就会对应不同的加载时候的优先级。

其中,我们写驱动中所用到的module_init对应的是

#define module_init(x) __initcall(x);




#define __initcall(fn) device_initcall(fn)


所以,驱动对应的加载的优先级为6


在上面的不同的优先级中,数字越小,优先级越高。

同一等级的优先级的驱动,加载顺序是链接过程决定的,结果是不确定的,我们无法去手动设置谁先谁后。


不同等级的驱动加载的顺序是先优先级高,后优先级低,这是可以确定的。


所以,像我们之前在驱动中用:


module_init(i2c_dev_init);module_init(as352x_afe_init);module_init(as352x_afe_i2c_init);
module_init(enc28j60_init);

所以,大家都是同一个优先级去初始化,
最后这些驱动加载的顺序,可以查看在根目录下,
生成的system.map:


。。。c00197d8 t __initcall_alignment_init5。。。。。c00197f4 t __initcall_default_rootfsrootfsc00197f8 t __initcall_timer_init_sysfs6c00197fc t __initcall_clock_dev_init6。。。c00198d8 t __initcall_loop_init6c00198dc t __initcall_net_olddevs_init6c00198e0 t __initcall_loopback_init6c00198e4 t __initcall_enc28j60_init6。。。c0019900 t __initcall_as352x_spi_init6c0019904 t __initcall_spidev_init6。。。c0019920 t __initcall_i2c_dev_init6c0019924 t __initcall_as352x_afe_i2c_init6c0019928 t __initcall_as352x_afe_init6。。。c0019970 t __initcall_random32_reseed7c0019974 t __initcall_seqgen_init7c0019978 t __initcall_rtc_hctosys7c001997c T __con_initcall_startc001997c t __initcall_con_initc001997c T __initcall_end。。。

此处就是由于
c0019920 t __initcall_i2c_dev_init6
c0019924 t __initcall_as352x_afe_i2c_init6
c0019928 t __initcall_as352x_afe_init6
在c00198e4 t __initcall_enc28j60_init6之前,所以我这里才要去改。。。

知道原理,能想到的,就是要么把as352x_afe_init改到enc28j60_init之前一级,即优先级为5。即在驱动中,调用:fs_initcall(as352x_afe_init);要么把enc28j60_init改到as352x_afe_init之后,即优先级为7即在驱动中,调用:late_initcall(enc28j60_init);但是,此处麻烦就麻烦在,如果把as352x_afe_init改到enc28j60_init之前一级,发现后面网卡初始化enc28j60_init中,虽然读取芯片ID对了,但是后面的IP-auto configure 有问题。所以放弃。

如果把enc28j60_init改到as352x_afe_init之后,但是,从system.map中看到的是,优先级为7的驱动中,明显有几个驱动,也是和网卡初始化相关的,所以,这样改,尝试后,还是失败了。

所以,没法简单的通过调整现有的驱动的顺序,去实现顺序的调整。最后,被逼无奈,想到了一个可以实现我们需求的办法,那就是,单独定义一个优先级,把afe相关的初始化都放到那里面去,这样,就可以保证,其他没什么相关的冲突了。最后证实,这样是可以实现目的的。

具体添加一个新的优先级的步骤如下:

1.定义新的优先级
include\linux\init.h中:

#define pure_initcall(fn) __define_initcall("0",fn,1)
#define core_initcall(fn) __define_initcall("1",fn,1)#define core_initcall_sync(fn) __define_initcall("1s",fn,1s)#define postcore_initcall(fn) __define_initcall("2",fn,2)#define postcore_initcall_sync(fn) __define_initcall("2s",fn,2s)#define arch_initcall(fn) __define_initcall("3",fn,3)#define arch_initcall_sync(fn) __define_initcall("3s",fn,3s)#define subsys_initcall(fn) __define_initcall("4",fn,4)#define subsys_initcall_sync(fn) __define_initcall("4s",fn,4s)#define fs_initcall(fn) __define_initcall("5",fn,5)#define fs_initcall_sync(fn) __define_initcall("5s",fn,5s)#define rootfs_initcall(fn) __define_initcall("rootfs",fn,rootfs)#if 1#define prev_device_initcall(fn) __define_initcall("6",fn,6)#define prev_device_initcall_sync(fn) __define_initcall("6s",fn,6s)#define device_initcall(fn) __define_initcall("7",fn,7)#define device_initcall_sync(fn) __define_initcall("7s",fn,7s)#define late_initcall(fn) __define_initcall("8",fn,8)#define late_initcall_sync(fn) __define_initcall("8s",fn,8s)
#else#define device_initcall(fn) __define_initcall("6",fn,6)#define device_initcall_sync(fn) __define_initcall("6s",fn,6s)#define late_initcall(fn) __define_initcall("7",fn,7)#define late_initcall_sync(fn) __define_initcall("7s",fn,7s)#endif

2.用对应新的宏,定义我们的驱动:

prev_device_initcall(i2c_dev_init);prev_device_initcall(as352x_afe_i2c_init);prev_device_initcall(as352x_afe_init);

做到这里,本以为可以了,但是编译后,在system.map中,发现之前优先级为7的那几个函数,被放到system.map最后了,而不是预想的,在优先级7之后,在

c001997c T __con_initcall_startc001997c t __initcall_con_initc001997c T __initcall_end


之前。最后,发现时没有把对应的链接文件中的宏加进去:

3.include\asm-generic\vmlinux.lds.h


#if 1#define INITCALLS \*(.initcall0.init) \*(.initcall0s.init) \*(.initcall1.init) \*(.initcall1s.init) \*(.initcall2.init) \*(.initcall2s.init) \*(.initcall3.init) \*(.initcall3s.init) \*(.initcall4.init) \*(.initcall4s.init) \*(.initcall5.init) \*(.initcall5s.init) \*(.initcallrootfs.init) \*(.initcall6.init) \*(.initcall6s.init) \*(.initcall7.init) \*(.initcall7s.init) \*(.initcall8.init) \*(.initcall8s.init)
#else
#define INITCALLS \*(.initcall0.init) \*(.initcall0s.init) \*(.initcall1.init) \*(.initcall1s.init) \*(.initcall2.init) \*(.initcall2s.init) \*(.initcall3.init) \*(.initcall3s.init) \*(.initcall4.init) \*(.initcall4s.init) \*(.initcall5.init) \*(.initcall5s.init) \*(.initcallrootfs.init) \*(.initcall6.init) \*(.initcall6s.init) \*(.initcall7.init) \*(.initcall7s.init)
#endif


最后,再重新编译,就可以实现我们要的,和afe相关的驱动初始化,都在网卡enc28j60_init之前了。也就可以在网卡里面读芯片ID了。当然,对应编译生成的system.map文件中,对应的通过module_init定义的驱动,优先级也都变成7了。而late_initcall对应优先级8了。

注:当前开发板arm的板子,所以,对应的load 脚本在:
linux-2.6.28.4\arch\arm\kernel\vmlinux.lds 看起来,应该是这个文件:

linux-2.6.28.4\arch\arm\kernel\vmlinux.lds.S
生成上面那个脚本的。vmlinux.lds中的这一行:

__initcall_start = .; *(.initcallearly.init) __early_initcall_end = .; *(.initcall0.init) *(.initcall0s.init) *(.initcall1.init) *(.initcall1s.init) *(.initcall2.init) *(.initcall2s.init) *(.initcall3.init) *(.initcall3s.init) *(.initcall4.init) *(.initcall4s.init) *(.initcall5.init) *(.initcall5s.init) *(.initcallrootfs.init) *(.initcall6.init) *(.initcall6s.init) *(.initcall7.init) *(.initcall7s.init)


就是将之前那些对应的init类型的函数,展开,放到这对应的位置。

【3】

不过,最后的最后,竟然发现网卡还是工作不正常,结果第二天,无意间发现是网卡地址设置导致网卡工作不正常的。

也就是说,实际是直接将afe设置到原先的优先级5就可以的,而不用这么麻烦去改系统的东西的...

不过,至少这也是一种办法,虽然不是那么的好...

-END-




推荐阅读



【01】为什么Linux CFS调度器没有带来惊艳的碾压效果?
【02】Linux是否能在 8 位 MCU 上运行?
【03】求职要做足功课!看看嵌入式linux牛人是如何做的
【04】看漫画,学Linux内核!看完明白小企鹅们在干啥了吧?
【05】若想成为一名Linux下编程高手,必须能对各种系统调用有透彻的了解



免责声明:整理文章为传播相关技术,版权归原作者所有,如有侵权,请联系删除
嵌入式ARM 关注这个时代最火的嵌入式ARM,你想知道的都在这里。
评论 (0)
  • 置信区间反映的是“样本均值”这个统计量的不确定性,因此使用的是标准误(standard error),而不是直接用样本标准差(standard deviation)。标准误体现的是均值的波动程度,而样本标准差体现的是个体数据的波动程度,两者并非一回事,就如下图所显示的一样。下面优思学院会一步一步解释清楚:一、标准差和标准误,究竟差在哪?很多同学对“标准差”和“标准误”这两个概念傻傻分不清楚,但其实差别明显:标准差(Standard Deviation,σ或s):是衡量单个数据点相对于平均值波动的
    优思学院 2025-04-17 13:59 25浏览
  • 自动驾驶技术的飞速发展,正在重新定义未来出行的边界。从感知到决策,从规划到控制,每一个环节都离不开海量、精准的高质量数据支撑。然而,随着传感器数量的增加和数据规模的指数级增长,行业正面临一系列挑战:多源传感器数据的时间同步难题、复杂数据格式的适配、测量技术的灵活性不足、设备集成周期冗长等,这些问题正成为自动驾驶研发与测试的“隐形瓶颈”。基于技术积累与行业洞察,本文分享一套创新的ADAS时空融合数据采集方案。通过硬件与软件的深度协同优化,能够很好地解决数据采集中的核心痛点,还为自动驾驶研发提供了高
    康谋 2025-04-17 09:54 51浏览
  • 【摘要/前言】4月春日花正好,Electronica就在浪漫春日里,盛大启幕。2025年4月15-17日,慕尼黑上海电子展于上海新国际博览中心成功举办。伴随着AI、新能源汽车、半导体的热潮,今年的Electronica盛况空前。请跟随Samtec的视角,感受精彩时刻!【 Samtec展台:老虎的朋友圈技术派对】借天时、占地利、聚人和,Samtec 展台人气爆棚!每年展会与大家相聚,总能收获温暖与动力~Samtec展台位于W3展馆716展位,新老朋友相聚于此,俨然一场线下技术派对!前沿D
    电子资讯报 2025-04-17 11:38 42浏览
  • 一、行业背景与需求随着智能化技术的快速发展和用户对便捷性需求的提升,电动车行业正经历从传统机械控制向智能交互的转型。传统电动车依赖物理钥匙、遥控器和独立防盗装置,存在操作繁琐、功能单一、交互性差等问题。用户期待通过手机等智能终端实现远程控制、实时数据监控及个性化交互体验。为此,将蓝牙语音芯片集成至电动车中控系统,成为推动智能化升级的关键技术路径。二、方案概述本方案通过在电动车中控系统中集成WT2605C蓝牙语音芯片,构建一套低成本、高兼容性的智能交互平台,实现以下核心功能:手机互联控制:支持蓝牙
    广州唯创电子 2025-04-18 08:33 116浏览
  •   北京华盛恒辉无人机电磁兼容模拟训练系统软件是专门用于模拟与分析无人机在复杂电磁环境中电磁兼容性(EMC)表现的软件工具。借助仿真技术,它能帮助用户评估无人机在电磁干扰下的性能,优化电磁兼容设计,保障无人机在复杂电磁环境中稳定运行。   应用案例   目前,已有多个无人机电磁兼容模拟训练系统在实际应用中取得了显著成效。例如,北京华盛恒辉和北京五木恒润无人机电磁兼容模拟训练系统。这些成功案例为无人机电磁兼容模拟训练系统的推广和应用提供了有力支持。   系统功能   电磁环境建模:支持三维
    华盛恒辉l58ll334744 2025-04-17 15:10 55浏览
  • 一、汽车智能化浪潮下的蓝牙技术革新随着智能网联汽车的快速发展,车载信息娱乐系统(IVI)正从单一的驾驶辅助向“第三生活空间”转型。蓝牙技术作为车内无线连接的核心载体,承担着音频传输、设备互联、数据交互等关键任务。然而,传统方案中MCU需集成蓝牙协议栈,开发周期长、成本高,且功能扩展性受限。WT2605C蓝牙语音芯片应势而生,以双模蓝牙SOC架构重新定义车用蓝牙系统的开发模式,通过“多、快、好、省”四大核心价值,助力车企快速打造高性价比的智能座舱交互方案。二、WT2605C芯片的四大核心优势1.
    广州唯创电子 2025-04-17 08:38 29浏览
  • 现阶段,Zigbee、Z-Wave、Thread、Wi-Fi与蓝牙等多种通信协议在智能家居行业中已得到广泛应用,但协议间互不兼容的通信问题仍在凸显。由于各协议自成体系、彼此割据,智能家居市场被迫催生出大量桥接器、集线器及兼容性软件以在不同生态的设备间构建通信桥梁,而这种现象不仅增加了智能家居厂商的研发成本与时间投入,还严重削减了终端用户的使用体验。为应对智能家居的生态割裂现象,家居厂商需为不同通信协议重复开发适配方案,而消费者则需面对设备入网流程繁琐、跨品牌功能阉割及兼容隐患等现实困境。在此背景
    华普微HOPERF 2025-04-17 17:53 52浏览
  • 近日,全球6G技术与产业生态大会(简称“全球6G技术大会”)在南京召开。紫光展锐应邀出席“空天地一体化与数字低空”平行论坛,并从6G通信、感知、定位等多方面分享了紫光展锐在6G前沿科技领域的创新理念及在空天地一体化技术方面的研发探索情况。全球6G技术大会是6G领域覆盖广泛、内容全面的国际会议。今年大会以“共筑创新 同享未来”为主题,聚焦6G愿景与关键技术、安全可信、绿色可持续发展等前沿主题,汇聚国内外24家企业、百余名国际知名高校与科研代表共同商讨如何推动全行业6G标准共识形成。6G迈入关键期,
    紫光展锐 2025-04-17 18:55 133浏览
  • 一、行业背景与需求智能门锁作为智能家居的核心入口,正从单一安防工具向多场景交互终端演进。随着消费者对便捷性、安全性需求的提升,行业竞争已从基础功能转向成本优化与智能化整合。传统门锁后板方案依赖多颗独立芯片(如MCU、电机驱动、通信模块、语音模块等),导致硬件复杂、功耗高、开发周期长,且成本压力显著。如何通过高集成度方案降低成本、提升功能扩展性,成为厂商破局关键。WTVXXX-32N语音芯片通过“单芯片多任务”设计,将语音播报、电机驱动、通信协议解析、传感器检测等功能整合于一体,为智能门锁后板提供
    广州唯创电子 2025-04-18 09:04 125浏览
  • 1. 在Ubuntu官网下载Ubuntu server  20.04版本https://releases.ubuntu.com/20.04.6/2. 在vmware下安装Ubuntu3. 改Ubuntu静态IP$ sudo vi /etc/netplan/00-installer-config.yaml# This is the network config written by 'subiquity'network:  renderer: networkd&nbs
    二月半 2025-04-17 16:27 68浏览
  •   无人机蜂群电磁作战仿真系统全解析   一、系统概述   无人机蜂群电磁作战仿真系统是专业的仿真平台,用于模拟无人机蜂群在复杂电磁环境中的作战行为与性能。它构建虚拟电磁环境,模拟无人机蜂群执行任务时可能遇到的电磁干扰与攻击,评估作战效能和抗干扰能力,为其设计、优化及实战应用提供科学依据。   应用案例   目前,已有多个无人机蜂群电磁作战仿真系统在实际应用中取得了显著成效。例如,北京华盛恒辉和北京五木恒润无人机蜂群电磁作战仿真系统。这些成功案例为无人机蜂群电磁作战仿真系统的推广和应用提
    华盛恒辉l58ll334744 2025-04-17 16:29 74浏览
  •   无人机蜂群电磁作战仿真系统软件,是专门用于模拟、验证无人机蜂群在电磁作战环境中协同、干扰、通信以及对抗等能力的工具。下面从功能需求、技术架构、典型功能模块、发展趋势及应用场景等方面展开介绍:   应用案例   目前,已有多个无人机蜂群电磁作战仿真系统在实际应用中取得了显著成效。例如,北京华盛恒辉和北京五木恒润无人机蜂群电磁作战仿真系统。这些成功案例为无人机蜂群电磁作战仿真系统的推广和应用提供了有力支持。   功能需求   电磁环境建模:模拟构建复杂多样的电磁环境,涵盖各类电磁干扰源与
    华盛恒辉l58ll334744 2025-04-17 16:49 67浏览
  •   无人机电磁兼容模拟训练系统软件:全方位剖析   一、系统概述   北京华盛恒辉无人机电磁兼容模拟训练系统软件,专为满足无人机于复杂电磁环境下的运行需求而打造,是一款专业训练工具。其核心功能是模拟无人机在电磁干扰(EMI)与电磁敏感度(EMS)环境里的运行状况,助力用户评估无人机电磁兼容性能,增强其在复杂电磁场景中的适应水平。   应用案例   目前,已有多个无人机电磁兼容模拟训练系统在实际应用中取得了显著成效。例如,北京华盛恒辉和北京五木恒润无人机电磁兼容模拟训练系统。这些成功案例为
    华盛恒辉l58ll334744 2025-04-17 14:52 34浏览
  •   无人机电磁环境效应仿真系统:深度剖析   一、系统概述   无人机电磁环境效应仿真系统,专为无人机在复杂电磁环境下的性能评估及抗干扰能力训练打造。借助高精度仿真技术,它模拟无人机在各类电磁干扰场景中的运行状态,为研发、测试与训练工作提供有力支撑。   应用案例   目前,已有多个无人机电磁环境效应仿真系统在实际应用中取得了显著成效。例如,北京华盛恒辉和北京五木恒润无人机电磁环境效应仿真系统。这些成功案例为无人机电磁环境效应仿真系统的推广和应用提供了有力支持。   二、系统功能  
    华盛恒辉l58ll334744 2025-04-17 15:51 72浏览
我要评论
0
0
点击右上角,分享到朋友圈 我知道啦
请使用浏览器分享功能 我知道啦