a3121772305的博客

这篇博客完整解析了dm-verity在使用过程中bootloader(uboot)向Linux kernel应该传递哪些参数以及这些参数分别是什么意思。

介绍了dm-verity的hashtree的结构图。很形象的表明了hashtree的构成。根据这个结构图，可以自己编码完成hashtree镜像的生成

这个博客主要是生成dm-verity对应的hashtree和root hash。里面是纯C代码，只依赖libcrypto.so这个库。非常易于移植。

注：上面的设备树代码是随便找的。#address-cells：本节点和父节点的值。注：具体有多少行，根据实际情况来决定。#size-cells：本节点的值。

vmalloc() 函数则会在虚拟内存空间给出一块连续的内存区，但这片连续的虚拟内存在物理内存中并不一定连续。由于 vmalloc() 没有保证申请到的是连续的物理内存，因此对申请的内存大小没有限制，如果需要申请较大的内存空间就需要用此函数了。kmalloc() 申请的内存位于物理内存映射区域，而且在物理上也是连续的，它们与真实的物理地址只有一个固定的偏移。kzalloc是kmalloc的变种。GFP_ATOMIC：分配内存的过程是一个原子过程，分配内存的过程不会被（高优先级进程或中断）打断；

定义一个list_head类型的head将我们自定义的结构体里面的所有的list_head串起来。后面我们需要的时候，就遍历head变量的所有list_head节点，找到的每一个节点，都使用container_of来找到该节点结构体的首地址，来判断是不是我们找寻的目标。最近用到了list_head，在这里记录一下。如果要搞清楚list_head的使用方法，需要了解container_of的原理。上面代码实现了list_head的增删改查的操作。里面有个我自己定义的删除函数，请忽略。

container_of宏之前看了一下内核里面的使用方法，然后就直接依葫芦画瓢用了。没有深究其实现原理。最近使用list_head的时候，发现也用到了container_of。所以就详细看看container_of的实现原理。那么问题又来了，我们根据结果或者结构体的定义，可以知道这个8是怎么来的。但是我们只知道t.c的地址，和t的类型，怎么来得到这个8呢？结合上面的代码，问个问题，如果我们知道t.c的地址，怎么计算t的地址。计算方式如下：t=t.c-8。

netlink的单播和广播demo

Linux /proc/version 文件解析

下面的代码是在tiny4412开发板上面验证通过的驱动代码。之前在imx6上面用过类似的代码，USB-HID鼠标、键盘驱动和平台相关性无关，理论上下面的代码在imx6上面也是可以正常使用的。和这个驱动有一个匹配的应用测试程序。该程序里面读取PC通过串口发送过来的坐标信息，然后转换成USB-HID鼠标数据，再上传给PC，以此来控制PC的鼠标。测试流程：1、移植驱动程序到内核里面2、移植应用测试程序到开发板里面3、连接硬件到PC上，这个时候PC应该提示有鼠标插入4、运行应用测试程序，读.

i.MX7这个芯片，目前就没有看见有几个厂家在用这个片子。因此大家对它感兴趣的人基本是少之又少。但是我们公司就用了这个芯片。我们公司用也就用了，但是还把它原有的千兆网络改成了百兆网络。所以又是得自己从头开始搞一遍。在这个平台上面调试ksz8041，比在i.MX6上面调试ksz8041顺利多了。没有多久就搞出来了。环境介绍：板卡：i.MX7Dlinux版本：4.9.88网卡芯片：KSZ8041下面直接上代码：设备树对应的文件　arch/arm/boot/dts/imx7d-sd

i.MX6的开发板，默认使用的是千兆网络。然后看了其他厂家的开发板，发现基本都是使用的千兆网络。公司最近有个项目需要使用百兆网络，找了一圈也没有找到可以参考，没有办法，只有自己弄了。注：i.MX6的千兆网络，因为芯片自带的bug，它的带宽只能支持到400Mbit左右。这个在刚开始测试千兆的时候，可把人坑惨了。环境介绍：板卡：i.MX6Ｄlinux版本：3.14.52网卡芯：KSZ8041百兆网卡的配置主要就是确定好一个50MHz的参考时钟，这个参考时钟是外部输入的，然后配置一下网卡寄

因为项目的需要，我们通过GPIO模拟SPI总线的方式去读写M25P16这款flash芯片。本文档会先介绍M25P16这款flash相关的特性，以及怎么读写操作它。然后会贴出驱动代码，以及对应的测试程序。注:驱动代码和测试程序都是经实际测试过的。先说最后的结果：１、驱动最后实现的效果可以让应用程序类似读写文件一样去读写flash。２、读写速度：1MByte/SM25P16介绍:1、容量－2MByte　共32个扇区，每个扇区256页，每页256Byte 32*256*25..

每一次的订阅，总是给我坚持下去的动力。这章博客应该是这个专栏里面最水的一篇博客了，因此这篇博客的核心内容基本就是NXP论坛官方提供的。因此这篇博客的内容涉及的技术，可以直接去NXP论坛里面找。写这篇博客的主要目的是教大家怎么去用别人已经完成了的技术。主要是一个验证的过程，当然，中间也会涉及一些小的技术。比如：BMP图片的数据提取。首先，我把NXP官网提供的相关代码贴出来。下载链接为：……………………//已经上传CSDN，还在审核过程中。大家也可以直接去NXP论坛找。不同的内核版本对应不同

效果：LVDS+HDMI 都是1080P的分辨率的屏，两者显示的内容完全一样，内容同步更新，无延迟。实现过程中没有使用Wayland、X11、X-window等插件支持。单纯的底层驱动实现。显示，一直都是一个很通用的功能，需要人机交互的产品，基本都有个屏。IMX6D 有3种屏幕显示接口： HDMI、LVDS、LCD。这三种接口基本满足了大部分产品显示接口的需求。在使用IMX6的过程中，只是简单的使用一种接口，或者同时独立的使用多种接口，这些都是比较简单的，在NXP官网提供的BSP里面就已经实

在上一章我们介绍了i.MX6 EPIT定时器驱动。那么这一章我们介绍一下i.MX7D GPT 定时器驱动。i.MX7D有4个GPT定时器，其中GPT1被用于系统定时。因此我们还有3个定时器可以使用。这里我们以GPT4这个定时器为例进行讲解。驱动实现分为如下几步：第一步、阅读i.MX7D的芯片手册GPT定时器对应的章节。我已经阅读过了，就不在这里再读了，没有读过的就需要去阅读一下。第二步、查看相关设备树GPT相关信息： 在 arch/arm/boot/dts/imx7s.dtsi 文..

注：这个驱动参考了https://blog.csdn.net/wince_lover/article/details/54577898#comments这位大神的博客。该大神给出了思路，驱动框架。大家可以直接去看他这个，即可以学习一下，也节约钱。如果你想走捷径，就看我这个吧。本来这个专栏都快没有动力继续往下写了的。之前弄这个专栏的目的也只是为了给自己做个笔记，方便后面查看，结果今天竟然收到了一个订阅，然后瞬间又有动力了。这一章介绍一下i.MX6 EPIT硬件定时器。下一章我们介绍一下i...

关于i.MX6/i.MX7 EIM总线驱动，我们前面已经用了两个章节进行了介绍，第一节用来介绍时序(非常重要)，第二节用来介绍通过非DMA的方式来进行DMA通信。第二节，只是EIM总线通信的一个过渡章节，对于初学者或许有一点帮助，但是在实际的使用过程中，非DMA的方式基本都不会被应用到产品上，因为使用非DMA的方式，会导致CPU的占用率异常的高，同时在传输的稳定性上也不是很可靠。我们之前使用非DMA的方式进行传输，使用示波器去测试DMA总线上面的波形，发现波形的读写时钟波动很大。那么，这一节，我们主

在上一章介绍了i.MX6/i.MX7 EIM总线异步通信的时序。在了解了该总线传输过程时的时序变化后，这一章我们将介绍如果通过编码的方式来实现。同样，我们先介绍我们一下我们的环境：Linux版本：Linux3.14.52 Linux4.9.88 这两个版本都经过实际测试，确定传输是没有问题的。硬件：i.MX6 (i.MX7也验证过，这里以i.MX6为实例进行介绍)在Linux3.xx.xx以后的版本里面，引入了设备树的机制。该机制替代了以前驱动里面device的角色。我们这里的编码...

i.MX6/i.MX7平台，支持EIM(External Interface Module)总线扩展。在实际项目中，大部分使用该总线和FPGA通信比较多，我们这里以与FPGA为例实现该驱动。i.MX6是使用较多的一个，我们一i.MX6为例进行分析。我手上的芯片型号是i.MX6D。我们实现的功能是：使用EIM的16根数据线与FPGA进行数据传输，EIM_OE/EIM_RW用来控制读写，EIM_CS用来选中。最后效果：传输速度可以达到18MByte/S，这个传输速度应该是EIM异步通信比较大的一个传