Kernel[Device Tree] - 1. 设备树的由来

内核代码中,arch文件夹下,是各个架构相关的代码,arm也在里面。

arm子文件夹下,有mach-xxx的目录,就是针对各个芯片类型的,比如mach-imx就是imx系列的芯片。

再里面就是具体的芯片或SOC,比如mach-imx6ul.c,这就是使用iMX6UL或者iMX6uLL的芯片的内容。

最开始,内核里的这部分代码,在内核源码中,存在大量对板级细节信息描述的代码, board specific函数。

这些代码充斥在/arch/arm/plat-xxx和/arch/arm/mach-xxx目录,对内核而言这些platform设备、resource、i2c_board_info、spi_board_info以及各种硬件的platform_data绝大多数纯属垃圾冗余代码。

这样每款芯片,不同的板子,都要有相应的代码维护。

但这些代码和一些描述硬件信息的静态table,对内核来讲毫无意义,徒增臃肿,应该避免。

否则维护这些代码和merge这些改动,工作量大,容易冲突。

ARM也是个特例,不像Intel芯片架构固定和易于管理,ARM很多应用于嵌入式,而且使用了license IP的方式,让很多厂商加入ARM生态系统,但芯片厂商太多,就有越来越多的ARM平台的代码加入内核,每个厂商的周边硬件的设计又不同,就给内核代码维护带来麻烦。而这些代码中还会有大量重复。

在Linux kernel维护和release中,就出现了在merge windows中,对ARM相关部分的patch的merge,有一些conflicts要处理,虽然用邮件做了详细说明了改动内容和冲突如何结局,但这个pull request还是引起了争议。

2011年3月17日邮件中Linux原话:Gaah. Guys, this whole ARM thing is a f*cking pain in the ass.

https://lkml.org/lkml/2011/3/17/492

From  Linus Torvalds <>

Date  Thu, 17 Mar 2011 19:50:36 -0700

Subject  Re: [GIT PULL] omap changes for v2.6.39 merge window

On Thu, Mar 17, 2011 at 11:30 AM, Tony Lindgren <tony@atomide.com> wrote:

>

> Please pull omap changes for this merge window from:

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

You need to stop stepping on each others toes. There is no way that

your changes to those crazy clock-data files should constantly result

in those annoying conflicts, just because different people in

different ARM trees do some masturbatory renaming of some random

device. Seriously.

That usb_musb_init() thing in arch/arm/mach-omap2/usb-musb.c also

seems to be totally insane. I wonder what kind of insanity I'm missing

just because I don't happen to see the merge conflicts, just because

people were lucky enough to happen to not touch the same file within a

few lines.

Somebody needs to get a grip in the ARM community. I do want to do

these merges, just to see how screwed up things are, but guys, this is

just ridiculous. The pure amount of crazy churn is annoying in itself,

but when I then get these "independent" pull requests from four

different people, and they touch the same files, that indicates that

something is wrong.

And stop the crazy renaming already! Just leave it off. Don't rename

boards and drivers "just because", at least not when there clearly are

clashes. There's no point. I'm not even talking about the file renames

(which happened and can also make it "fun" to try to resolve the

conflicts when somebody else then makes _other_ changes), but about

the stupid "change human-readable names in board files just to annoy

whoever needs to merge the crap".

Somebody in the ARM community really needs to step up and tell people

to stop dicking around.

(I'm replying to the omap pull request, because that's the one I did

last, but I don't know who to "blame". I don't care. It really doesn't

matter. I realize thar ARM vendors do crazy shit and haven't figured

out this whole "platform" thing yet, but you guys need to push back on

the people sending you crap).

                                   Linus

Linus注意到每次merge window中,ARM的代码变化中大约占整个ARCH目录的60%,他认为这是一个很明显的信号,意味着ARM linux的代码可能存在问题。

经过不断的讨论,确定问题如下:

1. ARM linux缺少platform(各个ARM sub architecture,或者说各个SOC)之间的协调,导致arm linux的代码有重复。

2. ARM linux中大量的board specific的源代码应该踢出kernel,否则这些垃圾代码和table会影响linux kernel的长期目标。

3. 各个sub architecture的维护者直接提交给Linux并入主线的机制缺乏层次。

解决方法:

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机制来负责传递硬件拓扑和硬件资源信息。

于是乎,Open Firmware这个在PowerPC架构中使用的硬件描述语言就进入了视野:Flattened Device Tree(FDT)。

Device Tree是一种描述硬件的数据结构,它起源于OpenFirmware (OF)。

kernel v2.6.23这个版本开始,drivers目录下多了一个of目录,of表示open firmware,里面存放device tree相关的处理。

2011年3月开始,内核在PowerPC、ARM等体系里正式使用设备树。

ARM内核版本3.x之后引入了原先在Power PC等其他体系架构已经使用的Flattened Device Tree。

以ARM为例,加入设备树的版本就是v3.1,在\arch\arm\boot\dts路径下,有各个芯片的dts文件。

在Linux 2.6中,ARM架构的板极硬件细节过多地被硬编码在arch/arm/plat-xxx和arch/arm/mach-xxx,采用Device Tree后,许多硬件的细节可以直接透过它传递给Linux,而不再需要在kernel中进行大量的冗余编码。

Device Tree由一系列被命名的结点(node)和属性(property)组成,而结点本身可包含子结点。所谓属性,其实就是成对出现的name和value。在Device Tree中,可描述的信息包括(原先这些信息大多被hard code到kernel中):

- CPU的数量和类别

-  内存基地址和大小

-  总线和桥

-  外设连接

-  中断控制器和中断使用情况

-  GPIO控制器和GPIO使用情况

-  Clock控制器和Clock使用情况

它基本上就是画一棵电路板上CPU、总线、设备组成的树,Bootloader会将这棵树传递给内核,然后内核可以识别这棵树,并根据它展开出Linux内核中的platform_device、i2c_client、spi_device等设备,而这些设备用到的内存、IRQ等资源,也被传递给了内核,内核会将这些资源绑定给展开的相应的设备。

整个Device Tree牵涉面比较广,即增加了新的用于描述设备硬件信息的文本格式,又增加了编译这一文本的工具,同时Bootloader也需要支持将编译后的Device Tree传递给Linux内核。

开源文档中对设备树的描述是,一种描述硬件资源的数据结构,它通过bootloader将硬件资源传给内核,使得内核和硬件资源描述相对独立(也就是说*.dtb文件由Bootloader读入内存,之后由内核来解析)。

DTS (device tree source).dts 文件是一种ASCII 文本格式的Device Tree描述,此文本格式非常人性化,适合人类的阅读习惯。基本上,在ARM Linux在,一个.dts 文件对应一个ARM的machine,一般放置在内核的arch/arm/boot/dts/目录。由于一个SoC可能对应多个machine(一个SoC可以对应多个产品和电路板),势必这些.dts 文件需包含许多共同的部分,Linux内核为了简化,把SoC公用的部分或者多个machine共同的部分一般提炼为.dtsi,类似于C语言的头文件。其他的machine对应的.dts 就include这个.dtsi。

设备树的主要优势:对于同一SOC的不同主板,只需更换设备树文件.dtb即可实现不同主板的无差异支持,而无需更换内核文件。

注:

1. 要使得3.x之后的内核支持使用设备树,除了内核编译时需要打开相对应的选项外,bootloader也需要支持将设备树的数据结构传给内核。

2. Linux使用device tree的主要是各类嵌入式设备,比如ARM架构的。PC上X86架构,并没有使用Device Tree,使用的自然是主板自带的BIOS来管理硬件信息。

3. 在Linux内核源码中,就有相关的Devicetree的说明文档,比如我下载的Linux 5.17版本就是:linux-5.17-rc4\Documentation\devicetree

    想找我使用的imx6ull芯片的特殊说明,就在:linux-5.17-rc4\Documentation\devicetree\bindings\arm\freescale

    想找某个功能的,就要选择相应的文件夹,比如端子设置的:linux-5.17-rc4\Documentation\devicetree\bindings\pinctrl\fsl,imx6ul-pinctrl.txt

4. 在arch\arm\boot\dts里面找ARM架构芯片的devicetree,比如使用imx6ull的开发板imx6ull-14x14-evk,那相关的devicetree文件就是(包含里面层层嵌套的文件):

imx6ul-14x14-evk.dtsi

imx6ul-pinfunc.h

imx6ul.dtsi

imx6ull-14x14-evk.dts

imx6ull-pinfunc-snvs.h

imx6ull-pinfunc.h

imx6ull.dtsi

5,在kernel/include/dt-bindings下,也放了各种外设、各种架构的和device tree binding相关的信息。

  • 7
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

夜流冰

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值