分类: 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>;
};
};
};
内容参考于: