- 博客(93)
- 资源 (1)
- 收藏
- 关注
RSS订阅
原创 线索二叉树和中序非递归遍历线索化后的二叉树
//线索二叉树#include#include#include#define OVERFLOW -2//二叉树的二叉线索存储结构enum PointerTag{Link,Thread}; //枚举类型,Link(0):指针，Thread(1):线索struct BiThrNode{ char data; BiThrNode *lchild,*rchild;//左右孩子指针
2015-10-25 12:19:40
4029
原创 u-boot(六) - 详细启动流程
将__image_copy_end的值赋值给r2，也就是uboot复制结束的地址，从表格中可以知道，此时r2 = 0x87868960，接下来，开始进行uboot代码的拷贝，进入到copy_loop循环，从r1，也就是__image_copy_start开始，读取uboot代码到r10和r11寄存器，一次就拷贝两个32位的数据，r1自动更新，保存下一个需要拷贝的地址，然后将r10和r11里面的数据，写到r0保存的地址，也就是uboot重定位的目的地址，r0自动更新。
2024-06-13 23:38:52
749
原创 u-boot(五) - 启动流程概述
一上电，CPU必定从XIP设备得到第1条指令。XIP设备是指一种可以直接在存储器中执行程序代码的设备，而不需要将代码复制到内存中。XIP的全称是eXecute In Place，即芯片内执行。这类设备包括片内的SRAM、NOR Flash、BootROM等。XIP设备的启动方式是系统上电之后CPU执行的第一条指令是直接在非易失性存储器中执行的，比如被存储在flash中的启动程序，便可以直接在flash中执行，而不需要拷贝到内存中运行。这种启动方式的特点是节省了从存储器到内存的复制过程，从而减少了启动时间和资
2024-06-13 23:19:21
819
原创 u-boot(四)-顶层目录链接脚本文件（u-boot.lds）介绍
对于IMX6ULL，烧写在EMMC、SD/TF卡上的程序，并不能“自己复制自己”，是“别人把它复制到内存里”。一上电首先运行的是boot ROM上的程序，它从EMMC、SD/TF卡上把程序复制进内存里。烧写在EMMC、SD卡或是TF卡上的，除了程序本身，还有位置信息、DCD 信息，这些内容合并成一个映像文件，如下图：这4 部分内容合并成为一个映像文件，烧写在EMMC、SD 卡或TF 卡等启动设备的某个固定地址，boot ROM 程序去这个固定地址读出映像文件。
2024-06-13 23:11:56
1024
原创 u-boot(三) - 编译
u-boot-dtb.imx依赖于u-boot-dtb.bin，u-boot-dtb.bin又依赖于u-boot-nodtb.bin和dts/dt.dtb。u-boot-dtb.imx依赖于u-boot-dtb.bin，u-boot-dtb.bin又依赖于u-boot-nodtb.bin和dts/dt.dtb。然后编译dts/dt.dtb；各类u-boot文件都依赖于u-boot，先编译得到u-boot，它由u-boot-init 、u-boot-main 两部分链接而成。
2024-06-13 22:59:22
824
原创 u-boot(二) - 配置
对于各类内核，只要支持menuconfig配置界面，都是使用Kconfig。在配置界面中，可以选择、设置选项，这些设置会保存在.config文件里。编译脚本会包含.config，根据里面的值决定编译哪些文件、怎么编译文件。.config文件也会被转换为头文件，C程序可以从头文件中获得配置信息。
2024-06-12 23:33:07
1065
原创 u-boot(一) - 开发环境搭建
芯片厂商一般都会提供烧写工具，除了可以烧写整个系统镜像还可以单独更新单个分区的镜像，比如IMX6ULL芯片可以使用MGTool工具单刷u-boot、kernel、rootfs等，将u-boot-dtb.imx传到windows系统，按照操作文档通过USB将u-boot烧写到EMMC。移植uboot时一般不会直接用 uboot 官方的源码的，官方的源码是给半导体厂商准备的，半导体厂商会根据自家的芯片，维护自己芯片对应的uboot。uboot官网上下载的是最原始的uboot源码。
2024-06-12 23:18:24
641
原创 Linux I2C(三) i2c bus/adapter/client_device注册
i2c bus/adapter/client_device注册
2024-04-23 22:15:20
854
原创 Device Tree (四) - device_node -＞ platform_device
device_node -> platform_device
2024-03-18 16:01:22
907
原创 Device Tree (一) - dts基本概念和语法
一，ARM设备树起源在过去的ARM Linux中，arch/arm/plat-xxx和arch/arm/mach-xxx中充斥着大量的垃圾代码，很多代码只是在描述板级细节，而这些板级细节对于内核来讲，不过是垃圾，如板上的platform设备、resource、i2c_board_info、spi_board_info以及各种硬件的platform_data。读者若有兴趣，可以统计一下常见的s3c2410、s3c6410等板级目录，代码量在数万行。设备树是一种描述硬件的数据结构，它起源于OpenFir
2024-03-12 23:09:28
1387
原创 Linux设备模型(十一) - platform设备
在Linux2.6以后的设备驱动模型中，需关心总线、设备和驱动这3个实体，总线将设备和驱动绑定。在系统每注册一个设备的时候，会寻找与之匹配的驱动；相反的，在系统每注册一个设备的时候，会寻找与之匹配的设备，而匹配由总线完成。一个现实的Linux设备和驱动通常都需要挂接在一种总线上，而对于本身依附于PCI、USB、I2C、SPI等的设备而言，这自然不是问题，但是在嵌入式系统里面，在SoC系统中集成的独立外设控制器、挂接在SoC内存空间的外设等却不依附于此类总线。基于这一背景，Linux。
2024-03-03 20:22:41
1151
原创 Linux设备模型(十) - bus/device/device_driver/class
在设备模型中，Bus、Device、Device driver等等，都比较好理解，因为它们对应了实实在在的东西，所有的逻辑都是围绕着这些实体展开的。而本文所要描述的Class就有些不同了，因为它是虚拟出来的，只是为了抽象设备的共性。举个例子，一些年龄相仿、需要获取的知识相似的人，聚在一起学习，就构成了一个班级（Class）。这个班级可以有自己的名称（如295），但如果离开构成它的学生（device），它就没有任何存在意义。另外，班级存在的最大意义是什么呢？是由老师讲授的每一个课程！
2024-03-03 19:26:15
1073
原创 Linux设备模型(九) - bus/device/device_driver/class
在Linux设备模型中，Bus（总线）是一类特殊的设备，它是连接处理器和其它设备之间的通道（channel）。当然实际中，同一总线下的设备有很多，驱动也有很多，在总线上管理着两个链表，分别管理着设备和驱动，当我们向系统注册一个驱动时，便会向驱动的管理链表插入我们的新驱动， 同样当我们向系统注册一个设备时，便会向设备的管理链表插入我们的新设备。在插入的同时总线会执行一个匹配方法对新插入的设备/驱动进行匹配，在匹配成功的时候会调用驱动中的初始化方法，在移除设备或驱动时会调用注销方法。那有没有合适的解决方案呢？
2024-03-03 18:39:25
572
原创 Linux设备模型(八) - sysfs
sysfs是一个基于内存的虚拟的文件系统，有kernel提供，挂载到/sys目录下，负责以设备树的形式向user space提供直观的设备和驱动信息。sysfs以不同的视角展示当前系统接入的设备：/sys/block 历史遗留问题，存放块设备，提供一设备名(如sda)到/sys/devices的符号链接；/sys/bus 按总线类型分类，在某个总线目录之下可以找到链接该总线的设备的符号链接，指向/sys/devices. 某个总线目录之下的drivers目录包含了该总线所需的所有驱动的符号链接。
2024-03-01 17:53:56
1239
原创 Linux设备模型(七) - Netlink
Netlink套接字是用以实现用户进程与内核进程通信的一种特殊的进程间通信(IPC) ,也是网络应用程序与内核通信的最常用的接口。Netlink 是一种特殊的 socket，它是 Linux 所特有的。Netlink 是一种在内核与用户应用间进行双向数据传输的非常好的方式，用户态应用使用标准的 socket API 就可以使用 netlink 提供的强大功能，内核态需要使用专门的内核 API 来使用 netlink。
2024-02-29 20:44:48
1190
原创 Linux设备模型(六) - Android ueventd浅析
在linux2.6之后，udev取代了devfs，但是在android中却没有udev或者mdev[1]，而是由ueventd进程实现了类似功能（管理设备节点权限、创建设备节点）。
2024-02-26 22:05:55
1431
原创 Linux设备模型(五) - uevent kernel实现
由此可知，Uevent的机制是比较简单的，设备模型中任何设备有事件需要上报时，会触发Uevent提供的接口。该机制通常是用来支持热拔插设备的，例如U盘插入后，USB相关的驱动软件会动态创建用于表示该U盘的device结构（相应的也包括其中的kobject），并告知用户空间程序，为该U盘动态的创建/dev/目录下的设备节点，更进一步，可以通知其它的应用程序，将该U盘设备mount到系统中，从而动态的支持该设备。用户空间程序收到这样的事件后，会做相应的处理。环境变量的作用是为执行用户空间程序指定运行环境。
2024-02-26 21:49:14
1112
原创 Linux设备模型(四) - uevent应用：内核发送uevent，用户空间接收uevent
kobject_uevent默认会发送”ACTION=xxx”，”DEVPATH=xxx”，”SUBSYSTEM=xxx”这三个uevent环境变量。内核发送uevent的API由lib/kobject_event.c文件实现，include/linux/kobject.h是头文件。在driver中可以调用kobject_uevent或者kobject_uevent_env来向用户空间发送uevent。kobject_uevent_env可以发送一些如”xxx=xxx”的自定义的uevent环境变量。
2024-02-26 21:37:49
1110
原创 Linux设备模型(三) - kset/kobj/ktype使用示例
【代码】Linux设备模型(三) - kset/kobj/ktype使用示例。
2024-02-26 21:34:50
432
原创 Linux设备模型(二) - kset/kobj/ktype APIs
Kobject的核心功能是：保持一个引用计数，当该计数减为0时，自动释放（由本文所讲的kobject模块负责） Kobject所占用的meomry空间。这就决定了Kobject必须是动态分配的（只有这样才能动态释放）。而Kobject大多数的使用场景，是内嵌在大型的数据结构中（如Kset、device_driver等），因此这些大型的数据结构，也必须是动态分配、动态释放的。那么释放的时机是什么呢？是内嵌的Kobject释放时。
2024-02-23 22:03:18
1031
3
原创 pinctrl子系统 - pinctrl与gpio之间的耦合（六）
任何一个gpio chip，在使用GPIO的时候（通常是gpio subsystem的consumer申请GPIO资源的时候），都需要向系统的pinctrl subsystem申请管脚，并将管脚配置为GPIO功能。思路是简单、直接的，但实际操作起来，却有点棘手，下面以一个最简单的例子说明：假设某一个gpio chip只包括2个gpio，这两个gpio分别和uart进行功能复用。
2023-10-16 10:30:19
159
原创 pinctrl子系统 - 源码解析（五）
设备节点要么被转换为platform_device，或者其他结构体(比如i2c_client)，但是里面都会有一个device结构体，每个device结构体里都有一个dev_pin_info结构体，用来保存设备的pinctrl信息。platform_device匹配driver会执行probe探测函数，执行到驱动中真正的probe函数之前，会进行pinctrl的处理，处理函数为pinctrl_bind_pins。map 到 setting的转化只是将字符串转为整型数表示的形式。
2023-10-16 10:20:32
428
原创 pinctrl子系统 - 架构和结构体关系（四）
每个device结构体里都有一个dev_pin_info结构体，用来保存设备的pinctrl信息，为了方便管理pin control state，我们又提出了一个pin control state holder的概念，用来管理一个设备的所有的pin control状态 -- struct pinctrl ，系统中的每一个需要和pin control subsystem进行交互的设备在进行设定之前都需要首先获取这个句柄。Pin controller节点的格式，没有统一的标准！
2023-10-13 21:44:00
773
原创 GPIO子系统（三）
中间层是 Gpiolib，用于管理系统中的 GPIO。个人理解，因为不知道这个 init 和我们的对接底层的驱动的 init 谁先执行到，所以用了一个变量 gpiolib_initialized 来表示当前的 Gpiolib 是不是已经完成了相关的字符设备的注册，如果是 Gpiolib 先去 init 的话，那么 gpiolib_initialized ture，芯片对接底层的部分错过 gpio_chip setup 的机会，所以需要重新调用这个 gpiochip_setup_dev 接口，反之 OK；
2023-10-13 21:30:28
407
原创 使用gpio子系统实现按键驱动（二）
Linux内核下的drivers/input/keyboard/gpio_keys.c实现了一个体系无关的GPIO按键驱动，使用此按键驱动，只需要在设备树gpio-key节点添加需要的按键子节点即可，适合于实现独立式按键驱动。gpio-keys是基于input架构实现的一个通用gpio按键驱动，该驱动基于platform_driver架构，实现了驱动和设备分离，符合linux设备驱动模型的思想。
2023-10-10 20:18:45
738
原创 gpio内部结构（一）
一般实际运用时，引脚不建议悬空，易受干扰。2） 一般来说，开漏是用来连接不同电平的器件，匹配电平用的，因为开漏引脚不连接外部的上拉电阻时，只能输出低电平，如果需要同时具备输出高电平的功能，则需要接上拉电阻，很好的一个优点是通过改变上拉电源的电压，便可以改变传输电平。* 将上拉和下拉的开关都关断，这种状态我们称为浮空模式，一旦配置成这个模式，引脚的电压是不确定的，如果用万用表测量此模式下管脚电压时会发现只有 1 点几伏，而且还不时改变，所以一般情况下我们都会给引脚设置成上拉或者下拉模式，使它有一个默认状态。
2023-10-10 19:56:29
1379
原创 mmap(三) mmap测试程序，user和设备驱动传递大量数据
构造一个ringbuffer，驱动中将产生的数据放入ringbuffer，用户空间将ringbuffer中的数据读走存在文件中。
2023-06-20 21:04:08
219
原创 mmap(二) 内核空间
分析：因为单位物理页面的大小是4096字节，虽然被映射的文件只有5000字节，但是对应到进程虚拟地址区域的大小需要满足整页大小，因此mmap函数执行后，实际映射到虚拟内存区域8192个 字节，5000~8191的字节部分用零填充。5)为映射分配了新的虚拟地址区域后，通过待映射的文件指针，在文件描述符表中找到对应的文件描述符，通过文件描述符，链接到内核“已打开文件集”中该文件的文件结构体（struct file），每个文件结构体维护着和这个已打开文件相关各项信息。映射完成后，驱动程序往这段内。
2023-06-20 20:47:28
332
1
原创 mmap(一) 用户空间
实现这样的映射关系后，进程就可以采用指针的方式读写操作这一段内存，而系统会自动回写脏页面到对应的文件磁盘上，即完成了对文件的操作而不必再调用read,write等系统调用函数。使用内存映射文件处理存储于磁盘上的文件时，将不必再对文件执行I/O操作，这意味着在对文件进行处理时将不必再为文件申请并分配缓存，所有的文件缓存操作均由系统直接管理，由于取消了将文件数据加载到内存、数据从内存到文件的回写以及释放内存块等步骤，使得内存映射文件在处理大数据量的文件时能起到相当重要的作用。
2023-06-20 20:38:00
246
转载 input subsystem (六) getevent源码分析
getevent命令链接到toolbox，那么入口函数就是toolbox的main函数了，就从toolbox的main函数开始讲起。events_buf是inotify_event的数组指针，读取事件的数量取决于数组的长度，BUF_LEN。创建完上面的watch后，当/dev/input/下的设备节点发生创建和删除操作时，都会将相应。它是一个二元组，包括监听目标和事件。码则表示了需要需要监听的事件类型，掩码中的每一位代表一种事件。过回调的方式通知事件，而需要使用者主动从inotify对象中进行事件读取。
2023-06-09 22:56:17
433
1
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人