在根文件系统中查看设备树,是一种不错的调试手段。因为很多时候会出现你修改了 dts 文件,并且也编译了新的 dtb,但是下载到板子上的还是以前的 dtb,因此查看板子中真实生效的设备树配置信息是很重要的。
Device Tree 是目前嵌入式 Linux 系统最常用的设备解耦工具, 所以要玩转嵌入式 Linux , 这个东西必须掌握.
linux作为一款流行的嵌入式系统,目前已经有多种架构的MCU支持Linux移植,arm64就是其中一种。今天在这里想做一个笔记,记录一下完整的arm64移植过程。
Dts:DTS即Device Tree Source,是一个文本形式的文件,用于描述硬件信息。一般都是固定信息,无法变更,无法overlay。
Raspberry Pi 内核Linux代码存储在 GitHub 中,可以在github.com/raspberrypi/linux上查看。
转载请注明文章地址 http://wiki.100ask.org/Linux_devicetree
NXP 会从linux内核官网下载某个版本,然后将其移植到自己的 CPU上,测试成功后就会将其开放给NXP的CPU开发者。开发者下载 NXP 提供的 Linux 内核,然后将其移植到自己的产品上。
上面介绍的编译模块是和内核一起编译的,这种编译方式比较耗时。在Linux3.x 以后的版本才引入了设备树,有了设备树之后,只需要一次编译内核,编译内核的时候会生成的dtc 工具,利用dtc工具就可以完成驱动的编译。我们这里只是简单介绍如何编译设备树、加载设备树,关于设备树,后面会有更加详细的解释。
NAND FLASH版本和eMMC版本核心板使用方法基本一致。本文主要描述U-Boot编译、基础设备树文件编译、固化Linux系统NAND FLASH分区说明和NAND FLASH启动系统、固化Linux系统、AND FLASH读写测试等,NAND FLASH版本与eMMC版本核心板在使用方面的不同之处,相同之处将不重复描述。
请按前面第七章使用 GIT 下载源码、使用 repo 下载工具链,并配置了交叉编译工具链。
在内核源码中,存在大量对板级细节信息描述的代码。这些代码充斥在/arch/arm/plat-xxx和/arch/arm/mach-xxx目录,对内核而言这些platform设备、resource、i2c_board_info、spi_board_info以及各种硬件的platform_data绝大多数纯属垃圾冗余代码。为了解决这一问题,ARM内核版本3.x之后引入了原先在Power PC等其他体系架构已经使用的Flattened Device Tree。
下载链接:en.SOURCES-tf-a-stm32mp1-openstlinux-5-10-dunfell-mp1-21-11-17_tar.xz[1]。
参考地址 http://blog.csdn.net/green1900/article/details/45646095 http://www.cnblogs.com/xiaojiang1025/p/6131381.html http://blog.csdn.net/21cnbao/article/details/8457546
设备树 (DT, Device Tree) 是用于描述 non-discoverable(google这样写的,意思应该就是硬件信息看不到) 硬件的命名节点和属性构成的一种数据结构。操作系统(例如在 Android 中使用的 Linux 内核)会使用 DT 来支持 Android 设备使用的各种硬件配置。硬件供应商会提供自己的 DT 源文件,接下来 Linux 会将这些文件编译成引导加载程序使用的DTB(Device Tree BLOB)文件。
AMD MPSoC Linux一般使用PetaLinux编译Linux系统,包括Linux内核、DTS、文件系统。
可能很多玩 Linux 的同学都听过 mainline 或者 upstream 这两个词,但是又搞不清他们到底指的是什么。
前进几篇文章,已经搞定了Linux移植三巨头:uboot、kernel(包含dtb)和rootfs,除了uboot是烧写在SD中的,其它的都是在ubuntu虚拟机的nfs服务器中,运行时必须通过网络将这些文件加载到开发板的内存中运行。
最近业余时间都在学习 Linux 内核和英语,或者是陪家人玩耍,没有投入太多的时间在文章。
zynq u-boot github地址:https://github.com/xilinx
在Linux 2.6中, ARM架构的板极硬件细节过多地被硬编码在arch/arm/plat-xxx和arch/arm/mach-xxx中,采用设备树后,许多硬件的细节可以直接通过它传递给Linux,而不再需要在内核中进行大量的冗余编码。
在之前使用 S3C2440 开发板移植 Linux 3.4.2 内核时,修改了很多关于 c 文件去适配开发板,和开发板相关的文件放在arch/arm/mxch-xxx目录下,因此 linux 内核 arm 架构下添加了很多开发板的适配文件:
本篇文章主要讲解嵌入式板卡中Linux系统是如何正确测试、使用的,其中内容包含有U-Boot编译、U-Boot命令和环境变量说明、Linux内核编译、xtra驱动编译、系统信息查询、程序开机自启动说明、NFS使用说明、TFTP使用说明、TFTP + NFS的系统启动测试说明、inux设备驱动说明等,其中案例源码部分公开。
编译器下载地址:Downloads | GNU-A Downloads – Arm Developer[1]
被誉为 “世界上最流行最便宜的小型电脑” 的「树莓派」Raspberry Pi 是一款性价比超高的迷你电脑主机 (仅有信用卡大小), 深受全球开发者、极客、技术爱好者们的追捧和喜爱
2、这里选择 /dev/sdb,这个是我们的 SD 卡,/dev/sda是我们的系统磁盘,千万不要选错,否则接下里的格式化会把系统磁盘格式化
SyterKit 是一个纯裸机框架,用于 TinyVision 或者其他 v851se/v851s/v851s3/v853 等芯片的开发板,SyterKit 使用 CMake 作为构建系统构建,支持多种应用与多种外设驱动。同时 SyterKit 也具有启动引导的功能,可以替代 U-Boot 实现快速启动
title: uboot处理dtb date: 2019/4/28 17:18:19 toc: true —
前言 本文翻译于Chiral Software的《Compiling Modules For The Jetson TX2》,点击阅读原文了解更多信息。 英伟达的Jetson TX2是在小型和低功耗设备上做机器学习方面应用开发的好东西。它的主机操作系统是标准的Ubuntu 16.04。这意味着我们可以启用任何我们需要的Linux内核模块,比如我们需要启用某些默认TX2不支持的网络设备。在我们的例子中,需要接入一个串行USB调制解调器,需要串行usb模块和其它一些模块。通过交叉编译模块,我们能够使用这些网络设
ubuntu14.04编译android4.4对应的linux内核 中讲述了适用于模拟器的linux kernel源码编译。适用于真机的有一些不同。为了能够对比,本文编译的目标是:
作者: 付汉杰 hankf@xilinx.com hankf@amd.com 测试环境: Vivado/PetaLinux 2021.2, Linux 5.10.0,VCK190
设备树是一种数据结构,它通过特有的语法格式描述片上片外的设备信息。由BootLoader传递给kernel,kernel进行解析后形成和驱动程序关联的dev结构供驱动代码使用。
上文我们讲述了uboot编译及配置,本文讲述了如何编译kernel,对编译过程中遇到的问题进行解决
直接和kernel编译在一起,生成zImage-dtb,dtb的位置在kernel起始地址偏移0x2C的位置,然后和kernel一起打包到bootimage里。
在探索Linux的庞大和复杂世界时🌌,我们经常会遇到许多关键概念和工具🛠️,它们使得Linux成为了一个强大和灵活的操作系统💪。其中,"设备树"(Device Tree)是一个不可或缺的部分🌲,尤其是在嵌入式系统🖥️和多平台硬件支持方面🔌。让我们深入了解Linux设备树是什么,它的起源,以及为什么Linux需要它🌳。
使用KR260 PetaLinux 2022.1 BSP创建工程后,使用产生的wic文件烧录tf卡,Linux启动报告错误“ERROR: There's no '/dev' on rootfs.”。使用的工具是PetaLinux 2022.1.
高通平台8953 Linux DTS(Device Tree Source)设备树详解之一(背景基础知识篇)
设备树(Device Tree),将这个词分开就是“设备”和“树”,描述设备设备树的文件叫做DTS(Device Tree Source),这个DTS文件采用了树形结构来描述板机设备,也就是开发板信息,比如CPU数量、内存基地址、IIC接口上接了那些设备、SPI接口上接了那些设备等。如最开始的图片所示! 在图片中,树的主干就是系统总线,IIC控制器、SPI控制器等都是接到系统主线的分支上的。通过DTS这个文件描述设备信息是有相关的语法规则的,并且在Linux内核中只有3.x版本以后的才支持设备树。
之前的文章:《一次搞定交叉编译》 给大家讲了如何安装交叉编译工具链,搭建交叉编译环境。
经过若干天的反复测试,搜索。终于成功利用 Qemu 在 u-boot 下引导 ARM Linux 4.7.3 内核。如下详细解释整个构建过程。
前面通过学习总线、设备、驱动模型知识后,知道了设备和驱动之间都是通过总线进行绑定而匹配的;然后通过设备树的深入探究,知道了设备树的出现大大增加了驱动的通用性;接着我们一起看了 Linux 的启动流程和设备在内核里一层一层的展开。
修改设备树打开 uart1 和 uart2,在 buildroot 移植 minicom 用来测试 uart1 和 uart2。
uboot在初始化完成后会为用户提供一个命令行交互接口,用户可通过该接口执行uboot定义的命令,以用于查看系统状态,设置环境变量和系统参数等。为了方便对硬件和驱动的管理,uboot还引入了类似linux内核的设备树和驱动模型特性。当然,为了增加系统的可配置性、可调试性以及可跟踪性等,它还支持环境变量、log管理、bootstage统计以及简单的ftrace等功能。下面将对这些特性做一简单的介绍。
板子做工精致很有份量,拿在手里沉甸甸的,各种接口一应俱全——USB、TF 卡座、SIM卡座、4G模块卡座、网口、RGB LCD接口、LVDS、RS485、CAN、各种音频口、TV-in/TV-Out,板上还自带一个RTL8723du wifi/蓝牙二合一模块,作为一块主打工业控制的主控板这些接口实属绰绰有余了。手里的板子是256MB内存+256MB nand flash版本(这个是低配版本,还有个512MB+8GB emmc的高配版本),飞凌开发文档中提到已经移植好了Qt5开发环境,所以这个内存跑跑Qt的UI程序是再合适不过了,可惜手里没有匹配的开箱即用的LCD显示屏不然接上直接能试试出厂自带的Qt测试程序了。
uboot需要支持众多的硬件,并且具有良好的可扩展性、可移植性和可维护性,因此必须要有一个设计良好的代码架构。代码架构的设计总是与软硬件架构密不可分的,在硬件层面嵌入式系统的核心一般包括以下层次:
EdgeCore AS6700 ONIE固件,用最新ONIE官方源编译 官方代码有一个bug:
今天和大家分享的依然是设备树,上一节里主要是介绍了设备树文件的基本格式、语法规则等,今天介绍一下如何使用设备树,以及如何动态加载设备树。
通过使用本地文件、Open Source U-Boot/Linux编译,既能适应部分开发人员的工作习惯,也能提高U-Boot/Linux的编译速度。
领取专属 10元无门槛券
手把手带您无忧上云