一arm-linux内核设备树来源
在过去的arm-linux内核源码树中arch/arm/plat-xxx和arch/arm/mach-xxx 等目录下边充斥着大量的垃圾代码，相当多数的代码只是在描述板级细节信息，而这些板级细节信息对于内核来说都是垃圾代码，比如板上的platform_device、resource、i2c_board_info、spi_board_info 以及各种硬件的platform_data.
为了改变这种局面，ARM 社区开始使用PowerPC 等其他体系架构下已经使用的Flattened Device Tree(FDT). Device Tree 是一种描述硬件的数据结构，它起源于OpenFirmware(OF). 采用Device Tree后，许多板级细节信息可以直接通过Device Tree传递给linux内核，而不需要在arch/arm/plat-xxx和arch/arm/mach-xxx中进行大量的冗余编码，内核启动时会展开Device Tree并创建和注册相关的设备(比如platform_device，i2c_client，spi_device)，同时驱动程序也会以新的方式和Devie Tree中定义的设备结点进行匹配. Device Tree的主要优势：对于相同SOC的不同板卡，只需更换设备树文件.dtb即可实现不同板卡的无差异支持
二arm-linux内核设备树简介
Device Tree由一系列被命名的结点(node)和属性(property)组成，而结点本身可包含子结点，所谓属性其实就是成对出现的name和value. 在Device Tree中可描述的细节信息包括
system runtime参数(主要设置bootargs)
cpu的数量和类别
memory基地址和大小(设置DDR内存)
总线控制器和桥
总线外设
内核基础设施使用情况，比如：
中断控制器和中断使用情况
DMA控制器和DMA使用情况
GPIO控制器和GPIO使用情况
CLOCK控制器和ClOCK使用情况
PINCTRL控制器和PINCTRL使用情况
从上述信息可知Device Tree并不能描述所有硬件信息，一般可以动态识别的设备(如usb设备，pci设备)是不需要设备树进行描述，它们是在设备热插拔时，由内核自动进行探测
设备树包含DTC(device tree compiler)、DTS(device tree source) 和DTB(device tree binary)，其对应关系如下图1所示：
图1
下面简单描述.dts文件.dtb文件和DTC
.dts文件是一种ASCII文本文件，放置在arch/arm/boot/dts目录.由于每个SOC可能有多个不同的电路板，每个电路板都有一个 .dts
文件，这些.dts文件势必会存在许多共同部分，Linux 内核为了简化，把SOC公用的部分或者多个machine 共同的部分保存到.dtsi文件中，供不同的.dts文件引用. 例如vexpress-v2f.dts引用了vexpress-v2.dtsi，此时vexpress-v2f.dts中会有如下行：#include "vexpress-v2.dtsi"，告诉编译器vexpress-v2f.dts需要引用vexpress-v2.dtsi. 类似于C语言的头文件，.dtsi 也可以include 其他的.dtsi，例如几乎所有ARM SOC
的.dtsi 都引用了skeleton.dtsi
DTC为编译工具，它可以将.dts文件编译成.dtb文件，DTC的源码位于scripts/dtc目录，在内核arch/arm/boot/dts/Makefile 中，描述了某个SOC 被选中后，哪些.dtb文件会被编译出来，例如与VEXPRESS 对应的.dtb 包括：
dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2o.dtb \
vexpress-v2p.dtb \
vexpress-v2q.dtb \
vexpress-v2f.dtb
从上述Makefile可知，若选择CONFIG_ARCH_VEXPRESS，上述.dtb 文件，都会从对应的.dts文件编译生成
bootloader在引导内核时，会预先读取.dtb文件到内存，进而由内核解析
三arm-linux内核设备树语法
下面以最简单的machine 为例来看如何编写.dts 文件，假设此machine 的配置如下：
双核ARM Cortex-A9处理器
2 个串口(分别位于0x101F1000和0x101F2000)
GPIO 控制器(位于0x101F3000)
SPI 控制器(位于0x101F4000)
I2C 控制器(位于0x101F5000)
I2C 控制器连接了maxim DS1338 实时钟(i2c地址为0x58)
中断控制器(位于0x10100000)
图2
上图2即一个简单的设备树，下面着重分析相关概念
compatible属性.dts文件的每个设备结点，都有一个compatible属性，该属性用来决定device_driver和device的相互匹配. compatible是一个字符串列表，列表的第一个字符串表征了结点所代表的确切设备，该字符串的组织形式为：“<制造商>，<型号>”，其后的字符串则表示与它兼容的设备. 如上图2所示串口设备的compatible属性为：“ti，omap4-uart”，表示该设备节点是omap4芯片的串口设备
再比如飞思卡尔mpc8349芯片拥有一个兼容美国国家半导体ns16550的串口设备，那么该串口设备的compatible属性应该是：
compatible = “fsl，mpc8349-uart”，“nsl16550”，其中mpc8349-uart指定了确切的设备，而nsl16550则说明与美国国家半导体的nsl16550 UART保持了寄存器兼容
注意：nsl16550没有制造商前缀，这是历史原因造成的，这种做法可以使现有驱动程序能够兼容新的设备，并仍然能够表征确切的设备. 记住以后compatible属性都应该使用这种形式：“<制造商>，<型号>”root结点compatible = “ti，omap4430”它定义了系统名称，linux内核通过root结点compatible属性来匹配machine type
cpu结点compatible = “arm，cortex-a9”它为machine指定了确切的cpu型号
从上可知，不论是root结点还是普通设备结点，它们都存在compatible 属性，而且组织形式都是：“<制造商>，<型号>”
结点名称每个结点必须有“name@0x20000000”形式的名称，其中name是一个不超过31位的ASCII字符串，0x20000000是设备地址，用来访问设备的主地址. 结点名称应该描述设备类型而不是特定的型号，比如3com公司的ethernet适配器对应的结点名称应该是ethernet而不是3com509. 同级结点名称必须是唯一的，当然设备地址不同，多个结点也可以使用相同的名称，比如serial@0x101f1000和serial@0x101f2000，设备地址是用来访问设备的主地址，并且该地址也在结点的reg属性中列出.
label用来唯一标识一个结点，定义label使得引用结点变得简单，只要以&label的形式就可以访问该结点，而不需要使用全路径的形式访问该结点.
图3
上图5定义了两个label，如下所示
标签mmc0表示结点/mmc@50001000
标签mmc1表示结点/mmc@50002000
通过&mmc0访问结点/mmc@50001000，将其status属性置为disable，使得/mmc@50001000处于disable状态
通过&mmc1访问结点/mmc@50002000，将其status属性置为okay，使得/mmc@50002000处于enable状态.
注意：label习惯以<设备类型>
设备树习惯以property = <&label>方式使用label
Linux设备驱动程序设计实例2007-03-03 23:09 Linux系统中，设备驱动程序是操作系统内核的重要组成部分，在与硬件设备之间 建立了标准的抽象接口。通过这个接口，用户可以像处理普通文件一样，对硬件设 备进行打开(open)、关闭(close)、读写(read/write)等操作。通过分析和设计设 备驱动程序，可以深入理解Linux系统和进行系统开发。本文通过一个简单的例子 来说明设备驱动程序的设计。 1、程序清单 //MyDev.c 2000年2月7日编写 #ifndef __KERNEL__ #define __KERNEL__//按内核模块编译 #endif #ifndef MODULE #define MODULE//设备驱动程序模块编译 #endif #define DEVICE_NAME "MyDev" #define OPENSPK 1 #define CLOSESPK 2 //必要的头文件 #include
实现如下的功能: --字符设备驱动程序的结构及驱动程序需要实现的系统调用 --可以使用cat命令或者自编的readtest命令读出"设备"里的内容 --以8139网卡为例,演示了I/O端口和I/O内存的使用 本文中的大部分内容在Linux Device Driver这本书中都可以找到, 这本书是Linux驱动开发者的唯一圣经。 ================================================== ===== 先来看看整个驱动程序的入口,是char8139_init(这个函数 如果不指定MODULE_LICENSE("GPL", 在模块插入内核的 时候会出错,因为将非"GPL"的模块插入内核就沾污了内核的 "GPL"属性。 module_init(char8139_init; module_exit(char8139_exit; MODULE_LICENSE("GPL"; MODULE_AUTHOR("ypixunil"; MODULE_DESCRIPTION("Wierd char device driver for Realtek 8139 NIC"; 接着往下看char8139_init( static int __init char8139_init(void {
int result; PDBG("hello. init.\n"; /* register our char device */ result=register_chrdev(char8139_major, "char8139", &char8139_fops; if(result<0 { PDBG("Cannot allocate major device number!\n"; return result; } /* register_chrdev( will assign a major device number and return if it called * with "major" parameter set to 0 */ if(char8139_major == 0 char8139_major=result; /* allocate some kernel memory we need */ buffer=(unsigned char*(kmalloc(CHAR8139_BUFFER_SIZE, GFP_KERNEL; if(!buffer { PDBG("Cannot allocate memory!\n"; result= -ENOMEM;
Linux设备驱动程序学习（18）－USB 驱动程序（三） (2009-07-14 11:45) 分类：Linux设备驱动程序 USB urb （USB request block） 内核使用2.6.29.4 USB 设备驱动代码通过urb和所有的 USB 设备通讯。urb用 struct urb 结构描述（include/linux/usb.h ）。 urb以一种异步的方式同一个特定USB设备的特定端点发送或接受数据。一个USB 设备驱动可根据驱动的需要，分配多个 urb 给一个端点或重用单个 urb 给多个不同的端点。设备中的每个端点都处理一个 urb 队列, 所以多个 urb 可在队列清空之前被发送到相同的端点。 一个 urb 的典型生命循环如下: （1）被创建； （2）被分配给一个特定 USB 设备的特定端点； （3）被提交给 USB 核心； （4）被 USB 核心提交给特定设备的特定 USB 主机控制器驱动； （5）被 USB 主机控制器驱动处理, 并传送到设备； （6）以上操作完成后，USB主机控制器驱动通知 USB 设备驱动。 urb 也可被提交它的驱动在任何时间取消；如果设备被移除，urb 可以被USB 核心取消。urb 被动态创建并包含一个内部引用计数，使它们可以在最后一个用户释放它们时被自动释放。 struct urb
struct list_head urb_list;/* list head for use by the urb's * current owner */ struct list_head anchor_list;/* the URB may be anchored */ struct usb_anchor *anchor; struct usb_device *dev;/* 指向这个 urb 要发送的目标 struct usb_device 的指针,这个变量必须在这个 urb 被发送到 USB 核心之前被USB 驱动初始化.*/ struct usb_host_endpoint *ep;/* (internal) pointer to endpoint */ unsigned int pipe;/* 这个 urb 所要发送到的特定struct usb_device 的端点消息,这个变量必须在这个 urb 被发送到 USB 核心之前被 USB 驱动初始化.必须由下面的函数生成*/ int status;/*当 urb开始由 USB 核心处理或处理结束, 这个变量被设置为 urb 的当前状态. USB 驱动可安全访问这个变量的唯一时间是在 urb 结束处理例程函数中. 这个限制是为防止竞态. 对于等时 urb, 在这个变量中成功值(0)只表示这个 urb 是否已被去链. 为获得等时 urb 的详细状态, 应当检查 iso_frame_desc 变量. */ unsigned int transfer_flags;/* 传输设置*/ void*transfer_buffer;/* 指向用于发送数据到设备(OUT urb)或者从设备接收数据(IN urb)的缓冲区指针。为了主机控制器驱动正确访问这个缓冲, 它必须使用 kmalloc 调用来创建, 不是在堆栈或者静态内存中。对控制端点, 这个缓冲区用于数据中转*/ dma_addr_t transfer_dma;/* 用于以 DMA 方式传送数据到 USB 设备的缓冲区*/ int transfer_buffer_length;/* transfer_buffer 或者 transfer_dma 变量指向的缓冲区大小。如果这是 0, 传送缓冲没有被 USB 核心所使用。对于一个 OUT 端点, 如果这个端点大小比这个变量指定的值小, 对这个USB 设备的传输将被分成更小的块，以正确地传送数据。这种大的传送以连续的 USB 帧进行。在一个 urb 中提交一个大块数据, 并且使 USB 主机控制器去划分为更小的块, 比以连续地顺序发送小缓冲的速度快得多*/
Linux2.6设备驱动常用的接口函数（一） ----字符设备 刚开始，学习linux驱动，觉得linux驱动很难，有字符设备，块设备，网络设备，针对每一种设备其接口函数，驱动的架构都不一样。这么多函数，要每一个的熟悉，那可多难啦！可后来发现linux驱动有很多规律可循，驱动的基本框架都差不多，再就是一些通用的模块。 基本的架构里包括：加载，卸载，常用的读写，打开，关闭，这是那种那基本的咯。利用这些基本的功能，当然无法实现一个系统。比方说：当多个执行单元对资源进行访问时，会引发竞态；当执行单元获取不到资源时，它是阻塞还是非阻塞？当突然间来了中断，该怎么办？还有内存管理，异步通知。而linux 针对这些问题提供了一系列的接口函数和模板框架。这样，在实际驱动设计中，根据具体的要求，选择不同的模块来实现其功能需求。 觉得能熟练理解，运用这些函数，是写号linux设备驱动的第一步。因为是设备驱动，是与最底层的设备打交道，就必须要熟悉底层设备的一些特性，例如字符设备，块设备等。系统提供的接口函数，功能模块就像是工具，能够根据不同的底层设备的的一些特性，选择不同的工具，方能在linux驱动中游刃有余。 最后就是调试，这可是最头疼的事。在调试过程中，总会遇到这样，那样的问题。怎样能更快，更好的发现并解决这些问题，就是一个人的道行咯！我个人觉得： 发现问题比解决问题更难！ 时好时坏的东西，最纠结！ 看得见的错误比看不见的错误好解决！ 一：Fops结构体中函数： ①ssize_t (*read) (struct file *, char __user *, size_t, loff_t *); 用来从设备中获取数据. 在这个位置的一个空指针导致 read 系统调用以-EINVAL("Invalid argument") 失败. 一个非负返回值代表了成功读取的字节数( 返回值是一个 "signed size" 类型, 常常是目标平台本地的整数类型). ②ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *); 发送数据给设备. 如果 NULL, -EINVAL 返回给调用 write 系统调用的程序. 如果非负, 返回值代表成功写的字节数 ③loff_t (*llseek) (struct file *, loff_t, int); llseek 方法用作改变文件中的当前读/写位置, 并且新位置作为(正的)返回值. loff_t 参数是一个"long offset", 并且就算在 32位平台上也至少 64 位宽. 错误由一个负返回值指示. 如果这个函数指针是 NULL, seek 调用会以潜在地无法预知的方式修改 file 结构中的位置计数器( 在"file 结构" 一节中描述). ④int (*open) (struct inode *, struct file *);
Linux设备驱动模型之platform总线深入浅出 在Linux2.6以后的设备驱动模型中，需关心总线，设备和驱动这三种实体，总线将设备和驱动绑定。在系统每注册一个设备的时候，会寻找与之匹配的驱动；相反，在系统每注册一个驱动的时候，会寻找与之匹配的设备，而匹配由总线完成。 对于依附在USB、PCI、I2C、SPI等物理总线来这些都不是问题。但是在嵌入式系统里面，在Soc系统中集成的独立外设控制器，挂接在Soc内存空间的外设等却不依附在此类总线。基于这一背景，Linux发明了一种总线，称为platform。相对于USB、PCI、I2C、SPI等物理总线来说，platform总线是一种虚拟、抽象出来的总线，实际中并不存在这样的总线。 platform总线相关代码：driver\base\platform.c 文件相关结构体定义：include\linux\platform_device.h 文件中 platform总线管理下最重要的两个结构体是platform_device和platform_driver 分别表示设备和驱动在Linux中的定义如下一：platform_driver //include\linux\platform_device.h struct platform_driver { int (*probe)(struct platform_device *); //探测函数，在注册平台设备时被调用int (*remove)(struct platform_device *); //删除函数，在注销平台设备时被调用void (*shutdown)(struct platform_device *); int (*suspend)(struct platform_device *, pm_message_t state); //挂起函数，在关机被调用int (*suspend_late)(struct platform_device *, pm_message_t state); int (*resume_early)(struct platform_device *); int (*resume)(struct platform_device *);//恢复函数，在开机时被调用struct device_driver driver;//设备驱动结构}; 1 2 3 4 5 6 7 8
以下电子书来源于宋宝华《Linux设备驱动开发详解：基于最新的Linux 4.0内核》第19章《Linux电源管理系统架构和驱动》 本章导读 Linux在消费电子领域的应用已经铺天盖地，而对于消费电子产品而言，省电是一个重要的议题。 本章将介绍Linux设备树（Device Tree）的起源、结构和因为设备树而引起的驱动和BSP 变更。 19.1节阐述了Linux电源管理的总体架构。 19.2~19.8节分别论述了CPUFreq、CPUIdle、CPU热插拔以及底层的基础设施Regulator、OPP以及电源管理的调试工具PowerTop。 19.9节讲解了系统Suspend to RAM的过程以及设备驱动如何提供对Suspend to RAM的支持。 19.10节讲解了设备驱动的Runtime suspend。 本章是相对《Linux设备驱动开发详解（第2版）》全新的一章内容，也是Linux设备驱动工程师必备的知识体系。
第十九章Linux电源管理系统架构和驱动 1.Linux电源管理全局架构 Linux电源管理非常复杂，牵扯到系统级的待机、频率电压变换、系统空闲时的处理以及每个设备驱动对于系统待机的支持和每个设备的运行时电源管理，可以说和系统中的每个设备驱动都息息相关。 对于消费电子产品来说，电源管理相当重要。因此，这部分工作往往在开发周期中占据相当大的比重，图19.1呈现了Linux内核电源管理的整体架构。大体可以归纳为如下几类： 1.CPU在运行时根据系统负载进行动态电压和频率变换的CPUFreq 2.CPU在系统空闲时根据空闲的情况进行低功耗模式的CPUIdle 3.多核系统下CPU的热插拔支持 4.系统和设备对于延迟的特别需求而提出申请的PM QoS，它会作用于CPUIdle的具体 策略 5.设备驱动针对系统Suspend to RAM/Disk的一系列入口函数 6.SoC进入suspend状态、SDRAM自刷新的入口 7.设备的runtime（运行时）动态电源管理，根据使用情况动态开关设备 8.底层的时钟、稳压器、频率/电压表（OPP模块完成）支撑，各驱动子系统都可能用 到 图19.1 Linux电源管理系统架构 2.CPUFreq驱动 CPUFreq子系统位于drivers/cpufreq目录，负责进行运行过程中CPU频率和电压的动态
Linux设备驱动程序学习（20）-内存映射和DMA-基本概念 (2011-09-25 15:47) 标签: 虚拟内存设备驱动程序Linux技术分类：Linux设备驱动程序 这部分主要研究 Linux 内存管理的基础知识, 重点在于对设备驱动有用的技术. 因为许多驱动编程需要一些对于虚拟内存（VM）子系统原理的理解。 而这些知识主要分为三个部分： 1、 mmap系统调用的实现原理：它允许设备内存直接映射到一个用户进程地址 空间. 这样做对一些设备来说可显著地提高性能. 2、与mmap的功能相反的应用原理：内核态代码如何跨过边界直接存取用户空间的内存页. 虽然较少驱动需要这个能力. 但是了解如何映射用户空间内存到内 核(使用 get_user_pages)会有用. 3、直接内存存取( DMA ) I/O 操作, 它提供给外设对系统内存的直接存取. 但所有这些技术需要理解 Linux 内存管理的基本原理, 因此我将先学习VM子 系统的基本原理. 一、Linux的内存管理 这里重点是 Linux 内存管理实现的主要特点，而不是描述操作系统的内存管理理论。Linux虚拟内存管理非常的复杂，要写可以写一本书：《深入理解Linux 虚拟内存管理》。学习驱动无须如此深入, 但是对它的工作原理的基本了解是必要的. 解了必要的背景知识后,才可以学习内核管理内存的数据结构. Linux是一个虚拟内存系统（但是在没有MMU的CPU中跑的ucLinux除外）, 意味着在内核启动了MMU 之后所有使用的地址不直接对应于硬件使用的物理地址，这些地址（称之为虚拟地址）都经过了MMU转换为物理地址之后再从CPU的内存总线中发出，读取/写入数据. 这样 VM 就引入了一个间接层, 它是许多操作成为可能： 1、系统中运行的程序可以分配远多于物理内存的内存空间，即便单个进程都可拥有一个大于系统的物理内存的虚拟地址空间. 2、虚拟内存也允许程序对进程的地址空间运用多种技巧, 包括映射程序的内存到设备内存.等等～～～ 1、地址类型 Linux 系统处理几种类型的地址, 每个有它自己的含义： 用户虚拟地址：User virtual addresses，用户程序见到的常规地址. 用户地址在长度上是 32 位或者 64 位, 依赖底层的硬件结构, 并且每个进程有它自己 的虚拟地址空间.
参考： 韦东山视频第10课第一节内核启动流程分析之编译体验 第11课第三节构建根文件系统之busybox 第11课第四节构建根文件系统之构建根文件系统韦东山书籍《嵌入式linux应用开发完全手册》 其他《linux设备驱动程序》第三版 平台： JZ2440、mini2440或TQ2440 交叉网线和miniUSB PC机（windows系统和Vmware下的ubuntu12.04） 一、交叉编译环境的选型 具体的安装交叉编译工具，网上很多资料都有，我的那篇《arm-linux- gcc交叉环境相关知识》也有介绍，这里我只是想提示大家：构建跟文件系统中所用到的lib库一定要是本系统Ubuntu中的交叉编译环境arm-linux- gcc中的。即如果电脑ubuntu中的交叉编译环境为arm-linux-
二、主机、开发板和虚拟机要三者互通 w IP v2.0》一文中有详细的操作步骤，不再赘述。 linux 2.6.22.6_jz2440.patch组合而来，具体操作： 1. 解压缩内核和其补丁包 tar xjvf linux-2.6.22.6.tar.bz2 # 解压内核 tar xjvf linux-2.6.22.6_jz2440.tar.bz2 # 解压补丁
cd linux_2.6.22.6 patch –p1 < ../linux-2.6.22.6_jz2440.patch 3. 配置 在内核目录下执行make 2410_defconfig生成配置菜单，至于怎么配置，《嵌入式linux应用开发完全手册》有详细介绍。 4. 生成uImage make uImage 四、移植busybox 在我们的根文件系统中的/bin和/sbin目录下有各种命令的应用程序，而这些程序在嵌入式系统中都是通过busybox来构建的，每一个命令实际上都是一个指向bu sybox的链接,busybox通过传入的参数来决定进行何种命令操作。 1）配置busybox 解压busybox-1.7.0,然后进入该目录，使用make menuconfig进行配置。这里我们这配置两项 一是在编译选项选择动态库编译，当然你也可以选择静态，不过那样构建的根文件系统会比动态编译的的大。 ->Busybox Settings ->Build Options
第一章Linux设备驱动程序简介 Linux Kernel 系统架构图 一、驱动程序的特点 ?是应用和硬件设备之间的一个软件层。 ?这个软件层一般在内核中实现 ?设备驱动程序的作用在于提供机制，而不是提供策略，编写访问硬件的内核代码时不要给用户强加任何策略 o机制：驱动程序能实现什么功能。 o策略：用户如何使用这些功能。 二、设备驱动分类和内核模块 ?设备驱动类型。Linux 系统将设备驱动分成三种类型 o字符设备 o块设备 o网络设备 ?内核模块：内核模块是内核提供的一种可以动态加载功能单元来扩展内核功能的机制，类似于软件中的插件机制。这种功能单元叫内核模块。 ?通常为每个驱动创建一个不同的模块，而不在一个模块中实现多个设备驱动，从而实现良好的伸缩性和扩展性。 三、字符设备 ?字符设备是个能够象字节流<比如文件）一样访问的设备，由字符设备驱动程序来实现这种特性。通过/dev下的字符设备文件来访问。字符设备驱动程序通常至少需要实现 open、close、read 和 write 等系统调用 所对应的对该硬件进行操作的功能函数。 ?应用程序调用system call<系统调用），例如：read、write，将会导致操作系统执行上层功能组件的代码，这些代码会处理内核的一些内部 事务，为操作硬件做好准备，然后就会调用驱动程序中实现的对硬件进 行物理操作的函数，从而完成对硬件的驱动，然后返回操作系统上层功 能组件的代码，做好内核内部的善后事务，最后返回应用程序。 ?由于应用程序必须使用/dev目录下的设备文件<参见open调用的第1个参数），所以该设备文件必须事先创建。谁创建设备文件呢？ ?大多数字符设备是个只能顺序访问的数据通道，不能前后移动访问指针，这点和文件不同。比如串口驱动，只能顺序的读写设备。然而，也 存在和数据区或者文件特性类似的字符设备，访问它们时可前后移动访
文库资料?2017 Guangzhou ZHIYUAN Electronics Stock Co., Ltd. 如何实现Linux 设备驱动模型 设备驱动模型，对系统的所有设备和驱动进行了抽象，形成了复杂的设备树型结构，采用面向对象的方法，抽象出了device 设备、driver 驱动、bus 总线和class 类等概念，所有已经注册的设备和驱动都挂在总线上，总线来完成设备和驱动之间的匹配。总线、设备、驱动以及类之间的关系错综复杂，在Linux 内核中通过kobject 、kset 和subsys 来进行管理，驱动编写可以忽略这些管理机制的具体实现。 设备驱动模型的内部结构还在不停的发生改变，如device 、driver 、bus 等数据结构在不同版本都有差异，但是基于设备驱动模型编程的结构基本还是统一的。 Linux 设备驱动模型是Linux 驱动编程的高级内容，这一节只对device 、driver 等这些基本概念作介绍，便于阅读和理解内核中的代码。实际上，具体驱动也不会孤立的使用这些概念，这些概念都融合在更高层的驱动子系统中。对于大多数读者可以忽略这一节内容。 1.1.1 设备 在Linux 设备驱动模型中，底层用device 结构来描述所管理的设备。device 结构在文件
Linux设备驱动程序学习（10）-时间、延迟及延缓操作 Linux设备驱动程序学习（10） -时间、延迟及延缓操作 度量时间差 时钟中断由系统定时硬件以周期性的间隔产生，这个间隔由内核根据HZ 值来设定，HZ 是一个体系依赖的值，在
的.config文件中定义，并没有在make menuconfig的配置选项中出现。Linux的\arch\arm\configs\s3c2410_defconfig文件中的定义为： 所以正常情况下s3c24x0的HZ为200。这一数值在后面的实验中可以证实。 每次发生一个时钟中断，内核内部计数器的值就加一。这个计数器在系统启动时初始化为0，因此它代表本次系统启动以来的时钟嘀哒数。这个计数器是一个64-位变量( 即便在32-位的体系上)并且称为“jiffies_64”。但是驱动通常访问jiffies 变量（unsigned long）（根据体系结构的不同：可能是jiffies_64 ，可能是jiffies_64 的低32位）。使用jiffies 是首选，因为它访问更快，且无需在所有的体系上实现原子地访问64-位的jiffies_64 值。 使用jiffies 计数器 这个计数器和用来读取它的工具函数包含在
Linux设备驱动 操作系统的目的之一就是将系统硬件设备细节从用户视线中隐藏起来。例如虚拟文件系统对各种类型已安装的文件系统提供了统一的视图而屏蔽了具体底层细节。本章将描叙Linux核心对系统中物理设备的管理。 CPU并不是系统中唯一的智能设备，每个物理设备都拥有自己的控制器。键盘、鼠标和串行口由一个高级I/O芯片统一管理，IDE控制器控制IDE硬盘而SCSI控制器控制SCSI硬盘等等。每个硬件控制器都有各自的控制和状态寄存器(CSR)并且各不相同。例如Adaptec 2940 SCSI控制器的CSR与NCR 810 SCSI控制器完全不一样。这些CSR被用来启动和停止，初始化设备及对设备进行诊断。在Linux中管理硬件设备控制器的代码并没有放置在每个应用程序中而是由内核统一管理。这些处理和管理硬件控制器的软件就是设备驱动。Linux 核心设备驱动是一组运行在特权级上的内存驻留底层硬件处理共享库。正是它们负责管理各个设备。 设备驱动的一个基本特征是设备处理的抽象概念。所有硬件设备都被看成普通文件；可以通过和操纵普通文件相同的标准系统调用来打开、关闭、读取和写入设备。系统中每个设备都用一种特殊的设备相关文件来表示(device special file)，例如系统中第一个IDE硬盘被表示成/dev/hda。块(磁盘)设备和字符设备的设备相关文件可以通过mknod命令来创建，并使用主从设备号来描叙此设备。网络设备也用设备相关文件来表示，但Linux寻找和初始化网络设备时才建立这种文件。由同一个设备驱动控制的所有设备具有相同的主设备号。从设备号则被用来区分具有相同主设备号且由相同设备驱动控制的不同设备。例如主IDE硬盘的每个分区的从设备号都不相同。如/dev/hda2表示主IDE 硬盘的主设备号为3而从设备号为2。Linux通过使用主从设备号将包含在系统调用中的(如将一个文件系统mount到一个块设备)设备相关文件映射到设备的设备驱动以及大量系统表格中，如字符设备表，chrdevs。 Linux支持三类硬件设备：字符、块及网络设备。字符设备指那些无需缓冲直接读写的设备，如系统的串口设备/dev/cua0和/dev/cua1。块设备则仅能以块为单位读写，典型的块大小为512或1024字节。块设备的存取是通过
Linux设备驱动程序简介 Linux是Unix操作系统的一种变种，在Linux下编写驱动程序的原理和思想完全类似于其他的Unix系统，但它dos或window环境下的驱动程序有很大的区别。在Linux环境下设计驱动程序，思想简洁，操作方便，功能也很强大，但是支持函数少，只能依赖kernel 中的函数，有些常用的操作要自己来编写，而且调试也不方便。本人这几周来为实验室自行研制的一块多媒体卡编制了驱动程序，获得了一些经验，愿与Linux fans共享，有不当之处，请予指正。 以下的一些文字主要来源于khg，johnsonm的Write linux device driver，Brennan's Guide to Inline Assembly，The Linux A-Z，还有清华BBS上的有关device driver的一些资料. 这些资料有的已经过时，有的还有一些错误，我依据自己的试验结果进行了修正. 一、Linux device driver 的概念 系统调用是操作系统内核和应用程序之间的接口，设备驱动程序是操作系统内核和机器硬件之间的接口.设备驱动程序为应用程序屏蔽了硬件的细节，这样在应用程序看来，硬件设备只是一个设备文件，应用程序可以象操作普通文件一样对硬件设备进行操作.设备驱动程序是内核的一部分，它完成以下的功能: 1.对设备初始化和释放. 2.把数据从内核传送到硬件和从硬件读取数据. 3.读取应用程序传送给设备文件的数据和回送应用程序请求的数据. 4.检测和处理设备出现的错误. 在Linux操作系统下有两类主要的设备文件类型，一种是字符设备，另一种是块设备.字符设备和块设备的主要区别是:在对字符设备发出读/写请求时，实际的硬件I/O一般就紧接着发生了，块设备则不然，它利用一块系统内存作缓冲区，当用户进程对设备请求能满足用户的要求，就返回请求的数据，如果不能，就调用请求函数来进行实际的I/O操作.块设备是主要针对磁盘等慢速设备设计的，以免耗费过多的CPU时间来等待. 已经提到，用户进程是通过设备文件来与实际的硬件打交道.每个设备文件都都有其文件属性(c/b)，表示是字符设备还蔤强樯璞?另外每个文件都有两个设备号，第一个是主设备号，标识驱动程序，第二个是从设备号，标识使用同一个设备驱动程序的不同的硬件设备，比如有两个软盘，就可以用从设备号来区分他们.设备文件的的主设备号必须与设备驱动程序在登记时申请的主设备号一致，否则用户进程将无法访问到驱动程序. 最后必须提到的是，在用户进程调用驱动程序时，系统进入核心态，这时不再是抢先式调度.也就是说，系统必须在你的驱动程序的子函数返回后才能进行其他的工作.如果你的驱动程序陷入死循环，不幸的是你只有重新启动机器了，然后就是漫长的fsck. 读/写时，它首先察看缓冲区的内容，如果缓冲区的数据 如何编写Linux操作系统下的设备驱动程序 二、实例剖析 我们来写一个最简单的字符设备驱动程序。虽然它什么也不做，但是通过它可以了解Linux的设备驱动程序的工作原理.把下面的C代码输入机器，你就会获得一个真正的设备驱动程序.不过我的kernel是2.0.34，在低版本的kernel上可能会出现问题，我还没测试过. [code]#define __NO_VERSION__
《LINUX设备驱动程序》阅读笔记 目录 第1章：设备驱动程序简介 (1) 第2章：构造和运行模块 (1) 第3章：字符设备驱动程序 (1) 第4章：调试技术 (2) 第5章：并发和竞态 (2) 第6章：高级字符驱动程序操作 (3) 第7章：时间、延迟及延缓操作 (3) 第8章：分配内存 (3) 第9章：与硬件通信 (4) 第10章：中断处理 (4) 第11章：内核的数据类型 (4) 第12章：PCI 驱动程序 (5) 第13章：USB 驱动程序 (5) 第14章：Linux 设备模型 (5) 第15章：内存映射和 DMA (5) 第16章：块设备驱动程序 (6) 第17章：网络驱动程序 (6) 第18章：TTY 驱动程序 (6) 第1章：设备驱动程序简介 1、“通常，设备驱动程序就是这个进入Linux内核世界的大门”，“设备驱动程序在Linux 内核中扮演着特殊的角色，它们是一个个独立的黑盒子，使某个特定硬件响应一个定义良好的内部编程接口，这些接口完全隐藏了设备的工作细节。用户的操作通过一组标准化的调用执行，而这些调用独立于特定的驱动程序”。 2、Linux系统将设备分成三种基本类型：字符设备、块设备和网络设备。 第2章：构造和运行模块 1、“内核黑客通常拥有一个‘牺牲用的’系统，用于测试新的代码”。 2、模块在被使用之前需要注册，而退出时要仔细撤销初始化函数所做的一切。驱动模块只能调用由内核导出的那些函数。 3、公共内核符号表中包含了所有的全局内核项（即函数和变量）的地址。当模块被装入内核后，它所导出的任何符号都会变成内核符号表的一部分。 第3章：字符设备驱动程序 第一节-主设备号和次设备号。对字符设备的访问都是通过文件系统内的设备名称进行的。通常而言，主设备号标识设备对应的驱动程序，而次设备号用于正确确定设备文件所指的设备。对应的数据结构为dev_t 类型。分配设备号使用函数alloc_chrdev_region() ，释放就使用unregister_chrdev_region() 函数。 第二节-一些重要的数据结构。大部分基本的驱动程序的操作都要涉及到三个重要的内
第1章Linux内核简介 世界各地都有人在钻研Linux内核，大多是在写设备驱动程序。尽管每个驱动程序都不一样，而且你还要知道自己设备的特殊性，但是这些设备驱动程序的许多原则和基本技术技巧都是一样的。通过本书，可以学会写自己的设备驱动程序，并且可以钻研内核的相关部分。本书涉及到的是设备无关编程技巧，不会将例子跟特殊设备绑定在一起。 本章没有实际编写代码。但我要介绍一些关于Linux内核的背景概念，这样到我们稍后开始介绍实际编程时，就很顺利了。 当你学习编写驱动程序的时候，你也会发现很多关于Linux内核的知识，这对理解你机器怎么工作很有帮助，并且还可以知道为什么你的机器没有希望的那么快，或者为什么不按照你象要它做的那样做。我们会逐渐介绍一些新概念，先从简单的驱动程序开始，每介绍一些新概念都会看到相关例子代码，这些代码都不需要特殊硬件。 驱动程序作者的作用 作为一个程序员，你可以选择自己的驱动程序，在编程所需时间和结果的灵活性之间做个可以接受的权衡。尽管说驱动程序的灵活性看起来有那么点怪，我喜欢这个词是因为它强调了设备驱动程序提供的是机制，而不是策略。 机制和策略之间的差别是Unix设计背后最好的点子之一。实际编程中遇到的大多数问题都可以被划分成两个部分：“需要作什么”（机制）和“这个程序怎么用”（策略）。如果这两个主题是由程序不同部分来承担的，或者是由不同的程序组合一起承担的，那么这个软件包就很容易开发，也很适合特殊需求。 举个例子，Unix的图形显示管理在X服务器和窗口管理器之间划了一道线，X服务器了解硬件并给用户程序提供唯一的接口，而窗口管理器实现特殊的策略并不需要知道硬件的任何信息。人们可以在不同硬件上使用同样的窗口管理器，并且不同用户在同一台工作站上可以使用不同的设置。另一个例子是TCP/IP的网络分层结构：操作系统提供抽象的套接字操作，是设备无关的，不同服务器主管这个服务。另外，ftpd服务器提供文件传输机制，而用户可以使用任何客户端程序；命令行的客户端和图形化界面的客户端都存在，并且谁都可以为传输文件写一个新的用户界面。 只要涉及到驱动程序，就会运用这样的功能划分。软盘驱动程序是设备无关的——这不仅表现在磁盘是一个连续读写的字节数组上。如何使用设备是应用程序要做的事：tar要连续地写数据，而mkfs则为要安装的设备做准备工作，mcopy依赖于设备上存在的特殊数据结构。在写驱动程序时，程序员应该特别留心这样的基本问题：我们要写内核代码访问硬件，但由于不同用户有不同需要，我们不能强迫用户采用什么样的特定策略。设备驱动程序应该仅仅处理硬件，将如何使用硬件的问题留给应用程序。如果在提供获得硬件能力的同时没有增加限制，我们就说驱动程序是灵活的。不过，有时必须要作一些策略决策。 可以从不同侧面来看你的驱动程序：它是位于应用层和实际设备之间的软件。驱动程序的程序员可以选择这个设备应该怎样实现：不同的驱动程序可以提供不同的能力，甚至相同的设备也可以提供不同能力。实际驱动程序设计应该是在众多需求之间的一个平衡。例如，不同程序可以同时使用同一个设备，而驱动程序的开发者可以完全自由地决定如何处理同步机制。你可以实现到设备上的内存映射，而完成独立于硬件的具体能力，或者你可以提供给用
一：前言 Linux设备模型是一个极其复杂的结构体系，在编写驱动程序的时候，通常不会用到这方面的东西，但是。理解这部份内容，对于我们理解linux设备驱动的结构是大有裨益的。我们不但可以在编写程序程序的时候知其然，亦知其所以然。又可以学习到一种极其精致的架构设计方法。由于之前已经详细分析了sysfs文件系统。所以本节的讨论主要集中在设备模型的底层实现上。上层的接口，如pci.,usb ,网络设备都可以看成是底层的封装。 二：kobject ,kset和ktype Kobject,kset,kypte这三个结构是设备模型中的下层架构。模型中的每一个元素都对应一个kobject.kset和ktype可以看成是kobject在层次结构与属性结构方面的扩充。将三者之间的关系用图的方示描述如下： 如上图所示：我们知道。在sysfs中每一个目录都对应一个kobject.这些kobject都有自己的parent。在没有指定parent的情况下，都会指向它所属的kset->object。其次，kset也内嵌了kobject.这个kobject又可以指它上一级的parent。就这样。构成了一个空间上面的层次关系。 其实，每个对象都有属性。例如，电源管理，执插拨事性管理等等。因为大部份的同类设备都有相同的属性，因此将这个属性隔离开来，存放在ktype中。这样就可以灵活的管理了.记得在分析sysfs 的时候。对于sysfs中的普通文件读写操作都是由kobject->ktype->sysfs_ops来完成的. 经过上面的分析，我们大概了解了kobject.kset与ktype的大概架设与相互之间的关系。下面我们从linux源代码中的分析来详细研究他们的操作。 三:kobject,kset和ktype的操作 为了说明kobject的操作，先写一个测试模块，代码如下： #include