Devices Tree加载流程

 

1. DT.IMG布局

hdr

zImage

Ramdisk.img

DT.img

其中DT.img由DTBTOOL打包所有编译生成的dtb生成；布局如下：

DT header

dt_entry_0

dt_entry_1

dt_entry_2

……

其中dt_entry_x对应是某棵DeviceTree编译输出的***.dtb。

1. Bootloader 加载DviceTree

   函数 int boot_linux_from_mmc(void)；

    

   Bootloader

   正常启动时把zImage、ramdisk.img以及某个dt_entry_x（dt.img中包含多个条目）分别从存储器（这里以eMMC为例）中读取到RAM中的具体位置。

   具体加载哪个dt_entry_x，有bootloader根据基板信息（platform_id/target_id/soc_version）等按照某个策略找到最匹配的。

   1. 调用boot_linux();

boot_linux((void *)hdr->kernel_addr, (void *)hdr->tags_addr,      (const char *)hdr->cmdline, board_machtype(),          (void *)hdr->ramdisk_addr, hdr->ramdisk_size);

其中参数： kernel_addr : 是zImage在RAM中的地址； tags_addr : 是dt_entry在RAM中的地址； cmdline : 是编译zImage时打包进去的，； 如下： [mkbooting —kernel$KERNEL ramdisk ./booting/ramdisk $BOARD_CFG.img —cmdline "console=ttyHSL0,115200,n8, androidboot.console=ttyHSL0 androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x37" --base 0x0000 0000—pagesize2048—ramdisk_offset 0x0200 0000 --tags_offset 0x01E0 0000 –dt ./booting/dt_$BOARD_CFG.img –output $BOOTIMG] machtype 目前在高通平台没有使用 ramdisk 是ramdisk在RAM中的地址 ramdisk_size 是ramdisk的大小

 

1. 调用update_device_tree();函数把commandline/ramdisk/ramdisk_size等信息更新到devicetree中的对应节点中。

update_device_tree( (void *)tags, (const char *)final_cmdline, ramdisk, ramdisk_size );

/chosen/bootargs ßfinal_cmdline /chosen/linux,initrd-start ßramdisk /chosen/linux,initrd-end ßramdisk+ramdisk_size 注释：这里的final_cmdline，有boot_linux中的cmdline和lk动态配置的commandline组合而成; 比如说pwr_reason￥lcd信息等。

 

1. 调用entry(0, machtype, (unsigned*)tags_phys);启动内核！

   向内核传递的信息只有machtype和(unsigned*)tags_phys；其中machtype为零、tags_phys为对应的devicetree（dtb）在RAM中的地址。

1. Kernel展开DTB
   1. 内核通过DeviceTree识别特定的machine（DT_MACHINE_START）

      Kernel的函数在Head.S中的ENTRY(stext),此时的寄存器r1,r2分别存储着machtype和devicetree（dtb）的地址；

 

1. 并调用kernel如下

str r1,[r5] @Save machine type str r2,[r6] @Save atags pointer b start_kernel

此时r1，r2的值存储到r[5],r[6];也就是_machine_arch_type、_atags_pointer中，以便在C代码空间访问。

 

1. 进入main.c中的start_kernel()函数，调用setup_arch()函数

进入setup.c中的setup_arch()函数，调用setup_machine_fdt()函数

进入devtree.c中的setup_machine_fdt()函数，在mdesc（即machine_desc）的table中搜索与DT数据最匹配的machine。设备树根节点的compatible属性跟mdesc的table数组相比较决定最匹配的machine。找到最匹配的machine后，setup_machine_fdt()返回machine_desc数组的基地址，否则返回null。

/** * setup_machine_fdt - Machine setup when an dtb was passed to the kernel * @dt_phys: physical address of dt blob * If a dtb was passed to the kernel in r2, then use it to choose the * correct machine_desc and to setup the system. */ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys) {     const struct machine_desc *mdesc, *mdesc_best = NULL; #ifdef CONIG_FARCH_MULTIPLATFORM     DT_MACHINE_START(GENERIC_DT, "Generic DT based system")     MACHINE_END     mdesc_best = &__mach_desc_GENERIC_DT; #endif     if (!dt_phys || !early_init_dt_verify(phys_to_virt(dt_phys)))         return NULL;     mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach);     if (!mdesc) {         const char *prop;         int size;         unsigned long dt_root;         early_print("\nError: unrecognized/unsupported "              "device tree compatible list:\n[ ");         dt_root = of_get_flat_dt_root();         prop = of_get_flat_dt_prop(dt_root, "compatible", &size);         while (size > 0) {             early_print("'%s' ", prop);             size -= strlen(prop) + 1;             prop += strlen(prop) + 1;         }         early_print("]\n\n");         dump_machine_table(); /* does not return */     }     /* We really don't want to do this, but sometimes firmware provides buggy data */     if (mdesc->dt_fixup)         mdesc->dt_fixup();     early_init_dt_scan_nodes();     /* Change machine number to match the mdesc we're using */     __machine_arch_type = mdesc->nr;     return mdesc; }

 

1. 设备加载流程

   上述3得到基地址后会初始化板级信息

以msm8953为例： #include <linux/kernel.h> #include <asm/mach/arch.h> #include "board-dt.h"   static const char *msm8953_dt_match[] __initconst = {     "qcom,msm8953",     "qcom,apq8053",     NULL }; static void __init msm8953_init(void) {     board_dt_populate(NULL); } DT_MACHINE_START(MSM8953_DT,     "Qualcomm Technologies, Inc. MSM 8953 (Flattened Device Tree)")     .init_machine = msm8953_init,     .dt_compat = msm8953_dt_match, MACHINE_END

 

1. 在start_kernel()开启新的线程kernel_init()，并根据devicetree创建设备。

   start_kernel(void)—> kernel_init(void *unused)—> kernel_init_freeable()—> do_basic_setup()—> do_initcalls();do_initcalls()完成各个等级的初始化工作，涉及devicetree初始化工作如下：

static int __init customize_machine(void) {     of_clk_init(NULL);     /*      * Traverses flattened DeviceTree - registering platform devices      * (if any) complete with their resources      */     of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);     if (machine_desc->init_machine)         machine_desc->init_machine();     return 0; } arch_initcall(customize_machine);

也就是回调具体的DT_MACHINE中的 init_machine， 以msm8953为例就是 msm8953_init。

msm8953_init()函数： static void __init msm8953_init(void) {     board_dt_populate(NULL); }

void __init board_dt_populate(struct of_dev_auxdata *adata) {     of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);       /* Explicitly parent the /soc devices to the root node to preserve      * the kernel ABI (sysfs structure, etc) until userspace is updated      */     of_platform_populate(of_find_node_by_path("/soc"),              of_default_bus_match_table, adata, NULL); }

of_platform_populate 递归完成device的创建工作。

在linux设备模型里, 假设它的所有设备是连接在bus controller上的子设备.e.g. i2c_client 是i2c_master的子设备;唯一没有特定父设备类型的模型就是platform_device.

调用of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL)完成根设备节点创建。调用of_platform_populate(of_find_node_by_path("/soc"),of_default_bus_match_table, adata, NULL);完成/soc下相关节点设备的创建。

 

1. Linux下的i2c驱动
   1. 设备模型

      由总线（bus_type）+设备（device）+驱动（device_driver）组成，在该模型下，所有的设备通过总线连接起来，即使有些设备没有连接到一根物理总线上,linux为其设置了一个内部的、虚拟的platform总线，用以维持

      总线、驱动、设备的关系。

      对于实现一个Linux下的设备驱动，可以分为两大步：

      1. 设备注册
      2. 驱动注册

      当然还有一些细节问题：

      1. 驱动的probe函数
      2. 驱动和设备是怎么绑定的

          

   2. i2c设备驱动的几个数据结构
      1. i2c_adapter:

         每一个i2c_adapter对应一个物理上的i2c控制器，在i2c总线驱动probe函数中动态创建。通过i2c_adapter注册到i2c_core。

/* * i2c_adapter is the structure used to identify a physical i2c bus along * with the access algorithms necessary to access it. */ struct i2c_adapter {     struct module *owner;     unsigned int class;         /* classes to allow probing for */     const struct i2c_algorithm *algo; /* the algorithm to access the bus */     void *algo_data;       /* data fields that are valid for all devices    */     struct rt_mutex bus_lock;       int timeout;            /* in jiffies */     int retries;     struct device dev;        /* the adapter device */       int nr;     char name[48];     struct completion dev_released;       struct mutex userspace_clients_lock;     struct list_head userspace_clients;       struct i2c_bus_recovery_info *bus_recovery_info; };

 

1. i2c_algorithm:

   i2c_algorithm中的关键函数master_xfer(),以i2c_msg为单位产生i2c访问需要的信号,不同平台所对应的master_xfer()是不同的，需要根据所用平台的硬件特性实现自己的xxx_xfer()方法以填充i2c_algorithm的master_xfer指针；

/** * struct i2c_algorithm - represent I2C transfer method * @master_xfer: Issue a set of i2c transactions to the given I2C adapter * defined by the msgs array, with num messages available to transfer via * the adapter specified by adap. * @smbus_xfer: Issue smbus transactions to the given I2C adapter. If this * is not present, then the bus layer will try and convert the SMBus calls * into I2C transfers instead. * @functionality: Return the flags that this algorithm/adapter pair supports * from the I2C_FUNC_* flags. * * The following structs are for those who like to implement new bus drivers: * i2c_algorithm is the interface to a class of hardware solutions which can * be addressed using the same bus algorithms - i.e. bit-banging or the PCF8584 * to name two of the most common. * * The return codes from the @master_xfer field should indicate the type of * error code that occured during the transfer, as documented in the kernel * Documentation file Documentation/i2c/fault-codes. */ struct i2c_algorithm {     /* If an adapter algorithm can't do I2C-level access, set master_xfer      to NULL. If an adapter algorithm can do SMBus access, set      smbus_xfer. If set to NULL, the SMBus protocol is simulated      using common I2C messages */     /* master_xfer should return the number of messages successfully      processed, or a negative value on error */     int (*master_xfer)(struct i2c_adapter *adap, struct i2c_msg *msgs,              int num);     int (*smbus_xfer) (struct i2c_adapter *adap, u16 addr,              unsigned short flags, char read_write,              u8 command, int size, union i2c_smbus_data *data)     /* To determine what the adapter supports */     u32 (*functionality) (struct i2c_adapter *); };

 

1. i2c_client:

   代表一个挂载到i2c总线上的i2c从设备，包含该设备所需要的数据：

   该i2c从设备所依附的i2c控制器 ：strut i2c_adapter *adapter

   该i2c从设备的驱动程序 ：struct i2c_driver *driver

   该i2c从设备的访问地址addr

   该i2c从设备的名称name

/** * struct i2c_client - represent an I2C slave device * @flags: I2C_CLIENT_TEN indicates the device uses a ten bit chip address; *    I2C_CLIENT_PEC indicates it uses SMBus Packet Error Checking * @addr: Address used on the I2C bus connected to the parent adapter. * @name: Indicates the type of the device, usually a chip name that's *    generic enough to hide second-sourcing and compatible revisions. * @adapter: manages the bus segment hosting this I2C device * @dev: Driver model device node for the slave. * @irq: indicates the IRQ generated by this device (if any) * @detected: member of an i2c_driver.clients list or i2c-core's *    userspace_devices list * * An i2c_client identifies a single device (i.e. chip) connected to an * i2c bus. The behaviour exposed to Linux is defined by the driver * managing the device. */ struct i2c_client {     unsigned short flags;        /* div., see below        */     unsigned short addr;        /* chip address - NOTE: 7bit    */                     /* addresses are stored in the    */                     /* _LOWER_ 7 bits        */     char name[I2C_NAME_SIZE];     struct i2c_adapter *adapter;    /* the adapter we sit on    */     struct device dev;        /* the device structure        */     int irq;            /* irq issued by device        */     struct list_head detected; };

 

1. i2c总线驱动
   1. 功能划分

      从硬件功能上可划分为：i2c控制器和i2c外设（从设备）。每个i2c控制器总线上都可以挂载多个i2c外设。Linux中对i2c控制器和外设分开管理：通过i2c-msm-qup.c文件完成i2c控制器的设备注册和驱动注册；通过i2c-core.c为具体的i2c外设提供了统一的设备注册接口和驱动注册接口，它分离了设备驱动和硬件控制的实现细节。

      需要注意的是：设备与驱动的对应关系是多对一的；即如果设备类型是一样的，会共用同一套驱动。

       

   2. 设备注册

      将i2c控制器设备注册为platform设备，为每一个控制器定义一个struct platform_device数据结构，并且把.name都设置为"i2c_qup"。后面会通过名字进行匹配驱动的。然后是调用platform_device_register()函数，将设备注册到platform bus上。

static struct of_device_id i2c_qup_dt_match[] = {     {         .compatible = "qcom,i2c-qup",     },     {} };   static struct platform_driver qup_i2c_driver = {     .probe        = qup_i2c_probe,     .remove        = qup_i2c_remove,     .driver        = {         .name    = "i2c_qup",         .owner    = THIS_MODULE,         .pm = &i2c_qup_dev_pm_ops,         .of_match_table = i2c_qup_dt_match,     }, };

设备注册完成后其直观的表现就是在文件系统下出现：sys/bus/platform/devices/xxx.o

通过platform_device_register()函数进行注册的过程，就是对platform_device这个数据结构的更改，逐步完成.dev.parent/.dev.kobj/.dev.bus的赋值,然后将.dev.kobj加入到platform_busàkobj的链表上。

1. 驱动注册步骤和设备注册类似，也是为驱动定义了一个数据结构：

static struct of_device_id i2c_qup_dt_match[] = {     {         .compatible = "qcom,i2c-qup",     },     {} };   static struct platform_driver qup_i2c_driver = {     .probe        = qup_i2c_probe,     .remove        = qup_i2c_remove,     .driver        = {         .name    = "i2c_qup",         .owner    = THIS_MODULE,         .pm = &i2c_qup_dev_pm_ops,         .of_match_table = i2c_qup_dt_match,     }, };   /* QUP may be needed to bring up other drivers */ int __init qup_i2c_init_driver(void) {     static bool initialized;       if (initialized)         return 0;     else         initialized = true;       return platform_driver_register(&qup_i2c_driver); } EXPORT_SYMBOL(qup_i2c_init_driver); arch_initcall(qup_i2c_init_driver);   static void __exit qup_i2c_exit_driver(void) {     platform_driver_unregister(&qup_i2c_driver); } module_exit(qup_i2c_exit_driver);

 

1. 设备与驱动匹配

   match过程：

   i2c_core.c: i2c_add_driver()—>i2c_register_driver()—>i2c_bus_type—>i2c_device_match()—>of_driver_match_device()，用驱动的信息与device的node处匹配,如果相同，则匹配，匹配上之后运行driver_register调用

   driver_probe_device（dd.c中）进行设备与驱动的绑定。

2. probe绑定过程

   初始化.probe和.remove函数，然后调用i2c_add_driver进行注册,主要调用函数流程：

   i2c_add_driver—>i2c_register_driver—>bus_add_driver—>driver_attach—>driver_probe_device—>really_probe(里面讲设备的驱动指针指向驱动，如果匹配成功，执行dev—>bus—>probe即设备驱动里的probe函数)—>driver_bound(绑定)

   需要注意的是driver_attach，这个函数遍历了总线上（platform_bus_type）的所有设备，寻找与驱动匹配的设备，并把满足条件的设备结构体上的驱动指针指向驱动，从而完成了驱动和设备的匹配(_driver_attach函数完成)

   如果匹配到设备，这是就需要执行platform_bus_type的probe函数，最终会调用驱动的probe函数。

 

1.