基于ZYNQ芯片的外设驱动技术方案

一、BootLoader的移植制作 (2)

1、生成uboot.elf文件 (3)

2、system.bit生成 (5)

3、创建fsbl (8)

4、生成BOOT.BIN (9)

二、配置并编译linux内核 (10)

1、修改设备树内容 (10)

2、配置编译linux内核 (12)

三、Linux设备驱动移植 (14)

1、Linux设备驱动模型 (14)

2、Linux设备驱动移植 (15)

在嵌入式操作系统中，BootLoader是在操作系统内核运行之前运行。可以初始化硬件设备、建立内存空间映射图，从而将系统的软硬件环境带到一个合适状态，以便为最终调用操作系统内核准备好正确的环境。在嵌入式系统中，通常并没有像BIOS那样的固件程序（注，有的嵌入式CPU也会内嵌一段短小的启动程序），因此整个系统的加载启动任务就完全由BootLoader来完成。在一个基于zynq的嵌入式Linux系统中，系统在上电或复位时通常都从地址0x00000000处开始执行，而在这个地址处安排的通常就是系统的BootLoader程序。

想要在zynq芯片上顺利启动Linux并且驱动相关模块正常工作，首先需要正确移植BootLoader。作为初始化硬件平台的一段Bare Metal代码，Bootloader的移植也并入了我们的工作。所以综合起来说，我们的工作主要分为了三个部分：Bootloader的移植以及Linux内核和设备驱动的移植。

在进行移植工作之前，首先要做的是要在宿主机上面搭建好我们目标板的开发平台，以及下载好uboot源代码，Linux内核源代码以及相关驱动源代码。（有的模块的驱动源代码在Linux内核源代码中已经包含进去了，那么就不用单独下载。需要下载的驱动源代码只是针对标准Linux内核中不支持的部件而言。）

一、BootLoader的移植制作

每一种操作系统都需要有自己的引导程序，最为人们所知的就是Windows 的BIOS。缺失了这一部分，系统将无法正常启动。对比与Windows的BIOS，android系统拥有自己的专属的BootLoader，它主要负责初始化系统平台的硬件设备，建立内存空间的映射关系。在它完成初始化工作之后，继续负责把内核镜像和yaffs2格式的文件系统从SD卡载入到RAM中，完成Linux内核和文件系统的加载并设置内核的启动参数，紧接着启动内核。等到内核真正启动了之后，BootLoader就杀死自己，把CPU让出给内核使用。之后内核根据硬件环境做出系统初始化设置，并将CPU转让给yaffs2文件系统运行管理。至此，Linux系统成功的启动起来。下图1为bootloader的启动过程。

图1 BootLoader 启动流程

在我们移植的BootLoader 中，由于XC7Z020-CLG484-1包含了可编程逻辑（PL ）和处理系统（PS ）两个部分，所以它的启动过程与一般的BootLoader 稍有不同。BootLoader 在它的启动过程中需要负责配置可编程逻辑（PL ）和处理系统（PS ）这两个部分。使用Xilinx 官方提供的SDK 生成的BOOT.BIN 文件包含了fsbl(first stage boot loader)文件、system.bit 文件和uboot.elf 文件，其中fsbl 文件主要用来加载system.bit 并且配置处理系统（PS ），而system.bit 文件起到了配置可编程逻辑（PL ）的作用，注意该文件其实并不是必要的，如果在生成BOOT.BIN 的过程中缺少该文件，那么PL 部分得不到配置，那么我们只是相当于把XC7Z020-CLG484-1当成ARM 来使用。之后系统开始加载ssbl(second stage boot loader)到RAM 中，即uboot.elf 文件，它主要作用是加载内核镜像到RAM 中。如下图所示。

1、生成uboot.elf 文件

Uboot 源码的主要目录及其描述

上电

基本硬件初始化

读取loader 信息计算loader 的二进制checksum 检测checksum 的正确性

检测是否有内核文件

扩展功能所需硬件初始化拷贝内核镜像至SDRAM

跳转至内核镜像

正确

有

输出错误信息

错误

进入下载

模式

无

上电基本硬件初始化读取loader 信息计算loader 的二进制checksum 检测checksum 的正确性检测是否有内核文件扩展功能所需硬件初始化拷贝内核镜像至SDRAM 跳转至内核镜像正确有输出错误信息错误进入下载模式无2

1

2

BOOT.BIN

FSBL

system.bit

uboot

加载system.bit

配置PS 配置PL

加载内核镜像

cpu 与处理器相关的文件。每个子目录中都包括cpu.c 和interrupt.c、start.S、u-boot.lds。

cpu.c：初始化CPU、设置指令Cache和数据Cache 等

interrupt.c：设置系统的各种中断和异常start.S ：是U-boot启动时执行的第一个文件，它主要做最早期的系统初始化，代码重定向和设置系统堆栈，为进入U-boot第二阶段的C程序奠定基础。

u-boot.lds：链接脚本文件，对于代码的最后组装非常重要。

board 已经支持的所有开发板相关文件，其中包含SDRAM 初始化代码、Flash底层驱动、板级初始化文件。其中的config.mk文件定义了TEXT_BASE，也就是代码在内存的实际地址，非常重要。

common 与处理器体系结构无关的通用代码，U-boot的命令解析代码/common/command.c、所有命令的上层代码cmd_*.c、U-boot环境变量处理代码env_*.c 等都位于该目录下

drivers 包含几乎所有外围芯片的驱动，网卡、USB、串口、LCD、Nand Flash等等

include 头文件，包括各CPU的寄存器定义，文件系统、网络等等

configs子目录下的文件是与目标板相关的配置头文件

根据上表可知，在进行uboot移植的过程中需要把相关目录下与目标平台相关的配置文件进行相应的修改，同时集成各种函数库以及驱动程序的支持。我们使用make zynq_zed_config来配置uboot，修改代码的目录列举如下：和处理器相关级别的代码：

u-boot/arch/arm/cpu/armv7/start.S

u-boot/arch/arm/cpu/armv7/Makefile

u-boot/arch/arm/include/asm/hardware.h

u-boot/arch/arm/lib/board.c

u-boot/arch/arm/lib/Makefile u-boot/arch/arm/config.mk

和板级相关的代码：

u-boot/board/xilinx/zynq_common/tools/image.c u-boot/board/xilinx/zynq_common/lowlevel_init.S u-boot/board/xilinx/zynq_common/mem_setup.S u-boot/board/xilinx/zynq_common/mmc_boot.c u-boot/board/xilinx/zynq_common/Makefile u-boot/board/xilinx/zynq_common/nand.c

u-boot/board/xilinx/zynq_common/nand/Makefile u-boot/spl/Makefile u-boot/boards.cfg u-boot/config.mk u-boot/Makefile

修改完成上述代码之后，需要在Makefile 文件中添加并指定交叉编译器名称和目标平台的类型，比如在我们的XC7Z020-CLG484-1平台下，应该指定为： make ARCH=arm CROSS_COMPILE=arm-xilinx-linux-gnueabi-

make 完成后会在根文件目录下生成uboot 文件，我们需要强制将其文件名改为uboot.elf ，以便Xilinx ISE 组件里面的SDK 能够识别并用于生成BOOT.BIN 。

2、system.bit 生成

在现有的Digilent 官网提供的基于XC7Z020-CLG484-1能够正常运行的linux 设计包ZedBoard_OOB_Design 中，已经包含了最重要的系统组件的驱动程序，如串口、网口，USB 等接口。

针对该设计包，我们需要根据我们的硬件环境进行适当的修改使之能够在我们的平台上运行，例如添加并打开模块所需要的SDIO1通道。由于zynq 芯片内部有54个MIO 的引脚，这些引脚在满足数量的情况下可以分配给SDIO 、SPI 或者Ethernet 等外部设备，SD/SDIO 的控制系统如下图所示。故我们可以使用MIO 接口来将SDIO1的通道引出到芯片外部，同时不需要我们自己添加约束文件。

SDIO 接口控制器

控制寄存器

MIO-EMIO 布线

外部设备MIO 引脚

...

PL

EMIO

SDIO 参考时钟

Interconnect

AHB slave port

Interconnect

AHB master port

中断号{56,79}

CPU_1x 时钟

SDIO{0,1}CPU_1x 复位

SD/SDIO 控制系统图

下表展示了SDIO接口与MIO的连接方式。

SDIO接口默认控制

器输入值

MIO引脚

引脚号I/O

SDIO0 时钟信号0

16, 28, 40 IO ~

SDIO0 控制信号0

17, 29, 41 IO ~

SDIO0 Data0 0

18, 30, 42 IO ~

SDIO0 Data1 0

19, 31, 43 IO ~

SDIO0 Data2 0

20, 32, 33 IO ~

SDIO0 Data3 0

21, 33, 45 IO ~

SDIO0 卡检测除了7和8外的所

有引脚

I

SDIO0 写保护除了7和8外的所

有引脚

I

SDIO1 时钟信号0

12, 24, 36, 48 IO ~

SDIO1 控制信号0

11, 23, 35, 47 IO ~

SDIO1 Data0 0

10, 22, 34, 46 IO ~

SDIO1 Data1 0

13, 25, 37, 49 IO ~

SDIO1 Data2 0

14, 26, 38, 50 IO ~

SDIO1 Data3 0

15, 27, 39, 51 IO ~

SDIO1 卡检测除了7和8外的所

有引脚

I

SDIO1 写保护除了7和8外的所I

有引脚

根据查询上表的内容，我们结合第二章的图？，将SDIO1与MIO通道进行了如下的分配。

IO 外设信号

MIO 10 SDIO 1 data[0]

MIO 11 SDIO 1 cmd

MIO 12 SDIO 1 clk

MIO 13 SDIO 1 data[1]

MIO 14 SDIO 1 data[2]

MIO 15 SDIO 1 data[3]

MIO 16 SDIO 1 SD1_cd 在Xilinx Platform Studio中配置好上述MIO接口之后，确保zynq的系统图和MIO接口图如下所示，就可以开始生成网格以及system.bit比特流文件了。

3、创建fsbl

在成功生成比特流文件system.bit以后，我们需要将该设计导出到SDK中进

行fsbl的创建以及BOOT.BIN的生成。点击上图中Export Design，并选择：

在SDK中，我们需要创建FSBL类型的程序，用来初始化PS部分。

查看fsbl工程的代码，它同其它裸机代码一样都有一个main主函数入口，

但是由于在fsbl加载之后，处理器PS部分并没有执行C代码的能力，而是只能

执行简单的汇编代码，我们可以在

zynq_fsbl_bsp==>ps7_cortexa9_0==>libsrc==>standalone_v3_07_a==>src里找到asm_vector.S，它包含了BSP所提供的汇编指令。它在零地址处给出了一个如下的代码段，在系统上电之后，PS部分会自动跳转到零地址并执行该地址的汇编

指令。

.section .vectors

_vector_table:

B _boot

B Undefined

B SVCHandler

B PrefetchAbortHandler

B DataAbortHandler

NOP

B IRQHandler

B FIQHandler

第一句话B _boot就是一个跳转指令，指示处理器应该跳转到boot.S汇编代码中执行_boot下的代码段，该代码段作用在于对系统进行初始化。完成该代码段之后，此时PS就具备了执行C代码的能力了。在_boot代码段的最后又有一个跳转指令，此时将跳转至xil.crt0.S中的_start代码段，该代码段将继续对系统进行初始化设置，我们可以看到，该代码第一段就是执行一个初始化CPU的动作。

_start:

bl __cpu_init

mov r0, #0

ldr r1, .Lsbss_start

ldr r2, .Lsbss_end

mov r0, #0

mov r1, #0

bl main

在_start代码段的末尾，再次进行一次跳转，不过这次是将PS跳转到main 函数并开始执行。至此，系统根据main函数的代码开始初始化MIO，PLL，CLOCK，DDR等外部设备。

4、生成BOOT.BIN

最后在Xilinx SDK中，选择Create Boot Image选项，并将上面生成的三个文件uboot.elf、system.bit以及fsbl文件添加进去，点击生成BOOT.BIN。此文件即是我们需要的BootLoader。

二、配置并编译linux内核

1、修改设备树内容

自linux3.x版本之后，嵌入式linux开始使用设备树的方式来存储目标板的硬件配置信息。设备树是一种用来阐述目标板硬件结构设备信息的二进制文件，它提供了一种方法，基于该方法可以轻松的将目标板的各种外设转换为以数据驱动，而非以前内核中所使用的硬编码方式。

在Linux内核开始使用设备树之前，编译过的内核包含了对于硬件的全部描

述，BootLoader 只是单独的加载一个以二进制文件存在的内核镜像。此外，BootLoader 还需要通过r2寄存器将存有额外信息的ATAGS 的指针传递给内核，以及通过r1寄存器传递机器码的方式通知内核当前在什么设备商被启动。而如今的Linux 内核中不再包含对于硬件的描述，这部分已经被搬移到dtb(与Linux 内核独立的设备树二进制文件)中了。所以如今的BootLoader 又增加了加载设备树二进制文件的功能，BootLoader 通过r2寄存器传递dtb 文件的地址。如下图所示。

zImage

ATAGS

RAM r1=

r2=

zImage

DTB

RAM r1=忽略

r2=

在ARM 平台中，所有设备树源代码都存储在arch/arm/boot/dts ，其中包含了两种源代码dts 和dtsi ，

※ .dts 板级定义。

※ .dtsi 为dts 文件所需要包含的头文件，通常该文件包含了SoC 级别定义。 这两种文件都遵循了相同的设备树源文件的语法规则，如下图。

/ { node@0 {

a-string-property = "A string";

a-string-list-property = "first string", "second string"; a-byte-data-property = [0x01 0x23 0x34 0x56];

child-node@0 {

first-child-property;

second-child-property = <1>;

a-reference-to-something = <&node1>; };

child-node@1 {

};

};

node1: node@1 {

an-empty-property;

a-cell-property = <1 2 3 4>;

child-node@0 { }; };};

节点名

单元地址

属性名称

属性值node0的属性

字节字符

pHandle

节点标签

设备树基本语法

我们可以在arch/arm/boot/dts/目录下找到digilent-zed.dts设备树源码，另外在OOB设计中也可以找到devicetree.dts设备树源码。由于ZedBoard和我们的目标板都是采用相同的主控芯片XC7Z020-CLG484-1，我们选用OOB里面的设备树源码更接近我们的目标板硬件环境的设备树源码，由于wifi模块是我们自己添加的，在OOB设计中并没有定义，所以需要针对该模块对设备树源码中的以下节点进行添加修改。

ps7_sd1: sdhci@e0101000 {

compatible = "xlnx,ps7-sdhci-1.00.a";

reg = <0xe0101000 0x1000>;

interrupts = <0 37 0>;

interrupt-parent = <&gic>;

xlnx,has-cd = <0x1>;

clock-frequency = <0x1fc9f08>;

};

2、配置编译linux内核

下载linux内核源码：

Linux内核源码非常庞大，对于可以适用于Android的版本就有数种之多，可见下表。

内核版本描述

Mainline Kernel 这种内核可以从主线(https://www.360docs.net/doc/cd14009035.html,)进行下载，它是没有经过修改的最原始的内核版本。

Reference Kernel 这是针对各种开发板的内核，一般是把Mainline Kernel打上针对具体开发板的内核补丁而得到

的内核版本。

Merged Kernel 这种内核是打上了Android内核补丁的Reference Kernel，这种内核可以支持Android系统。

Android Patches

该补丁由Google公司发布，是Mainline Kernel 导入到Android内核中所得到的补丁，具体可以参考https://www.360docs.net/doc/cd14009035.html,的介绍。

Android Kernel 这种内核可以从谷歌的Android开源项目资料库中下载而得，该内核里面包含了Google对Mainline Kernel进行的修改。

Android使用了linux作为它的内核，通常情况下开发板都提供了根据自身开发板硬件环境能够驱动起来的linux内核，Digilent公司为我们提供了基于XC7Z020-CLG484-1的zynq的linux内核源码，它在GitHub上的网址为：https://https://www.360docs.net/doc/cd14009035.html,/Digilent/linux-digilent。我们可以使用git clone的方式从该仓库中下载该源码。

git clone https://https://www.360docs.net/doc/cd14009035.html,/Digilent/linux-digilent.git kernel

上述命令将会将该git仓库的代码克隆到kernel目录下。下载完成后，需要切换到zynq分支：

cd kernel

git checkout -b zedboard_oob v3.3.0-digilent-12.07-zed-beta

下载好内核源码之后，我们可以看到如下的结构组织，该表包含了几个比较重要的目录以及它所包含的内容的描述。

目录描述

arch 关于体系结构相关的所有代码。

block 块设备的通用函数库。

fs 存放了Linux所支持的文件系统代码，以及各种类型的文件操

作代码

include 目录包括编译核心所需要的大部分头文件，如基本头文件和驱

动或功能部件头文件。

drivers 所有Linux内核支持的设备的驱动程序源代码。当然也可以自己添加特定设备的源代码到该目录中。

kernel 内核管理的核心代码，此目录下的文件实现了大多数linux系统的内核函数，其中最重要的文件当属sched.c；同时与处理器结构相关代码都放在arch/*/kernel目录下。

lib 内核库函数的代码库。

mm 所有独立于处理器体系架构的内存管理代码。

ipc 内核中进程间通信的实现代码。

net 网络相关的代码。

在编译linux内核之前，我们先进行内核的配置，通过配置内核可以对内核进行适当的剪裁，使得系统在可以运行并且满足功能要求的前提下得到最小化，这在资源有限的嵌入式平台中是非常重要的。

因为我们需要在X86平台编译Linux的内核，所以我们需要用到前面提到的交叉编译环境。同样，在编译内核时我们需要指定CPU架构以及交叉编译工具。

由于Linux内核比较庞大，有很多的选项我们都不需要使用到。如果需要我们自己手动去一项一项的配置，那么将是一项非常冗杂的工作。不过好在针对我们的硬件环境，Digilent公司为我们提供了专门的配置文件，在终端执行以下命令即可。

make digilent_zed_defconfig

现在基本的内核配置已经完成了。我们执行下述命令就可以执行内核的编译。

make ARCH=arm CROSS_COMPILE=arm-xilinx-linux-gnueabi-

在编译过程中，可能会出现各种各样的错误，这些错误大多是由于宿主机没有安装好相关的依赖包导致的，在网上很容易找到解决的办法。

三、Linux设备驱动移植

Linux 设备驱动的移植需要对Linux 设备驱动的模型和Linux 设备驱动的初始化过程有一定了解。我们首先通过对Linux 设备驱动的初始化过程的简单介绍来描述Linux 设备驱动模型，然后再详细阐述驱动具体移植步骤。

1、Linux设备驱动模型

在对处理器完成一些如MMU、Cache、控制寄存器和页表等基本的初始化以后，系统调用函数start_kernel()来进行内核子系统的初始化。Start_kernel()比较复杂，在该函数的最后，调用了函数rest_init()。在rest_init()中，系统通过kernel_thread()函数创建了一个名叫kernel_init()的内核线程，设备模型初始化相关的重要函数do_basic_setup()就出现在这个函数中。其中，函数driver_init()用来建立设备模型子系统，而do_initcalls()函数完成包括设备在内的所有初始化函数的调用。

其中driver_init()的源代码如下：

void __init driver_init(void)

{

/* These are the core pieces */

devtmpfs_init();

devices_init();

buses_init();

classes_init();

firmware_init();

hypervisor_init();

/* These are also core pieces, but must come after the

* core pieces.

*/

platform_bus_init();

system_bus_init();

cpu_dev_init();

memory_dev_init();

}

由上面代码可以看出，设备模型的初始化分为两个部分，后面一部分必需先于前一部分完成。下面分别对这10个函数的功能做简单的介绍。

1. Devtmpfs_init() 函数的主要功能是用来创建设备文件系统，类型为

dev_fs_type。每个核心设备都会注册设备结点到这个文件系统下。Devfs文件系统被挂载到/dev 目录。

2. Devices_init()函数中完成对设备子系统的初始化。具体表现为将devices、dev、block、char 等kset、kobject 对象分别添加到sysfs 系统中。函数执行完成后，就在/sys 目录下建立devices 和dev 的目录项，block、char 两种类型也

被添加到其中。

3. Buses_init()为总线子系统创建kset 对象，并将其添加到sysfs 中。

4. Class_init()为类子系统创建kset 对象，并将其添加到sysfs 中。

5. Fireware_init()为firmware 子系统创建kobject 对象，并将其添加到sysfs 中。

6. hypervisor_init()为hypervisor 子系统创建kobject 对象，并将其添加到sysfs中。

7. Platform_bus_init()函数是整个设备子系统初始化过程中非常重要的一个函数。从功能上面来说，它完成了platform总线的初始化。platform device driver 机制由两部分组成：platform_device 和platform_driver。该机制下开发设备驱动的大致流程如图所示：

开始

定义平台设备

注册平台设备

定义平台驱动

注册平台驱动

结束

图设备驱动开发流程

8. System_bus_init()函数跟platform_bus_init()类似，区别在于此函数初始化的是系统总线。

9. Cpu_dev_init()函数的作用是在前面初始化完成的基础上，对cpu 系统设备进行注册。

10. Memery_dev_init()函数的作用同上，是向设备文件系统添加对存储设备的支持。

通常情况下只要和内核本身运行依赖性不大，拥有各自的地址总线和中断号等资源的外围设备，都可以用platform_driver实现。如：LCD、TouchScreen、KeyBoard、网卡、USB、UART 等。而如timer，irq 之类系统设备则一般不用platform_driver机制来实现。

2、Linux设备驱动移植

我们在Digilent网站下载而得到的Linux内核源代码里面，包含了Linux内

核本身以及以及BSP 和目标板硬件环境的系统驱动。它们都存放在drivers 目录下，只不过我们需要在剪裁配置内核的过程中将其包含进去，以达到驱动各种外部设备的目的。所以在我们下载得到的代码中，有许多现有的驱动已经集成在其中并且可以直接使用，我们将其列举在下表中。(具体可以参考https://www.360docs.net/doc/cd14009035.html,/Linux+Drivers)

下面我们以SD 卡控制器的驱动为例进行大致的分析。

SDIO 设备的驱动可以分为主从设备这两方面的驱动，对应于驱动SD 卡，我们的目标板上的zynq 相当于主设备，而SD 卡就相当于从设备。由于SD 卡只是一个具有存储功能的外部设备，所以只需要有主设备驱动(上表中表明SD 卡的驱动在host 目录下)，就可以驱动该模块正常工作。

组件 是否在主线

驱动位置

ADC 是

drivers/iio/adc/xilinx-xadc

以太网 是 drivers/net/ethernet/xilinx/xilinx_axienet_main.c drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c drivers/net/ethernet/xilinx/xilinx_axienet.h

GPIO 是 drivers/gpio/gpio-zynq.c I2C 控制器 是 drivers/i2c/busses/i2c-cadence.c NAND 否 drivers/mtd/nand/arasan_nfc.c PCIe 是 drivers/pci/host/pcie-xilinx.c arch/arm/mach-zynq/xaxipcie.c arch/arm/mach-zynq/xaxipcie-msi.c 否 否 QSPI 否 drivers/spi/spi-zynqmp-qspi.c SD 卡控制器 是 drivers/mmc/host/sdhci-of-xilinxps.c

SMC 控制器 否 drivers/memory/pl353-smc.c drivers/mtd/nand/pl353_nand.c SPI 控制器 是 drivers/spi/spi-cadence.c

串口

Zynq Ultrascale+

MPSoC 是 drivers/tty/serial/xilinx_uartps.c 串口axi_uartlite 是 drivers/tty/serial/uartlite.c USB(host)

否 drivers/usb/host/zynq-dr-of.c drivers/usb/host/ehci-zynq.c drivers/usb/chipidea/

否 是 USB(device) 否 drivers/usb/gadget/zynq_udc.c drivers/usb/chipidea/udc.c drivers/usb/chipidea/ci_hdrc_usb2.c

是 是 USB(OTG) 是 drivers/usb/phy/phy-zynq-usb.cdrivers/usb/chipi

dea

看门狗

是

drivers/watchdog/cadence_wdt.c

在linux系统中，将每个host设备封装成platform_device来逐一进行注册。在Linux内核完成了platform_device的注册之后，就应该来到对应的platform_driver的注册了，它的注册就是上表中列举的drivers/mmc/host/sdhci-of-xilinxps.c驱动文件中的如下代码：

static int __init sdhci_zynq_init(void){

return platform_driver_register(&sdhci_zynq_driver);

}

其中platform_driver_register(&sdhci_zynq_driver)中传入的参数sdhci_zynq_driver就是前面所述的platform_driver，它同样定义在该文件中：static struct platform_driver sdhci_zynq_driver = {

.driver = {

.name = "sdhci-zynq",

.owner = THIS_MODULE,

.of_match_table = sdhci_zynq_of_match,

.pm = SDHCI_PLTFM_PMOPS,

},

.probe = sdhci_zynq_probe,

.remove = __devexit_p(sdhci_zynq_remove),

};

对于sdhci_zynq_driver的注册过程中，内核首先会对platform_driver进行探测，首先会根据结构体中.driver的.name成员，亦即”sdhci-zynq”在platform_bus 总线上查找具有相同名字的platform_device，每一次找到具有相同名字”sdhci-zynq”的platform_device，就会调用一次sdhci_zynq_driver中的.probe即sdhci_zynq_probe函数，下面是该函数的主体：

static int __devinit sdhci_zynq_probe(struct platform_device *pdev)

{

int ret;

const void *prop = NULL;

struct device_node *np = pdev->dev.of_node;

struct sdhci_host *host = NULL;

ret = sdhci_pltfm_register(pdev, &sdhci_zynq_pdata);

if (ret == 0) {

prop = of_get_property(np, "xlnx,has-cd", NULL);

if (prop == NULL) {

host = platform_get_drvdata(pdev);

host->quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION;

} else if (!(u32) be32_to_cpup(prop)) {

host = platform_get_drvdata(pdev);

host->quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION;

}

} else

printk("sdhci platform registration failed\n");

return ret;

}

分析代码可以知道，该函数的主要功能是通过struct sdhci_host *host = NULL 构造出一个host，它是一个sdhci_host结构体的变量。紧接着根据sdhci-pltfm.c 中声明的sdhci_pltfm_register来，并调用sdhci_add_host来注册host，相关代码可以见下。然后根据传入的pdev->dev.of_node通过of_get_property来获取到相应节点的属性。然后判断prop的属性，并根据此属性调用platform_get_drvdata 来获取之前通过platform_set_drvdata保存的平台总线设备数据，并赋值给host。

int sdhci_pltfm_register(struct platform_device *pdev,

struct sdhci_pltfm_data *pdata)

{

struct sdhci_host *host;

int ret = 0;

host = sdhci_pltfm_init(pdev, pdata);

if (IS_ERR(host))

return PTR_ERR(host);

sdhci_get_of_property(pdev);

ret = sdhci_add_host(host);

if (ret)

sdhci_pltfm_free(pdev);

return ret;

}

所以下面我们需要分析sdhci_add_host，它的简化代码如下，我们只需要关注下面几行代码：

int sdhci_add_host(struct sdhci_host *host)

{

struct mmc_host *mmc;

mmc = host->mmc;

……

tasklet_init(&host->card_tasklet,sdhci_tasklet_card, (unsigned long)host);

tasklet_init(&host->finish_tasklet,sdhci_tasklet_finish, (unsigned long)host);

setup_timer(&host->timer, sdhci_timeout_timer, (unsigned long)host);

……

request_irq(host->irq, sdhci_irq, IRQF_SHARED,mmc_hostname(mmc), host);

……

mmc_add_host(mmc);

return 0;

}

可以看到，该函数在前面部分主要针对sdhci进行了必要的初始化和配置，最主要的还是最后的对mmc进行注册，mmc具有许多参数，我们先来看看mmc->ops = &sdhci_ops。

static const struct mmc_host_ops sdhci_ops = {

.request = sdhci_request,

.set_ios = sdhci_set_ios,

.get_ro = sdhci_get_ro,

.hw_reset = sdhci_hw_reset,

.enable_sdio_irq = sdhci_enable_sdio_irq,

.start_signal_voltage_switch = sdhci_start_signal_voltage_switch,

.execute_tuning = sdhci_execute_tuning,

.enable_preset_value = sdhci_enable_preset_value,

};

这些操作函数里面，request主要处理主设备向从设备发送的各种命令；set_ios 对从设备的电源和时钟频率等进行设置；get_ro用来检测从设备是否开启了写保护……

再回到sdhci_add_host函数，在注册中断的函数requset_irq中，host->irq取决于资源文件内部的irq参数，sdhci_irq就是我们需要的中断处理程序，而第三个参数是中断标志位，可以为IRQF_DISABLED、IRQF_SHARED和IRQF_SAMPLE_RANDOM三者之一，在本SD卡的程序中选用IRQF_SHARED，表示多个中断处理程序共享irq中断线。该函数内部mmc_add_host函数的功能是调用device_add把mmc设备注册到Linux设备，从而完成注册sdhci。

下面我们再来分析中断处理程序sdhci_irq：

static irqreturn_t sdhci_irq(int irq, void *dev_id)

{

……

intmask = sdhci_readl(host, SDHCI_INT_STATUS);

……

if (intmask & (SDHCI_INT_CARD_INSERT |

SDHCI_INT_CARD_REMOVE)) {

sdhci_writel(host, intmask & (SDHCI_INT_CARD_INSERT |

SDHCI_INT_CARD_REMOVE), SDHCI_INT_STATUS);

tasklet_schedule(&host->card_tasklet);

}

……

}

分析代码可以知道，该中断处理程序将首先将会读取NORINTSTSn寄存器当前的值，该寄存器中有两个比特位用来表示SD卡的insert和remove的动作。接着通过一个判断语句根据读取到的intmask来判断中断源对应的到底是insert 还是remove的操作，同时将这两个比特位清零，为下一次中断处理做好准备。

再次回到sdhci_add_host函数，在声明完成中断处理程序之后，程序将会调用sdhci_tasklet_card函数，该函数的作用很简单，就是通过判断是否有SD卡存在于SD卡插槽，如果有的话，就通过mmc_detect_change调用mmc_rescan函数，进而扫描该SD卡：

static void sdhci_tasklet_card(unsigned long param)

{

struct sdhci_host *host;

unsigned long flags;

bool present = true;

host = (struct sdhci_host*)param;

spin_lock_irqsave(&host->lock, flags);

/* Check host->mrq first in case we are runtime suspended */

if (host->mrq &&

!(sdhci_readl(host, SDHCI_PRESENT_STATE) &

SDHCI_CARD_PRESENT)) {

pr_err("%s: Card removed during transfer!\n",

mmc_hostname(host->mmc));

pr_err("%s: Resetting controller.\n",

mmc_hostname(host->mmc));

sdhci_reset(host, SDHCI_RESET_CMD);

sdhci_reset(host, SDHCI_RESET_DATA);

host->mrq->cmd->error = -ENOMEDIUM;

tasklet_schedule(&host->finish_tasklet);

}

spin_unlock_irqrestore(&host->lock, flags);

mmc_detect_change(host->mmc, msecs_to_jiffies(200));

}

void mmc_rescan(struct work_struct *work){

//定义好的扫描频率

static const unsigned freqs[] = { 400000, 300000, 200000, 100000 };

……

for( i = 0; i < ARRAY_SIZE(freqs); i++) {

if(!mmc_rescan_try_freq(host, max(freqs[i], host->f_min))){

extend_wakelock = true;

break;

}

if (freqs[i] <= host->f_min)

break;

}

……

}

在mmc_rescan函数中，扫描SD卡的过程发生在mmc_rescan_try_freq中，这个函数的第二个参数告诉了系统应该用什么样的频率去对SD卡进行扫描检测，当成功使用某一频率扫描到SD卡的时候，将会执行break退出扫描循环。下面是mmc_rescan_try_freq的代码：

static int mmc_rescan_try_freq(struct mmc_host *host, unsigned freq){ ……

sdio_reset(host);

mmc_go_idle(host);

mmc_send_of_cond(host, host->ocr_avail);

//检测的顺序依次是：SDIO、SD、MMC

if (!mmc_attach_sdio(host))

return 0;

if (!mmc_attach_sd(host))