参考博客：
http://blog.csdn.net/jiangwei0512
参考文章：
http://blog.csdn.net/morixinguan/article/details/79138325
http://blog.chinaunix.net/uid-27717694-id-3624294.html
http://blog.csdn.net/wh_19910525/article/details/16370863
https://www.ibm.com/developerworks/cn/linux/l-acpi/part1/
http://www.latelee.org/embedded-linux/kernel-note-7%EF%BC%8Dintel-lpc_ich-driver.html
http://www.latelee.org/embedded-linux/kernel-note-10-intel-gpio-driver.html
关于Hardware ID的用途，在前面已经大致的解释了它的用途，以及它和ACPI以及PNP之间的关系：
http://blog.csdn.net/morixinguan/article/details/79092440
接下来主要来看看在Linux内核中，内核是怎么去通过BIOS传递的参数表，传递对应的字串，然后内核又是如何来解析它，最终为Linux驱动统一模型所用。其实ARM和X86的驱动本质并没有太大的区别，都是有了一个基地址，然后依靠偏移来获取定位寄存器，写值驱动设备。ARM也会去解析uboot传递的参数，然而并没有那么的复杂，而X86对设备驱动进行了统一的管理，这点与ARM软件架构的实现是有很大区别的，比如，让GPIO的基地址在BIOS中进行统一分配，使用BIOS来统一管理电源等等。。。而ARM就相对来说简单很多，没有这么多的步骤，使用标准的Linux驱动模型+类ARM裸机操作(操作的地址需要进行映射，将物理地址转换成虚拟地址，这点和单片机是不太一样的)，也就是说，如果掌握了ARM的驱动模型，同样的，只要我们拥有X86架构的CPU数据手册，我们同样也可以使用ARM的思想来完成对X86架构的CPU的各类驱动BSP的编写。
以下是较为重要的结构体：
在这个结构体里发现，_HID是以内核链表成员的形式加载进Linux内核的
(内核源码/include/acpi/Acpi_bus.h)
struct acpi_hardware_id {
struct list_head list;
char *id;
};
//ACPI的对象类型结构体
typedef u32 acpi_object_type;
//ACPI对象
union acpi_object {
acpi_object_type type; /* See definition of acpi_ns_type for values */
struct {
acpi_object_type type; /* ACPI_TYPE_INTEGER */
u64 value; /* The actual number */
} integer;
struct {
acpi_object_type type; /* ACPI_TYPE_STRING */
u32 length; /* # of bytes in string, excluding trailing null */
char *pointer; /* points to the string value */
} string;
struct {
acpi_object_type type; /* ACPI_TYPE_BUFFER */
u32 length; /* # of bytes in buffer */
u8 *pointer; /* points to the buffer */
} buffer;
struct {
acpi_object_type type; /* ACPI_TYPE_PACKAGE */
u32 count; /* # of elements in package */
union acpi_object *elements; /* Pointer to an array of ACPI_OBJECTs */
} package;
struct {
acpi_object_type type; /* ACPI_TYPE_LOCAL_REFERENCE */
acpi_object_type actual_type; /* Type associated with the Handle */
acpi_handle handle; /* object reference */
} reference;
struct {
acpi_object_type type; /* ACPI_TYPE_PROCESSOR */
u32 proc_id;
acpi_io_address pblk_address;
u32 pblk_length;
} processor;
struct {
acpi_object_type type; /* ACPI_TYPE_POWER */
u32 system_level;
u32 resource_order;
} power_resource;
};
typedef char acpi_bus_id[8];
typedef unsigned long acpi_bus_address;
typedef char acpi_device_name[40];
typedef char acpi_device_class[20];
//这是一个位段，用来描述pnp中的类型
struct acpi_pnp_type {
u32 hardware_id:1;
u32 bus_address:1;
u32 platform_id:1;
u32 reserved:29;
};
//acpi的pnp设备，包括对象名称、ID类型、以及各种ID，具体参考ACPI spec
struct acpi_device_pnp {
acpi_bus_id bus_id; /* Object name */
struct acpi_pnp_type type; /* ID type */
acpi_bus_address bus_address; /* _ADR */
char *unique_id; /* _UID */
struct list_head ids; /* _HID and _CIDs */
acpi_device_name device_name; /* Driver-determined */
acpi_device_class device_class; /* " */
union acpi_object *str_obj; /* unicode string for _STR method */
}; 那X86架构的CPU在启动内核的时候又是如何知道BIOS传递过来的HID参数？我们可以来看看X86架构在Linux下的启动流程：
不管是在ARM还是X86平台，本质都是将一系列代码拷贝到对应的存储器对应的区域中，这个存储器一般是NOR FLASH或者NAND FLASH，当然现在还有EMMC等其它的存储设备，然后在执行Uboot（ARM的叫法,也叫bootloader,用来引导内核，而X86用的是BIOS，也差不多）中，通过地址跳转的形式去启动内核，如果是我们自己实现的Bootloader，一般会在作为uboot的第一、第二阶段以后，通过如下的代码跳转到操作系统启动的模式：
/* 0. 帮内核设置串口: 内核启动的开始部分会从串口打印一些信息,但是内核一开始没有初始化串口 */
uart0_init();
/* 1. 从NAND FLASH里把内核读入内存 */
puts("Copy kernel from nand\n\r");
nand_read(0x60000+64, (unsigned char *)0x30008000, 0x200000);
puthex(0x1234ABCD);
puts("\n\r");
puthex(*p);
puts("\n\r");
/* 2. 设置参数 */
puts("Set boot params\n\r");
setup_start_tag();
setup_memory_tags();
setup_commandline_tag("noinitrd root=/dev/mtdblock3 init=/linuxrc console=ttySAC0");
setup_end_tag();
/* 3. 跳转执行 */
puts("Boot kernel\n\r");
theKernel = (void (*)(int, int, unsigned int))0x30008000;
theKernel(0, 362, 0x30000100); 如上代码段，Linux内核在启动的过程中会去解析ARM传递过去的参数：noinitrd root=/dev/mtdblock3 init=/linuxrc console=ttySAC0。
ARM的启动相对来说比较简单： uboot----->内核------>文件系统------>app，在uboot之前一般还会有IC厂商的固件驱动代码。
而X86架构的CPU与ARM的启动形式就不太一样，显然比这里要复杂得多，由于BIOS的源代码并不开放，所以我们也并不知道BIOS的内幕具体是怎么实现的，但我们可以从以下这张图可以得知X86架构从BIOS到kernel的整个流程，在这里我们能够得知，X86的OS和BIOS之间衔接的桥梁是ACPI，使用ACPI来对一些资源进行统一管理，我们要获取的这个Hardware ID其实就是ACPI Tables中的其中一个参数。
到这里我们就明白了，不懂BIOS是怎么实现的也没有什么关系，我们只要去百度下载一个ACPI的Spec，不就可以知道BIOS中具体的工作是做什么了吗？只要了解了BIOS和内核之间是要完成什么样的事情，对于我们驱动工程师来说就已经足够了。
接下来我们来看看在X86 Linux内核的启动过程中，是如何去识别BIOS传递过来的Hardware ID的?
不管是ARM架构的还是X86架构的CPU，在启动Linux内核的时候一定要进入start_kernel函数，这个函数位于：
内核源码/init/main.c
在这个函数中，会做操作系统的设备等一系列初始化，与ACPI最关键的地方在这个函数:acpi_early_init，这里完成的工作主要有如下：
acpi_early_init
acpi_reallocate_root_table
acpi_initialize_subsystem
(drivers/acpi/acpica/Tbxfload.c)
1.acpi_load_tables：
--->acpi_status __init acpi_load_tables(void)
2.acpi_tb_load_namespace:
--->static acpi_status acpi_tb_load_namespace(void)
3.acpi_ns_load_table
在table中会得到一系列参数，包括Hardware ID,需要根据不同的参数表来解析
--->
(1)acpi_ut_acquire_mutex
(2)acpi_tb_is_table_loaded
(3)acpi_tb_allocate_owner_id
(4)acpi_ns_parse_table原来，内核就是这样来获取BIOS传递过来的table的，这个table中就会包括Hardware ID,当然还会有其它的ID，具体请参考ACPI的Spec，根据Linux实现的驱动模型，那么有设备，自然就要有驱动，驱动和设备要相辅相成，在：内核源码/drivers/acpi/bus.c中就实现了acpi的驱动，在这个文件中，我们看到：
static int __init acpi_init(void)
{
int result;
if (acpi_disabled) {
printk(KERN_INFO PREFIX "Interpreter disabled.\n");
return -ENODEV;
}
acpi_kobj = kobject_create_and_add("acpi", firmware_kobj);
if (!acpi_kobj) {
printk(KERN_WARNING "%s: kset create error\n", __func__);
acpi_kobj = NULL;
}
init_acpi_device_notify();
result = acpi_bus_init();
if (result) {
disable_acpi();
return result;
}
pci_mmcfg_late_init();
acpi_scan_init();
acpi_ec_init();
acpi_debugfs_init();
acpi_sleep_proc_init();
acpi_wakeup_device_init();
return 0;
}那么acpi_init函数又是怎么被内核调用的呢？通过subsys_initcall(acpi_init)这个宏来调用，我们将subsys_initcall展开看看，在内核源码/include/init.h
#define subsys_initcall(fn) __define_initcall(fn, 4)将__define_initcall(fn,4)这个宏展开
#define __define_initcall(fn, id) \
static initcall_t __initcall_##fn##id __used \
__attribute__((__section__(".initcall" #id ".init"))) = fn; \
LTO_REFERENCE_INITCALL(__initcall_##fn##id) 其中initcall_t是函数指针，原型：typedef int (*initcall_t)(void);
属性 __attribute__((__section__())) 则表示把对象放在一个这个由括号中的名称所指代的section中，这个对象就是我们的acpi_init函数。由此可见__define_initcall主要是完成以下几个功能：
(1)声明一个名称为__initcall_##fn的函数指针；
(2) 将这个函数指针初始化为fn；
(3) 编译的时候需要把这个函数指针变量放置到名称为 ".initcall" level ".init"的section中。
而对应的这些.include，level，.init定义在Vmlinux.lds.h中，这个文件在内核源码/include/asm-generic/Vmlinux.lds.h中：
在Linux4.0的内核实现如下：
#define INIT_CALLS_LEVEL(level) \
VMLINUX_SYMBOL(__initcall##level##_start) = .; \
*(.initcall##level##.init) \
*(.initcall##level##s.init) \
#define INIT_CALLS \
VMLINUX_SYMBOL(__initcall_start) = .; \
*(.initcallearly.init) \
INIT_CALLS_LEVEL(0) \
INIT_CALLS_LEVEL(1) \
INIT_CALLS_LEVEL(2) \
INIT_CALLS_LEVEL(3) \
INIT_CALLS_LEVEL(4) \
INIT_CALLS_LEVEL(5) \
INIT_CALLS_LEVEL(rootfs) \
INIT_CALLS_LEVEL(6) \
INIT_CALLS_LEVEL(7) \
VMLINUX_SYMBOL(__initcall_end) = .;__initcall_start和__initcall_end以及INITCALLS中定义的SECTION都是在arch/x86/kernel/vmlinux.lds.S中放在.init.begin段中的，如下，这是linux4.0内核中实现的。
SECTIONS{
......
/* Init code and data - will be freed after init */
. = ALIGN(PAGE_SIZE);
.init.begin : AT(ADDR(.init.begin) - LOAD_OFFSET) {
__init_begin = .; /* paired with __init_end */
}
......
. = ALIGN(PAGE_SIZE);
/* freed after init ends here */
.init.end : AT(ADDR(.init.end) - LOAD_OFFSET) {
__init_end = .;
}
......
}而这些SECTION里的函数在初始化时被顺序执行，具体的调用流程是这样的：
rest_init ====> kernel_thread(kernel_init, NULL, CLONE_FS) ====> kernel_init ====> kernel_init_freeable ====>
do_basic_setup ====> do_initcalls
在内核启动的最后一步，开启一条内核线程来加载这些函数，从而成功装载acpi驱动。
static void __init do_initcalls(void)
{
int level;
for (level = 0; level < ARRAY_SIZE(initcall_levels) - 1; level++)
do_initcall_level(level);
}接下来再接着看acpi_init函数，这个函数中会调用acpi_scan_init函数，acpi_scan_init函数会完成如下：
1、注册ACPI的驱动模型
result = bus_register(&acpi_bus_type);2、完成与apci相关的一系列初始化:
acpi_pci_root_init();
acpi_pci_link_init();
acpi_processor_init();
acpi_lpss_init();
acpi_apd_init();
acpi_cmos_rtc_init();
acpi_container_init();
acpi_memory_hotplug_init();
acpi_pnp_init();
acpi_int340x_thermal_init();3、重点：调用acpi_bus_scan函数
在这个函数中会继续调用acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
acpi_bus_check_add, NULL, NULL, &device);
注册acpi_bus_check_add函数，在acpi_bus_check_add函数中继续调用：acpi_add_single_object函数:
static int acpi_add_single_object(struct acpi_device **child,
acpi_handle handle, int type,
unsigned long long sta)
在acpi_add_single_object函数中的主要操作：
1、调用acpi_init_device_object等完成acpi设备、电源管理相关等的初始化，详情见后面分析
2、调用acpi_device_add获取设备的HID信息,实际上是通过链表的遍历形式去获取
list_for_each_entry(acpi_device_bus_id, &acpi_bus_id_list, node) {
if (!strcmp(acpi_device_bus_id->bus_id,
acpi_device_hid(device))) {
acpi_device_bus_id->instance_no++;
found = 1;
kfree(new_bus_id);
break;
}
}
const char *acpi_device_hid(struct acpi_device *device)
{
struct acpi_hardware_id *hid;
//判断链表是否为空，如果为空，返回无效的hid，其实是一个字串："device"
if (list_empty(&device->pnp.ids))
return dummy_hid;
//通过list成员返回该结构体的起始地址，也就是acpi_hardware_id这个结构体的起始地址
hid = list_first_entry(&device->pnp.ids, struct acpi_hardware_id, list);
//找到该结构体的起始地址后，即可以获得结构体中的id成员，这个id就是我们当前要获取的HID
return hid->id;
}设置在/sys/devices/XXX下面的name
4、调用acpi_init_device_object函数:
void acpi_init_device_object(struct acpi_device *device, acpi_handle handle,
int type, unsigned long long sta)
(1)、初始化内核链表用来存储pnp设备中关于的链表等其它的信息
INIT_LIST_HEAD(&device->pnp.ids);
device->device_type = type;
device->handle = handle;
....
(2)、调用acpi_set_pnp_ids将ids的保存到ids中，具体操作见后面的剖析
5、调用acpi_set_pnp_ids函数：
static void acpi_set_pnp_ids(acpi_handle handle, struct acpi_device_pnp *pnp,
int device_type)
首先会根据swicth语句来判断设备类型：device_type，这里找到的是ACPI总线的设备类型ACPI_BUS_TYPE_DEVICE
switch (device_type)
{
...
case ACPI_BUS_TYPE_DEVICE:
...
}
case ACPI_BUS_TYPE_DEVICE:
在该选项ACPI_BUS_TYPE_DEVICE中:
5.1 首先会判断acpi句柄是否为ACPI的根对象，如果是，则会直接添加id节点到pnp->ids的链表中去。
5.2 接下来，调用acpi_get_object_info函数：
acpi_status acpi_get_object_info(acpi_handle handle,struct acpi_device_info **return_buffer)
通过acpi_get_object_info这个函数得到设备的_HID和_CIDs信息，获取之前需要对命名空间的句柄进行转换，怎么转？
通过struct acpi_namespace_node *acpi_ns_validate_handle(acpi_handle handle)这个函数转。
acpi_ns_validate_handle 对传入的名字空间句柄转换为名字空间节点，这是在处理根节点的特殊情况
这个句柄其实是: typedef void *acpi_handle; /* Actually a ptr to a NS Node */
为什么是Object？在ACPI标准手册上关于ASL语言中可以查询到：
ObjectType must have. A fixed list is written as ( a , b , c , … ) where the number of arguments depends on the specific ObjectType , and some elements can be nested objects, that is (a, b, (q, r, s,t), d) . 大致意思是，对象类型一定要包含，它是一个固定的列表写成(a,b,c...)参数，取决于特定的对象类型，有些元素也是可以嵌套的，比如(a,b,(q,r,s,t),d)。
该函数中会尝试去判断函数传过来的参数--句柄是否存在，或者句柄是否为根对象：
if ((!handle) || (handle == ACPI_ROOT_OBJECT))，只要有一个成立，则会return (acpi_gbl_root_node);
接下来尝试校验句柄：
if (ACPI_GET_DESCRIPTOR_TYPE(handle) != ACPI_DESC_TYPE_NAMED)
如果该句柄不是描述命名空间类型的句柄，则会return (NULL);
以上条件都不满足，则：return (ACPI_CAST_PTR(struct acpi_namespace_node, handle));
#define ACPI_CAST_PTR(t, p) ((t *) (acpi_uintptr_t) (p))
它的原型是将命名空间句柄强制转换为apci命名空间节点，因为只有这样，才能正确的解析BIOS传递过来的关于_HID的信息。
(1)提供运行_HID/_UID/_SUB/_CID的方法,这里只看_HID的执行方法
if ((type == ACPI_TYPE_DEVICE) || (type == ACPI_TYPE_PROCESSOR)) {
...
//得到_HID的信息
status = acpi_ut_execute_HID(node, &hid);
if (ACPI_SUCCESS(status)) {
info_size += hid->length;
valid |= ACPI_VALID_HID;
}
...
}acpi_ns_copy_device_id //将HID、UID、SUB和CIDs复制到返回缓冲区，如果是可变长度的字符串则会被复制到保留区域
acpi_ut_is_pci_root_bridge //对于HID和CID，会检查ID是否为PCI根桥，如果是，则要info->flags |= ACPI_PCI_ROOT_BRIDGE;
3、保存HID等ID的信息到device的pnp->ids里，这里只分析HID，同样是利用了内核链表的尾插机制，将id源源不断的接在链表的尾部
if (info->valid & ACPI_VALID_HID) {
acpi_add_id(pnp, info->hardware_id.string);
pnp->type.platform_id = 1;
}
static void acpi_add_id(struct acpi_device_pnp *pnp, const char *dev_id)
最关键的一步：
list_add_tail(&id->list, &pnp->ids);
如果没有拥有相关的HID，可以直接对Handle进行添加，而不用通过BIOS去获取：
if (acpi_is_video_device(handle))
acpi_add_id(pnp, ACPI_VIDEO_HID);
else if (acpi_bay_match(handle))
acpi_add_id(pnp, ACPI_BAY_HID);
else if (acpi_dock_match(handle))
acpi_add_id(pnp, ACPI_DOCK_HID);
else if (acpi_ibm_smbus_match(handle))
acpi_add_id(pnp, ACPI_SMBUS_IBM_HID);
else if (list_empty(&pnp->ids) &&
acpi_object_is_system_bus(handle)) {
/* \_SB, \_TZ, LNXSYBUS */
acpi_add_id(pnp, ACPI_BUS_HID);
strcpy(pnp->device_name, ACPI_BUS_DEVICE_NAME);
strcpy(pnp->device_class, ACPI_BUS_CLASS);
}例如：#define ACPI_BAY_HID "LNXIOBAY"
那么PNP设备又是如何被加载到ACPI中的呢？而Hardware ID传进来的字符串又是如何被PNP识别的呢？接下来请看：
内核源码/drivers/acpi/acpi_pnp.c
void __init acpi_pnp_init(void)
{
acpi_scan_add_handler(&acpi_pnp_handler);
}acpi_pnp_init这个函数是在acpi_scan_init中被调用的，也就是前面讲到的。接下来我们来看看acpi_scan_add_handler这个函数：
int acpi_scan_add_handler(struct acpi_scan_handler *handler)
{
if (!handler)
return -EINVAL;
list_add_tail(&handler->list_node, &acpi_scan_handlers_list);
return 0;
}很明显，这个函数完成的功能就是将节点插入到链表中去，插入的是什么节点？我们来看看acpi_pnp_handler：
static struct acpi_scan_handler acpi_pnp_handler = {
.ids = acpi_pnp_device_ids,
.match = acpi_pnp_match,
.attach = acpi_pnp_attach,
};
这是一个结构体变量，这里的ids其实就是一个字符串，这个字符串就是acpi的设备id，只不过在这被初始化成了pnp设备id，其实是一个意思，因为PNP设备是注册在ACPI之上的。
struct acpi_device_id {
__u8 id[ACPI_ID_LEN];
kernel_ulong_t driver_data;
};static const struct acpi_device_id acpi_pnp_device_ids[] = {
/* pata_isapnp */
{"PNP0600"}, /* Generic ESDI/IDE/ATA compatible hard disk controller */
/* floppy */
{"PNP0700"},
/* ipmi_si */
{"IPI0001"},
......
};而acpi_pnp_match是完成对BIOS传递过来的ID与这里的ID进行比较，如果存在这个ID，才会将对应的驱动注册到内核中去，这样内核才会去执行对应的驱动：
static bool matching_id(char *idstr, char *list_id)
{
int i;
if (memcmp(idstr, list_id, 3)){
return false;
}
for (i = 3; i < 7; i++) {
char c = toupper(idstr[i]);
if (!isxdigit(c)
|| (list_id[i] != 'X' && c != toupper(list_id[i])))
return false;
}
return true;
}
static bool acpi_pnp_match(char *idstr, const struct acpi_device_id **matchid)
{
const struct acpi_device_id *devid;
for (devid = acpi_pnp_device_ids; devid->id[0]; devid++) {
if (matching_id(idstr, (char *)devid->id)) {
if (matchid)
*matchid = devid;
return true;
}
}
return false;
}
static int acpi_pnp_attach(struct acpi_device *adev,
const struct acpi_device_id *id)
{
return 1;
}至此，我们已经完全明白内核是如何接收到BIOS传过来的Hardware ID的整个流程，确实是非常难的，简单的问题被复杂化，但没有办法，因为要统一管理的东西太多太多了，所以一定需要一个模型来进行管理。如果我们不想使用BIOS与ACPI的机制，完全也可以绕开这个流程，用标准的Linux驱动模型去实现，不过还是建议，还是使用标准的ACPI的流程，这样才有助于软件工程项目管理。
156
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
