新闻资讯
Group news
青岛广盛源肥业有限公司    您的位置: 首页  >  新闻资讯  >  正文

详细介绍Linux Device Tree的原理及应用

2019年10月12日 文章来源:网络整理 热度:200℃ 作者:刘英

作为一个多年耕耘在linux 2.6.23内核的开发者,各个不同项目中各种不同周边外设驱动的开发以及各种琐碎的、扯皮的俗务占据了大部分的时间。当有机会下载3.14的内核并准备学习的时候,突然发现linux kernel对于我似乎变得非常的陌生了,各种新的机制,各种framework、各种新的概念让我感到阅读内核代码变得举步维艰。 还好,剖析内核的热情还在,剩下的就交给时间的。首先进入视线的是Device Tree机制,这是和porting内核非常相关的机制,如果想让将我们的硬件平台迁移到高版本的内核上,Device Tree是一个必须要扫清的障碍。

我想从下面三个方面来了解Device Tree:

1、为何要引入Device Tree,这个机制是用来解决什么问题的?(这是本文的主题)

2、Device Tree的基础概念(请参考DT基础概念)

3、ARM linux中和Device Tree相关的代码分析(请参考DT代码分析)

阅读linux内核代码就像欣赏冰山,有看得到的美景(各种内核机制及其代码),也有埋在水面之下看不到的基础(机制背后的源由和目的)。沉醉于各种内核机制的代码固然有无限乐趣,但更重要的是注入更多的思考,思考其背后的机理,真正理解软件抽象。这样才能举一反三,并应用在具体的工作和生活中。

本文主要从下面几个方面阐述为何ARM linux会引入Device Tree:

1、没有Device Tree的ARM linux是如何运转的?

2、混乱的ARM architecture代码和存在的问题

3、新内核的解决之道

二、没有Device Tree的ARM linux是如何运转的?

我曾经porTIng内核到两个ARM-based的平台上。一个是小的芯片公司的应用处理器,公司自己购买了CPU core,该CPU core使用ARM兼容的指令集(但不是ARM)加上各种公司自行设计的多媒体外设整合成公司的产品进行销售。而我的任务就是porTIng 2.4.18内核到该平台上。在黑白屏幕的手机时代,那颗AP(applicaTIon process)支持了彩屏、camera、JPEG硬件加速、2D/3D加速、MMC/SD卡、各种音频加速(内置DSP)等等特性,功能强大到无法直视。另外一次移植经历是让2.6.23内核跑在一个大公司的冷门BP(baseband processor)上。具体porTIng的方法是很简单的:

1、自己撰写一个bootloader并传递适当的参数给kernel。除了传统的command line以及tag list之类的,最重要的是申请一个machine type,当拿到属于自己项目的machine type ID的时候,当时心情雀跃,似乎自己已经是开源社区的一份子了(其实当时是有意愿,或者说有目标是想将大家的代码并入到linux kernel main line的)。

2、在内核的arch/arm目录下建立mach-xxx目录,这个目录下,放入该SOC的相关代码,例如中断controller的代码,时间相关的代码,内存映射,睡眠相关的代码等等。此外,最重要的是建立一个board specific文件,定义一个machine的宏:

MACHINE_START(project name, "xxx公司的xxx硬件平台") 
    .phys_io    = 0x40000000, 
    .boot_params    = 0xa0000100,   
    .io_pg_offst    = (io_p2v(0x40000000) >> 18) & 0xfffc, 
    .map_io        = xxx_map_io, 
    .init_irq    = xxx_init_irq, 
    .timer        = &xxx_timer, 
    .init_machine    = xxx_init, 
MACHINE_END

在xxx_init函数中,一般会加入很多的platform device。因此,伴随这个board specific文件中是大量的静态table,描述了各种硬件设备信息。

3、调通了system level的driver(timer,中断处理,clock等)以及串口terminal之后,linux kernel基本是可以起来了,后续各种driver不断的添加,直到系统软件支持所有的硬件。

综上所述,在linux kernel中支持一个SOC平台其实是非常简单的,让linux kernel在一个特定的平台上“跑”起来也是非常简单的,问题的重点是如何优雅的”跑”。

三、混乱的ARM architecture代码和存在的问题

每次正式的linux kernel release之后都会有两周的merge window,在这个窗口期间,kernel各个部分的维护者都会提交各自的patch,将自己测试稳定的代码请求并入kernel main line。每到这个时候,Linus就会比较繁忙,他需要从各个内核维护者的分支上取得最新代码并merge到自己的kernel source tree中。Tony Lindgren,内核OMAP development tree的维护者,发送了一个邮件给Linus,请求提交OMAP平台代码修改,并给出了一些细节描述:

1、简单介绍本次改动

2、关于如何解决merge conficts。有些git mergetool就可以处理,不能处理的,给出了详细介绍和解决方案

一切都很平常,也给出了足够的信息,然而,正是这个pull request引发了一场针对ARM linux的内核代码的争论。我相信Linus一定是对ARM相关的代码早就不爽了,ARM的merge工作量较大倒在其次,主要是他认为ARM很多的代码都是垃圾,代码里面有若干愚蠢的table,而多个人在维护这个table,从而导致了冲突。因此,在处理完OMAP的pull request之后(Linus并非针对OMAP平台,只是Tony Lindgren撞在枪口上了),他发出了怒吼:

Gaah. Guys, this whole ARM thing is a f*cking pain in the ass.

上一篇:基于V4L2的视频驱动开发


下一篇:使用Linux C编程实现简单的ls命令

友情链接
Links