从零开始之驱动开发、linux驱动(一、驱动基础)

 

准备19年在深圳这边找驱动相关的工作了,所以从头开始再学一遍韦东山老师的驱动课程,并做好记录,希望能找到满意的工作。

同时该系列的驱动都是在前面新移植的linux3.16.57的基础上工作的。

 

之前的驱动模型学习和分析,从框架上了解的驱动的组织形式(在4.9的内核的基础上分析的)。

https://blog.csdn.net/qq_16777851/article/category/7901554

 

 

在ARM工作模式中,处理器模式切换可以通过软件控制进行切换,即修改CPSR模式位,但这是在特权模式下,当我们处于用户模式下,是没有权限实现模式转换的。若想实现模式切换,只能由另一种方法来实现,即通过中断或是异常处理过程进行切换。于是ARM指令集中提供了两条产生异常的指令,通过这两条指令可以用软件的方法实现异常,其中一个就是中断指令swi(另一个是断点中断BKPT ).

 

 软件中断指令(Software Interrupt, swi)用于产生软中断,实现从用户模式变换到管理模式,CPSR保存到管理模式的SPSR中,执行转移到swi向量。在其他模式下也可以使用SWI指令,处理器同样切换到管理模式。

1.SWI指令格式如下:

cond  是执行指令的条件

immed_24  24位立即数,值为从0――16777215之间的整数

SWI指令后面的24立即数是干什么用的呢?用户程序通过SWI指令切换到特权模式,进入软中断处理程序,但是软中断处理程序不知道用户程序到底想要做什么?SWI指令后面的24位用来做用户程序和软中断处理程序之间的接头暗号。通过该软中断立即数来区分用户不同操作,执行不同内核函数。如果用户程序调用系统调用时传递参数,根据ATPCSC语言与汇编混合编程规则将参数放入R0~R4即可。

 

使用SWI指令时,通常使用以下两种方法进行参数传递,SWI异常处理程序可以提供相关的服务,这两种方法均是用户软件协定。SWI异常中断处理程序要通过读取引起软件中断的SWI指令,以取得24为立即数。

1)、指令中24位的立即数指定了用户请求的服务类型,中断服务的参数通过通用寄存器传递。

如下面这个程序产生一个中断号位12 的软中断:

MOV R0,#34                    ;设置功能号为34

SWI 12                              ;产生软中断,中断号为12

2)、指令中的24位立即数被忽略,用户请求的服务类型有寄存器R0的值决定,参数通过其他的通用寄存器传递。

如下面的例子通过R0传递中断号,R1传递中断的子功能号:

MOV R0, #12                  ;设置12号软中断

MOV R1, #34                  ;设置功能号为34

SWI  0

 

 操作系统的主要功能是为应用程序的运行创建良好的环境,保障每个程序都可以最大化利用硬件资源,防止非法程序破坏其它应用程序执行环境,为了达到这个目的,操作系统会将硬件的操作权限交给内核程序来管理,用户程序不能随意使用硬件,使用硬件(对硬件寄存器进行读写)时要先向操作系统发出请求,操作系统内核帮助用户程序实现其操作,也就是说用户程序不会直接操作硬件,而是提供给用户程序一些具备预定功能的内核函数,通过一组称为系统调用的(system call)的接口呈现给用户,系统调用把应用程序的请求传给内核,调用相应的内核函数完成所需的处理,将处理结果返回给应用程序。

 

操作系统里将用户程序运行在用户模式下,并且为其分配可以使用内存空间,其它内存空间不能访问,内核态运行在特权模式下,对系统所有硬件进行统一管理和控制。从前面所学知识可以了解到,用户模式下没有权限进行模式切换,这也就意味着用户程序不可能直接通过切换模式去访问硬件寄存器,如果用户程序试图访问没有权限的硬件,会产生异常。这样用户程序被限制起来,如果用户程序想要使用硬件时怎么办呢?用户程序使用硬件时,必须调用操作系统提供的API接口才可以,而操作系统API接口通过软件中断方式切换到管理模式下,实现从用户模式下进入特权模式。

在3.16.57的内核中总共有382个系统调用

arch/arm/kernel/colls.S
/* 0 */		CALL(sys_restart_syscall)
		CALL(sys_exit)
		CALL(sys_fork)
		CALL(sys_read)
		CALL(sys_write)
/* 5 */		CALL(sys_open)
		CALL(sys_close)
		CALL(sys_ni_syscall)		/* was sys_waitpid */
		CALL(sys_creat)
		CALL(sys_link)

        ......

/* 375 */	CALL(sys_setns)
		CALL(sys_process_vm_readv)
		CALL(sys_process_vm_writev)
		CALL(sys_kcmp)
		CALL(sys_finit_module)
/* 380 */	CALL(sys_sched_setattr)
		CALL(sys_sched_getattr)
		CALL(sys_renameat2)

其中CALL的定义如下,可以看出是直接定义为代码段的某个地址了,方便数组下标索引,可以看到sys_open的偏移是5

#define CALL(x) .long x

 

EABI (Extended ABI)

CONFIG_OABI_COMPAT    //表示老的系统调用接口
CONFIG_AEABI          //新的系统调用接口

 

EABI ,说的是这样的一种新的系统调用方式

mov r7, #num

swi 0x0

原来的系统调用方式是这样,

swi (#num | 0x900000) (0x900000是个magic值)

也就是说原来的调用方式(Old ABI)是通过跟随在swi指令中的调用号来进行的,现在的是根据r7中的值。

现在看两个宏,一个是

CONFIG_OABI_COMPAT 意思是说和old ABI兼容

另一个是

CONFIG_AEABI 意思是说指定现在的方式为EABI

这两个宏可以同时配置,也可以都不配,也可以配置任何一种。

我说一下内核是怎么处理这一问题的。

我们知道,sys_call_table 在内核中是个跳转表,这个表中存储的是一系列的函数指针,这些指针就是系统调用函数的指针,如(sys_open).系统调用是根据一个调用号(通常就是表的索引)找到实际该调用内核哪个函数,然后运行该函数完成的。

首先,对于old ABI,内核给出的处理是给它建立一个单独的system calltable,叫sys_oabi_call_table,这样,兼容方式下就会有两个system call table, 以oldABI方式的系统调用会执行old_syscall_table表中的系统调用函数,EABI方式的系统调用会用sys_call_table中的函数指针

配置无外乎以下4中

第一 两个宏都配置 行为就是上面说的那样

第二 只配置CONFIG_OABI_COMPAT , 那么以old ABI方式调用的会用sys_oabi_call_table,以EABI方式调用的 用sys_call_table,和1实质相同,只是情况1更加明确。

第三 只配置CONFIG_AEABI 系统中不存在 sys_oabi_call_table, 对old ABI方式调用不兼容。只能 以EABI方式调用,用sys_call_table

第四 两个都没有配置 系统默认会只允许old ABI方式,但是不存在old_syscall_table,最终会通过sys_call_table 完成函数调用

 

 

用户空间如何让产生系统调用,即触发SWI异常

就看定义编译内核是默认是OABI还是EABI,可以看到新的EABI是r7传参方式

#ifndef CONFIG_CPU_THUMBONLY
#define ARM_OK(code...)	code        //正常都是这种
#else
#define ARM_OK(code...)
#endif


	.align

sigreturn_codes:

	/* ARM sigreturn syscall code snippet */
	arm_slot 0
ARM_OK(	mov	r7, #(__NR_sigreturn - __NR_SYSCALL_BASE)	)
ARM_OK(	swi	#(__NR_sigreturn)|(__NR_OABI_SYSCALL_BASE)	)

	/* Thumb sigreturn syscall code snippet */
	thumb_slot 0
	movs	r7, #(__NR_sigreturn - __NR_SYSCALL_BASE)
	swi	#0

	/* ARM sigreturn_rt syscall code snippet */
	arm_slot 1
ARM_OK(	mov	r7, #(__NR_rt_sigreturn - __NR_SYSCALL_BASE)	)
ARM_OK(	swi	#(__NR_rt_sigreturn)|(__NR_OABI_SYSCALL_BASE)	)

	/* Thumb sigreturn_rt syscall code snippet */
	thumb_slot 1
	movs	r7, #(__NR_rt_sigreturn - __NR_SYSCALL_BASE)
	swi	#0

 

 

 

通过上面的calls.S和下面两句可以知道,sys_call_table就是系统调用表的首地址。而#include "call.S"里面的内容在前面已经说明了,

就是以 .long sys_xxx   的函数的地址

	.type	sys_call_table, #object
ENTRY(sys_call_table)
#include "calls.S"

方然也有老的调用接口,但对里面的系统调用函数,明显都是一样的

	.type	sys_oabi_call_table, #object
ENTRY(sys_oabi_call_table)
#include "calls.S"

 

 

下面就是SWI异常处理函数的实现


/*=============================================================================
 * SWI handler
 *-----------------------------------------------------------------------------
 */

	.align	5
ENTRY(vector_swi)
#ifdef CONFIG_CPU_V7M
	v7m_exception_entry
#else
	sub	sp, sp, #S_FRAME_SIZE
	stmia	sp, {r0 - r12}			@ Calling r0 - r12
 ARM(	add	r8, sp, #S_PC		)
 ARM(	stmdb	r8, {sp, lr}^		)	@ Calling sp, lr
 THUMB(	mov	r8, sp			)
 THUMB(	store_user_sp_lr r8, r10, S_SP	)	@ calling sp, lr
	mrs	r8, spsr			@ called from non-FIQ mode, so ok.
	str	lr, [sp, #S_PC]			@ Save calling PC
	str	r8, [sp, #S_PSR]		@ Save CPSR
	str	r0, [sp, #S_OLD_R0]		@ Save OLD_R0
#endif
	zero_fp
	alignment_trap ip, __cr_alignment
	enable_irq
	ct_user_exit
	get_thread_info tsk

	/*
	 * Get the system call number.
	 */

#if defined(CONFIG_OABI_COMPAT)

	/*
	 * If we have CONFIG_OABI_COMPAT then we need to look at the swi
	 * value to determine if it is an EABI or an old ABI call.
	 */
#ifdef CONFIG_ARM_THUMB
	tst	r8, #PSR_T_BIT
	movne	r10, #0				@ no thumb OABI emulation
 USER(	ldreq	r10, [lr, #-4]		)	@ get SWI instruction
#else
 USER(	ldr	r10, [lr, #-4]		)	@ get SWI instruction
#endif
 ARM_BE8(rev	r10, r10)			@ little endian instruction

#elif defined(CONFIG_AEABI)

	/*
	 * Pure EABI user space always put syscall number into scno (r7).
	 */
#elif defined(CONFIG_ARM_THUMB)
	/* Legacy ABI only, possibly thumb mode. */
	tst	r8, #PSR_T_BIT			@ this is SPSR from save_user_regs
	addne	scno, r7, #__NR_SYSCALL_BASE	@ put OS number in
 USER(	ldreq	scno, [lr, #-4]		)

#else
	/* Legacy ABI only. */
 USER(	ldr	scno, [lr, #-4]		)	@ get SWI instruction
#endif

	adr	tbl, sys_call_table		@ load syscall table pointer

#if defined(CONFIG_OABI_COMPAT)
	/*
	 * If the swi argument is zero, this is an EABI call and we do nothing.
	 *
	 * If this is an old ABI call, get the syscall number into scno and
	 * get the old ABI syscall table address.
	 */
	bics	r10, r10, #0xff000000
	eorne	scno, r10, #__NR_OABI_SYSCALL_BASE
	ldrne	tbl, =sys_oabi_call_table
#elif !defined(CONFIG_AEABI)
	bic	scno, scno, #0xff000000		@ mask off SWI op-code
	eor	scno, scno, #__NR_SYSCALL_BASE	@ check OS number
#endif

local_restart:
	ldr	r10, [tsk, #TI_FLAGS]		@ check for syscall tracing
	stmdb	sp!, {r4, r5}			@ push fifth and sixth args

	tst	r10, #_TIF_SYSCALL_WORK		@ are we tracing syscalls?
	bne	__sys_trace

	cmp	scno, #NR_syscalls		@ check upper syscall limit
	adr	lr, BSYM(ret_fast_syscall)	@ return address
	ldrcc	pc, [tbl, scno, lsl #2]		@ call sys_* routine

	add	r1, sp, #S_OFF
2:	cmp	scno, #(__ARM_NR_BASE - __NR_SYSCALL_BASE)
	eor	r0, scno, #__NR_SYSCALL_BASE	@ put OS number back
	bcs	arm_syscall
	mov	why, #0				@ no longer a real syscall
	b	sys_ni_syscall			@ not private func

#if defined(CONFIG_OABI_COMPAT) || !defined(CONFIG_AEABI)
	/*
	 * We failed to handle a fault trying to access the page
	 * containing the swi instruction, but we're not really in a
	 * position to return -EFAULT. Instead, return back to the
	 * instruction and re-enter the user fault handling path trying
	 * to page it in. This will likely result in sending SEGV to the
	 * current task.
	 */
9001:
	sub	lr, lr, #4
	str	lr, [sp, #S_PC]
	b	ret_fast_syscall
#endif
ENDPROC(vector_swi)

 

真正的系统调用则是用过下面这个函数实现的。

asmlinkage long sys_open(const char __user *filename,
				int flags, umode_t mode);


SYSCALL_DEFINE3(open, const char __user *, filename, int, flags, umode_t, mode)
{
	if (force_o_largefile())
		flags |= O_LARGEFILE;

	return do_sys_open(AT_FDCWD, filename, flags, mode);
}



SYSCALL_DEFINE3是一个宏,可以自己解析一下,实际下面的两个是一样的
asmlinkage long sys_open(const char __user *filename,int flags, umode_t mode);
SYSCALL_DEFINE3(open, const char __user *, filename, int, flags, umode_t, mode);

 

 

 

对照上图,可以看到应用程序使用系统调用接口,需要从用户级切换到内核级。

方法是:通过SWI指令和寄存器传入参数,通过输入的swi中断号,直接以查表方式找到对应的系统调用函数。

以open一个led灯为例:

可以看到调用顺序依次是应用程序 open ->  swi软中断 -> 系统调用接口  -> sys_open  ->

文件子系统VFS中的open -> 驱动程序open  -> 硬件操作

 

其中应用程序空间的open需要通过swi指令来实现swi中断。

通过文件的属性(普通文件,设备文件),来不同的处理。

如果是设备文件,则继续通过属性查看是字符还是块设备文件,找到对应的驱动程序,最终操纵硬件。

 

相关推荐
©️2020 CSDN 皮肤主题: 技术黑板 设计师:CSDN官方博客 返回首页