精华内容
下载资源
问答
  • ARM Linux 3.x的设备树(Device Tree)

    万次阅读 多人点赞 2013-01-01 17:32:36
    本文部分案例和文字英文... 更多精华文章请扫描下方二维码关注Linux阅码场 1. ARM Device Tree起源 Linus Torvalds在2011年3月17日的ARM Linux邮件列表宣称“this whole ARM thing is a f*cking pain in the a...

    本文部分案例和文字英文原版来源于 http://devicetree.org/Device_Tree_Usage

    更多精华文章请扫描下方二维码关注Linux阅码场

    1.    ARM Device Tree起源

    Linus Torvalds在2011年3月17日的ARM Linux邮件列表宣称“this whole ARM thing is a f*cking pain in the ass”,引发ARM Linux社区的地震,随后ARM社区进行了一系列的重大修正。在过去的ARM Linux中,arch/arm/plat-xxx和arch/arm/mach-xxx中充斥着大量的垃圾代码,相当多数的代码只是在描述板级细节,而这些板级细节对于内核来讲,不过是垃圾,如板上的platform设备、resource、i2c_board_info、spi_board_info以及各种硬件的platform_data。读者有兴趣可以统计下常见的s3c2410、s3c6410等板级目录,代码量在数万行。
    社区必须改变这种局面,于是PowerPC等其他体系架构下已经使用的Flattened Device Tree(FDT)进入ARM社区的视野。Device Tree是一种描述硬件的数据结构,它起源于 OpenFirmware (OF)。在Linux 2.6中,ARM架构的板极硬件细节过多地被硬编码在arch/arm/plat-xxx和arch/arm/mach-xxx,采用Device Tree后,许多硬件的细节可以直接透过它传递给Linux,而不再需要在kernel中进行大量的冗余编码。
    Device Tree由一系列被命名的结点(node)和属性(property)组成,而结点本身可包含子结点。所谓属性,其实就是成对出现的name和value。在Device Tree中,可描述的信息包括(原先这些信息大多被hard code到kernel中):

    • CPU的数量和类别
    • 内存基地址和大小
    • 总线和桥
    • 外设连接
    • 中断控制器和中断使用情况
    • GPIO控制器和GPIO使用情况
    • Clock控制器和Clock使用情况

    它基本上就是画一棵电路板上CPU、总线、设备组成的树,Bootloader会将这棵树传递给内核,然后内核可以识别这棵树,并根据它展开出Linux内核中的platform_device、i2c_client、spi_device等设备,而这些设备用到的内存、IRQ等资源,也被传递给了内核,内核会将这些资源绑定给展开的相应的设备。

    2.    Device Tree组成和结构

    整个Device Tree牵涉面比较广,即增加了新的用于描述设备硬件信息的文本格式,又增加了编译这一文本的工具,同时Bootloader也需要支持将编译后的Device Tree传递给Linux内核。

    DTS (device tree source)

    .dts文件是一种ASCII 文本格式的Device Tree描述,此文本格式非常人性化,适合人类的阅读习惯。基本上,在ARM Linux在,一个.dts文件对应一个ARM的machine,一般放置在内核的arch/arm/boot/dts/目录。由于一个SoC可能对应多个machine(一个SoC可以对应多个产品和电路板),势必这些.dts文件需包含许多共同的部分,Linux内核为了简化,把SoC公用的部分或者多个machine共同的部分一般提炼为.dtsi,类似于C语言的头文件。其他的machine对应的.dts就include这个.dtsi。譬如,对于VEXPRESS而言,vexpress-v2m.dtsi就被vexpress-v2p-ca9.dts所引用, vexpress-v2p-ca9.dts有如下一行:
    /include/ "vexpress-v2m.dtsi"
    当然,和C语言的头文件类似,.dtsi也可以include其他的.dtsi,譬如几乎所有的ARM SoC的.dtsi都引用了skeleton.dtsi。
    .dts(或者其include的.dtsi)基本元素即为前文所述的结点和属性:

    / {
        node1 {
            a-string-property = "A string";
            a-string-list-property = "first string", "second string";
            a-byte-data-property = [0x01 0x23 0x34 0x56];
            child-node1 {
                first-child-property;
                second-child-property = <1>;
                a-string-property = "Hello, world";
            };
            child-node2 {
            };
        };
        node2 {
            an-empty-property;
            a-cell-property = <1 2 3 4>; /* each number (cell) is a uint32 */
            child-node1 {
            };
        };
    };

    上述.dts文件并没有什么真实的用途,但它基本表征了一个Device Tree源文件的结构:
    1个root结点"/";
    root结点下面含一系列子结点,本例中为"node1" 和 "node2";
    结点"node1"下又含有一系列子结点,本例中为"child-node1" 和 "child-node2";
    各结点都有一系列属性。这些属性可能为空,如" an-empty-property";可能为字符串,如"a-string-property";可能为字符串数组,如"a-string-list-property";可能为Cells(由u32整数组成),如"second-child-property",可能为二进制数,如"a-byte-data-property"。
    下面以一个最简单的machine为例来看如何写一个.dts文件。假设此machine的配置如下:
    1个双核ARM Cortex-A9 32位处理器;
    ARM的local bus上的内存映射区域分布了2个串口(分别位于0x101F1000 和 0x101F2000)、GPIO控制器(位于0x101F3000)、SPI控制器(位于0x10170000)、中断控制器(位于0x10140000)和一个external bus桥;
    External bus桥上又连接了SMC SMC91111 Ethernet(位于0x10100000)、I2C控制器(位于0x10160000)、64MB NOR Flash(位于0x30000000);
    External bus桥上连接的I2C控制器所对应的I2C总线上又连接了Maxim DS1338实时钟(I2C地址为0x58)。
    其对应的.dts文件为:

    / {
        compatible = "acme,coyotes-revenge";
        #address-cells = <1>;
        #size-cells = <1>;
        interrupt-parent = <&intc>;
    
        cpus {
            #address-cells = <1>;
            #size-cells = <0>;
            cpu@0 {
                compatible = "arm,cortex-a9";
                reg = <0>;
            };
            cpu@1 {
                compatible = "arm,cortex-a9";
                reg = <1>;
            };
        };
    
        serial@101f0000 {
            compatible = "arm,pl011";
            reg = <0x101f0000 0x1000 >;
            interrupts = < 1 0 >;
        };
    
        serial@101f2000 {
            compatible = "arm,pl011";
            reg = <0x101f2000 0x1000 >;
            interrupts = < 2 0 >;
        };
    
        gpio@101f3000 {
            compatible = "arm,pl061";
            reg = <0x101f3000 0x1000
                   0x101f4000 0x0010>;
            interrupts = < 3 0 >;
        };
    
        intc: interrupt-controller@10140000 {
            compatible = "arm,pl190";
            reg = <0x10140000 0x1000 >;
            interrupt-controller;
            #interrupt-cells = <2>;
        };
    
        spi@10115000 {
            compatible = "arm,pl022";
            reg = <0x10115000 0x1000 >;
            interrupts = < 4 0 >;
        };
    
        external-bus {
            #address-cells = <2>
            #size-cells = <1>;
            ranges = <0 0  0x10100000   0x10000     // Chipselect 1, Ethernet
                      1 0  0x10160000   0x10000     // Chipselect 2, i2c controller
                      2 0  0x30000000   0x1000000>; // Chipselect 3, NOR Flash
    
            ethernet@0,0 {
                compatible = "smc,smc91c111";
                reg = <0 0 0x1000>;
                interrupts = < 5 2 >;
            };
    
            i2c@1,0 {
                compatible = "acme,a1234-i2c-bus";
                #address-cells = <1>;
                #size-cells = <0>;
                reg = <1 0 0x1000>;
                interrupts = < 6 2 >;
                rtc@58 {
                    compatible = "maxim,ds1338";
                    reg = <58>;
                    interrupts = < 7 3 >;
                };
            };
    
            flash@2,0 {
                compatible = "samsung,k8f1315ebm", "cfi-flash";
                reg = <2 0 0x4000000>;
            };
        };
    };

    上述.dts文件中,root结点"/"的compatible 属性compatible = "acme,coyotes-revenge";定义了系统的名称,它的组织形式为:<manufacturer>,<model>。Linux内核透过root结点"/"的compatible 属性即可判断它启动的是什么machine。
    在.dts文件的每个设备,都有一个compatible 属性,compatible属性用户驱动和设备的绑定。compatible 属性是一个字符串的列表,列表中的第一个字符串表征了结点代表的确切设备,形式为"<manufacturer>,<model>",其后的字符串表征可兼容的其他设备。可以说前面的是特指,后面的则涵盖更广的范围。如在arch/arm/boot/dts/vexpress-v2m.dtsi中的Flash结点:

    flash@0,00000000 {
         compatible = "arm,vexpress-flash", "cfi-flash";
         reg = <0 0x00000000 0x04000000>,
         <1 0x00000000 0x04000000>;
         bank-width = <4>;
     };

    compatible属性的第2个字符串"cfi-flash"明显比第1个字符串"arm,vexpress-flash"涵盖的范围更广。
    再比如,Freescale MPC8349 SoC含一个串口设备,它实现了国家半导体(National Semiconductor)的ns16550 寄存器接口。则MPC8349串口设备的compatible属性为compatible = "fsl,mpc8349-uart", "ns16550"。其中,fsl,mpc8349-uart指代了确切的设备, ns16550代表该设备与National Semiconductor 的16550 UART保持了寄存器兼容。
    接下来root结点"/"的cpus子结点下面又包含2个cpu子结点,描述了此machine上的2个CPU,并且二者的compatible 属性为"arm,cortex-a9"。
    注意cpus和cpus的2个cpu子结点的命名,它们遵循的组织形式为:<name>[@<unit-address>],<>中的内容是必选项,[]中的则为可选项。name是一个ASCII字符串,用于描述结点对应的设备类型,如3com Ethernet适配器对应的结点name宜为ethernet,而不是3com509。如果一个结点描述的设备有地址,则应该给出@unit-address。多个相同类型设备结点的name可以一样,只要unit-address不同即可,如本例中含有cpu@0、cpu@1以及serial@101f0000与serial@101f2000这样的同名结点。设备的unit-address地址也经常在其对应结点的reg属性中给出。ePAPR标准给出了结点命名的规范。
    可寻址的设备使用如下信息来在Device Tree中编码地址信息:

    •     reg
    •     #address-cells
    •     #size-cells

    其中reg的组织形式为reg = <address1 length1 [address2 length2] [address3 length3] ... >,其中的每一组address length表明了设备使用的一个地址范围。address为1个或多个32位的整型(即cell),而length则为cell的列表或者为空(若#size-cells = 0)。address 和 length 字段是可变长的,父结点的#address-cells和#size-cells分别决定了子结点的reg属性的address和length字段的长度。在本例中,root结点的#address-cells = <1>;和#size-cells = <1>;决定了serial、gpio、spi等结点的address和length字段的长度分别为1。cpus 结点的#address-cells = <1>;和#size-cells = <0>;决定了2个cpu子结点的address为1,而length为空,于是形成了2个cpu的reg = <0>;和reg = <1>;。external-bus结点的#address-cells = <2>和#size-cells = <1>;决定了其下的ethernet、i2c、flash的reg字段形如reg = <0 0 0x1000>;、reg = <1 0 0x1000>;和reg = <2 0 0x4000000>;。其中,address字段长度为0,开始的第一个cell(0、1、2)是对应的片选,第2个cell(0,0,0)是相对该片选的基地址,第3个cell(0x1000、0x1000、0x4000000)为length。特别要留意的是i2c结点中定义的 #address-cells = <1>;和#size-cells = <0>;又作用到了I2C总线上连接的RTC,它的address字段为0x58,是设备的I2C地址。
    root结点的子结点描述的是CPU的视图,因此root子结点的address区域就直接位于CPU的memory区域。但是,经过总线桥后的address往往需要经过转换才能对应的CPU的memory映射。external-bus的ranges属性定义了经过external-bus桥后的地址范围如何映射到CPU的memory区域。

            ranges = <0 0  0x10100000   0x10000     // Chipselect 1, Ethernet
                      1 0  0x10160000   0x10000     // Chipselect 2, i2c controller
                      2 0  0x30000000   0x1000000>; // Chipselect 3, NOR Flash

    ranges是地址转换表,其中的每个项目是一个子地址、父地址以及在子地址空间的大小的映射。映射表中的子地址、父地址分别采用子地址空间的#address-cells和父地址空间的#address-cells大小。对于本例而言,子地址空间的#address-cells为2,父地址空间的#address-cells值为1,因此0 0  0x10100000   0x10000的前2个cell为external-bus后片选0上偏移0,第3个cell表示external-bus后片选0上偏移0的地址空间被映射到CPU的0x10100000位置,第4个cell表示映射的大小为0x10000。ranges的后面2个项目的含义可以类推。
    Device Tree中还可以中断连接信息,对于中断控制器而言,它提供如下属性:
    interrupt-controller – 这个属性为空,中断控制器应该加上此属性表明自己的身份;
    #interrupt-cells – 与#address-cells 和 #size-cells相似,它表明连接此中断控制器的设备的interrupts属性的cell大小。
    在整个Device Tree中,与中断相关的属性还包括:
    interrupt-parent – 设备结点透过它来指定它所依附的中断控制器的phandle,当结点没有指定interrupt-parent 时,则从父级结点继承。对于本例而言,root结点指定了interrupt-parent = <&intc>;其对应于intc: interrupt-controller@10140000,而root结点的子结点并未指定interrupt-parent,因此它们都继承了intc,即位于0x10140000的中断控制器。
    interrupts – 用到了中断的设备结点透过它指定中断号、触发方法等,具体这个属性含有多少个cell,由它依附的中断控制器结点的#interrupt-cells属性决定。而具体每个cell又是什么含义,一般由驱动的实现决定,而且也会在Device Tree的binding文档中说明。譬如,对于ARM GIC中断控制器而言,#interrupt-cells为3,它3个cell的具体含义Documentation/devicetree/bindings/arm/gic.txt就有如下文字说明:

    01   The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
    02   interrupts.
    03
    04   The 2nd cell contains the interrupt number for the interrupt type.
    05   SPI interrupts are in the range [0-987].  PPI interrupts are in the
    06   range [0-15].
    07
    08   The 3rd cell is the flags, encoded as follows:
    09         bits[3:0] trigger type and level flags.
    10                 1 = low-to-high edge triggered
    11                 2 = high-to-low edge triggered
    12                 4 = active high level-sensitive
    13                 8 = active low level-sensitive
    14         bits[15:8] PPI interrupt cpu mask.  Each bit corresponds to each of
    15         the 8 possible cpus attached to the GIC.  A bit set to '1' indicated
    16         the interrupt is wired to that CPU.  Only valid for PPI interrupts.

    另外,值得注意的是,一个设备还可能用到多个中断号。对于ARM GIC而言,若某设备使用了SPI的168、169号2个中断,而言都是高电平触发,则该设备结点的interrupts属性可定义为:interrupts = <0 168 4>, <0 169 4>;
    除了中断以外,在ARM Linux中clock、GPIO、pinmux都可以透过.dts中的结点和属性进行描述。

    DTC (device tree compiler)

    将.dts编译为.dtb的工具。DTC的源代码位于内核的scripts/dtc目录,在Linux内核使能了Device Tree的情况下,编译内核的时候主机工具dtc会被编译出来,对应scripts/dtc/Makefile中的“hostprogs-y := dtc”这一hostprogs编译target。
    在Linux内核的arch/arm/boot/dts/Makefile中,描述了当某种SoC被选中后,哪些.dtb文件会被编译出来,如与VEXPRESS对应的.dtb包括:

    dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2p-ca5s.dtb \
            vexpress-v2p-ca9.dtb \
            vexpress-v2p-ca15-tc1.dtb \
            vexpress-v2p-ca15_a7.dtb \
            xenvm-4.2.dtb

    在Linux下,我们可以单独编译Device Tree文件。当我们在Linux内核下运行make dtbs时,若我们之前选择了ARCH_VEXPRESS,上述.dtb都会由对应的.dts编译出来。因为arch/arm/Makefile中含有一个dtbs编译target项目。

    Device Tree Blob (.dtb)

    .dtb是.dts被DTC编译后的二进制格式的Device Tree描述,可由Linux内核解析。通常在我们为电路板制作NAND、SD启动image时,会为.dtb文件单独留下一个很小的区域以存放之,之后bootloader在引导kernel的过程中,会先读取该.dtb到内存。

    Binding

    对于Device Tree中的结点和属性具体是如何来描述设备的硬件细节的,一般需要文档来进行讲解,文档的后缀名一般为.txt。这些文档位于内核的Documentation/devicetree/bindings目录,其下又分为很多子目录。

    Bootloader

    Uboot mainline 从 v1.1.3开始支持Device Tree,其对ARM的支持则是和ARM内核支持Device Tree同期完成。
    为了使能Device Tree,需要编译Uboot的时候在config文件中加入
    #define CONFIG_OF_LIBFDT
    在Uboot中,可以从NAND、SD或者TFTP等任意介质将.dtb读入内存,假设.dtb放入的内存地址为0x71000000,之后可在Uboot运行命令fdt addr命令设置.dtb的地址,如:
    U-Boot> fdt addr 0x71000000
    fdt的其他命令就变地可以使用,如fdt resize、fdt print等。
    对于ARM来讲,可以透过bootz kernel_addr initrd_address dtb_address的命令来启动内核,即dtb_address作为bootz或者bootm的最后一次参数,第一个参数为内核映像的地址,第二个参数为initrd的地址,若不存在initrd,可以用 -代替。

    3.    Device Tree引发的BSP和驱动变更

    有了Device Tree后,大量的板级信息都不再需要,譬如过去经常在arch/arm/plat-xxx和arch/arm/mach-xxx实施的如下事情:
    1.    注册platform_device,绑定resource,即内存、IRQ等板级信息。

    透过Device Tree后,形如

     

    90 static struct resource xxx_resources[] = {
    91         [0] = {
    92                 .start  = …,
    93                 .end    = …,
    94                 .flags  = IORESOURCE_MEM,
    95         },
    96         [1] = {
    97                 .start  = …,
    98                 .end    = …,
    99                 .flags  = IORESOURCE_IRQ,
    100         },
    101 };
    102
    103 static struct platform_device xxx_device = {
    104         .name           = "xxx",
    105         .id             = -1,
    106         .dev            = {
    107                                 .platform_data          = &xxx_data,
    108         },
    109         .resource       = xxx_resources,
    110         .num_resources  = ARRAY_SIZE(xxx_resources),
    111 };

    之类的platform_device代码都不再需要,其中platform_device会由kernel自动展开。而这些resource实际来源于.dts中设备结点的reg、interrupts属性。典型地,大多数总线都与“simple_bus”兼容,而在SoC对应的machine的.init_machine成员函数中,调用of_platform_bus_probe(NULL, xxx_of_bus_ids, NULL);即可自动展开所有的platform_device。譬如,假设我们有个XXX SoC,则可在arch/arm/mach-xxx/的板文件中透过如下方式展开.dts中的设备结点对应的platform_device:

     

     

    18 static struct of_device_id xxx_of_bus_ids[] __initdata = {
    19         { .compatible = "simple-bus", },
    20         {},
    21 };
    22
    23 void __init xxx_mach_init(void)
    24 {
    25         of_platform_bus_probe(NULL, xxx_of_bus_ids, NULL);
    26 }
    32
    33 #ifdef CONFIG_ARCH_XXX
    38
    39 DT_MACHINE_START(XXX_DT, "Generic XXX (Flattened Device Tree)")
    41         …
    45         .init_machine   = xxx_mach_init,
    46         …
    49 MACHINE_END
    50 #endif

     

     

     

    2.    注册i2c_board_info,指定IRQ等板级信息。

    形如

     

    145 static struct i2c_board_info __initdata afeb9260_i2c_devices[] = {
    146         {
    147                 I2C_BOARD_INFO("tlv320aic23", 0x1a),
    148         }, {
    149                 I2C_BOARD_INFO("fm3130", 0x68),
    150         }, {
    151                 I2C_BOARD_INFO("24c64", 0x50),
    152         },
    153 };

    之类的i2c_board_info代码,目前不再需要出现,现在只需要把tlv320aic23、fm3130、24c64这些设备结点填充作为相应的I2C controller结点的子结点即可,类似于前面的

     

     

          i2c@1,0 {
                compatible = "acme,a1234-i2c-bus";
                …
                rtc@58 {
                    compatible = "maxim,ds1338";
                    reg = <58>;
                    interrupts = < 7 3 >;
                };
            };

    Device Tree中的I2C client会透过I2C host驱动的probe()函数中调用of_i2c_register_devices(&i2c_dev->adapter);被自动展开。

     

    3.    注册spi_board_info,指定IRQ等板级信息。

    形如

     

    79 static struct spi_board_info afeb9260_spi_devices[] = {
    80         {       /* DataFlash chip */
    81                 .modalias       = "mtd_dataflash",
    82                 .chip_select    = 1,
    83                 .max_speed_hz   = 15 * 1000 * 1000,
    84                 .bus_num        = 0,
    85         },
    86 };

    之类的spi_board_info代码,目前不再需要出现,与I2C类似,现在只需要把mtd_dataflash之类的结点,作为SPI控制器的子结点即可,SPI host驱动的probe函数透过spi_register_master()注册master的时候,会自动展开依附于它的slave。

     

    4.    多个针对不同电路板的machine,以及相关的callback。

    过去,ARM Linux针对不同的电路板会建立由MACHINE_START和MACHINE_END包围起来的针对这个machine的一系列callback,譬如:

     

    373 MACHINE_START(VEXPRESS, "ARM-Versatile Express")
    374         .atag_offset    = 0x100,
    375         .smp            = smp_ops(vexpress_smp_ops),
    376         .map_io         = v2m_map_io,
    377         .init_early     = v2m_init_early,
    378         .init_irq       = v2m_init_irq,
    379         .timer          = &v2m_timer,
    380         .handle_irq     = gic_handle_irq,
    381         .init_machine   = v2m_init,
    382         .restart        = vexpress_restart,
    383 MACHINE_END

    这些不同的machine会有不同的MACHINE ID,Uboot在启动Linux内核时会将MACHINE ID存放在r1寄存器,Linux启动时会匹配Bootloader传递的MACHINE ID和MACHINE_START声明的MACHINE ID,然后执行相应machine的一系列初始化函数。

     

    引入Device Tree之后,MACHINE_START变更为DT_MACHINE_START,其中含有一个.dt_compat成员,用于表明相关的machine与.dts中root结点的compatible属性兼容关系。如果Bootloader传递给内核的Device Tree中root结点的compatible属性出现在某machine的.dt_compat表中,相关的machine就与对应的Device Tree匹配,从而引发这一machine的一系列初始化函数被执行。

     

    489 static const char * const v2m_dt_match[] __initconst = {
    490         "arm,vexpress",
    491         "xen,xenvm",
    492         NULL,
    493 };
    495 DT_MACHINE_START(VEXPRESS_DT, "ARM-Versatile Express")
    496         .dt_compat      = v2m_dt_match,
    497         .smp            = smp_ops(vexpress_smp_ops),
    498         .map_io         = v2m_dt_map_io,
    499         .init_early     = v2m_dt_init_early,
    500         .init_irq       = v2m_dt_init_irq,
    501         .timer          = &v2m_dt_timer,
    502         .init_machine   = v2m_dt_init,
    503         .handle_irq     = gic_handle_irq,
    504         .restart        = vexpress_restart,
    505 MACHINE_END

    Linux倡导针对多个SoC、多个电路板的通用DT machine,即一个DT machine的.dt_compat表含多个电路板.dts文件的root结点compatible属性字符串。之后,如果的电路板的初始化序列不一样,可以透过int of_machine_is_compatible(const char *compat) API判断具体的电路板是什么。

     

        譬如arch/arm/mach-exynos/mach-exynos5-dt.c的EXYNOS5_DT machine同时兼容"samsung,exynos5250"和"samsung,exynos5440":

     

    158 static char const *exynos5_dt_compat[] __initdata = {
    159         "samsung,exynos5250",
    160         "samsung,exynos5440",
    161         NULL
    162 };
    163
    177 DT_MACHINE_START(EXYNOS5_DT, "SAMSUNG EXYNOS5 (Flattened Device Tree)")
    178         /* Maintainer: Kukjin Kim <kgene.kim@samsung.com> */
    179         .init_irq       = exynos5_init_irq,
    180         .smp            = smp_ops(exynos_smp_ops),
    181         .map_io         = exynos5_dt_map_io,
    182         .handle_irq     = gic_handle_irq,
    183         .init_machine   = exynos5_dt_machine_init,
    184         .init_late      = exynos_init_late,
    185         .timer          = &exynos4_timer,
    186         .dt_compat      = exynos5_dt_compat,
    187         .restart        = exynos5_restart,
    188         .reserve        = exynos5_reserve,
    189 MACHINE_END

         它的.init_machine成员函数就针对不同的machine进行了不同的分支处理:

     

    126 static void __init exynos5_dt_machine_init(void)
    127 {
    128         …
    149
    150         if (of_machine_is_compatible("samsung,exynos5250"))
    151                 of_platform_populate(NULL, of_default_bus_match_table,
    152                                      exynos5250_auxdata_lookup, NULL);
    153         else if (of_machine_is_compatible("samsung,exynos5440"))
    154                 of_platform_populate(NULL, of_default_bus_match_table,
    155                                      exynos5440_auxdata_lookup, NULL);
    156 }

     

     

     

    使用Device Tree后,驱动需要与.dts中描述的设备结点进行匹配,从而引发驱动的probe()函数执行。对于platform_driver而言,需要添加一个OF匹配表,如前文的.dts文件的"acme,a1234-i2c-bus"兼容I2C控制器结点的OF匹配表可以是:

     

    436 static const struct of_device_id a1234_i2c_of_match[] = {
    437         { .compatible = "acme,a1234-i2c-bus ", },
    438         {},
    439 };
    440 MODULE_DEVICE_TABLE(of, a1234_i2c_of_match);
    441
    442 static struct platform_driver i2c_a1234_driver = {
    443         .driver = {
    444                 .name = "a1234-i2c-bus ",
    445                 .owner = THIS_MODULE,
    449                 .of_match_table = a1234_i2c_of_match,
    450         },
    451         .probe = i2c_a1234_probe,
    452         .remove = i2c_a1234_remove,
    453 };
    454 module_platform_driver(i2c_a1234_driver);

     

    对于I2C和SPI从设备而言,同样也可以透过of_match_table添加匹配的.dts中的相关结点的compatible属性,如sound/soc/codecs/wm8753.c中的:

     

    1533 static const struct of_device_id wm8753_of_match[] = {
    1534         { .compatible = "wlf,wm8753", },
    1535         { }
    1536 };
    1537 MODULE_DEVICE_TABLE(of, wm8753_of_match);
    1587 static struct spi_driver wm8753_spi_driver = {
    1588         .driver = {
    1589                 .name   = "wm8753",
    1590                 .owner  = THIS_MODULE,
    1591                 .of_match_table = wm8753_of_match,
    1592         },
    1593         .probe          = wm8753_spi_probe,
    1594         .remove         = wm8753_spi_remove,
    1595 };
    1640 static struct i2c_driver wm8753_i2c_driver = {
    1641         .driver = {
    1642                 .name = "wm8753",
    1643                 .owner = THIS_MODULE,
    1644                 .of_match_table = wm8753_of_match,
    1645         },
    1646         .probe =    wm8753_i2c_probe,
    1647         .remove =   wm8753_i2c_remove,
    1648         .id_table = wm8753_i2c_id,
    1649 };

    不过这边有一点需要提醒的是,I2C和SPI外设驱动和Device Tree中设备结点的compatible 属性还有一种弱式匹配方法,就是别名匹配。compatible 属性的组织形式为<manufacturer>,<model>,别名其实就是去掉compatible 属性中逗号前的manufacturer前缀。关于这一点,可查看drivers/spi/spi.c的源代码,函数spi_match_device()暴露了更多的细节,如果别名出现在设备spi_driver的id_table里面,或者别名与spi_driver的name字段相同,SPI设备和驱动都可以匹配上:

     

     

     

    90 static int spi_match_device(struct device *dev, struct device_driver *drv)
    91 {
    92         const struct spi_device *spi = to_spi_device(dev);
    93         const struct spi_driver *sdrv = to_spi_driver(drv);
    94
    95         /* Attempt an OF style match */
    96         if (of_driver_match_device(dev, drv))
    97                 return 1;
    98
    99         /* Then try ACPI */
    100         if (acpi_driver_match_device(dev, drv))
    101                 return 1;
    102
    103         if (sdrv->id_table)
    104                 return !!spi_match_id(sdrv->id_table, spi);
    105
    106         return strcmp(spi->modalias, drv->name) == 0;
    107 }
    71 static const struct spi_device_id *spi_match_id(const struct spi_device_id *id,
    72                                                 const struct spi_device *sdev)
    73 {
    74         while (id->name[0]) {
    75                 if (!strcmp(sdev->modalias, id->name))
    76                         return id;
    77                 id++;
    78         }
    79         return NULL;
    80 }

     

    4.    常用OF API

    在Linux的BSP和驱动代码中,还经常会使用到Linux中一组Device Tree的API,这些API通常被冠以of_前缀,它们的实现代码位于内核的drivers/of目录。这些常用的API包括:

    int of_device_is_compatible(const struct device_node *device,const char *compat);

    判断设备结点的compatible 属性是否包含compat指定的字符串。当一个驱动支持2个或多个设备的时候,这些不同.dts文件中设备的compatible 属性都会进入驱动 OF匹配表。因此驱动可以透过Bootloader传递给内核的Device Tree中的真正结点的compatible 属性以确定究竟是哪一种设备,从而根据不同的设备类型进行不同的处理。如drivers/pinctrl/pinctrl-sirf.c即兼容于"sirf,prima2-pinctrl",又兼容于"sirf,prima2-pinctrl",在驱动中就有相应分支处理:

     

    1682 if (of_device_is_compatible(np, "sirf,marco-pinctrl"))
    1683      is_marco = 1;

    struct device_node *of_find_compatible_node(struct device_node *from,

     

             const char *type, const char *compatible);

     

    根据compatible属性,获得设备结点。遍历Device Tree中所有的设备结点,看看哪个结点的类型、compatible属性与本函数的输入参数匹配,大多数情况下,from、type为NULL。

    int of_property_read_u8_array(const struct device_node *np,

                         const char *propname, u8 *out_values, size_t sz);

    int of_property_read_u16_array(const struct device_node *np,

                          const char *propname, u16 *out_values, size_t sz);

    int of_property_read_u32_array(const struct device_node *np,

                          const char *propname, u32 *out_values, size_t sz);

    int of_property_read_u64(const struct device_node *np, const char

    *propname, u64 *out_value);

    读取设备结点np的属性名为propname,类型为8、16、32、64位整型数组的属性。对于32位处理器来讲,最常用的是of_property_read_u32_array()。如在arch/arm/mm/cache-l2x0.c中,透过如下语句读取L2 cache的"arm,data-latency"属性:

     

    534         of_property_read_u32_array(np, "arm,data-latency",
    535                                    data, ARRAY_SIZE(data));

    在arch/arm/boot/dts/vexpress-v2p-ca9.dts中,含有"arm,data-latency"属性的L2 cache结点如下:

     

    137         L2: cache-controller@1e00a000 {
    138                 compatible = "arm,pl310-cache";
    139                 reg = <0x1e00a000 0x1000>;
    140                 interrupts = <0 43 4>;
    141                 cache-level = <2>;
    142                 arm,data-latency = <1 1 1>;
    143                 arm,tag-latency = <1 1 1>;
    144         }


    有些情况下,整形属性的长度可能为1,于是内核为了方便调用者,又在上述API的基础上封装出了更加简单的读单一整形属性的API,它们为int of_property_read_u8()、of_property_read_u16()等,实现于include/linux/of.h:

     

     

    513 static inline int of_property_read_u8(const struct device_node *np,
    514                                        const char *propname,
    515                                        u8 *out_value)
    516 {
    517         return of_property_read_u8_array(np, propname, out_value, 1);
    518 }
    519
    520 static inline int of_property_read_u16(const struct device_node *np,
    521                                        const char *propname,
    522                                        u16 *out_value)
    523 {
    524         return of_property_read_u16_array(np, propname, out_value, 1);
    525 }
    526
    527 static inline int of_property_read_u32(const struct device_node *np,
    528                                        const char *propname,
    529                                        u32 *out_value)
    530 {
    531         return of_property_read_u32_array(np, propname, out_value, 1);
    532 }


    int of_property_read_string(struct device_node *np, const char

     

    *propname, const char **out_string);

    int of_property_read_string_index(struct device_node *np, const char

        *propname, int index, const char **output);

    前者读取字符串属性,后者读取字符串数组属性中的第index个字符串。如drivers/clk/clk.c中的of_clk_get_parent_name()透过of_property_read_string_index()遍历clkspec结点的所有"clock-output-names"字符串数组属性。

     

    1759 const char *of_clk_get_parent_name(struct device_node *np, int index)
    1760 {
    1761         struct of_phandle_args clkspec;
    1762         const char *clk_name;
    1763         int rc;
    1764
    1765         if (index < 0)
    1766                 return NULL;
    1767
    1768         rc = of_parse_phandle_with_args(np, "clocks", "#clock-cells", index,
    1769                                         &clkspec);
    1770         if (rc)
    1771                 return NULL;
    1772
    1773         if (of_property_read_string_index(clkspec.np, "clock-output-names",
    1774                                   clkspec.args_count ? clkspec.args[0] : 0,
    1775                                           &clk_name) < 0)
    1776                 clk_name = clkspec.np->name;
    1777
    1778         of_node_put(clkspec.np);
    1779         return clk_name;
    1780 }
    1781 EXPORT_SYMBOL_GPL(of_clk_get_parent_name);


    static inline bool of_property_read_bool(const struct device_node *np,

     

                                             const char *propname);

     

    如果设备结点np含有propname属性,则返回true,否则返回false。一般用于检查空属性是否存在。

     

    void __iomem *of_iomap(struct device_node *node, int index);

     

    通过设备结点直接进行设备内存区间的 ioremap(),index是内存段的索引。若设备结点的reg属性有多段,可通过index标示要ioremap的是哪一段,只有1段的情况,index为0。采用Device Tree后,大量的设备驱动通过of_iomap()进行映射,而不再通过传统的ioremap。

     

    unsigned int irq_of_parse_and_map(struct device_node *dev, int index);

    透过Device Tree或者设备的中断号,实际上是从.dts中的interrupts属性解析出中断号。若设备使用了多个中断,index指定中断的索引号。

     

    还有一些OF API,这里不一一列举,具体可参考include/linux/of.h头文件。

    5.    总结

    ARM社区一贯充斥的大量垃圾代码导致Linus盛怒,因此社区在2011年到2012年进行了大量的工作。ARM Linux开始围绕Device Tree展开,Device Tree有自己的独立的语法,它的源文件为.dts,编译后得到.dtb,Bootloader在引导Linux内核的时候会将.dtb地址告知内核。之后内核会展开Device Tree并创建和注册相关的设备,因此arch/arm/mach-xxx和arch/arm/plat-xxx中大量的用于注册platform、I2C、SPI板级信息的代码被删除,而驱动也以新的方式和.dts中定义的设备结点进行匹配。

    更多精华文章请扫描下方二维码关注Linux阅码场

    展开全文
  • 图解ARM Linux的启动全过程

    万次阅读 多人点赞 2012-05-02 14:07:53
    图解ARM Linux的启动全过程 图解ARM-Linux的启动全过程:内核自解压阶段—>内核引导阶段—>内核初始化阶段—>BusyBox初始化阶段。 图片有点大,打开的时候比较慢。大家可以免费下载...

    图解ARM Linux的启动全过程

    图解ARM-Linux的启动全过程:内核自解压阶段—>内核引导阶段—>内核初始化阶段—>BusyBox初始化阶段。
    图片有点大,打开的时候比较慢。大家可以免费下载http://download.csdn.net/detail/ce123/4275871
    注意:本图在不断的修改中,本网页中的图是最新的。下载链接中的图不能替换,可能有些错误!



    展开全文
  • ARM LINUX与普通LINUX区别

    万次阅读 2018-06-07 09:34:25
    相对于ARM linux,我们说的普通linux指的是X86 linux,他们都是linux系统,但是由于ARM和X86是不同的CPU架构,他们的指令集不同,所以软件编译环境不同,软件代码一般不能互用,一般需要进行兼容性移植。  X86是...
    相对于ARM linux,我们说的普通linux指的是X86 linux,他们都是linux系统,但是由于ARM和X86是不同的CPU架构,他们的指令集不同,所以软件编译环境不同,软件代码一般不能互用,一般需要进行兼容性移植。
      X86是经典的CISC指令集,指令集复杂,功能多,串行执行,但是也意味着执行效率低下,但性价比突出,所以称为民用终端的主流处理器内置指令集。Intel和AMD的家用处理器都是X86指令集。以X86为代表的CISC,理论并发线程1-2条。
    ARM是Advanced RISC Machine 的缩写。它的指令集比RISC还要精简。通常使用ARM架构处理器的机型,多为嵌入式或者便携机。主频通常不高,现在高通公司ARM架构处理器有1.0GHz的,已经算相当高了。另外,ARM 7沿用冯·诺依曼结构;而从ARM 9以后,就都采用了哈佛结构。ARM的并发线程,理论上有4条左右,处理效率较X86高不少。

    展开全文
  • 从单片机到ARM Linux驱动——Linux驱动入门篇

    万次阅读 多人点赞 2020-10-24 10:58:43
    我们需要熟悉Linux操作系统,知道Linux的常用命令、文件系统、Linux网络、多线程/多进程,同时要会用vi编辑器、gcc编译器、shell脚本和一些简单的makefile的编写,在这些的基础之上进行Linux驱动开发的学习就会如步...

           大一到大二这段时间里学习过单片机的相关知识,对单片机有一定的认识和了解。如果要深究其原理可能还差了一些火候。知道如何编写程序来点量一个LED灯,改一改官方提供的例程来实现一些功能做一些小东西,对IIC、SPI底层的通信协议有一定的了解,但是学着学着逐渐觉得单片机我也就只能改改代码了(当然有的代码也不一定能改出来)。对于我这种以后不想从事单片机开发想搬砖的码农来说已经差不多了(仅仅是个人观点)。
           在单片机开发中我们常常用到的是裸机,并没有用到操作系统(或者接触过ucos/rtos这种实时操作系统),但是嵌入式Linux开发就必须得在Linux系统中进行操作。我们需要熟悉Linux操作系统,知道Linux的常用命令、文件系统、Linux网络、多线程/多进程,同时要会用vi编辑器、gcc编译器、shell脚本和一些简单的makefile的编写,在这些的基础之上进行Linux驱动开发的学习就会如步青云。

    往期推荐:
           史上最全的Linux常用命令汇总(超全面!超详细!)收藏这一篇就够了!
           STM32通过PWM产生频率为20HZ占空比为50%方波,并通过单片机测量频率并显示在这里插入图片描述

           嵌入式Linux操作系统具有:开放源码、所需容量小(最小的安装大约需要2MB)、不需著作权费用、成熟与稳定(经历这些年的发展与使用)、良好的支持等特点。因此被广泛应用于移动电话、个人数码等产品中。嵌入式Linux开发主要包括:底层驱动、操作系统内核、应用开发三大类。需要掌握系统移植(Uboot、Linux Kernel的移植和裁剪、根文件系统的构建)、Linux驱动及内核开发(字符设备驱动、块设备驱动、网络设备驱动)应用开发由于博主能力有限所了解的也不多。

    字符设备驱动简介

           字符设备是Linux驱动中最基本的一类设备驱动,字符设备就是一个字节,按照字节进行读写操作设备,读写数据是分先后顺序的。比如我们常见的点灯、按键、IIC、SPI、LCD等都是字符设备,这些设备的驱动就叫做字符设备驱动。
           在Linux中开发一般只能是用户态,也就是用户只能编写应用程序,但是要作用于内核,那么就需要了解Linux中应用程序是如何调用内核中的驱动程序的,Linux 应用程序对驱动程序的调用如下图所示:
    在这里插入图片描述
           在Linux 中一切皆为文件,驱动加载成功以后会在“/dev”目录下生成一个相应的文件,应用程序通过对这个名为“/dev/xxx” (xxx 是具体的驱动文件名字)的文件进行相应的操作即可实现对硬件的操作。比如现在有个叫做/dev/led 的驱动文件,此文件是 led 灯的驱动文件。应用程序使用 open 函数来打开文件/dev/led,使用完成以后使用 close 函数关闭/dev/led 这个文件。 open和 close 就是打开和关闭 led 驱动的函数,如果要点亮或关闭 led,那么就使用 write 函数来操作,也就是向此驱动写入数据,这个数据就是要关闭还是要打开 led 的控制参数。如果要获取led 灯的状态,就用 read 函数从驱动中读取相应的状态。
           应用程序运行在用户空间,而 Linux 驱动属于内核的一部分,因此驱动运行于内核空间。当我们在用户空间想要实现对内核的操作,比如使用 open 函数打开/dev/led 这个驱动,因为用户空间不能直接对内核进行操作,因此必须使用一个叫做“系统调用”的方法来实现从用户空间陷入到内核空间,这样才能实现对底层驱动的操作。 open、 close、 write 和 read 等这些函数是有 C 库提供的,在 Linux 系统中,系统调用作为 C 库的一部分。当我们调用 open 函数的时候流程如图所示:
    在这里插入图片描述
           应用程序使用到的函数在具体的驱动中都有与之对应的函数,比如应用程序中调用了 open 这个函数,那么在驱动程序中也得有一个名为 open 的函数。每一个系统调用,在驱动中都有与之对应的一个驱动函数,在 Linux 内核文件 include/linux/fs.h 中有个叫做 file_operations 的结构体,此结构体就是 Linux 内核驱动操作函数集合

    struct file_operations {
    	struct module *owner;//owner 拥有该结构体的模块的指针,一般设置为 THIS_MODULE
    	loff_t (*llseek) (struct file *, loff_t, int);//llseek 函数用于修改文件当前的读写位置
    	ssize_t (*read) (struct file *, char __user *, size_t, loff_t*);//read 函数用于读取设备文件
    	ssize_t (*write) (struct file *, const char __user *, size_t,loff_t *);//write 函数用于向设备文件写入(发送)数据
    	ssize_t (*read_iter) (struct kiocb *, struct iov_iter *);
    	ssize_t (*write_iter) (struct kiocb *, struct iov_iter *);
    	int (*iterate) (struct file *, struct dir_context *);
    	unsigned int (*poll) (struct file *, struct poll_table_struct*);//poll 是个轮询函数,用于查询设备是否可以进行非阻塞的读写
    	long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);//unlocked_ioctl 函数提供对于设备的控制功能,与应用程序中的 ioctl 函数对应。
    	long (*compat_ioctl) (struct file *, unsigned int, unsigned long);//compat_ioctl 函数与 unlocked_ioctl 函数功能一样,区别在于在 64 位系统上,32 位的应用程序调用将会使用此函数。在 32 位的系统上运行 32 位的应用程序调用的是unlocked_ioctl。
    	int (*mmap) (struct file *, struct vm_area_struct *);//mmap 函数用于将将设备的内存映射到进程空间中(也就是用户空间),一般帧缓冲设备会使用此函数,比如 LCD 驱动的显存,将帧缓冲(LCD 显存)映射到用户空间中以后应用程序就可以直接操作显存了,这样就不用在用户空间和内核空间之间来回复制。
    	int (*mremap)(struct file *, struct vm_area_struct *);
    	int (*open) (struct inode *, struct file *);//open 函数用于打开设备文件。
    	int (*flush) (struct file *, fl_owner_t id);
    	int (*release) (struct inode *, struct file *);//release 函数用于释放(关闭)设备文件,与应用程序中的 close 函数对应。
    	int (*fsync) (struct file *, loff_t, loff_t, int datasync);//fasync 函数用于刷新待处理的数据,用于将缓冲区中的数据刷新到磁盘中。
    	int (*aio_fsync) (struct kiocb *, int datasync);//aio_fsync 函数与 fasync 函数的功能类似,只是 aio_fsync 是异步刷新待处理的数据
    	int (*fasync) (int, struct file *, int);
    	int (*lock) (struct file *, int, struct file_lock *);
    	ssize_t (*sendpage) (struct file *, struct page *, int, size_t,loff_t *, int);
    	unsigned long (*get_unmapped_area)(struct file *, unsigned long,
    	unsigned long, unsigned long, unsigned long);
    	int (*check_flags)(int);
    	int (*flock) (struct file *, int, struct file_lock *);
    	ssize_t (*splice_write)(struct pipe_inode_info *, struct file *,
    	loff_t *, size_t, unsigned int);
    	ssize_t (*splice_read)(struct file *, loff_t *, struct
    	pipe_inode_info *, size_t, unsigned int);
    	int (*setlease)(struct file *, long, struct file_lock **, void **);
    	long (*fallocate)(struct file *file, int mode, loff_t offset,loff_t len);
    	void (*show_fdinfo)(struct seq_file *m, struct file *f);
    	#ifndef CONFIG_MMU
    		unsigned (*mmap_capabilities)(struct file *);
    	#endif
    };
    

    字符设备驱动开发步骤

           在学习裸机或者 STM32 的时候关于驱动的开发就是初始化相应的外设寄存器,在 Linux 驱动开发中肯定也是要初始化相应的外设寄存器,这是毫无疑问的。只是在 Linux 驱动开发中我们需要按照其规定的框架来编写驱动,所以说学 Linux 驱动开发重点是学习其驱动框架

    驱动模块的加载和卸载

           Linux 驱动有两种运行方式第一种就是将驱动编译进 Linux 内核中,这样当 Linux 内核启动的时候就会自动运行驱动程序第二种就是将驱动编译成模块(Linux 下模块扩展名为.ko),在Linux 内核启动以后使用“insmod”命令加载驱动模块。在调试驱动的时候一般都选择将其编译为模块,这样我们修改驱动以后只需要编译一下驱动代码即可,不需要编译整个 Linux 代码。而且在调试的时候只需要加载或者卸载驱动模块即可,不需要重启整个系统。

           模块有加载和卸载两种操作,我们在编写驱动的时候需要注册这两种操作函数,模块的加载和卸载注册函数如下:

    module_init(xxx_init); //注册模块加载函数
    module_exit(xxx_exit); //注册模块卸载函数
    

           module_init 函数用来向 Linux 内核注册一个模块加载函数,参数 xxx_init 就是需要注册的具体函数,当使用“insmod”命令加载驱动的时候, xxx_init 这个函数就会被调用。 module_exit()函数用来向 Linux 内核注册一个模块卸载函数,参数 xxx_exit 就是需要注册的具体函数,当使用“rmmod”命令卸载具体驱动的时候 xxx_exit 函数就会被调用。字符设备驱动模块加载和卸载模板如下所示:

     /* 驱动入口函数 */
    static int __init xxx_init(void)
    {
    	/* 入口函数具体内容 */
    	return 0;
    }
    /* 驱动出口函数 */
    static void __exit xxx_exit(void)
    {
    	 /* 出口函数具体内容 */
     }
    
    	/* 将上面两个函数指定为驱动的入口和出口函数 */
    	module_init(xxx_init);
    	module_exit(xxx_exit);
    
    • 第 2 行,定义了个名为 xxx_init 的驱动入口函数,并且使用了“__init”来修饰。
    • 第 9 行,定义了个名为 xxx_exit 的驱动出口函数,并且使用了“__exit”来修饰。
    • 第 15 行,调用函数 module_init 来声明 xxx_init 为驱动入口函数,当加载驱动的时候 xxx_init函数就会被调用。
    • 第16行,调用函数module_exit来声明xxx_exit为驱动出口函数,当卸载驱动的时候xxx_exit函数就会被调用。

           驱动编译完成以后扩展名为.ko,有两种命令可以加载驱动模块: insmodmodprobe,insmod是最简单的模块加载命令,此命令用于加载指定的.ko 模块,比如加载 drv.ko 这个驱动模块,命令如下:

    	insmod drv.ko
    

           insmod 命令不能解决模块的依赖关系,比如 drv.ko 依赖 first.ko 这个模块,就必须先使用insmod 命令加载 first.ko 这个模块,然后再加载 drv.ko 这个模块。但是 modprobe 就不会存在这个问题, modprobe 会分析模块的依赖关系,然后会将所有的依赖模块都加载到内核中,因此modprobe 命令相比 insmod 要智能一些。 modprobe 命令主要智能在提供了模块的依赖性分析、错误检查、错误报告等功能,推荐使用 modprobe 命令来加载驱动。 modprobe 命令默认会去/lib/modules/目录中查找模块,比如本书使用的 Linux kernel 的版本号为 4.1.15,因此 modprobe 命令默认到/lib/modules/4.1.15 这个目录中查找相应的驱动模块,一般自己制作的根文件系统中是不会有这个目录的,所以需要自己手动创建。驱动模块的卸载使用命令“rmmod”即可,比如要卸载 drv.ko,使用如下命令即可:

    	rmmod drv.ko
    

           也可以使用“modprobe -r”命令卸载驱动,比如要卸载 drv.ko,命令如下:

    	modprobe -r drv.ko
    

           使用 modprobe 命令可以卸载掉驱动模块所依赖的其他模块,前提是这些依赖模块已经没有被其他模块所使用,否则就不能使用 modprobe 来卸载驱动模块。所以对于模块的卸载,还是推荐使用 rmmod 命令。

    字符设备注册与注销

           对于字符设备驱动而言,当驱动模块加载成功以后需要注册字符设备,同样,卸载驱动模块的时候也需要注销掉字符设备。字符设备的注册和注销函数原型如下所示:

    static inline int register_chrdev(unsigned int major, const char *name,const struct file_operations *fops)
    static inline void unregister_chrdev(unsigned int major, const char *name)
    
    • register_chrdev 函数用于注册字符设备,此函数一共有三个参数,这三个参数的含义如下:
    • major: 主设备号, Linux 下每个设备都有一个设备号,设备号分为主设备号和次设备号两部分,关于设备号后面会详细讲解。
    • name:设备名字,指向一串字符串。
    • fops: 结构体 file_operations 类型指针,指向设备的操作函数集合变量。
    • unregister_chrdev 函数用户注销字符设备,此函数有两个参数,这两个参数含义如下:
    • major: 要注销的设备对应的主设备号。
    • name: 要注销的设备对应的设备名。

    一般字符设备的注册在驱动模块的入口函数 xxx_init 中进行,字符设备的注销在驱动模块的出口函数 xxx_exit 中进行。在下面代码中字符设备的注册和注销,内容如下所示:

    static struct file_operations test_fops;
    
    /* 驱动入口函数 */
    static int __init xxx_init(void)
    {
    	/* 入口函数具体内容 */
    	int retvalue = 0;
    
    	/* 注册字符设备驱动 */
    	retvalue = register_chrdev(200, "chrtest", &test_fops);
    	if(retvalue < 0){
    		/* 字符设备注册失败,自行处理 */
    	}
    	return 0;
    }
    
    /* 驱动出口函数 */
    static void __exit xxx_exit(void)
    {
    	/* 注销字符设备驱动 */
    	unregister_chrdev(200, "chrtest");
    }
    
    /* 将上面两个函数指定为驱动的入口和出口函数 */
    module_init(xxx_init);
    module_exit(xxx_exit);
    
    • 以上代码中,一开始定义了一个 file_operations 结构体变量 test_fops, test_fops 就是设备的操作函数集合,只是此时我们还没有初始化 test_fops 中的 open、 release 等这些成员变量,所以这个操作函数集合还是空的。
    • 第十行,调用函数 register_chrdev 注册字符设备,主设备号为 200,设备名字为“chrtest”,设备操作函数集合就是第 1 行定义的 test_fops。要注意的一点就是,选择没有被使用的主设备号,输入命令cat /proc/devices可以查看当前已经被使用掉的设备号。
    • 第二十一行,调用函数 unregister_chrdev 注销主设备号为 200 的这个设备。

    实现设备的具体操作函数

           file_operations 结构体就是设备的具体操作函数,在示例代码 40.2.2.1 中我们定义了file_operations结构体类型的变量test_fops,但是还没对其进行初始化,也就是初始化其中的open、release、 read 和 write 等具体的设备操作函数。本节小节我们就完成变量 test_fops 的初始化,设置好针对 chrtest 设备的操作函数。在初始化 test_fops 之前我们要分析一下需求,也就是要对chrtest 这个设备进行哪些操作,只有确定了需求以后才知道我们应该实现哪些操作函数。假设对 chrtest 这个设备有如下两个要求:
    1、能够对 chrtest 进行打开和关闭操作
           设备打开和关闭是最基本的要求,几乎所有的设备都得提供打开和关闭的功能。因此我们需要实现 file_operations 中的 open 和 release 这两个函数。
    2、对 chrtest 进行读写操作
           假设 chrtest 这个设备控制着一段缓冲区(内存),应用程序需要通过 read 和 write 这两个函数对 chrtest 的缓冲区进行读写操作。所以需要实现 file_operations 中的 read 和 write 这两个函数。需求很清晰了,修改驱动示例代码在其中加入 test_fops 这个结构体变量的初始化操作,完成以后的内容如下所示:

    /* 打开设备 */
    static int chrtest_open(struct inode *inode, struct file *filp)
    {
    	/* 用户实现具体功能 */
    	return 0;
    }
    /* 从设备读取 */
    static ssize_t chrtest_read(struct file *filp, char __user *buf,
    size_t cnt, loff_t *offt)
    {
    	/* 用户实现具体功能 */
    	return 0;
    }
    
    /* 向设备写数据 */
    static ssize_t chrtest_write(struct file *filp,
    const char __user *buf,
    size_t cnt, loff_t *offt)
    {
    	/* 用户实现具体功能 */
    	return 0;
    }
    /* 关闭/释放设备 */
    static int chrtest_release(struct inode *inode, struct file *filp)
    {
    	/* 用户实现具体功能 */
    	return 0;
    }
    
    static struct file_operations test_fops = {
    	.owner = THIS_MODULE,
    	.open = chrtest_open,
    	.read = chrtest_read,
    	.write = chrtest_write,
    	.release = chrtest_release,
    };
    
    /* 驱动入口函数 */
    static int __init xxx_init(void)
    {
    	/* 入口函数具体内容 */
    	int retvalue = 0;
    	
    	/* 注册字符设备驱动 */
    	retvalue = register_chrdev(200, "chrtest", &test_fops);
    	if(retvalue < 0){
    		/* 字符设备注册失败,自行处理 */
    	}
    	return 0;
    }
    
    /* 驱动出口函数 */
    static void __exit xxx_exit(void)
    {
    	/* 注销字符设备驱动 */
    	unregister_chrdev(200, "chrtest");
    }
    
    /* 将上面两个函数指定为驱动的入口和出口函数 */
    module_init(xxx_init);
    module_exit(xxx_exit);
    
    • 在上面代码中,我们一开始编写了四个函数:chrtest_openchrtest_readchrtest_writechrtest_release。这四个函数就是 chrtest 设备的 open、 read、 write 和 release 操作函数。第 29行~35 行初始化 test_fops 的 open、read、 write 和 release 这四个成员变量。

    添加LICENSE和作者信息

           在驱动编写最后,我们需要在驱动中加入LICENSE信息和作者信息,其中LICENSE是必须添加的,否则的话编译时会报错,作者信息可以添加也可以不添加。 LICENSE 和作者信息的添加使用如下两个函数:

    	MODULE_LICENSE() //添加模块 LICENSE 信息
    	MODULE_AUTHOR() //添加模块作者信息
    

           给示例代码加入 LICENSE 和作者信息,完成以后的内容如下:

    /* 打开设备 */
    static int chrtest_open(struct inode *inode, struct file *filp)
    {
    	/* 用户实现具体功能 */
    	return 0;
    }
    ......
    
    /* 将上面两个函数指定为驱动的入口和出口函数 */
    module_init(xxx_init);
    module_exit(xxx_exit);
    
    MODULE_LICENSE("GPL");//LICENSE 采用 GPL 协议。
    MODULE_AUTHOR("wly");//添加作者名字
    

           当添加完作者和LICENSE和作者信息后,字符设备驱动的完整流程就基本上结束了,并且也提供了一个完整的Linux驱动的模板,以后字符设备驱动开发就可以修改这个模板。

    Linux设备号

           Linux的设备管理是和文件系统紧密结合的,各种设备都以文件的形式存放在/dev目录下,称为设备文件。应用程序可以打开、关闭和读写这些设备文件,完成对设备的操作,就像操作普通的数据文件一样。为了管理这些设备,系统为设备编了号,这个号就被称为Linux设备号!

    设备号的组成

           设备号由主设备号和次设备号两部分组成,主设备号表示某一个具体的驱动,次设备号表示使用这个驱动的各个设备。 Linux 提供了一个名为 dev_t 的数据类型表示设备号, dev_t 定义在文件include/linux/types.h 里面,定义如下:

    typedef __u32 __kernel_dev_t;
    ......
    typedef __kernel_dev_t dev_t;
    

           可以看出 dev_t 是__u32 类型的,而__u32 定义在文件 include/uapi/asm-generic/int-ll64.h 里面,定义如下:

    typedef unsigned int __u32;
    

           dev_t 其实就是 unsigned int 类型,是一个 32 位的数据类型。这 32 位的数据构成了主设备号和次设备号两部分,其中高 12 位为主设备号,第 20 位为次设备号。因此 Linux系统中主设备号范围为0~4095,所以大家在选择主设备号的时候一定不要超过这个范围。在文件 include/linux/kdev_t.h 中提供了几个关于设备号的操作函数(本质是宏),如下所示:

    #define MINORBITS 20
    #define MINORMASK ((1U << MINORBITS) - 1)
    #define MAJOR(dev) ((unsigned int) ((dev) >> MINORBITS))
    #define MINOR(dev) ((unsigned int) ((dev) & MINORMASK))
    #define MKDEV(ma,mi) (((ma) << MINORBITS) | (mi))
    
    • 第 1 行,宏 MINORBITS 表示次设备号位数,一共是 20 位。
    • 第 2 行,宏 MINORMASK 表示次设备号掩码。
    • 第 3 行,宏 MAJOR 用于从 dev_t 中获取主设备号,将 dev_t 右移 20 位即可。
    • 第 4 行,宏 MINOR 用于从 dev_t 中获取此设备号,取 dev_t 的低 20 位的值即可。
    • 第 5 行,宏 MKDEV 用于将给定的主设备号和次设备号的值组合成 dev_t 类型的设备号。

    设备号的分配

    1、静态分配设备号

    注册字符设备的时候需要给设备指定一个设备号,这个设备号可以是驱动开发者静态的指定一个设备号,比如选择 200 这个主设备号。有一些常用的设备号已经被 Linux 内核开发者给分配掉了,具体分配的内容可以查看文档 Documentation/devices.txt。并不是说内核开发者已经分配掉的主设备号我们就不能用了,具体能不能用还得看我们的硬件平台运行过程中有没有使用这个主设备号,使用cat /proc/devices命令即可查看当前系统中所有已经使用了的设备号。

    2、动态分配设备号

    静态分配设备号需要我们检查当前系统中所有被使用了的设备号,然后挑选一个没有使用的。而且静态分配设备号很容易带来冲突问题, Linux 社区推荐使用动态分配设备号,在注册字符设备之前先申请一个设备号,系统会自动给你一个没有被使用的设备号,这样就避免了冲突。卸载驱动的时候释放掉这个设备号即可,设备号的申请函数如下:

    int alloc_chrdev_region(dev_t *dev, unsigned baseminor, unsigned count, const char *name)
    
    • dev:保存申请到的设备号。
    • baseminor: 次设备号起始地址, alloc_chrdev_region 可以申请一段连续的多个设备号,这些设备号的主设备号一样,但是次设备号不同,次设备号以 baseminor 为起始地址地址开始递增。一般 baseminor 为 0,也就是说次设备号从 0 开始。
    • count: 要申请的设备号数量。
    • name:设备名字。

    注销字符设备之后要释放掉设备号,设备号释放函数如下:

    void unregister_chrdev_region(dev_t from, unsigned count)
    
    • from:要释放的设备号。
    • count: 表示从 from 开始,要释放的设备号数量。

           不积小流无以成江河,不积跬步无以至千里。而我想要成为万里羊,就必须坚持学习来获取更多知识,用知识来改变命运,用博客见证成长,用行动证明我在努力。
           如果我的博客对你有帮助、如果你喜欢我的博客内容,记得“点赞” “评论” “收藏”一键三连哦!听说点赞的人运气不会太差,每一天都会元气满满呦!如果实在要白嫖的话,那祝你开心每一天,欢迎常来我博客看看。
    在这里插入图片描述

    展开全文
  • arm linux 安装 JRE

    千次阅读 2018-03-24 22:34:55
    arm linux 安装 JRE arm linux (非发行版)安装JDK和ubuntu上安装还是挺不一样的。现在ubuntu好像也可以在arm上运行,如果用ubuntu还是很方便的,但是好像ubuntu的arm版不太稳定,而且主要是现在用的板子系统...
  • openssl移植到ARM Linux

    万次阅读 2017-07-04 16:06:41
    openssl 移植 ARM Linux
  • libnl移植到ARM Linux

    千次阅读 2017-07-04 14:51:50
    libnl 移植 ARM Linux
  • 最近在开发基于arm linux的集中器,出于保护系统的目的,需要给系统设置登录用户名和密码,因此就在网上查询了下怎样给嵌入式arm linux系统设置登录用户名和密码的方法,结果如下: 设置登录用户和用户密码,在/etc...
  • I.MX6ULL ARM Linux学习笔记

    千次阅读 2020-02-21 10:06:01
    I.MX6ULL ARM Linux学习笔记写在前面 写在前面 本文章为我在学习I.MX6ULL ARM Linux时的记录文章,知识来源为《正点原子阿尔法 I.MX6ULL ARM Linux开发板》的视频教程和野火《i.MX Linux开发实战指南》的视频和电子...
  • PCL arm linux 源码安装

    千次阅读 2016-10-18 10:23:57
    PCL arm linux 源码安装PCL(Point Cloud Library)点云库,计算机视觉在3D方面的地位相当于OpenCV。 由于PCL在Ubuntu的软件源中只有x86架构的包,所以arm下只能通过源码编译。 系统:Ubuntu14.04 LTS CPU:Tegra ...
  • arm linux 移植全部过程

    千次阅读 2019-05-19 11:56:41
    arm linux 移植全部过程总述功能快捷键合理的创建标题,有助于目录的生成如何改变文本的样式插入链接与图片如何插入一段漂亮的代码片生成一个适合你的列表创建一个表格设定内容居中、居左、居右SmartyPants创建一个...
  • linux 内核学习3-自己编译一个ARM Linux内核 1. 目的 编译一个ARM版本的内核镜像,谁让我是做Android的呢!并且在QEMU上运行。 2. 准备工作 2.1 开发环境 ubuntu 18.4虚拟机 linux内核版本 4.19.67 linux内核地址 ...
  • QEMU搭建arm Linux开发环境

    千次阅读 2018-03-19 00:25:25
    为什么使用QEMU学习ARM LINUX ? 嵌入式80%的知识体系和技能,都可以脱离“开发板”,在QEMU仿真平台上学习和练习 1 仿真ARM处理器:ARM926E、ARM1136、Cortex-A8/A9… 2 模拟真实的开发板、外设:串口、LCD、网卡...
  • ARM Linux 更新启动画面

    千次阅读 2016-01-29 15:42:04
    通常默认情况下Linux只是输出一些传统的小企鹅图标和启动Console命令行,但嵌入式设备都需要定制自己开机画面,这里就以Toradex ARM计算机模块及其发布Linux 为例对ARM Linux更新启动画面做说明。 1). 配置 开发...
  • 使用CMake交叉编译Arm Linux程序

    千次阅读 2020-01-30 14:20:40
    我们平常使用CMake时,主要是在x86或x86_64平台上,其实CMake在2.6版本后就已经支持交叉编译了,下面就来看下如何使用CMake进行Arm Linux程序的交叉编译。 一 建立工程 按照如下结构体建立一个简单工程 main.c内容...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 59,318
精华内容 23,727
关键字:

armlinux

linux 订阅