在探索Linux的庞大和复杂世界时🌌,我们经常会遇到许多关键概念和工具🛠️,它们使得Linux成为了一个强大和灵活的操作系统💪。其中,"设备树"(Device Tree)是一个不可或缺的部分🌲,尤其是在嵌入式系统🖥️和多平台硬件支持方面🔌。让我们深入了解Linux设备树是什么,它的起源,以及为什么Linux需要它🌳。
本篇文章主要讲解嵌入式板卡中Linux系统是如何正确测试、使用的,其中内容包含有U-Boot编译、U-Boot命令和环境变量说明、Linux内核编译、xtra驱动编译、系统信息查询、程序开机自启动说明、NFS使用说明、TFTP使用说明、TFTP + NFS的系统启动测试说明、inux设备驱动说明等,其中案例源码部分公开。
在根文件系统中查看设备树,是一种不错的调试手段。因为很多时候会出现你修改了 dts 文件,并且也编译了新的 dtb,但是下载到板子上的还是以前的 dtb,因此查看板子中真实生效的设备树配置信息是很重要的。
上面介绍的编译模块是和内核一起编译的,这种编译方式比较耗时。在Linux3.x 以后的版本才引入了设备树,有了设备树之后,只需要一次编译内核,编译内核的时候会生成的dtc 工具,利用dtc工具就可以完成驱动的编译。我们这里只是简单介绍如何编译设备树、加载设备树,关于设备树,后面会有更加详细的解释。
设备树(Device Tree),将这个词分开就是“设备”和“树”,描述设备设备树的文件叫做DTS(Device Tree Source),这个DTS文件采用了树形结构来描述板机设备,也就是开发板信息,比如CPU数量、内存基地址、IIC接口上接了那些设备、SPI接口上接了那些设备等。如最开始的图片所示! 在图片中,树的主干就是系统总线,IIC控制器、SPI控制器等都是接到系统主线的分支上的。通过DTS这个文件描述设备信息是有相关的语法规则的,并且在Linux内核中只有3.x版本以后的才支持设备树。
NAND FLASH版本和eMMC版本核心板使用方法基本一致。本文主要描述U-Boot编译、基础设备树文件编译、固化Linux系统NAND FLASH分区说明和NAND FLASH启动系统、固化Linux系统、AND FLASH读写测试等,NAND FLASH版本与eMMC版本核心板在使用方面的不同之处,相同之处将不重复描述。
上一节说过设备树的出现是为了解决内核中大量的板级文件代码,通过 DTS 可以像应用程序里的 XML 语言一样很方便的对硬件信息进行配置。关于设备树的出现其实在 2005 年时候就已经在 PowerPC Linux 里出现了,由于 DTS 的方便性,慢慢地被广泛应用到 ARM、MIPS、X86 等架构上。为了理解设备树的出现的好处,先来看下在使用设备树之前是采用什么方式的。
参考地址 http://blog.csdn.net/green1900/article/details/45646095 http://www.cnblogs.com/xiaojiang1025/p/6131381.html http://blog.csdn.net/21cnbao/article/details/8457546
Linux内核从3.x开始引入设备树的概念,用于实现驱动代码与设备信息相分离。在设备树出现以前,所有关于设备的具体信息都要写在驱动里,一旦外围设备变化,驱动代码就要重写。引入了设备树之后,驱动代码只负责处理驱动的逻辑,而关于设备的具体信息存放到设备树文件中,这样,如果只是硬件接口信息的变化而没有驱动逻辑的变化,驱动开发者只需要修改设备树文件信息,不需要改写驱动代码。比如在ARM Linux内,一个.dts(device tree source)文件对应一个ARM的machine,一般放置在内核的"arch/arm/boot/dts/"目录内,比如exynos4412参考板的板级设备树文件就是"arch/arm/boot/dts/exynos4412-origen.dts"。这个文件可以通过$make dtbs命令编译成二进制的.dtb文件供内核驱动使用。
上篇文章(【i.MX6ULL】驱动开发4--点亮LED(寄存器版))介绍了在驱动程序中,直接操作寄存器了点亮LED。本篇,介绍另外一种点亮LED的方式——设备树,该方式的本质也是操作寄存器,只是寄存器的相关信息放在了设备树中,配置寄存器时需要使用OF函数从设备树中读取处寄存器数据后再进行配置。
NXP官方linux仓库地址为:https://github.com/Freescale/linux-fslc/tree/5.4-2.1.x-imx。
最近有一些riscv的项目做,虽然以前也用过例如k210之类的riscv架构的芯片,但是都止于能够做一些应用,并未特别关注其芯片的体系架构方面的东西,但是随着接触的芯片架构的种类的逐渐的增加,发现要想使用一款好芯片的,仅仅做上层应用并不能完全发挥出特定架构芯片的全部优势。比如aarch64的el层级和虚拟化的模型,mips的mmu特性,以及sparc的窗口寄存器等等,芯片架构的特点要是能够完全的发挥出来,写起应用起来,那真是觉得很爽的事情。
很多学员有过STM32的学习经验,他们手上的开发板很多,LCD也很多。 一个LCD还挺贵的,不能浪费。 各家的LCD引脚顺序都不一样,所以别家的LCD不能直接接到100ASK_IMX6ULL开发板,需要转接板。 大部分单片机学员都是使用正点原子、野火的板子,有他们的屏。 针对这两家的屏,我们做了转接板,如下:
修改内核文件:drivers/video/fbdev/Makefile,把内核自带驱动程序mxsfb.c对应的那行注释掉,如下:
总线、设备和驱动模型,如果把它们之间的关系比喻成生活中的例子是比较容易理解的。举个例子,充电墙壁插座安静的嵌入在墙面上,无论设备是电脑还是手机,插座都能依然不动的完成它的使命——充电,没有说为了满足各种设备充电而去更换插座的。其实这就是软件工程强调的高内聚、低耦合概念。
Linux内核从3.x开始引入设备树的概念,用于实现驱动代码与设备信息相分离。在设备树出现以前,所有关于设备的具体信息都要写在驱动里,一旦外围设备变化,驱动代码就要重写。
在platform_device部分有简单说明描述设备有两种方法:一种是使用platform_device结构体来指定;另一种是使用设备树来描述。
设备树是一种数据结构,它通过特有的语法格式描述片上片外的设备信息。由BootLoader传递给kernel,kernel进行解析后形成和驱动程序关联的dev结构供驱动代码使用。
设备树 (DT, Device Tree) 是用于描述 non-discoverable(google这样写的,意思应该就是硬件信息看不到) 硬件的命名节点和属性构成的一种数据结构。操作系统(例如在 Android 中使用的 Linux 内核)会使用 DT 来支持 Android 设备使用的各种硬件配置。硬件供应商会提供自己的 DT 源文件,接下来 Linux 会将这些文件编译成引导加载程序使用的DTB(Device Tree BLOB)文件。
部分硬件设计中需要CPU完成对电路寄存器的配置,为了完成Zedboard对FPGA上部分寄存器的配置功能,可以在PS单元(处理器系统)上运行裸机程序(无操作系统支持)完成和PL单元(FPGA部分)的数据交互功能,此时PS单元更像单片机开发;另一种方法是PS单元运行Linux操作系统,通过驱动程序和应用程序完成对硬件寄存器的读写操作,并且Linux有着完整的网络协议栈支持,后续可拓展性更强,可以更好的发挥ZYNQ这种异构架构芯片的性能。主要分为两部分,分别阐述Zedboard中FPGA和处理器互联总线与硬件设计和Zedboard处理器系统上嵌入式Linux的移植与通过驱动和应用程序简单配置FPGA寄存器的实现。上次介绍了没有操作系统下的驱动和应用程序开发,本文介绍带操作系统的驱动和应用程序开发。
今天和大家分享的依然是设备树,上一节里主要是介绍了设备树文件的基本格式、语法规则等,今天介绍一下如何使用设备树,以及如何动态加载设备树。
我们需要编写设备树文件 (dts: device tree source) ,它需要编译为 dtb(device tree blob) 文件,内核使用的是 dtb 文件。
在之前使用 S3C2440 开发板移植 Linux 3.4.2 内核时,修改了很多关于 c 文件去适配开发板,和开发板相关的文件放在arch/arm/mxch-xxx目录下,因此 linux 内核 arm 架构下添加了很多开发板的适配文件:
本文将以Myirtech的MYD-YF13X以及STM32MP135F-DK为例,讲解如何使用STM32CubeMX结合Developer package实现最小系统启动。
默认情况下,所有接口信号引脚都配置为GPIO输入,除了引脚3和5、引脚27和28 (I2C SDA和SCL)、引脚8和10 (UART TX和RX)。
进入 uboot 的命令行模式以后输入“help”或者“?”,然后按下回车即可查看当前 uboot 所支持的命令,如下图所示:
理想状况是:按下、松开按键,各产生一次中断,也只产生一次中断。 但是对于机械开关,它的金属弹片会反复震动。GPIO电平会反复变化,最后才稳定。一般是几十毫秒才会稳定。 如果不处理抖动的话,用户只操作一次按键,会发生多次中断,驱动程序可能会上报多个数据。
Dts:DTS即Device Tree Source,是一个文本形式的文件,用于描述硬件信息。一般都是固定信息,无法变更,无法overlay。
有人在NVIDIA官方论坛上反应NVIDIA Jetson Orin NANO开发套件启动时间太久?如何缩短这个时间呢?
转载请注明文章地址 http://wiki.100ask.org/Linux_devicetree
【CSDN 编者按】自去年苹果自研 M1 芯片发布之后,激发了无数用户的体验热情,与此同时,也吸引大批开发者在 M1 上开启探索模式。其中,国外一位资深操作系统移植专家 Hector Martin 发起了一项名为「Asahi Linux」项目,通过众筹的方式为苹果 M1 系列新机移植 Linux 系统。
分享产品试用报告,测试板卡是基于Xilinx Zynq-7000系列XC7Z010/XC7Z020高性能低功耗处理器设计的异构多核SoC工业级核心板。
本篇的重点是讲解设备和驱动的启动流程,设备和驱动的流程是整个内核启动的核心,也是工作中最常面对的问题。出于知识点的系统性考虑,在进入主题之前我们先看下整个 Linux 在 ARM 中的启动流程如何。
为降低RK3568J功耗,提高运行系统健壮性,在产品现场对RK3568J实现主频调节则显得尤为重要。
在Linux 2.6中, ARM架构的板极硬件细节过多地被硬编码在arch/arm/plat-xxx和arch/arm/mach-xxx中,采用设备树后,许多硬件的细节可以直接通过它传递给Linux,而不再需要在内核中进行大量的冗余编码。
传统的配置 pin 的方式就是直接操作相应的寄存器,但是这种配置方式比较繁琐、而且容易出问题(比如 pin 功能冲突)。pinctrl 子系统就是为了解决这个问题而引入的,pinctrl 子系统主要工作内容如下:
设备树(Device Tree),将这个词分开就是“设备”和“树”,描述设备树的文件叫做 DTS(DeviceTree Source),这个 DTS 文件采用树形结构描述板级设备,也就是开发板上的设备信息,比如CPU 数量、 内存基地址、IIC 接口上接了哪些设备、SPI 接口上接了哪些设备等等。
对于linux3.0之后,linux内核支持了设备树“这个家伙”,刚接触Device Tree的人,一开始会比较迷茫,不知道怎么用,他究竟有多强大。作者刚接触的时候也是一样,在我之前的一篇文章《linux 设备树与驱动的关系》中,将早先时候的设备模块与现在的设备树的区别进行了比较。作者在这里也说说我在学习一点小经验:
前面通过学习总线、设备、驱动模型知识后,知道了设备和驱动之间都是通过总线进行绑定而匹配的;然后通过设备树的深入探究,知道了设备树的出现大大增加了驱动的通用性;接着我们一起看了 Linux 的启动流程和设备在内核里一层一层的展开。
今天跟大家分享的是设备树,设备树是Linux3.x以后的版本才引入的,设备树用于描述一个硬件平台的板级细节。
linux作为一款流行的嵌入式系统,目前已经有多种架构的MCU支持Linux移植,arm64就是其中一种。今天在这里想做一个笔记,记录一下完整的arm64移植过程。
这节课讲解如何在中断系统中使用设备树,也就是用设备树如何描述中断。 中断体系在4.x内核中变化很大,中断体系又跟pinctrl系统密切相关,pinctrl中又涉及GPIO子系统,这样讲下去的话,设备树课程就变成驱动专题了,所以我打算只讲中断体系统,对于pinctrl、gpio等系统留待以后在驱动课程中扩展。
整理出了6种驱动开发时与设备注册、设备树相关的调试方法,彼此间没有优先级之分,每种方法不一定是最优解,但可以作为一种debug查找问题的手段,快速定位问题原因。例如在芯片验证时,不同时钟频率下系统启动情况摸底时,U-Boot fdt命令可以方便快捷的帮助我们完成这个实验。
Zynq的程序分为三部分,上电启动的引导程序(fsbl),FPGA的程序,arm程序。这里以arm程序存储位置为主进行讨论。
在内核里,使用gic_chip_data结构体表示GIC,gic_chip_data里有什么?
上一篇文章学习了字符设备的注册,操作过的小伙伴都知道上一篇文章中测试驱动时是通过手动创建设备节点的,现在开始学习怎么自动挂载设备节点和设备树信息的获取,这篇文章中的源码将会是我以后编写字符驱动的模板。
领取专属 10元无门槛券
手把手带您无忧上云