lcm的分析首先是mtkfb.c 1.mtk_init中platform_driver_register(&mtkfb_driver)注册平台驱动 panelmaster_init(); DBG_init(); mtkfb_ipo_init(); 2.mtkfb_probe进行普配 3.然后执行primary_display_init(mtkfb_find_lcm_driver(),lcd_fps); 4.mtkfb_find_lcm_driver()进行查找驱动: p=strstr(saved

返回目录:<ARM-Linux中断系统>. 总结: 原文地址:<linux kernel的中断子系统之(七):GIC代码分析> 参考代码:http://elixir.free-electrons.com/linux/v3.17-rc3/source 一.前言 GIC(Generic Interrupt Controller)是ARM公司提供的一个通用的中断控制器,其architecture specification目前有四个版本,V1-V4(V2最多支持8个ARM core,V3

Linux Kernel文件系统写I/O流程代码分析(二)bdi_writeback 上一篇# Linux Kernel文件系统写I/O流程代码分析(一),我们看到Buffered IO,写操作写入到page cache后就直接返回了,本文主要分析脏页是如何刷盘的. 概述 由于内核page cache的作用,写操作实际被延迟写入.当page cache里的数据被用户写入但是没有刷新到磁盘时,则该page为脏页(块设备page cache机制因为以前机械磁盘以扇区为单位读写,引入了buffer_h

Linux Kernel文件系统写I/O流程代码分析(一) 在Linux VFS机制简析(二)这篇博客上介绍了struct address_space_operations里底层文件系统需要实现的操作,实际编码过程中发现不是那么清楚的知道这里面的函数具体是干啥,在什么时候调用.尤其是写IO相关的操作,包括write_begin, write_end, writepage, writepages, direct_IO以及set_page_dirty等函数指针. 要搞清楚这些函数指针,就需要纵观整个

Linux 内核为了处理各种不同类型的的输入设备 , 比如说鼠标 , 键盘 , 操纵杆 , 触摸屏 , 设计并实现了一个对上层应用统一的试图的抽象层 , 即是Linux 输入子系统 . 输入子系统的层次结构体如下 从底层到上层 , input 子系统由 设备驱动层 , 核心层 , 以及事件处理层3个部分组成 当一个鼠标移动, 一个按键按下或弹起 , 它都需要从底层设备驱动-->核心层-->事件处理层 -->用户空间 , 层层上报 , 一直到运用程序. 应用这个input  子系统有如下优

转自:http://www.wowotech.net/linux_kenrel/dt-code-analysis.html Device Tree(三):代码分析 作者:linuxer 发布于:2014-6-6 16:03 分类:统一设备模型 一.前言 Device Tree总共有三篇,分别是: 1.为何要引入Device Tree,这个机制是用来解决什么问题的?(请参考引入Device Tree的原因) 2.Device Tree的基础概念(请参考DT基础概念) 3.ARM linux中和De

u-boot_mod 是具有web 浏览器的uboot,也就是传说中的不死uboot,这里的不死指的是不管怎么刷firmware 都可以方便更换firmware,而不是uboot本身就是不死的. 这里将其的代码分析一下. 代码的网址是:https://github.com/pepe2k/u-boot_mod uboot的代码在openwrt上是最底层的,就像PC的BIOS. 整个uboot最开始的入口,是一段汇编语言(MIPS)代码 要证明这段代码是一开始执行的,首先要看链接器脚本(u-boot

一.前言 对于一个嵌入式软件工程师,我们的软件模块经常和硬件打交道,pin control subsystem也不例外,被它驱动的硬件叫做pin controller(一般ARM soc的datasheet会把pin controller的内容放入GPIO controller的章节中),主要功能包括: (1)pin multiplexing.基于ARM core的嵌入式处理器一般会提供丰富的功能,例如camera interface.LCD interface.USB.I2C.SPI等等.虽然

一.前言 Device Tree总共有三篇,分别是: 1.为何要引入Device Tree,这个机制是用来解决什么问题的?(请参考引入Device Tree的原因) 2.Device Tree的基础概念(请参考DT基础概念) 3.ARM linux中和Device Tree相关的代码分析(这是本文的主题) 本文主要内容是:以Device Tree相关的数据流分析为索引,对ARM linux kernel的代码进行解析.主要的数据流包括: 1.初始化流程.也就是扫描dtb并将其转换成Device

MTK6589下传感器框架结构和代码分析以及传感器的参数指标 作者:韩炜彬  中国当代著名嵌入式研究专家 一.      模块框架 1)配置 路径:Alps/mediatek/config/$(project)/ProjectConfig.mk # accelerometer sensor to detect accelerometerfrom x y z axis. l  CUSTOM_KERNEL_ACCELEROMETER=bma050 # ALSPS sensor driverto de

原文网址:http://www.wowotech.net/linux_kenrel/dt-code-analysis.html 一.前言 Device Tree总共有三篇,分别是: 1.为何要引入Device Tree,这个机制是用来解决什么问题的?(请参考引入Device Tree的原因) 2.Device Tree的基础概念(请参考DT基础概念) 3.ARM linux中和Device Tree相关的代码分析(这是本文的主题) 本文主要内容是:以Device Tree相关的数据流分析为索引,

Linux内核启动代码分析二之开发板相关驱动程序加载分析 1 从linux开始启动的函数start_kernel开始分析,该函数位于linux-2.6.22/init/main.c  start_kernel()    --2>setup_arch(&command_line);//该函数位于arch/arm/kernel/setup.c           //在这个函数中定义了一个描述开发板的属性的结构体struct machine_desc *mdesc           struc

专题文档汇总目录 Notes:ARM平台Clock/Timer架构:System counter.Timer以及两者之间关系:Per cpu timer通过CP15访问,System counter通过memory mapped IO访问:将System counter和Per cpu timer分别作为clocksource和clock event device注册到Linux时间子系统. 原文地址:Linux时间子系统之(十七):ARM generic timer驱动代码分析 一.前言 关注

20155326<网络攻防>Exp4 恶意代码分析 基础问题回答: 1)如果在工作中怀疑一台主机上有恶意代码,但只是猜想,所有想监控下系统一天天的到底在干些什么.请设计下你想监控的操作有哪些,用什么方法来监控. 答:首先,可以使用windows自带的schtasks指令设置一个计划任务,每隔一定的时间对主机的联网记录等进行记录.也可以使用sysmon工具,通过修改配置文件,记录相关的日志文件,或是Process Explorer工具,监视进程执行情况. 2)如果已经确定是某个程序或进程有问题,

转自:http://blog.chinaunix.net/uid-30254565-id-5637596.html linux内核中链表代码分析---list.h头文件分析(一) 16年2月27日17:13:14 在学习数据结构时,有一个重要的知识点就是链表.对于链表的一些基本操作,它的最好学习资料就是内核中的list.h头文件,内核中大量的使用链表,都是基于此文件的,下面来仔细分析它: (一) 结构体的定义 首先需要明确的一点是,在数据结构书中,大部分的链表定义是这样的(双向链表): type

start_kernel之前的汇编代码分析 Boot中执行下面两句话之后,进入uclinux内核. theKernel = (void (*)(int, int, unsigned int))((uint32_t)0x08003001); theKernel(0, 2189, ((uint32_t)0x20000100)); 首先来到0x0800 3000处,此时携带有三个参数,R0.R1.R2,分别是0,2189,0x2000 0100. 0x0800 3000对应着下面stext的汇编代码.

一.前言 GIC(Generic Interrupt Controller)是ARM公司提供的一个通用的中断控制器,其architecture specification目前有四个版本,V1-V4(V2最多支持8个ARM core,V3/V4支持更多的ARM core,主要用于ARM64服务器系统结构).目前在ARM官方网站只能下载到Version 2的GIC architecture specification,因此,本文主要描述符合V2规范的GIC硬件及其驱动. 具体GIC硬件的实现形态有两

一.前言 关注ARM平台上timer driver(clocksource chip driver和clockevent chip driver)的驱动工程师应该会注意到timer硬件的演化过程.在单核时代,各个SOC vendor厂商购买ARM core的IP,然后自己设计SOC上的peripherals,这里面就包括了timer的硬件.由于没有统一的标准,各个厂商的设计各不相同,这给驱动工程师带来了工作量.然而,如果仅仅是工作量的话就还好,实际上,不仅仅如此.linux的时间子系统要求硬件t

start_kernel之前的汇编代码分析 Boot中执行下面两句话之后,进入uclinux内核. theKernel = (void (*)(int, int, unsigned int))((uint32_t)0x08003001); theKernel(0, 2189, ((uint32_t)0x20000100)); 首先来到0x0800 3000处,此时携带有三个参数,R0.R1.R2,分别是0,2189,0x2000 0100. 0x0800 3000对应着下面stext的汇编代码.

ARM Linux 大小核切换——cortex-A7 big.LITTLE 大小切换代码分析 8核CPU或者是更多核的处理器,这些CPU有可能不完全对称.有的是4个A15和4个A7,或者是4个A57和4个A53,甚至像海思麒麟935处理器(4核A53 2.2 GHz + 4核A53 1.5 GHz),这8个核的频率可能不一样,则使用过程中需要大小核切换(频率高的是大核,频率低的是小核).本文以ARM cortex-A7为例,分析大小核切换的代码,着重于分析实现切换的代码,对于为什么要这样切换.以