Linux-uboot-学习笔记（9）：uboot硬件驱动
 
一、uboot与linux驱动
 
1、驱动是什么？
 
驱动的狭义概念：操作系统中用来具体操控硬件的那部分代码。裸机程序中是直接操控硬件的，而操作系统中必须通过驱动来操控硬件。
 裸机程序和驱动这两者同样都是控制硬件的，它们之间有什么区别呢？
 答：驱动有分层结构。
 
操作系统（指的是linux）下MMU肯定是开启的，也就是说linux驱动中肯定都使用的是虚拟地址。而纯裸机程序中根本不会开MMU，全部使用的是物理地址。这是裸机下和驱动中操控硬件的一个重要区别。
 因此在linux中使用驱动时，就要考虑虚拟地址这个问题，即要弄清楚虚拟地址映射表。
 
2、uboot和驱动的关系
 
linux驱动本身做了模块化设计。linux驱动本身和linux内核不是强耦合的，这是linux驱动可以被uboot借用（移植）的关键。
 uboot移植了linux驱动源代码。uboot是从源代码级别去移植linux驱动的，这就是linux系统的开源性。
 uboot中的硬件驱动比linux简单。linux驱动本身有更复杂的框架，需要实现更多的附带功能，而uboot本质上只是个裸机程序，uboot移植linux驱动时只是借用了linux驱动的一部分而已。
 
二、简单分析uboot驱动
 
我们知道，在uboot中有一部分是对SD卡/iNand进行读写操作，这其中离不开驱动设置。我们简单分析一下uboot中的控制MMC驱动，从而对驱动有个简单的理解。
 
mmc_initialize
 
若想控制mmc，首先要mmc进行初始化，该部分代码位于uboot/drivers/mmc/mmc.c。
 
MMC初始化应包含：SoC里的MMC控制器初始化（MMC系统时钟的初始化、SFR初始化）、SoC里MMC相关的GPIO的初始化、SD卡/iNand芯片的初始化。
 
 
cpu_mmc_init
 
 
s3c_hsmmc_initialize
 

 定义并且实例化一个struct mmc类型的对象（定义了一个指针，并且给指针指向有意义的内存，或者说给指针分配内存），然后填充它的各种成员，最后调用mmc_register函数来向驱动框架注册这个mmc设备驱动。
 驱动的设计中有一个关键数据结构。譬如MMC驱动的结构体就是struct mmc这些结构体中包含一些变量和一些函数指针，变量用来记录驱动相关的一些属性，函数指针用来记录驱动相关的操作方法。这些变量和函数指针加起来就构成了驱动。驱动就被抽象为这个结构体。
 
mmc_register功能是进行mmc设备的注册，注册方法其实就是将当前这个struct mmc使用链表连接到mmc_devices这个全局变量中去。
 我们在X210中定义了USE_MMC0和USE_MMC2，因此在我们的uboot初始化时会调用2次s3c_hsmmc_initialize函数，传递参数分别是0和2，因此完成之后系统中会注册上2个mmc设备，表示当前系统中有2个mmc通道在工作。
 
find_mmc_device
 

 这个函数其实就是通过mmc设备编号来在系统中查找对应的mmc设备（struct mmc的对象，根据上面分析系统中有2个，编号分别是0和2）。
 函数工作原理就是通过遍历mmc_devices链表，去依次寻找系统中注册的mmc设备，然后对比其设备编号和我们当前要查找的设备编号，如果相同则就找到了要找的设备。找到了后调用mmc_init函数来初始化它。通过分析可以看出，mmc_init函数内部就是依次通过向mmc卡发送命令码（CMD0、CMD2那些）来初始化SD卡/iNand内部的控制器，以达到初始化SD卡的目的。
 
总结，整体函数调用关系如下：
 
mmc_initialize(（MMC控制器初始化）
	cpu_mmc_init（SoC部分MMC控制器初始化）
		setup_hsmmc_clock（设置时钟）
		setup_hsmmc_cfg_gpio（配置GPIO）
		smdk_s3c_hsmmc_init
			s3c_hsmmc_initialize（构建mmc结构体）
	find_mmc_device（寻找注册的MMC设备）
	mmc_init（SD卡部分初始化）
		mmc_go_idle
			mmc_send_cmd（发送控制命令）
		mmc_send_if_cond
			mmc_send_cmd
	······
 
整个MMC系统初始化分为2大部分：SoC这一端的MMC控制器的初始化，SD卡这一端卡本身的初始化。前一步主要是在cpu_mmc_init函数中完成，后一部分主要是在mmc_init函数中完成。
 整个初始化完成后去使用sd卡/iNand时，操作方法和mmc_init函数中初始化SD卡的操作一样的方式。读写sd卡时也是通过总线向SD卡发送命令、读取/写入数据来完成的。
 struct mmc结构体是关键。两部分初始化之间用mmc结构体来链接的，初始化完了后对mmc卡的常规读写操作也是通过mmc结构体来链接的。
 
三、驱动设计思想
 
1、分离思想
 
一个驱动工作时主要就分几部分：驱动构建（构建一个struct mmc然后填充它）、驱动运行时（调用这些函数指针指针的函数和变量）。
 
 分离思想就是说在驱动中将操作方法和数据分开。操作方法就是函数，数据就是变量。所谓操作方法和数据分离的意思就是：在不同的地方来存储和管理驱动的操作方法和变量，这样的优势就是驱动便于移植。
 
2、分层思想
 
分层思想是指一个整个的驱动分为好多个层次。简单理解就是驱动分为很多个源文件，放在很多个文件夹中。譬如本课程讲的mmc的驱动涉及到drivers/mmc下面的2个文件和cpu/s5pc11x下的好几个文件。
 
以mmc驱动为例来分析各个文件的作用：
 uboot/drivers/mmc/mmc.c：本文件的主要内容是和MMC卡操作有关的方法，譬如MMC卡设置空闲状态的、卡读写数据等。但是本文件中并没有具体的硬件操作函数，操作最终指向的是struct mmc结构体中的函数指针，这些函数指针是在驱动构建的时候和真正硬件操作的函数挂接的（真正的硬件操作的函数在别的文件中）。
 uboot/drivers/mmc/s3c_hsmmc.c:本文件中是SoC内部MMC控制器的硬件操作的方法，譬如向SD卡发送命令的函数（s3c_hsmmc_send_command），譬如和SD卡读写数据的函数（s3c_hsmmc_set_ios），这些函数就是具体操作硬件的函数，也就是mmc.c中需要的那些硬件操作函数。这些函数在mmc驱动初始化构建时（s3c_hsmmc_initialize函数中）和struct mmc挂接起来备用。
 
3、分析
 
mmc.c和s3c_hsmmc.c构成了一个分层，mmc.c中调用了s3c_hsmmc.中的函数，所以mmc.c在上层，s3c_hsmmc.c在下层。这两个分层后我们发现mmc.c中不涉及具体硬件的操作，s3c_hsmmc.c中不涉及驱动工程时的时序操作。因此移植的时候就有好处：譬如我们要把这一套mmc驱动移植到别的SoC上mmc.c就不用动，s3c_hsmmc.c动就可以了；譬如SoC没变但是SD卡升级了，这时候只需要更换mmc.c，不需要更换s3c_hsmmc.即可。
 
cpu/s5pc11x/下面还有一个setup_hsmmc.c，也和MMC驱动有关。但是这些代码为什么不能放到drivers目录下去，而要放到cpu目录下去？因为这里面的2个函数（setup_hsmmc_clock和setup_hsmmc_cfg_gpio）都是和SoC有关的初始化函数，这两个函数不能放到drivers目录下去。

        【简介】Windows Server 2016 自带许多驱动程序，能驱动绝大多数服务器硬件，但仍有部分硬件是无法驱动的，这就需要我们手动下载驱动程序进行驱动。
 
 
 
   设备管理器
 
        首先我们需要知道有哪些硬件没有驱动。
 
 
        ① 点击左下角窗口标标，弹出窗口里选择【控制面板】。
 
 

 
 
        ② 在控制面板窗口，点击【硬件】。
 
 

 
 
        ③ 在硬件窗口，点击【设备管理器】。
 
 

 
 
        ④ 在设备管理器窗口，我们可以看到绝大多数硬件都已经驱动，部分没有驱动的设备会用醒目的符号提示出来。
 
 
  官方驱动
 
 
        一般服务器的生产厂家都会在官网提供各种软件版本的驱动程序下载，我们根据服务器型号、序列号，就可以很快找到对应的驱动程序。
 


 
        ① 以HP DL360 G7 服务器为例，可以在官网找到对应的驱动程序。
 
 
 
   通用驱动
 
         如果在官网仍然找不到驱动程序，我们还可以利用自动匹配驱动程序的软件，比较有代表性的是驱动人生和驱动精灵。 

 
 
        ① 驱动人生的的官网网址是 www.160.com，它的特点是对Windows 10 和 Server 驱动支持较好，缺点是会装入其它软件。
 
 

 
 
        ② 驱动精灵的官网网址是 www.drivergenius.com，支持驱动比较多。两款软件都带有网卡版，在安装的同时驱动网卡。这对找不到网卡驱动的来说不失为一种好办法。
 
          【提示】服务器对声卡、显卡的使用并不高，所以这块的驱动不用太在意，在大多数情况下，只用Windows Server 2016自带的驱动就可以了。
 
 

 
 
老梅子   QQ：57389522
 
 
 

Android的硬件驱动调用流程分为以下几层：
 
 
 1、内核驱动；
 
 2、硬件抽象层（HAL层）；
 
 3、通过JNI方法提供java调用接口；
 
 4、在应用程序框架层（）增加硬件服务接口供应用程序使用；
 
 5、app层最终调用硬件；
 
 
 
 
 以下重点解释下硬件抽象层：
 
 简单来说，就是对Linux内核驱动程序的封装，向上提供接口，屏蔽低层的实现细节。也就是说，把对硬件的支持分成了两层，一层放在用户空间（User Space），一层放在内核空间（Kernel Space），其中，硬件抽象层运行在用户空间，而Linux内核驱动程序运行在内核空间。为什么要这样安排呢？把硬件抽象层和内核驱动整合在一起放在内核空间不可行吗？从技术实现的角度来看，是可以的，然而从商业的角度来看，把对硬件的支持逻辑都放在内核空间，可能会损害厂家的利益。我们知道，Linux内核源代码版权遵循GNU License，而Android源代码版权遵循Apache License，前者在发布产品时，必须公布源代码，而后者无须发布源代码。如果把对硬件支持的所有代码都放在Linux驱动层，那就意味着发布时要公开驱动程序的源代码，而公开源代码就意味着把硬件的相关参数和实现都公开了，在手机市场竞争激烈的今天，这对厂家来说，损害是非常大的。因此，Android才会想到把对硬件的支持分成硬件抽象层和内核驱动层，内核驱动层只提供简单的访问硬件逻辑，例如读写硬件寄存器的通道，至于从硬件中读到了什么值或者写了什么值到硬件中的逻辑，都放在硬件抽象层中去了，这样就可以把商业秘密隐藏起来了。也正是由于这个分层的原因，Android被踢出了Linux内核主线代码树中。大家想想，Android放在内核空间的驱动程序对硬件的支持是不完整的，把Linux内核移植到别的机器上去时，由于缺乏硬件抽象层的支持，硬件就完全不能用了，这也是为什么说Android是开放系统而不是开源系统的原因。
 
      撇开这些争论，学习Android硬件抽象层，对理解整个Android整个系统，都是极其有用的，因为它从下到上涉及到了Android系统的硬件驱动层、硬件抽象层、运行时库和应用程序框架层等等，下面这个图阐述了硬件抽象层在Android系统中的位置，以及它和其它层的关系：
 
 
 
      接下来，我们将会学习如何在内核空间编写硬件驱动程序、如何在硬件抽象层中添加接口支持访问硬件、如何在系统启动时提供硬件访问服务以及 如何编写JNI使得可以通过Java接口来访问硬件，而作为中间的一个小插曲，我们还将学习一下如何在Android系统中添加一个C可执行程序来访问硬件驱动程序。由于这是一个系统的学习过程，我们将分成五篇文章来描述每一个学习过程，包括:
 
 （一）为Android系统编写Linux内核驱动程序HelloWorld
 
 
 （二）在Android硬件抽象层增加接口模块访问硬件驱动程序
 
 
 （三）为Android硬件抽象层（HAL）模块编写JNI方法提供Java访问硬件服务接口
 
 
 （四）为Android系统的Application Frameworks层增加硬件访问服务
 
 
 （五）编写Android App测试Hello驱动程序API
 
 

导读
ESXi专为运行虚拟机、最大限度降低配置要求和简化部署而设计。只需几分钟时间，客户便可完成从安装到运行虚拟机的全过程，特别是在下载并安装预配置虚拟设备的时候。Linux就该这么学
主机系统维护模式设置
 
esxcli system maintenanceMode set --enable true
 
将GPU设备设置为vGPU模式
 
esxcli graphics host set --default-type SharedPassthru
 
返回Default Graphics Type: SharedPassthru
 
esxcli graphics host get
 
 
安装VIB
 
安装显卡驱动
 
esxcli software vib install -v /tmp/NVIDIA/NVIDIA-VMware_ESXi_6.5_Host_Driver_390.42-1OEM.670.0.0.7535516.vib
 
 
更新显卡驱动
 
esxcli software vib update -v /tmp/NVIDIA/NVIDIA-VMware_ESXi_6.5_Host_Driver_390.42-1OEM.670.0.0.7535516.vib
 
ESXi主机服务器退出维护模式
 
esxcli system maintenanceMode set --enable false
 
安装在ESXi主机上的VIB，并确保正确完成了NVIDIA VIB
 
esxcli software vib list | grep -i NVIDIA
 
 
驱动检查
 
gpuvm  vGPU
 
 
GPU卡和ESXi是否可以正常工作
 
nvidia-smi
 
 
检查是否有vgpu资源
 
nvidia-smi vgpu –s
 
查看第三块卡的运行参数
 
nvidia-smi -i 2 –q
 
使用vGPU需要关闭ECC
 
nvidia-smi -i 2 -e 0
nvidia-smi -e 0
 
 
现在检查是否已禁用ECC模式
 
nvidia-smi -q
 
设置GPU的工作模式，默认VSGA
 
nvidia-smi -i 2 -vm 3
 
移除 VIB
 
esxcli software vib remove --vibname=NVIDIA-vGPU-VMware_ESXi_6.0_Host_Driver
esxcli software vib remove --vibname=NVIDIA-VMware_ESXi_6.7_Host_Driver
 
测试集群虚拟机是否可以添加新PCI设备
 
 
我们可以从上面的VM列表中选择一个示例vGPU配置文件：grid_P100-8q。此配置文件允许VM使用最多8GB的物理GPU内存（总计16GB）。因此，具有此配置文件的主机服务器上的两个单独的虚拟机可以共享同一物理GPU。
 
通过选择将GPU的全部内存分配给VM的vGPU配置文件，我们可以将该GPU完全专用于该VM，例如，对于具有16 GB内存的GPU，使用名为“ grid_p100-16q”的配置文件。
 
问题分析
 
DELL服务器BIOS设置I/O参数
 
ECC设置
 
英伟达显卡驱动版本不对
 
解决办法
 
设置BIOS内存映射I/O库设置为512GB(默认情况下为56TB)
 
关闭ECC
 
更换显卡驱动版本