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

简介: linux驱动开发之驱动基础

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

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

1.SWI指令格式如下:
20180827210530671.png
20180827210614325.png

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);

0_1322832443IQlL.jpg

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

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

以open一个led灯为例:

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

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

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

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

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

相关文章
|
2月前
|
Linux API 开发工具
FFmpeg开发笔记(五十九)Linux编译ijkplayer的Android平台so库
ijkplayer是由B站研发的移动端播放器,基于FFmpeg 3.4,支持Android和iOS。其源码托管于GitHub,截至2024年9月15日,获得了3.24万星标和0.81万分支,尽管已停止更新6年。本文档介绍了如何在Linux环境下编译ijkplayer的so库,以便在较新的开发环境中使用。首先需安装编译工具并调整/tmp分区大小,接着下载并安装Android SDK和NDK,最后下载ijkplayer源码并编译。详细步骤包括环境准备、工具安装及库编译等。更多FFmpeg开发知识可参考相关书籍。
114 0
FFmpeg开发笔记(五十九)Linux编译ijkplayer的Android平台so库
|
3月前
|
存储 Linux 开发工具
如何进行Linux内核开发【ChatGPT】
如何进行Linux内核开发【ChatGPT】
|
4月前
|
Java Linux API
Linux设备驱动开发详解2
Linux设备驱动开发详解
56 6
|
4月前
|
消息中间件 算法 Unix
Linux设备驱动开发详解1
Linux设备驱动开发详解
61 5
|
4月前
|
Ubuntu NoSQL Linux
Linux内核和驱动
Linux内核和驱动
39 2
|
4月前
|
数据采集 Linux
Linux源码阅读笔记20-PCI设备驱动详解
Linux源码阅读笔记20-PCI设备驱动详解
|
4月前
|
编解码 安全 Linux
基于arm64架构国产操作系统|Linux下的RTMP|RTSP低延时直播播放器开发探究
这段内容讲述了国产操作系统背景下,大牛直播SDK针对国产操作系统与Linux平台发布的RTMP/RTSP直播播放SDK。此SDK支持arm64架构,基于X协议输出视频,采用PulseAudio和Alsa Lib处理音频,具备实时静音、快照、缓冲时间设定等功能,并支持H.265编码格式。此外,提供了示例代码展示如何实现多实例播放器的创建与管理,包括窗口布局调整、事件监听、视频分辨率变化和实时快照回调等关键功能。这一技术实现有助于提高直播服务的稳定性和响应速度,适应国产操作系统在各行业中的应用需求。
143 3
|
3月前
|
Linux API
Linux里的高精度时间计时器(HPET)驱动 【ChatGPT】
Linux里的高精度时间计时器(HPET)驱动 【ChatGPT】
|
4月前
|
Linux
【linux】【驱动】<specifier>-map-pass-thru讲解
【linux】【驱动】<specifier>-map-pass-thru讲解
24 0
|
4月前
|
Linux
【linux】【驱动】phy接口类型
【linux】【驱动】phy接口类型
28 0