Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1244427
  • 博文数量: 261
  • 博客积分: 4196
  • 博客等级: 上校
  • 技术积分: 3410
  • 用 户 组: 普通用户
  • 注册时间: 2012-02-17 17:05
文章分类

全部博文(261)

文章存档

2018年(1)

2017年(22)

2016年(2)

2015年(8)

2014年(27)

2013年(40)

2012年(161)

分类: LINUX

2016-04-25 11:00:26

0. Linux Device Tree基础:

在早期的ARM Linux Kernel中,板级细节使用代码形式,存放在arch/arm/目录。名字通常为:plat-xxxx或者mach-xxxx,内容多为特定板上细节信息,如platform, i2c_board_info, spi_board_info和各类资源数据。(Sam在学习I2C时,Borad就在类似目录mach-tegra)

但这类目录对Linux Kernel来说,意义非常有限,因为板级代码只对相应开发板有用。使用这种方法显然不是一个好办法。与此同时PowerPC等其它架构已经在使用一种新的方法:Flattened Device Tree(FDT)。Device Tree是一种描述硬件的数据结构。它包含板级硬件细节信息,这样,通过Device Tree,就可以把硬件信息传递给Kernel,而不需要再硬编码了。

 

1. 无Linux Device Tree之前的状况:

在没有使用Linux Device Tree之前,要porting Linux 到一个新的ARM开发板上时,工作流程如下:

A:构建Bootloader,copy kernel到内存,并传递参数。并统一Bootloader和Kernel中的machine type ID。这个Machine Type ID与此开发板一一对应。

 

DT_MACHINE_START(ARDBEG, "ardbeg")

ARDBEG:就是Machine ID。

定义在arch/arm/tools/mach-types 文件中。

 

B:在kernel/arch/arm目录下创建mach-xxxx目录。这个目录下的文件就是板级代码,只与开发板硬件相关。

DT_MACHINE_START(ARDBEG, "ardbeg")
 .atag_offset = 0x100,
 .smp  = smp_ops(tegra_smp_ops),
 .map_io  = tegra_map_common_io,
 .reserve = tegra_ardbeg_reserve,
 .init_early = tegra_ardbeg_init_early,
 .init_irq = irqchip_init,
 .init_time = clocksource_of_init,
 .init_machine = tegra_ardbeg_dt_init,
 .restart = tegra_assert_system_reset,
 .dt_compat = ardbeg_dt_board_compat,
 .init_late      = tegra_init_late
MACHINE_END

 

在tegra_ardbeg_dt_init()中,初始化和定义了板级设备。如memory, display, uart, usb, i2c, audio等。

可以看到,每个ARM开发板,均需要对应的Machine ID对应,并用代码实现对应的初始化和功能定义。

 

2.无Linux Device Tree之前ARM Board 存在的问题:

很明显,其实Board Info独立于Kernel之外。所以每次Kernel升级,都需要Board Info的实现者对应做升级和测试工作。又因为ARM 对应开发板极其众多,所以这堆代码(arch/arm/)越来越庞大。各个Table之间可能会有冲突。且很多代码有重合和冲突的可能。

在一次Kernel升级后,OMAP平台的维护者Tony Lindgren提交了OMAP的升级。但长期被ARM板级代码困扰的Linus终于爆发了:Gaah. Guys, this whole ARM thing is a f*cking pain in the ass.

ARM Linux维护者也提出了各种不同意见和改进建议。

 

分析下来,同一件事,在不同的人看来,有不同的层次和意义(屁股决定大脑):

A. 内核维护者(与CPU体系结构无关的代码)

B. 维护ARM系统结构者。

C. 维护ARM sub architecture者(来自ARM SOC vendor)

ARM Sub Architecture维护者来自 ARM芯片提供厂商,他们的第一要素是尽快把SOC推出市场,而不是代码多么合理和美观。

维护ARM体系结构的人能力不容置疑,但他们面对的是不断有新SOC加入的局面。且这也是ARM能够与Intel抗衡的根本。

内核维护者对整个系统更加高屋建瓴。他们注意到每次kernel升级,ARM代码变化量占整个ARCH目录的60%,他们认为这明显意味着ARM Linux 代码存在问题。

 

如此人员和架构设计,会导致ARM sub architecture缺乏沟通,代码有重复。且质量不高。

 

 

3. 解决方案:

针对重复的代码问题,如果不同的SOC使用了相同的IP block(例如I2C controller),那么这个driver的code要从各个arch/arm/mach-xxx中独立出来,变成一个通用的模块供各个SOC specific的模块使用。移动到哪个目录呢?对于I2C或者USB OTG而言,这些HW block的驱动当然应该移动到kernel/drivers目录。因为,对于这些外设,可能是in-chip,也可能是off-chip的,但是对于软件而言,它们是没有差别的(或者说好的软件抽象应该掩盖底层硬件的不同)。对于那些system level的code呢?例如clock control、interrupt control。其实这些也不是ARM-specific,应该属于linux kernel的核心代码,应该放到linux/kernel目录下,属于core-Linux-kernel frameworks。当然对于ARM平台,也需要保存一些和framework交互的code,这些code叫做ARM SoC core architecture code。OK,总结一下:

1、ARM的核心代码仍然保存在arch/arm目录下

2、ARM SoC core architecture code保存在arch/arm目录下

3、ARM SOC的周边外设模块的驱动保存在drivers目录下

4、ARM SOC的特定代码在arch/arm/mach-xxx目录下

5、ARM SOC board specific的代码被移除,由Device Tree机制来负责传递硬件拓扑和硬件资源信息。

 

4. Device Tree使用概述:

从前面的文字看来,Device Tree是用来替代之前将Hardware配置信息直接写入Code的办法,改用写入一个DB的方法。

之前习惯于每个ARM platform编译一个Kernel Image。但从长远来看,未来将会希望所有Platform对应一个Image。那么Bootloader在启动kernel,需要指出识别出的Platform信息。

 

那Device Tree从生成到使用流程如何呢?

A: 充分了解硬件配置和系统运行参数,并将信息写入Device Tree source file.

B: 使用Device Tree Compiler(DTC)将Device Tree Source File编译成适合机器处理的Device Tree binary file(又叫:Device Tree Blob----DTB).

C: 在系统启动时,Boot Program(BIOS,Bootloader)可以将Flash中的DTB copy到内存。

D: 把DTB内存地址传递给后续程序(bootloader或Kernel)。

 

 

5. Device Tree Source file

Device Tree Source file中并不需要描述系统中所有硬件,一些可以动态探测到的设备不需要被描述,如USB Device。但对于SOC上的USB Host Controller,因为无法自动识别,需要在Device Tree Source file中描述。

其实这和Device Tree 出现前的Board file时的准则是一致的。

 

 Device Tree Source file是由一个或多个node组成的,node格式是:

[label:] node-name[@unit-address] { 
   [properties definitions] 
   [child nodes] 
}

以kernel/arch/arm/boot/dts/skeleton.dtsi为例(dtsi: device tree source include):

/ {
 #address-cells = <1>;
 #size-cells = <1>;
 chosen { };
 aliases { };
 memory { device_type = "memory"; reg = <0 0>; };
};

可以看到,"/"是跟节点的node name, {}之间是该node的具体定义,其内容包括各种属性和child node.

属性包括:

 #address-cells = <1>;
 #size-cells = <1>;

 

子node包括:

 chosen { };
 aliases { };
 memory { device_type = "memory"; reg = <0 0>; };

 

 

6. Device Tree Compiler:

DTC 源码在scripts/dtc目录下。而某个Platform编译时,哪些dtb会被编译出来,则可以在arch/arm/boot/dts/Makefile中看到。

这里可以看出,dtb其实是和Linux Kernel分离的。所以,它可以单独被编译出来:

make dtbs

 

 

7. Device Tree对BSP和Device Driver造成的影响和变更

如上所述,Device Tree就是为了取代板级信息代码而推出的。所以,大量在arch/arm/plat-xxxx, arch/arm/mach-xxxx中做的工作不再是必要的了。

A: 注册platform_device,绑定resource,即内存、IRQ等板级信息

形如

 

static struct resource xxx_resources[] = {
         [0] = {
                 .start  = …,
                 .end    = …,
                 .flags  = IORESOURCE_MEM,
         },
         [1] = {
                 .start  = …,
                 .end    = …,
                 .flags  = IORESOURCE_IRQ,
        },
 };

 static struct platform_device xxx_device = {
         .name           = "xxx",
         .id             = -1,
         .dev            = {
                                 .platform_data          = &xxx_data,
         },
         .resource       = xxx_resources,
         .num_resources  = ARRAY_SIZE(xxx_resources),
 };

 

 

 

之类的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:

 static struct of_device_id xxx_of_bus_ids[] __initdata = {
         { .compatible = "simple-bus", },
         {},
 };

 void __init xxx_mach_init(void)
 {
         of_platform_bus_probe(NULL, xxx_of_bus_ids, NULL);
 }

 #ifdef CONFIG_ARCH_XXX

 DT_MACHINE_START(XXX_DT, "Generic XXX (Flattened Device Tree)")
         …
         .init_machine   = xxx_mach_init,
         …
 MACHINE_END
 #endif

 

B. 注册i2c_board_info,指定IRQ等board级别信息:

 

 

static struct i2c_board_info __initdata inv_mpu9250_i2c0_board_info[] = {
 {
  I2C_BOARD_INFO(MPU_GYRO_NAME, MPU_GYRO_ADDR),// MPU_GYRO_ADDR=0x68
  .platform_data = &mpu9250_gyro_data,
 },
 {
  I2C_BOARD_INFO(MPU_BMP_NAME, MPU_BMP_ADDR),
  .platform_data = &mpu_bmp_pdata,
 },
 {
  I2C_BOARD_INFO(MPU_COMPASS_NAME, MPU_COMPASS_ADDR),
  .platform_data = &mpu_compass_data,
 },
};

 

 

 

 

 

inv_mpu9250_i2c0_board_info[0].irq = gpio_to_irq(MPU_GYRO_IRQ_GPIO);

i2c_register_board_info(gyro_bus_num, inv_mpu9250_i2c0_board_info, ARRAY_SIZE(inv_mpu9250_i2c0_board_info));

 

 

 

 

可以在dtsi中修改为:

/ {
  {
   {
   compatible = "invensense,mpu6515";
   reg = <0x68>;
   interrupt-parent = <&gpio>;
   interrupts = <169 0x01>;
   invensense,int_config = <0x10>;
   invensense,level_shifter = <0>;
   invensense,orientation = [ff 00 00 00 01 00 00 00 ff];
   invensense,sec_slave_type = <0>;
   invensense,key = [4e cc 7e eb f6 1e 35 22
       00 34 0d 65 32 e9 94 89];
   vlogic-supply = <&palmas_smps8>;
   vdd-supply = <&palmas_smps9>;
  };

   {
   compatible = "ak,ak8963";
   reg = <0x0c>;
   orientation = [ff 00 00 00 01 00 00 00 ff];
   config = "mpu";
   vid-supply = <&palmas_smps8>;
   vdd-supply = <&palmas_smps9>;
  };
 };
};

 

 

 

 

 

 

 

 

内容参考于:

http://blog.csdn.net/21cnbao/article/details/8457546

阅读(2881) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~