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

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

网址https://www.360docs.net/doc/6d3769813.html,/thread-1950216-1-1.html

如何调整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】

在网上看到很多帖子,主要就是这几个:

怎么确定驱动加载顺序

https://www.360docs.net/doc/6d3769813.html,/u2/72751/showart_1074704.html

Linux内核驱动程序初始化顺序的调整

https://www.360docs.net/doc/6d3769813.html,/tech/OS/Linux/2006-12-21/74501.html

内核启动时,设备及驱动初始化的实现

https://www.360docs.net/doc/6d3769813.html,/bbs/archiver/tid-1109340.html

其说明的也很清楚了,就是:

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_rootfsrootfs

c00197f8 t __initcall_timer_init_sysfs6

c00197fc t __initcall_clock_dev_init6

。。。

c00198d8 t __initcall_loop_init6

c00198dc t __initcall_net_olddevs_init6

c00198e0 t __initcall_loopback_init6

c00198e4 t __initcall_enc28j60_init6

。。。

c0019900 t __initcall_as352x_spi_init6

c0019904 t __initcall_spidev_init6

。。。

c0019920 t __initcall_i2c_dev_init6

c0019924 t __initcall_as352x_afe_i2c_init6

c0019928 t __initcall_as352x_afe_init6

。。。

c0019970 t __initcall_random32_reseed7

c0019974 t __initcall_seqgen_init7

c0019978 t __initcall_rtc_hctosys7

c001997c T __con_initcall_start

c001997c t __initcall_con_init

c001997c 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_start

c001997c t __initcall_con_init

c001997c 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) \

#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中的这一行:

*(.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就可以的,而不用这么麻烦去改系统的东西的。。。

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

linux启动过程

Linux系统启动过程分析 by 王斌斌 binbinwang118@https://www.360docs.net/doc/6d3769813.html, Linux系统启动过程分析 操作系统的启动过程,实际上是控制权移交的过程。Linux 系统启动包含四个主要的阶段:BIOS initialization, boot loader, kernel initialization, and init startup.见下图: 阶段一、BIOS initialization,主要功能如下: 1.Peripherals detected 2.Boot device selected 3.First sector of boot device read and executed 系统上电开机后,主板BIOS(Basic Input / Output System)运行POST(Power on self test)代码,检测系统外围关键设备(如:CPU、内存、显卡、I/O、键盘鼠标等)。硬件配置信息及一些用户配置参数存储在主板的CMOS( Complementary Metal Oxide Semiconductor)上(一般64字节),实际上就是主板上一块可读写的RAM芯片,由主板上的电池供电,系统掉电后,信息不会丢失。 执行POST代码对系统外围关键设备检测通过后,系统启动自举程序,根据我们在BIOS中设置的启动顺序搜索启动驱动器(比如的硬盘、光驱、网络服务器等)。选择合适的启动器,比如通常情况下的硬盘设备,BIOS会读取硬盘设备的第一个扇区(MBR,512字节),并执行其中的代码。实际上这里BIOS并不关心启动设备第一个扇区中是什么内容,它只是负责读取该扇区内容、并执行,BIOS的任务就完成了。此后将系统启动的控制权移交到MBR部分的代码。 注:在我们的现行系统中,大多关键设备都是连在主板上的。因此主板BIOS提供了一个操作系统(软件)和系统外围关键设备(硬件)最底级别的接口,在这个阶段,检测系统外围关键设备是否准备好,以供操作系 “” 统使用。 阶段二、Boot Loader 关于Boot Loader,简单的说就是启动操作系统的程序,如grub,lilo,也可以将boot loader本身看成一个小系统。 The BIOS invokes the boot loader in one of two ways: 1.It pass control to an initial program loader (IPL) installed within a driver's Master Boot Record (MBR) 2.It passes control to another boot loader, which passes control to an IPL installed within a partition's boot sector. In either case, the IPL must exist within a very small space, no larger than 446 bytes. Therefore, the IPL for GRUB is merely a first stage, whose sole task is to locate and load a second stage boot loader, which does most of the work to boot the system. There are two possible ways to configure boot loaders: Primary boot loader: Install the first stage of your Linux boot loader into the MBR. The boot loader must be configure to pass control to any other desired operating systems. Secondary boot loader: Install the first stage of your Linux boot loader into the boot sector of some partition. Another boot loader must be installed into the MBR, and configured to pass control to your Linux boot loader. 假设Boot Loader 为grub (grub-0.97),其引导系统的过程如下: grub 分为stage1 (stage1_5) stage2两个阶段。stage1 可以看成是initial program loaderI(IPL),而stage2则实现了grub 的主要功能,包括对特定文件系统的支持(如ext2,ext3,reiserfs等),grub自己的shell,以及内部程序(如:kernrl,initrd,root )等。

Linux设备驱动程序学习(5)-高级字符驱动程序操作[(2)阻塞型IO和休眠]

Linux设备驱动程序学习(5)-高级字符驱动程序操作[(2)阻 塞型I/O和休眠] Linux设备驱动程序学习(5) -高级字符驱动程序操作[(2)阻塞型I/O和休眠]这一部分主要讨论:如果驱动程序无法立即满足请求,该如何响应?(65865346) 一、休眠 进程被置为休眠,意味着它被标识为处于一个特殊的状态并且从调度器的运行队列中移走。这个进程将不被在任何CPU 上调度,即将不会运行。直到发生某 些事情改变了那个状态。安全地进入休眠的两条规则: (1)永远不要在原子上下文中进入休眠,即当驱动在持有一个自旋锁、seqlock或者RCU 锁时不能睡眠;关闭中断也不能睡眠。持有一个信号量时休眠是 合法的,但你应当仔细查看代码:如果代码在持有一个信号量时睡眠,任何其他的等待这个信号量的线程也会休眠。因此发生在持有信号量时的休眠必须短暂, 而且决不能阻塞那个将最终唤醒你的进程。 (2)当进程被唤醒,它并不知道休眠了多长时间以及休眠时发生什么;也不知道是否另有进程也在休眠等待同一事件,且那个进程可能在它之前醒来并获取了 所等待的资源。所以不能对唤醒后的系统状态做任何的假设,并必须重新检查等待条件来确保正确的响应。 除非确信其他进程会在其他地方唤醒休眠的进程,否则也不能睡眠。使进程可被找到意味着:需要维护一个称为等待队列的数据结构。它是一个进程链表,其中饱含了等待某个特定事件的所有进程。在Linux 中,一个等待队列由一个wait_queue_head_t 结构体来管理,其定义在中。 wait_queue_head_t 类型的数据结构非常简单: 它包含一个自旋锁和一个链表。这个链表是一个等待队列入口,它被声明做wait_queue_t。wait_queue_head_t包含关于睡眠进程的信息和它想怎样被唤

设备驱动加到Linux内核中

7.2.3 设备驱动加到Linux内核中 设备驱动程序编写完后将该驱动程序加到内核中。这需要修改Linux 的源代码,然后重新编译内核。 ①将设备驱动程序文件(比如mydriver.c)复制到/Linux/drivers/char目录下。该目录保存了Linux下字符设备的设备驱动程序。修改该目录下mem.c 文件,在int chr_dev_init()函数中增加如下代码: #ifdef CONFIG_MYDRIVER device_init(); #endif 其中CONFIG_MYDRIVER是在配置Linux内核时赋值。 ②在/linux/drivers/char目录下Makefile中增加如下代码: ifeq ($(CONFIG_MYDRIVER),y) L_OBJ + = mydriver.o endif 如果在配置Linux内核时选择了支持新定义的设备,则在编译内核时会编译mydriver.c生成mydriver.o文件。 ③修改/linux/drivers/char目录下config.in文件,在 comment Character devices 语句下面加上 bool suppot for mydriver CONFIG_MYDRIVER 这样,若编译内核,运行make config,make menuconfig或make xconfig,那么在配置字符设备时就会有选项: Support for mydriver 当选中这个设备时,设备驱动就加到了内核中了。 重新编译内核,在shell中将当前目录cd 到Linux目录下,然后执行以下代码: # make menuconfig # make dep # make 在配置选项时要注意选择支持用户添加的设备。这样得到的内核就包含用户的设备驱动程序。 Linux通过设备文件来提供应用程序和设备驱动的接口,应用程序通过标准的文件操作函数来打开、关闭、读取和控制设备。查看Linux文件系统下的/proc/devices,可以看到当前的设备信息。如果设备驱动程序已被成功加进,这里应该由该设备对应的项。/proc/interrupts纪录了当时中断情况,可以用来查看中断申请是否正常;对于DMA和I/O口的使用,在/proc下都有相应的文件进行记录;还可以在设备驱动程序中申请在/proc 文件系统下创建一个文件,该文件用来存放设备相关信息。这样通过查看该文件就可以了解设备的使用情况。总之,/proc文件系统为用户提供了查

linux内核启动 Android系统启动过程详解

linux内核启动+Android系统启动过程详解 第一部分:汇编部分 Linux启动之 linux-rk3288-tchip/kernel/arch/arm/boot/compressed/ head.S分析这段代码是linux boot后执行的第一个程序,完成的主要工作是解压内核,然后跳转到相关执行地址。这部分代码在做驱动开发时不需要改动,但分析其执行流程对是理解android的第一步 开头有一段宏定义这是gnu arm汇编的宏定义。关于GUN 的汇编和其他编译器,在指令语法上有很大差别,具体可查询相关GUN汇编语法了解 另外此段代码必须不能包括重定位部分。因为这时一开始必须要立即运行的。所谓重定位,比如当编译时某个文件用到外部符号是用动态链接库的方式,那么该文件生成的目标文件将包含重定位信息,在加载时需要重定位该符号,否则执行时将因找不到地址而出错 #ifdef DEBUG//开始是调试用,主要是一些打印输出函数,不用关心 #if defined(CONFIG_DEBUG_ICEDCC)

……具体代码略 #endif 宏定义结束之后定义了一个段, .section ".start", #alloc, #execinstr 这个段的段名是 .start,#alloc表示Section contains allocated data, #execinstr表示Section contains executable instructions. 生成最终映像时,这段代码会放在最开头 .align start: .type start,#function /*.type指定start这个符号是函数类型*/ .rept 8 mov r0, r0 //将此命令重复8次,相当于nop,这里是为中断向量保存空间 .endr b 1f .word 0x016f2818 @ Magic numbers to help the loader

linux、内核源码、内核编译与配置、内核模块开发、内核启动流程

linux、内核源码、内核编译与配置、内核模块开发、内核启动流程(转) linux是如何组成的? 答:linux是由用户空间和内核空间组成的 为什么要划分用户空间和内核空间? 答:有关CPU体系结构,各处理器可以有多种模式,而LInux这样的划分是考虑到系统的 安全性,比如X86可以有4种模式RING0~RING3 RING0特权模式给LINUX内核空间RING3给用户空间 linux内核是如何组成的? 答:linux内核由SCI(System Call Interface)系统调用接口、PM(Process Management)进程管理、MM(Memory Management)内存管理、Arch、 VFS(Virtual File Systerm)虚拟文件系统、NS(Network Stack)网络协议栈、DD(Device Drivers)设备驱动 linux 内核源代码 linux内核源代码是如何组成或目录结构? 答:arc目录存放一些与CPU体系结构相关的代码其中第个CPU子目录以分解boot,mm,kerner等子目录 block目录部分块设备驱动代码 crypto目录加密、压缩、CRC校验算法 documentation 内核文档 drivers 设备驱动 fs 存放各种文件系统的实现代码 include 内核所需要的头文件。与平台无关的头文件入在include/linux子目录下,与平台相关的头文件则放在相应的子目录中 init 内核初始化代码 ipc 进程间通信的实现代码 kernel Linux大多数关键的核心功能者是在这个目录实现(程序调度,进程控制,模块化) lib 库文件代码 mm 与平台无关的内存管理,与平台相关的放在相应的arch/CPU目录net 各种网络协议的实现代码,注意而不是驱动 samples 内核编程的范例 scripts 配置内核的脚本 security SElinux的模块 sound 音频设备的驱动程序 usr cpip命令实现程序 virt 内核虚拟机 内核配置与编译 一、清除 make clean 删除编译文件但保留配置文件

am335x_linux-3.14.43内核移植笔记

本文主要描述在EVB335X-II以Device Tree的方式移植新TI官网AM335X系列最新的linux-3.14.43版本内核以及移植Debian文件系统的过程及遇到的一些问题。整个Device Tree牵涉面比较广,即增加了新的用于描述设备硬件信息的文本格式(即.dts文件),又增加 了编译这一文本的工具,同时Bootloader也需要支持将编译后的Device Tree传递给Linux 内核。以下是修改步骤: 一、修改uboot,支持Device Tree EVB335X-II在linux-3.2版本内核移植的时候已经有uboot,因此只需在该uboot上增加Device Tree支持即可,以下是修改步骤: 1、修改include/configs/com335x.h文件,增加支持DT的宏定义: /* Flattened Device Tree */ #define CONFIG_OF_LIBFDT 2、修改uboot启动参数,增加dtb文件的加载和启动(由于目前只是移植EMMC版本的EVB335X-II,因此只需修改EMMC的启动参数即可,大概在405行),修改如下: #elif defined(CONFIG_EMMC_BOOT) #define CONFIG_BOOTCOMMAND \ "run mmcboot;" #define CONFIG_EXTRA_ENV_SETTINGS \ "lcdtype=AUO_AT070TN94\0" \ "console=ttyO0,115200n8\0" \ "mmcroot=/dev/mmcblk0p2 rw\0" \ "mmcrootfstype=ext4 rootwait\0" \ "mmcargs=setenv bootargs console=${console} noinitrd root=${mmcroot} rootfstype=${mmcrootfstype} lcdtype=${lcdtype} consoleblank=0\0" \ "mmcdev=" MMCDEV "\0" \ "loadaddr=0x81000000\0" \ "dtbfile=evb335x-ii-emmc.dtb\0" \ "bootenv=uEnv.txt\0" \ "bootpart=" BOOTPART "\0" \ "loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \ "importbootenv=echo Importing environment from mmc ...; " \ "env import -t $loadaddr ${filesize}\0" \ "loadaddr-dtb=0x82000000\0" \ "loadimage=load mmc ${bootpart} ${loadaddr} uImage\0" \ "loaddtb=load mmc ${bootpart} ${loadaddr-dtb} ${dtbfile}\0" \ "mmcboot=mmc dev ${mmcdev}; " \ "if mmc rescan; then " \ "echo SD/MMC found on device ${mmcdev};" \ "if run loadbootenv; then " \ "echo Loaded environment from ${bootenv};" \ "run importbootenv;" \ "fi;" \ "run mmcargs;" \

Linux内核驱动加载顺序

Linux内核驱动加载顺序 【问题】 背光驱动初始化先于LCD驱动初始化,导致LCD驱动初始化时出现闪屏的现象。 【解决过程】 1 mach-xxx.c中platform devices列表如下 /* platform devices */ static struct platform_device *athena_evt_platform_devices[] __initdata = { //&xxx_led_device, &xxx_rtc_device, &xxx_uart0_device, &xxx_uart1_device, &xxx_uart2_device, &xxx_uart3_device, &xxx_nand_device, &xxx_i2c_device, &xxx_lcd_device, &xxxpwm_backlight_device, ... }; LCD(xxx_lcd_device)设备先于PWM(xxxpwm_backlight_device)设备。 可见驱动的初始化顺序并不是和这个表定义的顺序始终保持一致的。(记得PM操作 - resume/suspend 的顺序 是和这个表的顺序保持一致的) 2 怀疑和编译顺序有关 Z:\kernel\drivers\video\Makefile:背光驱动(backlight/)的编译限于LCD驱动(xxxfb.o)的编译 obj-$(CONFIG_VT) += console/ obj-$(CONFIG_LOGO) += logo/ obj-y += backlight/ display/ ... obj-$(CONFIG_FB_xxx) += xxxfb.o ak_logo.o obj-$(CONFIG_FB_AK88) += ak88-fb/ 这样编译生成的System.map中的顺序为: 906 c001f540 t __initcall_pwm_backlight_init6 907 c001f544 t __initcall_display_class_init6 908 c001f548 t __initcall_xxxfb_init6 Makefile更改为: obj-$(CONFIG_VT) += console/ obj-$(CONFIG_LOGO) += logo/ obj-y += display/

linux grub 引导启动过程详解

linux grub 引导启动过程详解 2008-01-08 17:18 这几天看了很多文档,算是对linux的启动过程有了比较细致的了解. 网上有很多文章谈到这方面的内容,但总觉得没有一篇完全的解析linux启动的 细节,下面是我小弟在学习的过程中总结出来的一些东东.这个是完整的linux启动过程, 不涉及内核,但是我觉得比较详细哦. (由于本人比较懒,这一段是从网上抄的) 机器加电启动后,BIOS开始检测系统参数,如内存的大小,日期和时间,磁盘 设备以及这些磁盘设备用来引导的顺序,通常情况下,BIOS都是被配置成首先检查 软驱或者光驱(或两者都检查),然后再尝试从硬盘引导。如果在这些可移动的设 备中,没有找到可引导的介质,那么BIOS通常是转向第一块硬盘最初的几个扇区, 寻找用于装载操作系统的指令。装载操作系统的这个程序就是boot loader. linux里面的boot loader通常是lilo或者grub,从Red Hat Linux 7.2起,GRUB( GRand Unified Bootloader)取代LILO成为了默认的启动装载程序。那么启动的时候grub是如何被载入的呢 grub有几个重要的文件,stage1,stage2,有的时候需要stage1.5.这些文件一般都 在/boot/grub文件夹下面.grub被载入通常包括以下几个步骤: 1. 装载基本的引导装载程序(stage1),stage1很小,网上说是512字节,但是在我的系统上用du -b /boot/grub/stage1 显示的是1024个字节,不知道是不是grub版本不同的缘故还是我理解有误.stage1通常位于主引导扇区里面,对于硬盘就是MBR了,stage1的主要功能就是装载第二引导程序(stage2).这主要是归结于在主引导扇区中没有足够的空间用于其他东西了,我用的是grub 0.93,stage2文件的大小是107520 bit. 2. 装载第二引导装载程序(stage2),这第二引导装载程序实际上是引出更高级的功能, 以允许用户装载入一个特定的操作系统。在GRUB中,这步是让用户显示一个菜单或是输入命令。由于stage2很大,所以它一般位于文件系统之中(通常是boot所在的根 分区). 上面还提到了stage1.5这个文件,它的作用是什么呢你到/boot/grub目录下看看, fat_stage_1.5 e2fs_stage_1.5 xfs_stage_1.5等等,很容易猜想stage1.5和文件系统 有关系.有时候基本引导装载程序(stage1)不能识别stage2所在的文件系统分区,那么这 时候就需要stage1.5来连接stage1和stage2了.因此对于不同的文件系统就会有不同的stage1.5.但是对于grub 0.93好像stage1.5并不是很重要,因为我试过了,在没有stage1.5 的情况下, 我把stage1安装在软盘的引导扇区内,然后把stage2放在格式化成ext2或者fat格式的软盘内,启动的时候照常引导,并不需要e2fs_stage_1.5或者fat_stage_1.5. 下面是我的试验: #mkfs.ext2 /dev/fd0 #mount -t ext2 /dev/fd0 /mnt/floppy #cd /mnt/floppy #mkdir boot #cd boot #mkdir grub (以上三步可用mkdir -p boot/grub命令完成) #cd grub #cp /boot/grub/{stage1,stage2,grub.conf} ./ #cd; umount /mnt/floppy

linux笔记

20150526 echo adfkjeroiu > /var/www/html/index.html service httpd restart ifconfig XXX.XXX.XXX.XXX elinks XXX.XXX.XXX.XXX web地址栏:XXX.XXX.XXX.XXX 20150527 方法一:Setup 设置IP 方法二:vim /etc/sysconfig/network-XXX/ifcfg-eth0 onboot=no改onboot=yes service network restart 虚拟机中安装2个linux,有时2个linux无法连接网络,即使是DHCP自动获取,也不可以;解决办法:打开其中一个linux虚拟机,单机“右下角-小电脑图标” —“设置”—“桥接模式(B);直接连接屋里网络” ,确定即可; 20150528 more /etc/issue 查看当前linux是centos还是redhat; man 命令查看当前命令的使用方法及参数 table 当一个命令不记得全部字母,可以双击table补齐; ctrl +c 终止当前程序 ctrl +l 清屏 20150529 ls -l查看命令;(-l显示更多属性) ls –a 查看隐藏文件; cp -r /etc/aaa /home/bbb复制/etc下的aaa 到/home下,并且改名bbb; (-r是整个文件夹的意思,如果,没有-r是复制单个文件) mv /etc/aaa /home/bbb 移动/etc下的aaa 到/home下,并且改名bbb;

rm –r 删除一个文件;(如果要是一个文件夹,就有询问yes或no) rm –rf 删除一个文件夹;(如果要是一个文件夹,就无询问) touch 创建文件; pwd 查看当前路径; cd.. 返回相对路径; cd / 返回绝对路径; cd- 返回刚才的路径; su – root或其它用户切换用户; mkdir 创建新目录; cat 查看文件内容; more或less 逐屏查看文件内容; useradd 新添加的用户,在没有更改密码前,无法登陆; passwd 更改密码;但是,密码必须符合复杂性; groupadd 添加一个组; 20150602 w 查看谁登陆过本计算机以及对方的IP; last 查看用户的登录日志; lastlog 查看每个用户最后登录的情况;(一般用于电脑被黑了之后); more /var/log/secure who /var/log/wtmp 干了些什么? root账户下输入su - username 切换到username下输入 history 能看到这个用户历史命令,默认最近的1000条 Linux查看History记录加时间戳小技巧 1.[root@servyou_web ~]# export HISTTIMEFORMAT="%F %T `whoami` " 2.[root@servyou_web ~]# history | tail 3. 1014 2011-06-22 19:17:29 root 15 2011-06-22 19:13:02 root ./test.sh 4. 1015 2011-06-22 19:17:29 root 16 2011-06-22 19:13:02 root vim test.sh 5. 1016 2011-06-22 19:17:29 root 17 2011-06-22 19:13:02 root ./test.sh 6. 1017 2011-06-22 19:17:29 root 18 2011-06-22 19:13:02 root vim test.sh 7. 1018 2011-06-22 19:17:29 root 19 2011-06-22 19:13:02 root ./test.sh 8. 1019 2011-06-22 19:17:29 root 20 2011-06-22 19:13:02 root vim test.sh 9. 1020 2011-06-22 19:17:29 root 21 2011-06-22 19:13:02 root ./test.sh

史上最全linux内核配置详解

对于每一个配置选项,用户可以回答"y"、"m"或"n"。其中"y"表示将相应特性的支持或设备驱动程序编译进内核;"m"表示将相应特性的支持或设备驱动程序编译成可加载模块,在需要时,可由系统或用户自行加入到内核中去;"n"表示内核不提供相应特性或驱动程序的支持。只有<>才能选择M 1. General setup(通用选项) [*]Prompt for development and/or incomplete code/drivers,设置界面中显示还在开发或者还没有完成的代码与驱动,最好选上,许多设备都需要它才能配置。 [ ]Cross-compiler tool prefix,交叉编译工具前缀,如果你要使用交叉编译工具的话输入相关前缀。默认不使用。嵌入式linux更不需要。 [ ]Local version - append to kernel release,自定义版本,也就是uname -r可以看到的版本,可以自行修改,没多大意义。 [ ]Automatically append version information to the version string,自动生成版本信息。这个选项会自动探测你的内核并且生成相应的版本,使之不会和原先的重复。这需要Perl的支持。由于在编译的命令make-kpkg 中我们会加入- –append-to-version 选项来生成自定义版本,所以这里选N。 Kernel compression mode (LZMA),选择压缩方式。 [ ]Support for paging of anonymous memory (swap),交换分区支持,也就是虚拟内存支持,嵌入式不需要。 [*]System V IPC,为进程提供通信机制,这将使系统中各进程间有交换信息与保持同步的能力。有些程序只有在选Y的情况下才能运行,所以不用考虑,这里一定要选。 [*]POSIX Message Queues,这是POSIX的消息队列,它同样是一种IPC(进程间通讯)。建议你最好将它选上。 [*]BSD Process Accounting,允许进程访问内核,将账户信息写入文件中,主要包括进程的创建时间/创建者/内存占用等信息。可以选上,无所谓。 [*]BSD Process Accounting version 3 file format,选用的话统计信息将会以新的格式(V3)写入,注意这个格式和以前的v0/v1/v2 格式不兼容,选不选无所谓。 [ ]Export task/process statistics through netlink (EXPERIMENTAL),通过通用的网络输出工作/进程的相应数据,和BSD不同的是,这些数据在进程运行的时候就可以通过相关命令访问。和BSD类似,数据将在进程结束时送入用户空间。如果不清楚,选N(实验阶段功能,下同)。 [ ]Auditing support,审计功能,某些内核模块需要它(SELINUX),如果不知道,不用选。 [ ]RCU Subsystem,一个高性能的锁机制RCU 子系统,不懂不了解,按默认就行。 [ ]Kernel .config support,将.config配置信息保存在内核中,选上它及它的子项使得其它用户能从/proc/ config.gz中得到内核的配置,选上,重新配置内核时可以利用已有配置Enable access to .config through /proc/config.gz,上一项的子项,可以通过/proc/ config.gz访问.config配置,上一个选的话,建议选上。 (16)Kernel log buffer size (16 => 64KB, 17 => 128KB) ,内核日志缓存的大小,使用默认值即可。12 => 4 KB,13 => 8 KB,14 => 16 KB单处理器,15 => 32 KB多处理器,16 => 64 KB,17 => 128 KB。 [ ]Control Group support(有子项),使用默认即可,不清楚可以不选。 Example debug cgroup subsystem,cgroup子系统调试例子 Namespace cgroup subsystem,cgroup子系统命名空间 Device controller for cgroups,cgroups设备控制器

Linux启动过程详解

深入浅出:Linux的启动流程刨析 Linux的启动过程,是一个Linuxer必须要熟练掌握的。通过系统的启动过程,可以更深入的理解Linux,假如Linux系统出问题的话,可以通过启动过程来分析原因,解决问题。而且,在掌握了Linux的启动流程后,还可以借助宿主机来打造自己的Linux。 下面是我画的一张简单的Linux启动流程图 在了解启动流程之前,我们应该先知道系统的几个重要脚本和配置文件,他们对应的路径为: 1、/sbin/init 2、/etc/inittab 3、/etc/rc.d/rc.sysinit 4、/etc/rc.d/rcN.d //这是几个文件夹N代表数字1,2,3,4.. 5、/etc/fstab 1、关于/sbin/init与/etc/inittab 关于/sbin/init ,它是一个二进制可执行文件,为系统的初始化程序,而/etc/inittab是它的配置文件,我们可以通过/etc/inittab来一睹它的功能,里面的内容是一种固定的文本格式,id:runlevels:action:process 我们来通过它的内容来学习它之前,先了解写运行级别的分类(0-6): 0:关机half

1:单用户模式singel user 2:多用户模式multi user ,不提供nfs服务without nfs 3:完全多用户字符模式full multiuser text mod 4:系统预留officially undefined 5:图形登录界面graphical login 6:重启reboot id:3:initdefault: //这里定义linux的启动时的运行级别,可以看到我的主机的启动级别是3 # System initialization. si::sysinit:/etc/rc.d/rc.sysinit //紧接着,运行系统第一个脚本/etc/rc.d/rc/sysinit //它的action:sysyinit指的是定义系统初始化过程 l0:0:wait:/etc/rc.d/rc 0 l1:1:wait:/etc/rc.d/rc 1 l2:2:wait:/etc/rc.d/rc 2 //然后就是加载服务了,他们被定义在/etc/rc.d/rcN.d l3:3:wait:/etc/rc.d/rc 3 //action:waite 这个进程在在对应级别启动一次,知道它结束为止,我的系统启动级别为3,所有执行rc 3对应的服务 l4:4:wait:/etc/rc.d/rc 4 l5:5:wait:/etc/rc.d/rc 5 l6:6:wait:/etc/rc.d/rc 6 ca::ctrlaltdel:/sbin/shutdown -t3 -r now //这里定义了一个组合快捷键,熟悉吧,没错就是重启,你可以把它注释掉不用 pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"//这里定义了ups电源,powerfail 指的是如果突然断电,它对应的process命令是,提示用户系统电源失效,将要关机,提醒用户把数据都存储好 pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"//这里的action,powerokwaite,指的是系统恢复供电,关机取消...

 1:2345:respawn:/sbin/mingetty tty1 //开启终端,在系统准备工作做好后,就会启动出6个终端,tty1~6 mingetyy就是终端的执行命令 2:2345:respawn:/sbin/mingetty tty2 //可以看到他们对应的级别是2345,你也可以注释

linux内核启动时几个关键地址

linux内核启动时几个关键地址 1、名词解释 ZTEXTADDR 解压代码运行的开始地址。没有物理地址和虚拟地址之分,因为此时MMU处于关闭状态。这个地址不一定时RAM的地址,可以是支持读写寻址的flash等存储中介。 ZRELADDR 内核启动在RAM中的物理地址。压缩的内核映像被解压到这个地址,然后执行。 This is the address where the decompressed kernel will be written, and eventually executed. The following constraint must be valid: __virt_to_phys(TEXTADDR) == ZRELADDR The initial part of the kernel is carefully coded to be position independent. TEXTADDR 内核启动的虚拟地址,与ZRELADDR相对应。一般内核启动的虚拟地址为RAM的第一个bank地址加上0x8000。 TEXTADDR = PAGE_OFFSET + TEXTOFFST Virtual start address of kernel, normally PAGE_OFFSET + 0x8000.This is where the kernel image ends up. With the latest kernels, it must be located at 32768 bytes into a 128MB region. Previous kernels placed a restriction of 256MB here. TEXT_OFFSET 内核偏移地址,即内核起始位置相对于内存起始位置的偏移,对于相对于物理内存还是相对于虚拟内存都是一样的结果。在arch/arm/makefile中设定。 PHYS_OFFSET RAM第一个bank的物理起始地址,即物理内存的起始地址。 Physical start address of the first bank of RAM. PAGE_OFFSET RAM第一个bank的虚拟起始地址,即内核虚拟地址空间的起始地址。 2、小结 从上面分析可知道,linux内核被bootloader拷贝到RAM后,解压代码从ZTEXTADDR开始运行(这段代码是与位置无关的PIC)。内核被解压缩到ZREALADDR处,也就是内核启动的物理地址处。相应地,内核启动的虚拟地址被设定为TEXTADDR,满足如下条件: TEXTADDR = PAGE_OFFSET + TEXT_OFFSET 内核启动的物理地址和虚拟地址满足入下条件: ZRELADDR == virt_to_phys(PAGE_OFFSET + TEXT_OFFSET)= virt_to_phys(TEXTADDR) 假定开发板为smdk2410,则有: 内核启动的虚拟地址 TEXTADDR = 0xC0008000 内核启动的物理地址 ZRELADDR = 0x30008000 如果直接从flash中启动还需要设置ZTEXTADDR地址。

linux读书笔记

12.29 Linux系统 Linux是真正的多用户、多任务操作系统。它继承了UNIX系统的主要特征,具有强大的信息处理功能,特别在Internet和Intranet的应用中占有明显优势。是一个完整的UNIX类操作系统。它允许多个用户同时在一个系统上运行多道程序。真正的32位操作系统。 用户接口 用户接口定义了用户和计算机交互作用的方式。Linux操作系统提供4种不同的用户接口。命令行接口 命令行是为具有操作系统使用经验,熟悉所用命令和系统结构的人员设计的。功能强大,使用方便的命令行是UNIX/Linux系统的一个显著特征。支持命令行的系统程序是命令解释程序。它的主要功能是接收用户输入的命令,然后予以解释并执行。 “$ ”是系统提示符。 在UNIX/Linux系统中,通常将命令解释程序称为shell。各种Linux环境下都安装了多种shell。这些shell由不同的人编写并得到一部分用户的青睐,各有其优势,最常用的几种是Bourne shell(sh),C shell(csh),Bourne Again shell(bash)和Korn shell(ksh)。红旗Linux 的默认shell是bash。 Bash 菜单 图形用户接口 程序接口 程序接口也称为系统调用接口。用户在自己的C程序中使用系统调用,从而获得系统提供的更基层的服务。 系统调用是操作系统内核与用户程序,应用程序之间的接口。在UNIX/Linux系统中,系统调用以C函数的形式出现。例如:fd=fopen(“file1.c”,2);其中,open是系统调用。 所有内核之外的程序都必须经由系统调用才能获得操作系统的服务。系统调用只能在C程序中使用,不能作为命令在终端上执行。由于系统调用能直接进入内核执行,所以其执行效率高。 Linux的版本 Linux有两种版本:核心(Kernel)版本和发行(Distribution)版本。 核心版本 核心版本主要是Linux的内核。Linux内核的官方版本由Linus Torvalds本人维护着。核心版本的序号由三部分数字构成,其形式为:major.minor.patchlevel 其中,major是主版本号,minor是次版本号,二者共同构成了当前核心版本好;patchlevel 表示对当前版本的修订次数。例如:2.6.34表示对2.6核心版本的第34次修订。

Linux内核驱动模块编写概览-ioctl,class_create,device_create

如果你对内核驱动模块一无所知,请先学习内核驱动模块的基础知识。 如果你已经入门了内核驱动模块,但是仍感觉有些模糊,不能从整体来了解一个内核驱动模块的结构,请赏读一下这篇拙文。 如果你已经从事内核模块编程N年,并且道行高深,也请不吝赐教一下文中的疏漏错误。 本文中我将实现一个简单的Linux字符设备,旨在大致勾勒出linux内核模块的编写方法的轮廓。其中重点介绍ioctl的用途。 我把这个简单的Linux字符设备模块命名为hello_mod. 设备类型名为hello_cl ass 设备名为hello 该设备是一个虚拟设备,模块加载时会在/sys/class/中创建名为hello_class 的逻辑设备,在/dev/中创建hello的物理设备文件。模块名为hello_mod,可接受输入字符串数据(长度小于128),处理该输入字符串之后可向外输出字符串。并且可以接受ioctl()函数控制内部处理字符串的方式。 例如: a.通过write函数写入“Tom”,通过ioctl函数设置langtype=chinese,通过read函数读出的数据将会是“你好!Tom/n” b.通过write函数写入“Tom”,通过ioctl函数设置langtype=english,通过read函数读出的数据将会是“hello!Tom/n” c.通过write函数写入“Tom”,通过ioctl函数设置langtype=pinyin,通过read函数读出的数据将会是“ni hao!Tom/n” 一般的内核模块中不会负责设备类别和节点的创建,我们在编译完之后会得到.o或者.k o文件,然后insmod之后需要mk nod来创建相应文件,这个简单的例子 中我们让驱动模块加载时负责自动创建设备类别和设备文件。这个功能有两个步骤, 1)创建设备类别文件class_cr eate(); 2)创建设备文件dev ice_create(); 关于这两个函数的使用方法请参阅其他资料。 linux设备驱动的编写相对wi ndows编程来说更容易理解一点因为不需要处理IR P,应用层函数和内核函数的关联方式浅显易懂。 比如当应曾函数对我的设备调用了open()函数,而最终这个应用层函数会调用我的设备中的自定义open()函数,这个函数要怎么写呢, 我在我的设备中定义的函数名是hello_mod_open,注意函数名是可以随意定义,但是函数签名是要符合内核要求的,具体的定义是怎么样请看 static int hello_mod_open(struct inode *, struct file *); 这样就定义了内核中的open函数,这只是定义还需要与我们自己的模块关联起来,这就要用到一个结构 struct file_operations 这个结构里面的成员是对应于设备操作的各种函数的指针。 我在设备中用到了这些函数所以就如下定义,注意下面的写法不是标准ANSI C的语法,而是GNU扩展语法。 struct file_operations hello_mod_fops = { .owner = THIS_MODULE, .open = hello_mod_open,

相关文档
最新文档