蜗窝科技

蜗窝的答案——写在站点迁移之际

Fri, 09 Oct 2026 10:00:00 +0800

2014年初，蜗蜗带着一脑袋的问题，建起了蜗窝科技。十二年后，这些问题有的想明白了，有的被时间解开了，有的——被 AI 解开了。

linux thermal framework(5)_thermal core

Mon, 14 Apr 2025 10:47:55 +0800

本文从thermal framework core对内部实现做一个简单的分析

linux thermal framework(4)_thermal governor

Mon, 14 Apr 2025 10:45:14 +0800

thermal governor是通过一定算法控制cooling device状态来控温的在这篇文章中，我们使用一个简单的step_wise governor来说明整个过程。

linux thermal framework(3)_thermal cooling device

Mon, 14 Apr 2025 10:33:00 +0800

linux使用thermal cooling device来描述一个平台上可以降温的设备，本文详细介绍thermal cooling device相关的函数接口和相关调用过程。

linux thermal framework(2)_thermal zone

Mon, 14 Apr 2025 10:15:42 +0800

linux使用thermal zone来描述一个平台各个区域的温度信息，本文详细介绍thermal_zone相关的函数接口和相关调用过程。

linux thermal framework(1)_概述

Mon, 14 Apr 2025 09:56:16 +0800

热能是电子器件在通电工作后散发能量的主要方式之一，电子器件（cpu、电源适配器等）中的电阻、晶体管、集成电路等元件在工作中，电流通过导体，电子与原子碰撞，导致能量以热能形式散发。在手持移动设备（手机、手表等）中，由于接触人体皮肤，保证设备的温度在人体可接受范围内是重要的一个研发方向，硬件上可以通过选择更低功耗的电子器件或者在设备内部添加散热材料，比方说导热凝胶、石墨片、金属散热片等，来降低温度，

mmap在arm64背后的那个深坑

Wed, 28 Feb 2024 20:13:54 +0800

本文记录了linux kernel 5.10内核上的一个bug修复过程，希望可以给大家参考。

Linux读写锁逻辑解析

Mon, 29 May 2023 20:57:49 +0800

除了mutex，在linux内核中，还有一个经常用到的睡眠锁就是rw semaphore（后文简称为rwsem），它到底和mutex有什么不同呢？为何会有rw semaphore？无他，仅仅是为了增加内核的并发，从而增加性能而已。Mutex严格的限制只有一个thread可以进入临界区，但是实际应用中，有些场景对共享资源的访问可以严格区分读和写的，并且是读多写少，这时候，其实多个读的thread同时

futex基础问答

Sun, 09 Oct 2022 07:20:48 +0800

futex是Fast Userspace muTEX的缩写，该机制是由Rusty Russell、Hubertus Franke和Mathew Kirkwood在2.5.7版本的内核中引入，虽然名字中有互斥锁（mutex）的含义，但实际它是一种用于用户空间应用程序的通用同步工具（基于futex可以在userspace实现互斥锁、读写锁、condition variable等同步机制）。

如何使能500个virtio_blk设备

Fri, 12 Aug 2022 16:12:13 +0800

一例virtio_blk设备中断占用分析背景：这个是在客户的centos8.4的环境上复现的，dpu是目前很多云服务器上的网卡标配了，在云豹的dpu产品测试中，dpu实现的virtio_blk设备在申请中断时报错，在排查这个错误的过程中，觉得某些部分还比较有趣，故记录之。本身涉及的背景知识有：irq,msi,irq_domain,affinity，virtio_blk，irqbalance。下面

Linux内核同步机制之（九）：Queued spinlock

Wed, 29 Jun 2022 06:33:40 +0800

本站之前已经有了一篇关于 spinlock 的文档，在之前的文章中有对自旋锁进行简单的介绍，同时给出了API汇整和应用场景。不过该文章中的自旋锁描述是基于比较老的内核版本，那时候的自旋锁还是ticket base锁，而目前最新内核中的自旋锁已经进化成queued spinlock，因此需要一篇新的自旋锁文档来跟上时代。此外，本文将不再描述基本的API和应用场景，主要的篇幅将集中在具体的自旋锁实现上

Linux内核同步机制之（八）：mutex

Tue, 10 May 2022 05:55:31 +0800

在linux内核中，互斥量（mutex，即mutual exclusion）是一种保证串行化的睡眠锁机制。和spinlock的语义类似，都是允许一个执行线索进入临界区，不同的是当无法获得锁的时候，spinlock原地自旋，而mutex则是选择挂起当前线程，进入阻塞状态。本文代码来自Linux 5.10.61，文章中的代码片段有删减，阅读本文时可以参考源代码。

schedutil governor情景分析

Tue, 26 Apr 2022 06:29:07 +0800

这是一篇分析schedutil governor（后文称之sugov）代码逻辑的文章。通过详细的代码级别的分析，希望能够帮助读者理解sugov的代码精妙之处。本文主要分四个章节：第一章简单重复了sugov相关的软件结构和基本算法，让读者对整个sugov在系统所处的位置和基本的逻辑控制有所了解。第二章对sugov使用的数据结构给出了详细的解释。第三章对sugov和cpufreq core的基本数据流

PELT算法浅析

Thu, 07 Apr 2022 07:09:28 +0800

Linux是一个通用操作系统的内核，她的目标是星辰大海，上到网络服务器，下至嵌入式设备都能运行良好。做一款好的linux进程调度器是一项非常具有挑战性的任务，因为设计约束太多了： —它必须是公平的 —快速响应 —系统的throughput要高 —功耗要小 3.8版本之前的内核CFS调度器在计算CPU load的时候采用的是跟踪每个运行队列上的负载（per-rq load track

load_balance函数代码详解

Wed, 16 Feb 2022 07:29:28 +0800

我们描述CFS任务负载均衡的系列文章一共三篇，第一篇是框架部分，第二篇描述了task placement和active upmigration两个典型的负载均衡场景，第三篇是负载均衡的情景分析，包括tick balance、nohz idle balance和new idle balance。在负载均衡情景分析文档最后，我们给出了结论：tick balancing、nohz idle balanc

CPU 多核指令 —— WFE 原理

Fri, 11 Feb 2022 01:34:57 +0800

今天我想分享一个跟多核锁原理相关的东西，由于我搞 arm 居多，所以目前只研究了 arm 架构下的 WFE 指令，分享出来，如果有表述不精准或者错误的地方还请大家指出，非常感谢。研究这个原因也是只是想搞清楚所以然和来龙去脉，以后写代码可以更游刃有余。

CFS任务放置代码详解

Fri, 31 Dec 2021 07:00:42 +0800

我们描述CFS任务负载均衡的系列文章一共三篇，第一篇是框架部分，第二篇描述了task placement的逻辑过程，第三篇是负载均衡的情景分析，包括tick balance、nohz idle balance和new idle balance。之前已经有一篇关于task placement的文档发表在本站，为了更精细的讲解代码逻辑，我们这次增加了代码分析部分。本文作为第二篇任务放置的附篇，深入讲解

CFS任务的负载均衡（load balance）

Mon, 22 Nov 2021 20:49:39 +0800

我们描述CFS任务负载均衡的系列文章一共三篇，第一篇是框架部分，第二篇描述了task placement和active upmigration两个典型的负载均衡场景。本文是第三篇，主要是分析各种负载均衡的触发和具体的均衡逻辑过程。本文出现的内核代码来自Linux5.10.61，为了减少篇幅，我们尽量删除不相关代码，如果有兴趣，读者可以配合代码阅读本文。

Atomic operation in aarch64

Mon, 15 Nov 2021 19:42:04 +0800

在Linux内核中看到下面这句话: At least on ARM, pgprot_noncached causes the memory to be mapped strongly ordered, and atomic operations on strongly ordered memory are implementation defined, and won’t work on many

irq wakeup in linux

Mon, 15 Nov 2021 18:41:58 +0800

在本篇文章中基于AARCH64平台，GIC作为中断控制器来进行讨论下面是GIC-600的系统框架图：

CFS任务的负载均衡（任务放置）

Fri, 12 Nov 2021 06:55:01 +0800

负载均衡的系列文章共分为三篇，第一篇为框架篇，描述负载均衡的相关原理、场景和框架。本篇作为该系列文章第二篇，主要通过对任务放置场景（task placement）的均衡分布进行分析，加深对内核调度器实现任务均衡分布的理解。本文基于linux-5.4.24分析，由于涉及较多代码的讲解，建议结合源码阅读。另外，浏览本文前，建议先阅读负载均衡系列文章第一篇：CFS任务的负载均衡（概述）。当然，部分已经

CFS任务的负载均衡（概述）

Fri, 05 Nov 2021 06:39:22 +0800

我们描述负载均衡的系列文章一共三篇，第一篇是框架部分，即本文，主要描述了负载均衡相关的原理、场景和框架。后面的两篇是对均衡代码的情景分析，通过对tick balance、new idle balance和task placement等几个典型的负载均衡来呈现其实现细节，稍后发布，敬请期待。本文出现的内核代码来自Linux5.10.61，如果有兴趣，读者可以配合代码阅读本文。

mellanox的网卡故障分析

Tue, 06 Jul 2021 10:38:50 +0800

知识分享，与有趣的灵魂同行。这是一篇关于mellanox网卡的uaf问题问题，其中涉及到dma_pool，uaf等常见知识点。

一个较复杂dcache问题

Fri, 11 Jun 2021 09:44:20 +0800

本文主要讲述的是一个dcache的问题，主要知识点涉及dentry，inode，proc fs，mount，docker，cni插件，hash桶，冲突链等，最终针对云上内核的监控产生了一些细化的需求。

关于java单线程经常占用cpu100%分析

Sat, 08 May 2021 09:08:44 +0800

openjdk的bug分析，oracle的jdk也存在类似问题，目前该bug已经推动合入到社区， https://github.com/openjdk/jdk/pull/4378

关于numa loadbance的死锁分析

Sat, 08 May 2021 09:03:00 +0800

一例关于numa loadbance的死锁分析

一例ext4使用的jbd2模块死锁分析

Sat, 08 May 2021 08:36:56 +0800

本文分析一例ext4使用的jbd2的死锁。

一例hardened_usercopy的bug解析

Mon, 30 Mar 2020 20:54:54 +0800

本文介绍了一例hardened_usercopy的bugon解析。

一例centos7.6内核hardlock的解析

Mon, 30 Mar 2020 20:03:16 +0800

本文以一个在centos7.6内核发生的crash,描述一下常见hardlock导致panic的解bug流程。

联系我们

Wed, 18 Mar 2020 17:51:51 +0800

E-mail: wowotech#yeah.net 发送邮件时请将#替换为@ ｜ QQ交流群: 457024058

zRAM内存压缩技术原理与应用

Sun, 08 Mar 2020 08:38:19 +0800

说到压缩这个词，我们并不陌生，应该都能想到是降低占用空间，使同样的空间可以存放更多的东西，类似于我们平时常用的文件压缩,内存压缩同样也是为了节省内存。尽管当前android手机6GB，8GB甚至12GB的机器都较为常见了，但内存无论多大，总是会有不够用的时候。当系统内存紧张的时候，会将文件页丢弃或回写回磁盘（如果是脏页），还可能会触发LMK杀进程进行内存回收。这些被回收的内存如果再次使用都需要重

Binder从入门到放弃（下）

Tue, 18 Feb 2020 21:19:51 +0800

Binder从入门到放弃包括了上下篇，上篇是框架部分，下篇通过几个典型的binder通信过程来呈现其实现细节，即本文。

Binder从入门到放弃（上）

Tue, 18 Feb 2020 21:13:00 +0800

Binder从入门到放弃包括了上下篇，上篇是框架部分，即本文。下篇通过几个典型的binder通信过程来呈现其实现细节，稍后发布，敬请期待。

F2FS技术拆解

Fri, 31 Jan 2020 20:26:37 +0800

F2FS (Flash Friendly File System) 是专门针对SSD、eMMC、UFS等闪存设备设计的文件系统。由三星工程师Jaegeuk Kim于2012年10月发布到Linux社区，并于2012年12月进入Linux 3.8 内核主线。和UBIFS、JFFS2等文件系统不同，F2FS并不直接面向裸NAND闪存设计，而是和其他通用文件系统一样基于块设备层接口实现。既然如此，为什么

以太网驱动的流程浅析(五)-mii_bus初始化以及phy id的获取

Tue, 07 Jan 2020 14:42:59 +0800

我们继续沿着上一篇的《以太网驱动的流程浅析(四)-以太网驱动probe流程》思路来继续分析

以太网驱动的流程浅析(四)-以太网驱动probe流程

Tue, 07 Jan 2020 14:25:21 +0800

我们继续沿着上一篇的以太网思路来继续分析，目的是为了学习以太网这块从应用层到底层的整块加载和匹配流程。

以太网驱动的流程浅析(二)-Ifconfig的详细代码流程

Fri, 27 Dec 2019 16:53:45 +0800

此文衔接上一节以太网驱动的流程浅析(一)-Ifconfig主要流程

以太网驱动的流程浅析(三)-ifconfig的-19错误最底层分析

Fri, 27 Dec 2019 15:22:31 +0800

此文衔接上一节以太网驱动的流程浅析(二)-Ifconfig的详细代码流程

以太网驱动的流程浅析(一)-Ifconfig主要流程

Fri, 06 Dec 2019 15:50:30 +0800

以太网的知识非常多，我这里是工作中遇到了一个很奇怪的以太网问题，因此便通读了一遍以太网的加载流程，分享出来供大家阅读。如有不准确的地方还请指出，非常感谢

RCU（2）- 使用方法

Fri, 24 May 2019 19:36:15 +0800

本文介绍RCU的使用方法。

RCU（1）- 概述

Fri, 24 May 2019 19:30:14 +0800

本文介绍RCU。

Linux内核的自旋锁

Fri, 17 May 2019 19:11:14 +0800

自旋锁用于处理器之间的互斥，适合保护很短的临界区，并且不允许在临界区睡眠。申请自旋锁的时候，如果自旋锁被其他处理器占有，本处理器自旋等待（也称为忙等待）。进程、软中断和硬中断都可以使用自旋锁。自旋锁的实现经历了 3 个阶段： (1) 最早的自旋锁是无序竞争的，不保证先申请的进程先获得锁。 (2) 第 2 个阶段是入场券自旋锁，进程按照申请锁的顺序排队，先申请的进程先获得锁。 (3) 第 3 个

浅谈Cache Memory

Thu, 02 May 2019 21:14:57 +0800

今天探究的主题是cache。我们围绕几个问题展开。为什么需要cache？如何判断一个数据在cache中是否命中？cache的种类有哪些，区别是什么？

支持者列表

Sun, 14 Apr 2019 11:33:29 +0800

| | | | — | — | | 感谢如下朋友的支持和鼓励： | | | | | | | | 称呼 | 日期 | 数量 | 备注 | | \飞 | 2016/5/1 | 2 | 32位ARM开发板 | | \飞 | 2016/5/1 | 1 | 通信协议测试仪 | | \龙 | 2016/5/17 | - | - | | \韬 | 2016/5/18 | - | - | | 炬芯 | 2

内存一致性模型

Sun, 24 Mar 2019 14:22:03 +0800

早期的 CPU 是通过提高主频来提升 CPU 的性能，但是随着频率“红利”越来越困难的情况下，厂商开始用多核来提高 CPU 的计算能力。多核是指一个 CPU 里有多个核心，在同一时间一个 CPU 能够同时运行多个线程，通过这样提高 CPU 的并发能力。内存一致性模型（ memory consistency model ）就是用来描述多线程对共享存储器的访问行为，在不同的内存一致性模型里，多线程对

imx6q应用层select 返回0

Wed, 13 Mar 2019 16:59:28 +0800

本文是原「蜗窝讨论区」的历史存档（2019-03-13），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

qdzhaozx · 2019-03-13 16:59

最近在测试网络tcp通讯，设备环境：客户端：arm imx6q linux 服务器端：intel windows

服务器监听端口：31122

客户端主动连接服务器，连接成功后，服务器主动发送固定长度（1743字节）的包给客户端，间隔时间为6ms

测试结果：

大部分时间，客户端接收正常。间隔10ms左右收到数据包。但是，偶尔会出现，应用层select连续多次返回0，timeout，frozen time可能是1秒，2秒甚至是6秒多。

初步排查：

利用 tcpdump工具，抓取网络包，发现在应用层select连续多次超时时，tcpdump抓取到的包显示，服务器给客户端发送正常，但是，客户端一直不回复ack。很奇怪。

copy_{to,from}_user()的思考

Sun, 27 Jan 2019 19:03:28 +0800

我们对copy_{to,from}user()接口的使用应该是再熟悉不过吧。基本Linux书籍都会介绍它的作用。毕竟它是kernel space和user space沟通的桥梁。所有的数据交互都应该使用类似这种接口。所以，今天我们一起探究下 copy{to,from}user() 接口的作用。通过本文可以解答以下问题。为什么需要copy{to,from}_user()，它究竟在背后为我们

编译乱序(Compiler Reordering)

Wed, 23 Jan 2019 22:59:19 +0800

编译乱序(Compiler Reordering) 编译器（compiler）的工作就是优化我们的代码以提高性能。这包括在不改变程序行为的情况下重新排列指令。因为compiler不知道什么样的代码需要线程安全（thread-safe），所以compiler假设我们的代码都是单线程执行（single-threaded），并且进行指令重排优化并保证是单线程安全的。因此，当你不需要compiler重新排

CFS调度器（6）-总结

Tue, 01 Jan 2019 12:37:30 +0800

CFS调度器-总结经过前面一系列的文章描述，我们已经对CFS调度器有了一定的认识。那么本篇文章就作为一篇总结和思考。我们就回忆一下CFS调度器的那些事。我们就以问题的形式重新回顾一遍CFS调度器设计的原理。现在开始，我们问题来了。

CFS调度器（5）-带宽控制

Sat, 22 Dec 2018 15:07:23 +0800

前言什么是带宽控制？简而言之就是控制一个用户组在给定周期时间内可以消耗CPU的时间，如果在给定的周期内消耗CPU时间超额，就限制该用户组内任务调度，直到下一个周期。限制某个进程的最大CPU使用率是否真的有必要呢？如果一个系统中仅存在一个进程，限制该进程使用CPU使用率最大50%，当进程使用率达到50%的时候，就限制该进程运行，CPU进入idle状态。看起来好像没有任何意义。但是，有时候，这正是系

CFS调度器（4）-PELT(per entity load tracking)

Sun, 02 Dec 2018 15:40:17 +0800

为什么需要PELT？为了让调度器更加的聪明，我们总是希望系统满足最大吞吐量同时又最大限度的降低功耗。虽然可能有些矛盾，但是现实总是这样。PELT算法是Linux 3.8合入的，那么在此之前，我们存在什么问题才引入PELT算法呢？在Linux 3.8之前，CFS以每个运行队列（runqueue，简称rq）为基础跟踪负载。但是这种方法，我们无法确定当前负载的来源。同时，即使工作负载相对稳定的情况下，

CFS调度器（3）-组调度

Sat, 10 Nov 2018 20:43:19 +0800

前言现在的计算机基本都支持多用户登陆。如果一台计算机被两个用户A和B使用。假设用户A运行9个进程，用户B只运行1个进程。按照之前文章对CFS调度器的讲解，我们认为用户A获得90% CPU时间，用户B只获得10% CPU时间。随着用户A不停的增加运行进程，用户B可使用的CPU时间越来越少。这显然是不公平的。因此，我们引入组调度（Group Scheduling ）的概念。我们以用户组作为调度的单位

关于zynq-7000DMA的疑问

Mon, 22 Oct 2018 10:49:39 +0800

本文是原「蜗窝讨论区」的历史存档（2018-10-22），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

thatwas · 2018-10-22 10:49

最近在做关于zynq的DMA驱动相关的东西，在查看赛灵思官方网站的时候，发现

大致意思就是3.6内核之后DMA330的驱动就被遗弃了，后面使用标准的linuxDMA驱动，这是什么意思？设备树中还有pl330的信息，内核中关于pl330的驱动也编译了。zynq-7000的DMA控制器一直都是pl330.遗弃这一说法是从何而来呢？

CFS调度器（2）-源码解析

Sun, 21 Oct 2018 20:55:07 +0800

前言经通过上一篇文章《CFS调度器-基本原理》，我们可以了解到CFS调度器基本工作原理。本篇文章主要集中在Linux CFS调度器源码解析。注：文章代码分析基于Linux-4.18.0。

IRQF_NO_SUSPEND和enable_irq_wake的疑问

Mon, 15 Oct 2018 09:21:02 +0800

本文是原「蜗窝讨论区」的历史存档（2018-10-15），来自版块「Linux kernel技术问答」，共 2 帖。讨论区已停止服务，此处仅供查阅。

leo.liu · 2018-10-15 09:21

wowo你好，之前在读《系统休眠（System Suspend）和设备中断处理》这一篇文章的时候，有一点非常的疑惑，希望你能指点迷津。文章中说IRQF_NO_SUSPEND标志并不能唤醒系统，只是保证suspend的过程中该中断enable，并且可以执行handler。而如果要唤醒系统则必须使用API：enable_irq_wake将这个中断标记为唤醒源，而且enable_irq_wake和IRQF_NO_SUSPEND不能同时使用。

我的疑惑是： 1.对于IRQF_NO_SUSPEND，可以执行interrupt handler，但是系统都无法唤醒，那么内核的调度应该也没有起来，此时进程都冻结了，谁来执行这个handler呢？ 2.假如这个handler被执行了，但是系统没起来，也做不了什么事情啊对这一块很模糊，想不清感觉睡觉都还惦记这个事情，还请wowo和linuxer指点下

wowo · 2018-10-16 16:26

leo.liu 写道： wowo你好，之前在读《系统休眠（System Suspend）和设备中断处理》这一篇文章的时候，有一点非常的疑惑，希望你能指点迷津。文章中说IRQF_NO_SUSPEND标志并不能唤醒系统，只是保证suspend的过程中该中断enable，并且可以执行handler。而如果要唤醒系统则必须使用API：enable_irq_wake将这个中断标记为唤醒源，而且enable_irq_wake和IRQF_NO_SUSPEND不能同时使用。

这个东西的重点在于：“suspend的过程中该中断enable，并且可以执行handler”。也就是说，在suspend过程中，如果有紧急情况，是可以反悔的。当然了，如果真的suspend了，这个标志就无能为力了。

CFS调度器（1）-基本原理

Sun, 07 Oct 2018 17:36:47 +0800

前言首先需要思考的问题是：什么是调度器（scheduler）？调度器的作用是什么？调度器是一个操作系统的核心部分。可以比作是CPU时间的管理员。调度器主要负责选择某些就绪的进程来执行。不同的调度器根据不同的方法挑选出最适合运行的进程。目前Linux支持的调度器就有RT scheduler、Deadline scheduler、CFS scheduler及Idle scheduler等。我想用一系

per-entity load tracking

Sat, 18 Aug 2018 10:27:17 +0800

本文分三个部分描述了3.8内核引入的PELT（per-entity load tracking）机制。第一章主要描述了PELT比per-runqueue load tracking的好处在哪里，这也是引入PELT的原因。第二章描述了具体PELT的算法，有兴趣的同学可以自行根据代码进行分析。第三章主要给出几个PELT的应用场景，在这些场景中，其他的内核子系统可以通过PELT进行更精准的控制。本文是

common clk framework的问题

Tue, 31 Jul 2018 22:01:28 +0800

本文是原「蜗窝讨论区」的历史存档（2018-07-31），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

巴扎黑 · 2018-07-31 22:01

最新学习linux内核的clk部分，有个疑惑想请大家指点一下

在新的clk框架中，例如 clk_hw_register_mux 注册的clk应该是保存在 clk_orphan_list clk_root_list 中，里面使用的都是clk_core结构进行相互关联，使用clk_get(dev,name)可以获取到这些时钟

我想问，使用clk_get(null,name)能获取到上述时钟吗？clk_get(null,name) 应该是在 clocks 链表中查找，我在追代码的过程中并没有找到clk_hw_register_mux 的过程中有向该链表中添加节点，是我遗漏了吗？

此外，看蜗窝文章的时候有同学说 clk_set_rate 时父时钟的问题，4.16版本的内核已经可以自动选择最优父时钟，前提是这个时钟有一个特殊的flag允许这么做

如何知道android系统中GPS在 /dev/tty*下具体生成的节点名称？

Tue, 17 Jul 2018 02:09:27 +0800

本文是原「蜗窝讨论区」的历史存档（2018-07-17），来自版块「Linux kernel技术问答」，共 3 帖。讨论区已停止服务，此处仅供查阅。

ihexon · 2018-07-17 02:09

题目可能描述的不是很清晰，我通过Google大概了解了GPS通过UART接口并且在/dev/tty*下生成设备节点，我知道bluetooth的节点是/dev/ttyHS0(歪打正着), 但其他的tty[1-24]完全不知道是什么设备.....

[== Undefined ==] %ls /dev/tty* /dev/tty /dev/tty12 /dev/tty17 /dev/tty21 /dev/tty26 /dev/tty30 /dev/tty35 /dev/tty4 /dev/tty44 /dev/tty49 /dev/tty53 /dev/tty58 /dev/tty62 /dev/ttyHS0 /dev/tty0 /dev/tty13 /dev/tty18 /dev/tty22 /dev/tty27 /dev/tty31 /dev/tty36 /dev/tty40 /dev/tty45 /dev/tty5 /dev/tty54 /dev/tty59 /dev/tty63 /dev/ttyprintk /dev/tty1 /dev/tty14 /dev/tty19 /dev/tty23 /dev/tty28 /dev/tty32 /dev/tty37 /dev/tty41 /dev/tty46 /dev/tty50 /dev/tty55 /dev/tty6 /dev/tty7 /dev/tty10 /dev/tty15 /dev/tty2 /dev/tty24 /dev/tty29 /dev/tty33 /dev/tty38 /dev/tty42 /dev/tty47 /dev/tty51 /dev/tty56 /dev/tty60 /dev/tty8 /dev/tty11 /dev/tty16 /dev/tty20 /dev/tty25 /dev/tty3 /dev/tty34 /dev/tty39 /dev/tty43 /dev/tty48 /dev/tty52 /dev/tty57 /dev/tty61 /dev/tty9

这些tty设备的名字是在内核源码你固定并映射至X传感器，还是动态分配的， tty存在空闲的节点吗(如没有映射任何硬件设备的ttyXXX)，还是按照需要自动创建....

我对内核源码的结构也不是清晰，大概知道在driver/tty/serial/* 下，

[== Undefined ==] % ls shared/superuber-kernel-angler/drivers/tty/serial 21285.c arc_uart.c crisv10.h ioc4_serial.c m32r_sio.h mpsc.c msm_smd_tty.c pmac_zilog.h serial_core.c suncore.c ucc_uart.c 68328serial.c atmel_serial.c dz.c ip22zilog.c m32r_sio_reg.h mrst_max3110.c msm_smd_tty.o pnx8xxx_uart.c serial_core.o sunhv.c vr41xx_siu.c 8250 bcm63xx_uart.c dz.h ip22zilog.h Makefile mrst_max3110.h mux.c pxa.c serial_ks8695.c sunsab.c vt8500_serial.c altera_jtaguart.c bfin_sport_uart.c efm32-uart.c jsm max3100.c msm_serial.c mxs-auart.c rp2.c serial-tegra.c sunsab.h xilinx_uartps.c altera_uart.c bfin_sport_uart.h icom.c Kconfig max310x.c msm_serial.h netx-serial.c sa1100.c serial_txx9.c sunsu.c zs.c amba-pl010.c bfin_uart.c icom.h kgdb_nmi.c mcf.c msm_serial_hs.c nwpserial.c samsung.c sh-sci.c sunzilog.c zs.h amba-pl011.c built-in.o ifx6x60.c kgdboc.c mfd.c msm_serial_hs_hwreg.h of_serial.c samsung.h sh-sci.h sunzilog.h apbuart.c clps711x.c ifx6x60.h lantiq.c modules.builtin msm_serial_hs_lite.c omap-serial.c sb1250-duart.c sirfsoc_uart.c timbuart.c apbuart.h cpm_uart imx.c lpc32xx_hs.c modules.order msm_serial_hs_lite.o pch_uart.c sc26xx.c sirfsoc_uart.h timbuart.h ar933x_uart.c crisv10.c ioc3_serial.c m32r_sio.c mpc52xx_uart.c msm_serial_hs.o pmac_zilog.c sccnxp.c sn_console.c uartlite.c

如果需要阅读源码，那么具体在那些地方有tty*节点的定义（如Bluetooth的节点为ttyHS0）....

Linux中常见同步机制设计原理

Sat, 09 Jun 2018 16:19:03 +0800

引言今天谈谈linux中常见并发访问的保护机制设计原理。为什么要写这篇文章呢？其实想帮助自己及读者更深入的了解背后的原理（据可靠消息，锁的实现经常出现在笔试环节。既可以考察面试者对锁的原理的理解，又可以考察面试者编程技能）。我们抛开linux中汇编代码。用C语言为大家呈现背后实现的原理。同时，文章中的代码都没有考虑并发情况（例如某些操作需要原子性，或者数据需要保护等）。

招蓝牙BLE协议栈开发兼职老师

Mon, 28 May 2018 14:32:52 +0800

本文是原「蜗窝讨论区」的历史存档（2018-05-28），来自版块「其它」，共 1 帖。讨论区已停止服务，此处仅供查阅。

清风拂面1230 · 2018-05-28 14:32

企业培训公司面向单位员工培训，长期招蓝牙BLE协议栈开发兼职老师，一般三天左右的短周期培训，周末为主，有2人左右的小

辅导，也有30人左右的培训大班，待遇优，北京、上海、成都、广州、深圳等；如您想挣点外快，积累资源，充实生活，请联系

我。

要求：相关技术专业，本科及以上学历；三年以上实际项目经验；认真、热情、耐心、乐于助人、不保守、表达能力较好。详细面议。

感兴趣的可以联系：QQ1489302364、微信15501239699、简历接收邮箱：admin@info-soft.cn

KASLR

Sun, 06 May 2018 10:00:16 +0800

引言什么是KASLR？KASLR是kernel address space layout randomization的缩写，直译过来就是内核地址空间布局随机化。KASLR技术允许kernel image加载到VMALLOC区域的任何位置。当KASLR关闭的时候，kernel image都会映射到一个固定的链接地址。对于黑客来说是透明的，因此安全性得不到保证。KASLR技术可以让kernel im

fixmap addresses原理

Sun, 29 Apr 2018 20:35:14 +0800

引言 fixmap是一段固定地址映射。kernel预留一段虚拟地址空间。因此虚拟地址是在编译的时候确定。fixmap可以用来做什么？kernel启动初期，由于此时的kernel已经运行在虚拟地址上。因此我们访问具体的物理地址是不行的，必须建立虚拟地址和物理地址的映射，然后通过虚拟地址访问才可以。例如：dtb中包含bootloader传递过来的内存信息，我们需要解析dtb，但是我们得到的是dtb的物

有没有一起读Linux源码的，一块交流一下啊！

Sat, 28 Apr 2018 23:01:06 +0800

本文是原「蜗窝讨论区」的历史存档（2018-04-28），来自版块「灌水区」，共 3 帖。讨论区已停止服务，此处仅供查阅。

LY_Linux · 2018-04-28 23:01

有没有一起读Linux源码的，一块交流一下啊！ QQ:937285794

coderall · 2018-08-14 20:53

有啊，正在读

jinfa · 2018-10-07 15:51

要不建个qq群？

文件系统和裸块设备的page cache问题

Sat, 28 Apr 2018 10:16:27 +0800

普通文件的数据可以保存在它的地址空间中，同时直接访问块设备中此文件的块，也会将这个文件的数据保存在块设备的地址空间中。这两份缓存相互独立，kernel并不会为这种非正常访问同步两份缓存，从而避免了同步的开销。注：本文代码基于linux-3.18.31，此版本中块缓存已经合入页缓存。

一次触摸屏中断调试引发的深入探究

Mon, 23 Apr 2018 16:01:25 +0800

大家好，我叫张昺华，中间那个字念“饼”，首先非常感谢陈莉君老师的指点，题目名字也是陈老师起的，也很荣幸此文章能在蜗窝上发表一次，感谢郭大侠给的机会如下为本人原创，在解决问题的过程中的一点心得，如果有描述不准确的地方还请各位指出，非常感谢 Linux 内核版本： linux-4.9.18 曾有一次调试触摸屏的时候遇到如下的问题

ARM64 Kernel Image Mapping的变化

Sat, 21 Apr 2018 20:25:19 +0800

随着linux的代码更新，阅读linux-4.15代码，从中发现很多与众不同的地方。之所以与众不同，就是因为和我之前从网上博客或者书籍中看到的内容有所差异。当然了，并不是为了表明书上或者博客的观点是错误的。而是因为linux代码更新的太快，网上的博客和书籍跟不上linux的步伐而已。究竟是哪些发生了差异了？例如：kernel image映射区域从原来的linear mapping region（线

tty驱动分析

Fri, 20 Apr 2018 18:02:07 +0800

分析背景： xilinx_uartps.c (drivers\tty\serial)—-linux-4.9 内核以具体驱动为例，描述了驱动的注册、打开和读写过程；梳理了相关数据结构间的关系。最后给出了一个模拟tty驱动实例。

【找人】【zdc2124288】【华为招聘嵌入式内核开发工程师】

Fri, 20 Apr 2018 11:50:18 +0800

本文是原「蜗窝讨论区」的历史存档（2018-04-20），来自版块「内推区」，共 1 帖。讨论区已停止服务，此处仅供查阅。

zdc2124288 · 2018-04-20 11:50

2017年上半年某业界大佬在服务器市场领域的份额依然高达90%以上，但是这个市场也被其他厂商盯上了，ARM日前宣布了雄心勃勃的新计划，将联手高通、海思、飞腾等8家半导体公司推ARM服务器，目标是在2021年拿下25%的市场份额，ARM崛起，势不可挡!!!

我们不提岗位，我们只说技能，只要有精于以下一项技能即可（注意任意一项技能即可）：

1、从事AI、云化、大数据、高密计算等业务提供系统及解决方案相关工作，熟练掌握相关业务部署，测试相关，性能优化相关知识者。

2、从事业务建模、业务特征提取和处理器业务处理瓶颈和优化方法研究者；

3、精通处理器体系结构、数据结构，从事过某种协议栈开发者

4、精通C/C++.python等语言者

5、具有嵌入式软件开发经验者

6、有1年及以上测试经验，有芯片验证经验者。

7、对linux架构，驱动开发，内核优化调试技能精通者。

8、对X86/ARM架构熟悉，有开发经验者。

9、对PCI，网络，SAS/SATA，ROCEE等高速接口协议精通者。

10、为人诚实，做事踏实，具备良好的团队合作精神、良好的沟通能力和严谨的工作态度，有较强的学习能力者

PS（偷偷给大家算笔账：去年业界大佬数据中心业务营收达172亿美元，运营利润则高达75亿美元，我们只要抢占5%的份额，利润即将高达3.75亿美元，所以我们也是个有钱的团队）

本五硕三，待遇从优（社招要求985/211大学）, C9院校学生不要求工作经验

简历请发送至 zhudacai@huawei.com

ftrace时间精度issue修复

Mon, 16 Apr 2018 19:07:32 +0800

在调试ATMEL SAMA5D3 上的ftrace功能的时候，发现了一个时间精度的问题，本文主要记录这个issue修复的过程，方便后续查阅。linux内核版本是4.4.19，当然，最新的内核中仍然存在这个issue。

致驱动工程师的一封信

Sat, 14 Apr 2018 21:00:45 +0800

作为一个算是合格的驱动工程师，总是有很多话想说。代码看的多了总是有些小感悟。可能是吧。那就总结一下自己看的代码的一些感悟和技巧。如何利用你看的这些代码？如何体现在工作的调试中。作为驱动工程师，主要的工作就是移植各种驱动，接触各种硬件。接触最多的就是dts、中断、gpio、sysfs、proc fs。如何利用sysfs、proc fs及内核提供的接口为我们降低调试难度，快速解决问题呢？

x-project uboot打开CONFIG_ENV_IS_IN_NAND后，不能运行uboot.bin的问题

Wed, 11 Apr 2018 09:33:09 +0800

本文是原「蜗窝讨论区」的历史存档（2018-04-11），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

gjianw217 · 2018-04-11 09:33

想问个问题： 1 按照ooonebook的方法，我移植了x-project的uboot代码在OK210开发板上，且成功 2 在此基础上，我移植了nandflash，并且在uboot命令行可读写 3 当我打开CONFIG_ENV_IS_IN_NAND（注释掉CONFIG_ENV_IS_IN_MMC）时，uboot可以执行spl的代码，但不能执行uboot.bin的代码

应该是跳转过程中，出现了问题我在start.s文件中，通过宏CONFIG_SPL_BUILD控制Led灯在uboot.bin中闪烁，发现根本没有执行led,也就是说，没有执行uboot.bin程序

感觉跑飞了，跑飞应该有两种可能：一是uboot.bin执向一个不存在的地址，二是运行过程中，出现了指针问题（1）我查看了链接地址，没有问题，和打开CONFIG_ENV_IS_IN_MMC时一样（2）我查看了nand相关代码，没有问题

可否提供了个思路，现在无从下手了，在此不甚感激！

bootargs优先级

Wed, 21 Mar 2018 17:19:59 +0800

本文是原「蜗窝讨论区」的历史存档（2018-03-21），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

wangpeng_bj · 2018-03-21 17:19

Hi linux, uboot中有do_bootm_linux -> boot_prep_linux -> image_setup_linux -> image_setup_libfdt -> fdt_chosen，我看到里面有find or create "/chosen" node的动作，之后判断如果存在环境变量bootargs，就使用这一份。请教以下想法是否正确： 1、dts中可以不添加chosen -> bootargs属性，uboot会帮我们创建 2、uboot环境变量中的bootargs优先级最高其次是uboot代码里默认的那个bootargs 最后才是dts中指定的bootargs

找人-弯曲的旅行-珠海昇生微电子招聘嵌入式软件工程师

Sat, 24 Feb 2018 16:41:06 +0800

本文是原「蜗窝讨论区」的历史存档（2018-02-24），来自版块「内推区」，共 1 帖。讨论区已停止服务，此处仅供查阅。

弯曲的旅行 · 2018-02-24 16:41

工作性质：全职工作地点：珠海市工作经验：一年及以上岗位性质：研发学历要求：本科及以上招聘人数：2人职责描述： 1、负责公司芯片软件SDK的开发和维护； 2、参与嵌入式软件需求开发、设计、修改工作； 3、按照操作流程进行软件整体设计、详细设计和编码； 4、参与新IC的规格制定、前期验证等工作。岗位要求： 1、本科以上学历，计算机、电子、控制或相关专业； 2、熟练掌握C/C++程序设计语言； 3、具有单片机（C51、ARM等）相关项目开发经验，掌握其中一种芯片开发环境，具备较强的软件设计和调试能力； 4、熟悉Timer、ADC、PWM、UART、I2C等外部设备，并有相关项目经验 5、具备相关硬件电路调试能力； 6、熟悉软件技术文档的编写；具备良好的文档编制习惯和代码书写规范； 7、具有较强的逻辑分析能力，责任心强,善于沟通。

工作地址：珠海市高新区大洲科技园 B区发送简历：hr@sinhmicro.com

SLUB DEBUG原理

Thu, 22 Feb 2018 21:49:54 +0800

前言在工作中，经常会遇到由于越界导致的各种奇怪的问题。为什么越界访问导致的问题很奇怪呢？在工作差不多半年的时间里我就遇到了很多越界访问导致的问题（不得不吐槽下IC厂商提供的driver，总是隐藏着bug）。比如说越界访问导致的死机问题，这种问题的出现一般需要长时间测试才能发现，而且发现的时候即使有panic log。你也没什么头绪。这是为什么呢？

图解slub

Thu, 22 Feb 2018 21:02:44 +0800

前言在 Linux 中，伙伴系统（ buddy system ）是以页为单位管理和分配内存。但是现实的需求却以字节为单位，假如我们需要申请 20Bytes ，总不能分配一页吧！那岂不是严重浪费内存。那么该如何分配呢？ slab 分配器就应运而生了，专为小内存分配而生。 slab 分配器分配内存以 Byte 为单位。但是 slab 分配器并没有脱离伙伴系统，而是基于伙伴系统分配的大内存进一步

Deadline调度器之（二）：细节和使用方法

Thu, 22 Feb 2018 18:23:28 +0800

Linux内核的DL调度器是一个全局EDF调度器，它主要针对有deadline限制的sporadic任务。注意：这些术语已经在本系列文章的第一部分中说明了，这里不再赘述。在这本文中，我们将一起来看看Linux DL调度器的细节以及如何使用它。另外，本文对应的英文原文是https://lwn.net/Articles/743946/，感谢lwn和Daniel Bristot de Oliveir

KASAN实现原理

Sun, 11 Feb 2018 22:32:39 +0800

前言 KASAN是一个动态检测内存错误的工具。KASAN可以检测全局变量、栈、堆分配的内存发生越界访问等问题。功能比SLUB DEBUG功能齐全并且支持实时检测。越界访问的严重性和危害性通过我之前的文章（SLUB DEBUG技术）应该有所了解。正是由于SLUB DEBUG缺陷，因此我们需要一种更加强大的检测工具。难道你不想吗？KASAN就是其中一种。KASAN的使用真的很简单。但是我是一个追

deadline调度器之（一）：原理

Wed, 31 Jan 2018 19:20:48 +0800

关于deadline调度器的文档有两篇，本篇简单介绍了实时调度及其背后的一些理论。另外一篇将专门讨论Linux系统中的Deadline调度器。另外，本文主要的框架和思想来自 Deadline scheduling part 1 — overview and theory ，但经过作者的翻译、整理和演绎。

64位Linux下的vmalloc

Mon, 29 Jan 2018 10:16:46 +0800

本文是原「蜗窝讨论区」的历史存档（2018-01-29），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

jack · 2018-01-29 10:16

请问下，64位情况下的vmalloc还有实际的作用吗？？内核不是已经把所有物理内存都一致映射了吗

Hikey上关于TZASC和TZPC的问题

Wed, 24 Jan 2018 15:48:38 +0800

本文是原「蜗窝讨论区」的历史存档（2018-01-24），来自版块「灌水区」，共 1 帖。讨论区已停止服务，此处仅供查阅。

rtosiDiot · 2018-01-24 15:48

请教一下，谁清楚Hikey上关于TZASC和TZPC的寄存器地址问题。网上只查到了海思6210的信息和hikey上tzpc的零星信息，关于tzasc的还是没有。请问能通过什么渠道获知呢？

Meltdown论文翻译

Fri, 19 Jan 2018 20:18:40 +0800

本文是作者阅读meltdown论文随手翻译的一些文字记录，希望能帮助到那些对meltdown感兴趣，但英文不是那么好的同学。水平有限，欢迎指正。

统一设备模型：kobj、kset分析

Tue, 09 Jan 2018 18:37:05 +0800

kobj/kset 作为统一设备模型的基础，到底提供了哪些功能，在具体应用过程中，如 device 、 bus 甚至 platform_device 等是如何使用 kobj/kset 的，这是本文的主要阐述内容。

O(n)、O(1)和CFS调度器

Mon, 08 Jan 2018 19:19:30 +0800

随着内核版本的演进，其源代码的膨胀速度也在递增，这让Linux的学习曲线变得越来越陡峭了。这对初识内核的同学而言当然不是什么好事情，满腔热情很容易被当头浇灭。我有一个循序渐进的方法，那就是先不要看最新的内核，首先找到一个古老版本的内核（一般都会比较简单），将其吃透，然后一点点的迭代，理解每个版本变更背后的缘由和目的，最终推进到最新内核版本。本文就是从2.4时代的任务调度器开始，详细描述其实现并慢

中断唤醒系统流程

Mon, 01 Jan 2018 17:03:28 +0800

设备唤醒cpu之后是立即跳转中断向量表指定的位置吗？如果不是，那么是什么时候才会跳转呢？ 2) 已经跳转到中断服务函数开始执行代码，后续就会调用你注册的中断handle 代码吗？如果不是，那中断服务函数做什么准备呢？而你注册的中断handle又会在什么时候才开始执行呢？ 3) 假如register_thread_irq方式注册的threaded irq中调用msleep(1000)，睡眠1秒

USB-C(USB Type-C)规范的简单介绍和分析

Mon, 18 Dec 2017 16:18:25 +0800

从1996年1月USB1.0正式发布至今（2017年9月 USB3.2发布），USB已经走过了21个年头。在这21年的时间了，USB标准化组织（ USB Implementers Forum，USB-IF）折腾出来了各式各样、五花八门的接口形态：Type A、Type A SuperSpeed、Type B、Type B SuperSpeed、Mini-A、Mini-B、Micro-A、Micro

DM9000网络延时问题

Sun, 17 Dec 2017 22:49:49 +0800

本文是原「蜗窝讨论区」的历史存档（2017-12-17），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

jeremy · 2017-12-17 22:49

arm-cotex a8 内核版本3.20 主频600MHZ 由于工作需要接触到网络驱动，目前对DM9000网卡驱动进行测试，使用ping发送64byte字节测试延时发现网络延时很高，基本在400ms~900ms之间，这个能作为评判9000网卡网络通信状况的依据吗？我考虑这个延时是不是跟任务调度以及内核抢占有关系，所以我后面针对它们做了修改，结果延时立马降到10ms左右—— 原来的linux HZ为100，我把它修改为了250并且打了rt-patch. 还有一个现象就是我不对内核进行修改，运行我们自己的应用层程序，会通过DM9000通信，然后使用ping测试延时，发现延时也在10ms左右！就以上现象，我比较疑惑的是这个延时到底是哪个地方才会导致出现这么大的差别？还是说使用ping测试延时本来就不准确？希望和各位交流一下！

进程切换分析（3）：同步处理

Mon, 11 Dec 2017 17:59:34 +0800

本文主要描述了主调度器（schedule函数）中的同步处理。

请问什么是kernel domain与init domain？

Fri, 17 Nov 2017 19:10:27 +0800

本文是原「蜗窝讨论区」的历史存档（2017-11-17），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

harryxp · 2017-11-17 19:10

在android init进程中，有如下一段代码： // Set up SELinux, including loading the SELinux policy if we're in the kernel domain. selinux_initialize(is_first_stage);

// If we're in the kernel domain, re-exec init to transition to the init domain now 
// that the SELinux policy has been loaded.
if (is_first_stage) {
 if (restorecon("/init") == -1) {
 ERROR("restorecon failed: %s\n", strerror(errno));
 security_failure(;
 }
 char* path = argv[0];
 char* args[] = { path, const_cast&lt;char*&gt;("--second-stage"), nullptr };
 if (execv(path, args) == -1) {
 ERROR("execv(\"%s\") failed: %s\n", path, strerror(errno));
 security_failure(;
 }
}

请问什么是kernel domain与init domain？此init为什么要执行两次？还请高手帮忙解答，万分感激。

逆向映射的演进

Fri, 17 Nov 2017 15:47:38 +0800

数学大师陈省身有一句话是这样说的：了解历史的变化是了解这门学科的一个步骤。今天，我把这句话应用到一个具体的Linux模块：了解逆向映射的最好的方法是了解它的历史。本文介绍了Linux内核中的逆向映射机制如何从无到有，如何从笨重到轻盈的历史过程，通过这些历史的演进过程，希望能对逆向映射有更加深入的理解。

请问硬核写sd卡速度有什么提高的好方法

Fri, 10 Nov 2017 17:31:17 +0800

本文是原「蜗窝讨论区」的历史存档（2017-11-10），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

vlah · 2017-11-10 17:31

SDHC SDXC 的卡都试验过。用测试软件在台式机上写速度大约60MB/s 希望在linux下能达到1(X)MB/s的速度。

[ 61.186962] mmc0: starting CMD25 arg 0004f868 flags 000000b5 [ 61.192621] mmc0: blksz 512 blocks 256 flags 00000100 tsac 3000 ms nsac 0 [ 61.199725] mmc0: CMD12 arg 00000000 flags 0000049d [ 61.228389] mmc0: req done (CMD25): 0: 00000900 00000000 00000000 00000000 [ 61.235246] mmc0: 131072 bytes transferred: 0 [ 61.239932] mmc0: (CMD12): 0: 00000c00 00000000 00000000 00000000

这是我截取的mmc调试信息，写入sd卡时会有很多很多次的CMD25 WRITE_MULTI_BLOCK。

没做过sd卡相关的东西，希望能有人指导一下。感谢!!

Linux kernel内存管理的基本概念

Thu, 09 Nov 2017 22:37:32 +0800

内存（memory）在Linux系统中是一种牵涉面极广的资源，上至应用程序、下至kernel和driver，无不为之魂牵梦绕。加上它天然的稀缺性，导致内存管理（Memory Management，简称MM）是linux kernel中非常重要又非常复杂的一个子系统。重要性就不多说了，Kernel自有分寸。关于复杂性（鉴于Linux kernel优秀的抽象能力），应该不会被普通人（Linux系统的

[招人]--[千帆]--[高通FAE]

Fri, 03 Nov 2017 11:47:59 +0800

本文是原「蜗窝讨论区」的历史存档（2017-11-03），来自版块「内推区」，共 1 帖。讨论区已停止服务，此处仅供查阅。

千帆 · 2017-11-03 11:47

工作职责: 支持高通ARM64服务器芯片工作地: 北京/上海年限: 硕士5年以上, 本科8年以上

高通Centriq 2400服务器芯片, 基于ARMv8, 48核10nm. 对Linux有研究, 对系统有全面深入了解的蜗窝人才我们求贤若渴.

对KVM有深入研究是plus 对性能剖析和优化有研究是plus 对ARMV8架构有深入研究是plus

中英文简历请发至: yingjieb@qti.qualcomm.com

arm板pwm申请失败，Failed to request pwm device: -517

Thu, 02 Nov 2017 22:27:09 +0800

本文是原「蜗窝讨论区」的历史存档（2017-11-02），来自版块「X Project」，共 2 帖。讨论区已停止服务，此处仅供查阅。

今夕何夕 · 2017-11-02 22:27

我用pwm_request申请pwm，一直提示Failed to request pwm device: -517，我dts也已经okay了，求大神指导啊！！

wowo · 2017-11-03 09:10

今夕何夕写道： 我用pwm_request申请pwm，一直提示Failed to request pwm device: -517，我dts也已经okay了，求大神指导啊！！

建议你可以把kernel的debug信息全部打开（可以参考“(/linux_application/kernel_debug_enable.html)”），然后一步一步通过打印找找为什么会失败了。

Linux kernel scatterlist API介绍

Fri, 13 Oct 2017 22:20:34 +0800

我们在那些需要和用户空间交互大量数据的子系统（例如MMC [1] 、Video、Audio等）中，经常看到scatterlist的影子。对我们这些“非英语母语”的人来说，初见这个词汇，脑袋瞬间就蒙圈了。scatter可翻译成“散开、分散”，list是“列表”的意思，因而scatterlist可翻译为“散列表”。“散列表”又是什么？太抽象了！之所以抽象，是因为这个词省略了主语—-物理内存（Ph

X-026-KERNEL-Linux gpio driver的移植之gpio range

Wed, 27 Sep 2017 22:27:43 +0800

我们在[1][2]中提到过，鉴于gpio的特殊性，pinctrl subsystem特意留了一个后门（gpio range），gpio driver可以通过这个后门直接向pinctrl subsystem申请将某个pin用作gpio功能。本文将根据一个简单的示例，介绍这个后门的使用方法，以加深对相关机制的理解。注1：本文的测试方法和[3]中的一致，即：通过gpiolib sysfs api控制L

Device Tree（四）：文件结构解析

Sun, 24 Sep 2017 11:08:53 +0800

通过linuxer发表的三篇设备树的文章，我想你应该对设备已经有一个非常充分的认识了。本篇文章即作为一篇Device Tree的总结性文章，同时也作为linuxer文章的补充。本篇文章曾发表在Linuxer公众号，链接为： http://mp.weixin.qq.com/s/OX-aXd5MYlE_YoZ3p32qWA

X-025-KERNEL-Linux gpio driver的移植之基本功能

Wed, 13 Sep 2017 22:18:00 +0800

本文将基于本站GPIO subsystem [1] 相关的文章，结合” X Project ”的开发过程，实现一个简单的gpio driver，并利用gpiolib提供的sysfs api进行简单的测试，进而加深对gpio相关概念的理解。注1：本文后续的描述，kernel基于本站“ X Project ”所使用的kernel版本，硬件基于 ” X Project ”所使用的“Bubbugum-9

arm 内存管理页表问题咨询

Wed, 13 Sep 2017 11:15:06 +0800

本文是原「蜗窝讨论区」的历史存档（2017-09-13），来自版块「Linux kernel技术问答」，共 7 帖。讨论区已停止服务，此处仅供查阅。

Taochao · 2017-09-13 11:15

想了解下Linux页表相关内容，看的云里雾里

被mmu页表和Linux软件页表绕晕了

综合各种原因，最终arm-linux假装第一级目录只有2048个条目，但其实每个条目是2个ulong大小即8字节，所以最终设置MMU的还是4096个条目，只是每访问1个pgd条目将可以访问到2个pte条目，linux为了实现其内存管理功能又在后面加上2个对应的假pte表，这个假pte表专门给linux内核代码自己用的，不会影响arm硬件

如上描述mm指向的pgd实际是Linux软件页目录和页表？不影响mmu，那mmu通过什么地址转换呢？

还有我在测试的时候看initmm对应的pgd在create_mapping建立了1M的段表，这个是内核用的还是mmu用的？

我看其他的一些mm->pgd指向的内存地址还是有二级页表的，晕了

求大神指导

Taochao · 2017-09-13 11:49

又看了下create_mapping的实现，看上去如果是1m的块内存，直接就把内存的首地址放到pgd的条目中了

不足1m的先申请页表空间，按4k循环建立页表填充页表项，最后将页表的首地址填充到pgd条目中。

1m的内存pgd[0]和pgd[1]是分别映射了1m的空间，而后面的pte页表pgd[0]和pgd[1]似乎赋值一样属性不一样。

这两种mmu怎么区分，如果一个地址过来怎么知道他是断映射还是二级映射？

linuxer · 2017-09-13 17:56

方便把代码贴出来吗？要不不知道你说的那一段代码。

Taochao · 2017-09-14 09:13

linuxer 写道： 方便把代码贴出来吗？要不不知道你说的那一段代码。

alloc_init_section

static void __init alloc_init_section(pud_t pud, unsigned long addr, unsigned long end, phys_addr_t phys, const struct mem_type type, bool force_pages) { pmd_t *pmd = pmd_offset(pud, addr);

/*
 * Try a section mapping - end, addr and phys must all be aligned
 * to a section boundary. Note that PMDs refer to the individual
 * L1 entries, whereas PGDs refer to a group of L1 entries making
 * up one logical pointer to an L2 table.
 */
if (((addr | end | phys) &amp; ~SECTION_MASK) == 0 &amp;&amp; !force_pages) {
 pmd_t *p = pmd;

ifndef CONFIG_ARM_LPAE

 if (addr &amp; SECTION_SIZE)
 pmd++;

endif

 do {
 *pmd = __pmd(phys | type-&gt;prot_sect);
 phys += SECTION_SIZE;
 } while (pmd++, addr += SECTION_SIZE, addr != end);
flush_pmd_entry(p);

} else {
/*
* No need to loop; pte’s aren’t interested in the
* individual L1 entries.
*/
alloc_init_pte(pmd, addr, end, __phys_to_pfn(phys), type);
}

}

不太明白pgd两个long型的意义，作为一级映射和二级映射时候，这两个long型值意义不一样，一个普通的地址怎么知道他是一级映射了还是二级映射的

逆向映射的两个问题

Mon, 11 Sep 2017 17:20:10 +0800

本文是原「蜗窝讨论区」的历史存档（2017-09-11），来自版块「Linux kernel技术问答」，共 2 帖。讨论区已停止服务，此处仅供查阅。

linuxer · 2017-09-11 17:20

问题：书上讲子进程发生COW，会分配新的页面。那么，如果是父进程先遇见COW，是会为父进程还是子进程分配新的页面？这时候匿名页面如何构建AV、AVC和VMA的关系？

回答：如果父进程首先访问，那么它先COW，调用do_wp_page，分配page frame，然后copy，然后建立和自己AV的关系。这时候，子进程的pte仍然指向old page（但是这时候不是和父进程分享该page，而是自己独占了），old page指向父进程的AV。

当子进程访问该页面的时候，也是会page fault，调用do_wp_page，不过这时候不需要分配新的page了（因为该page是自己独占的），而是调用page_move_anon_rmap，从而指向了自己的AV。

linuxer · 2017-09-11 17:20

问题：从v2.6.34开始，anon_vma中的AVC，是被组织成rbtree的。可是，该rbtree，除了insert和remove操作，就只有一种操作了：遍历。这个我不能理解，因为任何数据结构的遍历，都是O(N)的，那么为什么(不像原来一样)用list呢？

回答：大家比较熟悉的场景都是进程fork的场景，例如：进程P，包含一个VMA（a，b），进程P fork了999个子进程，在这个场景下： 1、 P进程AV红黑树中有1000个VMA并且所有的VMA的起始地址都是（a，b），当然是在不同地址空间 2、子进程AV红黑树中只有1个VMA 在这样的场景下，anon_vma_interval_tree_foreach会遍历每一个VMA，这是没有办法的事情。不过还有一个场景也很有意思，如果一个进程，有一个很大的VMA，随着用户空间修改部分映射的属性（例如mprotect），这个大的VMA会不断的分裂。这些分裂的VMA（x0～xn）会共享一个AV（当然，前提是VMA是匿名映射），这时候，一个进程内，非常多的VMA（起始地址都不一样）共享一个AV结构，而这个AV结构的红黑树中根据起始地址挂入分裂后的VMA（x0～xn），这时候，anon_vma_interval_tree_foreach就有意义了，如果是链表，对于给定的page，那么的确是需要一个个的匹配，但实际上x0～xn只有一个是真正match这个page的，如果是红黑树，那么anon_vma_interval_tree_foreach不会遍历，会直接命中对应的VMA。

蓝牙协议分析(11)_BLE安全机制之SM

Thu, 07 Sep 2017 19:49:57 +0800

注1：此SM是Security Manager的缩写，非彼SM，大家不要理解歪了！书接上文，我们在“ 蓝牙协议分析(10)_BLE安全机制之LE Encryption ”中介绍了BLE安全机制中的终极武器—-数据加密。不过使用这把武器有个前提，那就是双方要共同拥有一个加密key（LTK，Long Term Key）。这个key至关重要，怎么生成、怎么由通信的双方共享，关系到加密的成败。因此蓝

【来自谢宝友同学的微信群】如何追踪stack overflow的issue？

Wed, 06 Sep 2017 09:43:38 +0800

本文是原「蜗窝讨论区」的历史存档（2017-09-06），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

linuxer · 2017-09-06 09:43

问题：我们开发应用的时候, 经常遇到爆栈和栈被破坏是个什么情况?怎么追踪这样的错误？

回答：爆栈，个人理解就是栈大小不够了。例如，默认8M的栈空间，结果实际使用过程中，最长的调用链占用了超过8M的空间，导致撞上了保护墙，这时表现为段错误。

其原因一般是在函数中用了较大的局部变量，这些变量占用过多的栈空间。Linux内核有一个编译检测功能，可以检测函数局部变量过大的情况，并给出警告，这个应该是工具链提供的功能，用户态应该也可以使用。也存在一些特殊情况，例如函数中数组或者变量越界，破坏了栈帧，导致在堆栈压栈退栈时候，将SP值破坏，看起来堆栈爆了。栈被破坏，一般还是调用链上临时变量越界引起，但是也不能排除其他线程的野指针改写了堆栈里面的内容。另一种特殊情况，是内核，特别是驱动，在内核态中有内存野指针，或者在管理cache时出现问题。

具体如何分析有如下方法： 1、创建时改变线程栈大小，这样现象可能会发生改变。甚至故障现象消失。 2、创建一些无用的线程，在出问题的时候，用gdb连上去看看是不是栈里面的内容不是0。 3、借用编译器的功能，在函数序言和尾声处加入钩子，在钩子中监控SP大小，一旦超过特定大小就报告，防止爆栈。 4、直接拿着驱动走查代码，很多时候，走查代码是最快的查找故障的方法。 5、在爆栈的时候，看看堆栈是不是全满了。直接看smaps文件里面，堆栈所在vma的rss字段即可。如果满了，用GDB连上去，把堆栈dump出来，手工找一找调用链也是可行的。

【来自谢宝友同学的微信群】线程创建之后栈大小还可调整吗？

Wed, 06 Sep 2017 09:41:53 +0800

本文是原「蜗窝讨论区」的历史存档（2017-09-06），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

linuxer · 2017-09-06 09:41

最近遇到一个奇怪的问题，线程创建都是使用统一接口创建的，线程栈默认8M，但是有个别线程栈几十M？线程栈不是创建之初就确定了吗？线程创建之后栈大小还可调整吗？

这里的栈，要分两种情况讨论： 1、线程组里面的Leader线程的栈，即main函数所在的线程的栈 2、通过pthread_create创建的线程的栈。

内核在处理Leader线程的栈的时候，一般是自动扩展，直到vma虚拟地址空间无法扩展。这在内核的do_page_fault函数中有专门的expend_stack处理。这个栈的大小，一般很大，几乎可以认为不受限制。

对于第2种情况，即pthread_create创建的线程，其栈地址从进程高地址向下分配，每个线程的栈大小，在创建线程的时候可以指定。下一个创建的线程，会紧跟在上一个线程的栈地址空间。两个栈之间，会有一个大小为PAGE_SIZE的，属性为“不可读不可写”的vma，作为两个栈之间的保护墙，防止栈之间越界。这种栈不能自动扩展，也不能随意扩大。

pthread栈是自定义的mmap出来的vma，只在底部有一个4KB保护墙，确实在高处有可能和其他的mmap出来的VMA发生合并。

Linux reset framework

Fri, 01 Sep 2017 10:46:14 +0800

大家都知道，复杂IC内部有很多具有独立功能的硬件模块，例如CPU cores、GPU cores、USB控制器、MMC控制器、等等，出于功耗、稳定性等方面的考虑，有些IC在内部为这些硬件模块设计了复位信号（reset signals），软件可通过寄存器（一般1个bit控制1个硬件）控制这些硬件模块的复位状态。 Linux kernel为了方便设备驱动的编写，抽象出一个简单的软件框架—-rese

页面回收的基本概念

Fri, 25 Aug 2017 19:01:35 +0800

本文主要介绍了一些page reclaim机制中的基本概念。这份文档其实也可以看成阅读ULK第17章第一小节的一个读书笔记。虽然ULK已经读了很多遍，不过每一遍还是觉得有收获。Linux内核虽然不断在演进，但是页面回收的基本概念是不变的，所以ULK仍然值得内核发烧友仔细品味。

【ARM中文社区微信群的一个问题讨论】用户空间如何操作cache？

Thu, 24 Aug 2017 17:42:31 +0800

本文是原「蜗窝讨论区」的历史存档（2017-08-24），来自版块「Linux kernel技术问答」，共 2 帖。讨论区已停止服务，此处仅供查阅。

linuxer · 2017-08-24 17:42

问题：各位大神，怎么样手动invalidate arm v8的cache？内核里面，__inval_cache_range是刷新已经存在的映射，但这是内核API，想手动将应用程序的某部分Cache Invalidate掉，这个能实现吗？虽然armv8在用户态不鼓励cache maintanece，但是我们的场景比较特殊，具体是这样的：我们在将加速器的一部分DMA地址直接映射到用户态，并且在用户态直接操作加速器硬件。在硬件操作完毕DMA后，我们需要将相应的虚拟地址空间invalidate。目前我们已经基本实现功能，在向DMA写入数据后，调用__clear_cache实现了回写，唯一的问题是硬件写入DMA后，没有找到invalidate的地方。

linuxer · 2017-08-24 17:42

讨论过程： 1、如何保证coherence？这里的场景基本上是想用cacheable的dma，mapping到用户空间，然后自己在用户空间使用cache maintanence 来保证coherence？不过，gcc的build-in函数： void __builtinclearcache (char begin, char end) ARMv8下面最终会调用aarch64_sync_cache_range，而这个函数定义如下： void __aarch64_sync_cache_range (const void base, const void end) { unsigned icache_lsize; unsigned dcache_lsize; static unsigned int cache_info = 0; const char *address;

if (! cache_info) / CTR_EL0 [3:0] contains log2 of icache line size in words. CTR_EL0 [19:16] contains log2 of dcache line size in words. / asm volatile ("mrs\t%0, ctr_el0":"=r" (cache_info));

icache_lsize = 4 << (cache_info & 0xF); dcache_lsize = 4 << ((cache_info >> 16) & 0xF);

/ Loop over the address range, clearing one cache line at once. Data cache must be flushed to unification first to make sure the instruction cache fetches the updated data. 'end' is exclusive, as per the GNU definition of __clear_cache. /

/ Make the start address of the loop cache aligned. / address = (const char*) ((UINTPTR_TYPE) base & ~ (UINTPTR_TYPE) (dcache_lsize - 1));

for (; address < (const char *) end; address += dcache_lsize) asm volatile ("dc\tcvau, %0" : : "r" (address) : "memory"); asm volatile ("dsb\tish" : : : "memory");

/ Make the start address of the loop cache aligned. / address = (const char*) ((UINTPTR_TYPE) base & ~ (UINTPTR_TYPE) (icache_lsize - 1));

for (; address < (const char *) end; address += icache_lsize) asm volatile ("ic\tivau, %0" : : "r" (address) : "memory");

asm volatile ("dsb\tish; isb" : : : "memory"); } 显然，这里的cache 操作只是到PoU, 不是到PoC. 最终不一定到memory。因此，clear_cache 不能用于保证dma coherent，只能适用于self-modifying code。

2、用户态自己实现怎么样？如果考虑在user space使用cache maintanence指令，不过这种方法有限制： A、在EL0，不是所有的cache maintanence指令都能用 B、如果用户态aarch32，就不能用了

3、把用户空间的虚拟地址和size传递到内核，由内核调用__inval_cache_range可不可以？让kernel去执行flush/invalidate用户空间虚拟地址的操作是行不通的，问题在于__flush_dcache_area（）只接受一个对于kernel合法的虚拟地址。

4、怎么优雅的解决目前的困境？其实这个问题在kernel没有一个有效的方案，DMA-APIs不愿去提供这样的一个机制，是由于各个体系结构的差异。就拿ARM cache来说就有VIPT, PIPT（cortex-A53）, 在一个体系结构下有效的方式，很难扩展应用到其他体系结构下，所以就不能被合并到kernel source code中去

5、性能方面的考虑其实可以仔细思考这个问题：使用cacheable的buffer真的能解决性能瓶颈么？这可能取决于application如何使用这些data，以及data的规模。试图缓存很大的一块buffer会不会污染CPU cache,进而有其他的系统影响？

内核中文件解压缩操作

Mon, 21 Aug 2017 16:57:41 +0800

本文是原「蜗窝讨论区」的历史存档（2017-08-21），来自版块「Linux kernel技术问答」，共 5 帖。讨论区已停止服务，此处仅供查阅。

wangpeng_bj · 2017-08-21 16:57

Hi linuxer, 非常感谢提供这么好的技术平台。目前项目遇到一个需求，需要将内核异常日志搜集压缩后转存到BMC，请教内核有现成的解压缩函数可用吗？

linuxer · 2017-08-22 23:16

解压函数的话在启动代码中有，ARM平台上，在启动的时候，首先需要把压缩内核解开，我记得是有解压函数可以用。压缩函数的话，这个我真不知道。

wangpeng_bj · 2017-09-04 17:20

内核解压缩算法总结 1、842 接口： EXPORT_SYMBOL_GPL(sw842_compress); （没有解压缩接口）内核中引用位置：无 2、lz4 接口： EXPORT_SYMBOL(lz4hc_compress); EXPORT_SYMBOL(lz4_compress); EXPORT_SYMBOL(lz4_decompress); EXPORT_SYMBOL(lz4_decompress_unknownoutputsize); 内核中引用位置： \drivers\block\zram\Zcomp_lz4.c（只有zram模块引用到） 3、lzo 接口： EXPORT_SYMBOL_GPL(lzo1x_1_compress); EXPORT_SYMBOL_GPL(lzo1x_decompress_safe); 内核中引用位置： Compr_lzo.c (fs\jffs2) Regcache-lzo.c (drivers\base\regmap) Swap.c (kernel\power) Zcomp_lzo.c (drivers\block\zram) 4、xz 解压接口： EXPORT_SYMBOL(xz_dec_init); EXPORT_SYMBOL(xz_dec_reset); EXPORT_SYMBOL(xz_dec_run); EXPORT_SYMBOL(xz_dec_end); 内核中引用位置： decompress_unxz.c (lib)用于解压.xz xz_wrapper.c (fs\squashfs) - a compressed read only filesystem 5、gzip 压缩接口： EXPORT_SYMBOL(zlib_deflate_workspacesize); EXPORT_SYMBOL(zlib_deflate); EXPORT_SYMBOL(zlib_deflateInit2); EXPORT_SYMBOL(zlib_deflateEnd); EXPORT_SYMBOL(zlib_deflateReset); 解压缩接口： EXPORT_SYMBOL(zlib_inflate_workspacesize); EXPORT_SYMBOL(zlib_inflate); EXPORT_SYMBOL(zlib_inflateInit2); EXPORT_SYMBOL(zlib_inflateEnd); EXPORT_SYMBOL(zlib_inflateReset); EXPORT_SYMBOL(zlib_inflateIncomp); EXPORT_SYMBOL(zlib_inflate_blob); 内核引用位置：有多处引用 Ppp_deflate.c (drivers\net\ppp) Zlib.c (crypto) 压缩 Bnx2x_main.c (drivers\net\ethernet\broadcom\bnx2x) 解压

总结：从内核使用情况看，842没有解压接口，lz4只有zram模块用到，xz用于解压.xz文件； lzo和zlib用的更普遍些，lzo有更好的解压缩速度，zlib被更普遍应用，对应的应用层库几乎已经成为一个业界标准。

压缩算法的比较 Algorithm % remaining Encoding Decoding GZIP 13.4% 21 MB/s 118 MB/s LZO 20.5% 135 MB/s 410 MB/s Zippy/Snappy 22.2% 172 MB/s 409 MB/s 注：来自《HBase: The Definitive Guide》其中： 1）GZIP的压缩率最高，但是其实CPU密集型的，对CPU的消耗比其他算法要多，压缩和解压速度也慢； 2）LZO的压缩率居中，比GZIP要低一些，但是压缩和解压速度明显要比GZIP快很多，其中解压速度快的更多； 3）Zippy/Snappy的压缩率最低，而压缩和解压速度要稍微比LZO要快一些。

参考文档： http://www.zlib.net/zlib_how.html zlib API接口使用（内核使用情况类似） http://blog.csdn.net/memoryjs/article/details/39053127 使用lzo实现zram http://doc.mbalib.com/view/80bcc5c56278b864b67e6a3f603d5ab7.html in kernel memory compression

/proc/meminfo分析（一）

Thu, 17 Aug 2017 19:27:06 +0800

本文主要分析/proc/meminfo文件的各种输出信息的具体含义。

【微信群技术讨论】/proc/meminfo中的Buffers和Cached有什么区别

Tue, 15 Aug 2017 08:32:22 +0800

本文是原「蜗窝讨论区」的历史存档（2017-08-15），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

linuxer · 2017-08-15 08:32

总结群内网友的讨论如下： 1、Buffers给出了系统中的buffer cache占用的内存数量。所谓buffer cache就是直接访问block device（不是通过文件系统）时候使用的disk cache。主要的场景包括： 1-1、打开该block device的设备节点，直接进行读写操作（例如dd一个块设备） 1-2、mount文件系统的时候，需要从相应的block device上直接把块设备上的特定文件系统的super block相关信息读取出来 1-3、文件操作的时候，和文件元数据相关的操作也是通过buffer cache进行访问。上面的这些访问，都是通过块设备的page cache（位于bdev->bd_inode->i_mapping）中，也就是说，buffer cache其实是一种特殊的page cache而已。虽然可以通过多个设备节点直接访问块设备，但是其buffer cache还是要保存在一个地方，因此Linux建立了一个特别的bdev文件系统，专门保存块设备的inode。也就是说，/dev/aaa和/dev/bbb两个块设备节点，设备号一样，open这两个设备节点虽然有两个inode对应，但是address space却是bdev文件系统中的那个inode对应的address space。具体如何统计Buffers的内存，可以参考nr_blockdev_pages的实现，其实就是把系统中所有block device对应的inode（指bdev文件系统中那个inode）的page cache累加起来就OK了。

2、Cached给出了普通文件读写使用的page cache内存数量。其计算公式如下： Cache内存数量 = 系统中page cache的数量（标记了NR_FILE_PAGES flag） - swap cache的数目 - buffer cache的数目无论buffer cache还是swap cache，也都是page cache，但是它们和普通文件读写无关，因此，要减去这些page cache的内存数目才能得到真正用于普通文件读写的page cache数目。

linux内核中的GPIO系统之（5）：gpio subsysem和pinctrl subsystem之间的耦合

Thu, 10 Aug 2017 22:17:49 +0800

按理说，kernel中gpio subsystem和pinctrl subsystem的关系应该非常清楚： pinctrl subsystem管理系统的所有管脚，GPIO是这些管脚的用途之一，因此gpio subsystem应该是pinctrl subsystem的client（也可叫做backend、consumer），基于pinctrl subsystem提供的功能，处理GPIO有关的逻辑。

【微信群技术讨论】threaded irq和工作队列(work queue)如何选择？

Tue, 08 Aug 2017 08:24:04 +0800

本文是原「蜗窝讨论区」的历史存档（2017-08-08），来自版块「Linux kernel技术问答」，共 5 帖。讨论区已停止服务，此处仅供查阅。

linuxer · 2017-08-08 08:24

问题：threaded irq和工作队列(work queue)都是在进程上下文中处理中断下半部。什么时候选工作队列，什么时候选threaded irq? 谢谢。

linuxer · 2017-08-08 08:27

讨论的结果： 1、threaded irq handler所在的进程（内核线程）的调度类别是SCHED_FIFO，即属于实时进程。而workqueue所依赖的线程池创建的worker线程属于普通进程。因此，如果有实时需求，优先选择threaded irq 2、如果没有实时需求，选择workqueue这个机制。

linuxer · 2017-08-08 08:33

此外，还顺便讨论了workqueue的排队问题。threaded irq处理中断也是需要排队，但是这些中断事件一般来自一个驱动。而workqueue可能有多个驱动共享的情况，这时候，多个驱动的work被挂入了一个workqueue，需要排队处理。一般而言，除非work被阻塞，否则workqueue对应的线程池也不会创建新的worker线程。

linuxer · 2017-08-08 08:37

有一位同学追问了一个问题：现在的work都是提交到workpool里处理，那使用自己创建的workqueue和系统的workqueue有什么区别呢？

回答： CMWQ的目标之一就是明确的划分了workqueue的前端接口和后端实现机制。也就是说，用户应该关注workqueue的前端的那些接口，自己创建workqueue、销毁workqueue、queue一个work等，而具体后端采用什么机制（例如是否两个workqueue共用同一个worker thread pool）应该是用户不可见的。因此，为何要使用自己创建的workqueue而不使用系统的workqueue呢？这和workqueue属性相关，也就是说你要创建怎样的workqueue（bound or unbound，normal or high priority等），如果你的workqueue没有什么特别的属性，那么使用系统缺省的那些就OK了，但是如果系统中缺省创建的workqueue所具备的属性不符合你的需求，那么你就需要自己创建workqueue。但是，无论如何，底层是什么的线程池来处理其实用户是不需要关系的，系统可以做好一切的。

linuxer · 2017-08-08 08:42

那到底要自己创建的workqueue还是使用系统的workqueue呢？一言以蔽之，如果没有需要，还是使用系统的workqueue吧。

《奔跑吧，Linux内核》已经上架预售了

Sat, 05 Aug 2017 12:10:42 +0800

不想当将军的士兵不是好士兵，不想写进程调度器的麻醉师不是好的麻醉师，不想钻研内核的FAE不是好的FAE。笨叔叔就是这样的一个有点特别的FAE，写了一本书叫做《奔跑吧Linux内核》，每个人都会经过这个阶段，见到一座山，就想知道山后面是什么。而作为FAE，每次被客户吊打之后，总是想知道Linux的内核机制是什么，吊打久了，各种内核的脉络也就慢慢清晰了。在无数的不眠之夜以后，全球首本基于4.0内核的

uboot 链接错误

Fri, 04 Aug 2017 10:22:16 +0800

本文是原「蜗窝讨论区」的历史存档（2017-08-04），来自版块「X Project」，共 2 帖。讨论区已停止服务，此处仅供查阅。

xcl706 · 2017-08-04 10:22

我把内存，时钟等初始化代码写到了板级文件夹中。然后在SOC级(mach-xxxx)的通用代码中调用。编译u-boot时遇到了链接错误，提示符号未定义，也就是板级文件中定义的那些符号在链接mach-xxx相关代码时找不到。原因大概能猜到，应该是最后的链接命令中mach-xxx的built-in.o 出现在board的built-in.o的前面。我想问下：有没有有没有办法在不修改链接命令的情况下忽略上述的链接顺序。还有就是，为什么_start 中调用了_main 链接时却不会出错。难道有什么特殊的用法。

附上最后的链接命令和错误信息： (cd spl && arm-linux-ld -T u-boot-spl.lds --gc-sections -Bstatic --gc-sections -Ttext 0x02021410 arch/arm/cpu/armv7/start.o --start-group arch/arm/mach-exynos/built-in.o arch/arm/cpu/armv7/built-in.o arch/arm/cpu/built-in.o arch/arm/lib/built-in.o board/samsung/tiny4412/built-in.o board/samsung/common/built-in.o common/init/built-in.o drivers/built-in.o dts/built-in.o fs/built-in.o --end-group arch/arm/lib/eabi_compat.o arch/arm/lib/lib.a -Map u-boot-spl.map -o u-boot-spl)

arch/arm/mach-exynos/built-in.o: In function do_lowlevel_init': /home/xcl706/Documents/Source Insight 4.0/Projects/uboot/src/arch/arm/mach-exynos/lowlevel_init.c:221: undefined reference tosystem_clock_init' /home/xcl706/Documents/Source Insight 4.0/Projects/uboot/src/arch/arm/mach-exynos/lowlevel_init.c:229: undefined reference to `mem_ctrl_init' scripts/Makefile.spl:333: recipe for target 'spl/u-boot-spl' failed make[1]: *** Error 1 Makefile:1382: recipe for target 'spl/u-boot-spl' failed make: *** Error 2

【微信群技术讨论】寄存器访问使用writel还是writel_relaxed？

Fri, 04 Aug 2017 08:55:48 +0800

本文是原「蜗窝讨论区」的历史存档（2017-08-04），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

linuxer · 2017-08-04 08:55

问个问题，如果一个外设寄存器0写操作后，必须在规定的bus clock cycle 内完成寄存器1的写操作，此时如果两次写不用memory barrier 会有什么后果. 之所以这么问，是因为在驱动中，两次写用writel 和writel_relaxed 情况完全不一样，用writel 是ok的，用relaxed reg1写无效. BTW，平台是ARMv7。

分析结果： 1、这是一个需要同步的场景，即reg0的操作必须先于reg1到达target。在这样的场景下，必须使用writel进行同步。更具体的说，如果第二个寄存器的写要求第一个寄存器先完成第一个用relaxed 第二个用writel。 2、如果mapping成strongly ordered device memory，那么可以使用writel_relaxed

一个简单的编程套路：比如平时编程dma ，写src dst，direction size这些寄存器用writel relaxed ，最后开始启动dma的寄存器用writel。

另外，在linux内核中，一般ioremap都是mapping如下： 1、对于ARMv7,是普通的device type（非strongly ordered ） 2、对于ARMv8，是Device-nGnRnE。

附录：在ARMv7上，适合外设的memory type有两种：device type和strongly-ordered，他们都可以保证 1、all accesses occur at their program size 2、the number of accesses is the number specified by the program. 但是也有明显的不同： 1、a write to Strongly-ordered memory can complete only when it reaches the peripheral or memory component accessed by the write 2、a write to Device memory is permitted to complete before it reaches the peripheral or memory component accessed by the write.

对应这个问题场景，如果reg0和reg1是device type的话而且没有显式的mb操作，很显然，对reg0的写还没有到达目的地，对reg1的写就又上路了，有可能先于reg0到达target。

对于ARMv8，device type定义了memory attribute来约束地址访问： 1、Gathering。是否忠实反映io操作。例如：如果可以gathering，那么程序中的两个2B操作可能会合成一个4B操作。 2、Reordering 。是否忠实反映io顺序（我的理解是cpu发送到总线上的顺序，但不关心是否到达target）。 3、Early Write Acknowledgement。对于write response的约束。如果是nE的话，那么对reg0的write操作需要等到target的ack返回之后才能发出对reg1的写操作。 Device-nGnRE，相对于ARMv7中的device type。 Device-nGnRnE，相对于ARMv7中的strongly-ordered type。限制的非常死，CPU没有任何发挥性能优化的空间。

【微信群技术讨论】strncpy_from_user如果copy内核字符串会怎样？

Fri, 04 Aug 2017 08:38:42 +0800

本文是原「蜗窝讨论区」的历史存档（2017-08-04），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

linuxer · 2017-08-04 08:38

请问，strncpy_from_user(char dst, const char __user src, long count)从用户空间复制字符串到内核缓冲区，如果这个src指针指向内核空间的一个字符串，那么这个函数还能正常执行吗？

为什么这么问呢？因为在内核代码中，kernel_init_freeable里面调用sys_open((const char __user*) "/dev/console", O_RDWR, 0)，这个/dev/console字符串就是编译进内核映像，src指针应该就是指向内核空间的一个地址，这里的调度不会有问题吗？

回答：Strncpy_from_user会检查src是否超过地址空间的上限（struct thread_info 中的addr_limit），对于用户空间进程，这个addr_limit就是用户空间的上限，对于ARM，这个极限值是TASK_SIZE（3G），对于ARM64，这个极限值是(UL(1) << VA_BITS)，对于内核线程，这个addr_limit就是整个地址空间的上限，也就是说，在内核态可以访问所有的地址空间（内核空间＋用户地址空间）

关于ext4文件系统损坏问题

Wed, 02 Aug 2017 19:29:46 +0800

本文是原「蜗窝讨论区」的历史存档（2017-08-02），来自版块「Linux kernel技术问答」，共 2 帖。讨论区已停止服务，此处仅供查阅。

小艾的 · 2017-08-02 19:29

设备突然断电或者看门狗重启导致的文件系统节点损坏或者文件丢失的问题，大家都是如何处理？

linuxer · 2017-08-03 15:17

现在论坛没落了，如果想讨论技术问题，可以考虑加入蜗窝内核群，那里有更多的工程师。
这个论坛慢慢的变成一个保存微信群技术讨论的地方了，哈哈。

【微信群技术讨论】BUG: KASan: user-memory-access on address 00000000da3f9000

Wed, 02 Aug 2017 16:14:15 +0800

本文是原「蜗窝讨论区」的历史存档（2017-08-02），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

vachel · 2017-08-02 16:14

问题描述: 打开KASAN监测kernel内存, 发现会出现BUG: KASan: user-memory-access on address 00000000da3f9000, 从trace里面分析copy_from_user传入了一个不在user stack 里面地址. 比如: user space: int nTest; ioctl(xxx, xxx, &nTest);

kernel space: int xxx_IOCt(struct file filp, unsigned int u32Cmd, unsigned long u32Arg) { .... if(copy_from_user(xxx, (int __user )arg, sizeof(int))) //这里的arg即nTest的地址不在stack里面. { return -EFAULT; } }

Debug发现: 局部变量的地址没有溢出但不在stack的VMA范围, 而stack和局部变量的地址所在vma都有执行权限比如: nTest的地址是da3f9050, cat /proc/{pid}/maps 看到 da3f9000-dabf8000 rwxp 00000000 00:00 0 ffee3000-fff04000 rwxp 00000000 00:00 0

Root cause: 宿主进程load 一个gcc4.7.2的共享库. 目前owner表示某些平台兼容这个lib做的不好, 导致一些异常的事情发生.

参考: https://bugs.chromium.org/p/chromium/issues/detail?id=29824

【微信群问题讨论】arm64_memory_present中的代码注释疑问

Tue, 01 Aug 2017 00:12:10 +0800

本文是原「蜗窝讨论区」的历史存档（2017-08-01），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

linuxer · 2017-08-01 00:12

问题：请教一下, 为什么arm64_memory_present的注释要这么写"so must be done after the fixed reservations"

回答： fixed reservations是指在arm64_memblock_init中通过memblock_reserve保留地内存，包括 1、kernel text, kernel data, initrd, 以及起始阶段的页表。 2、通过dts，你也可以指定reserved的memory region，具体在early_init_fdt_scan_reserved_mem中处理 3、为DMA保留地连续内存，具体在dma_contiguous_reserve中处理。

arm64_memblock_init之后，memory block都已经初始化完毕，启动阶段的内存管理机制memblock已经OK，现在需要向真正的Linux内存管理机制（伙伴系统）转移。具体的转移过程中需要注意： 1、arm64_memblock_init之后，所有的memory type和reserved type的memory block都已经保存在相关的数据结构中。可以说memblock初始化完成 2、只有在memblock初始化完成，代码才可以调用memblock_alloc进行物理内存分配。但是不能访问其虚拟地址。为什么呢？因为没有建立页表。 3、在调用map_mem之前，只有很少一部分的物理内存建立了地址映射，包括kernel image，dtb等局部内存区域，初始阶段映射这些memory region就足够了 4、在调用map_mem之前，有两段内存已经是可见的（完成了地址映射），一个是kernel image段，另外一个是fdt段。，而广大的系统内存区域仍然在黑暗之中，等待我们去拯救（进行地址映射）。

经过上面的铺垫，我们再看看paging_init的代码： void __init paging_init(void) { void *zero_page;

map_mem(;

...... / allocate the zero page. / zero_page = early_alloc(PAGE_SIZE);

bootmem_init(;

......

void __init bootmem_init(void) { unsigned long min, max;

min = PFN_UP(memblock_start_of_DRAM();
max = PFN_DOWN(memblock_end_of_DRAM();
/*

Sparsemem tries to allocate bootmem in memory_present(, so must be
done after the fixed reservations.
*/
arm64_memory_present(;

在arm64_memory_present中，如果配置了CONFIG_SPARSEMEM，那么我们需要针对每一个memblock中的memory type的region，调用memory_present函数，声称该段memory当前状态是present的。而在memory_present函数中会调用memblock_alloc分配物理内存，并通过虚拟地址访问分配的物理内存，正因为有这样的特点，因此arm64_memory_present必须： 1、在fixed reservation之后调用，否则有可能会命中kernel image或者dtb的物理内存区域。 2、必须在map_mem之后

【微信群技术讨论】deep idle的唤醒问题

Mon, 31 Jul 2017 17:31:57 +0800

本文是原「蜗窝讨论区」的历史存档（2017-07-31），来自版块「Linux kernel技术问答」，共 6 帖。讨论区已停止服务，此处仅供查阅。

linuxer · 2017-07-31 17:31

问题描述：gic500 下，cpuidle 中core1进了power down的idle state后，ipi 还能唤醒这个core么?

经过大家的讨论，整个系统结构描述如下：

该问题涉及的HW block包括： 1、 PMC 2、 GIC 3、 Cpu core（PE）

涉及的软件模块包括： 1、 CPU idle和CPU PM模块 2、 Gic dirver模块

CPU idle软件模块控制某个cpu core进入深度的idle状态，这将导致cpu core下电，一旦cpu core下电，接收外部中断信号的cpu interface也就不工作了（cpu interface 是包含在cpu core中的一个HW block，cpu interface 是和cpu core 应该是一个power domain），因此cpu core也就没有办法接收到中断了，除非有一个上电过程。

本身cpu idle的定义和system suspend不同，任何的中断都是可以将cpu从 idle中唤醒的，不论是外设的中断还是IPI中断。为了让系统正常运转，在进入深度idle状态的时候，CPU idle模块和GIC driver模块需要交互（通过cpu pm driver模块），确保当中断发生的时候，系统可从deep idle中恢复。

具体交互的内容就是把该PE对应的redistributor给disable了。这需要操作GICR_WAKER寄存器的ProcessorSleep比特。这样，GIC就知道对应的cpu core进入sleep状态，其对应的redistributor也就不会转发中断到该cpu core了。我们称这种cpu interface和对应的redistributor处于quiescent state（是否让你想起了RCU，哈哈）

在quiescent state的时候，如果有中断送达该cpu core会怎么办呢？GIC会assert cpuWakeupRequest信号，而该信号一般会连接到PMC上，PMC收到这个asserted的信号会给对应的PE上电，走上从deep idle状态的恢复之路。IPI的中断也是通过GIC<---->redistributorX<---->cpu interfaceX<---->PEX这样的路径，因此也应该可以唤醒cpu core。

最后的结论： ipi可以唤醒CPU idle的CPU，但需要正确的GIC和PMC的硬件连接。

【微信群问题讨论】双核挂死问题

Fri, 28 Jul 2017 09:10:22 +0800

本文是原「蜗窝讨论区」的历史存档（2017-07-28），来自版块「Linux kernel技术问答」，共 2 帖。讨论区已停止服务，此处仅供查阅。

linuxer · 2017-07-28 09:10

请教个双核挂死问题：armv8的core，我在bootloader阶段让一个core进入wfe，只有core0在跑，core0启动linux内核后，在smp初始化的时候bringup core1，发现core1启动有问题，状态不对。

把上次问的armv8 smp 启动的问题完结一下，1，smp时多核进入kernel的模式必须一致（el2或el1）我的问题就是两个不一致，主core是el2，但是其他的core在el3；2双核挂死，芯片里边gic有根线tie的不对。关于问题1，如果你是用atf或已有的启动流程据估计也不会遇到，如果整个启动flow都是自己搞定而且是第一次，像我这样的，这些坑你有可能会遇到。

qdzhaozx · 2017-07-28 10:11

赞一个

X-024-OHTHERS-在windows平台下使用libusb

Sun, 23 Jul 2017 22:21:15 +0800

话说我们“ X Project ”的第一个任务就是通过USB将主机上的Image文件下载到开发板的Ram中执行（参考[1]中有关的内容），为此我们在host中porting了一个简单的应用程序（称作DFU [2] ），负责和开发板ROM中的代码交流，下载并执行Image文件。为了方便，该应用程序使用libusb [3] 进行USB有关的操作。 libusb不止使用起来简单，还有一个极大的优点，就是

Dynamic DMA mapping Guide

Thu, 20 Jul 2017 19:23:38 +0800

这是一篇指导驱动工程师如何使用DMA API的文档，为了方便理解，文档中给出了伪代码的例程。另外一篇文档dma-api.txt给出了相关API的简明描述，有兴趣也可以看看那一篇，这两份文档在DMA API的描述方面是一致的。

【微信群技术讨论】Linux armv7的mmu到底有沒有使用ttbr1

Thu, 20 Jul 2017 11:38:32 +0800

本文是原「蜗窝讨论区」的历史存档（2017-07-20），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

linuxer · 2017-07-20 11:38

請問各位大俠，Linux armv7的mmu到底有沒有使用ttbr1 ?，看了資料跟代碼還是搞的好糊塗。

讨论的结果： 1、 ARMv6之前，毫无疑问，各个进程只有一个ttbr 2、 ARMv7分成两种情况，一种是没有开LPAE的，这时候，Linux系统行为跟随ARMv6之前：TTBR1没有使用，各个进程有自己的进程空间，pgd指针保存在各自task struct的pgd成员中，当进程切换的时候用自己的pgd来恢复ttbr0。还有一种情况是打开了LPAE，这时候Linux内核支持两个TTBR寄存器：其中TTBR1固定指向内核空间，而TTBR0指向各自的userspace。

请教一个initramdisk的问题

Wed, 19 Jul 2017 11:23:09 +0800

本文是原「蜗窝讨论区」的历史存档（2017-07-19），来自版块「Linux kernel技术问答」，共 2 帖。讨论区已停止服务，此处仅供查阅。

ghostpipi · 2017-07-19 11:23

我自己做了一个根文件系统，使用命令“sudo find . | sudo cpio -o -Hnewc | sudo gzip -9 > ../initramfs_data.cpio.gz”压缩成cpio.gz，大小有58.6M

在linux内核里，版本4.9，配置了initramdisk路径，编译出image，使用mkimage把image和dtb生成FIT文件，然后通过网络在板卡上启动linux

启动到是都正常，但是进入系统后，根文件系统下有的文件内容都是0，或者是别非法值，或者有些程序都不能使用，例如awk，一运行，就提示cannot execute binary file: Exec format error，也就是说不是可执行文件，貌似文件内容被改变了

请各位能否指点一二，这是什么原因？

wowo · 2017-07-19 22:13

ghostpipi 写道： 我自己做了一个根文件系统，使用命令“sudo find . | sudo cpio -o -Hnewc | sudo gzip -9 > ../initramfs_data.cpio.gz”压缩成cpio.gz，大小有58.6M

在linux内核里，版本4.9，配置了initramdisk路径，编译出image，使用mkimage把image和dtb生成FIT文件，然后通过网络在板卡上启动linux

请各位能否指点一二，这是什么原因？

我觉得可以从下面两个步骤去检查： 1. 怀疑文件坏了，就把initramfs_data.cpio.gz解出来，检查里面的文件是否正常，如果正常，可能是ramdisk的问题，进行第2步检查。 2. 系统启动后，检查对应的二进制文件，查看是否正常（可以和host中的文件对比）。如果正常（会正常吗？），有些奇怪；如果不正常（会不正常吗？），也挺奇怪（往memory上怀疑一下，嘴一个memory的读写测试）。

【微信群技术讨论】无效唤醒问题

Tue, 18 Jul 2017 17:23:04 +0800

本文是原「蜗窝讨论区」的历史存档（2017-07-18），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

linuxer · 2017-07-18 17:23

这是《linux内核设计与实现》中的一段代码，如果在while之后prepare_to_wait之前另一个线程做了wake_up，是不是有问题？ DEFINE_WAIT(wait);―――――――――――――1

add_wait_queue(q, &wait);―――――――――――2 while ( !condition) {――――――――――――――3 ------在这里，其他线程唤醒了这个task怎么办？？？ prepare_to_wait(&q, &wait, TASK_INTERRUPTIBLE);――――4 if (signal_pending(current))―――――――――5 进行信号处理 Schedule(;――――――――――――――――6 } finish_wait(&q, &wait);―――――――――――――7

过程分析： 1、定义一个wait queue entry 2、将该wait queue entry挂入等待队列（不修改进程状态） 3、检查一下条件如何？condition其实是和该task等待的事件相关的，如果condition等于true，那么说明事件发生了，那么进程没有必要进行睡眠，直接到finish_wait 4、修改进程状态，如果有需要，将该task重新挂入等待队列 5、如果进程状态是TASK_INTERRUPTIBLE，那么需要处理pengding的信号 6、发起调度，抢占当前的task的执行 7、唤醒之后会去3处重新判定condition，如果是true，那么调用finish_wait修改状态是TASK_RUNNING，并从等待队列中摘下该wait queue entry。

在条件检查（步骤3）和进程状态设定（步骤4）之间，如果其他cpu的进程调用wake up函数执行唤醒，那么这次唤醒其实是无效的唤醒，因为在随后的步骤4中，进程状态被该回成TASK_INTERRUPTIBLE并挂入等待队列，之后调用Schedule函数导致该task被无情的移出runqueue。而在prepare之后（步骤4）发生wake up是没有问题的，因为wakeup会把task置成TASK_RUNNING状态，这样schedule的时候就不会把该task移出runqueue，从而不会有问题。

【微信群问题讨论】如何检查内核stack是否被破坏？

Mon, 17 Jul 2017 11:44:51 +0800

本文是原「蜗窝讨论区」的历史存档（2017-07-17），来自版块「Linux kernel技术问答」，共 2 帖。讨论区已停止服务，此处仅供查阅。

linuxer · 2017-07-17 11:44

问题的提出：早上好，请问大侠们, kernel stack bottom是不是固定的. 最近我们发现有些case下面, stack爆了. 系统报告未定义指令的异常。我们怀疑是内核栈太大，覆盖了内核栈顶部的thread_info而导致的这个issue。我们的思路是：现在我得到了出问题的stack top pointer. 所以如果知道bottom的话, 就能算出是不是stack overflow。

整体思路：直面问题，不能通过加大内核栈来修复这个issue。主要是因为改stack牵扯太多，内存消耗也增多。如果正面攻击该issue，需要一些调试的手段，包括： 1、静态检查的方法。配置项是CONFIG_FRAME_WARN，这个选项可以让gcc在编译的时候做stack frame的检查。例如配置CONFIG_FRAME_WARN＝1024，那么在编译内核的时候，如果stack frame的大小大于1024，那么就会报警。通过这个方法可以知道哪个模块使用的stack memory比较大，他们就是潜在的引起statck overflow的怀疑对象。

2、系统运行时，动态跟踪栈的使用情况。配置项是CONFIG_STACK_TRACER。这个配置项用来跟踪最大的栈的使用场景，当配置了该选项之后，内核会自动跟踪内核栈的情况并将信息输出到/sys/kernel/debug/tracing/stack_trace中。

3、运行时检查stack overflow。配置项是CONFIG_CC_STACKPROTECTOR。这种方法是在函数的开始和结尾处增添代码，发现有stack overflow，则直接panic。

最后的解决方法： 1、压测机器会出现undefined instruction, 但是PC都没有跑飞, 发生kernel oops 2、日志分析发现：从log里面看栈帧已经爆掉了, 栈帧限制:stack limit = 0xecdf2238 目前的栈顶: sp : ecdf3fb0 3、加入CONFIG_FRAME_WARN,在编译kernel的时候会打印出warning: the frame size of 3128 bytes is larger than 1080 bytes 4、从warning打印里面可以看到函数的行数, 追查到此函数使用了一个很大的结构体 typedef struct { U32 u32Output[512]; U16 u16Input[512] }NG_St;

void NG_Func({ NG_St ng_st; xxxx return; } 5、把大数组转成指针, 用heap里面的memory存资料，问题解决。

【微信群问题讨论】系统级的timer的应用场景是怎样的？

Mon, 17 Jul 2017 11:07:15 +0800

本文是原「蜗窝讨论区」的历史存档（2017-07-17），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

linuxer · 2017-07-17 11:07

请教个问题：SoC（ARM base）里边除了core里边的local timer，都还会做几个系统级的timer，不知道群里边是否有人用过这些timer，一般的应用场景是什么样的？谢谢！

1、作为local timer的备用。当CPU core进入idle状态的时候，如果local timer 在某个C state 会被stop，software timer无法驱动（内核中的高精度timer和低精度timer都是基于local tick device的，local timer停摆，也就无法触发timer中断了），系统必须提供一个系统级别的timer来完成唤醒cpu的功能，这也就是broadcast tick device了。怎么选择broadcast tick device呢？能作为broadcast timer需要满足：1. cpuidle中不掉电，2.尽量支持oneshot mode，3.能产生event中断, 4 count 要尽量大. 如果系统中多个broadcast timer 可用，通过注册时给的rating值选择最佳的一个.

2、系统休眠中作为一个唤醒源使用。比如说系统休眠了，只有32k时钟了，cpu core timer一般就不能用了，可以用系统级别的 timer维持系统时钟，也可以用该timer中断来唤醒。需要注意的是，这个系统级别的timer需要谨慎的设计供电域和clock domain。

3、这些timer可以用于外部信号的，比如产生一个PWM脉冲，驱动红外或者其他外设。

4、可以做sched clock。

【微信群问题讨论】我想请教一下，有木有人实现或者了解过sparse file在文件系统层面里中是如何支持空洞的？

Mon, 17 Jul 2017 10:45:08 +0800

本文是原「蜗窝讨论区」的历史存档（2017-07-17），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

linuxer · 2017-07-17 10:45

技术讨论主题：我想请教一下，有木有人实现或者了解过sparse file在文件系统层面里中是如何支持空洞的？是如何用metadata追踪这些空洞的呢？

讨论的过程和结果如下：

1、怎么形成file hole呢？

形成空洞的方法是这样的：首先是创建一个空文件，然后用truncate或者seek命令强制将当前文件指针移动到一个地方，例如1G处，然后在1G处随便写一些数据，这样会形成一个1G的空洞。

2、用户层面读一个文件中的空洞会怎么样？

当对文件中的空洞进行读操作的时候，会返回全0。因此，你想要复制一个包含空洞文件的时候需要小心，由于空洞文件的读操作，会返回全0，在向新文件写的时候，实际上是执行了0写入，但是文件系统不可能去判断数据是否为非0，一旦有数据写入，就会真的写入物理磁盘，这时是不会形成空洞的。例如：cp命令会调ioctl（FIBMAP）下到内核，再到文件系统注册的bmap函数来确认，这个函数会告诉cp，到底是空洞，还是文件结束，如果是空洞，cp会有对应的处理，也会跳成空洞，scp没有这个跳过过程，会把你的空洞全部补0。

3、为何读空洞会返回0呢？

这和内核中的read_page操作相关。一般用户空间对文件发起read操作的时候，首先会在page cache中找，如果没有则发起磁盘操作。而在read_page函数会把磁盘上没有记录的block所对应的page中全部填充0。因此，读空洞就返回全0了。

4、如果写入文件时候空洞的部分不是一页的整数倍怎么处理呢？

文件系统是按照file block来组织数据的，因此，对于一个1M的空洞，如果多次跳着写，每次写一个字节a，如果将跨度包含多个块，中间的块仍然是洞，但那一个字节所在的块剩下的blovksize-1会被填充0。之所以如此是因为当我们对空洞写的时候，首先会找到对应的page，如果是空洞，那么其实的数据全0，然后写入这个字节a，然后系统在适当的时候，当把这个page写入磁盘，这时候page中有啥就写啥。

X-023-KERNEL-Linux pinctrl driver的移植

Fri, 14 Jul 2017 21:58:51 +0800

本文是“ linux内核中的GPIO系统之（4）：pinctrl驱动的理解和总结 ”的一个实例，结合” X Project ”的开发过程，介绍pinctrl driver的移植步骤，进而加深对pinctrl framework的理解。注1：本文后续的描述，kernel基于本站“ X Project ”所使用的kernel版本 [4] ，硬件基于 ” X Project ”所使用的“Bubbug

蜗窝微信群问题整理

Tue, 11 Jul 2017 19:00:50 +0800

蜗窝微信群开张了，这个群是为那些愿意慢下来，仔细研究内核技术、愿意为了搞清楚内核代码逻辑而废寝忘食的工程师准备的，在这个群里，大家讨论了一些技术问题，当然，也有一些问题没有解决和答案。鉴于微信群的特点，我还是把大家讨论的技术整理了一下，分享出来，希望能够对其他工程师有所帮助。

CMA模块学习笔记

Wed, 28 Jun 2017 18:29:36 +0800

本文是近期学习CMA模块的一个学习笔记，方便日后遗忘的时候，回来查询以便迅速恢复上下文。学习的基本方法是这样的：一开始，我自己先提出了若干的问题，然后带着这些问题查看网上的资料，代码，最后整理形成这样以问题为导向的index，顺便也向笨叔叔致敬。笨叔叔写了一本书叫做《奔跑吧Linux内核》，采用了问答的方式描述了4.x Linux内核中的进程管理、内存管理，同步和中断子系统。7月将和大家见面，敬

linux内核中的GPIO系统之（4）：pinctrl驱动的理解和总结

Tue, 27 Jun 2017 22:30:11 +0800

本站之前的三篇文章 [1][2][3] 介绍了pin controller（对应的pin controller subsystem）、gpio controller（对应的GPIO subsystem）有关的基本概念，包括pin multiplexing、pin configuration等等。本文将基于这些文章，单纯地从pin controller driver的角度（屏蔽掉pinctrl co

为什么会有文件系统(二)

Tue, 27 Jun 2017 21:06:45 +0800

距我将全套盗墓笔记成功保存在8MB空间里已经过去了19天58分钟32秒，我渐渐发觉更高、更快、更强的绝不限于奥运精神，也充分体现了人类贪婪的本质，无尽的需求催生出这光怪陆离的大千世界。就在今天下午，我得到一个通知，要么继续使用连续的存储空间，但是只能有4MB，要么去使用不连续的存储空间，总量可以仍然是8MB，那一刻，我的内心反而是平静的，因为我知道，这就是现实，一个不够优秀的系统是无法满足各种刁

DMA buffer及内存映射相关

Mon, 19 Jun 2017 19:01:25 +0800

本文是原「蜗窝讨论区」的历史存档（2017-06-19），来自版块「Linux kernel技术问答」，共 7 帖。讨论区已停止服务，此处仅供查阅。

wpeng_35097 · 2017-06-19 19:01

linuxer好，最近在学习V4L2时产生一些疑问，麻烦@linuxer帮忙点拨以下理解是否正确？ 1、在驱动实现的mmap接口函数中，可以使用dma_mmap_attrs把外部sensor申请的DMA缓冲区mmap到用户空间，此时之前申请DMA缓冲区的函数必须是dma_alloc_attrs，mmap之后相当于有两块虚拟地址对应了同一块物理地址。 2、dma_alloc_attrs和dma_alloc_coherent在用法上有什么区分吗？适用场景？ 3、我看到像一些fb驱动实现的mmap调用的都是remap_pfn_range，网上说可以使用它来映射内存中的保留页、设备I/O、framebuffer、camera等内存。那是不是可以这样理解：remap_pfn_range作用是用来将物理地址映射到用户空间，ioremap作用是用来将物理地址映射到内核空间。 4、在videobuf2-dma-config.c中有dma-buf的实现，大概是一个供用户空间或其他设备驱动共享DMA buffer的技术，虽然使用步骤很简单（调用几个API）但我这里还是不太理解：假设1中的想法正确的话，那它和dma_mmap_attrs映射DMA缓冲区到用户空间的手段有什么区别吗，感觉dma_mmap_attrs也有“共享”的意思，ISP负责向DMA buffer放数据，用户空间负责从DMA buffer取数据。 5、ISP各个子模块间流通数据需要内存额外开辟buffer中转吗（比如preview、resizer、H3A之间），还是它们有相应的硬件缓冲区，只需要将最终处理完的数据放到内存buffer就OK了 6、像camera、framebuffer用的大内存都来自保留内存吗（mem=size），感觉这种方式比较粗放、浪费，有其它更好的技术吗？

以上问题麻烦@linuxer前辈解惑，等您不帮时回复即可，不胜感激！

linuxer · 2017-06-20 19:26

过两天再回复你

wpeng_35097 · 2017-06-20 19:47

感谢前辈关注，问题问的有些多还望@linuxer见谅，如果有些问题您觉得没什么价值，那就pass掉可以啦

linuxer · 2017-06-22 09:29

技术交流，不需要这么客气。

1、是的，两段虚拟地址mapping到了一个物理地址段。dma_alloc_attrs会返回一个虚拟地址，内核可以使用这个地址访问DMA buffer，dma_alloc_attrs同时会返回dma_handle这个bus address，用于外设访问DMA Buffer。dma_mmap_attrs会针对DMA buffer创建第二mapping，这次是mapping到userspace，方便进程用户空间直接访问DMA Buffer. 2、dma_alloc_coherent其实还有很多变种，例如dma_alloc_noncoherent, dma_alloc_writecombine等，因此为了统一起来，新内核提供了一个统一的dma_alloc_attrs函数来替代旧的dma_alloc_*系列函数接口。具体场景很复杂，和cpu arch、cpu和外设如何互联，cpu和memory如何互联相关，不是一句话可以讲清楚的，不过，对于普通驱动，使用dma_alloc_coherent分配coherent DMA buffer是最简单的，不需要考虑cpu和device在操作DMA Buffer上的同步。 3、你说的也对，但是这里可以补充一些信息。remap_pfn_range是把一个page frame（有对应的struct page与之对应，也就有pfn，page frame number）mapping到userspace的虚拟地址空间上去（vma）。ioremap一般不用于mapping page frame，它一般用来mapping外设的MMIO（寄存器地址空间）。 4、我对V4L2没有研究，不过我觉得videobuf2-dma-contig.c这个管理dma buffer的模块，最终应该还是通过dma_mmap_attrs把DMA buffer mapping到用户空间的，只不过它会附加一些管理dma buffer的功能。BTW，我猜的，仅供参考。 5、这个不是非常了解，不好回答。 6、想要大块的连续内存，可以在内核管理模块之外开辟reserved memory，这样驱动可以永远可以bring up，不会因为memory分配导致问题，不过，在不加载驱动的时候，那些保存的内存的确是有些浪费，也许CMA可以解决这个问题。

wpeng_35097 · 2017-06-24 22:16

多谢linuxer细心解答，这样就明白多了。另外，“DMA controller做数据搬运期间，CPU可以并发地执行其他任务”像这样的描述一直不是很理解，DMA在占用总线传输数据时，CPU怎么还能并发执行呢？

linuxer · 2017-06-26 19:27

你这个问题其实和CPU系统架构相关的，如果整个系统的组件（cpu、dma controller、各种外设）都是在一条总线上的话，那么，当DAM发起bus transaction的时候，CPU已经不能发起第二个bus transaction，对memory进行访问了。不过现代的计算机系统的架构都不是那么的简单，各个cpu core有各自的cache或者共享的cache，DMA controller通过互连器件和cpu core进行互联，因此，各个cpu core以及DMA controller都是在不同的总线上，因此，虽然DMA占用了总线，并不影响cpu的并发。

INFO: rcu_preempt detected stalls on CPUs/tasks: { 1} (detected b y 0,

Wed, 07 Jun 2017 18:08:17 +0800

本文是原「蜗窝讨论区」的历史存档（2017-06-07），来自版块「Linux kernel技术问答」，共 4 帖。讨论区已停止服务，此处仅供查阅。

darren · 2017-06-07 18:08

那个炬芯的S500板子做压力测试，跑着内核突然报错，然后系统挂死了。不过谁有遇到了？不太懂这个RCU。网上说是

You probably have a real time application that is consuming all cpu (some bad implementation) and because of its realtime scheduling priority the system doesn't have enough resources available for other tasks.

I suggests that you remove realtime priority from your applications and check which one is consuming a lot of CPU and, after correcting the problem, puts it back to realtime priority


[== Undefined ==]
[ 2453.419146] INFO: rcu_preempt detected stalls on CPUs/tasks: { 1} (detected b
y 0, t=60017 jiffies, g=3373, c=3372, q=1612)
[ 2453.430209] [<c0015b54>] (unwind_backtrace+0x0/0x138) from [<c001306c>] (show
_stack+0x24/0x2c)
[ 2453.438799] [<c001306c>] (show_stack+0x24/0x2c) from [<c00148c4>] (smp_send_a
ll_cpu_backtrace+0x58/0xc4)
[ 2453.448261] [<c00148c4>] (smp_send_all_cpu_backtrace+0x58/0xc4) from [<c00a48
7c>] (rcu_check_callbacks+0x664/0x7e4)
[ 2453.458681] [<c00a487c>] (rcu_check_callbacks+0x664/0x7e4) from [<c003b7c8>] 
(update_process_times+0x3c/0x68)
[ 2453.468577] [<c003b7c8>] (update_process_times+0x3c/0x68) from [<c007c1b8>] (
tick_sched_timer+0x44/0x74)
[ 2453.478036] [<c007c1b8>] (tick_sched_timer+0x44/0x74) from [<c0050530>] (__ru
n_hrtimer+0x7c/0x278)
[ 2453.486972] [<c0050530>] (__run_hrtimer+0x7c/0x278) from [<c0051214>] (hrtime
r_interrupt+0x10c/0x2a4)
[ 2453.496166] [<c0051214>] (hrtimer_interrupt+0x10c/0x2a4) from [<c00152d4>] (t
wd_handler+0x2c/0x40)
[ 2453.505103] [<c00152d4>] (twd_handler+0x2c/0x40) from [<c009ea4c>] (handle_pe
rcpu_devid_irq+0x78/0x17c)
[ 2453.514478] [<c009ea4c>] (handle_percpu_devid_irq+0x78/0x17c) from [<c009b24c
>] (generic_handle_irq+0x24/0x38)
[ 2453.524458] [<c009b24c>] (generic_handle_irq+0x24/0x38) from [<c000fbf4>] (ha
ndle_IRQ+0x38/0x94)
[ 2453.533219] [<c000fbf4>] (handle_IRQ+0x38/0x94) from [<c00085e0>] (gic_handle
_irq+0x28/0x5c)
[ 2453.541633] [<c00085e0>] (gic_handle_irq+0x28/0x5c) from [<c000ef40>] (__irq_
svc+0x40/0x70)
[ 2453.549956] Exception stack(0xe0a5de10 to 0xe0a5de58)
[ 2453.554987] de00: 00000001 000

linux 内存管理逆向映射的问题

Mon, 29 May 2017 20:29:31 +0800

本文是原「蜗窝讨论区」的历史存档（2017-05-29），来自版块「Linux kernel技术问答」，共 2 帖。讨论区已停止服务，此处仅供查阅。

jack · 2017-05-29 20:29

请问，page结构中只有一个index，如何定位所有的vma中的虚拟页面的？？并不能保证page页框对应的虚拟页框在所有的vma中的偏移都是一致的吧？？还请老师们指点一二！！谢谢

wpch315 · 2017-06-08 14:35

可以看看这篇文章 (http://www.cnblogs.com/tolimit/p/5398552.html)

请教一个关于电源管理问题

Sat, 27 May 2017 14:44:02 +0800

本文是原「蜗窝讨论区」的历史存档（2017-05-27），来自版块「Linux kernel技术问答」，共 3 帖。讨论区已停止服务，此处仅供查阅。

zwskywalker · 2017-05-27 14:44

hi wowo，有一个电源管理的问题想请假您，linux系统在执行suspend to ram的流程时，会将所有的设备进入suspend状态，如果被唤醒源唤醒时所有的设备会resume。但是我们有一个4G模块，通过usb接口和mcu相连，如果usb进入suspend 4G模块也会进入suspend状态，但是系统唤醒的时候usb resume，4G模块也跟着resume了，此时我们并不想4G模块也跟着resume，因为想降低功耗，同时功能上也用不到4G模块。问题就是在系统唤醒的时候能否不让usb也resume，有什么好的方案吗？我现在的尝试时不让usb controller resume，但是会引起其他usb相关模块报错。

qdzhaozx · 2017-06-09 16:43

硬件上弄个pin，接在4G模块的使能信号上，不就可以了吗？

Hisenberg · 2017-06-28 15:16

我现在的尝试时不让usb controller resume，但是会引起其他usb相关模块报错。 ==> 所以这个controller还有别的usb设备在使用吗？你的4G模块是通过hub接到root port上去的？

【任务5】在linux kernel中支持MMC的读写

Sun, 21 May 2017 21:46:13 +0800

本文是原「蜗窝讨论区」的历史存档（2017-05-21），来自版块「X Project」，共 1 帖。讨论区已停止服务，此处仅供查阅。

wowo · 2017-05-21 21:46

任务说明通过“【任务4】启动Linux kernel到命令行”，我们已经可以通过USB boot的方式，将linux kernel启动到命令行。在这个基础上，可以进行后续的开发和实验了。本任务作为“X project”的第5个任务，比较简单明了：通过编写MMC/SD驱动，在kernel中支持MMC的读写。

不过呢，看似简单，背后确涉及很多的基础framework，例如gpio、pinmux、clock、power domain、reset、dma engine、等等。于是，本任务的目的浮现出来了：基于本站博文中各个framework的分析文章，借助mmc/sd driver的开发过程，学习并掌握嵌入式linux中那些基础驱动的开发方法。

目标一经明确，任务的步骤也可以确定了，大致如下：

基于本站“(/sort/gpio_subsystem)”的分析文章，移植并开发GPIO驱动和pinmux驱动[/*]
基于本站“(/tag/clock)”的分析文章，移植并开发clock驱动[/*]
基于本站“(/pm_subsystem/pm_domain_overview.html)”有关的分析文章，移植并开发power domain驱动[/*]
在本站的linux kernel的分析文章中，补充linux kernel reset framework有关的分析，然后移植并开发reset驱动[/*]
基于本站“(/tag/dma)”的分析文章，移植并开发dma controller驱动[/*]
基于本站“(/tag/mmc)”有关的分析文章，移植并开发mmc/sd controller驱动，以及相应的块设备驱动[/*]
最后，作为任务完结的验收，介绍在linux命令行进行mmc读写测试的方法[/*]
其它未尽事项，后面需要的话再补充[/*]
涉及的知识点该任务主要涉及linux kernel基础驱动的移植和开发，通过这个任务，大家应该可以掌握linux驱动开发的基本方法。
完成任务的思路思路的话，没什么大道理，直接上去怼就行了。另外，还是老话，感兴趣的同学可以认领任务
任务总结 TODO

Linux DMA Engine framework(3)_dma controller驱动

Thu, 18 May 2017 21:56:34 +0800

本文将从provider的角度，介绍怎样在linux kernel dmaengine的框架下，编写dma controller驱动。

Linux的时钟

Wed, 17 May 2017 18:55:56 +0800

时钟或者钟表（clock）是一种计时工具，每个人都至少有一块，可能在你的手机里，也可能佩戴在你的手腕上。如果Linux也是一个普通人的话，那么她的手腕上应该有十几块手表，包括：CLOCK_REALTIME、CLOCK_MONOTONIC、CLOCK_PROCESS_CPUTIME_ID、CLOCK_THREAD_CPUTIME_ID、CLOCK_MONOTONIC_RAW、CLOCK_REALTI

Linux DMA Engine framework(2)_功能介绍及解接口分析

Tue, 02 May 2017 22:47:41 +0800

从我们的直观感受来说，DMA并不是一个复杂的东西，要做的事情也很单纯直白。因此Linux kernel对它的抽象和实现，也应该简洁、易懂才是。不过现实却不甚乐观（个人感觉），Linux kernel dmaengine framework的实现，真有点晦涩的感觉。为什么会这样呢？如果一个软件模块比较复杂、晦涩，要么是设计者的功力不够，要么是需求使然。当然，我们不敢对Linux kernel的那些

系统休眠（System Suspend）和设备中断处理

Fri, 21 Apr 2017 12:02:24 +0800

本文主要描述系统休眠过程是如何和中断子系统交互的，全文的结构保持和内核文档中的power/suspend-and-interrupts.txt一致，当然，本质上也可以说这份文档是对suspend-and-interrupts.txt的翻译。

一直uboot到s3c6410上去，build出错时连接出错

Sun, 09 Apr 2017 21:21:06 +0800

本文是原「蜗窝讨论区」的历史存档（2017-04-09），来自版块「X Project」，共 2 帖。讨论区已停止服务，此处仅供查阅。

jansion · 2017-04-09 21:21

一直uboot到s3c6410上去，buildbuild出错时连接出错我按照您的教程去做，但是始终出现这个错误，两天了都没有解决这个问题，望大神指点一下,谢谢！输出log是：

LD net/built-in.o CC examples/standalone/hello_world.o CC examples/standalone/stubs.o LD examples/standalone/libstubs.o LD examples/standalone/hello_world OBJCOPY examples/standalone/hello_world.srec OBJCOPY examples/standalone/hello_world.bin LD u-boot arm-none-linux-gnueabi-ld: BFD (Sourcery CodeBench Lite 2014.05-29) 2.24.51.20140217 assertion fail /scratch/maciej/arm-linux-2014.05-rel/obj/binutils-src-2014.05-29-arm-none-linux-gnueabi-i686-pc-linux-gnu/bfd/elf32-arm.c:7781 arm-none-linux-gnueabi-ld: error: required section '.rel.plt' not found in the linker script arm-none-linux-gnueabi-ld: final link failed: Invalid operation make: *** Error 1 sugar@sugar-VirtualBox:/mnt/wowo/xproject/uboot2016/u-boot-2016.07$

搞两天了请指点一下！

wowo · 2017-04-10 09:08

jansion 写道： 一直uboot到s3c6410上去，buildbuild出错时连接出错我按照您的教程去做，但是始终出现这个错误，两天了都没有解决这个问题，望大神指点一下,谢谢！输出log是：

搞两天了请指点一下！

如果其它的配置没有问题的话，根目录clean一下试试： $ make clean $ make mrproper

Linux DMA Engine framework(1)_概述

Thu, 30 Mar 2017 22:01:37 +0800

前面文章介绍“ Linux MMC framework ”的时候，涉及到了MMC数据传输，进而不可避免地遭遇了DMA(Direct Memory Access)。因而，择日不如撞日，就开几篇文章介绍Linux的DMA Engine framework吧。本文是DMA Engine framework分析文章的第一篇，主要介绍DMA controller的概念、术语（从硬件的角度，大部分翻译自ke

蓝牙协议分析(10)_BLE安全机制之LE Encryption

Tue, 28 Mar 2017 11:52:27 +0800

前面文章介绍了两种BLE的安全机制：白名单 [4] 和LL privacy [3] 。说实话，在这危机四伏的年代，这两种“捂着脸讲话（其它人不知道是谁在讲话，因而不能插话、不能假传圣旨，但讲话的内容却听得一清二楚）”的方法，实在是小儿科。对于物联网的应用场景来说，要做到安全，就必须对传输的数据进行加密，这就是LE Encryption要完成的事情（当然，只针对面向连接的数据），具体请参考本文的介绍

关机失败

Mon, 27 Mar 2017 17:57:09 +0800

本文是原「蜗窝讨论区」的历史存档（2017-03-27），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

tz_999 · 2017-03-27 17:57

关机过程失败,log以下： [32791.280028] ------------[ cut here ]------------

[32791.280092] WARNING: CPU: 0 PID: 917 at /apps_proc/oe-core/build/tmp-glibc/work-shared/mdm9607-perf/kernel-source/include/linux/kref.h:47 kobject_get+0x4c/0x64(

[32791.280113] Modules linked in: nf_nat_rtsp(O) nf_conntrack_rtsp(O) shortcut_fe_cm(O) shortcut_fe_ipv6(O) shortcut_fe(O) embms_kernel(O)

[32791.280180] CPU: 0 PID: 917 Comm: key_shutdown Tainted: G W O 3.18.20 #1

[32791.280236] [<c00139a4>] (unwind_backtrace) from [<c0011a68>] (show_stack+0x10/0x14)

[32791.280281] [<c0011a68>] (show_stack) from [<c001d1d8>] (warn_slowpath_common+0x68/0x88)

[32791.280320] [<c001d1d8>] (warn_slowpath_common) from [<c001d2d8>] (warn_slowpath_null+0x18/0x20)

[32791.280359] [<c001d2d8>] (warn_slowpath_null) from [<c01b2290>] (kobject_get+0x4c/0x64)

[32791.280404] [<c01b2290>] (kobject_get) from [<c027a4a0>] (get_device+0x14/0x1c)

[32791.280449] [<c027a4a0>] (get_device) from [<c027c238>] (device_shutdown+0x50/0x1bc)

[32791.280490] [<c027c238>] (device_shutdown) from [<c00372c0>] (kernel_power_off+0x2c/0x70)

[32791.280529] [<c00372c0>] (kernel_power_off) from [<c00374b8>] (SyS_reboot+0x134/0x1d8)

[32791.280566] [<c00374b8>] (SyS_reboot) from [<c000e040>] (ret_fast_syscall+0x0/0x38)

[32791.280588] ---[ end trace e830ea8eb6b90c74 ]---

[32791.280618] Unable to handle kernel NULL pointer dereference at virtual address 00000000

[32791.280636] pgd = c6994000

[32791.280652] [00000000] *pgd=00000000

[32791.280678] Internal error: Oops: 805 [#1] PREEMPT ARM

[32791.280695] Modules linked in: nf_nat_rtsp(O) nf_conntrack_rtsp(O) shortcut_fe_cm(O) shortcut_fe_ipv6(O) shortcut_fe(O) embms_kernel(O)

[32791.280752] CPU: 0 PID: 917 Comm: key_shutdown Tainted: G W O 3.18.20 #1

[32791.280775] task: c1e6e640 ti: c70d6000 task.ti: c70d6000

[32791.280803] PC is at __mutex_lock_slowpath+0x6c/0x190

[32791.280830] LR is at device_shutdown+0xa8/0x1bc

[32791.280856] pc : [<c05ec094>] lr : [<c027c290>] psr: a0060013

[32791.280856] sp : c70d7e20 ip : 00000000 fp : 00000002

[32791.280883] r10: ffffffff r9 : c1e6e640 r8 : c1054638

[32791.280905] r7 : c08a4008 r6 : c70d6000 r5 : c70d6020 r4 : c1054634

[32791.280926] r3 : 00000000 r2 : 00000002 r1 : 00000000 r0 : c1054634

[32791.280949] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user

[32791.280973] Control: 10c53c7d Table: 86994059 DAC: 00000015

[32791.280995] Process key_led (pid: 917, stack limit = 0xc70d6230)

[32791.281016] Stack: (0xc70d7e20 to 0xc70d8000)

[32791.281052] 7e20: c1054638 00000000 c1054608 75061265 00000000 c105460c c70d6018 c1054600

[32791.281087] 7e40: 00000000 c08fcd60 c0983bd4 c1054634 b6d97f9c c027c290 4321fedc 4321fedc

[32791.281121] 7e60: c08a4008 c08afcd4 00000002 fee1dead 00000000 c00372c0 cdef0123 c00374b8

[32791.281155] 7e80: 00000800 00000000 0000c350 00000000 60060013 c70d6000 c08a4008 00000090

[32791.281189] 7ea0: d08d653b 00001dd2 00000000 c70d7f20 c70d6000 c70d6028 00000001 75061265

[32791.281224] 7ec0: b6d97c1c c70d7f20 c70d7f20 c70d6000 c70d6028 75061265 c091f21c b6f780fc

[32791.281259] 7ee0: 0000080f ffffffff c08a4008 c08ad7ac b6f96558 c70d7fb0 b6d97d7c c00084c8

[32791.281293] 7f00: c08a4008 00000001 0000c350 c0059ca0 0000c350 00000000 3b9b8d50 00000000

[32791.281327] 7f20: c70d7f20 c08b2388 00000000 00000000 d08d653b 00001dd2 d08ca1eb 00001dd2

[32791.281361] 7f40: c0058c08 c08b1cf8 00000000 00000000 00000000 c0029510 c08a4008 75061265

[32791.281395] 7f60: 00000002 c08a4008 b6d97c1c b6d97c24 000000a2 c000e1c4 c70d6000 00000000

[32791.281429] 7f80: b6d97f9c 75061265 00000000 7f5940c0 7f5a7dac b6f95f10 00000058 c000e1c4

[32791.281464] 7fa0: c70d6000 c000e040 7f5940c0 7f5a7dac fee1dead 28121969 4321fedc 00000002

[32791.281498] 7fc0: 7f5940c0 7f5a7dac b6f95f10 00000058 00000002 7f58f2f0 7f58f2f0 b6d97f9c

[32791.281533] 7fe0: b6ee3410 b6d97dcc 7f55c890 b6ee3430 60060010 fee1dead 91144202 a1a0e25a

[32791.281577] [<c05ec094>] (__mutex_lock_slowpath) from [<c027c290>] (device_shutdown+0xa8/0x1bc)

[32791.281617] [<c027c290>] (device_shutdown) from [<c00372c0>] (kernel_power_off+0x2c/0x70)

[32791.281653] [<c00372c0>] (kernel_power_off) from [<c00374b8>] (SyS_reboot+0x134/0x1d8)

[32791.281689] [<c00374b8>] (SyS_reboot) from [<c000e040>] (ret_fast_syscall+0x0/0x38)

[32791.281722] Code: e58d8000 e3a0b002 e58d3004 e3c5603f (e583d000)

[32791.281744] ---[ end trace e830ea8eb6b90c75 ]---

[32791.281770] note: key_shutdown[917] exited with preempt_count 2

================================= 从log来看是不是，还有设备的lock没free掉啊？

关于BLE中GAP,GATT和SDP的困惑

Mon, 27 Mar 2017 16:41:12 +0800

本文是原「蜗窝讨论区」的历史存档（2017-03-27），来自版块「其它」，共 2 帖。讨论区已停止服务，此处仅供查阅。

sfc0907 · 2017-03-27 16:41

个人理解，GAP是用于发现并配对别的设备的,而SDP是用来发现对端支持哪些功能。我认为SDP应该在GAP之上，在GATT下，但是从BLE核心文档上看起来他们是平行的。那么问题来了：什么情况下会去调用GATT和SDP呢？求大神不吝赐教，先行谢过！

wowo · 2017-04-10 08:59

sfc0907 写道： 个人理解，GAP是用于发现并配对别的设备的,而SDP是用来发现对端支持哪些功能。我认为SDP应该在GAP之上，在GATT下，但是从BLE核心文档上看起来他们是平行的。那么问题来了：什么情况下会去调用GATT和SDP呢？求大神不吝赐教，先行谢过！

BLE没有SDP的概念。

如何学习一个内核子系统

Sat, 25 Mar 2017 22:54:01 +0800

本文是原「蜗窝讨论区」的历史存档（2017-03-25），来自版块「灌水区」，共 2 帖。讨论区已停止服务，此处仅供查阅。

Terryjourneys · 2017-03-25 22:54

最近看了wowo同学的 “Linux I2C framework(1)_概述“这篇文章，感觉提纲挈领，也很清晰。但是作为读者一般只会看到分析的结果和产出，却很难了解作者对整个子系统分析总结的历程，想在这里请教一个wowo怎样学习一个内核子系统，大家有很好的学习方法和经验也帮忙指教下。有如下2个问题： 1. 一般框架性的文章都是在对子系统理解比较深刻的时候提炼出的，你是在分析完整个I2C子系统才写这篇概述文章呢？还是在深入分析之前先给出呢？ 2. 如何学习一个子系统，大概遵循怎样的步骤呢？如：先去网上搜索一些概述性的文章，从总体上得出子系统的框架？->从硬件上了解工作流程->结合硬件流程分析软件流程，各种实体，各种API?

wowo · 2017-03-27 11:37

Terryjourneys 写道： 最近看了wowo同学的 “Linux I2C framework(1)_概述“这篇文章，感觉提纲挈领，也很清晰。但是作为读者一般只会看到分析的结果和产出，却很难了解作者对整个子系统分析总结的历程，想在这里请教一个wowo怎样学习一个内核子系统，大家有很好的学习方法和经验也帮忙指教下。有如下2个问题： 1. 一般框架性的文章都是在对子系统理解比较深刻的时候提炼出的，你是在分析完整个I2C子系统才写这篇概述文章呢？还是在深入分析之前先给出呢？ 2. 如何学习一个子系统，大概遵循怎样的步骤呢？如：先去网上搜索一些概述性的文章，从总体上得出子系统的框架？->从硬件上了解工作流程->结合硬件流程分析软件流程，各种实体，各种API?

觉得这个问题不好回答啊…… 我自己的感受是：对框架的理解不是一蹴而就的，但如果理解了某一个框架，所有的框架都是一个样子了，无论是Linux、Windows还是RTOS，无论是硬件、软件还是其它什么。至于框架是怎么提炼出来的，肯定不是一开始就知道，而是做过了很多东西，慢慢学习、理解、抽象出来的。最后，所谓的框架，无非就是软件工程的经典思想，抽象、封装、屏蔽细节、等等。多看、多做、多想，我能说的，也就是这么多了。

关于workqueue问题

Thu, 23 Mar 2017 19:22:03 +0800

本文是原「蜗窝讨论区」的历史存档（2017-03-23），来自版块「Linux kernel技术问答」，共 3 帖。讨论区已停止服务，此处仅供查阅。

疯狂的锤头100 · 2017-03-23 19:22

大家好，现在遇到一个问题，是与workqueue相关的首先我这边定义了一个workqueue 之后再调用的时候，我调用了两次发现第一调用的地方生效了第二次调用的地方没能生效

详细点就是在一个中断函数中 irq_handler（）{ queue_delayed_work(work_q,&work, msecs_to_jiffies(5)); //这个执行了 queue_delayed_work(work_q,&work, msecs_to_jiffies(5000)); //这个没有执行 }

请大神们帮看看是什么原因

谢谢

linuxer · 2017-03-24 08:53

内核相关代码如下： bool queue_delayed_work_on(int cpu, struct workqueue_struct wq, struct delayed_work dwork, unsigned long delay) { struct work_struct *work = &dwork->work; bool ret = false; unsigned long flags;

/* read the comment in __queue_work( */
local_irq_save(flags);
if (!test_and_set_bit(WORK_STRUCT_PENDING_BIT, work_data_bits(work))) {
__queue_delayed_work(cpu, wq, dwork, delay);
ret = true;
}
local_irq_restore(flags);
return ret;

}

work数据结构中的data 成员，其WORK_STRUCT_PENDING_BIT比特标识了该work是否处于pending状态，pending状态的work只会挂入一次，因此，第二次queue work是不成功的。

在SMP boot secondary cores的时候，CPU如何知道存放secondary_startup入口的寄存器地址？

Wed, 22 Mar 2017 12:03:50 +0800

本文是原「蜗窝讨论区」的历史存档（2017-03-22），来自版块「Linux kernel技术问答」，共 3 帖。讨论区已停止服务，此处仅供查阅。

Robin · 2017-03-22 12:03

Hi Wowo，看了很多你们的文章，受益匪浅，在bring up多核SoC时，有一点没有弄清楚，以Vexpress为例，在platsmp.c中： static void __init vexpress_smp_dt_prepare_cpus(unsigned int max_cpus) { struct device_node *scu = of_find_matching_node(NULL, vexpress_smp_dt_scu_match);

if (scu)
 scu_enable(of_iomap(scu, 0));
/*

Write the address of secondary startup into the
system-wide flags register. The boot monitor waits
until it receives a soft interrupt, and then the
secondary CPU branches to this address.
*/
vexpress_flags_set(virt_to_phys(versatile_secondary_startup)); //将versatile_secondary_startup地址写到system-wide flags register

} 那么在secondary core收到IPI中断后执行wake up时，如何知道要去system flags这个寄存器去取呢？这是SoC 设计决定的吗？

中断上下文中调度会怎样？

Mon, 20 Mar 2017 19:08:14 +0800

每一个Linux驱动工程师都知道这样一个准则：在中断上下文中不能睡眠。但是为什么interrupt context中不能调用导致睡眠的kernel API呢？如果驱动这么做会导致什么样的后果呢？这就是本文探讨的主题。为了理解这个主题，我们设计了一些非常简单的驱动程序和用户空间的程序，实际做实验观察实验效果，最后给出了结果和分析。

Linux调度器：进程优先级

Tue, 14 Mar 2017 18:46:06 +0800

本文主要描述的是进程优先级这个概念。从用户空间来看，进程优先级就是nice value和scheduling priority，对应到内核，有静态优先级、realtime优先级、归一化优先级和动态优先级等概念，我们希望能在第二章将这些相关的概念描述清楚。为了加深理解，在第三章我们给出了几个典型数据流过程的分析。

玩转BLE(3)_使用微信蓝牙精简协议伪造记步数据

Sat, 11 Mar 2017 11:42:14 +0800

在物联网时代，有一个问题肯定会让人头疼（现在已经初露端倪了）：物联网中的IOT设备有两个主要特点： 1）简单小巧（不具备复杂的人机交互接口，需要手机等终端设备辅助完成配置、控制等功能）。 2）数量和种类繁多（消费者面对的可是数量众多的不同厂家、不同类型的设备）。基于这两个特点，手机等终端设备一般通过APP（或APK）对IOT设备进行控制，不同厂家的不同设备，通常需要不同的APP/APK。于是出

Linux调度器：用户空间接口

Fri, 10 Mar 2017 18:50:38 +0800

Linux调度器神秘而充满诱惑，每个Linux工程师都想深入其内部一探究竟。不过中国有一句古话叫做“相由心生”，一个模块精巧的内部逻辑（也就是所谓的“心”）其外延就是简洁而优雅的接口（我称之为“相”）。通过外部接口的定义，其实我们也可以收获百分之六七十的该模块的内部信息。因此，本文主要描述Linux调度器开放给用户空间的接口。

Linux MMC framework(2)_host controller driver

Wed, 08 Mar 2017 21:33:47 +0800

本文是Linux MMC framework的第二篇，将从驱动工程师的角度，介绍MMC host controller driver有关的知识，学习并掌握如何在MMC framework的框架下，编写MMC控制器的驱动程序。同时，通过本篇文章，我们会进一步的理解MMC、SD、SDIO等有关的基础知识。

UART 的平台设备驱动

Wed, 08 Mar 2017 10:33:33 +0800

本文是原「蜗窝讨论区」的历史存档（2017-03-08），来自版块「Linux kernel技术问答」，共 2 帖。讨论区已停止服务，此处仅供查阅。

Sky@Learn · 2017-03-08 10:33

问题：现在需要将使用UART，利用linux自带的serial的驱动框架实现，但是找不到相关资料，在内核源码也找不到相关例子，所以想请教下实现的思路和相关的资料。

刚开始学linux驱动，望各位多多指教！！！

wowo · 2017-03-13 22:17

建议可以参考本站的x project，一步步的做（没有捷径的）。

内核代码 __nosavedata 的作用是什么？

Tue, 07 Mar 2017 17:25:26 +0800

本文是原「蜗窝讨论区」的历史存档（2017-03-07），来自版块「Linux kernel技术问答」，共 2 帖。讨论区已停止服务，此处仅供查阅。

calm.xia · 2017-03-07 17:25

在内核代码中看到很多变量后面加了个__nosavedata属性，请问有什么作用？（百度搜了好久没搜到，来求助wowo了）比如：enum boot_mode_t g_boot_mode __nosavedata = UNKNOWN_BOOT;

wowo · 2017-03-08 08:49

calm.xia 写道： 在内核代码中看到很多变量后面加了个__nosavedata属性，请问有什么作用？（百度搜了好久没搜到，来求助wowo了）比如：enum boot_mode_t g_boot_mode __nosavedata = UNKNOWN_BOOT;

这些变量放到了一个特殊的section中了，看kernel的注释就明白什么意思了：


[== Undefined ==]
"include/linux/init.h"
/* Data marked not to be saved by software suspend */
#define __nosavedata __section(.data..nosave)

arm内核升级后，使用原来OK的dtb文件为什么起不来

Sun, 05 Mar 2017 17:12:49 +0800

本文是原「蜗窝讨论区」的历史存档（2017-03-05），来自版块「Linux kernel技术问答」，共 2 帖。讨论区已停止服务，此处仅供查阅。

pentagon · 2017-03-05 17:12

arm内核升级后，使用原来OK的dtb文件为什么起不来， dtb文件不是正确的么，原来的内核都可以啊，升级内核了这dtb文件就不对了么?

wowo · 2017-03-06 13:54

pentagon 写道： arm内核升级后，使用原来OK的dtb文件为什么起不来， dtb文件不是正确的么，原来的内核都可以啊，升级内核了这dtb文件就不对了么?

这也正常，查一下为什么不可用了（有source code，很好办）。

eMMC 原理 4 ：总线协议

Wed, 01 Mar 2017 22:48:38 +0800

本文将详细介绍 eMMC 总线协议，包括接口的定义、不同速率模式选择、数据读写过程的交互、数据的校验，基于 Command & Response 的通信模型等内容。

Debian8 内核升级实验

Mon, 27 Feb 2017 19:28:35 +0800

一直以来，我都是在使用一台ThinkPad T450 ＋ Debian 8的机器来研究内核，Debian 8上缺省的内核版本是3.16，为什么不把内核升级到4.4.6版本上呢？反正现在蜗窝主要分析的也是这个版本的内核？本文主要记录了整个升级过程，方便后续重复使用，哈哈，也许哪天要升级到8.8版本的内核呢，到时候可以把这份文档调出来轻松升级。

git如何clone一个shallow repository

Mon, 27 Feb 2017 14:57:56 +0800

本文是原「蜗窝讨论区」的历史存档（2017-02-27），来自版块「灌水区」，共 3 帖。讨论区已停止服务，此处仅供查阅。

三少 · 2017-02-27 14:57

我现在是有一份git管理的项目代码，其中有若干分支，现在想要把其中一个分支clone一份到本地路径。但是clone时会报如下错误： fatal: attempt to fetch/clone from a shallow repository fatal: The remote end hung up unexpectedly 网上搜了好多，都和我的现象不符合，现在不知道该怎么clone了，特来向各位请教一下。

其中原 git管理的项目代码，是网盘上下载的打包文件，然后解压后执行命令 “git checkout” 获得，在此基础上又自己创建了一些新的分支。

wowo · 2017-02-28 15:57

试试--depth选项，例如： git clone --depth 1 xxx

三少 · 2017-03-01 20:01

-depth选项很有用。另外一个比较有用的选项是 --single-branch。我这里的问题，还有一个影响因素就是git的版本，Ubuntu12.04默认的版本是1.7几的，对shallow repository有一些限制。需要升级一下git版本。网上找到的一个升级方法如下：支持Ubuntu 12.04、14.04、14.10、15.04 及其衍生版本。 sudo add-apt-repository ppa:git-core/ppa sudo apt-get update sudo apt-get install git

另外，实在要感谢一下wowo，看到好多没有人回复的，都是wowo给个答案，wowo的精神真是值得学习。

Linux系统如何标识进程？

Thu, 23 Feb 2017 19:10:26 +0800

其实两年前，本站已经有了一篇关于进程标识的文档，不过非常的简陋，而且代码是来自2.6内核。随着linux container、pid namespace等概念的引入，进程标识方面已经有了天翻地覆的变化，因此我们需要对这部分的内容进行重新整理。本文主要分成四个部分来描述进程标识这个主题：在初步介绍了一些入门的各种IDs基础知识后，在第三章我们描述了pid、pid number、pid name

ARM Linux上的系统调用代码分析

Mon, 20 Feb 2017 18:54:18 +0800

当用户空间的程序调用swi指令发起内核服务请求的时候，实际上程序其实是完成了一次“穿越”，该进程从用户态穿越到了内核态。这个过程有点象周末你在家里看片，突然有些内急，随手按下了pause按键，电影里面的世界嘎然而止了。程序世界亦然，一个swi后，用户空间的代码执行暂停了、stack（用户栈）上的数据，正文段、静态数据区、heap去的数据……一切都停下来了，程序的执行突然就转入另外一个世界，使用的栈

如何搭建高效率的开发环境？

Sat, 18 Feb 2017 17:07:55 +0800

本文是原「蜗窝讨论区」的历史存档（2017-02-18），来自版块「灌水区」，共 5 帖。讨论区已停止服务，此处仅供查阅。

三少 · 2017-02-18 17:07

先说说我自己现在的开发环境： 1.真机Win7 中 VM-Ubuntu，编辑代码软件使用装在Win7中的Source Insight 2.linux 及 android等源码在VM-Ubuntu中，Source Insight的工程也建立在VM-Ubuntu中。 3.平时代码编辑的时候在Win7环境下进行，VM与Win7使用samab服务

平时遇到的问题： 1.使用samab服务，平时偶尔会由于虚拟机ip变化而出现相关路径问题（暂时将虚拟机IP设置为固定来解决） 2.且在没有网（路由器也没有）的时候，Win7下不能用Source Insight 3.android源码所占空间较大，在好几个项目使用同一主源代码时，如果每个项目都拷贝一套代码所占空间较大。所以近期采用git分支功能，如此就带来新的问题：a.不能很快的多项目同时开发（比如比较耗时间的编译工作，切换分支后需要重新编译，耗费时间较久）；b.切换分支后，Source Insight会经常性的奔溃。

如此，觉得工作效率不是很高，想来找大家支支招。先行谢过！

jackindata · 2017-02-20 08:40

1、固定 IP 没什么问题吧，在路由里配。 2、怎么没网络 Source Insight 就用不了了？ 3、对于 N 多文件的框架等，我用 Git 一般只追踪会变化的文件，其他文件不加入管理。这样 Git 不回崩溃，反应速度也够快。

三少 · 2017-02-20 10:46

jackindata 写道： 1、固定 IP 没什么问题吧，在路由里配。 2、怎么没网络 Source Insight 就用不了了？ 3、对于 N 多文件的框架等，我用 Git 一般只追踪会变化的文件，其他文件不加入管理。这样 Git 不回崩溃，反应速度也够快。

1.固定IP确实没问题，现在就是这样设置的 2.我现在是通过 \192.168.1.* ，这样的方式来打开虚拟机中的工程，不接路由器的情况下是不能用的，不知有什么好的解决办法？ 3.我是做linux驱动及android的一些系统定制的工作，git是不会崩溃的，但是相应的Source Insight工程在切换branch后，如果改动的文件较多就会崩溃

wowo · 2017-02-20 11:39

三少写道：

jackindata 写道： 1、固定 IP 没什么问题吧，在路由里配。 2、怎么没网络 Source Insight 就用不了了？ 3、对于 N 多文件的框架等，我用 Git 一般只追踪会变化的文件，其他文件不加入管理。这样 Git 不回崩溃，反应速度也够快。

虚拟机的网络，应该选择为NAT模式（共享主机的IP），这样就和路由器没有关系了。至于看代码，如果Vim+Ctags用熟练了，绝对比Source Insight的效率高～

arm平台下系统调用的一点疑问。

Sat, 11 Feb 2017 16:15:37 +0800

本文是原「蜗窝讨论区」的历史存档（2017-02-11），来自版块「Linux kernel技术问答」，共 8 帖。讨论区已停止服务，此处仅供查阅。

fdm_dec · 2017-02-11 16:15

在学习arm平台下系统调用时遇见的疑问想不明白

大致理解是通过swi指令触发软中断，从而cpu强制切换了模式（硬件行为），然后进入到软中断的中断处理函数，然后根据传递下来的参数和对应的系统调用号去找到相应的系统处理函数（这个处理函数的执行我的理解为在软中断的中断处理上下文中，但是该系统调用链下肯定会有很多引发调度的代码，这个不是和中断处理中不准调用引起调度的函数相矛盾吗？？），执行完后在恢复堆栈返回用户态执行swi的下一条指令继续运行。在网上找答案是看见一个帖子跟我疑惑差不多，也一同贴出来大家一起分析讨论下，被这个这个问题困惑了很久。

以下是我网上找的另一个人的帖子想知道linux系统调用发生在哪个内核线程的上下文中。另外，针对kernel module的read和write操作发生在什么上下文中？当前的理解是：以ARM为例，系统调用执行了swi指令，使得处理器进入SVC模式下的软中断处理函数中。现在的疑问是后续的处理函数仍然在中断处理函数中执行吗？还是调用tasklet后放到ksoftirqd中运行呢？个人感觉应该是后者，否则会导致中断处理长时间占用处理器，造成其他内核服务无法被调度。

linuxer · 2017-02-13 10:39

你需要区分ARM SWI和linux内核中的soft irq，这两个术语是不一样的“软中断”。

fdm_dec · 2017-02-14 10:56

感谢对问题的回答 softirq是真正运行在中断上下文 asm_do_IRQ( { ....... irq_exit(//执行软中断。如tasklet等等 }

假如分析从用户态利用svc进入触发该异常的方式

ENTRY(vector_swi)
/****将中断发生前的寄存器状态备份入栈***/
1： sub sp, sp, #S_FRAME_SIZE /在栈上开辟184的空间备份跳转之前的寄存器值/
2： stmia sp, {r0 - r12} / Calling r0 - r12 备份公用寄存器r0-r12/
3： ARM( add r8, sp, #S_PC /r8指向栈空间中应该存pc的位置/
4： ARM( stmdb r8, {sp, lr}^ / Calling sp, lr/

（r0-r12）和用户态的（r0-r12）是共享的，这也可以解释为什么进入svc后可以通过rxx寄存器来传递参数。但是此时sp和用户sp是不一样的，理解成sp切换成了另外一个值。就叫做内核态的sp值吧。

关于这个sp值就是我最难理解的地方，此时这个sp我认为只是由于强制进入svc模式下的某个值，而并不能说明就是当前进程的内核态的sp，既然对于每个进程来说都有用户态和内核态的栈空间，那为什么此时sp就一定是当前进程的sp呢，我自己认为如果此时有个（sp= current->sp(仅仅表达这个意思，真正进程保它的内核态sp的值可能是更负责的实现，仅仅是想说要把sp切换成当前进程内核态的sp的值，这样后续的操作才能是在这个进程内核态的上下文中运行) 这种代码来显示下，我就能理解sp就是明确指向当前进程内核态的sp,这样后续的操作确实就在当前任务的内核态上下文，也能理一系列调用链的的合理性）

进程切换分析（2）：TLB处理

Thu, 09 Feb 2017 12:05:11 +0800

进程切换是一个复杂的过程，本文不准备详细描述整个进程切换的方方面面，而是关注进程切换中一个小小的知识点：TLB的处理。为了能够讲清楚这个问题，我们在第二章描述在单CPU场景下一些和TLB相关的细节，第三章推进到多核场景，至此，理论部分结束。在第二章和第三章，我们从基本的逻辑角度出发，并不拘泥于特定的CPU和特定的OS，这里需要大家对基本的TLB的组织原理有所了解，具体可以参考本站的《 TLB操作

eMMC 原理 3 ：分区管理

Mon, 06 Feb 2017 21:31:31 +0800

本文主要介绍 eMMC 内部的分区管理机制

进程和底半部（softirq tasklet）间的数据共享的问题，持有锁，为何还要禁止底半部

Mon, 06 Feb 2017 09:26:00 +0800

本文是原「蜗窝讨论区」的历史存档（2017-02-06），来自版块「Linux kernel技术问答」，共 5 帖。讨论区已停止服务，此处仅供查阅。

巴扎黑 · 2017-02-06 09:26

最近在看LKD，有些疑问来请教一下

当一个进程持有一把自旋锁的时候，内核此时preempt_count非0，也就是禁止抢占，同样书中说，preempt_count非0时，底半部也是禁止的那么，疑问来了，当进程中持有一把自旋锁时，preempt_count非0，底半部是否自动禁止了？如果按照上面的推理，底半部被禁止了，那么为何书中说：一般单纯禁止下半部处理是不够的，一般做法是先得到一个锁，再禁止下半部书中的说法有问题吗？

对于硬中断——底半部——进程的理解，我觉得只有硬中断是异步的，随时可能到来打断别人，对于底半部和进程抢占都是同步的，能否把底半部当成一个优先级非常高的进程来理解触发底半部软中断或者tasklet，它们也是需要等待调度执行，我觉得它们和进程抢占非常像。软中断执行的时机，相比进程抢占是否是一样的（进程抢占多一个软中断返回时？）

初学linux，上述都是个人简单的理解，有很多不对的地方，请大家帮忙指点一下，谢谢

linuxer · 2017-02-06 17:07

那么，疑问来了，当进程中持有一把自旋锁时，preempt_count非0，底半部是否自动禁止了？－－－－－－－－－－－－－－－－－－不会，持有自旋锁的时候仅仅是disable了preempt而已，不会disable bottom half。

linuxer · 2017-02-06 17:43

在QQ群中，你给出了一段LKD中的话，如下：如果一个进程上下文和一个下半部共享数据，在访问这些数据之前，你需要禁止下半部的处理并得到锁的使用权，一般单纯禁止下半部处理是不够的，一般做法是先得到一个锁，再禁止下半部－－－－－－－－－－－－－－－－－－－－－－－－－－其实你的问题可以归结为在进程上下文和bottom half中共享数据，如何使用锁。我手边有一本LKD 3rd edition，没有中文版，我猜测这段话对应的英文是157页的Locking between the bottom halves小节，英文原文是：－－－－－－－－－－－－－－－－－－－－－－－－－－ If process context code and a bottom half share data, you need to disable bottom-half processing and obtain a lock before accessing the data. Doing both ensures local and SMP protection and prevents a deadlock.

在UP的场景下，process context不用抢占bottom half的执行，因此，这时候如何保护临界区非常简单：在process context中disable bottom half的处理就OK了。在SMP场景下，事情就有点复杂了。既然你的问题说道了spin lock，那么就假设本场景中使用的锁就是spin lock了，哈哈。这时候，保护临界区可能采用的方法包括： 1、spin lock only 2、disable bottom half only 3、both 当然，这里只有第三种方法是对的。对于第一种方法，为何是错误的呢？让我们从CPUa上的进程上下文来看，这时候，spinlock仅仅能够保护来自其他cpu上的process context和bottom half的并发访问，对于CPUa的bottom half的抢占却会造成灾难性的后果：dead lock 为何第二种方法是错误的呢？因为这时候无法保护来自其他CPU上bottom half的并发，也无法保护来自其他cpu的process context的并发。正确的方法是：进程上下文的时候，在进入临界区之前，先disable bottom half，然后获取spinlock。在bottom half中，在进入临界区之前，获取spinlock。

进程切换分析(1)：基本框架

Sat, 04 Feb 2017 18:43:03 +0800

本文主要是以context_switch为起点，分析了整个进程切换过程中的基本操作和基本的代码框架，很多细节，例如tlb的操作，cache的操作，锁的操作等等会在其他专门的文档中描述。进程切换包括体系结构相关的代码和系统结构无关的代码。第二、三、四分别描述了context_switch的代码脉络，后面的章节是以ARM64为例子，讲述了具体进程地址空间的切换过程和硬件上下文的切换过程。

中断和软中断不能阻塞原因？

Sun, 22 Jan 2017 09:36:27 +0800

本文是原「蜗窝讨论区」的历史存档（2017-01-22），来自版块「Linux kernel技术问答」，共 5 帖。讨论区已停止服务，此处仅供查阅。

Taochao · 2017-01-22 09:36

刚入门驱动不久，一直被告诉中断、软中断环境不能调用阻塞函数。对于我的理解是阻塞会切出去，中断借用的当前线程环境，什么时候能切回来不确定。

最近在网络速率优化的时候，注意到驱动注册的发送接口，大部分情况会由net core中的软中断触发调用，而我们的发送接口不可避免的会调用一些可能阻塞的接口，这样岂不是会有问题？

linuxer · 2017-01-23 11:41

调度器是每一个OS的必备组件，在编码阶段之前，我们往往要制定下我们的设计概念。对于Linux 调度器，它的目标就是调度线程，而一个线程就是调度实体（暂不考虑group sched）。中断上下文是不是调度实体呢？当然不是，它没有专属的task struct，内核无从调度。这是调度器设计者的决定，这样的决定让调度器设计起来简洁而美丽。

基于上面的设计概念，中断上下文（hard irq和softirq context）并不参与调度（暂不考虑中断线程化），它们是异步事件的处理机制，目标就是尽快完成处理，返回现场。因此，所有中断上下文的优先级都是高于进程上下文的，也就是说，对于用户进程（无论内核态还是用户态）或者内核线程，除非disable了CPU的本地中断，否则一旦中断发生，它们是没有任何能力阻挡中断上下文抢占当前进程上下文的执行的。

因此，Linux kernel的设计者制定了规则： 1、中断上下文不是调度实体 2、中断上下文的优先级高于进程上下文而在中断上下文中调度毫无疑问会打破规则，因此不能在硬中断、软中断环境中调用阻塞函数。

linuxer · 2017-01-23 12:06

当然，我们可以追问为何制定这样的规则？让中断上下文参与调度会引入什么样子的复杂性呢？我们可以想象一个场景：进程A通过系统调用陷入内核，进入spin lock保护的临界区，这时候，中断来了，并且你想要在中断上下文中调用调度器接口，切换到其他进程，怎么处理？spin lock保护的临界区本来设计的时候就要求一定要短，现在居然准备切换到其他进程，你让spin lock情何以堪呐。这样的例子很多，这里就不列举了。

linuxer · 2017-01-23 12:14

我看网上很多的文章都说在中断上下文调用睡眠函数会导致“找不到回来的路”，其实对于linux kernel而言，这是看运气的事情，也就是说要看被中断的上下文的情况，如果中断发生在进程的用户态时候，调用schedule函数还是有机会返回的，进程的内核栈上依次保存了“进程被中断的上下文”和“中断执行路径的上下文”，这些信息足够让进程找到”回家的路“

Taochao · 2017-01-24 21:18

多谢linuxer的解答了，我这边最近在调网络速度，驱动的发送函数被网络层调用，还被modem的线程走fastnet调用，modem的线程优先级高，发包的时候会导致我们缓冲满，丢弃了一部分，也浪费了一部分cpu，最初做实验在发送接口发送满的时候阻塞等待，这样效果还可以，速度上去了，但是发送函数就有阻塞的情况了，之前看过网络那边似乎会从softirq调用的情况，真实测试的时候也会出现这种情况，所以很纳闷这种网络核心层这种设计，不知道是不是我理解错了，驱动的发送函数不可避免有阻塞接口，因为经常有队列操作。。。

linuxer 写道： 我看网上很多的文章都说在中断上下文调用睡眠函数会导致“找不到回来的路”，其实对于linux kernel而言，这是看运气的事情，也就是说要看被中断的上下文的情况，如果中断发生在进程的用户态时候，调用schedule函数还是有机会返回的，进程的内核栈上依次保存了“进程被中断的上下文”和“中断执行路径的上下文”，这些信息足够让进程找到”回家的路“

ARMv8.1中为何恢复对SWP的支持？

Fri, 20 Jan 2017 15:28:15 +0800

本文是原「蜗窝讨论区」的历史存档（2017-01-20），来自版块「Linux kernel技术问答」，共 2 帖。讨论区已停止服务，此处仅供查阅。

linuxer · 2017-01-20 15:28

在ARMv8-A中，SWP指令被认为是obsolete的，感觉这条指令要慢慢被淘汰的样子，不过，这几天，在阅读ARMv8.1文档的时候，赫然发现在ARMv8.1引入的若干原子操作指令中有SWP指令。看起来很神奇，呵呵～～～表面上看起来一条指令的事，不过深究起来，应该是ARMv8和ARMv8.1在原子操作指令上面的思路是不一样的： 1、ARMv8倾向于使用Exclusive access instructions来解决read-modify-write的原子操作性。 2、ARMv8.1提供了专门的atomic instructions来解决read-modify-write的原子操作性。为何做这样的改变呢？我的想法是： 1、对于Exclusive access instructions来说，ARMv8文档描述的很清楚了，其实就是放了global monitor和local monitor来监视总线，如果有其他的bus master插入，那么重新来过。这种机制在cpu core比较少的情况下，运作应该是基本OK的，不过，随着cpu core数量的增多，重来的机会（或者说其他CPU插入的机会）也随之上升，从而导致性能急剧下降。 2、 ARMv8.1的atomic instructions应该锁总线的吧（我猜的），在CPU core少的时候，各个CPU之间的冲突没有那么剧烈，武断的锁住总线实际上应该是阻碍了其他CPU core上指令的执行。当core多到一定程度，冲突加剧，试错重来的机制应该不如统一步伐（只让一个cpu core发起总线访问）机制。

有没有对ARM处理器比较了解的同学，出来讲讲。

linuxer · 2017-01-25 10:15

和其他工程师讨论之后，可以认定我的想法2是错误的。在ARMv8.1中原子指令不是采用锁总线的方式，因为本身锁总线的方式效率异常的差。因为一个CPU core因为执行了原子操作（访问memory X）而锁住总线，实际上禁止了其他所有核上的总线访问操作，而实际上应该禁止的是其他核上针对该memory X的访问而不是一棍子打死，锁住总线，禁止cpu core对所有memory的访问。但是，毫无疑问，当cpu core不断增多，Exclusive access instructions指令性能急剧下降，肯定要进行优化，否则，ARMv8.1中也不会提供原子指令操作了。具体ARMv8.1中如何实现原子指令操作呢？目前的细节还是没有讨论清楚，但是这个功能模块应该是位于系统中所有cpu core访问memory的汇聚点处（例如L3 cache）。而实际的read-modify-write的原子操作性在系统中应该是被分解成两个bus transaction，例如对地址X的原子操作应该包括Read X和write X，而在L3 cache中的功能模块的功能包括： 1、识别原子操作指令中的Read X 2、pending所有对X地址的操作 3、对其他地址的操作正常 4、检测到write X操作之后，一切恢复正常

一句话总结，lock bus是把处理原子操作那个功能模块放置到靠近cpu core附近的位置，限制了cpu core的发挥，放到远端的memory hierachy的某个节点上应该可以加快cpu性能。

BTW，一切都是猜测......

为什么会有文件系统(一)

Tue, 17 Jan 2017 20:56:50 +0800

Linux发展到现今，在fs目录下我们可以看到形形色色的文件系统，眼花缭乱的同时首先需要回答的问题是，为什么会有文件系统这个东西呢？我想如果能搞清楚这个问题，会帮助大家更好的理解文件系统，那么我就尝试着来模拟一次文件系统的演进过程，于是，我们来到了那一天，那天之前，人们还没有文件系统的概念。友情提示 : 下面将在荒诞的场景下演进人类合理的诉求神说，要有光，于是，光照大地神说，要有风，于是，风

代码跑飞的问题

Tue, 17 Jan 2017 13:27:28 +0800

本文是原「蜗窝讨论区」的历史存档（2017-01-17），来自版块「Linux kernel技术问答」，共 4 帖。讨论区已停止服务，此处仅供查阅。

wpch315 · 2017-01-17 13:27

遇到代码偶尔跑飞的问题，跑飞的位置看不出什么规律，很难下手，下面是一个例子：


[== Undefined ==]
......
mDelay(1);
/* send this info to indicate the start of comunicaton */
for(i=0; i<7; i++)
 sysPutChar(chk_start[i], WB_UART_1);
.......

这段代码sysPutChar只发了一个字节，之后就没有反应了，作如下修改：


[== Undefined ==]
.......
mDelay(1);
/* send this info to indicate the start of comunicaton */
for(i=0; i<7; i++)
 sysPutChar(chk_start[i], WB_UART_1);
asm volatile("nop":::"memory"); 
.......

加了一条空指令就正常运行，不是sysPutChar的问题，因为其他地方有的时候也会出现类似现象，反汇编如下，看不出什么问题 1401bc4: e3a00001 mov r0, #1 1401bc8: ebfff956 bl 1400128 <mDelay> 1401bcc: e3a03000 mov r3, #0 1401bd0: ea000007 b 1401bf4 <check_board_valid+0x40> 1401bd4: e59d1010 ldr r1, 1401bd8: e59f21e8 ldr r2, ; 1401dc8 <check_board_valid+0x214> 1401bdc: e0820001 add r0, r2, r1 1401be0: e5d00063 ldrb r0, [r0, #99] ; 0x63 1401be4: e3a01001 mov r1, #1 1401be8: eb0017c5 bl 1407b04 <sysPutChar> 1401bec: e59d3010 ldr r3, 1401bf0: e2833001 add r3, r3, #1 1401bf4: e58d3010 str r3, 1401bf8: e59dc010 ldr ip, 1401bfc: e35c0006 cmp ip, #6 1401c00: 9afffff3 bls 1401bd4 <check_board_valid+0x20> 1401c04: e1a00000 nop ; (mov r0, r0)

没有调试器，不知道代码运行的情况，请教大家，有没有什么调试方向？

Boardconfig.mk与device.mk

Mon, 16 Jan 2017 16:52:25 +0800

本文是原「蜗窝讨论区」的历史存档（2017-01-16），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

maze · 2017-01-16 16:52

小白一枚。今天想把一个android/vendor/目录下的一个小工具编译出来； vendor目录下的Android.mk正确。然而全编始终编不出来。后来发现android/device/目录下的Boardconfig.mk与device.mk修改了一下。编译成功但是我对Boardconfig.mk与device.mk这个两个mk不懂，有人随便给回答一下？或者给个链接我自己去看。不胜感激不胜感激不胜感激

链接相关的一个问题

Fri, 13 Jan 2017 13:33:26 +0800

本文是原「蜗窝讨论区」的历史存档（2017-01-13），来自版块「Linux kernel技术问答」，共 6 帖。讨论区已停止服务，此处仅供查阅。

wpch315 · 2017-01-13 13:33

链接脚本如下： . = 0x1400000;

 .Reset = .;
. = ALIGN(4);
.text : {
*(.text)
. = ALIGN(4);
}
.rodata : { *(.rodata) }
. = ALIGN(4);
.data : { *(.data) }
. = ALIGN(4);
__bss_start = .;
.bss : { *(.bss) }
__bss_end = .;

section布局如下： [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .text PROGBITS 01400000 008000 00ff90 00 AX 0 0 32 [ 2] .rodata PROGBITS 0140ff90 017f90 000c8f 00 A 0 0 4 [ 3] .rodata.str1.1 PROGBITS 01410c1f 018c1f 000624 01 AMS 0 0 1 [ 4] .data PROGBITS 01411244 019244 0002ac 00 WA 0 0 4 [ 5] .bss NOBITS 01414000 0194f0 225554 00 WA 0 0 16384 [ 6] .ARM.attributes ARM_ATTRIBUTES 00000000 0194f0 000030 00 0 0 1 [ 7] .shstrtab STRTAB 00000000 019520 000053 00 0 0 1 [ 8] .symtab SYMTAB 00000000 019704 0043e0 10 9 651 4 [ 9] .strtab STRTAB 00000000 01dae4 001f1d 00 0 0 1

请教各位：为什么bss段没有连着data段，而是空了很多？

eMMC 原理 2 ：eMMC 简介

Thu, 12 Jan 2017 20:28:40 +0800

eMMC 是 embedded MultiMediaCard 的简称。MultiMediaCard，即 MMC，是一种闪存卡（Flash Memory Card）标准，它定义了 MMC 的架构以及访问 Flash Memory 的接口和协议。而 eMMC 则是对 MMC 的一个拓展，以满足更高标准的性能、成本、体积、稳定、易用等的需求。

Linux MMC framework(1)_软件架构

Tue, 10 Jan 2017 22:24:45 +0800

由[1]中MMC、SD、SDIO的介绍可知，这三种技术都是起源于MMC技术，有很多共性，因此Linux kernel统一使用MMC framework管理所有和这三种技术有关的设备。本文将基于[1]对MMC技术的介绍，学习Linux kernel MMC framework的软件架构。

eMMC 原理 1 ：Flash Memory 简介

Mon, 09 Jan 2017 19:28:14 +0800

eMMC 是 Flash Memory 的一类，在详细介绍 eMMC 之前，先简单介绍一下 Flash Memory。 Flash Memory 是一种非易失性的存储器。在嵌入式系统中通常用于存放系统、应用和数据等。在 PC 系统中，则主要用在固态硬盘以及主板 BIOS 中。另外，绝大部分的 U 盘、SDCard 等移动存储设备也都是使用 Flash Memory 作为存储介质。

Linux hrtimer定时器误差很大，可能会有哪些原因啊？

Sun, 08 Jan 2017 13:30:26 +0800

本文是原「蜗窝讨论区」的历史存档（2017-01-08），来自版块「Linux kernel技术问答」，共 4 帖。讨论区已停止服务，此处仅供查阅。

elicec · 2017-01-08 13:30

用的arm平台Linux，现在需要定时us级别。有事定时500us，实际可能达到700多。而且这个hrtimer是不是可能会被打断吗？我测试了hrtimer定时400us，跑2000次。期间不断触摸屏幕。结果是实际到期达到2ms多，比预期的400us多太多了。

444444+count1:813---difftime:408- 333333+count:814---difftime:407-- 444444+count1:814---difftime:408-//定时400us正常 ly event->au16_y[i] =1060//有一个触摸屏的中断 333333+count:815---difftime:2979-//下次hrtimer到期达到近3ms 444444+count1:815---difftime:2979 333333+count:816---difftime:411-- 444444+count1:816---difftime:416-

还有一个测试情况，开两个hrtimer，定时600us，实际老是会多出200us左右，并且定时一个小时也是会经常多出200us。但是定时时间非常短，就不会多出200us，比如定时300us以下，都是准确的。

[== Undefined ==] 444444+count1:23---difftime:847- 333333+count:24---difftime:841-- 444444+count1:24---difftime:846- 333333+count:25---difftime:841-- 444444+count1:25---difftime:846- 333333+count:26---difftime:842-- 444444+count1:26---difftime:847- 333333+count:27---difftime:607--//正常600us 444444+count1:27---difftime:609- 333333+count:28---difftime:842-- 444444+count1:28---difftime:846-//不正常 333333+count:29---difftime:840-- 444444+count1:29---difftime:844- 333333+count:30---difftime:840-- 444444+count1:30---difftime:845- 333333+count:31---difftime:606-- 444444+count1:31---difftime:609- 333333+count:32---difftime:610-- 444444+count1:32---difftime:613- 333333+count:33---difftime:842-- 444444+count1:33---difftime:845- 333333+count:34---difftime:840-- 444444+count1:34---difftime:845- 333333+count:35---difftime:841-- 444444+count1:35---difftime:845- 333333+count:36---difftime:841-- 444444+count1:36---difftime:845- 333333+count:37---difftime:608-- 444444+count1:37---difftime:612- 333333+count:38---difftime:842-- 444444+count1:38---difftime:846-

不知道有哪些原因会导致hrtimer这么的不准，这么多问题啊？

wowo · 2017-01-09 14:10

Linux kernel并不是一个硬实时的kernel，所以hrtimer不准很正常。影响hrtimer准确度的最有可能的原因，就是kernel中那些关中断的临界区。中断都关闭了，什么timer都完蛋了…… 所以，不要纠结准不准了，尽量减少误差的影响，例如问问自己：需要这么精确的timer吗？另外，如果需要一个周期性的timer，尽量使用hrtimer_forward_now重启timer，以避免误差累积。

温柔海洋 · 2017-01-20 09:10

是啊，有些驱动中经常 spin_lock_irqsave spin_unlock_irqrestore的，对Linux 实时性能也有影响的

想问问各位大神是怎么翻墙的？

Sat, 07 Jan 2017 21:42:13 +0800

本文是原「蜗窝讨论区」的历史存档（2017-01-07），来自版块「灌水区」，共 4 帖。讨论区已停止服务，此处仅供查阅。

井中月 · 2017-01-07 21:42

如题。。。

wowo · 2017-01-09 14:04

我的需求很简单，能有Google就可以了，因此还是很好fan的。以前用GAE，现在用hosts（github上一大把）。

jackindata · 2017-02-20 13:49

https://github.com/XX-net/XX-Net 推荐这个。

替换 host 文件一个不好的地方是需要自己反复去更新，因为过段时间有些 IP 就会失效。

iwakan · 2017-03-31 19:43

我用过这个，不过现在没用了。https://github.com/racaljk/hosts

uboot中的设备树影响到了linux内核

Wed, 04 Jan 2017 01:01:03 +0800

本文是原「蜗窝讨论区」的历史存档（2017-01-04），来自版块「Linux kernel技术问答」，共 2 帖。讨论区已停止服务，此处仅供查阅。

井中月 · 2017-01-04 01:01

使用的uboot：xilinx uboot-v2015.4 linux 内核：xilinx linux-v2015.4

问题描述：我发现在这个版本的uboot中配置内存等信息是读取的设备树，因为原来移植uboot我直接更改include/configs/zynq-zc70x.h中的一些限制即可，比如:


[== C++ ==]
 #define CONFIG_SYS_SDRAM_SIZE (512 * 1024 * 1024)

这样就修改就能在启动时查看到sdram打印为512M，而这个版本修改后无效。然后，我大概去跟了一下uboot，发现是xilinx默认一个宏CONFIG_OF_CONTROL会一直被define（不受make ***_defconfig影响），这样在代码中会去解析arch/arm/dts中对应的设备树，我修改该设备树内容后，uboot启动内容随之改变。

但问题出现在启动内核后，linux内核启动后，我通过free或cat /etc/meminfo发现内核中的内存大小是随uboot的设备树中的sdram值发生变化的，而不是读的flash中存放的设备树文件，但另外我在linux内核加载的设备树中对flash的分区等信息又能正确解析出。所以这里我就有一个问题了：uboot的设备树有部分影响到了linux的资源初始化，这个是怎么影响的呢？整个流程是如何贯穿起来的？

PS：由于只做过简单的移植，所以对很多细节的东西不清楚，希望各位不吝赐教，谢谢！另：程序在设备上运行的，家里电脑不能截图，如果为了分析有需要，我将在后面把运行结果贴上。

wowo · 2017-01-04 14:39

井中月写道： 使用的uboot：xilinx uboot-v2015.4 linux 内核：xilinx linux-v2015.4

问题描述：我发现在这个版本的uboot中配置内存等信息是读取的设备树，因为原来移植uboot我直接更改include/configs/zynq-zc70x.h中的一些限制即可，比如:


[== C++ ==]
 #define CONFIG_SYS_SDRAM_SIZE (512 * 1024 * 1024)

可以检查一下uboot传递的命令行参数，是不是有mem信息。

X-022-OTHERS-git操作记录之合并远端分支的更新

Mon, 02 Jan 2017 22:26:22 +0800

本文将以“ X Project ”的开发过程为例，介绍“合并远端分支的更新”的方法。事情的起因如下： “ X Project ”是一个学习嵌入式Linux开发全过程的小项目，项目开始的时候，u-boot、linux kernel等代码，都是直接从官方仓库的当前状态获取的(具体可参考[2]）。以u-boot为例，“ X Project ”的u-boot [3] 是2016年4月23日从u-boot的

build linux kernel for shc board

Sun, 01 Jan 2017 22:11:18 +0800

本文是原「蜗窝讨论区」的历史存档（2017-01-01），来自版块「Linux kernel技术问答」，共 2 帖。讨论区已停止服务，此处仅供查阅。

zhan7802 · 2017-01-01 22:11

Hi, I have a unknown board which using am335x and I tried to make it boot linux. First I tried TI emv as configuration but it does not work. Finally I got a board config which is am335x_shc_defconfig I used this config build u-boot it generated spl and u-boot.img and I can load it through UART and it boots ok. But I can't build kernel with am335x_shc_defconfig. I tried TI emv config but I got the following:

U-Boot SPL Ambonare 2016.07 (Dec 14 2016 - 19:13:27) SHC Timed out in wait_for_event: status=0000 Check if pads/pull-ups of bus 0 are properly configured Trying to boot from UART CCxyzModem - CRC mode, 1(SOH)/213(STX)/0(CAN) packets, 3 retries Loaded 217448 bytes

U-Boot 2016.07 (Dec 14 2016 - 19:13:27 -0600)

 Watchdog enabled

I2C: ready DRAM: 256 MiB Timed out in wait_for_event: status=0000 Check if pads/pull-ups of bus 0 are properly configured Could not probe the EEPROM; something fundamentally wrong on the I2C bus. EEPROM Content Invalid. MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 ** Wrong ISO Ident: ãã´Äá ã on 1:1 ** Net: Could not get PHY for cpsw: addr 0 cpsw Enter 's' to enter prompt (times out) 2 Enter 'n' to enter prompt without timeout => loadb 0x80300001

Ready for binary (kermit) download to 0x80300001 at 115200 bps...

Total Size = 0x0000023a = 570 Bytes

Start Addr = 0x80300001

=> go 0x80300004

Starting application at 0x80300004 ...

loadaddr=0x80200000 U-Boot=> loadb

Ready for binary (kermit) download to 0x80200000 at 115200 bps...

Total Size = 0x0034a9d8 = 3451352 Bytes

Start Addr = 0x80200000

U-Boot=> bootz Kernel image @ 0x80200000 [ 0x000000 - 0x34a9d8 ]

Starting kernel testing ...

Before cleanup_before_linux(

after cleanup CCCCCCCC

I need help on how to build a linux kernel and make it boot on my board.

Please help me.

Best regards,

问个多核架构下中断优化的问题

Mon, 26 Dec 2016 11:19:16 +0800

本文是原「蜗窝讨论区」的历史存档（2016-12-26），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

温柔海洋 · 2016-12-26 11:19

现在我用的imx6芯片是SMP架构，双核的，有个性能优化的问题。imx6 系统一跑起来，芯片厂商把外设中断执行全部绑定在 CPU0上了。这是我的推测，我是看代码得知的，看到imx6 内核初始化时，通过写GIC 相关寄存器，把imx6芯片所有的外设中断都绑定在CPU0上了。因为嵌入式系统是要求及时响应为目的，应用没有irqbalance 这种中断负载均衡的措施。（imx6里面没有irqbalance）

那芯片厂商如果这样设计发布他们sdk 开发包的话，我觉得有问题啊，如果比如说MMC 设备在进行频繁的写数据通信。同时wifi 外设又在接受几十个G的数据流量。这样的话，都在CPU0上执行的话。虽说即使是有中断上半部和下半部的区分，但是很多中断上半部都在同一个CPU上执行，会不会影响中断触发性能。

还有啊，如果代码里有很多的spin_lock_irqsave spin_unlock_irqrestore操作（这些应该很多是禁用CPU0上的本地中断吧），这样的话，会不会影响中断执行的性能？

所有我的建议是不是在一些中断频繁触发的场合，非常有必要把某个外设中断绑定在CPU1上执行，不在CPU0。

MMC/SD/SDIO介绍

Sun, 25 Dec 2016 21:52:05 +0800

熟悉Linux kernel的人都知道，kernel使用MMC subsystem统一管理MMC、SD、SDIO等设备，为什么呢？到底什么是MMC？SD和SDIO又是什么？为什么可以用MMC统称呢？在分析Linux kernel的MMC subsystem之前，有必要先介绍一些概念，以便对MMC/SD/SDIO有一个大致的了解，这就是本文的目的。

用一个简介的例子：区分阻塞，非阻塞，同步，异步

Wed, 21 Dec 2016 16:27:56 +0800

本文是原「蜗窝讨论区」的历史存档（2016-12-21），来自版块「Linux kernel技术问答」，共 5 帖。讨论区已停止服务，此处仅供查阅。

maze · 2016-12-21 16:27

如题~！

wowo · 2016-12-21 16:54

maze 写道： 如题~！

以从串口读取数据为例(假如你能看懂的话，哈哈～～)。


[== Undefined ==]
1.阻塞方式
 read(10 bytes)
 wait...
 wait...
 <---RX(5 bytes)
 wait...
 <---RX(5 bytes)
 return(10 bytes)
2.非方式阻塞
 read(10 bytes)
 return(0 bytes)
 ...
 <---RX(5 bytes)
 read(10 bytes)
 return(5 bytes)
 ...
 <---RX(5 bytes)
 read(5 bytes)
 return(5 bytes)
3. 同步方式
 上面的阻塞或者非阻塞，都属于同步方式。
4. 异步方式
 read(10 bytes， callback)
 return(0)
...
 &lt;---RX(5 bytes)
...
 &lt;---RX(5 bytes)
callback(10bytes)

maze · 2016-12-21 16:57

wowo 写道：

maze 写道： 如题~！

以从串口读取数据为例(假如你能看懂的话，哈哈～～)。


[== Undefined ==]
1.方式阻塞
 read(10 bytes)
 wait...
 wait...
 <---RX(5 bytes)
 wait...
 <---RX(5 bytes)
 return(10 bytes)
2.非方式阻塞
 read(10 bytes)
 return(0 bytes)
 ...
 <---RX(5 bytes)
 read(10 bytes)
 return(5 bytes)
 ...
 <---RX(5 bytes)
 read(5 bytes)
 return(5 bytes)
3. 同步方式
 上面的阻塞或者非阻塞，都属于同步方式。
4. 异步方式
 read(10 bytes， callback)
 return(0)
...
 &lt;---RX(5 bytes)
...
 &lt;---RX(5 bytes)
callback(10bytes)

感谢wowo的回复，正确，但是感觉缺乏一些必要的说明，也把进程这个概念给淡化了。。

Hikey一块，送人了～～

Wed, 21 Dec 2016 11:41:31 +0800

本文是原「蜗窝讨论区」的历史存档（2016-12-21），来自版块「X Project」，共 7 帖。讨论区已停止服务，此处仅供查阅。

wowo · 2016-12-21 11:41

时间有限，玩不了那么多板子，又不想板子浪费，希望能送给能利用起来的人（最好一起做X project ）。想要的同学回复报名。至于怎么才能得到板子呢？我也不太清楚，例如可以写一点东西（比如把这个脚本---https://github.com/wowotechX/tools/blob/hikey/hisilicon/hisi-idt.py转为x project dfu工具的c code---https://github.com/wowotechX/tools/tree/master/dfu）？大家先各舒其见吧～～

PS：有关该板子的介绍，我写了一篇文章，大家可以参考： /x_project/hikey_usb_boot.html

BubbleoO · 2016-12-21 11:54

111!!! 504879504@qq.com

soaringrocs · 2016-12-21 12:26

板子只有一块吗，吃个中午饭就没有了

wowo · 2016-12-21 13:50

BubbleoO 写道：

好歹要拿点诚意嘛:-)

soaringrocs 写道：

只有一块，还没有送出～～

cinmun · 2016-12-21 14:33

这个板子支持安卓6.0，目前刚好缺个支持6.0的板子，现在还是三星4412的板子只能到安卓5.0

ooonebook · 2016-12-27 17:02

:lol: wowo,送出了没有，最近比较忙都没上讨论区~看到这么动人的消息，不知道现在加把劲还来得及吗~ 不过对python不是很熟，一般都是直接用，接触得很少~~有没有其他选项~~~

wowo · 2016-12-30 10:09

ooonebook 写道： wowo,送出了没有，最近比较忙都没上讨论区~看到这么动人的消息，不知道现在加把劲还来得及吗~ 不过对python不是很熟，一般都是直接用，接触得很少~~有没有其他选项~~~

大家响应不太积极，所以我就忘了这回事了，哈哈。你要的话送你好了，我知道你的情况，所以“考察”的事情就免了好了～～

测试是否能收到linuxKernel技术问答的邮件

Wed, 21 Dec 2016 11:19:34 +0800

本文是原「蜗窝讨论区」的历史存档（2016-12-21），来自版块「Linux kernel技术问答」，共 2 帖。讨论区已停止服务，此处仅供查阅。

maze · 2016-12-21 11:19

如果您收到这封邮件，表明您已经正确设置，能够收到linux_kernel技术问答的邮件，基于wowo科技

wowo · 2016-12-21 11:29

maze 写道： 如果您收到这封邮件，表明您已经正确设置，能够收到linux_kernel技术问答的邮件，基于wowo科技

版块下面有个链接：“订阅该版块”，找到后点击。

基于Hikey的"Boot from USB"调试

Tue, 20 Dec 2016 22:36:53 +0800

话说在半年前，乐美客送给蜗窝几块Hikey(乐美客版)开发板 [1] ，不过由于太忙，就一直把它们放在角落里思考人生，因此甚是愧疚。这几天，闲来无事，翻了下Hikey的资料，觉得挺有意思，就想花点时间让“ X Project ”在这个板子上跑起来。当然，按照“规矩”，先从“ 【任务1】启动过程-Boot from USB ”做起，记录如下。

请教大家 linux-2.6.22.6中i2c_register_driver（）中drivers，adapters在哪儿定义的？

Sat, 17 Dec 2016 21:43:05 +0800

本文是原「蜗窝讨论区」的历史存档（2016-12-17），来自版块「Linux kernel技术问答」，共 2 帖。讨论区已停止服务，此处仅供查阅。

wall-E · 2016-12-17 21:43

int i2c_register_driver(struct module owner, struct i2c_driver driver) { int res;

/* new style driver methods can't mix with legacy ones */
if (is_newstyle_driver(driver)) {
 if (driver-&gt;attach_adapter || driver-&gt;detach_adapter
 || driver-&gt;detach_client) {
 printk(KERN_WARNING
 "i2c-core: driver [%s] is confused\n",
 driver-&gt;driver.name);
 return -EINVAL;
 }
}
/* add the driver to the list of i2c drivers in the driver core */
driver-&gt;driver.owner = owner;
driver-&gt;driver.bus = &amp;i2c_bus_type;
/* for new style drivers, when registration returns the driver core

will have called probe( for all matching-but-unbound devices.
*/
res = driver_register(&amp;driver-&gt;driver);
if (res)
return res;

mutex_lock(&amp;core_lists);
list_add_tail(&amp;driver-&gt;list,&amp;drivers); //drivers在哪儿定义的？
pr_debug(“i2c-core: driver [%s] registered\n”, driver-&gt;driver.name);
/* legacy drivers scan i2c busses directly */
if (driver-&gt;attach_adapter) {
struct i2c_adapter *adapter;
list_for_each_entry(adapter, &amp;amp;adapters, list) { //adatpters在哪儿定义的
 driver-&amp;gt;attach_adapter(adapter);
}

}
mutex_unlock(&amp;core_lists);
return 0;

}

samsung 2440 uboot 编译不过

Sat, 17 Dec 2016 14:53:04 +0800

本文是原「蜗窝讨论区」的历史存档（2016-12-17），来自版块「X Project」，共 6 帖。讨论区已停止服务，此处仅供查阅。

heziq · 2016-12-17 14:53

这个问题困扰我半个月了先贴代码： +++ b/arch/arm/Kconfig

+config TARGET_QT2440 + bool "Support samsung QT2440" + select CPU_ARM920T + select SUPPORT_SPL + select SPL + help + Support for SamSung platform based arm920t +

++ b/board/samsung/qt2440/Kconfig @@ -0,0 +1,18 @@ +# +#heziqin qt2440 samsung arm920t +# + +if TARGET_QT2440 + +config SYS_BOARD + default "qt2440" + +config SYS_VENDOR + default "samsung" + +config SYS_SOC + default "s3c24x0" + +config SYS_CONFIG_NAME + default "qt2440" +endif

Makefile 内容： nclude config.mk

UBOOT_DIR=$(BUILD_DIR)/../u-boot

OUT_DIR=$(BUILD_DIR)/out UBOOT_OUT_DIR=$(OUT_DIR)/u-boot

_all: all

env_prepare: git clone $(COMPILE_URL)

all: uboot

clean: uboot-clean

uboot: mkdir -p $(UBOOT_OUT_DIR) make -C $(UBOOT_DIR) CROSS_COMPILE=$(CROSS_COMPILE) KBUILD_OUTPUT=$(UBOOT_OUT_DIR) $(BOARD_NAME)_defconfig make -C $(UBOOT_DIR) CROSS_COMPILE=$(CROSS_COMPILE) KBUILD_OUTPUT=$(UBOOT_OUT_DIR)

config.mk 内容： ARD_NAME=qt2440 BOARD_ARCH=arm920t

BOARD_VENDOR=samsung BUILD_DIR=$(shell pwd) BIT32_64=$(shell getconf LONG_BIT)

ifeq ($(BOARD_NAME), qt2440) ifeq ($(BIT32_64), 64) COMPILE_URL=https://github.com/wowotechX/gcc-linaro-4.9-2015.02-3-x86_64_aarch64-linux-gnu.git CROSS_COMPILE=$(BUILD_DIR)/gcc-linaro-4.9-2015.02-3-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu- else COMPILE_URL=https://github.com/wowotechX/gcc-linaro-aarch64-linux-gnu-4.8-2013.12_linux.git CROSS_COMPILE=$(BUILD_DIR)/gcc-linaro-aarch64-linux-gnu-4.8-2013.12_linux/bin/aarch64-linux-gnu- endif endif

主要内容就是这么多

下面是编译错误内容： make uboot error: /home/heziqin/x-project/u-boot/lib/asm-offsets.c:1:0: error: unknown value ‘armv4t’ for -march

网上说我在makefile里面没有添加ARCH=arm 好吧那我就添加 make -C $(UBOOT_DIR) ARCH=arm CROSS_COMPILE=$(CROSS_COMPILE) KBUILD_OUTPUT=$(UBOOT_OUT_DIR)

error: /home/heziqin/x-project/u-boot/lib/asm-offsets.c:1:0: error: unknown value ‘armv4t’ for -march 错误一样。

我尝试这样修改： make -C $(UBOOT_DIR) ARCH=arm920t CROSS_COMPILE=$(CROSS_COMPILE) KBUILD_OUTPUT=$(UBOOT_OUT_DIR) include/config.h:6:24: fatal error: asm/config.h: No such file or directory

居然不报上次那个错误了，但我内心是觉得有ARCH=arm920t这样的吗？

为什么wowo搞的Makefile 里面没有添加ARCH=的内容就编过去了，为什么非要我添加这个？诸位帮帮忙。

thanks

支持与合作

Thu, 15 Dec 2016 22:15:57 +0800

如果您来到这个页面（无论是有心还是无意^^），说明蜗窝分享的文章可能给您带来了些许的帮助，这是蜗窝的荣幸，因为知己难求，这里要向您表示感谢。与此同时，如果您想向蜗窝提供一些支持（不管什么原因，先谢过了），有如下的方法: 1）多来蜗窝，多交流，思想的碰撞能带来快乐。 2）宣传蜗窝，多向您的同事、朋友、老板、客户、等等，介绍、推荐。 3）和蜗窝合作，具体形式暂时没有太多的思路，可以慢慢摸索，例如向

Linux serial framework(1)_概述

Mon, 12 Dec 2016 22:04:41 +0800

串口设备（serial or uart，后面不再区分）是TTY设备的一种，Linux kernel为了方便串口驱动的开发，在TTY framework的基础上，封装了一层串口框架（serial framework）。该框架尽可能的屏蔽了TTY有关的技术细节（比较难懂），驱动工程师在编写串口驱动的时候，只需要把精力放在串口以及串口控制器本身即可。本文将通过对serial framework的简单分

linux armv8 MMU 相关知识学习QA

Mon, 12 Dec 2016 14:02:06 +0800

本文是原「蜗窝讨论区」的历史存档（2016-12-12），来自版块「Linux kernel技术问答」，共 13 帖。讨论区已停止服务，此处仅供查阅。

tigger · 2016-12-12 14:02

作为一个嵌入式工程师，平时对MMU相关配置是敬而远之的。因为linux kernel已经做得很完善。我们最经常使用的就是内存申请相关接口。但是越是难懂的东西，说明她的精髓越是掌握在少数人的手里面。为了自己更好的了解ARM V8架构。我决定跟随linuxer的步伐，啃一啃相关的代码。但是我现在是一张白纸，所以经过跟linuxer大哥讨论。我决定把我阅读文章以及文档的相关问题都一一记录下来。这样如果有新人，也对这一块感兴趣。可以查看此贴，希望能有所帮助。

tigger · 2016-12-12 14:05

hi linuxer Considering the resolution of the maximum IA range of 48 bits, with a translation granule size of 2n bytes: • The least-significant n bits of the IA address the memory page. This means OA[(n-1):0]=IA[(n-1):0]. • The remaining (48-n) bits of the IA, IA[47:n], must be resolved by the address translation. • A translation table descriptor is 8 bytes. Therefore: — A complete translation table holds 2(n-3) descriptors.(2的n-3 次方) — A single level of translation can resolve a maximum of (n-3) bits of address

n=12/14/16 2的n-3次方，这里不太懂

Linux 3.10.1内核中操作位图的函数

Sun, 11 Dec 2016 17:37:08 +0800

本文是原「蜗窝讨论区」的历史存档（2016-12-11），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

jack · 2016-12-11 17:37

老师们，我对于内核中操作位图的函数有点不明白，在3.10.1内核中，定义了好多，如果我要测试某个位图中的某个位是否为1，应该使用哪个函数啊？在kVM中定义了这么一个：

if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,39)

static inline int test_and_set_bit_le(int nr, void *addr) { return test_and_set_bit(nr ^ BITOP_LE_SWIZZLE, addr); }

endif

我当前内核是3.10.1,就不能直接使用这个了吧，如果直接使用内核中的，传递参数需要加上BITOP_LE_SWIZZLE吗？谢谢！

有没有对KVM源代码深入分析过的老师啊！

Fri, 09 Dec 2016 16:13:11 +0800

本文是原「蜗窝讨论区」的历史存档（2016-12-09），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

jack · 2016-12-09 16:13

我想在KVM中直接搞一块内存，然后交给虚拟机使用，注意不是虚拟机分配好传递下来，而是KVM直接分配，请问有没有办法？？

快讯：蓝牙5.0发布（新特性速览）

Thu, 08 Dec 2016 11:05:39 +0800

2016年12月6日，蓝牙SIG发布了5.0版本的核心规范，该规范从距离、速度等多个方面，对BLE进行了增强，蓝牙官网的总结如下 [1] ： With the launch of Bluetooth 5, Bluetooth® technology continues to evolve to meet the needs of the industry as the global wireles

X-021-ROOTFS-基于busybox的最简rootfs的制作

Mon, 05 Dec 2016 22:50:08 +0800

在前一篇文章 [1] 中，我们编写并成功运行了一个简单的init程序。于是，“ 【任务4】启动Linux kernel到命令行 ”就成了一个水到渠成的事情。当然，只有一个简单的程序还不够，我们要来点实在的，一个真正的根文件系统。 Linux系统中制作根文件系统的方法有很多种，基于一个个package一点点编译、利用buildroot、利用busybox、等等，本文将以嵌入式系统中普遍使用的busy

X-020-ROOTFS-initramfs的制作和测试

Sat, 03 Dec 2016 11:08:08 +0800

我们在“ X-015-KERNEL-ARM generic timer driver的移植 ”中移植完ARM generic timer之后，Linux的启动已经走完了内核空间的旅程，即将冲破kernel走向用户空间，有“诗”为证： [ 0.142156] —[ end Kernel panic - not syncing: No working init found. Try passing

关于Linux各种上下文的理解

Wed, 30 Nov 2016 18:02:43 +0800

本文是原「蜗窝讨论区」的历史存档（2016-11-30），来自版块「Linux kernel技术问答」，共 2 帖。讨论区已停止服务，此处仅供查阅。

electrlife · 2016-11-30 18:02

在 /memory_management/mm-init-1.html#4940贴子上有网友提出了如下问题？

>> Hello,linuxer >> 请教一个问题，可能对你比较简单，但是我百思不得其解 >> Linux中的各个驱动是在进程的上下文里面执行的吗，如果是，在哪个进程

个人觉得这是个很好的问题，想了想似乎我也不能很好去回答这个问题，因此在这里提出来希望各位大侠们来解惑！

下面是我从另一个角度去理解(以下全部是个人出于对程序的理解而得出的猜测)：

对于“上下文”这个词，我觉得需要理解清楚，“上下文”应该源于context这个词，我的理解是指一段程序运行时所处的相应的系统状态。因为这种系统的状态影响着程序的各种行为方式。比如中断context不可以blocking。因此可以分为以下几种，但这种划分方式也是不严格的，依赖于具体的软硬件系统结构： 1. 进程context 2. 中断context 以上两种context应该存在于所有的体系中（如有例外，请各位补充:)），对于linux而言，似乎又多了个“内核context”。但对于Linux是否还存在其它的 context，我不得而知，各位高手们补充！

对于内核也只不过是一堆函数的集合，每个函数也需要相应的stack，这些函数运行时也会遇到blocking，因此也需要相应的空间去保存其运行的上下文(context 后面以此词代替)。这些函数依据调用者可以简单分为以下几种： 1. 在内核空间有很多内核thread，那运行在这些线程的函数毋庸置疑会保存在相应线程的context中。 2. 中断程序，这个毫无疑问运行在中断context 3. 系统调用，用户空间的程序会调用来运行内核空间的相应的函数，如：processA-->open-->sys_open, 此时sys_open运行在内核空间因此系统应该提供相应的专门的stack空间供sys_open使用（系统如何提供这样的stack？）。如果此时sys_open由于资源缺乏而pending了，显然此时我们需要保存其相应的stack及CPU registers，那保存到哪里呢，我觉得应该保存到相应的process对应的stack上（或许保存到该process相关联的某个空间，因为从安全的角度考虑，内核的stack保存在process stack上毕竟不太放心），也即本例中的processA。简化整个调用过程如下： processA-->open-->sys_open-->SVC xxx-->(保存相应的registers,切换到相应的stack，返回并执行相应的system call:do_sysopen)-->pending(保存此时的stack及registers到相应的processA某个空间)

从上面的描述可以认为sys_open运行在内核context。

类比驱动程序的执行，也可以简单认为驱动是一些函数，也会因为调用者的不同而不同。如：在中断中调用则运行在中断的context，也可能运行在内核thread中。当然也可能运行在系统调用里，那相应的情景就如上所述！

思考： 1. 驱动程序如果被内核thread调用，其stack应该是由该thread提供，是不是意味着可以定义很大的变量在其stack，因为thread的stack我理解是可依据需求自动扩大的。

驱动程序如果被系统调用中被调用，那其运行context不是在process的context，我的理解其stack是系统分配的固定大小，因此此驱动函数定义局部变量时需要格外注意其大小。

以上是我个人的理解，请不吝赐教！

jack · 2016-12-01 18:19

对于系统调用，每一个进程调用，那么系统调用自然运行在当前进程的内核空间，这么说主要是因为调用并没有切换地址空间，仅仅是切换了内核栈，而内核栈就是当前进程的内核栈。如果遇到pending，保存应该也是保存在这个栈中。对于中断context，看怎么理解了，其和进程context还有些区别，个人感觉中断context只是标记当前在处理中断，防止中断重入，至于使用的栈和寄存器等，还要考虑到当时运行级别以及中断表中对应的门类型。个人理解

请教wowo 内核出现死锁需要怎么调？谢谢

Wed, 30 Nov 2016 15:36:49 +0800

本文是原「蜗窝讨论区」的历史存档（2016-11-30），来自版块「Linux kernel技术问答」，共 6 帖。讨论区已停止服务，此处仅供查阅。

shumanzhou · 2016-11-30 15:36

Dear：

按电源键休眠的时候会出现内核死锁的情况，估计是cpu down的时候有些地方没做好，看了一些smp跟进程的知识但还是解决不了，故请教下wowo等各位,附部分log。

先谢谢了！ //=======================================================================


[== Undefined ==]
<6>[ 40.368469] [2:PhotonicModulat: 674] psci: CPU7 killed.
<5>[ 40.374563] [2:PhotonicModulat: 674] CPU6: shutdown
<6>[ 40.374685] [2:PhotonicModulat: 674] psci: CPU6 killed.
<5>[ 40.380205] [2:PhotonicModulat: 674] CPU5: shutdown
<6>[ 40.380303] [2:PhotonicModulat: 674] psci: CPU5 killed.
<5>[ 40.386471] [2:PhotonicModulat: 674] CPU4: shutdown
<4>[ 60.257475] I[1: swapper/1: 0] ------------[ cut here ]------------
<4>[ 60.257583] I[1: swapper/1: 0] WARNING: at kernel/watchdog.c:259 watchdog_timer_fn+0xf8/0x258(
<4>[ 60.257614] I[1: swapper/1: 0] Watchdog detected hard LOCKUP on cpu 2
<4>[ 60.257644] I[1: swapper/1: 0] Modules linked in: pvrsrvkm(O)
<4>[ 60.257714] I[1: swapper/1: 0] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G O 3.10.0 #410
<4>[ 60.257793] I[1: swapper/1: 0] [<ffffffc000088468>] ump_backtrace+0x0/0x10c
<4>[ 60.257873] I[1: swapper/1: 0] [<ffffffc0008d3f54>] dump_stack+0x1c/0x28
<4>[ 60.257945] I[1: swapper/1: 0] [<ffffffc0000a6924>] warn_slowpath_fmt+0x4c/0x58
<4>[ 60.258018] I[1: swapper/1: 0] [<ffffffc0000caf64>] __run_hrtimer+0x12c/0x238
<4>[ 60.258088] I[1: swapper/1: 0] [<ffffffc000654008>] arch_timer_handler_virt+0x28/0x38
<4>[ 60.258160] I[1: swapper/1: 0] [<ffffffc00010cf00>] generic_handle_irq+0x28/0x3c
<4>[ 60.258229] I[1: swapper/1: 0] [<ffffffc0000813b0>] gic_handle_irq+0x50/0x84
<4>[ 60.258305] I[1: swapper/1: 0] 7da0: 3fd1bee8 ffffffc0 00000000 00000000 3b337ee0 ffffffc0 00638868 ffffffc0
<4>[ 60.258376] I[1: swapper/1: 0] 7de0: 0000003b 00000000 3434a37e 00000000 29aaaaab 00000000 00000018 00000000
<4>[ 60.258455] I[1: swapper/1: 0] 7e20: 00000078 00000000 df4798e0 00000000 f750b1d9 00000000 00000000 00000000
<4>[ 60.258517] I[1: swapper/1: 0] 7e60: 00000000 00000000 fc74ccb4 0000000d 00000000 00000000 00ea1000 ffffffc0
<4>[ 60.258589] I[1: swapper/1: 0] 7ea0: 00200000 00000040 3b337ee0 ffffffc0 00638864 ffffffc0 3b337ee0 ffffffc0
<4>[ 60.258659] I[1: swapper/1: 0] [<ffffffc000638a30>] cpuidle_idle_call+0x160/0x228
<4>[ 60.258731] I[1: swapper/1: 0] [<ffffffc0000e9fac>] cpu_startup_entry+0x1e8/0x240
<4>[ 60.258799] I[1: swapper/1: 0] ---[ end trace cfd25baee3abf284 ]---
<3>[ 61.064363] I[0: AudioOut_2: 580] INFO: rcu_preempt detected stalls on CPUs/tasks: { 2} (detected by 0, t=2102 jiffies, g=333, c=332, q=1572)
<6>[ 61.064470] I[0: AudioOut_2: 580] Task dump for CPU 2:
<6>[ 61.064507] I[0: AudioOut_2: 580] PhotonicModulat R running task 0 674 209 0x00000002
<0>[ 61.064545] I[0: AudioOut_2: 580] Call trace:
<4>[ 61.064610] I[0: AudioOut_2: 580] [<ffffffc0000856c0>] __switch_to+0x80/0x8c
<3>[ 61.064665] I[0: AudioOut_2: 580] INFO: rcu_sched detected stalls on CPUs/tasks: { 2} (detected by 0, t=2102 jiffies, g=18446744073709551320, c=18446744073709551319, q=4)
<6>[ 61.064748] I[0: AudioOut_2: 580] PhotonicModulat R running task 0 674 209 0x00000002
<4>[ 61.064807] I[0: AudioOut_2: 580] [<ffffffc0000856c0>] __switch_to+0x80/0x8c
<12>[ 64.181463] [1: healthd: 191] healthd: battery none chg=a 2013-01-21 08:51:06.191798946 UTC
<0>[ 68.109814] I[0: AudioOut_2: 580] BUG: soft lockup - CPU#0 stuck for 22s! [AudioOut_2:580]
<4>[ 68.109871] I[0: AudioOut_2: 580] Modules linked in: pvrsrvkm(O)
<4>[ 68.109921] I[0: AudioOut_2: 580] 
<4>[ 68.109970] I[0: AudioOut_2: 580] CPU: 0 PID: 580 Comm: AudioOut_2 Tainted: G W O 3.10.0 #410
<4>[ 68.110016] I[0: AudioOut_2: 580] task: ffffffc03ac3a700 ti: ffffffc020c04000 task.ti: ffffffc020c04000
<4>[ 68.110074] I[0: AudioOut_2: 580] PC is at smp_call_function_many+0x28c/0x2b0
<4>[ 68.110109] I[0: AudioOut_2: 580] LR is at smp_call_function_many+0x268/0x2b0
<4>[ 68.110147] I[0: AudioOut_2: 580] pc : [<ffffffc0000f8160>] lr : [<ffffffc0000f813c>] pstate: 80000145
<4>[ 68.110170] I[0: AudioOut_2: 580] sp : ffffffc020c07c00
<4>[ 68.110225] I[0: AudioOut_2: 580] x27: ffffffc000f5c000 x26: ffffffc000cfe8c8 
<4>[ 68.110277] I[0: AudioOut_2: 580] x23: ffffffc0006384dc x22: ffffffc03fd11708 
<4>[ 68.110325] I[0: AudioOut_2: 580] x19: ffffffc03fd11700 x18: 0000000000000000 
<4>[ 68.110373] I[0: AudioOut_2: 580] x15: 0000000000000000 x14: 00000000f72311f9 
<4>[ 68.110428] I[0: AudioOut_2: 580] x11: 000000000000b815 x10: 0000000000000000 
<4>[ 68.110476] I[0: AudioOut_2: 580] x7 : ffffffc03fd35740 x6 : ffffffc03fd11708 
<4>[ 68.110531] I[0: AudioOut_2: 580] x3 : ffffffc000f5c528 x2 : 0000000000000002 
<4>[ 68.110587] I[0: AudioOut_2: 580] 
<4>[ 68.110587] I[0: AudioOut_2: 580] PC: 0xffffffc0000f80e0:
<4>[ 68.110685] I[0: AudioOut_2: 580] 8100 aa0603e0 941f8d9e f9403fa2 17ffffd5 91004260 97fe5a23 12800002 34000279
<4>[ 68.110774] I[0: AudioOut_2: 580] 8140 b94002a1 6b01001f 5400010a 9114a283 f9400261 f860d860 8b000021 79404020
<4>[ 68.110860] I[0: AudioOut_2: 580] 8180 d65f03c0 a9bf7bfd aa0003e6 aa0103e5 910003e0 910003fd 9272c404 b9405083
<4>[ 68.110946] I[0: AudioOut_2: 580] 81c0 97ffff45 910003e0 9272c400 b9405001 51000421 b9005001 f9400000 36080040
<4>[ 68.111039] I[0: AudioOut_2: 580] 80bc 91004086 f9000b97 aa0603e0 f9000f98 f90043a4 f90047a6 941f8d1d f94043a4
<4>[ 68.111121] I[0: AudioOut_2: 580] 80fc f90000fc aa0603e0 941f8d9e f9403fa2 17ffffd5 91004260 97fe5a23 12800002
<4>[ 68.111207] I[0: AudioOut_2: 580] 813c 2a0003e2 b94002a1 6b01001f 5400010a 9114a283 f9400261 f860d860 8b000021
<4>[ 68.111289] I[0: AudioOut_2: 580] 817c a8c97bfd d65f03c0 a9bf7bfd aa0003e6 aa0103e5 910003e0 910003fd 9272c404
<4>[ 68.111376] I[0: AudioOut_2: 580] 
<4>[ 68.111376] I[0: AudioOut_2: 580] SP: 0xffffffc020c07b80:
<4>[ 68.111462] I[0: AudioOut_2: 580] 7ba0 00000000 00000000 00000001 00000000 00cfe8c8 ffffffc0 00f5c000 ffffffc0
<4>[ 68.111542] I[0: AudioOut_2: 580] 7be0 000f8160 ffffffc0 80000145 00000000 20c07c00 ffffffc0 000f8118 ffffffc0
<4>[ 68.111625] I[0: AudioOut_2: 580] 7c20 00000000 00000000 00004406 00000000 77359400 00000000 00000140 00000000
<4>[ 68.111710] I[0: AudioOut_2: 580] 7c60 00000008 00000000 00cd5fd0 ffffffc0 3f062000 00000000 00000003 00000000
<4>[ 68.111799] I[0: AudioOut_2: 580] bf50 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<4>[ 68.111886] I[0: AudioOut_2: 580] bf90 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<4>[ 68.111969] I[0: AudioOut_2: 580] bfd0 3fd29740 ffffffc0 3fd29740 ffffffc0 006384dc ffffffc0 00000000 00000000
<4>[ 68.112045] I[0: AudioOut_2: 580] c010 00000000 00000000 49a11880 00000009 d5555585 00000014 000003e8 00000000
<4>[ 68.112130] I[0: AudioOut_2: 580] 
<4>[ 68.112130] I[0: AudioOut_2: 580] X3: 0xffffffc000f5c4a8:
<4>[ 68.112223] I[0: AudioOut_2: 580] c4c8 1592dc40 ffffffc0 083b083b 0000c000 0000000f 00000000 3fd0ce00 ffffffc0
<4>[ 68.112308] I[0: AudioOut_2: 580] c508 00000048 00000000 3fd6d040 ffffffc0 3fd6d000 ffffffc0 00001000 00000000
<4>[ 68.112635] I[0: AudioOut_2: 580] 16c8 00000037 00000000 00000000 00000000 5c46ca7a 00000009 00000a49 00000000
<4>[ 68.112679] I[0: AudioOut_2: 580] 16e8 00000000 00000000 00000000 00000000 00000000 00000000 00cd5fd0 ffffffc0
<4>[ 68.112723] I[0: AudioOut_2: 580] 1708 0000000e 00000000 0000000e 00000000 00000000 00000000 00000000 00000000
<4>[ 68.112763] I[0: AudioOut_2: 580] 1728 00000000 00000000 00000000 00000000 00000000 00000000 3fd11740 ffffffc0
<4>[ 68.112804] I[0: AudioOut_2: 580] 1748 3fd11740 ffffffc0 00580058 00000000 00000000 00000000 00000000 00000000
<4>[ 68.112844] I[0: AudioOut_2: 580] 1768 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<4>[ 68.112883] I[0: AudioOut_2: 580] 
<4>[ 68.112883] I[0: AudioOut_2: 580] X7: 0xffffffc03fd356c0:
<4>[ 68.112926] I[0: AudioOut_2: 580] 56c0 00000000 00000000 00000000 00000000 00000000 00000000 54427236 00000009
<4>[ 68.112966] I[0: AudioOut_2: 580] 56e0 0000005f 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<4>[ 68.113006] I[0: AudioOut_2: 580] 5700 00cd6a28 ffffffc0 000000f7 00000000 000000f7 00000000 00000000 00000000
<4>[ 68.113054] I[0: AudioOut_2: 580] 5720 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<4>[ 68.113098] I[0: AudioOut_2: 580] 5740 3fd35740 ffffffc0 3fd35740 ffffffc0 00660066 00000000 00000000 00000000
<4>[ 68.113138] I[0: AudioOut_2: 580] 5760 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<4>[ 68.113179] I[0: AudioOut_2: 580] 5780 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<4>[ 68.113222] I[0: AudioOut_2: 580] 57a0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<4>[ 68.113264] I[0: AudioOut_2: 580] 
<4>[ 68.113264] I[0: AudioOut_2: 580] X9: 0xffffffc020c07780:
<4>[ 68.113307] I[0: AudioOut_2: 580] 7780 00b6178b ffffffc0 00000000 00000080 ffffff80 0000003f ffffff00 0000003f
<4>[ 68.113345] I[0: AudioOut_2: 580] 77a0 00ccff38 ffffffc0 3fd0dc98 ffffffc0 3fd0dc58 ffffffc0 00000002 00000000
<4>[ 68.113383] I[0: AudioOut_2: 580] 77c0 00000000 00000000 0000ffff 00000008 00000000 00000000 30303020 30303020
<4>[ 68.113423] I[0: AudioOut_2: 580] 77e0 20c07830 ffffffc0 0008549c ffffffc0 20c07ae0 ffffffc0 00ccffa9 ffffffc0
<4>[ 68.113468] I[0: AudioOut_2: 580] 7800 00f38000 ffffffc0 20c07ae0 ffffffc0 00000029 00000000 3fd0df50 ffffffc0
<4>[ 68.113509] I[0: AudioOut_2: 580] 7820 0002840e ffffff80 30003958 31373839 20c07850 ffffffc0 0010cb60 ffffffc0
<4>[ 68.113550] I[0: AudioOut_2: 580] 7840 00ccf000 ffffffc0 00cfeab0 ffffffc0 20c078c0 ffffffc0 000caf68 ffffffc0
<4>[ 68.113591] I[0: AudioOut_2: 580] 7860 3fd0df50 ffffffc0 d8b138b9 0000000f 3fd0dbe0 ffffffc0 3fd0dba0 ffffffc0
<4>[ 68.113638] I[0: AudioOut_2: 580] 
<4>[ 68.113638] I[0: AudioOut_2: 580] X16: 0xffffffc000176674:
<4>[ 68.113684] I[0: AudioOut_2: 580] 6674 940067e9 aa1603e0 94002b0e 93407e80 a94153f3 a9425bf5 a94363f7 a8c67bfd
<4>[ 68.113733] I[0: AudioOut_2: 580] 6694 d65f03c0 a9bf7bfd aa0003e4 aa0203e3 910003fd 320f0022 12800c60 aa0403e1
<4>[ 68.113770] I[0: AudioOut_2: 580] 66b4 97ffff89 a8c17bfd d65f03c0 a9bf7bfd 320f0042 910003fd 97ffff83 a8c17bfd
<4>[ 68.113816] I[0: AudioOut_2: 580] 66d4 d65f03c0 a9bf7bfd aa0103e2 52804821 910003fd 97ffffec a8c17bfd d65f03c0
<4>[ 68.113857] I[0: AudioOut_2: 580] 66f4 a9bf7bfd aa0003e1 910003e0 910003fd 9272c400 f9400800 f943d400 940067ce
<4>[ 68.113902] I[0: AudioOut_2: 580] 6714 11080401 7100043f 540000c9 121e7801 3108103f 12800061 1a811000 14000002
<4>[ 68.113943] I[0: AudioOut_2: 580] 6734 12800060 93407c00 a8c17bfd d65f03c0 a9bf7bfd 52800340 910003fd 97fcec05
<4>[ 68.113987] I[0: AudioOut_2: 580] 6754 53001c01 92800000 34000061 9407eb64 d2800000 a8c17bfd d65f03c0 f9402400
<4>[ 68.114032] I[0: AudioOut_2: 580] 
<4>[ 68.114032] I[0: AudioOut_2: 580] X19: 0xffffffc03fd11680:
<4>[ 68.114077] I[0: AudioOut_2: 580] 1680 00000000 00000000 000df971 00000000 ffffa636 00000000 fffffe82 ffffffff
<4>[ 68.114118] I[0: AudioOut_2: 580] 16a0 00000000 00000000 00000a49 0000b926 e2a19611 00000009 00000000 00000000
<4>[ 68.114158] I[0: AudioOut_2: 580] 16c0 00000000 00000000 00000037 00000000 00000000 00000000 5c46ca7a 00000009
<4>[ 68.114199] I[0: AudioOut_2: 580] 16e0 00000a49 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<4>[ 68.114243] I[0: AudioOut_2: 580] 1700 00cd5fd0 ffffffc0 0000000e 00000000 0000000e 00000000 00000000 00000000
<4>[ 68.114283] I[0: AudioOut_2: 580] 1720 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<4>[ 68.114320] I[0: AudioOut_2: 580] 1740 3fd11740 ffffffc0 3fd11740 ffffffc0 00580058 00000000 00000000 00000000
<4>[ 68.114361] I[0: AudioOut_2: 580] 1760 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<4>[ 68.114403] I[0: AudioOut_2: 580] 
<4>[ 68.114403] I[0: AudioOut_2: 580] X20: 0xffffffc000f5bf80:
<4>[ 68.114448] I[0: AudioOut_2: 580] bf80 00e954a0 ffffffc0 00e95528 ffffffc0 00e955b0 ffffffc0 00e95638 ffffffc0
<4>[ 68.114493] I[0: AudioOut_2: 580] bfa0 00e956c0 ffffffc0 00e95748 ffffffc0 00e957d0 ffffffc0 00e95858 ffffffc0
<4>[ 68.114534] I[0: AudioOut_2: 580] bfc0 00e958e0 ffffffc0 00e95968 ffffffc0 00e959f0 ffffffc0 00e95a78 ffffffc0
<4>[ 68.114579] I[0: AudioOut_2: 580] bfe0 00e95b00 ffffffc0 00e95b88 ffffffc0 00e95c10 ffffffc0 00e95c98 ffffffc0
<4>[ 68.114624] I[0: AudioOut_2: 580] c000 00e95d20 ffffffc0 00e95da8 ffffffc0 00e95e30 ffffffc0 00000000 00000000
<4>[ 68.114671] I[0: AudioOut_2: 580] c020 00000000 00000000 00000000 00000000 00000000 00000000 00003600 ffffffc0
<4>[ 68.114712] I[0: AudioOut_2: 580] c040 00001e40 ffffffc0 00000000 00000000 00000000 00000000 00000000 00000000
<4>[ 68.114753] I[0: AudioOut_2: 580] c060 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<4>[ 68.114792] I[0: AudioOut_2: 580] 
<4>[ 68.114792] I[0: AudioOut_2: 580] X21: 0xffffffc000cfe848:
<4>[ 68.114834] I[0: AudioOut_2: 580] e848 00000000 00000000 000f24e0 ffffffc0 00000000 00000000 00000000 00000000
<4>[ 68.114878] I[0: AudioOut_2: 580] e868 00000001 00000000 ffffffff ffffffff 00000000 00000000 00000000 00000000
<4>[ 68.114922] I[0: AudioOut_2: 580] e888 ffffffff 00000000 008e33b8 ffffffc0 3fd14098 ffffffc0 3fd20098 ffffffc0
<4>[ 68.114963] I[0: AudioOut_2: 580] e8a8 00000000 00000000 00000000 00000000 00000000 00000000 00000001 00000400
<4>[ 68.115003] I[0: AudioOut_2: 580] e8c8 00000008 00000008 000f78ec ffffffc0 00125f44 ffffffc0 00125f44 ffffffc0
<4>[ 68.115048] I[0: AudioOut_2: 580] e8e8 00125f44 ffffffc0 000f78a0 ffffffc0 00125f44 ffffffc0 00125f44 ffffffc0
<4>[ 68.115096] I[0: AudioOut_2: 580] e908 00125f44 ffffffc0 00cfd5b8 ffffffc0 00cfe998 ffffffc0 00e97c28 ffffffc0
<4>[ 68.115137] I[0: AudioOut_2: 580] e928 00b6c3ab ffffffc0 00000000 00000000 00d0cda8 ffffffc0 00cfe9c8 ffffffc0
<4>[ 68.115183] I[0: AudioOut_2: 580] 
<4>[ 68.115183] I[0: AudioOut_2: 580] X22: 0xffffffc03fd11688:
<4>[ 68.115226] I[0: AudioOut_2: 580] 1688 000df971 00000000 ffffa636 00000000 fffffe82 ffffffff 00000000 00000000
<4>[ 68.115264] I[0: AudioOut_2: 580] 16a8 00000a49 0000b926 e2a19611 00000009 00000000 00000000 00000000 00000000
<4>[ 68.115304] I[0: AudioOut_2: 580] 16c8 00000037 00000000 00000000 00000000 5c46ca7a 00000009 00000a49 00000000
<4>[ 68.115344] I[0: AudioOut_2: 580] 16e8 00000000 00000000 00000000 00000000 00000000 00000000 00cd5fd0 ffffffc0
<4>[ 68.115382] I[0: AudioOut_2: 580] 1708 0000000e 00000000 0000000e 00000000 00000000 00000000 00000000 00000000
<3>[ 123.105561] I[0: AudioOut_2: 580] INFO: rcu_preempt detected stalls on CPUs/tasks: { 2} (detected by 0, t=8407 jiffies, g=333, c=332, q=4787)
<6>[ 123.105675] I[0: AudioOut_2: 580] Task dump for CPU 2:
<6>[ 123.105706] I[0: AudioOut_2: 580] PhotonicModulat R running task 0 674 209 0x00000002
<0>[ 123.105744] I[0: AudioOut_2: 580] Call trace:
<4>[ 123.105805] I[0: AudioOut_2: 580] [<ffffffc0000856c0>] __switch_to+0x80/0x8c
<3>[ 123.105864] I[0: AudioOut_2: 580] INFO: rcu_sched detected stalls on CPUs/tasks: { 2} (detected by 0, t=8407 jiffies, g=18446744073709551320, c=18446744073709551319, q=4)
<6>[ 123.105913] I[0: AudioOut_2: 580] Task dump for CPU 2:
<6>[ 123.105943] I[0: AudioOut_2: 580] PhotonicModulat R running task 0 674 209 0x00000002
<0>[ 123.105971] I[0: AudioOut_2: 580] Call trace:
<4>[ 123.106003] I[0: AudioOut_2: 580] [<ffffffc0000856c0>] __switch_to+0x80/0x8c
<12>[ 123.221284] [1: healthd: 191] healthd: battery none chg=a 2013-01-21 08:52:06.191643891 UTC
<12>[ 182.261329] [1: healthd: 191] healthd: battery none chg=a 2013-01-21 08:53:06.191686003 UTC
<3>[ 185.146773] I[1: swapper/1: 0] INFO: rcu_preempt detected stalls on CPUs/tasks:
<3>[ 185.146848] I[0: AudioOut_2: 580] INFO: rcu_sched detected stalls on CPUs/tasks: { 2
<4>[ 185.146862] I[1: swapper/1: 0] { 2} 
<4>[ 185.146899] I[1: swapper/1: 0] } (detected by 1, t=14712 jiffies, g=18446744073709551320, c=18446744073709551319, q=4)
<6>[ 185.146950] I[1: swapper/1: 0] Task dump for CPU 2:
<6>[ 185.146979] I[1: swapper/1: 0] PhotonicModulat R running task 0 674 209 0x00000002
<0>[ 185.147030] I[1: swapper/1: 0] Call trace:
<4>[ 185.147045] I[0: AudioOut_2: 580] (detected by 0, t=14712 jiffies, g=333, c=332, q=8294)
<6>[ 185.147071] I[0: AudioOut_2: 580] Task dump for CPU 2:
<6>[ 185.147115] I[0: AudioOut_2: 580] PhotonicModulat R running task 0 674 209 0x00000002
<4>[ 185.147179] I[1: swapper/1: 0] [<ffffffc0000856c0>] __switch_to+0x80/0x8c
<0>[ 185.147206] I[0: AudioOut_2: 580] Call trace:
<4>[ 185.147239] I[0: AudioOut_2: 580] [<ffffffc0000856c0>] __switch_to+0x80/0x8c
<12>[ 241.301311] [1: healthd: 191] healthd: battery none chg=a 2013-01-21 08:54:06.191676199 UTC
<3>[ 247.187959] I[0: AudioOut_2: 580] INFO: rcu_preempt detected stalls on CPUs/tasks: { 2} (detected by 0, t=21017 jiffies, g=333, c=332, q=16780)
<6>[ 247.188059] I[0: AudioOut_2: 580] Task dump for CPU 2:
<6>[ 247.188093] I[0: AudioOut_2: 580] PhotonicModulat R running task 0 674 209 0x00000002
<0>[ 247.188126] I[0: AudioOut_2: 580] Call trace:
<4>[ 247.188187] I[0: AudioOut_2: 580] [<ffffffc0000856c0>] __switch_to+0x80/0x8c
<3>[ 247.188236] I[0: AudioOut_2: 580] INFO: rcu_sched detected stalls on CPUs/tasks: { 2} (detected by 0, t=21017 jiffies, g=18446744073709551320, c=18446744073709551319, q=4)
<6>[ 247.188283] I[0: AudioOut_2: 580] Task dump for CPU 2:
<6>[ 247.188305] I[0: AudioOut_2: 580] PhotonicModulat R running task 0 674 209 0x00000002
<0>[ 247.188331] I[0: AudioOut_2: 580] Call trace:
<4>[ 247.188360] I[0: AudioOut_2: 580] [<ffffffc0000856c0>] __switch_to+0x80/0x8c
<12>[ 300.341328] [1: healthd: 191] healthd: battery none chg=a 2013-01-21 08:55:06.191691769 UTC

//=======================================================================

X-019-KERNEL-串口驱动开发之数据收发

Tue, 29 Nov 2016 21:55:06 +0800

本文是“ X Project ”串口驱动开发的第四篇，在第二篇“ uart driver框架 [1] ”的基础上，实现基本的、可收发数据的uart驱动，并借助这个过程，学习如下知识：中断的申请和使用；利用中断发送和接收数据； uart_ops中常用函数（.startup, .start_tx, etc.）的使用。

linux内核源码分析

Mon, 28 Nov 2016 09:52:07 +0800

本文是原「蜗窝讨论区」的历史存档（2016-11-28），来自版块「Linux kernel技术问答」，共 9 帖。讨论区已停止服务，此处仅供查阅。

jack · 2016-11-28 09:52

老师们，发个处女贴！！在用sourceinsight看Linux源代码的时候，有时候一个函数有多个实现，比如进程调度的switch_to，怎么确定在函数中调用的是哪一个啊？？有没有什么好的办法？？谢谢

wowo · 2016-11-28 15:21

jack 写道： 老师们，发个处女贴！！在用sourceinsight看Linux源代码的时候，有时候一个函数有多个实现，比如进程调度的switch_to，怎么确定在函数中调用的是哪一个啊？？有没有什么好的办法？？谢谢

静态的看的话，除了我们自己，没有好办法知道到底用哪一个。

jack · 2016-11-28 16:18

好吧，谢谢wowo老师！！

wowo · 2016-11-28 16:39

jack 写道： 好吧，谢谢wowo老师！！

不要喊老师，太别扭～～

jack · 2016-11-28 18:02

哈哈，我本来就是学生，况且值得学习的都是老师！！对了老师，这论坛有新消息没通知啊？是否可以考虑添加此功能

wowo 写道：

jack 写道： 好吧，谢谢wowo老师！！

不要喊老师，太别扭～～

wowo · 2016-11-28 19:13

jack 写道： 哈哈，我本来就是学生，况且值得学习的都是老师！！对了老师，这论坛有新消息没通知啊？是否可以考虑添加此功能 wowo 写道：

jack 写道： 好吧，谢谢wowo老师！！

不要喊老师，太别扭～～

默认是不通知的，怕影响大家。不过如果是自愿的，可以点板块右下方的订阅按钮：

** 写道：**

订阅该版块 - 标记该版块为已读

jack · 2016-11-28 19:28

老师我的意思是在板块已更新哪里加个小括号之类的，又更新的话，上面显示通知数量！

wowo 写道：

jack 写道： 哈哈，我本来就是学生，况且值得学习的都是老师！！对了老师，这论坛有新消息没通知啊？是否可以考虑添加此功能 wowo 写道：

jack 写道： 好吧，谢谢wowo老师！！

不要喊老师，太别扭～～

默认是不通知的，怕影响大家。不过如果是自愿的，可以点板块右下方的订阅按钮：

** 写道：**

订阅该版块 - 标记该版块为已读

想听听wowo对嵌入式的看法

Sat, 26 Nov 2016 01:14:40 +0800

本文是原「蜗窝讨论区」的历史存档（2016-11-26），来自版块「Linux kernel技术问答」，共 3 帖。讨论区已停止服务，此处仅供查阅。

karma303 · 2016-11-26 01:14

wowo，我这两天找工作不很顺利。有一些疑惑，想听听你的看法。主要是关于嵌入式。

前天面试被问到，为什么不愿意做嵌入式。其实我简历里没说不愿意，是在一个论坛上提到，他们的hr竟然找到了那篇帖子。我说”不是不愿意，只是不喜欢“。他们说纯”纯内核的需求很少，包括我们公司，需要的也是驱动方面的人“。后来我被pass掉了。多少感觉到有点儿意外。不知道是不是那句话的原因。不过那天我的状态确实也不好。

我不喜欢做嵌入式，是因为，我觉得这个东西又难，又没意思。 wowo，你为什么会对嵌入式感兴趣呢？我不反对软硬通吃，但我觉得不是这个吃法。将来如果有时间，我很愿意搭一个cpu。但是嵌入式整天都是在读写寄存器，调试，不是吗？学那些总线协议，到底不如人家做 IC 的来得亲切，那些协议就是人家设计的。你有没有觉得，嵌入式程序员的编程能力，比不上常规的程序员，对硬件的了解，又比不上IC工程师。

另外一点。我对调试硬件有某种恐惧心理，如果遇到一个bug，白天调不通，我晚上都睡不舒服。但调试软件就不一样，每一行代码都是我自己写的，我对自己的编程有信心。另一方面，头脑清醒时写的代码，调试起来更容易，这是一个良性的循环。但硬件呢，你有没有觉得硬件（以及驱动的）bug调试起来更难？你遇到的频率高吗？我很难想象，如果每天都与这些bug相伴，该怎么维持一个好的心态，好的睡眠。

夜深了，言语有冒犯之处，请包涵。

wowo · 2016-11-26 15:22

karma303 写道： wowo，我这两天找工作不很顺利。有一些疑惑，想听听你的看法。主要是关于嵌入式。

夜深了，言语有冒犯之处，请包涵。

一些个人看法（不一定正确），供你参考： 1. 很多HR不太喜欢这样的应聘者（特别是应届毕业生）：我不喜欢做xxx，我不愿意做xxx，我觉得做xxx没意思，等等。至于原因，你可以换位思考想一下。 2. 他们说纯”纯内核的需求很少，包括我们公司，需要的也是驱动方面的人“，人家说的可能是真实情况，既然你不喜欢做，被pass掉很正常的，不用耿耿于怀。 3. “我觉得这个东西又难，又没意思”，其实这句话有点小小的矛盾，“难”的东西一般都会有意思。 4. 至于内核和驱动的关系，我觉得（我对内核也不是特别在行，仅仅是个人感觉）：一个厉害的驱动工程师，内核方面不一定厉害；但反过来，一个厉害的内核工程师，做驱动一定很easy。要记得，内核是提供服务的，它的客户有两类，用户和硬件驱动。如果你连你的一大客户都不熟悉，怎么做好内核呢？ 5. 至于嵌入式程序员的能力，我觉得编程能力只是一方面，整合能力也很重要。每一份职业都有其存在的价值和意义，横向没有比较的意义。但就你所说的编程能力，我赞成你的观点，其实大多嵌入式的程序员，都不是软件科班出身（以我为例，我的专业是通信工程），之所以选择嵌入式，是因为能力不足以去做纯软件，又喜欢编程（还是以我为例，毕业的时候面试腾讯，被秒杀，只好做嵌入式）。 6. “如果每天都与这些bug相伴，该怎么维持一个好的心态，好的睡眠”，如果这是你的真实想法，无论是硬件bug还是软件bug，你都要思考一下自己真的要从事软件行业吗？软件行业每夜都会与bug相伴。 7. 安慰一下。一次面试而已，不要纠结。如果立志做纯内核，可以去游戏公司、服务器公司试试，但有一点要记住：国内的行业里面，对内核开发的需求真的很少，这些是那些牛逼的老外的事情，因此你要有心理准备。

温柔海洋 · 2016-12-05 15:32

wowo 写道：

karma303 写道： wowo，我这两天找工作不很顺利。有一些疑惑，想听听你的看法。主要是关于嵌入式。

夜深了，言语有冒犯之处，请包涵。

至于嵌入式程序员的能力，我觉得编程能力只是一方面，整合能力也很重要。每一份职业都有其存在的价值和意义，横向没有比较的意义。但就你所说的编程能力，我赞成你的观点，其实大多嵌入式的程序员，都不是软件科班出身（以我为例，我的专业是通信工程），之所以选择嵌入式，是因为能力不足以去做纯软件，又喜欢编程（还是以我为例，毕业的时候面试腾讯，被秒杀，只好做嵌入式）。
“如果每天都与这些bug相伴，该怎么维持一个好的心态，好的睡眠”，如果这是你的真实想法，无论是硬件bug还是软件bug，你都要思考一下自己真的要从事软件行业吗？软件行业每夜都会与bug相伴。
安慰一下。一次面试而已，不要纠结。如果立志做纯内核，可以去游戏公司、服务器公司试试，但有一点要记住：国内的行业里面，对内核开发的需求真的很少，这些是那些牛逼的老外的事情，因此你要有心理准备。

这跟人民日报里面说为何中国产的东西买到国外可以出精品，买到国内的很多是廉价的。当面对某些客户比如日本客户，那么变态的测试对质量的高标准需求时，自己就不是单纯做驱动了，内核相关的也会跟着被迫的提高的。

蓝牙协议分析(9)_BLE安全机制之LL Privacy

Fri, 25 Nov 2016 16:28:10 +0800

在上一篇文章 [1] 中，我们介绍了BLE的白名单机制，这是一种通过地址进行简单的访问控制的安全机制。同时我们也提到了，这种安全机制只防君子，不防小人，试想这样一种场景： A设备表示只信任B、C、D设备，因此就把它们的地址加入到了自己的白名单中，表示只愿意和它们沟通。与此同时，E设备对它们的沟通非常感兴趣，但A对自己不信任啊，肿么办？ E眼珠子一转，想出一个坏主意：把自己的地址伪装成成B、C、D中

内存初始化代码分析（三）：创建系统内存地址映射

Thu, 24 Nov 2016 12:08:56 +0800

经过内存初始化代码分析（一）和内存初始化代码分析（二）的过渡，我们终于来到了内存初始化的核心部分：paging_init。当然本文不能全部解析完该函数（那需要的篇幅太长了），我们只关注创建系统内存地址映射这部分代码实现，也就是解析paging_init中的map_mem函数。同样的，我们选择的是4.4.6的内核代码，体系结构相关的代码来自ARM64。

exynos4412 u-boot 移植链接板级文件lowlevel_init.o的位置超过了１４K的地址范围

Mon, 21 Nov 2016 18:56:03 +0800

本文是原「蜗窝讨论区」的历史存档（2016-11-21），来自版块「X Project」，共 8 帖。讨论区已停止服务，此处仅供查阅。

ap0904225 · 2016-11-21 18:56

大家好！我在X-project项目中移植exynos4412 u-boot（u-boot版本为v2016-11）的时候遇到的问题是：三星提供好了BL1的文件，且这个BL１是不开源的也不知道是如何生成的。因此我在移植exynos4412的时候没有使用SPL，参考了u-boot/board/samsung/odroid这个开发板来移植。想在整个u-boot.bin中截取前面的１４K作为BL２。但是我发现板级文件的lowlevel_init.o的链接位置超过了１４K的地址，因此在截取的BL２中并不包lowlevel_init.o。请问大家知道如何通过修改u-boot.lds文件来改变文件的链接位置。

wowo · 2016-11-21 21:29

ap0904225 写道： 大家好！我在X-project项目中移植exynos4412 u-boot（u-boot版本为v2016-11）的时候遇到的问题是：三星提供好了BL1的文件，且这个BL１是不开源的也不知道是如何生成的。因此我在移植exynos4412的时候没有使用SPL，参考了u-boot/board/samsung/odroid这个开发板来移植。想在整个u-boot.bin中截取前面的１４K作为BL２。但是我发现板级文件的lowlevel_init.o的链接位置超过了１４K的地址，因此在截取的BL２中并不包lowlevel_init.o。请问大家知道如何通过修改u-boot.lds文件来改变文件的链接位置。

其实我们移植u-boot的时候，可以不使用lowlevel_init，参考下面的代码：


[== Undefined ==]
/* arch/arm/cpu/armv7/Makefile */
ifneq ($(CONFIG_SUNNY)$(CONFIG_AM43XX)$(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TEGRA)$(CONFIG_MX6)$(CONFIG_MX7)$(CONFIG_TI81XX)$(CONFIG_AT91FAMILY)$(CONFIG_SUNXI)$(CONFIG_ARCH_SOCFPGA),)
ifneq ($(CONFIG_SKIP_LOWLEVEL_INIT),y)
obj-y += lowlevel_init.o
endif
endif

至于怎么改变链接位置，其实也很简单，例如：


[== Undefined ==]
 .0x2000xxxx； ----- 想放的位置
 . = ALIGN(4);
 .xxx_text :
 {
 xxx/lowlevel_init.o (.text*)
 }

ap0904225 · 2016-11-21 22:13

谢谢wowo,我试试看

ap0904225 · 2016-12-08 22:07

我一开始移植exynos4412的时候参考了u-boot/board/samsung/odroid这个开发板来移植，直接在整个u-boot.bin中截取前面的１４K作为BL２。通过反汇编u-boot.bin文件，我发现板级初始化的代码（内存和时钟初始化）被放在了u-boot.bin文件的14K地址之后，因此在截取的BL２中并不包含相关板级初始化的代码。后来参考u-boot/board/samsung/origen这个开发板,解决了这个问题。目前已经可以实现把u-boot拷贝到片外DDR上运行，命令行也可以使用了。相关的记录文档地址：http://www.cnblogs.com/AP0904225/p/6078966.html u-boot代码仓库：git@github.com:X-Project-FriendlyARMTiny4412/u-boot.git 有兴趣的同学可以一起参与进来，一起学习提高。

usb实现vga输入的设计思路

Mon, 21 Nov 2016 18:26:19 +0800

本文是原「蜗窝讨论区」的历史存档（2016-11-21），来自版块「Linux kernel技术问答」，共 5 帖。讨论区已停止服务，此处仅供查阅。

三少 · 2016-11-21 18:26

各位好，我最近想要实现一个vga输入的功能，用在android平台上，现在的方案是vga采集转换为usb输入到mcu，然后mcu做处理以及显示到lcd。底下的vga采集及转换为usb是其他人负责，usb设计为：通过默认的控制0端点去获取vga的一些参数，具体的数据（格式为rgb565）则是通过一个fifo端点来传输。最后要显示的lcd的格式是ARGB。现在我简单实现了个usb的设备驱动，以及相应的HAL，jni直到android的小测试应用，但是只是实现了一个字节的读写功能。考虑到数据处理，图像缩放等功能的实现，如果都是自己实现感觉有点功力不够。上网搜了一下有可以用v4l2架构实现的。现在想要问问大家有没有什么建议。能说说大致的思路最好。由于usb驱动、android HAL等架构、android应用都是初次接触，所以感觉工作量大，时间比较紧，想在确定思路前问问大家怎样的设计方法实现起来会比较容易一些。先行谢过！

wowo · 2016-11-21 18:40

其实你这就是一个USB camera。上网上（最好google）搜索一下linux uvc driver，应该能找到有用的东西。 Linux USB framework是很庞大的，你这样问，估计没有人能给你详细的答案。

三少 · 2016-11-21 19:28

多谢wowo这么快的回复，我看一下uvc相关的东西。

wowo · 2016-11-21 21:38

三少写道： 多谢wowo这么快的回复，我看一下uvc相关的东西。

不客气。USB的东西太复杂，蜗窝上也没有相关的系列文章，所以我们也帮不了你太多的，见谅哈~

三少 · 2016-12-20 18:00

这里自己做个结贴，最后的实现方式是通过android现成的UsbManager等相关的类来实现的，实现起来还是比较简单的，就不详说了，百度一下UsbManager基本就能知道个大概，只是之前都不知道有这么个东西。

找工作-oser-linux内核相关

Sat, 19 Nov 2016 10:53:42 +0800

本文是原「蜗窝讨论区」的历史存档（2016-11-19），来自版块「内推区」，共 1 帖。讨论区已停止服务，此处仅供查阅。

OSer · 2016-11-19 10:53

之前一直在做ARM相关的裸机和rtos相关的工作，为了做最初的爱好，想找个linux内核相关的工作。地点：北京

X-018-KERNEL-串口驱动开发之serial console

Fri, 18 Nov 2016 22:25:12 +0800

本文是“ X Project ”串口驱动开发的第三篇，在第二篇“ uart driver框架 [1] ”的基础上，实现console驱动，并借助这个过程，理解如下知识： 1）从DTS regs字段中获取设备的I/O基址，并map出来供driver访问。这是device tree最基本的使用场景。 2）从DTS aliases中获取串口的索引号。这是device tree aliases功能的一个应

内存初始化代码分析（二）：内存布局

Fri, 18 Nov 2016 18:25:20 +0800

同样的，本文是内存初始化文章的一份补充文档，希望能够通过这样的一份文档，细致的展示在初始化阶段，Linux 4.4.6内核如何从device tree中提取信息，完成内存布局的任务。具体的cpu体系结构选择的是ARM64。

X-017-KERNEL-串口驱动开发之uart driver框架

Wed, 16 Nov 2016 22:09:48 +0800

本文是“ X Project ”串口驱动开发的第二篇，将以“bubblegum-96”开发板为例，介绍在linux serial framework的框架下，编写串口driver以及console driver的方法和步骤（暂不涉及实现细节）。注1：有关串口、TTY、console等概念，可参考本站“TTY子系统 [1] ”的文章。Linux serial framework的分析，会在后续的文

时间子系统中的hrtimer_interrupt函数

Tue, 15 Nov 2016 14:10:36 +0800

本文是原「蜗窝讨论区」的历史存档（2016-11-15），来自版块「Linux kernel技术问答」，共 2 帖。讨论区已停止服务，此处仅供查阅。

西人 · 2016-11-15 14:10

看了@linuxer大神的时间子系统的文章，又去看了代码，现在对于函数hrtimer_interrupt有点疑问，我感觉要理解hrtimer这个函数很重要,但是看了一下代码，不是很懂，我现在是这么理解这个函数的作用：这个函数通过在hrtimer红黑树中，找到最近要执行的hrtimer，然后reprograme定时器。上面是第一点不知到理解对不对？

第二点就是，对于“高精度timer + Dynamic Tick ”，现在周期性的tick现在可以看成一个hrtimer,只不过这个hrtimer的时间是固定的，而且循环的插入hrtimer红黑树中，不知道这点理解对不对？

＠linuxer大神能不能指点一下

linuxer · 2016-11-16 09:07

你说的基本是没有问题的，大概就是那个样子的，只不过还有一些细节需要梳理一下。指点谈不上，大家多交流我也有一段时间没有去阅读时间子系统相关的内容，有空可以回来再整理一次。

X-016-KERNEL-串口驱动开发之驱动框架

Thu, 10 Nov 2016 22:12:03 +0800

在过去的一段时间里，蜗窝上发表了一系列的关于内核各个子系统的分析文章，设备模型、device tree、中断子系统、clock framework、电源管理、GPIO、pinctrl等等，这些文章重理论、轻实践。随着“ X Project ”的进行，我们渐渐有机会把这些缺失的实践慢慢补回来。串口驱动是进入Linux kernel之后最先遭遇的一个驱动，虽然不是很复杂，但要素齐全，使用到了kern

内存初始化代码分析（一）：identity mapping和kernel image mapping

Thu, 10 Nov 2016 19:07:31 +0800

本文没有什么框架性的东西，就是按照__create_page_tables代码的执行路径走读一遍，记录在初始化阶段，内核是如何创建内核运行需要的页表过程。想要了解一些概述性的、框架性的东西可以参考内存初始化文档。本文的代码来自ARM64，内核版本是4.4.6，此外，阅读本文最好熟悉ARMv8中翻译表描述符的格式。

蓝牙协议分析(8)_BLE安全机制之白名单

Thu, 10 Nov 2016 14:20:47 +0800

在万物联网的时代，安全问题将会受到非常严峻的挑战（相应地，也会获得最大的关注度），因为我们身边的每一个IOT设备，都是一个处于封印状态的天眼，随时都有被开启的危险。想想下面的场景吧：凌晨2点，x米手环的闹钟意外启动，将你从睡梦中惊醒，然后床头的灯光忽明忽暗…… 你的心率、血压、睡眠质量等信息，默默地被竞争对手收集着，并通过大数据分析你的情绪、健康等，随时准备给你致命一击…… 我知道你家里有几盏灯

请教各位老大，如何修改内核代码段的只读标记？

Sat, 05 Nov 2016 17:08:16 +0800

本文是原「蜗窝讨论区」的历史存档（2016-11-05），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

xFrank · 2016-11-05 17:08

我在学习编写内核模块，想编一个hook系统调用的模块。但在一个arm64 的Android手机上测试（已root），发现内核代码段只读，常规方法失败

网上搜了下，用set_memory_rw、和 set_fs(KERNEL_DS)都没有成功。其它方法貌似都是x86/x64 平台的。 http://stackoverflow.com/questions/2103315/linux-kernel-system-call-hooking-example

各位大神有啥招么？

多谢

X-015-KERNEL-ARM generic timer driver的移植

Wed, 02 Nov 2016 22:31:07 +0800

本文将基于“ Linux时间子系统之（十七）：ARM generic timer驱动代码分析 [1] ”，以bubblegum-96平台为例，介绍ARM generic timer的移植步骤。另外，我们在[2]中完成了ARM GIC驱动的移植，但还没有测试是否可用。刚好借助timer驱动，测试GIC是否可以正常工作，顺便理解Interrupt的使用方法。

Cubieboard u-boot移植遇到的问题

Wed, 02 Nov 2016 17:25:14 +0800

本文是原「蜗窝讨论区」的历史存档（2016-11-02），来自版块「Linux kernel技术问答」，共 12 帖。讨论区已停止服务，此处仅供查阅。

OSer · 2016-11-02 17:25

我这有一块Cubieboard的板子，所以想要自己移植一下u-boot(上流分支以支持cubieboard),学习一下u-boot的架构和工作流程，然后按着X-Project项目的入门介绍，然后开始的移植。我所做的工作已经都提交到了我的github上了，https://github.com/OSer916/u-boot 对应的分支是cubieboard

下面的内容是 git diff master cubieboard 的输出：


[== Undefined ==]
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d7a9b11..298da70 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -873,6 +873,11 @@ config TARGET_THUNDERX_88XX
 select OF_CONTROL
 select SYS_CACHE_SHIFT_7
+config TARGET_SUNNY

bool "Support Sunny board"
select CPU_V7



endchoice
source "arch/arm/mach-at91/Kconfig"
@@ -935,6 +940,7 @@ source "arch/arm/cpu/armv8/Kconfig"
source "arch/arm/imx-common/Kconfig"



source "board/bosch/shc/Kconfig"
source "board/BuR/brxre1/Kconfig"
source "board/BuR/brppt1/Kconfig"
@@ -1021,6 +1027,7 @@ source "board/woodburn/Kconfig"
source "board/work-microwave/work_92105/Kconfig"
source "board/zipitz2/Kconfig"
+source "board/sunny/Kconfig"
source "arch/arm/Kconfig.debug"
endmenu
diff –git a/arch/arm/Makefile b/arch/arm/Makefile
index 42093c2..f0bf884 100644
— a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -65,6 +65,7 @@ machine-$(CONFIG_ARCH_MVEBU) += mvebu
machine-$(CONFIG_ORION5X) += orion5x
machine-$(CONFIG_ARCH_S5PC1XX) += s5pc1xx
machine-$(CONFIG_ARCH_SUNXI) += sunxi
+machine-$(CONFIG_SUNNY) += sunny
machine-$(CONFIG_ARCH_SNAPDRAGON) += snapdragon
machine-$(CONFIG_ARCH_SOCFPGA) += socfpga
machine-$(CONFIG_ARCH_RMOBILE) += rmobile
diff –git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
index 4d3bc94..6f4329c 100644
— a/arch/arm/cpu/armv7/Makefile
+++ b/arch/arm/cpu/armv7/Makefile
@@ -12,7 +12,7 @@ obj-y += cache_v7.o cache_v7_asm.o
obj-y += cpu.o cp15.o
obj-y += syslib.o
-ifneq ($(CONFIG_AM43XX)$(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TEGRA)$(CONFIG_MX6)$(CONFIG_MX7)$(CONFIG_TI81XX)$(CONFIG_AT91FAMILY)$(CONFIG_ARCH_SUNXI)$(CONFIG_ARCH_SOCFPGA)$(CONFIG_LS102XA),)
+ifneq ($(CONFIG_SUNNY)$(CONFIG_AM43XX)$(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TEGRA)$(CONFIG_MX6)$(CONFIG_MX7)$(CONFIG_TI81XX)$(CONFIG_AT91FAMILY)$(CONFIG_ARCH_SUNXI)$(CONFIG_ARCH_SOCFPGA)$(CONFIG_LS102XA),)
ifneq ($(CONFIG_SKIP_LOWLEVEL_INIT),y)
obj-y += lowlevel_init.o
endif
@@ -45,4 +45,5 @@ obj-$(CONFIG_OMAP54XX) += omap5/
obj-$(CONFIG_RMOBILE) += rmobile/
obj-$(if $(filter stv0991,$(SOC)),y) += stv0991/
obj-$(CONFIG_ARCH_SUNXI) += sunxi/
+obj-$(CONFIG_SUNNY) += sunny/
obj-$(CONFIG_VF610) += vf610/
diff –git a/arch/arm/cpu/armv7/sunny/Makefile b/arch/arm/cpu/armv7/sunny/Makefile
new file mode 100644
index 0000000..62c0dad
— /dev/null
+++ b/arch/arm/cpu/armv7/sunny/Makefile
@@ -0,0 +1,2 @@
+#
+obj-y += start.o
diff –git a/arch/arm/cpu/armv7/sunny/start.c b/arch/arm/cpu/armv7/sunny/start.c
new file mode 100644
index 0000000..8337712
— /dev/null
+++ b/arch/arm/cpu/armv7/sunny/start.c
@@ -0,0 +1 @@
+//
diff –git a/arch/arm/mach-sunny/Makefile b/arch/arm/mach-sunny/Makefile
new file mode 100644
index 0000000..8ad9650
— /dev/null
+++ b/arch/arm/mach-sunny/Makefile
@@ -0,0 +1,3 @@
+
+obj-y += board.o
+
diff –git a/arch/arm/mach-sunny/board.c b/arch/arm/mach-sunny/board.c
new file mode 100644
index 0000000..17f9c99
— /dev/null
+++ b/arch/arm/mach-sunny/board.c
@@ -0,0 +1,3 @@
+void s_init(void)
+{
+}
diff –git a/board/sunny/Kconfig b/board/sunny/Kconfig
new file mode 100644
index 0000000..65e80c4
— /dev/null
+++ b/board/sunny/Kconfig
@@ -0,0 +1,39 @@
+
+config ARCH_SUNNY

bool
default y
+config SYS_CPU
default "armv7"
+config SYS_SOC
default "sunny"
+config SYS_BOARD
default "sunny"


+config SYS_CONFIG_NAME

default "sunny"


+config NR_DRAM_BANKS

int "DRAM bank number"
default 1


+config SYS_MAXARGS

int "max arguments"
default 16


+config ENV_IS_NOWHERE

bool "where is the envs"
default y


+config BAUDRATE

int "serail port baudrate"
default 115200


+config SYS_CBSIZE

int "Console I/O buffer size"
default 1024


+config CONS_INDEX

int "console index"
default 1



diff –git a/board/sunny/Makefile b/board/sunny/Makefile
new file mode 100644
index 0000000..933f5d0
— /dev/null
+++ b/board/sunny/Makefile
@@ -0,0 +1,2 @@
+
+obj-y += board.o
diff –git a/board/sunny/board.c b/board/sunny/board.c
new file mode 100644
index 0000000..2717fe2
— /dev/null
+++ b/board/sunny/board.c
@@ -0,0 +1,27 @@
+#include <common.h>
+void reset_cpu(ulong addr)
+{
+}
+
+//void lowlevel_init(void)
+////{
+//}
+int board_run_command(const char *buf)
+{

return 0;
+}


+int dram_init(void)
+{

return 0;
+}


+int board_init(void)
+{

return 0;
+}


+ulong get_tbclk(void)
+{

return 0;
+}
diff –git a/configs/sunny_defconfig b/configs/sunny_defconfig
new file mode 100644
index 0000000..7bc77ca
— /dev/null
+++ b/configs/sunny_defconfig
@@ -0,0 +1,593 @@
+#
+# Automatically generated file; DO NOT EDIT.
+# U-Boot 2016.11-rc2 Configuration
+#
+CONFIG_CREATE_ARCH_SYMLINK=y
+# CONFIG_ARC is not set
+CONFIG_ARM=y
+# CONFIG_AVR32 is not set
+# CONFIG_BLACKFIN is not set
+# CONFIG_M68K is not set
+# CONFIG_MICROBLAZE is not set
+# CONFIG_MIPS is not set
+# CONFIG_NDS32 is not set
+# CONFIG_NIOS2 is not set
+# CONFIG_OPENRISC is not set
+# CONFIG_PPC is not set
+# CONFIG_SANDBOX is not set
+# CONFIG_SH is not set
+# CONFIG_SPARC is not set
+# CONFIG_X86 is not set
+# CONFIG_XTENSA is not set
+CONFIG_SYS_ARCH="arm"
+CONFIG_SYS_CPU="armv7"
+CONFIG_SYS_SOC="sunny"
+CONFIG_SYS_BOARD="sunny"
+CONFIG_SYS_CONFIG_NAME="sunny"


+#
+# ARM architecture
+#
+CONFIG_HAS_VBAR=y
+CONFIG_HAS_THUMB2=y
+CONFIG_CPU_V7=y
+CONFIG_SYS_ARM_ARCH=7
+CONFIG_SYS_CACHE_SHIFT_6=y
+CONFIG_SYS_CACHELINE_SIZE=64
+# CONFIG_SEMIHOSTING is not set
+# CONFIG_SYS_L2CACHE_OFF is not set
+# CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK is not set
+# CONFIG_ARCH_AT91 is not set
+# CONFIG_TARGET_EDB93XX is not set
+# CONFIG_TARGET_VCMA9 is not set
+# CONFIG_TARGET_SMDK2410 is not set
+# CONFIG_TARGET_ASPENITE is not set
+# CONFIG_TARGET_GPLUGD is not set
+# CONFIG_ARCH_DAVINCI is not set
+# CONFIG_KIRKWOOD is not set
+# CONFIG_ARCH_MVEBU is not set
+# CONFIG_TARGET_DEVKIT3250 is not set
+# CONFIG_TARGET_WORK_92105 is not set
+# CONFIG_TARGET_MX25PDK is not set
+# CONFIG_TARGET_ZMX25 is not set
+# CONFIG_TARGET_APF27 is not set
+# CONFIG_TARGET_APX4DEVKIT is not set
+# CONFIG_TARGET_XFI3 is not set
+# CONFIG_TARGET_M28EVK is not set
+# CONFIG_TARGET_MX23EVK is not set
+# CONFIG_TARGET_MX28EVK is not set
+# CONFIG_TARGET_MX23_OLINUXINO is not set
+# CONFIG_TARGET_BG0900 is not set
+# CONFIG_TARGET_SANSA_FUZE_PLUS is not set
+# CONFIG_TARGET_SC_SPS_1 is not set
+# CONFIG_ORION5X is not set
+# CONFIG_TARGET_SPEAR300 is not set
+# CONFIG_TARGET_SPEAR310 is not set
+# CONFIG_TARGET_SPEAR320 is not set
+# CONFIG_TARGET_SPEAR600 is not set
+# CONFIG_TARGET_STV0991 is not set
+CONFIG_TARGET_SUNNY=y
+# CONFIG_TARGET_X600 is not set
+# CONFIG_TARGET_IMX31_PHYCORE is not set
+# CONFIG_TARGET_MX31ADS is not set
+# CONFIG_TARGET_MX31PDK is not set
+# CONFIG_TARGET_WOODBURN is not set
+# CONFIG_TARGET_WOODBURN_SD is not set
+# CONFIG_TARGET_FLEA3 is not set
+# CONFIG_TARGET_MX35PDK is not set
+# CONFIG_ARCH_BCM283X is not set
+# CONFIG_TARGET_VEXPRESS_CA15_TC2 is not set
+# CONFIG_TARGET_VEXPRESS_CA5X2 is not set
+# CONFIG_TARGET_VEXPRESS_CA9X4 is not set
+# CONFIG_TARGET_BRXRE1 is not set
+# CONFIG_TARGET_BRPPT1 is not set
+# CONFIG_TARGET_DRACO is not set
+# CONFIG_TARGET_THUBAN is not set
+# CONFIG_TARGET_RASTABAN is not set
+# CONFIG_TARGET_ETAMIN is not set
+# CONFIG_TARGET_PXM2 is not set
+# CONFIG_TARGET_RUT is not set
+# CONFIG_TARGET_TI814X_EVM is not set
+# CONFIG_TARGET_TI816X_EVM is not set
+# CONFIG_TARGET_BCM23550_W1D is not set
+# CONFIG_TARGET_BCM28155_AP is not set
+# CONFIG_TARGET_BCMCYGNUS is not set
+# CONFIG_TARGET_BCMNSP is not set
+# CONFIG_ARCH_EXYNOS is not set
+# CONFIG_ARCH_S5PC1XX is not set
+# CONFIG_ARCH_HIGHBANK is not set
+# CONFIG_ARCH_INTEGRATOR is not set
+# CONFIG_ARCH_KEYSTONE is not set
+# CONFIG_ARCH_MESON is not set
+# CONFIG_ARCH_MX7 is not set
+# CONFIG_ARCH_MX6 is not set
+# CONFIG_ARCH_MX5 is not set
+# CONFIG_TARGET_M53EVK is not set
+# CONFIG_TARGET_MX51EVK is not set
+# CONFIG_TARGET_MX53ARD is not set
+# CONFIG_TARGET_MX53EVK is not set
+# CONFIG_TARGET_MX53LOCO is not set
+# CONFIG_TARGET_MX53SMD is not set
+# CONFIG_OMAP34XX is not set
+# CONFIG_OMAP44XX is not set
+# CONFIG_OMAP54XX is not set
+# CONFIG_AM43XX is not set
+# CONFIG_AM33XX is not set
+# CONFIG_ARCH_RMOBILE is not set
+# CONFIG_TARGET_S32V234EVB is not set
+# CONFIG_ARCH_SNAPDRAGON is not set
+# CONFIG_ARCH_SOCFPGA is not set
+# CONFIG_TARGET_CM_T43 is not set
+# CONFIG_ARCH_SUNXI is not set
+# CONFIG_TARGET_TS4800 is not set
+# CONFIG_TARGET_VF610TWR is not set
+# CONFIG_TARGET_COLIBRI_VF is not set
+# CONFIG_TARGET_PCM052 is not set
+# CONFIG_TARGET_BK4R1 is not set
+# CONFIG_ARCH_ZYNQ is not set
+# CONFIG_ARCH_ZYNQMP is not set
+# CONFIG_TEGRA is not set
+# CONFIG_TARGET_VEXPRESS64_AEMV8A is not set
+# CONFIG_TARGET_VEXPRESS64_BASE_FVP is not set
+# CONFIG_TARGET_VEXPRESS64_BASE_FVP_DRAM is not set
+# CONFIG_TARGET_VEXPRESS64_JUNO is not set
+# CONFIG_TARGET_LS2080A_EMU is not set
+# CONFIG_TARGET_LS2080A_SIMU is not set
+# CONFIG_TARGET_LS2080AQDS is not set
+# CONFIG_TARGET_LS2080ARDB is not set
+# CONFIG_TARGET_HIKEY is not set
+# CONFIG_TARGET_LS1012AQDS is not set
+# CONFIG_TARGET_LS1012ARDB is not set
+# CONFIG_TARGET_LS1012AFRDM is not set
+# CONFIG_TARGET_LS1021AQDS is not set
+# CONFIG_TARGET_LS1021ATWR is not set
+# CONFIG_TARGET_LS1043AQDS is not set
+# CONFIG_TARGET_LS1043ARDB is not set
+# CONFIG_TARGET_LS1046AQDS is not set
+# CONFIG_TARGET_LS1046ARDB is not set
+# CONFIG_TARGET_H2200 is not set
+# CONFIG_TARGET_ZIPITZ2 is not set
+# CONFIG_TARGET_COLIBRI_PXA270 is not set
+# CONFIG_ARCH_UNIPHIER is not set
+# CONFIG_STM32 is not set
+# CONFIG_ARCH_ROCKCHIP is not set
+# CONFIG_TARGET_THUNDERX_88XX is not set
+# CONFIG_ARMV7_LPAE is not set
+CONFIG_IDENT_STRING=""
+# CONFIG_PRE_CONSOLE_BUFFER is not set
+# CONFIG_VIDEO is not set
+
+#
+# ARM debug
+#
+# CONFIG_DEBUG_LL is not set
+
+#
+# General setup
+#
+CONFIG_LOCALVERSION=""
+CONFIG_LOCALVERSION_AUTO=y
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+# CONFIG_DISTRO_DEFAULTS is not set
+# CONFIG_SYS_MALLOC_F is not set
+CONFIG_EXPERT=y
+CONFIG_SYS_MALLOC_CLEAR_ON_INIT=y
+# CONFIG_TOOLS_DEBUG is not set
+# CONFIG_PHYS_64BIT is not set
+
+#
+# Boot images
+#
+# CONFIG_FIT is not set
+CONFIG_SYS_EXTRA_OPTIONS=""
+CONFIG_ARCH_FIXUP_FDT=y
+
+#
+# Boot timing
+#
+# CONFIG_BOOTSTAGE is not set
+CONFIG_BOOTSTAGE_USER_COUNT=20
+CONFIG_BOOTSTAGE_STASH_ADDR=0
+CONFIG_BOOTSTAGE_STASH_SIZE=4096
+
+#
+# Boot media
+#
+# CONFIG_NAND_BOOT is not set
+# CONFIG_ONENAND_BOOT is not set
+# CONFIG_QSPI_BOOT is not set
+# CONFIG_SATA_BOOT is not set
+# CONFIG_SD_BOOT is not set
+# CONFIG_SPI_BOOT is not set
+CONFIG_BOOTDELAY=2
+
+#
+# Console
+#
+# CONFIG_CONSOLE_RECORD is not set
+# CONFIG_SILENT_CONSOLE is not set
+# CONFIG_CONSOLE_MUX is not set
+# CONFIG_SYS_CONSOLE_IS_IN_ENV is not set
+# CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE is not set
+# CONFIG_SYS_CONSOLE_ENV_OVERWRITE is not set
+# CONFIG_SYS_CONSOLE_INFO_QUIET is not set
+# CONFIG_SYS_STDIO_DEREGISTER is not set
+CONFIG_DEFAULT_FDT_FILE=""
+# CONFIG_SYS_NO_FLASH is not set
+# CONFIG_VERSION_VARIABLE is not set
+# CONFIG_DISPLAY_CPUINFO is not set
+# CONFIG_DISPLAY_BOARDINFO is not set
+
+#
+# SPL / TPL
+#
+
+#
+# Command line interface
+#
+# CONFIG_CMDLINE is not set
+CONFIG_SYS_PROMPT="=> "
+
+#
+# Autoboot options
+#
+CONFIG_AUTOBOOT=y
+# CONFIG_AUTOBOOT_KEYED is not set
+
+#
+# FASTBOOT
+#
+# CONFIG_FASTBOOT is not set
+
+#
+# Commands
+#
+
+#
+# Info commands
+#
+# CONFIG_CMD_BDI is not set
+# CONFIG_CMD_CONSOLE is not set
+# CONFIG_CMD_CPU is not set
+# CONFIG_CMD_LICENSE is not set
+
+#
+# Boot commands
+#
+# CONFIG_CMD_BOOTD is not set
+# CONFIG_CMD_BOOTM is not set
+# CONFIG_CMD_BOOTZ is not set
+# CONFIG_CMD_ELF is not set
+# CONFIG_CMD_GO is not set
+# CONFIG_CMD_RUN is not set
+# CONFIG_CMD_IMI is not set
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_XIMG is not set
+
+#
+# Environment commands
+#
+# CONFIG_CMD_ASKENV is not set
+# CONFIG_CMD_EXPORTENV is not set
+# CONFIG_CMD_IMPORTENV is not set
+# CONFIG_CMD_EDITENV is not set
+# CONFIG_CMD_GREPENV is not set
+# CONFIG_CMD_SAVEENV is not set
+# CONFIG_CMD_ENV_EXISTS is not set
+
+#
+# Memory commands
+#
+# CONFIG_CMD_MEMORY is not set
+# CONFIG_CMD_CRC32 is not set
+# CONFIG_LOOPW is not set
+# CONFIG_CMD_MEMTEST is not set
+# CONFIG_CMD_MX_CYCLIC is not set
+# CONFIG_CMD_MEMINFO is not set
+
+#
+# Device access commands
+#
+# CONFIG_CMD_LOADB is not set
+# CONFIG_CMD_LOADS is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_ARMFLASH is not set
+# CONFIG_CMD_MMC is not set
+# CONFIG_CMD_NAND is not set
+# CONFIG_CMD_SF is not set
+# CONFIG_CMD_SPI is not set
+# CONFIG_CMD_I2C is not set
+# CONFIG_CMD_USB is not set
+# CONFIG_CMD_DFU is not set
+# CONFIG_CMD_USB_MASS_STORAGE is not set
+# CONFIG_CMD_FPGA is not set
+# CONFIG_CMD_GPIO is not set
+
+#
+# Shell scripting commands
+#
+# CONFIG_CMD_ECHO is not set
+# CONFIG_CMD_ITEST is not set
+# CONFIG_CMD_SOURCE is not set
+# CONFIG_CMD_SETEXPR is not set
+
+#
+# Network commands
+#
+# CONFIG_CMD_NET is not set
+# CONFIG_CMD_TFTPPUT is not set
+# CONFIG_CMD_TFTPSRV is not set
+# CONFIG_CMD_RARP is not set
+# CONFIG_CMD_DHCP is not set
+# CONFIG_CMD_NFS is not set
+# CONFIG_CMD_MII is not set
+# CONFIG_CMD_PING is not set
+# CONFIG_CMD_CDP is not set
+# CONFIG_CMD_SNTP is not set
+# CONFIG_CMD_DNS is not set
+# CONFIG_CMD_LINK_LOCAL is not set
+
+#
+# Misc commands
+#
+# CONFIG_CMD_CACHE is not set
+# CONFIG_CMD_TIME is not set
+# CONFIG_CMD_MISC is not set
+# CONFIG_CMD_TIMER is not set
+# CONFIG_CMD_QFW is not set
+
+#
+# Power commands
+#
+
+#
+# Security commands
+#
+
+#
+# Firmware commands
+#
+
+#
+# Filesystem commands
+#
+# CONFIG_CMD_EXT2 is not set
+# CONFIG_CMD_EXT4 is not set
+# CONFIG_CMD_FAT is not set
+# CONFIG_CMD_FS_GENERIC is not set
+# CONFIG_CMD_UBI is not set
+CONFIG_SUPPORT_OF_CONTROL=y
+
+#
+# Device Tree Control
+#
+# CONFIG_OF_CONTROL is not set
+CONFIG_NET=y
+# CONFIG_NET_RANDOM_ETHADDR is not set
+# CONFIG_NETCONSOLE is not set
+# CONFIG_NET_TFTP_VARS is not set
+CONFIG_BOOTP_PXE_CLIENTARCH=0x15
+CONFIG_BOOTP_VCI_STRING="U-Boot.armv7"
+
+#
+# Device Drivers
+#
+
+#
+# Generic Driver Options
+#
+# CONFIG_DM is not set
+# CONFIG_ADC is not set
+# CONFIG_ADC_EXYNOS is not set
+# CONFIG_ADC_SANDBOX is not set
+# CONFIG_BLOCK_CACHE is not set
+
+#
+# Clock
+#
+# CONFIG_CPU is not set
+
+#
+# Hardware crypto devices
+#
+# CONFIG_FSL_CAAM is not set
+
+#
+# Demo for driver model
+#
+
+#
+# DFU support
+#
+
+#
+# DMA Support
+#
+# CONFIG_TI_EDMA3 is not set
+
+#
+# FPGA support
+#
+# CONFIG_FPGA_XILINX is not set
+
+#
+# GPIO Support
+#
+
+#
+# I2C support
+#
+# CONFIG_SYS_I2C_DW is not set
+# CONFIG_CROS_EC_KEYB is not set
+
+#
+# LED Support
+#
+
+#
+# Mailbox Controller Support
+#
+
+#
+# Memory Controller drivers
+#
+
+#
+# Multifunction device drivers
+#
+# CONFIG_CROS_EC is not set
+# CONFIG_FSL_SEC_MON is not set
+# CONFIG_MXC_OCOTP is not set
+# CONFIG_NUVOTON_NCT6102D is not set
+# CONFIG_PCA9551_LED is not set
+# CONFIG_WINBOND_W83627 is not set
+
+#
+# MMC Host controller Support
+#
+
+#
+# MTD Support
+#
+
+#
+# NAND Device Support
+#
+# CONFIG_NAND_DENALI is not set
+# CONFIG_NAND_VF610_NFC is not set
+# CONFIG_NAND_PXA3XX is not set
+# CONFIG_NAND_ARASAN is not set
+
+#
+# Generic NAND options
+#
+
+#
+# SPI Flash Support
+#
+# CONFIG_SPI_FLASH is not set
+
+#
+# UBI support
+#
+# CONFIG_MTD_UBI is not set
+# CONFIG_PHYLIB is not set
+# CONFIG_NETDEVICES is not set
+# CONFIG_PCI is not set
+# CONFIG_MVEBU_COMPHY_SUPPORT is not set
+
+#
+# Pin controllers
+#
+
+#
+# Power
+#
+
+#
+# Power Domain Support
+#
+
+#
+# Remote Processor drivers
+#
+
+#
+# Reset Controller Support
+#
+
+#
+# Real Time Clock
+#
+
+#
+# Serial drivers
+#
+# CONFIG_DEBUG_UART is not set
+# CONFIG_DEBUG_UART_SKIP_INIT is not set
+# CONFIG_ATMEL_USART is not set
+# CONFIG_FSL_LPUART is not set
+# CONFIG_MVEBU_A3700_UART is not set
+# CONFIG_SYS_NS16550 is not set
+
+#
+# Sound support
+#
+# CONFIG_SOUND is not set
+
+#
+# SPI Support
+#
+# CONFIG_FSL_ESPI is not set
+# CONFIG_FSL_QSPI is not set
+# CONFIG_TI_QSPI is not set
+
+#
+# SPMI support
+#
+
+#
+# System reset device drivers
+#
+# CONFIG_DM_THERMAL is not set
+
+#
+# Timer Support
+#
+
+#
+# TPM support
+#
+# CONFIG_USB is not set
+
+#
+# Graphics support
+#
+
+#
+# TrueType Fonts
+#
+# CONFIG_VIDEO_VESA is not set
+# CONFIG_VIDEO_LCD_ANX9804 is not set
+# CONFIG_VIDEO_LCD_SSD2828 is not set
+# CONFIG_VIDEO_MVEBU is not set
+# CONFIG_LCD is not set
+# CONFIG_PHYS_TO_BUS is not set
+
+#
+# File systems
+#
+
+#
+# Library routines
+#
+# CONFIG_CC_OPTIMIZE_LIBS_FOR_SPEED is not set
+CONFIG_HAVE_PRIVATE_LIBGCC=y
+CONFIG_USE_PRIVATE_LIBGCC=y
+CONFIG_SYS_HZ=1000
+# CONFIG_USE_TINY_PRINTF is not set
+CONFIG_REGEX=y
+# CONFIG_LIB_RAND is not set
+# CONFIG_CMD_DHRYSTONE is not set
+# CONFIG_RSA is not set
+
+#
+# Hashing Support
+#
+# CONFIG_SHA1 is not set
+# CONFIG_SHA256 is not set
+# CONFIG_SHA_HW_ACCEL is not set
+
+#
+# Compression Support
+#
+# CONFIG_LZ4 is not set
+# CONFIG_ERRNO_STR is not set
+# CONFIG_OF_LIBFDT is not set
+# CONFIG_OF_LIBFDT_OVERLAY is not set
+# CONFIG_SPL_OF_LIBFDT is not set
+
+#
+# System tables
+#
+# CONFIG_UNIT_TEST is not set
diff –git a/include/configs/sunny.h b/include/configs/sunny.h
new file mode 100644
index 0000000..5a1af26
— /dev/null
+++ b/include/configs/sunny.h
@@ -0,0 +1,29 @@
+#ifndef SUNNY_H
+
+#define SUNNY_H
+
+#define CONFIG_SUNNY
+
+#define CONFIG_ENV_SIZE (128 << 10)
+#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (64 << 20))
+#define CONFIG_SYS_TEXT_BASE 0x2a000000
+#define CONFIG_SYS_LOAD_ADDR 0x22000000
+#define CONFIG_SYS_NO_FLASH
+
+#define CONFIG_SYS_INIT_RAM_ADDR 0x0
+#define CONFIG_SYS_INIT_RAM_SIZE 0x8000
+#define CONFIG_SYS_INIT_SP_OFFSET \

(CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE)
+#define CONFIG_SYS_INIT_SP_ADDR \

 (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET)





+#define CONFIG_SYS_NS16550
+#define CONFIG_SYS_NS16550_SERIAL
+#define CONFIG_SYS_NS16550_CLK 24000000
+#define CONFIG_SYS_NS16550_REG_SIZE -4
+
+#define SUNXI_UART0_BASE 0x01c28000
+#define CONFIG_SYS_NS16550_COM1 SUNXI_UART0_BASE
+#endif
+

然后我执行make sunny_defconfig 输出正常再执行 make CROSS_COMPILE=arm-linux-gnueabihf-下面是最后的输出结果，在最后链接的时候出现了链接错误

LDS u-boot.lds LD u-boot arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils) 2.25.0 Linaro 2015_10 assertion fail /home/tcwg-buildslave/workspace/tcwg-make-release/label/tcwg-x86_64-ex40/target/arm-linux-gnueabihf/snapshots/binutils-gdb.git~linaro_binutils-2_25-branch/bfd/elf32-arm.c:7827 arm-linux-gnueabihf-ld.bfd: error: required section '.rel.plt' not found in the linker script arm-linux-gnueabihf-ld.bfd: final link failed: Invalid operation Makefile:1207: recipe for target 'u-boot' failed make: *** Error 1

Linux kernel debug技巧----开启DEBUG选项

Tue, 01 Nov 2016 19:39:29 +0800

kernel的source code中有很多使用pr_debug/dev_dbg输出的日志信息（例如device tree解析的代码，drivers/of/fdt.c）。默认情况下，kernel不会将这些日志输出到控制台上，除非： 1）开启了DEBUG宏，并且 2）kernel printk的默认日志级别大于7 看似简单，不过我相信每个人都问过这样的问题（不管是问自己还是问别人，特别是在调试ker

X-014-KERNEL-ARM GIC driver的移植

Mon, 31 Oct 2016 22:23:41 +0800

“ X Project ”完成“ X-012-KERNEL-serial early console的移植 ”之后，终止在如下的kernel panic中： NR_IRQS:64 nr_irqs:64 0 Kernel panic - not syncing: No interrupt controller found. —[ end Kernel panic - not syncing: N

请教WOWO和其它高手一个电源管理的问题.

Mon, 31 Oct 2016 12:03:13 +0800

本文是原「蜗窝讨论区」的历史存档（2016-10-31），来自版块「Linux kernel技术问答」，共 7 帖。讨论区已停止服务，此处仅供查阅。

马六甲2017 · 2016-10-31 12:03

我们的产品期望在系统待机时, 系统仍能处理ethernet 和USB的通信 (至少能把系统唤醒), 甚至wifi traffic.

我们的产品在一天98%以上的时间里是没有作业需要处理的,但系统要保证有响应作业请求的能力(响应时间大约为人的反映时间即可), 因此系统在大部分时间里必须处于低功耗状态.但系统又必须有处理用户新请求的能力,因此网络和USB不能关掉.

我们的系统采用A53 多处理器 (SMP) + R4低功耗小处理器结构, linux只运行在A53 SMP 多处理器上, R4 侧跑其它RTOS.

我的理解是,我们LINUX不能采用传统的hibernate或suspend to ram 模式, 因为在这种模式下,所有的DEVICE是停止工作的. 我不清楚ethernt or USB port event能不能作为一个wake up source. 即使能作为wake up source, 系统enter/exit hibernate or suspend to ram的时间也比较长, 如果系统上ethernet traffic (尤其是广播/组播包较多), 系统需要频繁enter/exit STD or STR.

我们目前想采用的solution是: 当系统没有作业处理时, 把non-boot SMP cores 关掉, 同时把其它相关模块关掉 (比如其它协处理器, GPU) , 让boot core A53 core 0来应付网络和USB traffic, 我想一个core来应付网络协议和USB Port应该已经足够了. 同时, 我们扩展了更多的cpudile states, 在boot core 最深层 CPUIDLE state时, linux把自己suspend (waiting r4 to turn off A53 boot core), 同时让r4检测ethernet mac+phy 和 USB port中断, 在r4检测到这些中断时, 它把linux唤醒 (re-power on it, A53 boot core will begin to run from the specific reset vector address which we set before suspend boot core). When A53 inform r4 that it can power off A53 core 0, it also indicate system can now enter low power mode, so r4 can turn off, or by pass some PLLs, power down some unused PIN pads, internal other blocks or SRAM, and set DDR memory into self refresh mode.

该方案目前能工作,但我不确定是不是最佳方案, 或能不能大规模的应用的产品中. 它的缺点可能是: 1, The timing required to enter/exist low power status, which including A53 core 0 suspend itself, R4 set system enter/exit low power status, and A53 exist suspend status. I have not measure these timing, also currently don’t sure the detailed allowed delay for all our TCP/IP application. 2, Seems when CPU enter CPUIDLE state, we still can not assure all devices are idle, maybe Ethernent MAC or USB port DMA still working (I need to understand CPUidle governor well), if r4 set DDR enter self –refresh mode, but some DMA or other bus master still try to access it, maybe system will crash. But maybe I can exploit some other feature that DDR memory controller can dynamically decide when to enter self-refresh mode, and exit this mode when it find some master still try to access DDR. Our datasheet said it support this feature.

不知道wowo对上述方案有何看法? 市场上其它平台是如何在顶功耗下保持ethernet和USB通信的?

我们以前其它平台上是在低功耗时, 在R4小处理器运行简化的ethernet 和 USB 驱动, 如果检测到是新的用户数据和请求(没有运行整个TCP/IP 协议栈), 在唤醒主处理器是把受到的数据放置在主处理器相关的驱动buffer里(主处理器的驱动程序都是我们自己的, 其结构也了解的很清楚,所以能够这样做), 但在LINUX平台上, R4把数据直接放置在A53 linux 侧的驱动buffer里可能需要较大的工作量, 所以目前没考虑这种做法.

谢谢.

Linux TTY framework(5)_System console driver

Sat, 29 Oct 2016 22:43:44 +0800

由[1]中的介绍可知，Linux kernel的console框架，主要提供“控制台终端”的功能，用于： 1）kernel日志信息（printk）的输出。 2）实现基础的、基于控制台的人机交互。本文将从console driver开发者的视角，介绍：console有关的机制；编写一个console驱动需要哪些步骤；从用户的角度怎么使用；等等。

进程管理和终端驱动：基本概念

Fri, 28 Oct 2016 18:56:20 +0800

对于任何一种OS，终端部分的内容总是令人非常的痛苦和沮丧，GNU/linux也是如此。究其原因主要有两个，一是终端驱动和终端相关的系统软件承载了太多的内容：各种虚拟终端、伪终端、串口通信、modem、printer等。其次可能是终端和信号处理、进程关系等耦合在一起加大了理解终端驱动的难度。本文的目标是希望能够理清这些内容。

"内存屏障"浅谈[投稿]

Thu, 27 Oct 2016 21:28:52 +0800

本文是原「蜗窝讨论区」的历史存档（2016-10-27），来自版块「Linux kernel技术问答」，共 4 帖。讨论区已停止服务，此处仅供查阅。

karma303 · 2016-10-27 21:28

如果觉得可以的话, 希望能发到博客上. 不用给我开账号, 博主发上去就行了. 如果觉得太单薄了, 就仅作参考算了.

======================================== 因为要面试, 今天看了看"内存屏障"这部分. 网上这类文章很多, 但总感觉不得要领. 我尽量写短一些, 算是对wiki的补充. https://en.wikipedia.org/wiki/Memory_barrier 希望加起来能做为入门.

"内存屏障"是因为多核的出现才成为话题. wiki上举了一个应用的场合, 我把它完整的引用下来. 这个例子很好, 请一定不要跳过去.

** 写道：**

The following two-processor program gives an example of how such out-of-order execution can affect program behavior:

Initially, memory locations x and f both hold the value 0. The program running on processor #1 loops while the value of f is zero, then it prints the value of x. The program running on processor #2 stores the value 42 into x and then stores the value 1 into f. Pseudo-code for the two program fragments is shown below. The steps of the program correspond to individual processor instructions.

Processor #1:

while (f == 0); // Memory fence required here print x;

Processor #2:

x = 42; // Memory fence required here f = 1;

One might expect the print statement to always print the number "42"; however, if processor #2's store operations are executed out-of-order, it is possible for f to be updated before x, and the print statement might therefore print "0". Similarly, processor #1's load operations may be executed out-of-order and it is possible for x to be read before f is checked, and again the print statement might therefore print an unexpected value. For most programs neither of these situations are acceptable. A memory barrier can be inserted before processor #2's assignment to f to ensure that the new value of x is visible to other processors at or prior to the change in the value of f. Another can be inserted before processor #1's access to x to ensure the value of x is not read prior to seeing the change in the value of f.

"内存屏障"分为两种, 一种是compile-time的. 像上面core-2的代码, 完全可能被gcc优化成 f = 1; x = 42;

所以我们得加上一条"编译器级别"的"内存屏障": x = 42; asm volatile("":::"memory"); f = 1;

仅仅是一句"指导指令", 跟编译器打个招呼而已.

其实"内存屏障"这个名字取得不好, 我更愿意把它叫做"序列化指令", "分割线指令", 或者干脆叫做"分割线". 它上方和下方的代码被一分为二. 在编译优化的时候, 上面的代码不会被优化到"分割线"下方, 下方的代码也不会跑到"分割线"上面. 我这么说不严谨, 但我一直是这样记忆的. 很实用. 回到正文. 分割不是目的, 目的是有序. 这样, 就能保证, 编译出来的机器码, f=1; 在 x=42; 后面了.

一旦理解了编译器界别的barrier, cpu级别的其实如出一辙. gcc的优化,本来就相当于"编译器级别"的乱序. 像安腾, 就是完全把out-of-order交给编译器的. 接着wiki中的例子, 现在到了指令执行阶段: mov [x], 42 mov , 1 为了保证mov [x], 42 始终在 mov ,1 前面执行, 我们还是需要加个"分割线": mov [x], 42 cpuid mov , 1 如果你忘了什么是分割线, 我们再复述一遍: 分割线上方的不会跑到下面去, 下面的不会跑到上面去. 这是最表象的解释, 略微本质一点的讲, 就是cpu的乱序执行部件, 在执行完cpuid之前, 绝对不会执行cpuid后面的指令, 而且绝对会执行完cpuid之前的指令. 类似的指令还有iret, invd, lgdt等等, 不过都不能当"分割线"用, 因为要么是特权指令, 要么是side effect无法接受. 真正干净的还就只有cpuid一个.

这篇文章的基本部分就是这些. 只是讲了memory barrier最表象的功能,以及该怎么使用. 我猜很多人都知道, 但我觉得整理一下还是必要的, 网上缺少这种短小的入门文章.

[扩展部分] 下面延伸讲一些相关和不相关的东西. 我好像在哪儿看到过一种说法, 说"内存屏障就是把cache里的内容都写回到memory里". 当然不对. 我不愿意称呼"内存屏障", 甚至"memory barrier"这个词我都不愿意叫, 就是强迫自己摆脱这种思维. 我有段时间, 总以为"内存屏障"是关于memory,cache的. 但其实毫不相干, 它的作用是"序列化", 或曰"串行化". 也就是为了对付"乱序处理". 它使得我们对"乱序处理"有基本的控制, 哪两条指令不能乱, 我们就在中间插入一条这样的"分割线"指令. 其实像cpuid这种类型的指令, 在intel文档上就叫做Seriallizing Instructions. 它的定义是"These instructions force the processor to complete all modifications to flags, registers, and memory by previous instructions and to drain all buffered memory before the next instruct is fetched and executed". 大概是说, serializing instruction会把它前面的指令的作为都"冲刷". 就是说, 你修改了寄存器, 那我就让寄存器改变吧(因为pentium引入了寄存器重命名), 你写了内存, 那我把这些修改从cache冲刷到内存里吧. 你会问, 这跟"memory barrier"有什么关系? 是的, 一毛钱的关系都没有. 我上面说一大串, 纯粹是为了科普, Seriallizing instructions大概是干什么的. 再回到正文, Seriallizing instructions还有一个"小小的作用", 正是我们需要的, 它藏在在intel文档8.2.2<Memory Ordering>里的一大段经文一样的rules里: Reads or writes cannot be reordered with I/O instructions, locked instructions, or Seriallizing instructions.

就是说, 在执行到cpuid之前, 之前的指令会被执行完, 在执行完cpuid之后, 后面的指令才会开始运行. serializing instruction对"乱序执行"的冲击是很大的, 甚至指令的prefetch和speculatively execute都被它干掉了. 所以intel在pentium III引入了SFENCE指令, 又在pentium 4引入了MENCE和LFENCE. 并在文档里好言相劝, ...provide a more efficient method of controlling memory ordering than the CPUID instruction. 文档里强调了fence指令跟cpuid这种序列化指令的区别: "... are memory-ordering instructions, not serializing instructions. 1, These drain the data memory subsystem. 2, They do not serialize the instruction execution stream." 1,2两点其实就是serializes instruction主要的两个作用. fence指令只做到了第一点.(所以轻量些) 第一点我们刚才科普过, 再说句废话, 千万不要以为这个drain动作是冲刷整个cache. 不是, 只是冲刷之前指令所做的内存写.(被buffer在cache里), 用intel的话说, 就是ensures all pending memory transactions are completed. 第二点, fence指令不会像cpuid那样强烈的"序列化"指令流. 是有选择的序列化, 例如sfence只序列化指令流里的store类型的指令. 但lfence有些例外, 它确实保证了指令流的"序列化": LFENCE does provide some guarantees on instruction ordering. It does not execute until all prior instructions have completed locally. and no later instruction begins execution until LFENCE completes. 当然, 这就属于intel x86上的细节了. 我也是懒得追究, 所以读到了就赶紧记下, 但求别栽在上面就行了. 我写到这儿, 其实sfence, lfence在什么场合用, 以及它们的原理, 都还没有讲. 其实我也不很清楚,所以干脆一个字也不写好了. 下面是手册上的话. (sfence) serializes all store(write) operations that occurred prior to the SFENCE instruction in the program instruction stream, but does not affect laod operations. (lfence) serialize all load(read) operations that occurred prior to the LFENCE instruction in the program instruction stream, but does not affect store operations. 其实细究起来, 一旦分读写, 就复杂好多. 以后有时间再弄吧. 这已经算是一天的工作量了.

PS: 如果你有重要的回复, 请记得发信到jiejinmv@163.com告诉我一声, 我好来看看.

2.4内核里semaphore源码的一个疑问

Wed, 26 Oct 2016 18:32:03 +0800

本文是原「蜗窝讨论区」的历史存档（2016-10-26），来自版块「Linux kernel技术问答」，共 4 帖。讨论区已停止服务，此处仅供查阅。

karma303 · 2016-10-26 18:32

博主你好, 请教一个问题. __down(里面有一段代码, 我觉得不那么保险.我先把__down的源码贴出来: ============================================= void __down(struct semaphore * sem) { struct task_struct *tsk = current; DECLARE_WAITQUEUE(wait, tsk); //定义一个"队列项", 等待者是当前进程 tsk->state = TASK_UNINTERRUPTIBLE; add_wait_queue_exclusive(&sem->wait, &wait); //把当前进程添加到该信号量的wait queue里.

spin_lock_irq(&amp;semaphore_lock); //抓取"大锁"
sem-&gt;sleepers++;
for (;;) {
 int sleepers = sem-&gt;sleepers;
/*
 * Add "everybody else" into it. They aren't
 * playing, because we own the spinlock.
 */
if (!atomic_add_negative(sleepers - 1, &amp;amp;sem-&amp;gt;count)) { //临睡前最后一次尝试
 sem-&amp;gt;sleepers = 0;
 break;
}
sem-&amp;gt;sleepers = 1; /* us - see -1 above */
spin_unlock_irq(&amp;amp;semaphore_lock);

schedule(; //睡眠
tsk-&amp;gt;state = TASK_UNINTERRUPTIBLE;
spin_lock_irq(&amp;amp;semaphore_lock);

}
spin_unlock_irq(&amp;semaphore_lock);
remove_wait_queue(&amp;sem-&gt;wait, &amp;wait); //取得信号量后, 退出该信号量的等待队列
tsk-&gt;state = TASK_RUNNING;
wake_up(&amp;sem-&gt;wait);

}

我也是这两天才开始读linux的源码. 我先说说我读到的一点经验. 2.4内核里的semaphore结构体里面没有lock字段, 整个semaphor.c里是共用一个文件域的大锁, 就是semaphore.c里定义的semaphore_lock. 每当要操作semaphore结构体之前, 就先抓取这个"全局锁". 但是up(操作的全程都没有理睬这把锁, 我很好奇, 会不会出现这样一种bug呢: 为了方便分析, 假设除了当前进程, 没有别的进程在竞争这个信号量. 刚才说到up(的全程都没理会"大锁", 所以在整个__down(的过程中, 别的cpu上, 随时可能会有一个up(平行的运行. up(最终调用的是wake_up_process(. ===================================== inline void wake_up_process(struct task_struct * p) { unsigned long flags;

/*
 * We want the common case fall through straight, thus the goto.
 */
spin_lock_irqsave(&amp;runqueue_lock, flags);
p-&gt;state = TASK_RUNNING; if (task_on_runqueue(p)) goto out;
add_to_runqueue(p);
reschedule_idle(p);

out: spin_unlock_irqrestore(&runqueue_lock, flags); } =============================================== 那么在__down(里面的这段区间, add_wait_queue_exclusive(&sem->wait, &wait); ... ... schedule(;

也就是, current进入信号量排队之后, 调用schedule(之前, 我们随时可能遭受"wake_up_process(". 如果在if (!atomic_add_negative(sleepers - 1, &sem->count)) 这句之前被wake_up_process(, 倒也无所谓, 因为反正我们能通过这个if拿到信号量, (既然有人up, 肯定就是有门票了). 但是如果这个if失败, 我们就要睡眠了. 在我们调用schdule入睡之前的这个空隙里, 即执行这几行代码的时候: sem->sleepers = 1; / us - see -1 above / spin_unlock_irq(&semaphore_lock); schedule(;
我们遭到了wake_up_process. 会发生什么呢? 其实看wake_up_process(的源码,它也做不了什么( 因为我们已经在运行队列里了 , 但它把我们的状态设置成TASK_RUNNING了. 就是说, 接下来, 我们是以"TASK_RUNNING"的身份调用schedule的. 更坏的是, 我们等于说是错过了这次up(, 再没有人来唤醒我们了.

我上面说的很麻烦, 简单的说, 就是, up(为什么不理睬semaphore_lock这个锁? 明明会出bug.

我想是我哪里错了, linux肯定不会有这种bug. 恳请指教.

* 为了方便一些, 我把相关的源码都贴上:


[== C++ ==]
== down(和up(的入口函数来自 include/asm-i386/semaphore.h
static inline void down(struct semaphore * sem)
{
#if WAITQUEUE_DEBUG
 CHECK_MAGIC(sem->__magic);
#endif
__asm__ __volatile__(
 &quot;# atomic down operation\n\t&quot;
 LOCK &quot;decl %0\n\t&quot; /* --sem-&gt;count */
 &quot;js 2f\n&quot;
 &quot;1:\n&quot;
 &quot;.section .text.lock,\&quot;ax\&quot;\n&quot;
 &quot;2:\tcall __down_failed\n\t&quot;
 &quot;jmp 1b\n&quot;
 &quot;.previous&quot;
 :&quot;=m&quot; (sem-&gt;count)
 :&quot;c&quot; (sem)
 :&quot;memory&quot;);

}
static inline void up(struct semaphore * sem)
{
#if WAITQUEUE_DEBUG
CHECK_MAGIC(sem->__magic);
#endif
asm volatile(
"# atomic up operation\n\t"
LOCK "incl %0\n\t" /* ++sem->count */
"jle 2f\n"
"1:\n"
".section .text.lock,&quot;ax&quot;\n"
"2:\tcall __up_wakeup\n\t"
"jmp 1b\n"
".previous"
:"=m" (sem->count)
:"c" (sem)
:"memory");
}
===fall through失败后的操作, 都在arch/i386/kernel/semaphore.c
asm(
".align 4\n"
".globl __down_failed\n"
"__down_failed:\n\t"
"pushl %eax\n\t"
"pushl %edx\n\t"
"pushl %ecx\n\t"
"call __down\n\t"
"popl %ecx\n\t"
"popl %edx\n\t"
"popl %eax\n\t"
"ret"
;
void __down(struct semaphore * sem)
{
struct task_struct *tsk = current;
DECLARE_WAITQUEUE(wait, tsk);
tsk->state = TASK_UNINTERRUPTIBLE;
add_wait_queue_exclusive(&sem->wait, &wait);
spin_lock_irq(&amp;semaphore_lock);
sem-&gt;sleepers++;
for (;;) {
 int sleepers = sem-&gt;sleepers;

 /*
 * Add &quot;everybody else&quot; into it. They aren't
 * playing, because we own the spinlock.
 */
 if (!atomic_add_negative(sleepers - 1, &amp;sem-&gt;count)) {
 sem-&gt;sleepers = 0;
 break;
 }
 sem-&gt;sleepers = 1; /* us - see -1 above */
 spin_unlock_irq(&amp;semaphore_lock);

 schedule(;
 tsk-&gt;state = TASK_UNINTERRUPTIBLE;
 spin_lock_irq(&amp;semaphore_lock);
}
spin_unlock_irq(&amp;semaphore_lock);
remove_wait_queue(&amp;sem-&gt;wait, &amp;wait);
tsk-&gt;state = TASK_RUNNING;
wake_up(&amp;sem-&gt;wait);

}
void __up(struct semaphore *sem)
{
wake_up(&sem->wait);
}
asm(
".align 4\n"
".globl __up_wakeup\n"
"__up_wakeup:\n\t"
"pushl %eax\n\t"
"pushl %edx\n\t"
"pushl %ecx\n\t"
"call __up\n\t"
"popl %ecx\n\t"
"popl %edx\n\t"
"popl %eax\n\t"
"ret"
;

* <情景分析>这部分的内容在403页前后.

关于pid和pid_hash、task_struct的一个问题

Wed, 26 Oct 2016 17:43:07 +0800

本文是原「蜗窝讨论区」的历史存档（2016-10-26），来自版块「Linux kernel技术问答」，共 13 帖。讨论区已停止服务，此处仅供查阅。

西人 · 2016-10-26 17:43

从一个pid_t（下面函数的nr），通过调用函数find_pid_ns，可以得到struct pid


[== Undefined ==]
struct pid *find_pid_ns(int nr, struct pid_namespace *ns)
{
 struct upid *pnr;
hlist_for_each_entry_rcu(pnr,
 &amp;pid_hash, pid_chain)
 if (pnr-&gt;nr == nr &amp;&amp; pnr-&gt;ns == ns)
 return container_of(pnr, struct pid,
 numbers[ns-&gt;level]);

return NULL;

}

那么我就可以通过container_of一步步得到task_struct，我觉得没必要在pid结构体中再设置字段struct hlist_head tasks;不知道这个字段有什么其他的用途吗？而且也没必要用一个struct hlist_head，就这个问题和大家交流一下


[== Undefined ==]
struct pid
{
 atomic_t count;
 unsigned int level;
 /* lists of tasks that use this pid */
 struct hlist_head tasks;
 struct rcu_head rcu;
 struct upid numbers[1];
};

Linux TTY framework(4)_TTY driver

Tue, 25 Oct 2016 22:40:31 +0800

本文将从驱动工程师的角度去看TTY framework：它怎么抽象、管理各个TTY设备？它提供了哪些编程接口以方便TTY driver的开发？怎么利用这些接口编写一个TTY driver？等等。注1：话说介绍各个framework的时候，我一直比较喜欢用provider、consumer等概念，因为非常生动、易懂。不过在TTY framework的官方俗语中，压根没有provider、consu

softfp 应用程序在armhf 的rootfs 执行

Fri, 21 Oct 2016 14:43:30 +0800

本文是原「蜗窝讨论区」的历史存档（2016-10-21），来自版块「Linux kernel技术问答」，共 2 帖。讨论区已停止服务，此处仅供查阅。

darren · 2016-10-21 14:43

背景简介：

gcc的选项 -mfloat-abi 有三种值 soft、softfp、hard（其中后两者都要求 arm 里有 fpu 浮点运算单元，soft 与后两者是兼容的，但 softfp 和 hard 两种模式互不兼容）： soft：不用fpu进行浮点计算，即使有fpu浮点运算单元也不用，而是使用软件模式。 softfp： armel架构（对应的编译器为 arm-linux-gnueabi-gcc ）采用的默认值，用fpu计算，但是传参数用普通寄存器传，这样中断的时候，只需要保存普通寄存器，中断负荷小，但是参数需要转换成浮点的再计算。 hard： armhf架构（对应的编译器 arm-linux-gnueabihf-gcc ）采用的默认值，用fpu计算，传参数也用fpu中的浮点寄存器传，省去了转换，性能最好，但是中断负荷高。

 Demo举例：
 arm-none-linux-gnueabi-gcc -o mfloat_soft mfloat.c -static -mfloat-abi=soft

___背景简介结束__

现在有很多softfp 应用程序,而且是动态编译,不能重编的情况下,是否能在armhf 的rootfs 执行?

现在执行的话,报如下,

root@linaro-alip:~# ./hello_worl_softfp -bash: ./hello_worl_softfp : No such file or directory

我想确认有什么办法,实在没办法才会换成armel的rootfs了,但工程量变大. 这个问题困扰着我,项目的成败就看这个问题是否有解决办法.谢谢各位能提出意见!

弯曲的旅行 · 2016-10-21 15:54

这估计很难，没办法做吧？

Linux内核启动执行完函数run_init_process(execute_command)后发生Kernel panic

Thu, 20 Oct 2016 23:36:35 +0800

本文是原「蜗窝讨论区」的历史存档（2016-10-20），来自版块「Linux kernel技术问答」，共 6 帖。讨论区已停止服务，此处仅供查阅。

活出自我 · 2016-10-20 23:36

问题:Linux内核启动时发生如log所示kernel panic:


[== HTML ==]
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 3
ThumbEE CPU extension supported.
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
devtmpfs: mounted
Freeing unused kernel memory: 284K (805f6000 - 8063d000)
kernel_init 0
kernel_init 1
execute /linuxrc...
kernel_init 9
Unhandled fault: imprecise external abort (0x1c06) at 0x00156042
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000007
CPU: 0 PID: 1 Comm: linuxrc Tainted: G W 3.10.31-ltsi-04995-g339abcb-dirty #1
[<80014de0>] (unwind_backtrace+0x0/0x104) from [<80012440>] (show_stack+0x20/0x24)
[<80012440>] (show_stack+0x20/0x24) from [<80450bb0>] (dump_stack+0x20/0x28)
[<80450bb0>] (dump_stack+0x20/0x28) from [<8044df98>] (panic+0x8c/0x1dc)
[<8044df98>] (panic+0x8c/0x1dc) from [<80024e9c>] (do_exit+0x768/0x830)
[<80024e9c>] (do_exit+0x768/0x830) from [<800250f0>] (do_group_exit+0x4c/0xac)
[<800250f0>] (do_group_exit+0x4c/0xac) from [<80031574>] (get_signal_to_deliver+0x188/0x50c)
[<80031574>] (get_signal_to_deliver+0x188/0x50c) from [<8044da1c>] (do_signal+0xbc/0x3e4)
[<8044da1c>] (do_signal+0xbc/0x3e4) from [<80011e64>] (do_work_pending+0xac/0xc0)
[<80011e64>] (do_work_pending+0xac/0xc0) from [<8000e840>] (work_pending+0xc/0x20)

自己在内核中加入的debug信息为:


[== C++ ==]
static int __ref kernel_init(void *unused)
{
 kernel_init_freeable(;
 /* need to finish all async __init code before freeing the memory */
 async_synchronize_full(;
 free_initmem(;
 mark_rodata_ro(;
 system_state = SYSTEM_RUNNING;
 numa_default_policy(;
flush_delayed_fput(;

if (ramdisk_execute_command) {
 if (!run_init_process(ramdisk_execute_command))
 return 0;
 pr_err(&quot;Failed to execute %s\n&quot;, ramdisk_execute_command);
}

printk(KERN_INFO&quot;kernel_init 0\n&quot;);

/*
 * We try each of these until one succeeds.
 *
 * The Bourne shell can be used instead of init if we are
 * trying to recover a really broken machine.
 */
if (execute_command) {
 printk(KERN_INFO&quot;kernel_init 1\n&quot;);
 printk(KERN_INFO&quot;execute %s...\n&quot;,
 execute_command);
 if (!run_init_process(execute_command))
 {
 printk(KERN_INFO&quot;kernel_init 9\n&quot;);
 return 0;
 printk(KERN_INFO&quot;kernel_init 10\n&quot;);
 }
 pr_err(&quot;Failed to execute %s. Attempting defaults...\n&quot;,
 execute_command);
}

printk(KERN_INFO&quot;kernel_init 2\n&quot;);
if (!run_init_process(&quot;/sbin/init&quot;) ||
 !run_init_process(&quot;/etc/init&quot;) ||
 !run_init_process(&quot;/bin/init&quot;) ||
 !run_init_process(&quot;/bin/sh&quot;))
 return 0;
printk(KERN_INFO&quot;kernel_init 3\n&quot;);

panic(&quot;No init found. Try passing init= option to kernel. &quot;
 &quot;See Linux Documentation/init.txt for guidance.&quot;);

}

背景及猜测可能出问题的点: 1、双核A9双核SOC。但是在uboot中将CPU 1至于了Debug模式。 2、log中出现了以下warning。


[== HTML ==]
Truncating RAM at 10000000-7fffffff to -7f7fffff (vmalloc region overlap).
BUG: mapping for 0xffa00000 at 0xffa00000 out of vmalloc space

DDR的地址范围为0x10000000~0x80000000。 3、使用的根文件系统为ramdisk,bootargs为 bootargs = "root=/dev/ram0 rw initrd=0x38000000,16M init=/linuxrc console=ttyS0,115200"; 4、uImage下的地址为0x10008000,ramdisk下载的地址为0x38000000 5、内核及交叉工具链版本:Linux version 3.10.31-ltsi-04995-g339abcb-dirty (root@Linux) (gcc version 4.7.3 20121106 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2012.11-20121123 - Linaro GCC 2012.11)

完整的log信息如下:


[== HTML ==]
tarting kernel ...
Uncompressing Linux… done, booting the kernel.
ooting Linux on physical CPU 0x0
Initializing cgroup subsys cpuset
Linux version 3.10.31-ltsi-04995-g339abcb-dirty (root@Linux) (gcc version 4.7.3 20121106 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2012.11-20121123 - Linaro GCC 2012.11) #2 SMP Thu Oct 20 11:28:12 EDT 2016
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: cma9, model: chipmotion cma9
Truncating RAM at 10000000-7fffffff to -7f7fffff (vmalloc region overlap).
Memory policy: ECC disabled, Data cache writealloc
BUG: mapping for 0xffa00000 at 0xffa00000 out of vmalloc space
PERCPU: Embedded 8 pages/cpu @8180e000 s11200 r8192 d13376 u32768
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 453136
Kernel command line: root=/dev/ram0 rw initrd=0x38000000,16M init=/linuxrc console=ttyS0,115200
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 262144 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 131072 (order: 7, 524288 bytes)
Memory: 1784MB = 1784MB total
Memory: 1787248k/1787248k available, 39568k reserved, 0K highmem
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
vmalloc : 0xf0000000 - 0xff000000 ( 240 MB)
lowmem : 0x80000000 - 0xef800000 (1784 MB)
modules : 0x7f000000 - 0x80000000 ( 16 MB)
.text : 0x80008000 - 0x80641468 (6374 kB)
.init : 0x80642000 - 0x80694bc0 ( 331 kB)
.data : 0x80696000 - 0x806d15d0 ( 238 kB)
.bss : 0x806d15d0 - 0x80710e84 ( 255 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
Hierarchical RCU implementation.
NR_IRQS:16 nr_irqs:16 16
sched_clock: 32 bits at 12MHz, resolution 80ns, wraps every 343597ms
Switching to timer-based delay loop
Console: colour dummy device 80x30
Calibrating delay loop (skipped), value calculated using timer frequency.. 25.00 BogoMIPS (lpj=125000)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
ftrace: allocating 17412 entries in 52 pages
schedule_preempt_disabled 0
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0x80497b98 - 0x80497bf0
CPU1: failed to boot: -38
Brought up 1 CPUs
SMP: Total of 1 processors activated (25.00 BogoMIPS).
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
L2x0 series cache controller enabled
l2x0: 8 ways, CACHE_ID 0x00000000, AUX_CTRL 0x00000000, Cache size: 65536 B
hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
hw-breakpoint: maximum watchpoint size is 4 bytes.
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
PTP clock support registered
Switching to clocksource arm_global_timer
NET: Registered protocol family 2
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 16384 (order: 5, 131072 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP: reno registered
UDP hash table entries: 1024 (order: 3, 32768 bytes)
UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Trying to unpack rootfs image as initramfs…
rootfs image is not initramfs (no cpio magic); looks like an initrd
Freeing initrd memory: 16384K (a8000000 - a9000000)
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
NTFS driver 2.1.30 .
jffs2: version 2.2. (NAND) 漏 2001-2006 Red Hat, Inc.
msgmni has been set to 3522
io scheduler noop registered (default)
Serial: 8250/16550 driver, 1 ports, IRQ sharing disabled
ttyS0: autoconf (0x0000, 0xfe020000): iir1=6 iir2=6 iir=3 type=16550A
fe020000.serial0: ttyS0 at MMIO 0xfe020000 (irq = 101) is a 16550A
console enabled
brd: module loaded
CAN device driver interface
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice
i2c /dev entries driver
Synopsys Designware Multimedia Card Interface Driver
ledtrig-cpu: registered to indicate activity on CPUs
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
oprofile: no performance counters
oprofile: using timer interrupt.
TCP: cubic registered
NET: Registered protocol family 10
sit: IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
NET: Registered protocol family 15
can: controller area network core (rev 20120528 abi 9)
NET: Registered protocol family 29
can: raw protocol (rev 20120528)
can: broadcast manager protocol (rev 20120528 t)
can: netlink gateway (rev 20130117) max_hops=1
8021q: 802.1Q VLAN Support v1.8
Key type dns_resolver registered
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 3
ThumbEE CPU extension supported.
Registering SWP/SWPB emulation handler
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
devtmpfs: mounted
Freeing unused kernel memory: 328K (80642000 - 80694000)
kernel_init 0
kernel_init 1
execute /linuxrc…
kernel_init 9
Unhandled fault: imprecise external abort (0x1c06) at 0x00156042
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000007
CPU: 0 PID: 1 Comm: linuxrc Not tainted 3.10.31-ltsi-04995-g339abcb-dirty #2
[<80016710>] (unwind_backtrace+0x0/0x104) from [<80012f50>] (show_stack+0x20/0x24)
[<80012f50>] (show_stack+0x20/0x24) from [<80493be4>] (dump_stack+0x20/0x28)
[<80493be4>] (dump_stack+0x20/0x28) from [<80490778>] (panic+0xa0/0x1f4)
[<80490778>] (panic+0xa0/0x1f4) from [<80028118>] (do_exit+0x844/0x914)
[<80028118>] (do_exit+0x844/0x914) from [<800283ac>] (do_group_exit+0x4c/0xd4)
[<800283ac>] (do_group_exit+0x4c/0xd4) from [<800357ec>] (get_signal_to_deliver+0x1b8/0x620)
[<800357ec>] (get_signal_to_deliver+0x1b8/0x620) from [<80012264>] (do_signal+0x110/0x41c)
[<80012264>] (do_signal+0x110/0x41c) from [<800128e4>] (do_work_pending+0x78/0xb8)
[<800128e4>] (do_work_pending+0x78/0xb8) from [<8000e8c0>] (work_pending+0xc/0x20)

请教大家用什么办法看程序从用户空间到内核的执行过程

Thu, 20 Oct 2016 21:20:24 +0800

本文是原「蜗窝讨论区」的历史存档（2016-10-20），来自版块「Linux kernel技术问答」，共 6 帖。讨论区已停止服务，此处仅供查阅。

wall-E · 2016-10-20 21:20

include <sys/types.h>

include <dirent.h>

include <unistd.h>

int main({ DIR * dir; struct dirent *ptr; dir = opendir("/sys/bus/serio"); while((ptr = readdir(dir))!=NULL){ printf("d_name :%s ",ptr->d_name); } closedir(dir); return -1; }

比如上面这个，我想看到在内核里怎么跟sysfs里面的读的过程。该怎么进行，先谢谢大家。我用strace命令然后加编译后的可执行文件，结果只看到有很多mmap

wowo · 2016-10-21 10:12

从用户空间顶多就跟到系统调用吧？需要往kernel跟的话，不知道有没有好方法，比如backtrace？

wall-E · 2016-10-21 18:46

wowo 写道： 从用户空间顶多就跟到系统调用吧？需要往kernel跟的话，不知道有没有好方法，比如backtrace？

wowo我看到这篇博文 http://blog.csdn.net/fudan_abc/article/details/1783837 /device_model/314.html 以及这篇，里面都写到一些调用过程----想知道是怎么得到上述过程的，毕竟有时候有几个分支吧

wowo · 2016-10-22 21:17

wall-E 写道：

wowo 写道： 从用户空间顶多就跟到系统调用吧？需要往kernel跟的话，不知道有没有好方法，比如backtrace？

这些都是读代码自己总结出来的吧？

electrlife · 2016-12-22 10:41

lz可以看下ftrace，可以看到函数级的调用，包括普通的非库函数！看看是否满足你的需求!

wowo · 2016-12-22 11:01

electrlife 写道： lz可以看下ftrace，可以看到函数级的调用，包括普通的非库函数！看看是否满足你的需求!

他想看kernel space的调用，ftrace看不到。

关于Boot from USB的问题，基于三星4412

Tue, 18 Oct 2016 15:49:34 +0800

本文是原「蜗窝讨论区」的历史存档（2016-10-18），来自版块「X Project」，共 7 帖。讨论区已停止服务，此处仅供查阅。

zmnqaz · 2016-10-18 15:49

三星4412的启动机制

iROM 通过OM配置sd/mmc/usb方式加载BL1，并且BL1文件头经过某种加密，后来找到了制作BL1的工具但是不清楚具体如何加密。

那么BL1就应该是实现将uboot.bin下载emmc或者内存中吧？并没有找到三星关于USB下载的资料，那岂不是要自己实现一套USB下载的协议吗？

zmnqaz · 2016-10-18 16:21

刚又看了一下三星的dnw,似乎可以用上。

ooonebook · 2016-10-18 21:23

BL1是指uboot-spl.bin,s5pv210需要加上16k的校验头。BL0会去验证这个校验头。我觉得4412应该也是类似的。我觉得你可以先用SD卡的方式，samsung把SD卡读写接口都做好了，代码固化在了ROM上，文档上应该可以找得到。 BL1放在SD卡的第一个扇区上，BL0会自动把这个扇区的内容加载到BL1上。

zmnqaz · 2016-10-19 08:59

ooonebook 写道： BL1是指uboot-spl.bin,s5pv210需要加上16k的校验头。BL0会去验证这个校验头。我觉得4412应该也是类似的。我觉得你可以先用SD卡的方式，samsung把SD卡读写接口都做好了，代码固化在了ROM上，文档上应该可以找得到。 BL1放在SD卡的第一个扇区上，BL0会自动把这个扇区的内容加载到BL1上。

SD卡启动是ok的。

BL0对于BL1的校验方式和s5p210并不清楚，官方手册也没有提到。网上流传的资料都是编写BL2用SD卡启动,BL1(官方提供的二进制文件，不提供源码)对BL2的校验方法是知道的，移植好的Uboot都采用这种方式。

如果想从USB下载就必须先搞定BL1，唯一知道的资料对文件头的加密也没弄清楚，感觉特别不爽。

wowo · 2016-10-19 10:02

zmnqaz 写道：

ooonebook 写道： BL1是指uboot-spl.bin,s5pv210需要加上16k的校验头。BL0会去验证这个校验头。我觉得4412应该也是类似的。我觉得你可以先用SD卡的方式，samsung把SD卡读写接口都做好了，代码固化在了ROM上，文档上应该可以找得到。 BL1放在SD卡的第一个扇区上，BL0会自动把这个扇区的内容加载到BL1上。

SD卡启动是ok的。

如果想从USB下载就必须先搞定BL1，唯一知道的资料对文件头的加密也没弄清楚，感觉特别不爽。

从这个文件里面看到的： S5PV210_iROM_ApplicationNote_Preliminary_20091126.pdf UART/USB启动，不需要header，你可以试试。

ooonebook · 2016-10-19 10:06

zmnqaz 写道：

ooonebook 写道： BL1是指uboot-spl.bin,s5pv210需要加上16k的校验头。BL0会去验证这个校验头。我觉得4412应该也是类似的。我觉得你可以先用SD卡的方式，samsung把SD卡读写接口都做好了，代码固化在了ROM上，文档上应该可以找得到。 BL1放在SD卡的第一个扇区上，BL0会自动把这个扇区的内容加载到BL1上。

SD卡启动是ok的。

如果想从USB下载就必须先搞定BL1，唯一知道的资料对文件头的加密也没弄清楚，感觉特别不爽。

不好意思前面说错了，头部是16B，我记得当时看过4412和210给uboot-spl加校验头部的方法是一样的，uboot里面已经做好了脚本的。确实用SD卡是比较简单点，所以你可以先用SD卡启动的方式。先不要纠结USB下载，先保证uboot-spl是可以被BL0校验成功的。然后再考虑通过usb把uboot-spl加载到ram相应位置上。总之个人觉得先不要考虑那么多，那实现project-X项目上编译出来uboot-spl.bin在你的机子上可以成功跑起来。参考代码中应该有裸机代码，一般也是放在IRAM里面实现，也是有加头部的，你也可以参考一下参考代码里面裸机bin编译过程是怎么加头部的。

DRAM 原理 5 ：DRAM Devices Organization

Sat, 15 Oct 2016 09:12:08 +0800

随着系统对内存容量、带宽、性能等方面的需求提高，系统会接入多个 DRAM Devices。而多个 DRAM Devices 不同的组织方式，会带来不同的效果。本文将对不同的组织方式及其效果进行简单介绍。

Linux TTY framework(3)_从应用的角度看TTY设备

Fri, 14 Oct 2016 22:13:33 +0800

可以毫不夸张的说，我们在使用Linux系统的过程中，每时每刻都在和TTY打交道，显示输出、键盘输入、用户登录、shell终端、等等。与此同时，作为软件工程师的我们，也会或多或少的困惑：这些习以为常的行为，怎么和kernel中的这些冷冰冰的代码联系起来的？因此，在Linux TTY framework分析工作正式开始之前，让我们带着上面的疑问，以这些熟悉的应用场景为视角，进一步理解TTY有关的概

smp下，task在各CPU迁移问题

Fri, 14 Oct 2016 10:02:45 +0800

本文是原「蜗窝讨论区」的历史存档（2016-10-14），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

温柔海洋 · 2016-10-14 10:02

多核下，bootcpu,和非boot cpu 的执行情况应该有很大区别的，非boot cpu不能执行任务切换吧，得靠boot cpu 执行任务切换，选中一个多余的（就是boot cpu已经有执行de task了）需要运行的task，把它通过发送IPI消息机制发送给非boot cpu去执行

蜗蜗群里也在讨论：

话唠】絕對の零度 @温柔海洋非bootcpu 不能进行任务切换？

【话唠】温柔海洋 2016/10/13 18:42:29 非bootcpu要是也切换岂不乱套了我看到非bootcpu执行任务的唯一接口好像就是ipi，唯一通道把

【话唠】絕對の零度 2016/10/13 18:46:02 没有哦所有的cpu都有自己的runqueue 【话唠】絕對の零度 2016/10/13 18:47:07 为什么需要bootcpu发ipi做为切换点？ 2016/10/13 18:54:06 【话唠】温柔海洋 2016/10/13 18:54:06 我看到一篇文章讲任务切换时，bootcpu会调用reschedule idle函数再选一个task通过ipi选定一个其他cpu去执行 2016/10/13 18:56:54 【话唠】温柔海洋 2016/10/13 18:56:54 多核设计中主从cpu的作用应该不是对等把，要不怎么会有主从之分 2016/10/13 18:59:28 【话唠】絕對の零度 2016/10/13 18:59:28 运行的时候是对等的 2016/10/13 18:59:48 【话唠】絕對の零度 2016/10/13 18:59:48 不对等往往是上电热插拔的时候【话唠】絕對の零度 2016/10/13 19:00:09 例如cpu上电时，只会有bootcpu启动【话唠】絕對の零度 2016/10/13 19:00:34 其他的core都没上电，以后bootcpu再给非bootcpu上电【话唠】絕對の零度 2016/10/13 19:01:31 但在运行的时候，每个core都会建立自己的调度域 2016/10/13 19:04:10 【话唠】絕對の零度 2016/10/13 19:04:10 任务只会处于一个调度域中（假设一个core就是一个调度域），任务要去另外一个core要靠cfs调度（实时进程在创建时就会选择好cpu，运行时不会乱跑），从一个调度域迁移到另一个调度域

【吐槽】Brian CPU运行起来是对等的 7:53:59 【吐槽】Brian 2016/10/14 7:53:59 一开始非boot CPU是等待的一般等待再原始bootloader里【吐槽】Brian 2016/10/14 7:54:37 启动内核后 CPU0设置好环境才会唤醒其他CPU 【吐槽】Brian 2016/10/14 7:55:12 每个CPU都有自己的IDLE 里面有做任务切换的【吐槽】Brian 2016/10/14 7:55:43 其他。地方也有任务切换。但是有点复杂【吐槽】Brian 2016/10/14 7:55:48 还没看懂

以上是群里的讨论，感觉如果运行起来后，是对等的模型，各个CPU角色都一样，那么各个CPU都可以做任务切换的话，都可以把自己的task 发送给其他CPU去执行。这样管理起来应该没有做成主从结构下，只有CPU0有发送task到其他CPU的权限，其他CPU没迁移task权限。没主从结构下设计简单。

我是这方面的小白，请教下大神们。

linux 中断没有优先级的问题

Thu, 13 Oct 2016 16:21:19 +0800

本文是原「蜗窝讨论区」的历史存档（2016-10-13），来自版块「Linux kernel技术问答」，共 3 帖。讨论区已停止服务，此处仅供查阅。

温柔海洋 · 2016-10-13 16:21

现在比较新的Linux内核中断还是没有优先级区分吗？那么没有优先级的话，只要一个类型的中断上半部在执行，随便其他类型的中断都可以打断它,发生中断嵌套。

那么如果正在执行的是时钟tick等一些比较重要的中断，被一些不重要的中断经常打断时，这些不重要的中断上半部如果设计的不怎么好，执行时间过长的话，Linux怎么保证时钟tick及其他对时延要求很苛刻的中断的及时响应呢?

现在一些RTOS都有中断优先级概念，保证高优先级任务处理时不被低优先级中断打扰，Linux在中断设计方面感觉做的实时性还是比较差？

linuxer · 2016-10-13 23:15

其实新版本的内核已经不再区分fast handler（全程关闭本地中断）和slow handler了（开中断，其他类型的interrupt可以中断该handler的执行），取而代之的是全部采用了fast handler，也就是说，该handler会安安静静的全部执行完毕，不会被其他中断打断（除非你的handler中自己主动打开中断）。当然，配合这样的设计，所有的中断的handler（即上半部处理）都必须尽快完成，如果需要消耗非常多的CPU，那么考虑推迟到bottom half去执行。

中断优先级，这似乎应该是中断控制器的内容，GIC其实是支持中断优先级的概念的。

温柔海洋 · 2016-10-14 09:53

我已经明白了，谢谢 linuxer, 我查到我当前Linux版本时3.0.35，这个版本的./include/linux/interrupt.h 对IRQF_DISABLED的描述是： keep irqs disabled when calling the action handler. * DEPRECATED. This flag is a NOOP and scheduled to be removed

就是说内核实现为空，这应该就是说明该版本内核，用户自定义的中断上半部执行时，不会被其他任何中断打断的，会全部执行完毕的，是吧。因为因为废弃IRQF_DISABLED这个FLAG后，肯定默认行为是中断执行时，禁止其他中断的执行。

内存初始化（上）

Thu, 13 Oct 2016 12:05:52 +0800

一直以来，我都非常着迷于两种电影拍摄手法：一种是慢镜头，将每一个细节全方位的展现给观众。另外一种就是快镜头，多半是反应一个时代的变迁，从非常长的时间段中，截取几个典型的snapshot，合成在十几秒的镜头中，可以让观众很快的了解一个事物的发展脉络。对应到技术层面，慢镜头有点类似情景分析，把每一行代码都详细的进行解析，了解技术的细节。快镜头类似数据流分析，勾勒一个过程中，数据结构的演化。本文采用了快

Linux kernel初始化时调用的do_initcalls里面并行执行问题

Mon, 10 Oct 2016 13:38:10 +0800

本文是原「蜗窝讨论区」的历史存档（2016-10-10），来自版块「Linux kernel技术问答」，共 4 帖。讨论区已停止服务，此处仅供查阅。

温柔海洋 · 2016-10-10 13:38

我的Linux内核开发包里有两个I2C 触摸屏driver，都在driver/input/touchscreen/下面，两个driver的初始化函数都通过module_init，放在了__initcall_段里面，由do_initcalls依次调用执行。

现在项目组同事有观察到两个driver的probe 同时并发执行了。因为两个driver 的probe并发执行了，而且都会调用到同样的GPIO操作，所以我们不得不在两个probe里面都加了锁保护。

我的推测是kernel初始化时，即使是SMP架构，应该不会并发执行代码吧。但是我也不太确定我的推测。如果两个probe并发执行的话，难道多核情况下，函数do_initcalls调用时，因为SMP架构已经初始化完毕，这个时候虽然两个drvier的init函数看代码样子是顺序执行的，但是init函数执行完，两个i2c driver在I2C 总线上的匹配成功后，两个driver的probe有可能是并发执行的吗（比如两个核各执行一个probe）？

请大家谁知道的，答疑下，谢谢。（我的Linux内核版本是3.0.35）

wowo · 2016-10-10 15:12

温柔海洋写道： 我的Linux内核开发包里有两个I2C 触摸屏driver，都在driver/input/touchscreen/下面，两个driver的初始化函数都通过module_init，放在了__initcall_段里面，由do_initcalls依次调用执行。

请大家谁知道的，答疑下，谢谢。（我的Linux内核版本是3.0.35）

按理说,如果是build in kernel的driver的话,initcall只能在boot cpu上顺序执行,执行过程中,只有可能被中断打断. 因此不应该出现你所说的"并发执行"的现象.

李培锋 · 2018-02-06 10:26

以下是我的理解：initcall之前通过kernel_init(->kernel_init_freeable(->smp_init(已经开启了多核，只是do_initcalls调用每个level的初始化的时候选择了串行启动，也就是驱动的init函数，但是probe函数我的理解可以并行的，所以如果你需要串行走，通过init函数初始化应该是可以实现的。

xj916ch · 2018-04-09 11:02

可以参考编译出来的System.map，或者烧机后的/proc/kallsyms文件

ptp clock 模块中owner的设定问题

Sat, 08 Oct 2016 11:18:37 +0800

本文是原「蜗窝讨论区」的历史存档（2016-10-08），来自版块「Linux kernel技术问答」，共 2 帖。讨论区已停止服务，此处仅供查阅。

linuxer · 2016-10-08 11:18

您好 linuxer，请教一个问题：

我在读 linux-3.19.y 版本的 driver/ptp/ptp_clock.c 时看到使用 ptp clock 模块使用 posix_clock_register 注册 posix clock 时 posix_clock_operations 结构体 ptp_clock_ops 的 owner 设置为 THIS_MODULE（我理解这个 THIS_MODULE 为 ptp clock 模块）

static struct posix_clock_operations ptp_clock_ops = { .owner = THIS_MODULE, ... ... };

进入 posix_clock_register 函数时将 posix_clock -> cdev.owner 也设置为 ptp_clock_ops.owner

int posix_clock_register(struct posix_clock *clk, dev_t devid) { ... ...

cdev_init(&amp;clk-&gt;cdev, &amp;posix_clock_file_operations);
clk-&gt;cdev.owner = clk-&gt;ops.owner;
... ...

}

可是在 posix-clock.c 中 file_operations 结构体 posix_clock_file_operations（也就是上面 cdev_init 函数中传入的 file_operations 结构体）的 owner 被设置为 THIS_MODULE，这个 THIS_MODULE 指的是什么？如果指的是 posix-clock 的话，会不会又矛盾？

请教一下 linuxer 对于这样的设计，您是怎么看？

X-013-UBOOT-使能autoboot功能

Wed, 05 Oct 2016 21:51:57 +0800

通过“ X-012-KERNEL-serial early console的移植 ”，早期的串口控制台已经ready，kernel的printk可以正确输出，“ X Project ”由此进入“文明”时代。基于此，后续的开发工作将会focus在linux kernel上，而u-boot，可以蜕化为其原始目标：boot kernel。在之前的测试和调试过程中，都是先进入u-boot的命令行，手动输

X-012-KERNEL-serial early console的移植

Sun, 02 Oct 2016 22:50:51 +0800

对Linux kernel工程师来说，最依赖的工具非printk莫属（不多解释，大家都懂）。因此，在Linux kernel移植的初期阶段，如果能够尽快地实现printk功能，将会为后续的工作带来极大的帮助。在众多可用作printk输出的终端里面（串口、屏幕、USB、网络、等等），串口终端（也即串口驱动）无疑是实现起来最简单一种，因此也是嵌入式linux开发过程中（特别是早期阶段）最普遍使用的。

第一次对一个东西相见恨晚

Wed, 28 Sep 2016 10:28:02 +0800

本文是原「蜗窝讨论区」的历史存档（2016-09-28），来自版块「灌水区」，共 2 帖。讨论区已停止服务，此处仅供查阅。

HHP_Low · 2016-09-28 10:28

谢谢蜗窝科技咯谢谢wowo和linuxer了真的是我见过的程序猿里最会写文章的了。相见很晚，其实是搜很多的问题总会有蜗窝的页面出来2333。

吐槽一把。我是一名刚刚步入linux driver的菜鸟哈，我觉得驱动最头疼的就是看原理图和文档了，尤其对我这种没有接触过硬件的=-=。然后还一直碰到什么的总线啊，时序啊，波形啊，巴拉巴拉。做驱动真的比较苦逼哈，不如做app 前端那种写完就可以看到，还可以给别人分享下。我们？？来，你看跑起来了！

谢谢wowo和linuxer

linuxer · 2016-09-28 15:08

:D 能在这里相遇就素那缘分啊！每一个牛人也都有不堪回首的往事，谁开始不是初哥呢？！哈哈，但愿蜗窝能助力各位愿意在嵌入式linux行业中深耕的工程师，让linux driver的菜鸟最终也能飞上自由软件的天空。

Linux TTY framework(2)_软件架构

Tue, 27 Sep 2016 22:42:56 +0800

由“ Linux TTY framework(1)_基本概念 ”的介绍可知，在Linux kernel中，TTY就是各类终端（Terminal）的简称。为了简化终端的使用，以及终端驱动程序的编写，Linux kernel抽象出了TTY framework：对上，向应用程序提供使用终端的统一接口；对下，提供编写终端驱动程序（如serial driver）的统一框架。本文是Linux TTY fra

Linux下“用户空间修改设备寄存器或者物理内存”的问题

Mon, 26 Sep 2016 14:59:30 +0800

本文是原「蜗窝讨论区」的历史存档（2016-09-26），来自版块「Linux kernel技术问答」，共 4 帖。讨论区已停止服务，此处仅供查阅。

anchen · 2016-09-26 14:59

我想请教一个和O_SYNC有关的具体问题。

我的系统是Altera的SoC，我要在用户空间为DMAC（pl330）更新其微码，结果发现DMA第一次运行正常，第二次运行依然执行前一次操作（虽然微码中的源和目的我都更新过了）。现在的结论是，因为这个SoC的架构，DMAC总是通过ACP访问L2 cache，意外着，DMA第一次会将微码锁存在L2 cache中，而用户空间在更新微码的过程中，没有处理L2 cache和memory的一致性，造成DMA第二次访问时，L2 cache依然命中，所以再次运行第一次的操作。我考虑过如下O_SYNC的使用，但也没有成功，不知道这样使用对不对？

FdforOcm = open("/dev/mem", O_RDWR); OcmAddr = mmap(NULL, 0x40000, PROT_READ|PROT_WRITE, MAP_SHARED, FdforOcm, 0xFFE00000); //这个返回的地址用来给程序更新DMA微码，不使用O_SYNC，意味着一定会写入cache，然后更新memory吗？

FdforDMA = open("/dev/mem", O_RDWR | O_SYNC); DMAAddr = mmap(NULL, 0x1000, PROT_READ|PROT_WRITE, MAP_SHARED, FdforDMA, 0xFFDA0000);
//这个返回的地址用来给程序访问DMA的寄存器

anchen · 2016-09-26 15:01

我两种都试了，无论是加还是不加 O_SYNC，结果似乎都是直接写入最终的物理设备，而没有同时更新到cache。有没有什么办法可以满足我的要求，写入最终设备的同时，更新到cache？或者说，如何在更新物理设备的同时，能够在用户空间，失效相对应的那部分cache？对现在的情况来说，我只要求物理memory和L2 cache能保持一致就可以了。

wowo · 2016-09-26 18:47

我觉得你的需求应该就是invalidate l2 cache？以arm平台为例，其实就是一条写p15协处理器的指令（当然，需要一些内存屏障操作）。 arm平台为这个需求抽象出来了一系列的接口，头文件在：arch/arm/include/asm/outercache.h 可以参考kernel中某些CPU的实现，例如：arch/arm/mm/cache-feroceon-l2.c 当然，如果粗暴一些，你也可以自己写一个，开放给用户空间程序使用。不知道还有没有其它好的方法？知道的同学也吱一声~~~

linuxer · 2016-09-27 18:59

wowo 写道： 我觉得你的需求应该就是invalidate l2 cache？以arm平台为例，其实就是一条写p15协处理器的指令（当然，需要一些内存屏障操作）。 arm平台为这个需求抽象出来了一系列的接口，头文件在：arch/arm/include/asm/outercache.h 可以参考kernel中某些CPU的实现，例如：arch/arm/mm/cache-feroceon-l2.c 当然，如果粗暴一些，你也可以自己写一个，开放给用户空间程序使用。不知道还有没有其它好的方法？知道的同学也吱一声~~~

我觉得选择mapping成 write back cache辅以clean cache to poc会比较适合这个用户场景。当然，如果选择mapping成non cache的，那么invalidate cache to poc指令也能让功能正常（应该在DMAC访问memory之前进行，确保DMAC可以访问到main memory中的更新后的数据），只是性能受一点影响。

papaya内核更新了

Sat, 24 Sep 2016 02:01:24 +0800

本文是原「蜗窝讨论区」的历史存档（2016-09-24），来自版块「Linux kernel技术问答」，共 3 帖。讨论区已停止服务，此处仅供查阅。

karma303 · 2016-09-24 02:01

这次的版本号是0.609。

主要增加了mm_struct, vm_area这两个数据结构。这是一个大的进步。新添的几个功能是：mmap(, brk(, fork(, execve(。 fork(和execve(我感觉我一直在写，原先内核那么简陋的时候，就有一个裸奔的fork(和execve 。。。

内核线程只能fork(出来内核线程。内核线程可以（也只可以）execve(出来用户进程。用户进程fork(和execve(出来的当然都是用户进程。上面4步都走完，fork(和execve(的功能基本就具备了。我编写的顺序也是这样。现在完成了第三步。

这是papaya内核的第一个用户程序：


[== Undefined ==]
#include "syscall.h"
static char g_array[10] = {1, 2, 3, 4, 5, 6};
int static_array[1024];
void doado(void){
int x;
for(int i = 0; i < 10; i++) printf("%u\n", g_array[i]); //测试.data的内存区
int ret = fork(;
printf("I am back ! %u\n", ret);
while(2){
static_array[1023] = 3; //这一句是测试bss的内存区
}
}

它是这么编译的：


[== Undefined ==]
doado: doado.c
 gcc -c doado.c -fno-builtin -std=c99 -g
 ld -static -e doado -o doado doado.o

这是运行的画面：

上面的12345, 123是fork(后，父子进程各自收到的返回值。那些页错误，有的是copy-on-write，有的是map on demand。

有兴趣的朋友欢迎去看看。 https://github.com/weiweishuo/papaya 这是我的博客地址： http://user.qzone.qq.com/2106507650/2

收工。好久没熬夜了。。。

TLB flush操作

Fri, 23 Sep 2016 19:57:20 +0800

Linux VM subsystem在很多场合都需要对TLB进行flush操作，本文希望能够把这个知识点相关的方方面面描述清楚。第二章描述了一些TLB的基本概念，第三章描述了ARM64中TLB的具体硬件实现，第四章描述了linux中和TLB flush相关的软件接口。内核版本依然是4.4.6版本。

kernel reboot -> device_shutdown(void) 函数相关疑惑

Mon, 19 Sep 2016 15:43:47 +0800

本文是原「蜗窝讨论区」的历史存档（2016-09-19），来自版块「Linux kernel技术问答」，共 10 帖。讨论区已停止服务，此处仅供查阅。

victor.guo · 2016-09-19 15:43

大家好，初次发帖，请多多支持。

项目过程中遇到一个很棘手的问题，详细如下：手机进行自动开关机压力测试（高通8937）400-1000次左右大概会有一次卡住导致不关机（并没有kernel panic），现象就是卡在关机动画，adb还可以连，uart log也正常输出，我的做法就是把kernel 关机流程全部加上printk，然后弄10台机器进行压力测试，等到出现问题后，触发ramdump，再解开ramdump，查看kmsg中加的trace走到哪一步进一步分析卡在哪里。

但是这个情况很特殊！！！！加了kernel log后，浮现概率大大降低，就算进行2000次测试也不一定可以出现问题（进一步怀疑是某一个dev时序问题卡住，但是不知道凶手是谁..），好不容易抓到一次，大致定位到了出问题就是卡在函数就是 device_shutdown函数，可惜log太少没有找出卡在具体哪一个device，现在还在继续压力测试中，我们分析极有可能是卡在pm_runtime_barrier 函数中，但是这个内核函数有点复杂，不太懂这块。希望有高手可以指定一二，重点详细的帮忙分析下device_shutdown 整个函数，多谢！！！！！集思广益，希望大神们不吝给出各种调试分析手段！

void device_shutdown(void) { struct device dev, parent;

 spin_lock(&amp;devices_kset-&gt;list_lock);
 /*
 * Walk the devices list backward, shutting down each in turn.
 * Beware that device unplug events may also start pulling
 * devices offline, even as the system is shutting down.
 */
 while (!list_empty(&amp;devices_kset-&gt;list)) {
 dev = list_entry(devices_kset-&gt;list.prev, struct device,
 kobj.entry);

** dev_p = (char )dev->kobj.name; step1++;*

 /*
 * hold reference count of device's parent to
 * prevent it from being freed because parent's
 * lock is to be held
 */
 parent = get_device(dev-&gt;parent);
 get_device(dev);
 /*
 * Make sure the device is off the kset list, in the
 * event that dev-&gt;*-&gt;shutdown( doesn't remove it.
 */
 list_del_init(&amp;dev-&gt;kobj.entry);
 spin_unlock(&amp;devices_kset-&gt;list_lock);
 /* hold lock to avoid race with probe/release */
 if (parent)
 device_lock(parent);
 device_lock(dev);

 /* Don't allow any more runtime suspends */
 pm_runtime_get_noresume(dev);
 pm_runtime_barrier(dev);

 ** step2++;**

 if (dev-&amp;gt;bus &amp;amp;&amp;amp; dev-&amp;gt;bus-&amp;gt;shutdown) {
 if (initcall_debug)
 dev_info(dev, "shutdown\n");
 dev-&amp;gt;bus-&amp;gt;shutdown(dev);
 } else if (dev-&amp;gt;driver &amp;amp;&amp;amp; dev-&amp;gt;driver-&amp;gt;shutdown) {
 if (initcall_debug)
 dev_info(dev, "shutdown\n");
 dev-&amp;gt;driver-&amp;gt;shutdown(dev);
 }

 device_unlock(dev);
 if (parent)
 device_unlock(parent);

 put_device(dev);
 put_device(parent);

 spin_lock(&amp;amp;devices_kset-&amp;gt;list_lock);
 }
 spin_unlock(&amp;amp;devices_kset-&amp;gt;list_lock);

}

上面的 dev_p = (char *)dev->kobj.name; 和step1，step2是我加的计数器，用于记录出问题时候跑了哪一步，是哪个dev卡住，可惜目前还没出结果，只能从代码层级深入挖掘o(╯□╰)o

Linux TTY framework(1)_基本概念

Sun, 18 Sep 2016 22:55:42 +0800

由于串口的缘故，TTY是Linux系统中最普遍的一类设备，稍微了解Linux系统的同学，对它都不陌生。尽管如此，相信很少有人能回到这样的问题：TTY到底是什么东西？我们常常挂在嘴边的终端（terminal）、控制台（console）等概念，到底是什么意思？本文是Linux TTY framework分析文章的第一篇，将带着上述疑问，介绍TTY有关的基本概念，为后续的TTY软件框架的分析，以及Li

armv8 安全想关

Sun, 11 Sep 2016 08:51:50 +0800

本文是原「蜗窝讨论区」的历史存档（2016-09-11），来自版块「Linux kernel技术问答」，共 4 帖。讨论区已停止服务，此处仅供查阅。

Assin · 2016-09-11 08:51

有没有大神可以进解下armv8安全想关的东西，比如el3,el1切换，trustzone,TEE等

bulunhaimu · 2016-09-19 13:12

我在关注trustzone，也是刚入门

wowo · 2016-09-19 13:26

实在抱歉，ARMv8安全方面的东西，我们也只是感兴趣，还没有时间去研究。希望大家多多分析~~

victor.guo · 2016-09-19 15:27

el0-el3属于ARMV8架构新增的exception level概念，对应关系如下： el0 --- APP el1 --- linux kernel el2 -- hypervisor el3 --- secure monitor

而trustzoon 就属于secure monitor内实现， el1到el3直接的切换需要发生exception的方式，比如特别发起smc的system call，如果el3-》el1则是发起svc的system call

参考：ARMv8 architecture.

[x-project tiny210] tiny210操作说明

Sat, 10 Sep 2016 23:40:56 +0800

本文是原「蜗窝讨论区」的历史存档（2016-09-10），来自版块「X Project」，共 10 帖。讨论区已停止服务，此处仅供查阅。

ooonebook · 2016-09-10 23:40

声明：s5pv210在该uboot和kernel版本上已经支持得很好了，所以改的代码很少，主要是一些简单的移植操作和部署。目前可以启动到command line位置。在此感谢wowo的无私指导。

一、准备操作 1、代码 github下载地址： build:https://github.com/wowotechX/build.git uboot:https://github.com/wowotechX/u-boot.git kernel:https://github.com/wowotechX/linux.git tools:https://github.com/wowotechX/tools.git （1）git clone下载以上代码到同一目录下。（2）注意：由于tiny210没有合到主分支上，上述所有都需要切换到tiny210分支上，命令如下： git checkout --track origin/tiny210 2、编译器 （1）进入build目录。（2）在config.mk中配置如下（在tiny210分支上已经是默认了）（3）执行“make env_prepare” 会下载arm-none-linux-gnueabi-4.8编译器。在tiny210编译的过程中，都使用这个编译器。 3、软件 在制作ramdisk的过程中，需要安装genext2fs、gzip命令，可以通过apt-get install进行安装。（1）ubuntu环境下安装genext2fs sudo apt-get install genext2fs （2）ubuntu环境下安装gzip sudo apt-get install gzip

二、编译操作 以下都是在build目录下进行操作. 在config.mk中配置如下（在tiny210分支上已经是默认了）： 1、uboot 执行“make uboot” 生成 out/u-boot/u-boot.bin out/u-boot/spl/u-boot-spl.bin out/u-boot/spl/tiny210-spl.bin

2、kernel、dtb 执行“make kernel” 生成 out/linux/arch/arm/boot/Image out/linux/arch/arm/boot/zImage out/linux/arch/arm/boot/dts/s5pv210-tiny210.dtb

3、rootfs tools/common/rootfs中就是根文件系统的一些东西。但是刚拉下的代码中busybox还是空的。（1）执行“make busybox” 在rootfs中安装busybox （2）在config.mk中配置要生成的rootfs的格式为ramdisk 执行“make rootfs” 生成 out/rootfs/ramdisk.img out/rootfs/ramdisk.gz

4、legacy_uimage （0）如果需要生成传统格式的uimage，需要在config.mk中配置如下：（1）执行“make kernel-img” 生成 out/linux/arch/arm/boot/uImage

5、fit_uimage （0）如果需要生成FIT格式的uimage，需要在config.mk中配置如下：（1）执行“make kernel-img” 生成 out/xprj_uImage.itb 注意：4、5只需要根据uImage的格式选择其中一种。legacy_uimage是在zImage加上uboot使用的64B的头部。fit_uimage则是组合了Image（zImage）、ramdisk、dtb的镜像，uboot会对其进行解析。具体请参考wowo的《u-boot FIT image介绍》《X-011-UBOOT-使用bootm命令启动kernel(Bubblegum-96平台)》两篇文章

三、烧录操作 以下都是在tools/samsung/tiny210目录下操作。需要先执行“sudo fdisk -l”看看sdb是否已经存在，保证sdcard已经被挂载上了。

0、使用SDcard来存放镜像 SDcard部署如下（扇区）： spl: SEC_UBOOT_SPL=1-48（29KB） uboot: SEC_UBOOT=49-1072（512KB） legacy_uimage: SEC_UIMAGE=1073-5168（2MB） dtb: SEC_DTB=5169-5296（64KB） ramdisk: SEC_ROOTFS=5297-13488（4MB） fit: SEC_FIT_IMAGE_START=13489

1、uboot 需要保证上述<二、1><二、4>步骤完成 ./flash_sdcard.sh uboot 会烧写spl.bin和uboot.bin到SDcard对应位置上。

2、kernel（legacy_uimage）& dtb 需要保证上述<二、2>步骤完成 ./flash_sdcard.sh kernel 会烧写legacy_uimage和dtb到SDcard对应位置上。

3、rootfs（ramdisk） 需要保证上述<二、3>步骤完成 ./flash_sdcard.sh rootfs 会烧写ramdisk到SDcard对应位置上。

4、fit-image 需要保证上述<二、5>步骤完成 ./flash_sdcard.sh fit_image 会烧写fit uimage到SDcard对应位置上。

四、启动操作 插入SD card到tiny210的板子上，将模块开关切换到SDBOOT模式，也就是从sdcard上加载spl的模式。 0、目前为了开发方便，在uboot中已经实现自动将镜像复制到ddr的对应位置上。 也就是说无需输入其他命令来复制镜像到ddr上。 ddr的部署如下： legacy_uimage：0x20008000 dtb：0x22000000 ramdisk：0x21000000 fit_image：0x30000000

1、通过uimage、ramdisk、dtb启动kernel（也就是通过传统的uImage来启动kernel） 需要保证<三、1><三、2><三、3>步骤完成在uboot的command line中，执行 “bootm 0x20008000 0x21000000 0x22000000” 到这里，kernel就跑起来了并且跑到了kernel的command line中。

2、通过fit_uimage的方式来启动kernel（也就是通过FIT格式的uImage来启动kernel） 需要保证<三、4>步骤完成在uboot的command line中，执行 “bootm 0x30000000” 到这里，kernel就跑起来了并且跑到了kernel的command line中。

【任务4】启动Linux kernel到命令行

Sat, 10 Sep 2016 21:49:20 +0800

本文是原「蜗窝讨论区」的历史存档（2016-09-10），来自版块「X Project」，共 9 帖。讨论区已停止服务，此处仅供查阅。

wowo · 2016-09-10 21:49

任务说明通过“【任务3】Linux kernel的配置、编译、加载与启动”，已经可以成功boot linux kernel并点亮LED了。基于此，我们可以展开第四个任务：启动Linux kernel到命令行（验收标准相当直接，不多说了）。完成该任务的基本步骤包括：
init/main.c中，增加一个简单的点LED的函数，以便用于最初的debug[/*]
为了方便后续的开发，尽早实现kernel的串口打印功能[/*]
完善dts文件，增加memory有关的信息，以便kernel可以正确初始化memory[/*]
debug IRQ、Timer有关的功能[/*]
debug其它功能，使kernel可以正确完成初始化过程[/*]
制作一个ramdisk，作为临时的rootfs，并启动至命令行[/*]
涉及的知识点该任务主要涉及如下知识点：
Linux kernel early console功能[/*]
Linux kernel串口子系统[/*]
Linux kernel memory、IRQ、Timer等基础功能的移植[/*]
Linux kernel的初始化流程，包括start_kernel、reset_init等[/*]
ramdisk、rootfs有关的知识[/*]
完成任务的思路该任务可以拆分为几个独立的部分：
将Linux kernel启动流程拆分为较为独立的功能，并完成一系列的分析文档（估计是一个漫长的过程）[/*]
为linux kernel early console功能写两篇文章，一篇是功能分析，一篇是移植说明[/*]
为linux kernel memory、IRQ、Timer等模块，分别写一篇文章，说明移植过程，并穿插有关的device tree知识[/*]
着手进行Linux kernel串口子系统的分析，会产出多篇文章，包括serial、TTY、console等等[/*]
写一篇文章，介绍基于ramdisk的rootfs的制作过程[/*]
其它等等，欢迎大家补充[/*]

最后，还是老话，感兴趣的同学可以认领任务

任务总结到目前为止（2016/12/06），该任务在bubblegum 96boards上基本完成，共有如下的文档产出：
X-012-KERNEL-serial early console的移植[/*]
X-013-UBOOT-使能autoboot功能[/*]
X-014-KERNEL-ARM GIC driver的移植[/*]
X-015-KERNEL-ARM generic timer driver的移植[/*]
X-016-KERNEL-串口驱动开发之驱动框架[/*]
X-017-KERNEL-串口驱动开发之uart driver框架[/*]
X-018-KERNEL-串口驱动开发之serial console[/*]
X-019-KERNEL-串口驱动开发之数据收发[/*]
X-020-ROOTFS-initramfs的制作和测试[/*]
X-021-ROOTFS-基于busybox的最简rootfs的制作[/*]

可以通过如下步骤在板子上验证： 1）代码下载（具体可参考“X-003-UBOOT-基于Bubblegum-96平台的u-boot移植说明”）


[== Undefined ==]
mkidr -p ~/work/xprj
cd ~/work/xprj
git clone https://github.com/wowotechX/build
git clone https://github.com/wowotechX/u-boot
git clone https://github.com/wowotechX/tools
git clone https://github.com/wowotechX/linux
git clone https://github.com/wowotechX/doc #包含有说明文档

2）代码编译

[== Undefined ==] cd build make env_prepare #下载交叉编译工具，只需要执行一次，之前任务有下载过的，请忽略该步骤 make libusb #只需要执行一次 make dfu #只需要执行一次 make uboot kernel busybox initramfs uImage

3）按住Bubblegum-96的ADFU键，使板子进入DFU模式 4）按住Bubblegum-96的ADFU键不松开，将splboot.bin（就是我们的SPL image）下载到SRAM并执行


[== Undefined ==]
cd ./build
make spl-run #这是一个快捷命令

5）执行完毕后，会重新进入DFU模式，进入后，可以松开ADFU按键。 6）连接好串口，将包含Kernel Image、dtb文件以及initramfs的FIT uImage下载DDR并执行


[== Undefined ==]
cd ./build
make kernel-run #这是一个快捷命令

7）执行成功后，可以在串口控制台上看到u-boot、kernel的启动日志，最终会运行到busybox的命令行中。

找人-负笈追梦-乐视生态企业酷派热聘

Fri, 09 Sep 2016 22:47:39 +0800

本文是原「蜗窝讨论区」的历史存档（2016-09-09），来自版块「内推区」，共 1 帖。讨论区已停止服务，此处仅供查阅。

负笈追梦 · 2016-09-09 22:47

乐视生态企业酷派招聘

工作地点：深圳/南京/西安/上海欢迎推荐

简历发至litao3@yulong.com

学历本科以上，工作经验三年以上，待遇高，招聘人数多，通信，驱动，系统，多媒体，互联网，硬件等模块千人规模招聘中，工资无上限，互联网公司的文化和待遇。尊重技术，尊重人才。群昵称：负笈追梦

X-011-UBOOT-使用bootm命令启动kernel(Bubblegum-96平台)

Fri, 09 Sep 2016 22:18:12 +0800

我们在“ X-010-UBOOT-使用booti命令启动kernel(Bubblegum-96平台) ”中介绍了使用u-boot booti指令加载并运行ARM64 Image格式kernel的方法。与此同时，我们在“ u-boot FIT image介绍 ”介绍了一种新的uImage（u-boot Image）格式—-FIT uImage。本文将基于这两篇文章，介绍FIT uImage的编译

找工作--weiweishuo--linux内核相关

Fri, 09 Sep 2016 16:30:35 +0800

本文是原「蜗窝讨论区」的历史存档（2016-09-09），来自版块「内推区」，共 2 帖。讨论区已停止服务，此处仅供查阅。

karma303 · 2016-09-09 16:30

【博主请不要删帖，才发的QＱ群申请，账号21O65O765O】

你好。我计划12月初出去找工作，linux内核相关的。偏上层一点儿的。驱动往上（包括驱动）都可以，再底层的，用示波器我就不大喜欢。另外加班不要太严重。这是我的os项目：(https://github.com/weiweishuo/papaya)。如果你有意向，可以提前跟我联系: jiejinmv#163.com

（感觉我这语气不大对。。。各位多包容）

wowo · 2016-09-09 16:49

karma303 写道： 【博主请不要删帖，才发的QＱ群申请，账号21O65O765O】

（感觉我这语气不大对。。。各位多包容）

哈哈，这语气……我喜欢，有才的人都有个性 :cool: 我帮你找朋友推荐一下~~~

Fix-Mapped Addresses

Fri, 09 Sep 2016 12:44:03 +0800

某天，wowo同学突然来了一句：如果要在start_kernel中点LED，ioremap在什么时间点才能调用呢？我想他应该是想通过点 LED灯来调试start_kernel之后的初始化的代码（例如DTB解析部分的代码）。那天，我们两个花了二十分钟的时间，讨论相关的问题，我觉得很有意思，因此决定写fix mapped address这样的一份文档。在汇编代码中，由于没有打开MMU，想怎么访问外

找人--更矫情--龙旗内推

Thu, 08 Sep 2016 14:18:45 +0800

本文是原「蜗窝讨论区」的历史存档（2016-09-08），来自版块「内推区」，共 1 帖。讨论区已停止服务，此处仅供查阅。

feison · 2016-09-08 14:18

最近龙旗貌似接了华为的项目，比较缺人，最近两个月一直在热招，下面是招聘岗位，希望有兴趣的小伙伴可以回贴或直接联系我邮箱：feisonlei@gmail.com。图片效果有点差，不过还是勉强看得清楚滴。

请教，测试程序的运行时间都有哪些nice的方法呢~

Wed, 07 Sep 2016 23:03:08 +0800

本文是原「蜗窝讨论区」的历史存档（2016-09-07），来自版块「Linux kernel技术问答」，共 2 帖。讨论区已停止服务，此处仅供查阅。

728330453 · 2016-09-07 23:03

当前由于工作需要，在程序中需要测试每个xxx_init驱动接口函数的初始化时间：

Step1

往往这个时候，想到的是printf 的__TIME__(在源文件中插入当前编译时间)，

然而，大家都知道，printf的话，会严重影响时间的准确性。

Step2

这个时候想到，如果在xxx_init之间插入printf打印时间有影响的话，那就把xxx_init的每个时间点记录在数组中，在初始化完成之后，统一将时间打印出来：

然后有了下面的做法：

以下是一个程序中的打点函数：

define DOT_SIZE 300

typedef struct{ //

unsigned int cnt;
unsigned int recor;

}Dot_rec;

Dot_rec dotrec = {0,{0}};

void trace(unsigned int line,unsigned int rec)

{

dotrec.recor = line;
dotrec.cnt++;
if(DOT_SIZE == dotrec.cnt)
{
dotrec.cnt = 0;

}
dotrec.recor = rec;
dotrec.cnt++;
if(DOT_SIZE == dotrec.cnt)
{
dotrec.cnt = 0;

}

}

define ltrace(a) trace(LINE,(unsigned int)(a));

void printrace(void)

{

int num;
DRV_Printf(“cnt = %d\n”,dotrec.cnt);
for(num= 0; num &lt; DOT_SIZE; num++)
{
DRV_Printf("%d,",dotrec.recor[num]);

num++;

DRV_Printf("%x,",dotrec.recor[num]);

if(num%20 == 19)

{

 DRV_Printf("-%d\n",num);

}

}
DRV_Printf("\n");

}

这个Step2，实际只是想想，并未采用该方法。

Step3

如果是用printf的__TIME__，打印的时间精确到秒级，测量程序执行时间，显然是不够用的。

因此想到，使用clock_gettime(CLOCK_MONOTONIC, &ts);

可以获得足够精确的每个xxx_init程序代码执行时间。

代码如下：

include <time.h>

define DOT_SIZE 600

typedef struct{ //

unsigned int cnt;
unsigned long recor;

}Dot_rec;

Dot_rec dotrec = {0,{0}};

void trace(unsigned int line,time_t tv_sec,long tv_nsec)

{

dotrec.recor = line;
dotrec.cnt++;
if(DOT_SIZE == dotrec.cnt)
{
dotrec.cnt = 0;

}
dotrec.recor = tv_sec;
dotrec.cnt++;
if(DOT_SIZE == dotrec.cnt)
{
dotrec.cnt = 0;

}
dotrec.recor = tv_nsec;
dotrec.cnt++;
if(DOT_SIZE == dotrec.cnt)
{
dotrec.cnt = 0;

}

}

define ltrace(a,b) trace(LINE,(time_t)a,( long b);

void printrace(void)

{

int num;
printf(“cnt = %d\n”,dotrec.cnt);
for(num = 0; num &lt; DOT_SIZE; num++)
{
printf("%d,",dotrec.recor[num]);

num++;

printf("%x,",dotrec.recor[num]);

num++;

printf("%x,",dotrec.recor[num]);

if(num%20 == 19)

{

 printf("-%d\n",num);

}

}
printf("\n");

}

这样的话，就满足了测试实际程序执行时间的要求.

但是引申一下，总觉得还有一些场景 和一些测试方法，自己没有想到！！！

比如在uboot下面，或者在中断中该如何测试代码运行时间？？？

在这里，想请教各位大虾，都用哪些方法测量程序运行时间呢？？？

喔喔对了，可以使用Linux的jffies的时间去测试？没有用过,不知道是否精准~

关于“内推”

Wed, 07 Sep 2016 21:33:59 +0800

本文是原「蜗窝讨论区」的历史存档（2016-09-07），来自版块「内推区」，共 3 帖。讨论区已停止服务，此处仅供查阅。

wowo · 2016-09-07 21:33

QQ群里“更矫情”同学提议：

** 写道：**

感觉群里有很多大神都有内推机会，能不能帮它们把工作机会贴到公告栏里，让群里找工作或者准备找工作的小伙伴能看到，毕竟内推概率大的多啊

故而成立该板块，希望能够把大家的内推机会收集下来，以方便各位小伙伴找人、找工作。有内推机会的小伙伴，可以来这里发帖，帖子标题的格式如下：


[== Undefined ==]
[事项]--[群昵称]--[描述]
事项，有两个可选：找人；找工作。
群昵称，请填写蜗窝QQ群昵称。如果不填，或者不正确，可能被删帖。
描述，随便写了。

希望大家用心维护该板块，不以功利为目的，互帮互助，互相成长。

feison · 2016-09-08 10:04

赞！！！！！！！

青春年少 · 2017-01-12 18:37

大大的赞?

【博客投稿】一个走野路子的fork( )

Wed, 07 Sep 2016 11:16:09 +0800

本文是原「蜗窝讨论区」的历史存档（2016-09-07），来自版块「Linux kernel技术问答」，共 4 帖。讨论区已停止服务，此处仅供查阅。

karma303 · 2016-09-07 11:16

再过两三个月，就准备出去找工作了。因为是第一次找内核相关的工作，心里有些没谱，希望到时候能听听wowo的建议。我准备以后往这里投一些文章，这样博主能对我的水平有一个了解。当然，也不全是自私的目的～我很欣赏这个博客，希望能给它添砖加瓦。只不过有时候写文章不爱发出来。这是第一篇。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝正文的分割线＝＝＝＝＝＝＝＝＝＝＝＝

写在前面：我对linux的研究远不及各位深入，但因为我一直在写自己的os(名字叫papaya)，有时看问题的角度会不同，加之papaya的设计意图就是linux的简化版，所以分享出来一些心得。所谓他山之石，可以攻玉，希望能帮助各位更好的理解linux，当然，也欢迎大家批评指正。另外，因为是突然想到给wowo投稿，手上没有现成的文章，所以就从papaya的src/document/log里面找出来一篇日志:ebp-when-when-fork-kernel_thread.txt，是前几天调试完fork(函数里的一个bug后写的。

=================================================

这两天在调试fork(的代码，不断的修改，逐渐发现fork(是很有意思的：我以前只知道它能镜像一个用户进程，原来它也可以镜像一个内核线程。

乍眼看上去，fork一个内核线程的工作量要小得多。因为不用考虑用户空间，通共不到8K的堆栈，吃住都在这里。

下面是papaya sys_fork(里的一段代码(有删改)，用来处理"镜像线程“返回的路线。 ================================================================= int pcb2pcb = (unsigned)(p) - (u32)(current); //两个task_struct的距离 stack_frame float_regs = (void )((unsigned) &regs + pcb2pcb); //float_regs->ebp += pcb2pcb;

p-&gt;thread.esp = (unsigned)float_regs;
p-&gt;thread.eip = (u32)ret_from_sys_call;
float_regs-&gt;eax = 123;
return 12345;
=================================================================)

首先，镜像线程和原线程重新投入运行（也就是从这次系统调用出去）的方式是不同的。原线程很简单，直接从这次sys_fork( return，然后pop刚才int 0x80时候压栈的寄存器现场，再iret就好了。镜像线程需要等一会儿。它投入运行的方式是”被调度“，被挑中之后，走的是schedule里的__switch(路线。所以处理它的返回路线，就是在task->thread里做文章。其实就是伪造一个“进程切换上下文”，因为从原线程复制过来的thread成员没有意义(you should know why..)。 papaya把thread->esp变量被设置成float_regs，即"浮动regs"。看float_regs的命名和赋值，能发现它不是传统的8K堆栈底部的那个struct pt_regs, 而是刚才int 0x80时候，所“就地压栈”的“cpu寄存器现场”。内核线程当然该这么做，它被硬中断时，就是“就地”做寄存器压栈的。它不像用户进程那样，有硬件的堆栈切换，总能自动定位到8K堆栈的最底部。

所以最底部那个struct pt_regs对内核线程是没有意义的，只有一种内核线程需要它，就是那种通过create_process(创建的(而非fork( 第一个进程。即使那样，也只是在创建后启动时用一次，以后就用不到了，不仅用不到，而且会覆盖掉。（因为启动之后，esp就在8K堆栈的最低部了，然后往上生长。。。）

【第二部分】 fork出来的内核线程，其实是不太稳定的。无法保证它绝对不崩溃。为什么呢？看下面一个例子： ================================================================= void func0(void){ int x; asm volatile(".intel_syntax prefix\n\t" "int 0x80\n\t" ".att_syntax prefix\n\t" :"=a"(x) :"a"(1) ; while(1){ oprintf("%u ", x); schedule_timeout(1000); }

=================================================================)

基本上这也是我测试时用的代码。 func0是一个内核线程。它通过int 0x80创建一个镜像线程。我期望的是在它俩在屏幕上竞相打印12345 和123．但屏幕上只输出123。通过gdb能断出来到两个线程确实都在运行。很明显，func0的堆栈里的x变量被修改了。看原因。下面是这段代码的反汇编： ================================================================= ... int $0x80 mov %eax, -0xc(%ebp) sub $0x8(%esp) pushl -0xc(%ebp) push $0xc001e263 call 0xc001c21c<oprintf> ... =================================================================) 问题出在ebp上。因为fork时float_regs也是完全拷贝过去的，所以新线程在被调度后，也就是，从float_regs resume后，ebp也就指向了原进程的堆栈。解决方式是在sys_fork(里加上一句代码： float_regs->ebp += pcb2pcb; 在这个例子中，这句代码能奏效。但是不严密。因为还有esi,ebx这样的寄存器，你不确定它们存储的是一个地址，还是一个常规的数值。没办法也做调整。

【第三部分】但是"fork内核线程"仍然是有用的。因为我们通常不会傻乎乎的fork一个线程，让它镜像的运行下去，而是会让它立刻执行某个函数。看linux的kernel_thread(函数，它就是通过fork实现的。 ================================================================= / * Create a kernel thread / int kernel_thread(int (fn)(void ), void * arg, unsigned long flags) { long retval, d0;

 __asm__ __volatile__(
 "movl %%esp,%%esi\n\t"
 "int $0x80\n\t" /* Linux/i386 system call */
 "cmpl %%esp,%%esi\n\t" /* child or parent? */
 "je 1f\n\t" /* parent - jump */
 /* Load the argument into eax, and push it. That way, it does
 * not matter whether the called function is compiled with
 * -mregparm or not. */
 "movl %4,%%eax\n\t"
 "pushl %%eax\n\t" 
 "call *%5\n\t" /* call fn */
 "movl %3,%0\n\t" /* exit */
 "int $0x80\n"
 "1:\t"
 :"=&amp;a" (retval), "=&amp;S" (d0)
 :"0" (__NR_clone), "i" (__NR_exit),
 "r" (arg), "r" (fn),
 "b" (flags | CLONE_VM)
 : "memory");
 return retval;
}
=================================================================)

它在int 0x80调用sys_fork之后，立刻又调用了fn。这样ebp等寄存器就会被这个新的函数刷新。这很像是一个进程vfork之后，立刻调用execve(，跟旧的生命告别。

【第四部分】这篇文章的主要部分讲完了。在最后，我想专门对比一下papaya在fork的设计上，跟linux的一个差异: 为子进程安排返回线路的差异。

返回线路肯定都是通过task->thread。区别在于设置task->thread->esp。

papaya是把esp设置的跟原进程的相对位置一样: int pcb2pcb = (unsigned)(p) - (u32)(current); stack_frame float_regs = (void )((unsigned) &regs + pcb2pcb); p->thread.esp = (unsigned)float_regs;

linux就比较激进了，它是让esp指向8K堆栈的底部的pt_regs: childregs = ((struct pt_regs ) (2PAGE_SIZE + (unsigned long) p)) - 1;

你可能会问，内核堆栈底部的pt_regs不是被覆盖了，怎么还让从那儿返回？所以linux紧接着是这样做的： childregs = regs; 不要小瞧了这句代码，对ring3进程来说，这个拷贝是镜像的，但是对ring0线程来说，这个拷贝通常是这样： linux这样做，其实就是临时搭建起来一个底部的pt_regs。新线程照从这里resume，是可以回到int 0x80的下一条指令的，但接下来是无法照旧路走下去的¹，因为原线程之前的堆栈，它没有。但papaya就可以，虽然不那么保险。

我觉得linux这么做，是为了提高fork的速度,因为不需要复制上图中routine stack那一片区域。

PS: linux的arch/alpha目录下的kernel/process.c里的copy_thread的行为有点儿像papaya:

=================================================================
stack_offset = PAGE_SIZE - sizeof(struct pt_regs);
if (!(regs-&gt;ps &amp; 8))
 stack_offset = (PAGE_SIZE-1) &amp; (unsigned long) regs;
childregs = (struct pt_regs *) (stack_offset + PAGE_SIZE + (long)p);
*childregs = *regs;
=================================================================)

-------------Fri Sep 2 11:17:38 CST 2016---------

【注释】 ⁰ 以上的linux源码基于linux2.4 。 ¹ linux也没打算让它继续走旧路。

最后最后，我似乎要解释一下题目。我想说的是papaya的fork(的路子比较野，如果把linux看做正规军的话。

u-boot FIT image介绍

Fri, 02 Sep 2016 21:49:08 +0800

Linux kernel在ARM架构中引入device tree（全称是flattened device tree，后续将会以FDT代称）的时候 [1] ，其实怀揣了一个Unify Kernel的梦想—-同一个Image，可以支持多个不同的平台。随着新的ARM64架构将FDT列为必选项，并将和体系结构有关的代码剥离之后，这个梦想已经接近实现：在编译linux kernel的时候，不必特意的指

Linux内存模型

Wed, 31 Aug 2016 12:01:30 +0800

在linux内核中支持3中内存模型，分别是flat memory model，Discontiguous memory model和sparse memory model。所谓memory model，其实就是从cpu的角度看，其物理内存的分布情况，在linux kernel中，使用什么的方式来管理这些物理内存。另外，需要说明的是：本文主要focus在share memory的系统，也就是说所有的

如何调试驱动开发过程中的Oops ？

Tue, 30 Aug 2016 11:17:11 +0800

本文是原「蜗窝讨论区」的历史存档（2016-08-30），来自版块「Linux kernel技术问答」，共 12 帖。讨论区已停止服务，此处仅供查阅。

peter · 2016-08-30 11:17

驱动开发中经常遇到Oops问题，主要有如下两类情况: 1. Unable to handle kernel paging request at virtual address xxxxxxxx (非法内存访问) 2. Unable to handle kernel NULL pointer dereference at virtual address xxxxxxxx (空指针)

Oops可以看成是内核级的Segmentation Fault。应用程序如果进行了非法内存访问或执行了非法指令，会得到Segfault信号，一般的行为是coredump，应用程序也可以自己截获Segfault信号，自行处理。如果内核自己犯了这样的错误，则会打出Oops信息。

依据自己的经验也就知道如下两种调试方法: 1. objdump反编译(转: http://www.cnblogs.com/wwang/archive/2010/11/14/1876735.html) 2. printk的方法来调试Oops问题

曾经在面试的时候，有被问过如何调试Oops，也就回答了上述两种，但是面试官就问是否分析过堆栈内容，当时就蒙了，调试驱动从来没去分析过这部分．一般只看寄存器状态和函数调用栈.

调试的驱动不多，所以接触到的东西有限，还请大家看看是否有更好的方法来调试Oops，期待分享.

qdzhaozx · 2016-08-30 14:47

函数调用栈，不是反映了堆栈内容吗？

wowo · 2016-08-30 18:26

如果自己可以修改kernel，其实是可以把KALLSYMS打开，这样OOPS之后，连反汇编都不需要，直接可以打出C函数的栈回梭。

[== Undefined ==] config KALLSYMS bool "Load all symbols for debugging/ksymoops" if EXPERT default y help Say Y here to let the kernel print out symbolic crash information and symbolic stack backtraces. This increases the size of the kernel somewhat, as all symbols have to be loaded into the kernel image. config KALLSYMS_ALL bool "Include all symbols in kallsyms" depends on DEBUG_KERNEL && KALLSYMS help Normally kallsyms only contains the symbols of functions for nicer OOPS messages and backtraces (i.e., symbols from the text and inittext sections). This is sufficient for most cases. And only in very rare cases (e.g., when a debugger is used) all symbols are required (e.g., names of variables from the data sections, etc). This option makes sure that all symbols are loaded into the kernel image (i.e., symbols from all sections) in cost of increased kernel size (depending on the kernel configuration, it may be 300KiB or something like this). Say N unless you really need all symbols.

DRAM 原理 4 ：DRAM Timing

Mon, 29 Aug 2016 22:42:16 +0800

在 DRAM Device 章节中，我们简单介绍了 SDRAM 的 Active、Read、Write 等的操作，在本中，我们将详细的介绍各个操作的时序。

在linux3.10内核中i2c_register_adapter的adap->bus_recovery_info是如何设置呢？

Fri, 26 Aug 2016 21:58:05 +0800

本文是原「蜗窝讨论区」的历史存档（2016-08-26），来自版块「Linux kernel技术问答」，共 5 帖。讨论区已停止服务，此处仅供查阅。

728330453 · 2016-08-26 21:58

RT 在内核中，看到有这么一个恢复的动作，但是如何去设置并在i2c模块注册过程中，先发9个脉冲恢复总线不清楚！！！

对了，忘记补充问题的背景了。

【问题背景】在当前使用的单板中，有概率性的单板启动失败，反复复位。重新上下电后回复。

【问题原因】打开内核的DEBUG_ll, 发现是在内核的i2c总线在操作pca9555过程中超时，也就是总线由于莫名原因SDA被拉低，i2c控制器判断总线状态为Busy，从而超时，导致单板复位。我想，am3352的i2c1总线外挂了四片pca9555,所以这种问题的概率就大些了。

【定位过程】硬件工程师将i2c1于pca9555之间线路断开，pca侧 sda线一直是拉低，而i2c控制器侧恢复高电平。从而推断: 在操作i2c总线过程中，pca9555回复ack，拉低sda，而此时正巧单板复位，scl时钟信号无效。sda会被pca9555，一直拉低。因此造成了总线的异常状态。

【解决方案】具体链接： http://www.voidcn.com/blog/yuyin86/article/p-4745473.html 6、无应答信号（NACK）

在时钟的第9个脉冲期间发送器释放数据总线，接收器不拉低数据总线表示一个 NACK，NACK有两种用途：a、一般表示接收器未成功接收数据字节；b、当接收器是主控器时，它收到最后一个字节后，应发送一个NACK信号，以通知被控发送器结束数据发送，并释放总线，以便主控接收器发送一个停止信号STOP。

【解决方案代码合入】为了合理，有效并优雅的解决问题，需要对i2c驱动架构有一定了解，所以在梳理驱动过程中发现，在i2c_register_adapter的adap->bus_recovery_info 做了总线恢复的相关动作。

因此设置下应该就OK了，明天自己验证下~

728330453 · 2016-08-26 22:03

内核本身，好像配置下就OK了，明天再单板上验证下就OK了。

Linux内核做的真心不错呀~ 理解驱动的代码很重要

wowo · 2016-08-27 17:27

728330453 写道： 内核本身，好像配置下就OK了，明天再单板上验证下就OK了。

Linux内核做的真心不错呀~ 理解驱动的代码很重要

:cool: cool

728330453 · 2016-08-28 07:01

具体关于i2c总线的自恢复功能配置，参见Linux4.7.2版本，顺便说一句我这里用的是ti的芯片，所以对比i2c-omap.c和i2c-core.c就可以啦~ / * Waiting on Bus Busy / static int omap_i2c_wait_for_bb(struct omap_i2c_dev *omap) { unsigned long timeout;

timeout = jiffies + OMAP_I2C_TIMEOUT;
while (omap_i2c_read_reg(omap, OMAP_I2C_STAT_REG) &amp; OMAP_I2C_STAT_BB) {
 if (time_after(jiffies, timeout))
 return i2c_recover_bus(&amp;omap-&gt;adapter);
 msleep(1);
}
return 0;

}

不过仍然还有疑惑的地方 1、/* timeout waiting for the controller to respond */ #define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000)) 驱动中i2c的超时间设置为1s, 看门狗的复位时间也就1.6s--->以为这个值蛮危险的！！！且i2c总线上挂载了外设，总线忙时，也会存在超时时间！这样的话 i2c总线被从机挂死的话，内核启动就会失败！

关于这个时间是如何得来的呢？后面需要看看，是否需要根据实际i2c的读写情况，重新设置超时时间！！！

eMMC框架及其初始化

Thu, 25 Aug 2016 16:33:54 +0800

eMMC 的全称是Embedded MultiMedia Card，MMC协会所制定的内嵌式存储器标准规格，主要应用于智能手机和移动嵌入式产品。eMMC是一种嵌入式非易失性存储系统，由标准MMC接口、主控制器和NAND Flash三部分组成，采用JEDEC标准BGA封装。 eMMC的这种将Nand Flash芯片和控制芯片封装在一起的设计概念，就是为了简化产品内存储器的使用，客户只需要采购eMMC

X-010-UBOOT-使用booti命令启动kernel(Bubblegum-96平台)

Wed, 24 Aug 2016 22:34:47 +0800

“ X-009-KERNEL-Linux kernel的移植(Bubblegum-96平台) ”中介绍了ARM64平台下，配置、编译、生成Linux kernel Image文件的方法。Image文件生成后，我们可以借助DFU工具将它下载到板子的DRAM中，然后借助u-boot boot有关的命令，加载并运行之（这个过程也称作引导）。针对不同的Kernel image格式，u-boot提供了不同

文件缓存回写简述

Wed, 24 Aug 2016 09:51:16 +0800

1 文件缓存回写的时机 (1) 周期性回写，周期为 dirty_writeback_interval ，默认 5s ； (2) 块设备首次出现脏数据； (3) 脏页达到限额，包括 dirty_bytes 、 dirty_background_bytes 、 dirty_ratio 、 dirty_background_ratio ； ……

问个关于ARM中System Counter的问题

Mon, 22 Aug 2016 23:43:18 +0800

本文是原「蜗窝讨论区」的历史存档（2016-08-22），来自版块「Linux kernel技术问答」，共 7 帖。讨论区已停止服务，此处仅供查阅。

metro · 2016-08-22 23:43

首先感谢网站，能够分享这么好的文章，让我学到了很多，谢谢。

最近我跟着相关文章的内容，自己在NanoPi M3（SoC为S5P6818，八核A53）上移植64位的U-boot。目前U-boot已经基本可用，但是遇到了一个问题：系统需要个定时器来记录时间，并且提供相应api以进行一些时间相关的功能，最终通过设备树的方式传递给Linux。通过查阅各种资料，我得到了以下信息： 1. 对系统定时器的初始化操作一般都在U-boot前期完成，包括System Counter的enable，基本是在lowlevel_init函数中完成，在进入C环境之前系统定时器可用。 2. 由于使用的是A53的SoC，所以参考了ARMv8和A53的技术手册的Generic Timers部分，但是看着看着就觉得有些奇怪。ARMv8中将Generic Timers分成了System Counter和Timers两部分，并且分别提供了Memory-mapped I/O和寄存器访问（AArch64 Mode）两种方式，其实在之前网站上的文章中也交待清楚了（Linux时间子系统之（十七）：ARM generic timer驱动代码分析），这倒没什么问题。但是，Cortex-A53的manuals则表示CPU中不存在System Counter部分（This resides in SoC），并且只提及了两个接口，即CNTCLKEN和CNTVALUEB，而没有提到通过bus访问的其他接口，而CNTCLKEN和CNTVALUEB在ARMv8的技术文档中完全没有提及。我做过测试，CNTVALUEB的值和AArch64中cntpct_el0寄存器的值一模一样，说明这确实是一个用作System Counter的接口。那么问题来了，我查阅了SoC的datasheet，发现关于System Counter的部分确实只提供了CNTCLKEN和CNTVALUEB的接口，坑爹的是并没有详细说明这部分接口是否连到了SoC Timers部分，datasheet中提到的timers都是32位down-counter的，与System Counter的要求不符，感觉并不是用作System Counter的timers。（顺便吐槽下，这个SoC的datasheet写得挺糟糕，IP核似乎是来自几个平台拼凑而成的，相关资料都不大好找，虽然基本最后都能找得到，除了这个。） 3. 看了半天文档也没什么结果，于是我去翻了翻网上移植好的U-boot和Linux。不过蛋疼的是网上找到的都是32位的代码，移植的版本也比较早（14年），说白了就是把S5P4418（一个系列的前代产品，使用四核A9）的代码直接移植过来使用的。可能是ARMv7时代对于Generic Timers没有统一的规范，这些代码都是自己编写的timers驱动，没有用到后面抽象好的架构，而是使用一个SoC的定时器作为tick使用，看着实在是头大。。问过板子的技术支持，得到的答复是暂时没有提供64位的文档，噗。。。不死心的我又看了几个同为A53的SoC的U-boot代码，但是却发现基本分成两种情况：要么压根没有初始化System Counter（可能在更早的时候就完成了初始化？），要么确实初始化了System Counter（典型的如freescale），但是访问了Memory-mapped I/O的接口（也就是CNTCR寄存器），而这个接口（当然也包括一个系列的其他接口）并没有出现在A53的技术文档和S5P6818的datasheet中。我猜测，System Counter的接口访问部分可能不是强制要求实现的，所以才会导致不一致的问题。

对于这个问题，我想到了以下几个解决方案： 1. 最好的方法当然是使用ARMv8和A53提供好的架构，但是在参考文档不大完善且有些矛盾的情况下似乎不大好搞。现在看来，要么等待官方更新64位部分的文档，要么就是自己使用定时器中断的方式更新CNTVALUEB寄存器来模拟，而前者遥遥无期，后者将要花费不少的系统资源来处理中断（DMA显然不适合，timer的类型都不一样），而且不符合power-down时的要求，更麻烦的是需要修改U-boot的exception vectors（U-boot默认将IRQ和FIQ中断引导到panic，不像ARMv7时可以自己处理异常），感觉不是一个合适的方法。 2. 参考旧的U-boot和linux代码，将其中一个普通定时器用作System Ticks，这样做的缺点也显而易见，那就是不符合ARMv8的规范，相关的驱动都要自己重新实现，这个只能说是下下之策。 3. 抛弃timer机制，使用一些其他函数替代system ticks的功能，但是只能在U-boot上凑合用用（U-boot基本上只在delay的时候用到），Linux上显然行不通。

目前卡在这个问题上，不知道各位对此有什么见解吗？谢谢！

wowo · 2016-08-23 09:18

System counter是ARM体系结构规定的，不是具体的CPU规定的，怎么会没有呢？你可以参考“DDI0487A_d_armv8_arm.pdf”，查看里面有关CNTFRQ_EL0的定义。另外，在u-boot中，要使用system counter是非常容易的： 1）在配置头文件中，定义system counter的时钟频率


[== Undefined ==]
COUNTER_FREQUENCY

2）arch/arm/cpu/armv8/start.S中会根据时钟频率，配置CNTFRQ_EL0


[== Undefined ==]
#ifdef COUNTER_FREQUENCY 
 ldr x0, =COUNTER_FREQUENCY 
 msr cntfrq_el0, x0 /* Initialize CNTFRQ */ 
#endif

3）arch/arm/cpu/armv8/generic_timer.c中有关的API就可以使用了

X-009-KERNEL-Linux kernel的移植(Bubblegum-96平台)

Fri, 19 Aug 2016 22:38:39 +0800

本文将以“ X Project ”的“ 【任务3】Linux kernel的配置、编译、加载与启动 ”为契机，介绍将Linux kernel移植到一个新的平台上的基本步骤，包括kernel以及device tree的配置、编译、二进制文件的生成等。注1：本文的硬件基于ARM64架构，kernel基于“ X Project ”初始的“ Linux 4.6-rc5 ”版本

U-boot中无法开启Cortex-A9的NEON功能

Thu, 18 Aug 2016 20:56:33 +0800

本文是原「蜗窝讨论区」的历史存档（2016-08-18），来自版块「Linux kernel技术问答」，共 3 帖。讨论区已停止服务，此处仅供查阅。

活出自我 · 2016-08-18 20:56

SOC平台：ARMV7-a架构,cortex-A9,含有NEON功能，且在ARM编译器下测试通过编译器：gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux.tar 编译参数：PLATFORM_CPPFLAGS += -mcpu=cortex-a9 -mfpu=neon 问题：在移植uboot时，无法使用float等浮点运算。

代码：


[== C++ ==]
float num1 = 3.14;
 float num2 = 0.0;
 float num3 = 0.0;
 num2 = num1 * 2.0;

 num3 = num1 + num1;

printf(&quot;\n&quot;);
printf(&quot;INFO:test neon float:\n&quot;);
printf(&quot;INFO:num1=%f\n&quot;, num1);
printf(&quot;INFO:multi func:num1 * 2.0 = %f\n&quot;, num2);
printf(&quot;INFO:plusfunc:num1+num1=%f\n&quot;, num3);

反汇编：


[== C++ ==]
 num2 = num1 * 2.0;
 num3 = num1 + num1;
printf(&quot;\n&quot;);
 ad0: e59f0148 ldr r0, ; c20 &lt;board_init_f+0x194&gt;
 ad4: eb001da6 bl 8174 &lt;printf&gt;
printf(&quot;INFO:test neon float:\n&quot;);
 ad8: e59f0144 ldr r0, ; c24 &lt;board_init_f+0x198&gt;
 adc: eb001da4 bl 8174 &lt;printf&gt;
 printf(&quot;INFO:num1=%f\n&quot;, num1);
 ae0: e3a02206 mov r2, #1610612736 ; 0x60000000
 ae4: e59f313c ldr r3, ; c28 &lt;board_init_f+0x19c&gt;
 ae8: e59f013c ldr r0, ; c2c &lt;board_init_f+0x1a0&gt;
 aec: eb001da0 bl 8174 &lt;printf&gt;
printf(&quot;INFO:multi func:num1 * 2.0 = %f\n&quot;, num2);
 af0: e3a02206 mov r2, #1610612736 ; 0x60000000
 af4: e59f3134 ldr r3, ; c30 &lt;board_init_f+0x1a4&gt;
 af8: e59f0134 ldr r0, ; c34 &lt;board_init_f+0x1a8&gt;
 afc: eb001d9c bl 8174 &lt;printf&gt;
printf(&quot;INFO:plusfunc:num1+num1=%f\n&quot;, num3);
 b00: e59f3128 ldr r3, ; c30 &lt;board_init_f+0x1a4&gt;
 b04: e3a02206 mov r2, #1610612736 ; 0x60000000
 b08: e59f0128 ldr r0, ; c38 &lt;board_init_f+0x1ac&gt;
 b0c: eb001d98 bl 8174 &lt;printf&gt;

实际打印效果:


[== C++ ==]
INFO:test neon float:
INFO:num1=%f
INFO:multi func:num1 * 2.0 = %f
INFO:plusfunc:num1+num1=%f

Linux kernel内核配置解析(5)_Boot options(基于ARM64架构)

Fri, 12 Aug 2016 22:46:06 +0800

本文将介绍ARM64架构下，Linux kernel和启动有关的配置项。注1：本系列文章使用的Linux kernel版本是“ X Project ”所用的“ Linux 4.6-rc5 ”，具体可参考“ https://github.com/wowotechX/linux.git ”。

ARM64架构下地址翻译相关的宏定义

Fri, 12 Aug 2016 18:50:53 +0800

本文主要分析linux-4.4.6/arch/arm64/include/asm目录下的若干和地址翻译相关的头文件（例如page.h、 pgtable.h、pgtable-hwdef.h、pgtable-prot.h等文件）中的各种宏定义以及相关的ARM64硬件知识。硬肯ARM ARM文档有时候太费劲，结合linux源代码会让学习变得简单一些。

Linux kernel内核配置解析(1)_概述(基于ARM64架构)

Wed, 10 Aug 2016 23:20:08 +0800

对刚接触Linux kernel的同学来说，遇到的第一个问题就是：我该从哪里入手？、话说Linux kernel的打开方式是多种多样的：从简单的设备驱动入手；从源代码的目录结构入手；从kernel的启动过程入手；从大的功能模块入手；等等。不管怎样，每条都是正途（条条大路通罗马嘛）。而本文（以及随后的系列文章），将从Linux kernel的配置项入手，从整体上认识Linux kernel。之所

好想蜗窝可以出书

Tue, 09 Aug 2016 21:04:57 +0800

本文是原「蜗窝讨论区」的历史存档（2016-08-09），来自版块「灌水区」，共 9 帖。讨论区已停止服务，此处仅供查阅。

ues123 · 2016-08-09 21:04

一直断断续续在看，遇到问题后，就会到这儿来找找资料。

希望蜗窝可以整理一下，出本书哇。觉得需要买一本书，好好研究。

wowo · 2016-08-10 08:59

ues123 写道： 一直断断续续在看，遇到问题后，就会到这儿来找找资料。

希望蜗窝可以整理一下，出本书哇。觉得需要买一本书，好好研究。

感谢热心支持。出书的事情，由于现在网站上的文章还不是很全，因此想再过一段时间再整理。比如x project基本完成之后。不过那时候你可能已经用不着了（因为已经变成大牛了，哈哈~~）

sklli · 2016-08-30 09:08

强烈渴望

wowo · 2016-08-30 18:27

sklli 写道： 强烈渴望

多谢关注，我们尽量~~

蓝色火焰 · 2016-09-12 10:20

支持。

firephoenix · 2016-11-15 17:13

期待，不知道wowo用的是什么开发板

wowo · 2016-11-16 11:07

firephoenix 写道： 期待，不知道wowo用的是什么开发板

你是指我们的x project吗？可以看看这里面的帖子：/forum/

peter · 2017-01-06 17:21

强烈期待

coderall · 2018-08-05 14:04

这个可以有！

请问一下关于中断发生内核堆栈切换的问题。

Mon, 08 Aug 2016 23:58:46 +0800

本文是原「蜗窝讨论区」的历史存档（2016-08-08），来自版块「Linux kernel技术问答」，共 6 帖。讨论区已停止服务，此处仅供查阅。

alone-wyr · 2016-08-08 23:58

对于X86架构来说，发生中断，可以进行切换，每个进程都有它的TSS（忘记了）大概就是会有地方去初始化SP，就是设置了内核堆栈。

但是对于ARM架构来说，中断发生，硬件上并没有这个初始化sp_irq(或者说是sp_svc）这个动作。在看了下中断发生的相关代码，也没有看到哪里有赋值的动作。

如果是在内核启动期间，设置好了sp_svc寄存器的值，给每个进程共用。那就是内核堆栈的虚拟地址都是相同的？进程切换会刷新页表，然后都会通过映射指向自己的内核堆栈... 那如果真的这样..应该还要保证进入和退出中断时候，sp_svc应该不要改变的？

是我疏忽了哪个地方？或者说是哪里理解错误。望博主指点一二。谢过~~

linuxer · 2016-08-09 16:21

这个问题在/irq_subsystem/irq_handler.html中有描述，你可以看看。

简单的说： 1、内核初始化的时候设置了sp_irq的值，也就是设定了irq mode下的stack，只有12个字节，所有的中断共用这个中断栈 2、中断栈只是一个跳板，最终要切换到发生中断那个点的current thread的内核栈上，也就是设定sp_svc

alone-wyr · 2016-08-09 20:42

谢谢你的回复。

确实sp_irq只是作为一个过渡，只保存几个寄存器，然后就会切换到了svc模式下了..也就切换为使用sp_svc. 我比较困惑的是，在x86，发生中断会通过每个进程的tss相应字段来设置sp0(内核堆栈).那就是说，在创建进程的时候，设置了tss内相应字段为分配thread_info的页帧地址上。这样在发生中断，其实就设置好了sp0了。

但是对于ARM来说，它并没有类似TSS这样会在发生中断的时候设置sp_irq或者是sp_svc.. 因此，我只能假设，所有进程发生中断的时候都是使用相同的sp_irq和sp_svc的值（虚拟地址.）.（映射到各个进程对应的物理地址）但是要是这样的话，就需要保证中断进入和退出的时候，不应该改变过sp_irq和sp_svc的值。

你的文章里面有写到函数cpu_init会设置idle任务的sp_irq sp_svc 等...

假设有这样的情况，CPU初始化sp_irp = a。进程A在执行时候发生中断，然后一些堆栈操作改变了sp_irp = b. 退出中断，接着切换到进程B执行。。进程B执行过程发生中断，它的sp_irq就是等于b了。。这样就有问题了。因为我才假设，每个进程的虚拟地址a都是作为sp_irq的堆栈..然后进程发生中断后，到退出中断。都应该保证说sp_irq=a..

x86不同的是，发生中断硬件上会设置sp0.因此没有这些条条框框。

不知道，你是否明白我描述的疑问。

谢谢。

linuxer · 2016-08-10 09:48

发生了中断，最重要的是保存现场，在中断处理完之后，能够恢复现场就OK了，硬件现场（hardware context）的保存是由硬件和软件共同完成的。

对于ARM，当发生中断的那一刻，硬件会进行如下的动作： 1、将发生中断那一刻的CPSR保存在SPSR寄存器中 2、将返回地址保存在lr寄存器中（注意：这个lr寄存器是IRQ mode的lr寄存器，可以表示为lr_irq）

真正将hardware context保存到内核栈上是软件的行为。当然，目标是一开始就设定好了，将发生中断那一刻的hardware context保存到current task的内核栈上。不同的CPU有不同的设计，提供不同的软件和硬件的接口，对于X86，硬件帮忙做的事情更多，而ARM更希望你自己能够自力更生（更简单的HW logic意味着更少的晶体管，更少的功耗，而这也是ARM在移动平台上能够横扫Intel的根本原因）。怎么办？hardware context包括了cpu中的各种寄存器，想要将hardware context压入内核栈首先要获取current thread的内核栈指针，任何对cpu寄存器的使用将破坏硬件上下文，因此，linux kernel采用的方法是借用12个字节的中断栈。方法如下： 1、在中断栈上保存了发生中断那一点的r0值、PC值以及CPSR值。你可能会觉得：PC和CPSR需要保存吗？不是硬件已经帮忙保存lr_irq（虽然不是PC值，但是和PC值有固定的偏移关系）和spsr_irq中了吗？之所以保存spsr_irq和lr_irq的值，那是因为随后在切换到svc mode的时候需要修改spsr_irq和lr_irq的值。之所以保存r0，是因为后续会修改r0的值，把它做为一个scratch register。 2、切换到svc mode，具体完成下面两个步骤：（A）将处理器模式切换到svc mode （B）根据发生中断那一点的处理器模式，将pc设定为__irq_usr或者__irq_svc 在上面的过程中，lr_irq，spsr_irq和r0被破坏了，但是没有关系，相关信息已经保存在了中断栈上了（sp_irq） 3、一旦切换到SVC mode，ARM处理器看到的寄存器已经发生变化，这里的sp已经变成了sp_svc了。问题来了：sp_svc是什么值？在进程切换的时候就已经设定好了，sp_svc被设定为current thread的内核栈。这时候，除了被破坏的三个寄存器保存在中断栈上，其他的寄存器毫发无伤，软件只要将这些hardware context压入current thread的内核栈上即可。

回答你提出的具体问题：－－－－－－－－－－－－－－－－假设有这样的情况，CPU初始化sp_irp = a。进程A在执行时候发生中断，然后一些堆栈操作改变了sp_irp = b. 退出中断，接着切换到进程B执行。。进程B执行过程发生中断，它的sp_irq就是等于b了。。这样就有问题了。因为我才假设，每个进程的虚拟地址a都是作为sp_irq的堆栈..然后进程发生中断后，到退出中断。都应该保证说sp_irq=a.. －－－－－－－－－－－－－－－－ sp_irp的值永远不会修改的，它只是个暂存数据的地方，就象临时变量，每次发生中断，临时用一下而已

[bubblegum96 问题解决] 笔记本thinkpad t440p+ubuntu16.04 环境下无法通过DFU下载SPL并点亮LED

Sun, 07 Aug 2016 21:43:44 +0800

本文是原「蜗窝讨论区」的历史存档（2016-08-07），来自版块「X Project」，共 7 帖。讨论区已停止服务，此处仅供查阅。

wowo · 2016-08-07 21:43

X project开发的过程中，calm.xia同学发现一个问题，描述如下（可参考“/forum/”）：

calm.xia 写道： 现在板子（bubblegum 96）的LED灯是点亮了，但是有点问题，大概整理如下: 1. 结果: LED灯亮环境: 台式机+win10+vmware10+ubuntu12.04 工具: x_project代码仓库的build目录和tools目录，并make libusb 和 make dfu image: tools/actions/spluboot.bin download: 插入usb线，按住ADFU键，插入电源，build目录下执行 sudo ../tools/dfu/dfu bubblegum 0xe406b200 ../tools/actions/spluboot.bin 1

结果: LED灯不亮环境: 笔记本thinkpad t440p+ubuntu16.04和ubuntu14.04 工具: 同上 image: 同上 download: 同上

由于笔记本安装ubuntu12.04出了点问题没有安装成功，所以这种情况没结果。现在的问题是: 不同环境下，LED灯出现点亮和无法点亮的问题，而且不同环境下download时的log都是一样的！！

由于问题比较有意思，现单独开一个帖子，debug该问题，具体的debug步骤可参考本帖后面的回复。

wowo · 2016-08-07 21:45

首先，自己搭建环境，重现该问题。最终可以稳定重现，我的环境为：一个破笔记本电脑+ubuntu16.04

wowo · 2016-08-07 21:52

其次，筛选怀疑对象，首先想到的是，USB传输出问题了。先检查能够工作时，不能工作时DFU下载的日志，竟然一模一样，如下：

[== Undefined ==] sudo ../tools/dfu/dfu bubblegum 0xe406b200 ../tools/actions/splboot.bin 1 password for pengo: board bubblegum address 0xe406b200 filename ../tools/actions/splboot.bin need_run 1 bDescriptorType: 1 bNumConfigurations: 1 iManufacturer: 0 bNumInterfaces: 1 Info: cannot detach kernel driver: LIBUSB_ERROR_NOT_FOUND (no worry) Configuiration: 1 Handler: 0x9a91160 CBW: 55 53 42 43 00 00 00 00 83 43 00 00 00 00 10 05 00 b2 06 e4 83 43 00 00 00 00 00 00 00 00 00 Bulk transferred 17283 bytes CSW:55534253000000000000000000 CBW: 55 53 42 43 00 00 00 00 00 00 00 00 00 00 00 10 00 b2 06 e4 00 00 00 00 00 00 00 00 00 00 00 Transffered: 31 CSW:55534253000000000000000000

还不死心，日志一样，会不会传输过程中出问题了呢？参考这份文件：(https://wiki.ubuntu.com/Kernel/Debugging/USB) 使用USBMON，抓取USB传输的数据包，再次确认，发现还是一模一样，如下：

[== Undefined ==] vim@vim-pc:~$ cat bus2data_ok.txt ffff8800357c23c0 3921553956 S Co:2:014:0 s 00 09 0001 0000 0000 0 ffff8800357c23c0 3921554387 C Co:2:014:0 0 0 ffff8800357c23c0 3921555490 S Bo:2:014:1 -115 31 = 55534243 00000000 b31b0000 00001005 00b206e4 b31b0000 00000000 000000 ffff8800357c23c0 3921555631 C Bo:2:014:1 0 31 > ffff880035511780 3922556019 S Bo:2:014:1 -115 4096 = 0a000014 1f2003d5 00000011 00000000 b81b0000 00000000 00500000 00000000 ffff880035511780 3922556244 C Bo:2:014:1 0 4096 > ffff8800b4cb8900 3923556726 S Bo:2:014:1 -115 2995 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ffff8800b4cb8900 3923556976 C Bo:2:014:1 0 2995 > ffff880034679840 3924557531 S Bi:2:014:2 -115 1024 < ffff880034679840 3924557712 C Bi:2:014:2 0 13 = 55534253 00000000 00000000 00 ffff8800bc20b900 3925558226 S Bo:2:014:1 -115 31 = 55534243 00000000 00000000 00000010 00b206e4 00000000 00000000 000000 ffff8800bc20b900 3925558308 C Bo:2:014:1 0 31 > ffff88003543e540 3925558402 S Bi:2:014:2 -115 1024 < ffff88003543e540 3925558563 C Bi:2:014:2 0 13 = 55534253 00000000 00000000 00 vim@vim-pc:~$ cat bus2data_fail.txt ffff8800357c2cc0 3962482159 S Co:2:015:0 s 00 09 0001 0000 0000 0 ffff8800357c2cc0 3962482337 C Co:2:015:0 0 0 ffff8800357c2cc0 3962482973 S Bo:2:015:1 -115 31 = 55534243 00000000 b31b0000 00001005 00b206e4 b31b0000 00000000 000000 ffff8800357c2cc0 3962483083 C Bo:2:015:1 0 31 > ffff8800b4cb8540 3963483515 S Bo:2:015:1 -115 4096 = 0a000014 1f2003d5 00000011 00000000 b81b0000 00000000 00500000 00000000 ffff8800b4cb8540 3963483702 C Bo:2:015:1 0 4096 > ffff8800b4cb80c0 3964484296 S Bo:2:015:1 -115 2995 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ffff8800b4cb80c0 3964484440 C Bo:2:015:1 0 2995 > ffff8800bd600d80 3965484700 S Bi:2:015:2 -115 1024 < ffff8800bd600d80 3965484797 C Bi:2:015:2 0 13 = 55534253 00000000 00000000 00 ffff8800bd6003c0 3966485241 S Bo:2:015:1 -115 31 = 55534243 00000000 00000000 00000010 00b206e4 00000000 00000000 000000 ffff8800bd6003c0 3966485288 C Bo:2:015:1 0 31 > ffff8800b4cb6480 3966485484 S Bi:2:015:2 -115 1024 < ffff8800b4cb6480 3966485659 C Bi:2:015:2 0 13 = 55534253 00000000 00000000 00

PS：可以根据上面链接中的解释，并结合抓包数据，理解DFU所使用的协议。

看来传输是对了，再想其它办法吧……

[tiny210 uboot移植]移植进度

Sat, 06 Aug 2016 15:19:29 +0800

本文是原「蜗窝讨论区」的历史存档（2016-08-06），来自版块「X Project」，共 5 帖。讨论区已停止服务，此处仅供查阅。

ooonebook · 2016-08-06 15:19

本次移植基于project-x使用的uboot来进行移植。

感谢wowo以及各位大神的指导。发这个移植进度是觉得希望能有更多有tiny210的板子的同学能一起参与进来，一个人搞的进度确实巨慢。一起努力让tiny210的移植代码也合入到project-x的主分支中。

有tiny210板子的同学，我们一起搞起来吧。

网上已经有很多tiny210移植uboot的资料了。关于kangear已经完成tiny210的uboot的移植，可以参考http://arm9home.net/read.php?tid-80476.html

我的移植进度。

7月23日以前。前期做一些准备工作，包括搭ubuntu环境，弄板子，下project-x的代码，找一些相关资料。git库操作的学习。尝试在ubuntu环境下编译过project-x的代码。第一次添加tiny210 board支持失败，在wowo的指导下发现关于tiny210的一些CPU配置搞错了，应该是armv7并且可以使用machine s5pv1xx. 进展：环境和代码都已经搞定，板子也已经到位。后续任务：继续尝试添加tiny210 board并且编译成功。（7.23-7.27完成）

7.23-7.27——需要整理文档第二次添加tiny210 board支持，使用arm-linux-gcc4.5编译器，逐步解决编译问题（有一部分修改内容是参考kangear的代码）。上传到自己的git hub分支上。注意：目前的修改有一些纯粹就是为了解决编译错误，不管代码的内容，后续移植过程中需要对这些内容进行fix。进展：初步添加到tiny210 board支持到project-x的项目上，并且编译成功。创建了一个tiny210的分支专门用于维护tiny210的代码。后续任务： 1、测试板子，安装好各种驱动，用kangear的uboot测试能否正常启动。熟悉一下sdcard启动uboot的步骤。（7.30完成） 2、搞清楚s5pv210的启动流程，BL0-BL1(uboot-spl)-BL2(uboot)。（7.29完成） 3、uboot-spl的流程，需要结合代码

7.29——需要整理文档根据文档和资料搞清楚了s5pv210的启动流程，简单结合文档看了一下arrmv7的uboot-spl的流程。 http://blog.csdn.net/linuxarmsummary/article/details/44836293 http://www.cnblogs.com/zhangpengshou/p/3617800.html 注意：上述网站代码和project-x中armv7的代码有差异，需要结合代码自己整理一遍流程，思考一下uboot-spl“点LED灯”的代码应该加在什么位置。进展：大致整明白了armv7-uboot-spl的流程。（armv7的uboot-spl使用位置无关代码的方式）后续任务： 1、结合project-x的代码来分析uboot-spl的流程。 2、让自己编译的uboot-spl也可以正常在tiny210中跑起来，通过点亮LED来观察是否跑起来了。（7.30完成）

7.30 测试tiny210板子，安装好各种驱动，编译了kangear的uboot，在tiny210的板子上测试kangear的uboot正常启动。熟悉一下sdcard启动uboot的步骤。进展： 1、kangear的uboot可以正常在tiny210中启动，后续在在tiny210上移植uboot，可以参考kangear的uboot来进行。 2、成功的让project-x项目的uboot-spl在tiny210中跑起来了，很残暴的在_main中直接去点亮LED测试了一下。后续任务： 1、在正常的board.c中去点亮LED。（8.3完成） 2、实现串口输出log。（放在uboot的时候去实现）

7.31 因为该版本uboot上已经添加了s5pv210的gpio的一些配置的API，在s5p_gpio.c。但是要编译通过这个函数需要使能FIT的部分，也就是要打开device_tree的功能。所以就先简单移植tiny210的device tree. 进展： 1、移植device tree成功。

8.3 uboot-spl太小，无法编译进s5pc110原来的gpio.o。所以无法使用标准的gpio_cfg_pin来点亮LED。只能直接操作GPIO的寄存器来实现。进展：在board.c中点亮LED。完善通过LED实现的tiny210_early_debug操作。后续：因为在spl中实现串口输出意义不大。先移植DRAM的代码。 1、研究kangear中DRAM的初始化和BL2的img的copy过程。 2、实现DRAM的初始化 3、实现BL2的img的copy过程几个重点关注问题（0）可以先尝试把kangear关于ddr的部分先移植过去再说。（8.6完成）（1）BL1中DRAM初始化的过程 _start——》reset——》cpu_init_crit——》lowlevel_init——》实现一些底层的初始化，包括DDR的初始化。（8.4完成）（2）BL1中copy BL2到DRAM的流程（3）如何验证是否初始化成功？是否copy成功？初始化完DDR之后尝试往DDR写入一个值，然后再读出来，如果读出来的值和写入的值一样，就说明初始化成功。（8.6完成）

8.6 直接移植kangear的ddr初始化代码成功。进展：移植kangear的ddr代码到project-x项目中，使用直接写一个DDR地址之后再从这个地址里面读出来，发现值是对的。所以DDR的初始化应该是成功的。

8.7-8.10——需要整理文档（已整理）进展：研究了s5pv210的DDR硬件结构，地址映射方法，初始化流程以及一些参数的设置根据原理图、datasheet和代码整理了文档《tiny210 ddr文档》。

8.11——需要整理文档（已整理）进展：参考kangear的代码实现了BL1中copy BL2到DRAM的流程。并且用kangear可以正常使用的uboot测试了一下。弄清楚了整个copy的流程和原理。并整理了文档《从SDCARD加载到dram中》。后续： 1、研究uboot的编译过程和运行过程（可以从Makefile入手）（8.12完成）。 2、使用自己编译通过的uboot，可以成功在DRAM上面跑起来（8.11完成）。通过在_start点亮三个灯并用b xys_loop死循环之后，可以判断uboot.bin已经开始执行了。

8.12——需要整理文档进展：1、大致搞清楚了uboot的启动和uboot-spl的启动的差异。弄明白了global data的原理、地址和使用等等。 uboot和uboot-spl的堆栈的设置。 2、定位到serial_init导致程序uboot不断重启，屏蔽掉之后就没事了疑问：uboot-spl中把sp设置错了（也就是堆栈设置错了），但是C函数还是可以正常调用。原因：因为编译器对于C函数的汇编进行了优化，没有使用push和pop指令，所以不需要使用到堆栈。后续：1、解决掉serial_init导致重启的问题（8.15完成） 2、使串口正常使用（8.15完成）

8.15 进展：1、解决开机过程中不断重启问题。两个原因导致，1、dts节点中serial的配置问题 2、CONFIG_OF_TRANSLATE使能之后导致的DTS解析错误的问题。 2、串口已经可以正常打印log了。后续：1、研究一下s5pv210的串口驱动代码。 2、继续完善一些初始化的东西，包括dram_init等等（08.18完成） 3、启动到命令行的位置（08.18完成）

8.18——需要整理文档进展：1、学习了下relocation过程uboot大小的计算（bss_end-_start）学习了下relocation的过程 2、使能DEBUG来打印debug(函数的log 3、对dram_init的补充 4、屏蔽掉一些函数之后uboot正常启动到了命令行模式。屏蔽了nand_init(; initr_nand, initr_mmc,initr_env, 后续：1、文档的整理《relocation》、《board_init_f》、《board_init_r》等等 2、对上述屏蔽掉的函数进行补充和修正（08.20完成）。

8.20 进展：1、修正屏蔽了nand_init(; initr_nand, initr_mmc,initr_env的问题 2、看project-x中移植kernel的方法，学习研究中。 3、查找了一下后续在tiny210中移植kernel的文档，以便后面学习参考。后续：1、针对tiny210添加一个配置，使其能够编译通过。

目前任务：针对tiny210添加一个配置，使其能够编译通过。目前问题：目前的一些想法：因为uboot做得比较简陋，nand flash还不支持，可以直接在SD卡中刷入kernel。另外，可以直接使用一个没有压缩的kernel，暂时不考虑参数的问题，直接将其拷贝到RAM上，然后直接跳转过去进行点灯。先保证kernel可以正常跑入。

希望有tiny210的板子的同学一起参与进来啊。

【任务3】Linux kernel的配置、编译、加载与启动

Fri, 05 Aug 2016 22:21:00 +0800

本文是原「蜗窝讨论区」的历史存档（2016-08-05），来自版块「X Project」，共 16 帖。讨论区已停止服务，此处仅供查阅。

wowo · 2016-08-05 22:21

任务说明通过“【任务2】启动到u-boot command line”，已经成功初始化了板子的DRAM，并将u-boot加载到DRAM中运行至命令行。基于此，我们可以展开第三个任务：加载并启动Linux kernel（可以以点亮一个LED 灯作为任务的验收标准）。完成该任务的基本步骤包括：
配置并编译一个最简单的Linux kernel，使其可以在具体的板子上执行。编译成功后，将生成uImage和对应的dtb文件。[/*]
为了便于验证，可以在linux kernel运行的第一时间，点亮一个LED灯，以标识任务的完成[/*]
根据板子的实际情况，通过dfu，将uImage和dtb文件，分别下载到DRAM的指定位置[/*]
根据板子的实际情况，使用指定的参数，通过u-boot的bootm命令，执行linux kernel[/*]
涉及的知识点该任务主要涉及如下知识点：
Linux kernel的启动流程（和具体的平台有关，我们会先以ARM64为例）[/*]
Linux kernel的配置（只需要掌握并理解最基本的即可）[/*]
Linux kernel最简单的移植（包括物理地址、虚拟地址等概念，device tree移植等）[/*]
Linux kernel的编译，以及uImage的生成[/*]
u-boot中boot linux kernel的要求、流程以及操作步骤[/*]
完成任务的思路该任务可以拆分为几个独立的部分：
Linux kernel启动流程中和平台相关部分的分析，针对不同的平台，可以写一系列的文章。我们已经完成了ARM64的分析，具体可参考博客中“ARM64的启动过程”系列文章[/*]
linux kernel的配置解析，这是观察linux kernel的另外一个视角。可以以具体的平台为单位，写一系列的分析文章[/*]
linux kernel平台相关部分的移植说明，根据实际的硬件情况，写一篇文章即可[/*]
linux kernel device tree的移植说明，结合博客上device tree的分析文章，从实践的角度，加深对device的理解[/*]
u-boot boot linux kernel的流程及步骤说明[/*]

另外，由于该任务涉及到u-boot和linux kernel的权利交接，任何一方出现问题，任务都无法完成。因此，遇到问题时的debug思路和手段，显得尤为重要，到时我们会尽量详细的记录和总结。

最后，还是老话，感兴趣的同学可以认领任务 4. 任务总结到目前为止（2016/09/10），该任务在bubblegum 96boards上基本完成，共有如下的文档产出：

X-009-KERNEL-Linux kernel的移植(Bubblegum-96平台)[/*]
X-010-UBOOT-使用booti命令启动kernel(Bubblegum-96平台)[/*]
(/u-boot/fit_image_overview.html)[/*]
X-011-UBOOT-使用bootm命令启动kernel(Bubblegum-96平台)[/*]

可以通过如下步骤在板子上验证： 1）代码下载（具体可参考“X-003-UBOOT-基于Bubblegum-96平台的u-boot移植说明”）


[== Undefined ==]
mkidr -p ~/work/xprj
cd ~/work/xprj
git clone https://github.com/wowotechX/build
git clone https://github.com/wowotechX/u-boot
git clone https://github.com/wowotechX/tools
git clone https://github.com/wowotechX/linux
git clone https://github.com/wowotechX/doc #包含有说明文档

2）代码编译


[== Undefined ==]
cd build
make env_prepare #下载交叉编译工具，只需要执行一次，之前任务有下载过的，请忽略该步骤
make libusb #只需要执行一次
make dfu #只需要执行一次
make uboot kernel uImage

3）按住Bubblegum-96的ADFU键，使板子进入DFU模式

4）按住Bubblegum-96的ADFU键不松开，将splboot.bin（就是我们的SPL image）下载到SRAM并执行


[== Undefined ==]
sudo ../tools/dfu/dfu bubblegum 0xe406b200 ../tools/actions/splboot.bin 1

5）执行完毕后，会重新进入DFU模式，进入后，可以松开ADFU按键。

6）将包含Kernel Image和dtb文件的FIT uImage下载DDR中（不执行）


[== Undefined ==]
sudo ../tools/dfu/dfu bubblegum 0x6400000 ./out/xprj_uImage.itb 0

7）将u-boot下载到DDR并执行


[== Undefined ==]
sudo ../tools/dfu/dfu bubblegum 0x11000000 out/u-boot/u-boot-dtb.bin 1

8）使用串口连接开发板，进入命令行后，以FIT uImage在memory中的位置为参数，执行bootm命令


[== Undefined ==]
bootm 0x6400000

即可成功启动linux kernel。

注：github上的kernel仓库，没有点亮LED的代码，如果需要确定kernel是否启动成功，请按照X-010-UBOOT-使用booti命令启动kernel(Bubblegum-96平台)中的相关说明，修改kernel的source code。

关于request_irq第一个参数irq number的问题

Fri, 05 Aug 2016 17:19:26 +0800

本文是原「蜗窝讨论区」的历史存档（2016-08-05），来自版块「Linux kernel技术问答」，共 2 帖。讨论区已停止服务，此处仅供查阅。

上海-云 · 2016-08-05 17:19

大家好，这里我有一个关于中断号的问题，描述如下： 1. 我们知道linux因为要支持多个中断控制器引入了irq domain的概念，所以irq number ≠ HW interrupt ID 2. 在一个典型的驱动程序中，基本套路是使用irq number = platform_get_irq(,来获取中断号，当内核支持设备树时，这个irq number是映射过的。 platform_get_irq(->of_irq_get(->irq_create_of_mapping(.

我的问题是，有一个"non-standard"的驱动程序，没有使用platform设备模型， 1. HW interrupt ID 已知，静态定义在程序中 2. 因为不能使用platform_get_irq(来获取映射后的中断，要使用request_irq(注册中断之前，如何申请一个映射的irq number?

linuxer · 2016-08-05 19:32

看来你不是不打算使用device tree了，呵呵～～～我能想到两个方案： 1、使用静态定义的mapping，也就是在系统初始化的时候就确定irq domain中指定的HW interrupt ID（你静态定义在程序的那个）和irq number的对应关系，这样，你的驱动程序不需要省钱irq number，直接使用就OK了。换句话说：其实你不必静态定义HW interrupt ID，你需要静态定义该驱动的IRQ number。

2、在驱动程序中调用irq子系统的接口来完成（1）申请一个free的irq number （2）建立该irq domain上指定HW interrupt ID（你静态定义在程序的那个）和你驱动程序申请的那个irq number的对应关系。

hello world,HelloBirthday

Sat, 30 Jul 2016 15:27:11 +0800

本文是原「蜗窝讨论区」的历史存档（2016-07-30），来自版块「灌水区」，共 3 帖。讨论区已停止服务，此处仅供查阅。

HelloBirthday · 2016-07-30 15:27

今天来到这里，也是在搜索资料时看到了蜗窝的相关帖子。蜗窝,I like!

才入职一家公司，主要负责android底层驱动这块。本人也是才毕业，没什么经验，来到公司也没人带，说实话很迷茫。除了看代码还是看代码，device tree,pinctl也看不懂，linux3.10架构更改太大，和大学学习时(友善4412)差别太大。现在的平台太多的新机制，新框架需要去学习。公司老大让什么都学，从LCD、触摸屏、音频、蓝牙、wifi、usb、4G...什么都看，什么都没看懂。有几个问题，想问问大神，有没有好的建议： 1.驱动部分产品要用的都看了(老大一直催，公司没人做驱动)，只是简单的了解流程，公司将我的定位我觉得应该也是在技术支持上，产品开发时，解决bug之类的，大部分也是交给方案公司了。那么我需要多了解哪方面呢？比如说wifi驱动，如果只是单纯的调试，关注点在哪里？如果为了更长远的学习、发展，关注点又在哪里？ 2.公司用的RK平台，本来打算从最简单的LED开始，就难了一天。接下来打算控制下WDT，直接蒙了，按照以前的思路找中断，一直没找到。最后看到了蜗窝的帖子，才算是大概明白。我的想法就是：首先熟悉这款开发板(RK3288的)，但是现在不知道从哪下手啊?裸机的话，这款开发板也没有dnw和tftp等功能，烧写也是个问题。 3.说实话，本人比较愚钝，学习方法不对，所以才浪费了大量时间。现在最迷茫的就是：我是应该继续看代码，还是敲代码(控制各个外设)？看，又看到什么程度？

请各路大神指导，在此感谢，谢谢！

wowo · 2016-07-31 17:55

您的问题和这个类似：/forum/ 我们能说的也就这么多了。关键是多做事情，会变的更好的。

HelloBirthday · 2016-08-01 08:54

是啊多做，多想

为什么这个DTS不好用呢

Thu, 28 Jul 2016 13:51:49 +0800

本文是原「蜗窝讨论区」的历史存档（2016-07-28），来自版块「Linux kernel技术问答」，共 6 帖。讨论区已停止服务，此处仅供查阅。

Kerry · 2016-07-28 13:51

这个定义是好用的，

** 写道：**

/ { model = "××××××××××××"; compatible = "××××××××××××××××"; #address-cells = <1>; #size-cells = <1>;

pll2: pll2 {
 #clock-cells = &lt;0&gt;;
 compatible = "fixed-clock";
 clock-frequency = &lt;800000000&gt;;
};
sdclk0: sdclk1 {
compatible = “fixed-factor-clock”;
#clock-cells = &lt;0&gt;;
clock-div = &lt;1&gt;;
clock-mult = &lt;1&gt;;
clocks = &lt;&amp;pll2&gt;;
clock-output-names = “ahbs”;
};
gate_sd1: gate_sd1 {
compatible = “xacti,ev9x-gates-sd-clk”;
#clock-cells = &lt;0&gt;;
reg = &lt;0x300A3010 0x4&gt;;
div_reg = &lt;0x30000A34&gt;;
clocks = &lt;&amp;pll2&gt;;
};
gate_sd0: gate_sd0 {
compatible = “xacti,ev9x-gates-sd-clk”;
#clock-cells = &lt;0&gt;;
reg = &lt;0x300A3000 0x4&gt;;
div_reg = &lt;0x30000A30&gt;;
clocks = &lt;&amp;pll2&gt;;
};

gate_sd2: gate_sd2 { compatible = "xacti,ev9x-gates-sd-clk"; #clock-cells = <0>; reg = <0x300A3040 0x4>; div_reg = <0x30000A38>; clocks = <&pll2>; };

sdhci: sdhci@21A10000 {
 compatible = "inrevium,te4395-sdhci";
 reg = &lt;0x21A10000 0x1000&gt;;
 int_mod = &lt;0x300A30F0 0x0020&gt;;
 int_stt = &lt;0x300A30F4 0x0020&gt;;
 clocks = &lt;&amp;gate_sd1&gt;;
 interrupt-parent = &lt;&amp;vic0&gt;;
 interrupts = &lt;21&gt;;
};

这个定义是不好用的，

** 写道：**

/ { model = "××××××××××××"; compatible = "××××××××××××××××"; #address-cells = <1>; #size-cells = <1>;

pll2: pll2 {
 #clock-cells = &lt;0&gt;;
 compatible = "fixed-clock";
 clock-frequency = &lt;800000000&gt;;
};
sdclk0: sdclk1 {
compatible = “fixed-factor-clock”;
#clock-cells = &lt;0&gt;;
clock-div = &lt;1&gt;;
clock-mult = &lt;1&gt;;
clocks = &lt;&amp;pll2&gt;;
clock-output-names = “ahbs”;
};
gate_sd0: gate_sd0 {
compatible = “xacti,ev9x-gates-sd-clk”;
#clock-cells = &lt;0&gt;;
reg = &lt;0x300A3000 0x4&gt;;
div_reg = &lt;0x30000A30&gt;;
clocks = &lt;&amp;pll2&gt;;
};
gate_sd1: gate_sd1 {
compatible = “xacti,ev9x-gates-sd-clk”;
#clock-cells = &lt;0&gt;;
reg = &lt;0x300A3010 0x4&gt;;
div_reg = &lt;0x30000A34&gt;;
clocks = &lt;&amp;pll2&gt;;
};

gate_sd2: gate_sd2 { compatible = "xacti,ev9x-gates-sd-clk"; #clock-cells = <0>; reg = <0x300A3040 0x4>; div_reg = <0x30000A38>; clocks = <&pll2>; };

sdhci: sdhci@21A10000 {
 compatible = "inrevium,te4395-sdhci";
 reg = &lt;0x21A10000 0x1000&gt;;
 int_mod = &lt;0x300A30F0 0x0020&gt;;
 int_stt = &lt;0x300A30F4 0x0020&gt;;
 clocks = &lt;&amp;gate_sd1&gt;;
 interrupt-parent = &lt;&amp;vic0&gt;;
 interrupts = &lt;21&gt;;
};

我的sdhci用的是gate_sd1时钟，在这里把gate_sd1写在前面就好用，是为什么呢，在代码里会调用devm_clk_get获取时钟

** 写道：**

pltfm_host-&gt;clk = devm_clk_get(&amp;pdev-&gt;dev, NULL);
if (IS_ERR(pltfm_host-&gt;clk)) {
 ret = PTR_ERR(pltfm_host-&gt;clk);
 pr_info("devm_clk_get( failed, return %d, got clk:%p\n", ret, pltfm_host-&gt;clk);
 goto err;
}

错误时的输出：

** 写道：**

devm_clk_get( failed, return -517, got clk:fffffdfb

是不是很奇怪

DRAM 原理 3 ：DRAM Device

Wed, 27 Jul 2016 22:12:11 +0800

在前面的文章中，介绍了 DRAM Cell 和 Memory Array。本文则以 SDR SDRAM 为例，描述 DRAM Device 与 Host 端的接口，以及其内部的其他模块，包括 Control Logic、IO、Row & Column Decoder 等。

X-008-UBOOT-支持命令行(Bubblegum-96平台)

Wed, 27 Jul 2016 21:41:16 +0800

经过前面文章的铺垫，u-boot command line的支持已经成了一个顺理成章的事情了。因此，本文没有太多技术细节，仅仅记录支持命令行的实现过程，权当“ X Project ” “ 【任务2】启动到u-boot command line ”的一个完结。

arm体系下的cpu_relax()函数疑惑--再讨论

Wed, 27 Jul 2016 10:41:22 +0800

本文是原「蜗窝讨论区」的历史存档（2016-07-27），来自版块「Linux kernel技术问答」，共 3 帖。讨论区已停止服务，此处仅供查阅。

tigger · 2016-07-27 10:41

hi linux 在之前的帖子中，最后一段对yeild的描述如下而嵌入式汇编中的yield指令则完成了cpu_relax的第二个功能，即让CPU 松弛下来，降低功耗，把资源配置给其他thread等 yield是不会让出cpu的，并没有调用schedule相关的函数，是忙等待。这里能把资源配置给其他thread吗？？我想你的意思应该是其他core上面的thread？另外附上ARMV8对YIELD指令的解释 The YIELD instruction The YIELD instruction provides a hint that the task performed by a thread is of low importance so that it could yield, see YIELD on page C6-768. This mechanism can be used to improve overall performance in an Symmetric Multi-Threading (SMT) or Symmetric Multi-Processing (SMP) system. Examples of when the YIELD instruction might be used include a thread that is sitting in a spin-lock, or where the arbitration priority of the snoop but in an SMP system is modified. The YIELD instruction permits binary compatibility between SMT and SMP systems. The YIELD instruction is a NOP (No Operation) hint instruction. The YIELD instruction has no effect in a single-threaded system, but developers of such systems can use the instruction to flag its intended use for future migration to a multiprocessor or multithreading system. Operating systems can use YIELD in places where a yield hint is wanted, knowing that it is treated as a NOP if there is no implementation benefit.

X-007-UBOOT-DDR的初始化(Bubblegum-96平台)

Thu, 21 Jul 2016 22:47:48 +0800

到目前为止，“ X Project ”在Bubblegum-96平台上的代码，都是运行在SRAM中。由于SRAM的size很小（最多也就96KB），如果要做更多的事情，就必须把DDR跑起来。不过，关于Bubblegum-96平台的DDR driver，我和 codingbelief 同学折腾了很久，试图找出一个最佳的方法，给大家呈现出DDR driver的开发方法和开发步骤。最终，受限于“资源”的

say hi to admin and myself

Sun, 10 Jul 2016 23:16:43 +0800

本文是原「蜗窝讨论区」的历史存档（2016-07-10），来自版块「灌水区」，共 2 帖。讨论区已停止服务，此处仅供查阅。

jackal · 2016-07-10 23:16

Good to be here.

linuxer · 2016-07-27 16:48

;) Welcome

X-006-UBOOT-pinctrl driver移植(Bubblegum-96平台)

Sat, 09 Jul 2016 21:47:14 +0800

wowo觉得，在linux kernel新引入的众多子系统中，pinctrl subsystem是一个特别晦涩难懂的子系统，它所解决的问题，和它所引入的困扰，不相上下。在平时工作的过程中，年轻工程师问的最多的，就是在驱动中要怎么使用pinctrl？这样配置pinctrl到底是什么意思？等等。对一个子系统来说，如果不能让它的使用者（consumer）很容易的理解和掌握，就宣告了它的失败。更不用说让

ARM 的 resource 管理，请赐教

Fri, 08 Jul 2016 15:58:11 +0800

本文是原「蜗窝讨论区」的历史存档（2016-07-08），来自版块「Linux kernel技术问答」，共 11 帖。讨论区已停止服务，此处仅供查阅。

Yoking Wang · 2016-07-08 15:58

谁对 resouce管理比较清楚，请赐教！有相关的文章也欢迎分享！

resource 在哪里定义，特别是引入 Device Tree 以后， resource的定义是否由Device Tree定义。
resource 是怎么管理的？根据设备管理（申请设备的时候访问该设备的resource）还是board（芯片自带）管理？

qdzhaozx · 2016-07-08 16:27

;)

qdzhaozx · 2016-07-08 16:31

Q: First, source的定义在哪？ A: include/linux/ioport.h / * Resources are tree-like, allowing * nesting etc.. / struct resource { resource_size_t start; resource_size_t end; const char name; unsigned long flags; struct resource parent, sibling, child; }; Q:Second，resource的种类主要有哪些？ A: / * IO resources have these defined flags. /

define IORESOURCE_BITS 0x000000ff / Bus-specific bits /

define IORESOURCE_TYPE_BITS 0x00001f00 / Resource type /

define IORESOURCE_IO 0x00000100 / PCI/ISA I/O ports /

define IORESOURCE_MEM 0x00000200 //................................................frequently, 访问设备就是访问那片mem

define IORESOURCE_REG 0x00000300 / Register offsets /

define IORESOURCE_IRQ 0x00000400//.................................................so do it,peripheral用的难免需要个中断

define IORESOURCE_DMA 0x00000800

define IORESOURCE_BUS 0x00001000

蓝牙协议分析(7)_BLE连接有关的技术分析

Fri, 01 Jul 2016 17:17:41 +0800

了解蓝牙的人都知道，在经典蓝牙中，保持连接（Connection）是一个相当消耗资源（power和带宽）的过程。特别是当没有数据传输的时候，所消耗的资源完全被浪费了。因而，对很多蓝牙设备来说（特别是功耗敏感的设备），希望在无数可传的时候，能够断开连接。但是，由于跳频（hopping）以及物理通道（Physical Channel）划分的缘故，经典蓝牙连接建立的速度实在难以忍受（要好几秒）。对那些突

X-005-UBOOT-device tree移植(Bubblegum-96平台)

Wed, 29 Jun 2016 22:14:31 +0800

我们在“ X-004-UBOOT-串口驱动移植(Bubblegum-96平台) ”中，简单介绍了u-boot中serial driver的移植过程。由于serial driver是u-boot移植中的第一个driver，为了方便debug，并没有引入device tree。在serial driver ready之后，基本的console功能已经okay，基于此，我们可以着手增加device tr

Hello, 大家好，我是Johnson，哈哈哈哈

Mon, 27 Jun 2016 19:57:29 +0800

本文是原「蜗窝讨论区」的历史存档（2016-06-27），来自版块「灌水区」，共 3 帖。讨论区已停止服务，此处仅供查阅。

johnson · 2016-06-27 19:57

希望在此向各位前辈多多学习和交流。

wowo · 2016-06-28 11:36

欢迎

只是为了好玩 · 2017-08-29 11:32

欢迎

网卡的tx_queue

Sat, 25 Jun 2016 11:38:03 +0800

本文是原「蜗窝讨论区」的历史存档（2016-06-25），来自版块「Linux kernel技术问答」，共 2 帖。讨论区已停止服务，此处仅供查阅。

karma303 · 2016-06-25 11:38

我最近在写自己的内核，对linux源代码读的不深。感觉一些我自己的设计，有些闭门造车了，所以贴出来，请大家评评。

今天设计的是RTL8139网卡的tx_queue。我让每个网卡都有一个tx_queue和rx_queue。其中tx_queue是被发包中断“驱动”的,当一个skbuff入队的时候，如果发现队列是空的，那就顺便的主动的启动tx_queue。如果发现队列不为空，那就把skbuff插进tx_queue里，然后放心的返回。因为这个队列必然在等待一个或多个发包中断。它还是被“驱动”着的。我上面所说的“驱动”，大家能“领会”吗？就像IDE磁盘的IO类型的（非DMA)驱动代码一样，发出一个READ或WRITE的命令之后，以后对request队列的操作都是靠硬盘中断来唤醒维持的。不知道linux是怎么样的，我觉得如果tx_queue非空，就只管把你要发送的skbuff提交到queue里，这样很合适。如果此时尝试wake它，就很丑，因为它必然在等待发包中断，而发包中断的bottom half里当然会netif_wake_queue(。代码还没有测试，等在机器上通过了，再贴出来大家看看。

Codingbelief · 2016-06-25 21:27

会不会有这样一个临界状态：skbuff 入队时判断 tx_queue 非空，但是 skbuff 入队完成前的一瞬间，tx_queue 刚好又变成了空的状态，睡了下去。在这种情况下，如果 skbuff 入队操作没有和 tx_queue 没有做同步，也没有在入队完成后主动唤醒 tx_queue 的话，可能就异常了，tx_queue 永远不会被唤醒。添加同步和主动唤醒两种方法都可以避免上面的问题出现，就看哪一个成本更低了~

串口通信技术浅析

Fri, 24 Jun 2016 22:50:11 +0800

最熟悉的陌生人！用这句话形容“串口”是再贴切不过的了。对嵌入式工程师来说，“串口”是一个再熟悉不过的模块，熟悉到像喝水一样自然。与此同时，有关串口的很多细节，却被渐渐地模糊和忽略，例如：我们经常挂在嘴边的serial、UART、RS232等概念，究竟是怎么回事？它们之间有何联系？有何区别？串口的波特率（baud rate）是怎么定义和计算的？比特率（bit rate）又是怎么回事？二者的关系

bitfield与endian

Fri, 24 Jun 2016 19:20:17 +0800

本文是原「蜗窝讨论区」的历史存档（2016-06-24），来自版块「Linux kernel技术问答」，共 4 帖。讨论区已停止服务，此处仅供查阅。

karma303 · 2016-06-24 19:20

看到这个博客觉得很好，把自己日常的笔记也贴出来，希望大家多多指教。（希望没违反版规）今天鼓捣的是bitfield的endian特性，纠结了一天，还好有所领悟。

网上开始关注bitfield的endian特性，似乎都是从linux源代码的一个细节开始的。

struct iphdr {

if defined(__LITTLE_ENDIAN_BITFIELD)

__u8 ihl:4,
 version:4;

elif defined (__BIG_ENDIAN_BITFIELD)

__u8 version:4,
 ihl:4;

else

error "Please fix <asm/byteorder.h>"

....

} 一些朋友看到这段代码，再品味一下"__BIG_ENDIAN_BITFIELD"这个宏，就会有种被颠覆三观的感觉。因为在我们心目中，只有byte order之说，没有bit order之说。 CPU是否有bit order的区别，其实很好验证。（我感觉这一段写的不好，大家可以直接ctrl-F跳到【第二段】阅读) x86的bit order是little endian的，(这样说也许不对，但很多人就是这么认为的，包括我),例如下面一个情景：内存中有如下两个字节的内存单元, 其中0x7c00处存放的是1，0x7c01处存放的是2 。

<<<[0x7c01]<<<< growth of memory address <<<[0x7c00]<<<<< 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1

上图就是一个典型的intel风格的内存模型，RAM地址从右往左变大，每个字节内的bit也是从右向左“变高”。这两个字节，(unsigned shor)0x7c00，在intel CPU眼中是0x0201,在MIPS眼中，是0x0102。对吧？其实这已经说明问题了，如果MIPS是有bit order的，那它读出来的，应该是0x8040 。我们前面说要做实验，我们编译下面的C文件: ---- file m.c--- int abc = 0x0102

对，这个文件就一句话，我们把它交叉编译成MIPS机器下的目标文件: $ mips-linux-gnu-gcc -c -o m.o m.c 如果MIPS的bit order是big endian的话，那gcc编译器为了保证到时候MIPS读出来的abc是0x0102,它肯定会为abc创建这样的内存布局： <<<[0x7c01]<<<< growth of memory address <<<[0x7c00]<<<<< 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 因此，我们在x86下看到的abc的值就该是0x4080 。我们看一下: wws@localhost:~/lab/test$ objdump -s m.o|grep data -A1 Contents of section .data: 0000 00000102 00000000 00000000 00000000 ................

并不是0x4080，而是0x0201，表明MIPS使用的是跟x86一样的bit order。好像说了半天废话。。。。。

【第二段】既然没有所谓的bit order，那怎么还会那样子呢？（你还记得是哪样子吗）事情是这样的，大多数人在阅读linux源码的时候，特别是习惯了inte体系结构的读者，脑子中只有一种内存模型，就是我刚才画的0x7c00-->0x7c01的模型。如果有一个整数在MIPS眼中是0xabcdef00，在我们心中，它在内存里就长成这样子： <<<< growth of memory address <<<<< 00 ef cd ab

如果有这么一个MIPS上的结构体: -------------m.c--------------- struct abcdef { char ab; int d: 4; int c: 4; char ef; char oo; }abcdefoo = { ab: 0xab, d: 0xd, c: 0xc, ef: 0xef, oo: 0};

我们会认为这个结构体的内存布局跟刚才的0xabcdef00没有区别。但是我们错了。看一下。 wws@localhost:~/lab/test$ mips-linux-gnu-gcc -c -o m.o m.c wws@localhost:~/lab/test$ objdump -s m.o|grep data -A1 Contents of section .data: 0000 00000102 abdcef00 00000000 00000000 ................

在MIPS眼中，这个结构体的value是0xabdcef00。两个bitfield的位置颠倒了。这就是问题所在，gcc开发者眼中的big endian的内存模型，其实是这样： >>>>>>memory address growth>>>>>>>>> ab cd ef 00

其实在大端模式下，本来就该这样看内存，这样非常自然。现在问题就明白了，在gcc编译器作者眼中，你指定的结构体的布局是这样来的： >>>>>>>>>memory address growth >>>>>>>>>>>>> (char ab) (int d:4) (int c:4) (char ef) (char oo)

那么，编译器当然会生成 0xabdcef00这个value。

总结一下，这个问题，不是bit order的问题。是编译器的问题。更确切说，是编译器作者的问题。为什么bitfield为什么会受 byte endian的影响呢。因为byte endian一变，编译器作者看待内存的眼光（他心中用的内存模型）也就变了，所以bitfield的生长方向也就变了。

Linux的启动参数中，mem用来指定Linux系统使用的物理内存大小，mem一定要设置为1M对齐吗？

Fri, 24 Jun 2016 14:29:20 +0800

本文是原「蜗窝讨论区」的历史存档（2016-06-24），来自版块「Linux kernel技术问答」，共 4 帖。讨论区已停止服务，此处仅供查阅。

anchen · 2016-06-24 14:29

我现在使用的socfpga的单板，设置mem时必须1M对齐，否则内核就起不来。请问这个是和硬件架构有关，还是和内核代码有关？

wowo · 2016-06-24 15:49

anchen 写道： 我现在使用的socfpga的单板，设置mem时必须1M对齐，否则内核就起不来。请问这个是和硬件架构有关，还是和内核代码有关？

是ARM64吗？只有在ARM64中，kernel RAM的虚拟地址才需要1M对齐，如果此时物理地址不是1M对齐，有可能出问题？


[== C++ ==]
/* arch/arm64/kernel/head.S */
#if (KERNEL_RAM_VADDR & 0xfffff) != 0x80000 

#error KERNEL_RAM_VADDR must start at 0xXXX80000 

#endif

anchen · 2016-06-24 17:38

应该不是。里面是两个Cortex A9。和DTS的设置有关吗？

lutingleo · 2016-07-04 09:51

在ARM32也是需要1M对齐的因为前期页表就是按照1M来做的虚实地址映射

NR_IRQS 和 irq_desc 的定义在哪里？ Kernel 4.7

Thu, 23 Jun 2016 08:41:23 +0800

本文是原「蜗窝讨论区」的历史存档（2016-06-23），来自版块「Linux kernel技术问答」，共 8 帖。讨论区已停止服务，此处仅供查阅。

Kerry · 2016-06-23 08:41

我在移植一个班子，正在写中断控制器的驱动，想改一下中断的个数，却发现找不到irq_desc的定义。在 arch/xxx/.../irqs.h(irq.h) 里有定义 NR_IRQS 。我也需要自己做一个irqs.h吗？

先谢谢下。。

Kerry · 2016-06-23 09:00

irq_desc的定义找到了 http://lxr.free-electrons.com/source/kernel/irq/irqdesc.c#L289

搜索 http://lxr.free-electrons.com/ident?i=irq_desc 居然找不到所有变量的定义，不能相信这个了。。。。。。。

还剩一个问题， NR_IRQS 怎么重新定义。。。。。。

wowo · 2016-06-23 09:09

Kerry 写道： irq_desc的定义找到了 http://lxr.free-electrons.com/source/kernel/irq/irqdesc.c#L289

搜索 http://lxr.free-electrons.com/ident?i=irq_desc 居然找不到所有变量的定义，不能相信这个了。。。。。。。

还剩一个问题， NR_IRQS 怎么重新定义。。。。。。

如果是ARM，随便参考一个“arch/arm/mach-xxx/include/mach/irqs.h”中的NR_IRQS的定义就行了。个数可以随便定，只要大于实际的数目就行了。

Kerry · 2016-06-23 09:17

谢谢回答，我猜想也是这样，就是不知道为什么是这样。。。。。。。是因为 arch/arm/include/asm/irq.h 中有一行

include <mach/irqs.h>

吗？感觉应该还有其他的途径，因为并不是所有的板子都有mach/irqs.h

wowo · 2016-06-23 10:09

Kerry 写道： 谢谢回答，我猜想也是这样，就是不知道为什么是这样。。。。。。。是因为 arch/arm/include/asm/irq.h 中有一行

include <mach/irqs.h>

吗？感觉应该还有其他的途径，因为并不是所有的板子都有mach/irqs.h

这里的<mach/irqs.h>，就是“arch/arm/mach-xxx/include/mach/irqs.h。如果没有这个头文件，在这里有默认值：include/asm-generic/irq.h。

Kerry · 2016-06-24 08:46

我试了一下，不好使，然后发现，CONFIG_SPARSE_IRQ=y 。是这个选线影响的吧应该，以为在 arch/arm/include/asm/irq.h 里面


[== C++ ==]
 6 #ifndef CONFIG_SPARSE_IRQ
 7 #include <mach/irqs.h>
 8 #else
 9 #define NR_IRQS NR_IRQS_LEGACY
 10 #endif

我看了一下，应该是 ARCH_MULTIPLATFORM = y 导致了 CONFIG_SPARSE_IRQ=y

但是呢，我用的CPU是ARM926，是通过在”ARM system type“ 菜单里面选择Allow multiple platforms to be selected（ARCH_MULTIPLATFORM = y ）然后在 "Multiple platform selection" 菜单里面选择 "ARMv5 based platforms..."

现在的问题是，如果想用静态的irq_desc分配的话，我需要自己在”ARM system type“ 菜单定义一个 ARCH_xxxx 吗？一般移植一个新板子的话，，大家怎么做呢：

自己定义一个ARCH?[/*]
还是大部分人就用 CONFIG_SPARSE_IRQ=y 呢？[/*]

对了，忘记说了，以为versatile-ab板子也是ARM926,所以我的移植是在versatile-ab板子的配置的基础上改的。

蜗窝，真是帮了大忙了

Wed, 22 Jun 2016 13:56:39 +0800

本文是原「蜗窝讨论区」的历史存档（2016-06-22），来自版块「灌水区」，共 2 帖。讨论区已停止服务，此处仅供查阅。

Kerry · 2016-06-22 13:56

今年5月份开始，第一次做嵌入式的工作，要移植最新内核到一个完全是自己公司开发的板子上。对Linux只有在大学，做毕业论文时候的一点经验，而且是十多年前的事了。完全抓瞎了。网上的一些资料都很旧，自从看到了蜗窝的文章，就像抓到了救命稻草，谢谢。。。。。

wowo · 2016-06-23 09:10

:) 多交流，一起学习

X-004-UBOOT-串口驱动移植(Bubblegum-96平台)

Sat, 18 Jun 2016 09:56:02 +0800

话说现在的u-boot长得和linux kernel越来越像，设备模型（driver model）、device tree、各种framework（gpio、pinctrl、clock、i2c、regulator、等等），各种概念，均和linux kernel保持一致。这对工程师（特别是linux驱动工程师）来说，是一个利好，因为熟悉了linux kernel相关子系统之后，去搞u-boot基本上

如何学习Linux内核的音频驱动？

Thu, 16 Jun 2016 14:14:34 +0800

本文是原「蜗窝讨论区」的历史存档（2016-06-16），来自版块「Linux kernel技术问答」，共 5 帖。讨论区已停止服务，此处仅供查阅。

peter · 2016-06-16 14:14

大家好，最近想研究下Linux内核的音频驱动，但不知道怎么开始，相信很多人都有玩过这块，希望能够指点下？我现在在玩的板子是支持USB和I2S接口的，是否有必要买块对应声卡调试实践？希望能够帮忙推荐下具体的型号。谢谢大家

wowo · 2016-06-16 17:29

peter 写道： 大家好，最近想研究下Linux内核的音频驱动，但不知道怎么开始，相信很多人都有玩过这块，希望能够指点下？我现在在玩的板子是支持USB和I2S接口的，是否有必要买块对应声卡调试实践？希望能够帮忙推荐下具体的型号。谢谢大家

声卡的话，板子上应该有ADC和DAC接口吧？接上mic和speaker，就可以啦。折腾一个月，把ALSA搞明白就行了。

peter · 2016-06-16 22:31

wowo 写道：

peter 写道： 大家好，最近想研究下Linux内核的音频驱动，但不知道怎么开始，相信很多人都有玩过这块，希望能够指点下？我现在在玩的板子是支持USB和I2S接口的，是否有必要买块对应声卡调试实践？希望能够帮忙推荐下具体的型号。谢谢大家

声卡的话，板子上应该有ADC和DAC接口吧？接上mic和speaker，就可以啦。折腾一个月，把ALSA搞明白就行了。

恩，谢谢指点，板子上有codec.

Allen.G · 2016-12-30 11:50

wowo 写道：

peter 写道： 大家好，最近想研究下Linux内核的音频驱动，但不知道怎么开始，相信很多人都有玩过这块，希望能够指点下？我现在在玩的板子是支持USB和I2S接口的，是否有必要买块对应声卡调试实践？希望能够帮忙推荐下具体的型号。谢谢大家

声卡的话，板子上应该有ADC和DAC接口吧？接上mic和speaker，就可以啦。折腾一个月，把ALSA搞明白就行了。

请问有没有什么好的资料介绍alsa内部机制的，比如各个数据结构的用途，数据流的控制

peter · 2017-01-11 17:08

Allen.G 写道：

wowo 写道：

peter 写道： 大家好，最近想研究下Linux内核的音频驱动，但不知道怎么开始，相信很多人都有玩过这块，希望能够指点下？我现在在玩的板子是支持USB和I2S接口的，是否有必要买块对应声卡调试实践？希望能够帮忙推荐下具体的型号。谢谢大家

声卡的话，板子上应该有ADC和DAC接口吧？接上mic和speaker，就可以啦。折腾一个月，把ALSA搞明白就行了。

请问有没有什么好的资料介绍alsa内部机制的，比如各个数据结构的用途，数据流的控制

推荐看看DroidPhone的博客http://blog.csdn.net/droidphone/article/details/6271122

DRAM 原理 2 ：DRAM Memory Organization

Tue, 14 Jun 2016 22:43:51 +0800

在 DRAM Storage Cell 章节中，介绍了单个 Cell 的结构。在本章节中，将介绍 DRAM 中 Cells 的组织方式。

Hello

Tue, 14 Jun 2016 15:56:50 +0800

本文是原「蜗窝讨论区」的历史存档（2016-06-14），来自版块「灌水区」，共 2 帖。讨论区已停止服务，此处仅供查阅。

East · 2016-06-14 15:56

Welcome to wowo

wowo · 2016-06-14 21:17

通过点亮LED的方法调试嵌入式代码

Sun, 12 Jun 2016 22:10:43 +0800

在软件开发的过程中，debug（调试）是一个很重要的事情，因为没有百分之百正确的代码，一旦结果不符合预期，我们需要知道问题出在哪里了。在PC环境下开发应用程序，我们不需要太操心，因为有各式各样的模拟器、调试器可供使用，我们可以追踪到每一行代码的执行过程和执行结果，找出问题只是时间问题而已。但在嵌入式环境下，就有些麻烦了，能用的手段，无外乎两种： 1）使用硬件仿真器定位问题。 2）使用日志输出定位

请问如何关闭或修改调试串口？

Fri, 10 Jun 2016 10:12:52 +0800

本文是原「蜗窝讨论区」的历史存档（2016-06-10），来自版块「Linux kernel技术问答」，共 4 帖。讨论区已停止服务，此处仅供查阅。

jidai · 2016-06-10 10:12

rk3128的SDK中，默认使用uart2作为调试串口，如何关闭或转到其它调试串口上？

现在调试串口关闭后，kernel不停重启，因为调试串口关了，也不知道如何查找问题。而修改调试串口后，输出是乱码，kernel也不能正常启动（等待很多时间，网卡也没有准备好，因此判断没有完成启动）

希望能给点方向和思路，谢谢！

wowo · 2016-06-10 21:17

jidai 写道： rk3128的SDK中，默认使用uart2作为调试串口，如何关闭或转到其它调试串口上？

希望能给点方向和思路，谢谢！

关闭或者修改调试串口的话，就是在命令行把“console=”删掉或者修改掉就行了 console=ttyFIQ0,115200

qdzhaozx · 2016-06-12 09:00

更改uboot传给kernel的env，将console的变量内容改成需要打印的的串口，以及波特率

jidai 写道： rk3128的SDK中，默认使用uart2作为调试串口，如何关闭或转到其它调试串口上？

希望能给点方向和思路，谢谢！

jidai · 2016-06-12 13:46

感谢二楼三楼两位的指点，现在问题已经解决了。除了两位提到的点，还有就是我用的内核中，有一个配置项，也需要修改串口号，然后就解决了，呵。

u-boot中CONFIG_SUPPORT_SPL、CONFIG_SPL和CONFIG_SPL_BUILD的作用

Wed, 08 Jun 2016 21:42:13 +0800

本文是原「蜗窝讨论区」的历史存档（2016-06-08），来自版块「Linux kernel技术问答」，共 1 帖。讨论区已停止服务，此处仅供查阅。

wowo · 2016-06-08 21:42

QQ群上bruno同学提出了如下的问题：

** 写道：**

请问 uboot在编译的时候是不是用 config_spl_build 来区分 spl 和 uboot的啊？

看到有 config_spl ,是不是这个是用来开启spl功能，而config_spl_build 用来编译过程控制，看了几个板子的config文件，都只有 config_spl=y ,那 config_spl_build是如何控制编译的啊？

想起在写“(/u-boot/boot_flow_1.html)”的时候，自己也有疑问，但是没有深究。多谢bruno提出来，又去看了下代码，记录如下： u-boot关于SPL有三个配置项，CONFIG_SUPPORT_SPL、CONFIG_SPL和CONFIG_SPL_BUILD，其中CONFIG_SUPPORT_SPL和CONFIG_SPL在Kconfig中定义，如下：


[== Undefined ==]
config SUPPORT_SPL
 bool
config SUPPORT_TPL
bool
config SPL
bool
depends on SUPPORT_SPL
prompt "Enable SPL"
help
If you want to build SPL as well as the normal image, say Y.

CONFIG_SUPPORT_SPL表示是否支持SPL功能，一般是在具体arch的Kconfig的版型菜单中，根据需要select，例如（可参考“(https://github.com/wowotechX/u-boot/blob/x_integration/arch/arm/Kconfig)”）：

[== Undefined ==] config TARGET_BUBBLEGUM bool "Support Bubblegum 96Board" select ARM64 select SUPPORT_SPL select SPL help Support for Bubblegum 96boards platform based on Actions S900 Soc, with 4xA53 CPU, PowerVR G6230 GPU, 2GB RAM, and USB 3.0 support.

某个版型支持SPL了，并不代表使能了SPL，因此通过额外的CONFIG_SPL来决定是否使能 SPL，根据上面Kconfig的定义，只有在CONFIG_SPL是依赖CONFIG_SUPPORT_SPL的，因此只有select了SUPPORT_SPL，CONFIG_SPL的菜单项才会在menuconfig中看到。当然，我们也可以粗暴的直接select SPL，就像上面bubblegum一样。

最后，再看CONFIG_SPL_BUILD，它是在(https://github.com/wowotechX/u-boot/blob/x_integration/scripts/Makefile.spl)中以编译选项的形式定义的，如下：


[== Undefined ==]
KBUILD_CPPFLAGS += -DCONFIG_SPL_BUILD

有什么目的？因为u-boot中，无论是defconfig，还是include/configs/*.h中的配置项，是不区分u-boot和SPL的，因此SPL的编译控制选项无法用这种方法给出。而u-boot和SPL是分两次编译的，也就是说，二者的编译选项不同，因此，使用编译选项的方法，就可以区隔u-boot和SPL的代码了。

DRAM 原理 1 ：DRAM Storage Cell

Wed, 08 Jun 2016 16:41:05 +0800

接下了 X Project SDRAM 的任务，趁机整理下 DRAM、SDRAM、DDR SDRAM、LPDDR 等相关的内容。这是第一篇，简单介绍下 DRAM Storage Cell 的相关内容。

u-boot启动流程分析(2)_板级(board)部分

Tue, 07 Jun 2016 22:06:38 +0800

书接上文（ u-boot启动流程分析(1)_平台相关部分），本文介绍u-boot启动流程中和具体版型（board）有关的部分，也即 board_init_f / board_init_r 所代表的、board有关初始化过程。该过程将持续u-boot的整个生命周期，直到main_loop（即传说中的命令行）。注1：由于u-boot后初始化过程，基本上涉及到了所有的软件模块，因此本文不能一一分析，

蓝牙协议分析(6)_BLE地址类型

Tue, 07 Jun 2016 11:40:03 +0800

也许关注BLE的同学都注意到了，BLE设备有多种类型的设备地址，如Public Device Address、Random Device Address、Static Device Address、Private Device Address等等。如果不了解内情，大家肯定会被它们绕晕。不过存在即合理，这样看似奇怪的设计，实际上反映了BLE的设计思路以及所针对的应用场景。让我们通过本文一窥究竟。

【任务2】启动到u-boot command line

Wed, 01 Jun 2016 22:26:28 +0800

本文是原「蜗窝讨论区」的历史存档（2016-06-01），来自版块「X Project」，共 8 帖。讨论区已停止服务，此处仅供查阅。

wowo · 2016-06-01 22:26

任务说明通过“【任务1】启动过程-Boot from USB”，我们已经可以通过USB将一个二进制文件，上传到板子的SRAM中并执行。基于此，我们可以展开第二个任务：启动到u-boot的命令行。完成该任务的基本步骤包括：
通过USB DFU操作，将u-boot SPL image上传到SRAM中并运行[/*]
u-boot SPL，初始化板子的SDRAM后，退出[/*]
通过USB DFU操作，将u-boot image上传到SDRAM中并运行[/*]
u-boot启动后，初始化UART，并执行UART console，进入命令行[/*]
涉及的知识点该任务主要涉及如下知识点：
SDRAM的配置和初始化（SDRAM driver）[/*]
u-boot driver model[/*]
u-boot device tree（和kernel中一模一样，可以统一学习）[/*]
u-boot UART driver[/*]
u-boot serial console[/*]
u-boot command line[/*]
完成任务的思路相比“【任务1】启动过程-Boot from USB”，该任务比较简单，可以拆分为几个独立的部分：
SDRAM有关的任务。和具体的版型、SDRAM型号有关，代码量较小。可以基于具体的板子，完成一篇SDRAM有关的硬件介绍的文章，并给出SDRAM初始化有关的步骤。然后在u-boot SPL的board_init_f函数中配置即可。[/*]
u-boot driver model有关的介绍和分析，写一篇文章即可。[/*]
u-boot device tree的编写、编译和使用，可以结合博客上的device tree的分析文章，从实战的角度，写一篇文章。[/*]
u-boot UART driver的设计和编写，要基于driver model和device tree。和u-boot的UART框架，以及具体的板子有关，可以出两份文章，一份介绍具体板子UART有关的硬件，一份介绍u-boot的UART框架。文档完成后，直接编写具体板子的代码即可。[/*]
u-boot serial console和command line有关的内容，不需要任何的实现，可以写一篇文章，介绍相应的机制，以及使用方式。[/*]
u-boot启动流程的第2部分，从u-boot开始，到command line出来，可以写一篇介绍文章。[/*]

最后还是希望大家能捡一些力所能及的任务，和我们一起开发，不然我们全包了的话，太木有意思了（说实话，这些事情对我们来说太小菜一碟了），呵呵~~

任务总结到目前为止（2016/07/27），该任务在bubblegum 96boards上基本完成，共有如下的文档和代码产出：
(/u-boot/boot_flow_2.html)[/*]
X-004-UBOOT-串口驱动移植(Bubblegum-96平台)[/*]
X-005-UBOOT-device tree移植(Bubblegum-96平台)[/*]
X-006-UBOOT-pinctrl driver移植(Bubblegum-96平台)[/*]
X-007-UBOOT-DDR的初始化(Bubblegum-96平台)[/*]
X-008-UBOOT-支持命令行(Bubblegum-96平台)[/*]

其中“X-005-UBOOT-device tree移植(Bubblegum-96平台)”、“X-006-UBOOT-pinctrl driver移植(Bubblegum-96平台)”并不是该任务的必要步骤。而“X-007-UBOOT-DDR的初始化(Bubblegum-96平台)”，为关键步骤，但受限于资源的缺乏，无法给大家呈现移植过程。

可以通过如下步骤在板子上验证： 1）代码下载（具体可参考“X-003-UBOOT-基于Bubblegum-96平台的u-boot移植说明”）


[== Undefined ==]
mkidr -p ~/work/xprj
cd ~/work/xprj
git clone https://github.com/wowotechX/build
git clone https://github.com/wowotechX/u-boot
git clone https://github.com/wowotechX/tools

2）代码编译


[== Undefined ==]
cd build
make env_prepare #下载交叉编译工具，只需要执行一次即可
make libusb #只需要执行一次
make dfu #只需要执行一次
make uboot

3）按住Bubblegum-96的ADFU键，使板子进入DFU模式

4）按住Bubblegum-96的ADFU键不松开，将splboot.bin（就是我们的SPL image）上传到SRAM并执行


[== Undefined ==]
sudo ../tools/dfu/dfu bubblegum 0xe406b200 ../tools/actions/splboot.bin 1

5）执行完毕后，会重新进入DFU模式，进入后，可以松开ADFU按键。

6）将u-boot上传到DDR并执行（注意上传位置和CONFIG_SYS_TEXT_BASE 一致）


[== Undefined ==]
sudo ../tools/dfu/dfu bubblegum 0x11000000 out/u-boot/u-boot-dtb.bin 1

7）使用串口连接开发板，将可以进入命令行。

关于页表同步问题

Wed, 01 Jun 2016 10:00:02 +0800

本文是原「蜗窝讨论区」的历史存档（2016-06-01），来自版块「Linux kernel技术问答」，共 6 帖。讨论区已停止服务，此处仅供查阅。

linuxer · 2016-06-01 10:00

QQ群中的MBeginner问了这样的一个问题：如果进程A、B都访问了某个虚拟地址x，此时A、B的页表都与init_mm同步后，然后进程A修改了地址x的映射关系，修改的是init_mm的页表，此时如果不更新进程B的页表，那么进程B再次访问地址X的时候会认为当前页表是有效的，不会发生缺页中断，从而导致实际上访问的是错误的物理地址，这种情况可能出现么？

整理大家的回答如下：这种情况不会发生。首先，内核空间可以分成下面几种： 1、 directed mapped memory region，就是mapping到main memory的那段虚拟地址空间，VM和PM之间有一个固定的offset。这个memory region的页表是初始化建立的，是不会动态变化的。 2、 permanent kernel mapping、temporary kernel mapping和noncontiguous memory allocation（就是大家熟悉的vmalloc适用的memory region）。这个段的页表可以被更新。因此，我相信大家说到页表同步问题都是指的第二段memory region的页表同步问题。

关于你说的场景，我分步描述如下： Step 1：A进程调用vmalloc分配了一段虚拟内存，首地址是x。这时候，所有进程的页表并没有建立关于x的项目，唯一完整建立x地址段的页表是init_mm的PGD。

Step 2：当进程A、B都访问了某个虚拟地址x，此时A、B的页表都与init_mm同步后，A和B也都建立好了关于x这个虚拟地址段的页表。但是，这里需要强调的是：对于x虚拟地址段，A进程和B进程有不同的PGD，但是它们PGD中关于x地址段的entry们都是指向相同的PMD。当然PMD entry指向的PTE也是相同的。换句话说，对于x地址段，所有进程还有init mm而言，它们的PMD和PTE都是共享的。

Step 3：进程A调用vfree函数释放了地址x，当然操作的依然是init mm的PGD以及其下级的页表们。需要说明的是：所有根是init mm PGD的那些PMD和PTE的内存不会回收，因此x地址段的PMD和PTE页表本身的内存并不会释放，vfree只是将x地址段对应的页表项全部清除。

Step 4：进程B访问x地址段的时候，PGD entry指向了大家共享的PMD，PMD的entry指向了大家共享的PTE，但是，PTE中的具体的entry已经被清除，因此产生page fault

linuxer · 2016-06-02 09:46

harvey网友的问题：关于你前面提到的“init_mm”，下面的理解是否正确 1，init_mm 本身是内核的一个数据结构，其中包括一个红黑树的跟，任何进程或线程在内核中申请内存后，内存管理模块就以申请空间对应的虚拟地址作为红黑树的key值，挂到这棵红黑树上。当然此时并没有真正分配页面。当进程或线程真正访问该内存空间是就会产生缺页中断，在中断中再真正分配内存。init_mm 本身是给软件用的。 2，关于申请内核空间的进程，内存管理模块会将空间对应的PMD（PTE表项直接填写到了PMD中了）表项填写到进程自己的PGD表中，只是填写了一个entry。这个PGD表是给硬件使用的，即访问时又硬件自动查表。

linuxer · 2016-06-04 13:00

所有和进程地址空间相关的内容都被封装到一个叫做mm_struct的数据结构中，被称作memory descriptor。每个用户空间进程都有其对应的memory descriptor，具体位于进程task_struct的mm成员中。内核线程是否有memory descriptor呢？没有，因此其进程描述符的mm成员指向了NULL。不过，对于linux而言，内核的最小调度单位是线程，因此存在内核线程和用户线程之间的切换问题，每当切换的时候，需要切换进程地址空间（切换页表，进程的页表信息位于其mm_struct的pgd成员中），用户线程到用户线程的切换当然没有问题，但是用户线程和内核线程之间的切换就会有问题，因为内核线程没有memory descriptor，怎么办？只能是借用了，因此，在进程描述符（task_struct）中有一个active_mm的成员，表示该进程（内核线程）当前正在使用的memory descriptor（注意：“使用”并不表示“拥有”）。对于普通用户进程，它拥有自己的memory descriptor，因此进程描述符的active_mm和mm成员指向同一个memory descriptor（自己有memory descriptor，当然使用自己的了）。对于内核线程，它不可能”拥有“memory descriptor（mm等于NULL），因此active_mm需要借用其他进程的memory descriptor，可以参考下面的代码（代码来自4.1.10）：－－－－－－－－－－－－－－－－－－－－ static inline struct rq * context_switch(struct rq rq, struct task_struct prev, struct task_struct next) { struct mm_struct mm, *oldmm;

prepare_task_switch(rq, prev, next);
mm = next-&gt;mm;
oldmm = prev-&gt;active_mm;
/*

For paravirt, this is coupled with an exit in switch_to to
combine the page table reload and the switch backend into
one hypercall.
*/
arch_start_context_switch(prev);

if (!mm) {－－－－－－－－－－－－－－－－切换到一个内核线程（next的mm成员为NULL）
next-&gt;active_mm = oldmm;－－－－－－－借用上一个的使用的memory descriptor
atomic_inc(&amp;oldmm-&gt;mm_count);
enter_lazy_tlb(oldmm, next);
} else－－－－－－－－－－－－－－－－－－－切换到普通进程
switch_mm(oldmm, mm, next);
if (!prev-&gt;mm) {
prev-&gt;active_mm = NULL;－－－－－－－－－如果是从一个内核线程切换到某个其他进程，那么借用期结束
rq-&gt;prev_mm = oldmm;
}
/*

Since the runqueue lock will be released by the next
task (which is an invalid locking op but in the case
of the scheduler it’s an obvious special-case), so we
do an early lockdep release here:
*/
spin_release(&amp;rq-&gt;lock.dep_map, 1, THIS_IP);

context_tracking_task_switch(prev, next);
/* Here we just switch the register state and the stack. */
switch_to(prev, next, prev);
barrier(;
return finish_task_switch(prev);

} －－－－－－－－－－－－－－－－－－－－－－－－－－讲了这么多，似乎还是没有到init_mm，呵呵，那么init_mm到底是属于哪一个进程呢？其实init_mm不属于任何的进程或者内核线程。当然，在启动阶段，swapper进程（idle进程，pid等于0的那个进程）曾经借用国init_mm，但是初始化完成，调度器正常运作之后（至少发生了一次进程切换涉及到了idle进程），init_mm不和任何的进程相关了。

关于ARMv8架构下函数栈

Tue, 31 May 2016 21:56:50 +0800

本文是原「蜗窝讨论区」的历史存档（2016-05-31），来自版块「Linux kernel技术问答」，共 5 帖。讨论区已停止服务，此处仅供查阅。

showstopper · 2016-05-31 21:56

Hi All，

Q群里问问题不过瘾，还是来这边了

是一个有关v8架构下函数栈的问题，先帖代码：


[== Undefined ==]
/*
 * AArch64 PCS assigns the frame pointer to x29.
 *
 * A simple function prologue looks like this:
 * sub sp, sp, #0x10
 * stp x29, x30, 
 * mov x29, sp
 *
 * A simple function epilogue looks like this:
 * mov sp, x29
 * ldp x29, x30, 
 * add sp, sp, #0x10
 */
int notrace unwind_frame(struct stackframe *frame)
{
 unsigned long high, low;
 unsigned long fp = frame->fp;
low = frame-&gt;sp;
high = ALIGN(low, THREAD_SIZE);

if (fp &lt; low || fp &gt; high || fp &amp; 0xf)
 return -EINVAL;

frame-&gt;sp = fp + 0x10;
frame-&gt;fp = *(unsigned long *)(fp);
/*
 * -4 here because we care about the PC at time of bl,
 * not where the return will go.
 */
frame-&gt;pc = *(unsigned long *)(fp + 8) - 4;

return 0;

}

Q：注释部分：


[== Undefined ==]
 * A simple function prologue looks like this:
 * sub sp, sp, #0x10
 * stp x29, x30, 
 * mov x29, sp

大概做了以下几件事： 1. sp指针自减0x10 2. 将0x29(即FP)入栈，将0x30（即LR）入栈，地址为SP 3. 将FP寄存器的值赋给SP 那么是不是意味着，对于单个函数，函数栈的大小只能是0x10？如果函数中临时变量较多超出0x10怎么办？

之前我在x86架构下，确定一个函数的栈范围需要ESP和EBP两个指针，似乎ARM下是用FP和SP，并且FP的相邻地址就保存了LR 按照以上的说法，如果出现了系统崩溃的bug，似乎只需要知道FP指针，就可以推导函数调用的整个流程（因为相当于同时知道了LR）

QQ群中关于TCR_EL1寄存器、shareable 概念以及内核地址空间，用户地址空间的讨论

Tue, 31 May 2016 11:06:05 +0800

本文是原「蜗窝讨论区」的历史存档（2016-05-31），来自版块「Linux kernel技术问答」，共 5 帖。讨论区已停止服务，此处仅供查阅。

linuxer · 2016-05-31 11:06

说明：这些文字来自蜗窝QQ群的讨论，因为觉得比较有价值，因此保留下来，方便后续查阅

Question from harvey: 请教蜗窝，发现一个问题。关于cache的分配方式（如写分配、读分配等）在TCR_EL1寄存器中有设置 cache分配方式的语句，在MMU表中的memory attribute 中依然可以设置cache分配方式？这两处设置有什么要求吗？需要一致？不一致会如何？非常感谢！

Answer from Shaman庆: tcr是设置页表本身需不需要cache

Answer from linuxer: 当PE访问一个虚拟地址的时候，需要遍历各级translation table来进行地址翻译过程，因此，在Translation table中就会有关于该虚拟地址的各种属性（memory type 和 attribute）。在进行上面过程的时候，需要访问保存在memory中的各级translation table，PE在访问各级translation table使用的是物理地址，没有地址翻译过程（否则会出现这样的问题：是现有鸡还是现有蛋呢？），也就无法定义其cacheability 和 shareability，因此，ARMv8在寄存器TCR_EL1中定义了访问Translation table的memory attribute。

Question from harvey: 再向各位大神请教一下。 1，shareable 是什么概念？起到什么作用？ 2，用户态使用TTBR0_EL1，内核态使用TTBR1_EL1？这个是需要寄存器指定吗？还是说TTBR0_EL1 对应的表中地址范围为低端，TTBR1_EL1对应的地址范围为高端。用户态在使用低端虚拟地址时自动落到TTBR0_EL1 对应区域。这样理解释放可以？谢谢先

Answer from Shaman庆: 对于第一个问题：例如一个4 cluster，每个cluster 4个core的系统，如果配置inner域为cluster内部，那么innershare内存只能在本cluster的4个core保持一致性，outeshare的能在16个core保持一致性，当然nonshare就不和任何core保持一致了

Answer from linuxer: 你问的第一个问题我是这样理解的：本身shareability的概念是和多核环境相关的，当系统中有多个PE，有多个level的cache的时候，事情变得复杂了。对于一个memory location，需要考虑下面的问题： 1、该memory location可以被多少个PE（或者说observer）访问？ 2、谁来维护多个PE之间的cache coherence？

如果一个memory location的shareable attribute是Non-shareable，那么则说明该memory不会在多个cpu core之间共享，只是对一个core可见如果一个memory location可以被多个observer（PE，GPU，DMA controller等）共享，那么我们可以设定该memory的shareable attribute是inner shareable，或者设定为outer shareable。outer shareable domain一般会包括多个inner shareable domain，具体如何划分inner和outer区域是和具体的实现相关。对于Non-shareable，不需要维护cache coherence，对于inner shareable或者outer shareable attribute而言，硬件会维护cache coherence（data cache或者unified cache）。为什么要区分inner shareable和outer shareable呢？我都设定为outer shareable多好，反正硬件会帮助维护一致性，不是吗？实际上，设计总是在多个因素之间平衡，虽然用硬件维持cache coherency对于软件来说比较方便，但是增加了硬件设计就是增加了SOC上的晶体管，增加了数据访问的delay，增加了功耗。因此，把一个大的，包括多个observer的outer shareable domain分成几个inner shareable domain可以降低上面说的那些开销。

Answer from linuxer: 你问的第二个问题我是这样理解的：首先，选择那一个Translation table应该是和虚拟地址相关，对于ARMv8，整个虚拟地址空间被分成了两个subrange：－－－－－－－－－－－－－－－－－－－ Lower VA subrange ：从0x0000_0000_0000_0000 到 (2^(64-T0SZ) - 1) Upper VA subrange ：从(2^64 - 2^(64-T1SZ)) 到 0xFFFF_FFFF_FFFF_FFFF －－－－－－－－－－－－－－－－－－－－－－如果VA落入Lower VA subrange，那么使用TTBR0_EL1，如果落入Upper VA subrange，那么将使用TTBR1_EL1。具体如何定义VA subrange的size可以参考TCR_EL1寄存器的描述。具体用户空间和内核空间都是linux kernel定义的，硬件并不关心（硬件只关心Lower VA subrange还是Upper VA subrange），正因为用户空间和内核空间都是linux kernel定义的，因此kernel中要为TTBR0_EL1和TTBR1_EL1设定正确的页表基地址，具体可以参考内核代码。

Question from harvey: 我有一个疑问，在ARM 32bit系统中，内核和用户态共用一个转换表。我一直认为，所有进程的内核态空间应该都是一样的（还包括内核线程空间），当然，用户态空间是私有的。那么问题来了，如果一个进程调用一个驱动模块，在内核空间申请了一段内存（未释放，以后还会使用）。那么这段内存空间的映射是否需要更新到所有进程的内核空间中？如果更新的话，系统开销岂不很大？

Answer from linuxer: 对于ARM32系统，硬件只支持一个Translation table，这个Translation table既包括了userspace，也包括了kernel space的页表。当然，说页表有些笼统，我们使用下面的术语好了： 1、PGD （对于ARM而言，应该是level0的translation table） 2、PMD （对于ARM而言，应该是level1的translation table） 3、PTE （对于ARM而言，应该是level2的translation table）当我们说一个进程的地址空间的时候，往往指的是一个PGD的地址，而该地址就保存在某个硬件寄存器中。例如对于X86就是CR3寄存器，对于ARM而言，就是TTBR寄存器。PGD有若干的entry，每个entry又指向了下一阶的translation table，也就是PMD（如果是4级映射，那么还有PUD，这里我们就不考虑那么复杂的场景了）。同样的，每个PMD也是由若干的entry组成，每个entry又指向了PTE。在完成上面的基本硬件描述之后，我们回头看看软件抽象，一个进程的地址空间是由mm struct中的pgd成员描述。以pgd为起始点，辅以pmd和pte，这些数据结构包括了一个进程需要地址翻译的全部信息（内核空间加上用户空间）。当进程切换的时候，所谓切换mm也就是切换pgd而已。虽然以pgd为起点，可以构建整个地址空间，但是在fork进程的时候，是否需要一并将kernel space和userspace的页表项（包括PGD entry，PMD entry，PTE entry）全部建立起来呢？不需要的，如果有CLONE_VM的flag，那么其实两个进程指向同一个mm struct即可，也就是说，所有的页表都是共享的。如果没有CLONE_VM，那么需要调用dup_mmap来copy该进程的页表信息，但是，dup_mmap并不会copy kernel space的页表。换句话说，一个新创建的进程，其页表（地址翻译表）中没有任何关于内核空间的条目，一旦该进程运行起来，并通过系统调用进入内核的时候，一定会发生page fault，因为该进程要访问的内核空间的地址在pgd中对应的entry是空的。产生了异常之后，内存管理模块会帮你处理一切的：根据init_mm来填写pgd entry的内容（具体参考do_translation_fault函数）。

OK，在完成上面的基础知识后，我们来看看你的问题： Q、是否所有进程的内核空间都是一样的？ A、Yes

Q、是否一个进程的内核空间以及用户空间共享一个地址翻译表 A、当然，都是以该mm struct的pgd成员为起点的各个level的地址翻译表，当然，在pgd或者说level 0 Translation table这个层面上，是共享的，不过对于PMD和PTE，内核空间和用户空间是不同的

Q、是否所有进程（包括内核线程）的内核空间是一样的？ A、的确是一样的。但是，由于各个用户进程都有自己的pgd，因此在pgd或者说level 0 Translation table这个层面上，各个进程不可能共享。我们知道，各个进程在访问内核空间地址的时候，其翻译过程包括PGD PMD PTE，各个进程通过各自的PGD中的entry指向了相同的PMD以及PTE，或者说PMD和PTE是共享的

Q、如果一个进程调用一个驱动模块，在内核空间申请了一段内存（未释放，以后还会使用）。那么这段内存空间的映射是否需要更新到所有进程的内核空间中？如果更新的话，系统开销岂不很大？ A、当然不需要了，其实，一个进程陷入内核，并在内核空间进行了地址映射，这时候创建的相关的页表并不会进入该进程的页表（mm_struct->pgd），也就是说该地址对应的pgd entry是null。取而代之的是在init_mm的pgd中建立相关entry（当然包括该entry对应的pmd和pte）。这时候，你心里肯定想：这是什么鬼？不在自己的translation tables中建立地址映射关系，反而去init_mm去建立，有没有搞错。但是，实际上这是内核巧妙的设计之处。一旦在init_mm（就是表示内核地址空间）中建立了地址映射关系，实际上就是为所有的进程（包括内核线程）建立的地址映射关系，因为当各个进程在访问该地址的时候，由于对应的PGD entry是null，因此产生异常，然后用init_mm pgd 对应的entry copy到该进程的pgd就OK了，仅仅是copy一个entry而已，因此不存在开销很大的问题。

BTW，多谢你的问题，让我又重温一下内存管理的内容，多谢！上面是我的理解，不一定对，大家可以探讨。

X-003-UBOOT-基于Bubblegum-96平台的u-boot移植说明

Sun, 29 May 2016 18:00:10 +0800

本文是X Project “ 【任务1】启动过程-Boot from USB ”的一部分，将以“Bubblegum 96boards”为例，介绍将u-boot移植到一个新的平台上的步骤和方法，并以此为契机，分析、理解u-boot的编译过程。

蓝牙协议分析(5)_BLE广播通信相关的技术分析

Fri, 27 May 2016 16:15:22 +0800

大家都知道，相比传统蓝牙，蓝牙低功耗（BLE）最大的突破就是加大了对广播通信（Advertising）的支持和利用。关于广播通信，通过“ 玩转BLE(1)_Eddystone beacon ”和“ 玩转BLE(2)_使用bluepy扫描BLE的广播数据 ”两篇文章的介绍，我们已经有了一个整体的认识。本文将依此为基础，从技术的角度，分析和理解BLE协议中有关广播通信的定义和实现。注1：之前的蓝牙协

ARMv8之Observability

Wed, 25 May 2016 18:22:53 +0800

在ARMv8关于memory order描述章节中，大量使用了observer、observed、completion等术语，本文主要是澄清这些术语，为后续描述memory order和memory barrier相关指令打下基础。另外，在几个星期前，和codingbelief同学讨论DMB指令的时候，他提出了一个尖锐的问题：什么是PE observes memory access，是指 cpu

USB传输速度问题

Fri, 20 May 2016 17:37:43 +0800

本文是原「蜗窝讨论区」的历史存档（2016-05-20），来自版块「Linux kernel技术问答」，共 2 帖。讨论区已停止服务，此处仅供查阅。

wpch315 · 2016-05-20 17:37

应用软件的同事使用USB从口的时候反映USB的传输速度有点慢，现在想看一下USB驱动有没有问题，但是不太清楚一般怎么调试USB，请问大家怎样测试USB的速度，还有调试USB主从口的方式

Codingbelief · 2016-05-27 10:31

这个估计还是要吧场景详细描述清楚一点才好分析，你的设备是作为 host 还是 device？传输速度慢实际传输场景是怎样的？先把场景定义清楚，然后在划分整个场景中涉及到的各个模块，分析可能的瓶颈，再一点点调试。

关于spin_lock是锁一个核还是所有核，gpio口模拟pwm怎么保持时间准确并不被打断

Fri, 20 May 2016 10:55:47 +0800

本文是原「蜗窝讨论区」的历史存档（2016-05-20），来自版块「Linux kernel技术问答」，共 9 帖。讨论区已停止服务，此处仅供查阅。

cinmun · 2016-05-20 10:55

如题，楼主最近用gpio口模拟pwm载波，用延迟udelay，结果要保持不被打断，只能用spin_lock，但是要500ms的时间就太长了，系统整个被锁死，后台播放的音乐就卡了，还有其他什么好方法，保持住gpio口高低循环，并且时间准确。

qdzhaozx · 2016-05-20 10:59

模拟pwm 建议用定时器timer中断来做

cinmun · 2016-05-20 11:01

没有多余的 timer 了只能用io口来模拟

qdzhaozx 写道： 模拟pwm 建议用定时器timer中断来做

wowo · 2016-05-20 11:06

udelay的方法，应该是下下策吧？ PWM的精度要求有多高？周期和占空比是什么量级的呢？如果精度要求不高，可以用timer。如果精度要求高，系统有高精度timer吗？有的话，可以用hrtimer。

另外不需要多余的timer啊，和系统共用timer就可以了： include/linux/hrtimer.h include/linux/timer.h

qdzhaozx · 2016-05-20 11:10

同意！看看片子上的Timer都怎么用的，共用同一个timer，还是用这个普通的io ，周期性的toggle即可！

wowo 写道： udelay的方法，应该是下下策吧？ PWM的精度要求有多高？周期和占空比是什么量级的呢？如果精度要求不高，可以用timer。如果精度要求高，系统有高精度timer吗？有的话，可以用hrtimer。

另外不需要多余的timer啊，和系统共用timer就可以了： include/linux/hrtimer.h include/linux/timer.h

linuxer · 2016-05-20 12:29

QQ群有若干相关的讨论，这里记录下来，如下：

【冒泡】维尼其实我一直有一个疑问， spinlock自旋锁是锁定一个核还是所有的核都锁?

spinlock当然是锁所有核了

【活跃】showstopper 之前看资料说是spinlock关闭抢占和中断，锁所有核是什么意思

spinlock关闭抢占很正常啊，因为如果该CPU上的A和B两个进程都使用spinlock来保护临界区，如果不关闭抢占，那么在A的临界区内会发送B抢占A的执行的事件，这样，当B试图进入临界区的时候，岂不是要一直spin下去了吗？至于中断，这从而说起啊，spinlock不会关闭中断的，本质上，spinlock和关闭本地中断是内核同步的两种工具，你可以单独使用其一，也可以组合使用，都是和你的临界区并发访问的特性有关的锁所有核是什么意思？就是锁所有内核上的并发的意思，也就是说，如果有来个多个cpu core上运行的进程的并发访问，那么spinlock也是适合的。

【活跃】chinaLazy 我认为spinlock锁的本质不是核应该是总线

spinlock是一种内核同步手段，本质上和cpu core以及bus都是没有什么关系的，就是保护临界区不会被多个excution thread（可能是中断上下文，也可能是进程上下文，也可能是软中断上下文...）并发访问，只允许一个excution thread进入。

【冒泡】维尼为什么是锁所有核呢驱动程序只在一个核心运行啊

驱动程序只在一个核心运行？你确定吗？驱动程序中有那么多上下文，怎么可能在一个CPU core上运行？例如：驱动的handler在哪个cpu core上执行？中断送达哪一个core就会在哪一个core上执行，如果你愿意，可以设定IRQ affinity，把中断分散送往各个core。而xxx_read这样的驱动函数，实际上属于进程上下文，各个cpu core上的进程都能够通过系统调用，从而执行驱动代码。

【冒泡】维尼我现在用gpio口模拟 pwm载波只能用spinlock来保持不被间断但是时间太长了 500多ms要

用spinlock来保护500ms的临界区，我也是醉了，可以考虑使用hrtimer

【冒泡】黑黑-Augus 2016/05/20 10:52:15 @showstopper 关闭本地中断是为了避免死锁吧

正解。当受保护的资源可能被中断上下文（hardirq）和进程上下文并发访问的时候，需要关闭本地中断。考虑下面的场景：在CPU CORE0上，在进程上下文中进入spinlock保护的临界区，这时候，如果不关闭本地中断，那么中断可以打断当前临界区的执行，从而执行interrupt handler，而在interupt handler中，获取spinlock并试图进入临界区，悲剧发生了，这时候该核永远的在中断上下文上spin起来......

【活跃】showstopper @黑黑-Augus 我的理解是，spin_lock为了当前临界区代码不被打断，所以不能有进程切换，这时候就需要关闭中断

"spin_lock为了当前临界区代码不被打断，所以不能有进程切换"，其实禁止抢占也就是禁止了进程切换，和关闭中断无关的，如果临界区没有interrupt handler访问，单纯的spinlock就OK了，不需要disable local interrupt。

【活跃】chinaLazy @YIN spin_lock 的时候需要锁住内存总线，然后访问并修改数据，所以必须关闭中断，否则中断插入的话，嘿嘿，x86上是这样，其他的不知道，

x86上的确是有lock指令，它主要是把lock修饰的那条指令变成原子指令，所谓原子指令，其实就是中断也无法插入的，因此，spinlock不是一定要关闭中断的。

u-boot启动流程分析(1)_平台相关部分

Thu, 19 May 2016 22:38:06 +0800

本文将结合u-boot的“board—>machine—>arch—>cpu”框架，介绍u-boot中平台相关部分的启动流程。并通过对启动流程的简单分析，掌握u-boot移植的基本方法。注1：本文所使用的u-boot版本，是2016/4/23从u-boot官网（git://git.denx.de/u-boot.git）导入的一个快照，具体可参考“ https://github.com/wowot

玩转BLE(2)_使用bluepy扫描BLE的广播数据

Thu, 19 May 2016 15:17:18 +0800

在linux平台下，bluez是一个很不错的软件，提供了很多基于命令行的测试工具，如hciconfig、hcitool、hcidump、bluetoothctl等。利用这些工具，我们可以方便的测试、demo各种蓝牙功能。例如，在“ 玩转BLE(1)_Eddystone beacon ”中，我们利用hcitool命令，演示了将手机变成一个Beacon设备的神奇效果。 Beacon的演示，从本质上看，

外设的寄存器是否映射到了物理内存中？还是有独立的内存空间？

Thu, 19 May 2016 11:35:36 +0800

本文是原「蜗窝讨论区」的历史存档（2016-05-19），来自版块「Linux kernel技术问答」，共 5 帖。讨论区已停止服务，此处仅供查阅。

peter · 2016-05-19 11:35

SOC处理器中外设的寄存器是否映射到了物理内存中？也就是说在系统跑起来后，通过free看到的物理内存小于真正的物理内存大小，其中有一部分分配给了外设的寄存器？

Codingbelief · 2016-05-19 16:42

> SOC处理器中外设的寄存器是否映射到了物理内存中？ SOC处理器有其物理地址空间，SOC 会为外设和物理内存分配不同的物理地址区域，这部分内容会在 SOC 的 Datasheet 中描述。在内核中，则会将这些不同的物理地址区域，映射到虚拟地址空间。最后，内核再通过虚拟地址访问到内存和外设。 ** > 也就是说在系统跑起来后，通过free看到的物理内存小于真正的物理内存大小，其中有一部分分配给了外设的寄存器？** free看到的物理内存小于真正的物理内存大小，应该是由于部分物理内存没有映射到内核，保留给其他模块使用（例如 GPU、TEE、Camera 等）。外设的寄存器不会占用物理内存，会占用虚拟地址空间。

wowo · 2016-05-19 16:43

Codingbelief 写道： > SOC处理器中外设的寄存器是否映射到了物理内存中？ SOC处理器有其物理地址空间，SOC 会为外设和物理内存分配不同的物理地址区域，这部分内容会在 SOC 的 Datasheet 中描述。在内核中，则会将这些不同的物理地址区域，映射到虚拟地址空间。最后，内核再通过虚拟地址访问到内存和外设。 ** > 也就是说在系统跑起来后，通过free看到的物理内存小于真正的物理内存大小，其中有一部分分配给了外设的寄存器？** free看到的物理内存小于真正的物理内存大小，应该是由于部分物理内存没有映射到内核，保留给其他模块使用（例如 GPU、TEE、Camera 等）。外设的寄存器不会占用物理内存，会占用虚拟地址空间。

正解。

wowo · 2016-05-19 16:44

我多补充一些信息：

kernel启动后，通过free或者cat /proc/meminfo，看到的Total memory，并不是真实的memory大小。因为在kernel睁开眼，看到memory之前，有些memory已经被“吃掉（reserved）”了。 reserved的memory主要有三类，以ARM64为例（可参考arm64_memblock_init，使用的内核版本是4.0.5） memblock_reserve(__pa(_text), _end - _text); / kernel image的代码段 / early_init_fdt_scan_reserved_mem(; / 命令行或者DTS中明确指明的 / dma_contiguous_reserve(arm64_dma_phys_limit); / 连续内存 /

以我手上一个树莓派为例，修改/boot/cmdline.txt，增加“memblock=debug”后启动，如下： dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait memblock=debug

可以看到相应的reserved的信息： [ 0.000000] Machine model: Raspberry Pi 2 Model B Rev 1.1 [ 0.000000] memblock_reserve: [0x00000000008240-0x0000000093f79b] flags 0x0 memblock_reserve+0x18/0x1c [ 0.000000] memblock_reserve: [0x00000000004000-0x00000000007fff] flags 0x0 memblock_reserve+0x18/0x1c [ 0.000000] memblock_reserve: [0x0000003afecb00-0x0000003afeffab] flags 0x0 memblock_reserve+0x18/0x1c [ 0.000000] memblock_reserve: [0x0000003a400000-0x0000003abfffff] flags 0x0 memblock_alloc_range_nid+0x74/0x88 [ 0.000000] cma: Reserved 8 MiB at 0x3a400000 [ 0.000000] MEMBLOCK configuration: [ 0.000000] memory size = 0x3b000000 reserved size = 0x113ea08 [ 0.000000] memory.cnt = 0x1 [ 0.000000] memory[0x0] [0x00000000000000-0x0000003affffff], 0x3b000000 bytes flags: 0x0 [ 0.000000] reserved.cnt = 0x4 [ 0.000000] reserved[0x0] [0x00000000004000-0x00000000007fff], 0x4000 bytes flags: 0x0 [ 0.000000] reserved[0x1] [0x00000000008240-0x0000000093f79b], 0x93755c bytes flags: 0x0 [ 0.000000] reserved[0x2] [0x0000003a400000-0x0000003abfffff], 0x800000 bytes flags: 0x0 [ 0.000000] reserved[0x3] [0x0000003afecb00-0x0000003afeffab], 0x34ac bytes flags: 0x0 [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] memblock_reserve: [0x0000003affffd8-0x0000003affffff] flags 0x0 memblock_alloc_range_nid+0x74/0x88 [ 0.000000] memblock_reserve: [0x0000003affe000-0x0000003affefff] flags 0x0 memblock_alloc_range_nid+0x74/0x88 [ 0.000000] memblock_reserve: [0x0000003affd000-0x0000003affdfff] flags 0x0 memblock_alloc_range_nid+0x74/0x88 [ 0.000000] memblock_reserve: [0x0000003affc000-0x0000003affcfff] flags 0x0 memblock_alloc_range_nid+0x74/0x88 [ 0.000000] memblock_reserve: [0x0000003affb000-0x0000003affbfff] flags 0x0 memblock_alloc_range_nid+0x74/0x88 [ 0.000000] memblock_reserve: [0x0000003aff8000-0x0000003aff9fff] flags 0x0 memblock_alloc_range_nid+0x74/0x88 [ 0.000000] memblock_reserve: [0x0000003affa000-0x0000003affafff] flags 0x0 memblock_alloc_range_nid+0x74/0x88 [ 0.000000] memblock_reserve: [0x0000003afffe48-0x0000003affffd7] flags 0x0 memblock_alloc_range_nid+0x74/0x88 [ 0.000000] memblock_reserve: [0x0000003aff7000-0x0000003aff7fff] flags 0x0 memblock_alloc_range_nid+0x74/0x88 [ 0.000000] memblock_reserve: [0x0000003aff6000-0x0000003aff6fff] flags 0x0 memblock_alloc_range_nid+0x74/0x88 [ 0.000000] memblock_reserve: [0x0000003aff5000-0x0000003aff5fff] flags 0x0 memblock_alloc_range_nid+0x74/0x88 [ 0.000000] memblock_reserve: [0x0000003aff4000-0x0000003aff4fff] flags 0x0 memblock_alloc_range_nid+0x74/0x88 [ 0.000000] memblock_reserve: [0x0000003aff3000-0x0000003aff3fff] flags 0x0 memblock_alloc_range_nid+0x74/0x88 [ 0.000000] memblock_reserve: [0x0000003aff2000-0x0000003aff2fff] flags 0x0 memblock_alloc_range_nid+0x74/0x88 [ 0.000000] On node 0 totalpages: 241664 [ 0.000000] memblock_virt_alloc_try_nid_nopanic: 8699904 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 alloc_node_mem_map.constprop.7+0x7c/0xa4 [ 0.000000] memblock_reserve: [0x00000039bb4000-0x0000003a3fffff] flags 0x0 memblock_virt_alloc_internal+0x154/0x190 [ 0.000000] free_area_init_node: node 0, pgdat 80876f80, node_mem_map b9bb4000 [ 0.000000] Normal zone: 2124 pages used for memmap [ 0.000000] Normal zone: 0 pages reserved [ 0.000000] Normal zone: 241664 pages, LIFO batch:31 [ 0.000000] memblock_virt_alloc_try_nid_nopanic: 120 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 free_area_init_node+0x2bc/0x358 [ 0.000000] memblock_reserve: [0x0000003afffdc0-0x0000003afffe37] flags 0x0 memblock_virt_alloc_internal+0x154/0x190 [ 0.000000] memblock_virt_alloc_try_nid_nopanic: 12288 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 zone_wait_table_init+0x88/0xf4 [ 0.000000] memblock_reserve: [0x0000003afe9b00-0x0000003afecaff] flags 0x0 memblock_virt_alloc_internal+0x154/0x190 [ 0.000000] memblock_virt_alloc_try_nid: 28 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 setup_arch+0x5f8/0x934 [ 0.000000] memblock_reserve: [0x0000003afffd80-0x0000003afffd9b] flags 0x0 memblock_virt_alloc_internal+0x154/0x190 [ 0.000000] memblock_reserve: [0x0000003afe12dc-0x0000003afe9aff] flags 0x0 memblock_alloc_range_nid+0x74/0x88 [ 0.000000] memblock_reserve: [0x0000003afffda4-0x0000003afffdbe] flags 0x0 memblock_alloc_range_nid+0x74/0x88 [ 0.000000] memblock_reserve: [0x0000003afffd64-0x0000003afffd7e] flags 0x0 memblock_alloc_range_nid+0x74/0x88 [ 0.000000] memblock_reserve: [0x0000003afffd48-0x0000003afffd60] flags 0x0 memblock_alloc_range_nid+0x74/0x88 [ 0.000000] memblock_reserve: [0x0000003afffd30-0x0000003afffd47] flags 0x0 memblock_alloc_range_nid+0x74/0x88 [ 0.000000] memblock_reserve: [0x0000003afffd18-0x0000003afffd2f] flags 0x0 memblock_alloc_range_nid+0x74/0x88 [ 0.000000] memblock_reserve: [0x0000003afffcfc-0x0000003afffd14] flags 0x0 memblock_alloc_range_nid+0x74/0x88 [ 0.000000] memblock_reserve: [0x0000003afffce4-0x0000003afffcfb] flags 0x0 memblock_alloc_range_nid+0x74/0x88 [ 0.000000] memblock_reserve: [0x0000003afffccc-0x0000003afffce3] flags 0x0 memblock_alloc_range_nid+0x74/0x88 [ 0.000000] [bcm2709_smp_init_cpus] enter (9420->f3003010) [ 0.000000] [bcm2709_smp_init_cpus] ncores=4 [ 0.000000] memblock_virt_alloc_try_nid: 462 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 start_kernel+0xdc/0x3dc [ 0.000000] memblock_reserve: [0x0000003afffac0-0x0000003afffc8d] flags 0x0 memblock_virt_alloc_internal+0x154/0x190 [ 0.000000] memblock_virt_alloc_try_nid: 462 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 start_kernel+0x100/0x3dc [ 0.000000] memblock_reserve: [0x0000003afff8c0-0x0000003afffa8d] flags 0x0 memblock_virt_alloc_internal+0x154/0x190 [ 0.000000] memblock_virt_alloc_try_nid: 462 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 start_kernel+0x124/0x3dc [ 0.000000] memblock_reserve: [0x0000003afff6c0-0x0000003afff88d] flags 0x0 memblock_virt_alloc_internal+0x154/0x190 [ 0.000000] memblock_virt_alloc_try_nid_nopanic: 4096 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 pcpu_alloc_alloc_info+0x54/0x90 [ 0.000000] memblock_reserve: [0x0000003aff1000-0x0000003aff1fff] flags 0x0 memblock_virt_alloc_internal+0x154/0x190 [ 0.000000] memblock_virt_alloc_try_nid_nopanic: 4096 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 pcpu_embed_first_chunk+0x510/0x7bc [ 0.000000] memblock_reserve: [0x0000003aff0000-0x0000003aff0fff] flags 0x0 memblock_virt_alloc_internal+0x154/0x190 [ 0.000000] memblock_virt_alloc_try_nid_nopanic: 196608 bytes align=0x1000 nid=-1 from=0x7fffffff max_addr=0x0 pcpu_dfl_fc_alloc+0x2c/0x34 [ 0.000000] memblock_reserve: [0x0000003afb1000-0x0000003afe0fff] flags 0x0 memblock_virt_alloc_internal+0x154/0x190 [ 0.000000] __memblock_free_early: [0x0000003afbd000-0x0000003afbcfff] pcpu_dfl_fc_free+0x14/0x18 [ 0.000000] __memblock_free_early: [0x0000003afc9000-0x0000003afc8fff] pcpu_dfl_fc_free+0x14/0x18 [ 0.000000] __memblock_free_early: [0x0000003afd5000-0x0000003afd4fff] pcpu_dfl_fc_free+0x14/0x18 [ 0.000000] __memblock_free_early: [0x0000003afe1000-0x0000003afe0fff] pcpu_dfl_fc_free+0x14/0x18 [ 0.000000] PERCPU: Embedded 12 pages/cpu @bafb1000 s20416 r8192 d20544 u49152 [ 0.000000] memblock_virt_alloc_try_nid: 4 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 pcpu_setup_first_chunk+0x32c/0xa20 [ 0.000000] memblock_reserve: [0x0000003afffe40-0x0000003afffe43] flags 0x0 memblock_virt_alloc_internal+0x154/0x190 [ 0.000000] memblock_virt_alloc_try_nid: 4 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 pcpu_setup_first_chunk+0x34c/0xa20 [ 0.000000] memblock_reserve: [0x0000003afffcc0-0x0000003afffcc3] flags 0x0 memblock_virt_alloc_internal+0x154/0x190 [ 0.000000] memblock_virt_alloc_try_nid: 16 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 pcpu_setup_first_chunk+0x36c/0xa20 [ 0.000000] memblock_reserve: [0x0000003afff680-0x0000003afff68f] flags 0x0 memblock_virt_alloc_internal+0x154/0x190 [ 0.000000] memblock_virt_alloc_try_nid: 16 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 pcpu_setup_first_chunk+0x38c/0xa20 [ 0.000000] memblock_reserve: [0x0000003afff640-0x0000003afff64f] flags 0x0 memblock_virt_alloc_internal+0x154/0x190 [ 0.000000] pcpu-alloc: s20416 r8192 d20544 u49152 alloc=12*4096 [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [ 0.000000] memblock_virt_alloc_try_nid: 120 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 pcpu_setup_first_chunk+0x784/0xa20 [ 0.000000] memblock_reserve: [0x0000003afff5c0-0x0000003afff637] flags 0x0 memblock_virt_alloc_internal+0x154/0x190 [ 0.000000] memblock_virt_alloc_try_nid: 68 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 pcpu_setup_first_chunk+0x7cc/0xa20 [ 0.000000] memblock_reserve: [0x0000003afff540-0x0000003afff583] flags 0x0 memblock_virt_alloc_internal+0x154/0x190 [ 0.000000] memblock_virt_alloc_try_nid: 68 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 pcpu_setup_first_chunk+0x910/0xa20 [ 0.000000] memblock_reserve: [0x0000003afff4c0-0x0000003afff503] flags 0x0 memblock_virt_alloc_internal+0x154/0x190 [ 0.000000] __memblock_free_early: [0x0000003aff1000-0x0000003aff1fff] pcpu_free_alloc_info+0x1c/0x20 [ 0.000000] __memblock_free_early: [0x0000003aff0000-0x0000003aff0fff] pcpu_embed_first_chunk+0x7a4/0x7bc [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 239540 [ 0.000000] Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2709.boardrev=0xa21041 bcm2709.serial=0xcfed5978 smsc95xx.macaddr=B8:27:EB:ED:59:78 bcm2708_fb.fbswap=1 bcm2709.uart_clock=3000000 bcm2709.disk_led_gpio=47 bcm2709.disk_led_active_low=0 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait memblock=debug [ 0.000000] memblock_virt_alloc_try_nid_nopanic: 16384 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 alloc_large_system_hash+0x158/0x25c [ 0.000000] memblock_reserve: [0x0000003afad000-0x0000003afb0fff] flags 0x0 memblock_virt_alloc_internal+0x154/0x190 [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes) [ 0.000000] memblock_virt_alloc_try_nid_nopanic: 524288 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 alloc_large_system_hash+0x158/0x25c [ 0.000000] memblock_reserve: [0x0000003af2d000-0x0000003afacfff] flags 0x0 memblock_virt_alloc_internal+0x154/0x190 [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 0.000000] memblock_virt_alloc_try_nid_nopanic: 262144 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 alloc_large_system_hash+0x158/0x25c [ 0.000000] memblock_reserve: [0x0000003aeed000-0x0000003af2cfff] flags 0x0 memblock_virt_alloc_internal+0x154/0x190 [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Memory: 939420K/966656K available (6024K kernel code, 534K rwdata, 1660K rodata, 448K init, 757K bss, 19044K reserved, 8192K cma-reserved)

arm体系下的cpu_relax()函数疑惑

Wed, 18 May 2016 16:23:06 +0800

本文是原「蜗窝讨论区」的历史存档（2016-05-18），来自版块「Linux kernel技术问答」，共 4 帖。讨论区已停止服务，此处仅供查阅。

pgalxx · 2016-05-18 16:23

在看代码过程中经常有遇到cpu_relax（）函数，记得是cpu 忙等的语句，不过今天查看了下，发现kernel/arch/arm/include/asm下面的process.h文件对其的定义如下：

if LINUX_ARM_ARCH == 6 || defined(CONFIG_ARM_ERRATA_754327)

define cpu_relax( smp_mb(

else

define cpu_relax( barrier(

endif

定义除了arm 6和ERRATA_754327外 cpu_relax(定义为barrier(函数，而barrier(应该是避免gcc 对code的优化，保证每次去内存读取对应的值，这和忙等待有啥关系呢？比较疑惑，不知我的理解是否正确呢？

linuxer · 2016-05-18 19:07

的确，cpu_relax是用于busy loop的场景，代码示例如下： flag ＝ 0； while （flag == 0) { cpu_relax(; } 程序逻辑很奇怪，当然它实际上是期待其他的thread会修改flag这个全局变量，从而解除本cpu的忙等待状态。 cpu_relax必须具备两个功能： 1、确保对flag的访问每次都从memory中加载，也就是barrier(函数的作用 2、通知底层CPU，目前代码没有在做什么实际有意义的事情，如果可以的话，别让cpu做太多事情，系统的资源尽量让给其他的cpu。当然，由于ARMv8之前的CPU不支持上面的第二个功能，因此你看到的cpu_relax(就是barrier(。如果有兴趣看看ARM64的代码，你会有新的发现： static inline void cpu_relax(void) { asm volatile("yield" ::: "memory"); }

在这里，嵌入式汇编中的clobber list没有描述汇编代码对寄存器的修改情况，只是有一个memory的标记。我们知道，clober list是gcc和gas的接口，用于gas通知gcc它对寄存器和memory的修改情况。因此，这里的memory就是告知gcc，在汇编代码中，我修改了memory中的内容，cpu_relax之前的c代码块和cpu_relax之后的c代码块看到的memory是不一样的，对memory的访问不能依赖于嵌入式汇编之前的c代码块中寄存器的内容，需要重新加载，这也就是Optimization barrier的功能。而嵌入式汇编中的yield指令则完成了cpu_relax的第二个功能，即让CPU 松弛下来，降低功耗，把资源配置给其他thread等。

pgalxx · 2016-05-18 23:43

非常感谢linuxer的精辟答复哈！

上海-云 · 2016-05-20 10:22

linuxer的解释很nice

感谢。

ARMv8之memory model

Wed, 18 May 2016 12:09:13 +0800

从阅读ARMv8手册的第一天起，我就饱受memory order、memory barrier、coherent、consistency等概念的残害，各种痛苦，各种迷茫，各种试图放弃，各种欲罢不能……，现在，终于收拾心情，再次出发，希望这次能把近期关于ARMv8上的memory model相关的知识点整理出来，让自己更清楚一些，也顺便希望能够和大家一起探讨。本文主要关注shared-memor

【电源管理】一个中断wakeup system相关的问题

Mon, 16 May 2016 11:49:13 +0800

本文是原「蜗窝讨论区」的历史存档（2016-05-16），来自版块「Linux kernel技术问答」，共 5 帖。讨论区已停止服务，此处仅供查阅。

时间为贵 · 2016-05-16 11:49

最近有个问题比较疑惑：如果某个driver希望自己的device具备wakeup system的能力，除掉电气特性上具备该能力外，是否还需要同时具备下列两个条件： 1. request_irq时加入IRQF_NO_SUSPEND flag; 2. 调用enable_irq_wake接口。还是说只要其中一个满足就可以？我看了下基本上所有的driver都会同时调用这两个接口，那么如果必须上述两个条件都成立，是否可以理解为： a. IRQF_NO_SUSPEND控制着request line和irq controller之间的联系； b. enable_irq_wake控制着irq controller和CPU之间的联系。（local_irq_disable断掉的是irq controller和CPU之间的联系么？）对硬件不了解，想了好久，瞅代码也没瞅太明白啊，各位解惑~~

wowo · 2016-05-16 13:14

时间为贵写道： 最近有个问题比较疑惑：如果某个driver希望自己的device具备wakeup system的能力，除掉电气特性上具备该能力外，是否还需要同时具备下列两个条件： 1. request_irq时加入IRQF_NO_SUSPEND flag; 2. 调用enable_irq_wake接口。还是说只要其中一个满足就可以？我看了下基本上所有的driver都会同时调用这两个接口，那么如果必须上述两个条件都成立，是否可以理解为： a. IRQF_NO_SUSPEND控制着request line和irq controller之间的联系； b. enable_irq_wake控制着irq controller和CPU之间的联系。（local_irq_disable断掉的是irq controller和CPU之间的联系么？）对硬件不了解，想了好久，瞅代码也没瞅太明白啊，各位解惑~~

这两个方法，做的是同一件事情，都是控制“request line和irq controller之间的联系”。 IRQF_NO_SUSPEND是旧方法； enable_irq_wake是新方法。之所以所有的driver都调用这两个接口，有两种可能：一是为兼容；而是不太理解，为保险起见，都调用。

“irq controller和CPU之间的联系”是由local_irq_disable控制。

时间为贵 · 2016-05-16 13:51

wowo 写道：

时间为贵写道： 最近有个问题比较疑惑：如果某个driver希望自己的device具备wakeup system的能力，除掉电气特性上具备该能力外，是否还需要同时具备下列两个条件： 1. request_irq时加入IRQF_NO_SUSPEND flag; 2. 调用enable_irq_wake接口。还是说只要其中一个满足就可以？我看了下基本上所有的driver都会同时调用这两个接口，那么如果必须上述两个条件都成立，是否可以理解为： a. IRQF_NO_SUSPEND控制着request line和irq controller之间的联系； b. enable_irq_wake控制着irq controller和CPU之间的联系。（local_irq_disable断掉的是irq controller和CPU之间的联系么？）对硬件不了解，想了好久，瞅代码也没瞅太明白啊，各位解惑~~

“irq controller和CPU之间的联系”是由local_irq_disable控制。

如果IRQF_NO_SUSPEND和enable_irq_wake的作用都是保留“request line”到“irq controller”之间的联系而local_irq_disable是断开“irq controller”到“CPU”之间的联系的话，那么在system suspend过程中，最后阶段在disable noboot cpus后会调用arch_suspend_disable_irqs-->local_irq_disable(,这不是一样断开了和cpu的联系了么，那cpu还如何感知wakeup source产生的irq呢？看linuxer曾说过controller和CPU之间除了irq/fiq还有wakeup信号，此时是controller只对CPU传递wakeup信号，直到cpu local_irq_enable后响应对应irq的handler吗？

4G模块移值问题基于Freescale I.mx6Q android 5.1.1 平台

Sat, 14 May 2016 10:58:57 +0800

本文是原「蜗窝讨论区」的历史存档（2016-05-14），来自版块「灌水区」，共 3 帖。讨论区已停止服务，此处仅供查阅。

hangkeke052 · 2016-05-14 10:58

第一帖没想到就是求助贴！求助各位大牛！！问题背景介绍：兄弟部门集成的4G (Qualcomm MDM9x07 + WTR2965 经过一组usb线连接到主芯片I.mx6Q上。最终目标是在android5.1.1上实现 4G模块上网、GPS 功能目前项目进展：前期调试4G模块外部线路、上电时序，可以通过lsusb命令侦测到该usb设备。通过修改kernel/driver/usb/serial/option.c 中的VID/PID 成功识别出来 /dev/ttyUSB0 -- ttyUSB4五个端口其中分别是Diagnostic adb AT NMEA QMI/wwan 接口，目前可以通过pppd call &gprs 上网（打开的是AT command 这个端口）。问题详情描述：由于我们这个模块的提供者是兄弟部门（主要业务是某品牌windows pc 的无线网卡），无法像zte huawei gemalto 提供完整的android开发文档，以及RIL 层的porting 代码。所以目前需要自定义修改RIL 层代码，其它厂商的文档看了不少感觉无从下手，进度陷入停滞状态。想请教各位大牛，实现我移植的目的，我一步步应该怎么走？如果有Qualcomm的参考代码，那更是感谢！！

wowo · 2016-05-16 13:15

这个问题不太好回答啊，等于是问怎么写一个RIL。我没有相关经验，帮顶吧，看看有没有人做过。

hangkeke052 · 2016-05-16 16:09

十分感谢wowo大神，的确是问题提的很大。问题的初衷就是没有任何support，想跟做过这方面的前辈寻求下指导！

wowo 写道： 这个问题不太好回答啊，等于是问怎么写一个RIL。我没有相关经验，帮顶吧，看看有没有人做过。

ARMv8之Atomicity

Fri, 13 May 2016 19:18:37 +0800

本文主要解析ARMv8手册中的Atomicity这个概念。首先给出为何定义这样的概念，定义这个概念的作用为何？然后介绍Atomicity相关的概念，很多时候我们引用了手册的原文，但是由于这些原文象天书一样难懂（可读性比较差），因此，我们使用程序员可理解的一些语言来描述这些概念。最后给出 ARMv8上，各种内存操作指令，针对各种memory type，其Atomicity的特性为何。

X-002-HW-S900芯片boot from USB有关的硬件描述

Thu, 12 May 2016 22:01:18 +0800

本文将以S900芯片 [1] 为例，介绍和“ 【任务1】启动过程-Boot from USB ” 有关的硬件行为。其它人可以借鉴该文档，描述自己所使用平台的硬件特性，以完成该任务。为了方便操作，这里以“填空题”的形式，给出我们关心的key point，只要我们能够把这些填空题完成，就可以放心的去coding了。题目如下： 1）CPU上电后，从哪种设备（）的哪个地址（）开始执行。 2）用

迷茫的程序员

Sun, 08 May 2016 19:16:46 +0800

本文是原「蜗窝讨论区」的历史存档（2016-05-08），来自版块「灌水区」，共 15 帖。讨论区已停止服务，此处仅供查阅。

cuixiaolei · 2016-05-08 19:16

这篇帖子写的可能比较长而且很随意，希望@wowo和@linuxer能够看到和看完，希望能得到你们的帮助。

我是15年6月毕业的学生，电子信息工程专业出身，一个普通的二本院校，到现在工作已经快有一年了。我从大一开始做技术，大一学的C，参加了很多C的比赛，大二开始做单片机，从51开始，用51做过很多小东西，然后玩了飞思卡尔/stm32等单片机，大三的时候参加电子设计大赛，那年是四轴飞行器，省一等奖。我大学的时候想毕业了就做控制类的工作，快到大四的时候不想做单片机了，想做嵌入式，那时候只听学长说过嵌入式、linux之类的，大三下学期自己学了linux，用了实验室的2440，只停留在把系统烧进去，然后跑uboot，觉的很神奇。我特别喜欢技术，经常会因为自己做的东西而激动的睡不着。大三下学期我着手找工作，在学校的时候联系了南京的公司，大三考完试我拿着我的简历和证书去了南京，到了一家刚刚成立的创业公司，当时就老板，我，和我一起的同学三个人。公司是做路边停车场的。老板特别好，是一家上市公司的技术经理出来创业的，在公司做的是a20，负责把社区做好的系统移植到板子上，然后学的python，在开发板上做各种实验，公司小，需要什么我就要去学什么，然后做什么，学了php，html5，然后用html做的android和ios应用。整个大四都在这家公司做，一年学的特别杂，但是很充实，学了很多东西，对物联网的整条线了解了一些，毕业设计也做的物联网相关的。毕业以后留在了这家公司，但是工作了两个月后，很不幸，公司倒闭了。倒闭的时候我正在做ios应用，那半年我一直在做应用。我去找工作，找的是android和ios应用开发，没办法，别的都是了解，很久没看了，只知道理念了。机缘巧合，我去了一家做手机的外包公司做android驱动。 15年9月初，去了新公司，我带着很大的激情，要努力，要使劲学习的这股劲到了新公司。但是去了公司我很快就迷茫了，前三个月我坐在那没人管没人问，也没人告诉我要做什么。我就想啊，我不能闲着啊，就上网百度android驱动相关的技术和内容，去买了很多书，给自己定了计划，多长时间把什么内容搞定，多长时间要达到什么水平。学习的过程中慢慢觉的android驱动好复杂，有时候根本都无从下手。过了两个多月以后心里很虚，感觉什么都不会，代码自己没有敲过几行，运行机制不知道是什么样的，只是知道android分为几块，每块干嘛的，大概啥样的，一道具体的就不知道了。看代码会看到很多函数，函数压根就不知道是干什么的，函数要不要往下去深追，深追到什么程度，到最后都是寄存器的地址，也不知道这些寄存器的地址是干什么的，厂商也不给数据手册。对问题我很想弄清楚，比如在看A问题，A问题需要用到B和C知识，B又需要用到B1和B2知识，C需要用到C1和C2知识，我想把这些东西都弄清楚，这样心里才会舒服，才会踏实，如果只把A问解决了，弄清楚了，但是心里还是有个疙瘩，心里很多为什么。延伸出来的东西我不知道哪些是重点，哪些需要我去弄清楚，越看越多，越看越复杂，越看越受打击，各种挫败感。每天想把某个东西弄清楚，但是又弄不清楚，对android或者linux，只能看代码，没有自己去动手写，很多都看不懂，自己又想弄清楚。这样的生活特别煎熬，自己特别想把东西弄清楚，但是自己又弄不清楚，一身的劲没处使的感觉。每天晚上会反思自己哪里不对，为什么会这样，接下来该看什么，该做什么才行，晚上会睡不着觉，很无奈。我经常找公司工作了很多年的工程师聊天，他们告诉我说不必深究，有些东西本身就很难，知道在什么地方改哪些东西会有哪些效果就行了。我是做单片机出身的，从电路图到硬件的搭建再到程序的编写自己非常清楚，心里做的也特别顺和开心。在什么地方改什么这样的方式压根就不能说服我，我总是想把东西弄清楚，晚上睡觉的时候才会很开心。做android驱动已经七个月了，这七个月我过的很煎熬，自己没有学到什么东西，特别没有安全感，我总结的是下面几个原因： 1.自己没有敲代码，心里感觉少点什么，没有安全感。 2.自己想把问题和问题延伸知识都弄清楚 3.觉的现在学的特别虚，什么都会，但是什么都不精

我知道linuxer和wowo很厉害，都是从我这个阶段过去的，想请你们看看我的问题出在什么地方，我也给自己列了知识路线，在坚持写技术博客，希望你们能看看我到底怎么了。

cuixiaolei · 2016-05-08 19:19

http://naotu.baidu.com/file/fb17f67f5034c063b63874f5418fa9fd?token=618060eb452f9f2f 这个是我给自己定的学习路线。

wowo · 2016-05-08 20:13

我觉得你是一个不错的人、不错的工程师，有想法，有上进心，喜欢刨根问底，不喜欢黑箱子，这一切都是成为一个优秀而快乐的工程师的必要条件。而你最大的问题，可能就是心急了点，迫不及待的想把自己变成自己所向往的哪种人，殊不知这是需要时间的。你现在应该做的，就是快速而又高质量的完成领导交给你的、在你能力范围内的工作。从不求甚解，到有一点点自己的想法，再到有建设性的想法，能力就在不知不觉中增强了。当然，你提到的三个原因，我的看法如下：

cuixiaolei 写道： 1.自己没有敲代码，心里感觉少点什么，没有安全感。

刚工作的人，很少能有机会自己写代码的。你能做的，就是等待。在等待的过程中，多看、多想，以确保机会到来的时候，你写出（或者模仿出）高质量的代码。

cuixiaolei 写道： 2.自己想把问题和问题延伸知识都弄清楚

我的建议是，不要太着急，不要给自己太大的压力。你没有做过那么多东西，没有那么多积累，试图去“延伸”，是非常困难的。最好顺其自然，让自己在技术的路上，多开心一些，后面有的是机会。

cuixiaolei 写道： 3.觉的现在学的特别虚，什么都会，但是什么都不精

不要试图大网撒鱼，把学习的面变小，甚至变成一个点，然后在某一个点上深入。这可以给自己一些自信，减少一些迷茫。

cuixiaolei · 2016-05-08 20:35

谢谢，我对思考你给予的答复。

linuxer · 2016-05-09 00:05

其实在目前的中国，大部分的驱动程序员都是这样度过的，对驱动不求甚解，能work就OK了，有原厂代码，自己不需要写代码，只需要调试驱动。我认识的三星的驱动工程师，根本没有写过自己的一行代码，没有写过任何的设计文档，但仍然愉快的工作着，呵呵~~~~你的烦恼主要来自你的思考，对未知世界强烈的好奇心，对任何技术细节刨根问底的精神头，这也是蜗窝科技希望能够汇聚的那些工程师的特质。不要怀疑这些特质，这些都是成为一个优秀工程师必须有具备的特征。当然，在我看来，你的问题主要是在短时间内把“网”撒的太“广”了： 1、为何要学习那么多的编程语言？坦率的讲，编程语言我除了c之外，其他的都不会，我也从来不试图去学习其他的编程语言。如果C++还略知一二，那么Java、PHP、python......我更是一窍不通。 2.Android是一个庞然大物，不要试图把每一件事情搞清楚。人的一生非常的有限，就算是linux内核，你也不太可能全部吃透，也许一个简单的RCU子系统就足够研究一辈子了，当然，这是指深入的研究。如果你有足够的兴趣，想将大部分的内核子系统通读一遍，了解其基本的运作逻辑，那么也是需要4~5年的时间（我曾经有两年的时间，每天花12小时来阅读内核代码（2.4版本），浏览了60%的内核代码，考虑现在内核的复杂度，如果你能投入同样的时间，我推断是需要4~5年的时间）。而对于Android，坦率的讲，我也是一无所知，也就是知道这个名词，呵呵~~~~

一句话总结：对于我们这类属于“打破砂锅问到底”的工程师，不要搞太广的技术，会把自己逼死的，呵呵~~~最好focus在某一个狭窄的技术领域，这样才能让自己快乐的技术中徜徉。

最后，顺便说一句，也许现在你不太能理解：其实当你focus在一个狭窄的技术领域，对其比较精通的时候，你就会发现，其实所有的技术都是相通的，你有能力深入的理解了linux内核的进程调度系统，你也有能力设计出一个非常优秀的SOC上的图形系统。唯一不同的是在你人生的分叉点上，你选择了做软件工程师，选择了做linux kernel，如果时间可以倒转，回到你职业规划的那个时间点，你选择了IC设计行业，你也一样可以出类拔萃（当然，前提是你足够优秀）。

Codingbelief · 2016-05-10 23:36

看到上面“随意”写出的“较长”文字，我觉得我应该过来灌灌水 ~~

没有安全感是好事，有求知欲是好事，会去总结是好事。所以啦，稍微努力一点点就好了，不用太纠结。

我也没有特别好的建议，就自顾自的写点东西吧~~

工作效率不管做什么工作，尽可能的提高自己的工作效率。效率高了，你就会有盈余的时间，再利用这个时间，去深挖工作相关的内容。慢慢就会形成良性循环，效率会越来越高。到某一个阶段时，可能你半天就可以把一般人需要一整天处理的工作量完成了，接着剩下的时间你就想整什么整什么去了。至于提高效率，动动脑筋应该可以想到很多。减少重复的劳动，别犯同样的错误，坚持总结反思之类的。
阅读与软件设计上面你说到没敲代码，没有安全感，我倒是觉得不懂“敲代码”，不能优雅的“敲代码”才是真正危险的。不要纠结代码量有多少，更多的去关注设计，关注架构，关注美。@Linuxer 之所以是 @Linuxer 肯定不是因为他敲了很多代码 ~~ 更多的去阅读好的代码，去阅读经典的书籍，然后多思考，一定会让你更有安全感。

3 关于技术重点对于 @linuxer 的观点：最好focus在某一个狭窄的技术领域，这样才能让自己快乐的技术中徜徉，我倒是有不一样的想法。我自己本人对于各种新鲜的事物还是充满好奇的，我觉得稍微放纵下这些好奇，也是能收获很多快乐和有意思的经历的~~ 当然，精通一个技术领域是必须的，最现实的理由是：这可是决定你作为工程师的身价的最重要指标啊。所以，我的观点是，有趣的东西花点时间也无妨，但是必定要选择一个自己喜欢并且擅长的方向，下苦功夫。

电源管理中的pm_opp.h 问题

Fri, 06 May 2016 22:22:17 +0800

本文是原「蜗窝讨论区」的历史存档（2016-05-06），来自版块「Linux kernel技术问答」，共 2 帖。讨论区已停止服务，此处仅供查阅。

barrenlake · 2016-05-06 22:22

您好，请问，看了您的帖子，我的理解是CPU的所有可调节的频率及电压信息存在于opp中, 现在我想通过pm_opp.h中的接口来获取当前工作频率对应的工作电压，但是我在usr/include中找不到pm.opp.h，请问这个文件在什么地方（centos6.5(2.6)及 centos7.1(3.10)），我是否能通过频率获取对应电压

wowo · 2016-05-09 09:20

你是想从用户空间调用吗？我觉得不是一个可行的方案，因为需要传入struct device指针，在用户空间怎么传？如果想得到电压信息，还不如直接去看DTS文件。只要能找到系统的dtb文件，用dtc命令转成dts，查看一下OPP的table就可以了。

在sys/class/gpio调试引脚出错的问题

Fri, 06 May 2016 16:15:39 +0800

本文是原「蜗窝讨论区」的历史存档（2016-05-06），来自版块「Linux kernel技术问答」，共 2 帖。讨论区已停止服务，此处仅供查阅。

泽霖 · 2016-05-06 16:15

最近在做一个基于intel的sofia3g平台的linux3.10 android5.1的项目，要求将引脚50作为充电检测脚，发现无法读取gpio50引脚的状态报错，于是在sys/class/gpio下单独调试如下：

shell@Sf3g_mrd7_p1_v2:/sys/class/gpio # echo 50 > export [ 92.979279] pcs_vmm_read: mv_svc_pinctrl_service(PINCTRL_GET) failed at e46002c8 [ 92.987341] pcs_vmm_write: mv_svc_pinctrl_service(PINCTRL_SET) failed at e46002c8 [ 92.997696] xgold_gpio_to_irq: Can't bind gpio to interrupt

Pinctrl-single.c (drivers\pinctrl) 51939 2016-04-01 出错点： static void maybe_unused pcs_vmm_write(unsigned val, void __iomem *reg) { if (mv_svc_pinctrl_service(PINCTRL_SET, (uint32_t)reg, val, NULL)) { pr_err("%s: mv_svc_pinctrl_service(PINCTRL_SET) failed at %p\n", __func, reg); }

}

shell@Sf3g_mrd7_p1_v2:/sys/class/gpio # echo high > direction [ 92.987341]pcl_write: mv_svc_pinctrl_service(PINCTRL_SET) failed at e46002c8 出错点： static void maybe_unused pcs_vmm_write(unsigned val, void __iomem reg) { if (mv_svc_pinctrl_service(PINCTRL_GET, read_addr, 0, (uint32_t )&tmp)) gpio_err("%s: mv_svc_pinctrl_service(PINCTRL_GET) failed at 0x%pa\n", __func, &read_addr); }

Mv_svc_hypercalls.c (arch\x86\sofia) 14117 2016-04-01 uint32_t mv_svc_pinctrl_service( uint32_t opcode, uint32_t arg1, uint32_t arg2, uint32_t *arg3) { int ret = 0; switch (opcode) { case PINCTRL_OPEN: case PINCTRL_SET: case PINCTRL_CONFIG_FUNC: case PINCTRL_CLOSE: ret = mv_platform_service(PINCTRL_SERVICE, opcode, arg1, arg2, 0, 0, 0, 0, 0); break; case PINCTRL_GET: ret = mv_platform_service(PINCTRL_SERVICE, opcode, arg1, 0, 0, 0, 0, 0, arg3); break;

default:
 break;
}
return ret;

} Mv_hypercalls.c (arch\x86\sofia) 8025 2016-04-01 uint32_t mv_platform_service(uint32_t service_type, uint32_t arg2, uint32_t arg3, uint32_t arg4, uint32_t ret0, uint32_t ret1, uint32_t ret2, uint32_t ret3, uint32_t *ret4) { return mv_call_5(VMCALL_PLATFORM_SERVICE, service_type, arg2, arg3, arg4, ret0, ret1, ret2, ret3, ret4); }

static inline int mv_call_5(uint32_t nr, uint32_t arg0, uint32_t arg1, uint32_t arg2, uint32_t arg3, uint32_t ret0, uint32_t ret1, uint32_t ret2, uint32_t ret3, uint32_t *ret4) { uint32_t results[5];

mv_guest_trace_vmcall_entry(nr, arg0, arg1);
trace_vmcall_entry(current, nr, 0);
asm volatile (VMCALL_OPCODE:"=a"(results[0]), "=b"(results[1]),
 "=c"(results[2]), "=d"(results[3]), "=S"(results[4])
 : "a"(nr), "b"(arg0), "c"(arg1), "d"(arg2), "S"(arg3)
 : "memory");
trace_vmcall_exit(current, nr, 0);
mv_guest_trace_vmcall_exit(;
 if (ret0)
 *ret0 = results[0];
if (ret1)
 *ret1 = results[1];
if (ret2)
 *ret2 = results[2];
if (ret3)
 *ret3 = results[3];
if (ret4)
 *ret4 = results[4];
return results[0];

}

【任务1】启动过程-Boot from USB

Thu, 05 May 2016 22:32:03 +0800

本文是原「蜗窝讨论区」的历史存档（2016-05-05），来自版块「X Project」，共 29 帖。讨论区已停止服务，此处仅供查阅。

wowo · 2016-05-05 22:32

任务说明

该任务是“X Project”第一个任务，也是所有嵌入式开发启动时遇到的第一个任务。

在ARM等嵌入式平台中，CPU上电后，会从固定地址运行Rom code（或者其它类型的介质，我们不再特意区分）。如果没有有效的启动介质，或者使用特殊手段，ROM code会执行一个称作DFU（Device Firmware Upgrade）的程序，该程序可以通过USB/UART等协议，和PC沟通，将PC上指定的Bin文件加载到RAM（通常为SRAM）中执行。

该任务将会以USB协议为例，结合U-Boot，实现这一过程，最终通过在Bin文件中点亮一盏LED灯，指示任务的完成。

涉及的知识点

看似简单的一个任务，其实牵涉很多知识点，总结如下：

CPU Boot过程[/*]
Boot ROM的执行逻辑[/*]
Boot ROM中USB download protocol[/*]
简单的USB原理[/*]
Linux平台下借助libusb编写简单的DFU工具[/*]
U-boot的基本框架（arch-->cpu-->machine-->board）[/*]
U-boot的启动流程，包括SPL等概念[/*]
U-boot的配置和移植[/*]
GPIO的控制（呵呵，小菜一碟）[/*]
简单的编译原理，链接脚本、运行时地址等[/*]
交叉编译环境的配置[/*]
U-Boot的编译[/*]
完成任务的思路

看到上面列举的知识点，相信大家会吓一跳，不过大可放心，按部就班的做就可以了。

首先，我们把任务拆分为如下几个相对独立的部分：

将所使用的硬件平台“Boot from USB”有关的硬件信息、以固定的格式罗列出来移植U-Boot的时候，可以直接将这些信息对应到代码中的指定宏定义、变量等元素上，这样可以降低大家移植到新平台上的困难。我和Linuxer会以特定的平台为例，写出一份或者两份硬件信息的范本，大家follow即可（就像做填空题，目的也是降低移植的困难）。[/*]
以博文的形式，将U-Boot的启动过程总结出来，供大家参考主要目的是厘清代码中和启动过程有关的配置、宏定义等，这些信息会和上面的硬件信息一一对应，移植U-Boot的时候只需要填入即可。[/*]
结合特定的开发板，以项目文档的形式，将U-Boot的配置、编译等移植过程，总结出来主要目的是为其它平台的移植提供参考。[/*]
以博文的形式，介绍linux平台下libusb的功能和使用方法为后续DFU程序的编写做准备。[/*]
结合CPU ROM code中的USB协议，编写DFU程序编写完成后，使用DFU将U-Boot的bin文件下载到板子指定的RAM地址执行。[/*]

其次，就是分猪肉了（）。大家根据自身情况，可以考虑选择任务2~任务5中的任意一个，多个人可以选择同一个任务，一个人也可以选择多个（，我们可能优先为积极参与任务的同学送开发板哦！）。任务进行的过程中，大家可以随时在讨论区交流、讨论。

最后，提醒一下，大家完成任务的过程中，要不惜一切代价地借用已有的资源，只要思路对，哪怕代码是从别处抄过来的（自己一定要整理一遍），也可以达到目的。

暂时就这么多了，大家有其它想法的话，请踊跃讨论。

任务总结到目前为止（2016/06/01），该任务在bubblegum 96boards上基本完成，共有如下的文档和代码产出：
X-002-HW-S900芯片boot from USB有关的硬件描述[/*]
(/u-boot/boot_flow_1.html)[/*]
X-003-UBOOT-基于Bubblegum-96平台的u-boot移植说明[/*]
u-boot代码，(https://github.com/wowotechX/u-boot)[/*]
交叉编译工具、Firmware下载工具等，(https://github.com/wowotechX/tools)[/*]
编译脚本，(https://github.com/wowotechX/tools)[/*]

由于Firmware下载工具（DFU）牵涉到USB，因此暂时没有产出文档（正在考虑分析一下USB子系统）。

可以通过如下步骤在板子上验证： 1）代码下载（具体可参考“X-003-UBOOT-基于Bubblegum-96平台的u-boot移植说明”）


[== Undefined ==]
mkidr -p ~/work/xprj
cd ~/work/xprj
git clone https://github.com/wowotechX/build
git clone https://github.com/wowotechX/u-boot
git clone https://github.com/wowotechX/tools

2）代码编译


[== Undefined ==]
cd build
make env_prepare #下载交叉编译工具，只需要执行一次即可
make libusb #只需要执行一次
make dfu #只需要执行一次
make uboot

3）开机是按住ADFU按键，将bubblegum 96board进入DFU模式，并使用USB和PC连接（当前支持linux，dfu工具也可以支持windows，我没有测试），下载u-boot并执行


[== Undefined ==]
sudo ../tools/dfu/dfu bubblegum 0xe406b200 out/u-boot/spl/u-boot-spl.bin 1

dfu命令的具体解释，可直接执行dfu命令查看。

最后，希望感兴趣的同学，可以帮忙检查文档、代码，并在空闲时间，在自己的开发板上将该任务完成。多谢~~

"X Project"开发者之间的交流方法

Wed, 04 May 2016 19:36:45 +0800

本文是原「蜗窝讨论区」的历史存档（2016-05-04），来自版块「X Project」，共 4 帖。讨论区已停止服务，此处仅供查阅。

wowo · 2016-05-04 19:36

互联网时代的沟通成本很低，但这似乎也成了一种困扰，我们有QQ、微信、微博、E-mail、论坛等十八般兵器，但到底哪一种好用呢？

选择多了，也麻烦，因为注意力被分散了，反而抓不住重点。对蜗窝以及“X Project”来说，我建议使用如下三种手段：

1）(/contact_us.html)----总线式的交流大家可以畅所欲言。

2）论坛讨论区----I/O式的交流

交流特定的主题，不限于技术，但要求主题明确。

注：大家记得在板块（如“X Project”）的右下角，点击“订阅该版块”按钮，这样便可以通过邮件收到讨论内容（相当于mail list）。

3）微信群----中断式的交流

和特定项目（如“X Project”）有关的交流。

起通知作用，类似CPU的中断，只是“叫醒大家”，叫醒后，请求大家到“论坛讨论区”继续交流。

cuixiaolei · 2016-05-04 20:20

版主还是比较明智的，微信像短信一样，大家都能收到。大家有问题只需要把主题放在微信里咨询，顺便把论坛的主题贴出来，懂的人看到微信来论坛回复，这样知识也可以积累，微信不适合积累知识，只适合通知大家。
大家如果灌水闲聊去QQ。

XU · 2016-06-16 21:21

非常棒的想法

wowo · 2016-06-16 22:37

XU 写道： 非常棒的想法

多谢鼓励哈~~

玩转BLE(1)_Eddystone beacon

Fri, 29 Apr 2016 22:50:43 +0800

你相信两条命令就可以把自己的破手机变成一个Beacon节点吗？不相信的话就接着往下看吧。通过前几篇“蓝牙协议分析”相关的文章，特别是“ 蓝牙协议分析(3)_蓝牙低功耗(BLE)协议栈介绍 ”，相信大家对BLE协议栈已经有了基本的认识。在继续后续的分析之前，我们有必要换个视角，从应用的角度，以“玩”的心态，学习并理解BLE的工作原理，并作为后续分析文章的引子和入口。这就是撰写“玩转BLE”系列文章

X-001-PRE-git介绍及操作记录

Tue, 26 Apr 2016 22:27:01 +0800

git是一个高效、实用的版本管理工具，但并不是一个容易掌握的工具，刚接触的时候，总有一种云里雾里的感觉。因此本文将结合“X Project”的开发过程，记录git的操作记录，从实战的角度，理解并学习git。注1：有关“X Project”的介绍和讨论，可参考“ /forum/ ”。

关于内存的一点疑问

Mon, 25 Apr 2016 13:33:20 +0800

本文是原「蜗窝讨论区」的历史存档（2016-04-25），来自版块「Linux kernel技术问答」，共 2 帖。讨论区已停止服务，此处仅供查阅。

bruno · 2016-04-25 13:33

目前ARM开发板一般都是设备树，而内存地址一般在 memory节点表示，而内核初始化函数 setup_arch(char cmdline_p) 调用 setup_machine_fdt(__atags_pointer) 匹配设备树这个函数里面调用 early_init_dt_scan_nodes( ** 里面有 / Setup memory, calling early_init_dt_add_memory_arch / of_scan_flat_dt(early_init_dt_scan_memory, NULL);

early_init_dt_scan_memory( 扫描memory节点将内存添加到内核， memblock_add(base, size); 那么请问在这之前内存是从哪里来的呢

wowo · 2016-04-25 17:02

bruno 写道： 目前ARM开发板一般都是设备树，而内存地址一般在 memory节点表示，而内核初始化函数 setup_arch(char cmdline_p) 调用 setup_machine_fdt(__atags_pointer) 匹配设备树这个函数里面调用 early_init_dt_scan_nodes( ** 里面有 / Setup memory, calling early_init_dt_add_memory_arch / of_scan_flat_dt(early_init_dt_scan_memory, NULL);

early_init_dt_scan_memory( 扫描memory节点将内存添加到内核， memblock_add(base, size); 那么请问在这之前内存是从哪里来的呢

memblock_add添加的是memory region，并不是memory。那什么是memory region呢？就是一个声明，声明这一段地址空间（可以理解为虚拟地址）属于我（这些内存对应的物理地址）的了，其它人不要用了。因此，add与否，都不耽误kernel在启动的时候访问系统的内存。

X-000-PRE-开发环境搭建

Sat, 23 Apr 2016 20:20:50 +0800

本文是“X Project”的第一篇文章，介绍怎么从零开始搭建“X Project”的开发环境（同样适用于其它的嵌入式Linux开发）。通过该过程，可以使读者对嵌入式Linux开发的基本流程有一个简单的了解，以达到“知其然、知其所以然”的目的。注1：有关“X Project”的介绍和讨论，可参考“ /forum/

使用pxe方式安装系统

Sat, 23 Apr 2016 13:25:54 +0800

前两天由于工作的需要，研究了下pxe安装系统的方式。虽然网上资料也蛮全的了，但是对于我这样对pxe，tftp，dhcp等完全不懂的人来说，就是按部就班地做，也是错误百出，花了好久才找到方法。所以就记录下具体的操作步骤和一些细节性的问题。

X Project协同工作的方法【讨论】

Fri, 22 Apr 2016 22:24:28 +0800

本文是原「蜗窝讨论区」的历史存档（2016-04-22），来自版块「X Project」，共 7 帖。讨论区已停止服务，此处仅供查阅。

wowo · 2016-04-22 22:24

“X Project”是一个比较独特的项目，由一帮散布于天南海北、素未谋面、有共同兴趣爱好和理想的工程师协同开发，如何协同工作，是项目成败的关键。我这里提出一些想法，希望大家积极讨论、拍砖。

仔细想想，这个项目有一些众创的味道（也赶了一把潮流），只不过目的有点另类：学习、研究、交流、讨论嵌入式Linux技术。既然是众创，我们的工作方法肯定不能循规蹈矩，怎么做比较好呢？

思考这个问题的时候，我想起了大家熟悉的电脑游戏，例如之前比较喜欢玩的《侠盗飞车》。这些游戏相当庞大，也比较复杂，怎么教会大家呢？我相信游戏的设计者，不会给大家写出一本厚厚的教程，相反，他们不会给你任何说教，而是通过很多由浅入深的任务，让你参与其中，自学成才。那么，同样地，我们能否也把“X Project”也拆分成一个个由浅入深的任务，让大家在不知不觉中，进入Linux的世界？

我觉得可行，思路如下：

我和Linuxer先把“X Project”拆分为一个个的小任务（如果有其他人感兴趣，也可以一起做这个事情）[/*]
根据项目的进度，把这些小任务放到论坛上，“招聘”任务Leader，大家如果有兴趣，请一定要站出来，承担Leader的角色（如果没有人认领，我和Linuxer会认领）。[/*]
任务Leader确定后，在论坛上发表该任务的讨论文章（由Leader负责），和大家一起分享、讨论完成该任务的思路[/*]
思路确认后，进入实施阶段，编码、调试等，任务Leader可以根据参与者的意愿，将任务分配给指定的人实施。任务Leader要负责指导工作[/*]
任务完成后，将结果分享出来，并写一份简单的总结说明文档，发表在博客或者论坛上[/*]
其它参与者，可以同步完成相应的任务，并进行测试、验证等工作，如果有不明白的，可以在论坛发起讨论[/*]
最后，将代码上传到项目的代码仓库，并请求所有的参与者review，review通过后，代码合并到仓库中[/*]

不知大家觉得如何？是否可行？如有其它想法，也请补充。多谢~~

linuxer · 2016-04-28 18:11

QQ群里的快乐生活问道：关于x project我想问一下。项目的进度是大家各做各的，每个开发版组成一个小team。还是蜗窝给出任务和目标，每隔一段时间总结写文档。？？？

linuxer · 2016-04-28 18:18

我感觉还是可以根据板子来分成小组，当然wowo和linuxer应该会在S900开发板的那个小组，属于示范性的小组，其他小组可以参考S900 release的文档和代码来具体执行。具体的项目进度应该是各个小组的Leader制定，应该是大家各自根据情况设定，对每个平台（或者每个小组）产出的文档和代码，蜗窝是有要求的，文档要review，代码要review。

wowo · 2016-04-29 13:17

@cuixiaolei, 小崔在关于“X Project”中也发表一些看法，挺好的，我把它同步过来了。 ====================分割线===================== 关于项目，会出现很多开发板，每个开发板若干人，这些人会是一个小的team。大家做事情有统一的规划，固定的时间完成某个东西，还是每个小team自己决定进度和内容呢？如果是后者，这个项目就失去了意义。我说一下我自己的一点建议。我个人觉的还是有统一的规划的好。每个开发板找出一个负责人。蜗窝给出任务和规划。例如任务是input subsystem移植，目标是把自己开发板上的按键加入到input子系统中，时间两周。然后蜗窝给出一个文档（可以不基于任何一款开发板），介绍input subsystem，移植input subsystem等，每个小team再去做，做玩以后写成针对自己开发板的文档，负责人把好的文档也push到git服务器上，这样后来参加此项目的人也不会落下什么。我个人还是希望能弄个邮件列表，每个小team有个邮件列表，push到服务器上的介绍往往太少，还是邮件写的清楚，还能加上自己的感悟和总结。

wowo · 2016-04-29 13:40

cuixiaolei 写道： 关于项目，会出现很多开发板，每个开发板若干人，这些人会是一个小的team。大家做事情有统一的规划，固定的时间完成某个东西，还是每个小team自己决定进度和内容呢？如果是后者，这个项目就失去了意义。

这一点应该很明确：各个开发板team所开发的内容，在时间点上，应该基本一致。这样大家才可以互相讨论、互相学习。

cuixiaolei 写道： 我个人觉的还是有统一的规划的好。每个开发板找出一个负责人。蜗窝给出任务和规划。例如任务是input subsystem移植，目标是把自己开发板上的按键加入到input子系统中，时间两周。然后蜗窝给出一个文档（可以不基于任何一款开发板），介绍input subsystem，移植input subsystem等，每个小team再去做，做玩以后写成针对自己开发板的文档，负责人把好的文档也push到git服务器上，这样后来参加此项目的人也不会落下什么。

好主意，我会在github上新建一个doc的目录，存放一些项目相关的文档。

cuixiaolei 写道： 我个人还是希望能弄个邮件列表，每个小team有个邮件列表，push到服务器上的介绍往往太少，还是邮件写的清楚

邮件列表的事情，github上的账号每个人都邮箱，gerrithub上有可以创建分组，我们可以利用。

linuxer 写道： 我感觉还是可以根据板子来分成小组，当然wowo和linuxer应该会在S900开发板的那个小组，属于示范性的小组，其他小组可以参考S900 release的文档和代码来具体执行。具体的项目进度应该是各个小组的Leader制定，应该是大家各自根据情况设定，对每个平台（或者每个小组）产出的文档和代码，蜗窝是有要求的，文档要review，代码要review。

这个OK。但是我觉得在小组leader的基础上，最好能再根据子系统划分一些team，每一个team有一个比较资深的工程师，作为leader。

关于XProject项目开发板的说明

Fri, 22 Apr 2016 16:00:04 +0800

本文是原「蜗窝讨论区」的历史存档（2016-04-22），来自版块「X Project」，共 25 帖。讨论区已停止服务，此处仅供查阅。

linuxer · 2016-04-22 16:00

源由和目的： Project X设定了多板支持的目标其实是为了把大家落满灰尘的各种各样的开发板给真正的玩起来，并不是想浪费大家的钱去再购买新的开发板，但是： 1、有些同学手中无板 2、有些同学手中有板，但是没有硬件手册和原理图，无法参与 3、有些同学手中有板，也有齐全的硬件资料，但是希望跟随蜗窝科技一起学习Linux内核知识

基于这些原因，估计还是有同学有购买开发板的需求，蜗窝并不限定大家购买开发板的型号，但是不同的开发板总会形成一个个小的team，如果你想加入蜗窝主打支持的Xproject team，那么还是需要保持和蜗窝使用的开发板保持一致。因此，这里会公布蜗窝使用的开发板型号：

1、S900-96board（注：该开发板价格昂贵，专门为土豪定制） 2、TODO（蜗窝正在和部分厂商商讨中，有结果的话会在这里更新）

这些板子在淘宝都有销售，大家可以自行购买。

之前，为了节省大家的钱，蜗窝收集这些购买板子的需求，希望能板子价格压低一些，但是效果不理想，因此取消了团购活动，大家自行购买即可。

最后强调一句：如果已经有板子，并且符合条件，强烈不建议购买新的板子，也不需要和蜗窝保持一致，开发板都是浮云，真正的技术是那些硬件无关的软件层次和结构。

linglongqion · 2016-04-22 16:07

QD-大括号，手中无板，报名参加团购s900板子

yin · 2016-04-22 16:11

yin，S900一枚

wfing123 · 2016-04-22 16:51

群里唯妮熊 s900板子一枚

linuxer · 2016-04-22 16:52

可以参考http://www.96boards.org/products/ce/bubblegum96/了解S900开发板的更详细的信息

bruno · 2016-04-22 18:59

有 dragonboard 430 ，支持活动啦

xiongchuan · 2016-04-22 19:05

群里熊川 ,s900开发板，1块

kadajur · 2016-04-22 19:08

群里heavenward。申购s900一块

borman · 2016-04-22 19:08

幸福吧，s900来一枚

OceanSummer · 2016-04-22 19:36

章鱼哥，s900申购一块

mikrobug · 2016-04-22 19:38

坚强的果，支持，能从头开始跟随一个项目学习，比较难得，申购s900一枚，不过希望厂家支持力度够高，硬件使用过程中的问题有些还是得厂家给答案，要不自己绕破天

hxiaoqiang · 2016-04-22 20:08

向日葵，申购S900一块。手头有am335x的，有块zedboard。

关于如何开展X Project的想法，大家一起补充啊

Thu, 21 Apr 2016 19:46:23 +0800

本文是原「蜗窝讨论区」的历史存档（2016-04-21），来自版块「X Project」，共 20 帖。讨论区已停止服务，此处仅供查阅。

linuxer · 2016-04-21 19:46

一、X Project项目规划项目分成两个阶段： 1、最小系统阶段。这个阶段定义为能够启动到串口控制台登录就OK了，这个阶段不需要用eMMC做为root，使用ramdisk做为root device就OK了。 2、完整系统支持阶段。这个阶段定义为各种外设的添加和支持。本次大家主要讨论最小系统阶段的任务

二、整体步骤 1、版主先把想到的任务罗列出来，然后大家一起补充，形成一个完成的任务列表 2、大家各自领取任务 3、PM收集各个参与人员的情况（水平、参与时间等）制定处于一个有时间、人力安排的项目计划 4、PM监控并随时调整计划

三、最小系统的任务列表 1、文档（1）基本系统搭建指南（2）CPU相关启动移植指南（3）中断子系统移植指南（4）时间子系统移植指南（5）Pinctrl子系统移植指南（6）GPIO子系统移植指南（7）clock系统移植指南（8）供电系统移植指南（9）串口tty驱动移植指南（10）bootloader移植指南（11）rootfs构建指南

2、代码实现（1）基本系统搭建（2）CPU相关启动移植（3）中断子系统移植（4）时间子系统移植（5）Pinctrl子系统移植（6）GPIO子系统移植（7）clock系统移植（8）供电系统移植（9）串口tty驱动移植（10）bootloader移植（11）rootfs构建

四、具体操作 1、移植之前，需要首先理解该驱动的framework，并整理发表在博客 2、wowo和linuxer会给出S900平台上的移植指南 3、其他人review并撰写自己平台上的文档 4、wowo和linuxer会给出S900平台上的代码实现 5、其他人review并撰写自己平台上的驱动

我先抛出一块砖头，希望能看到漫天飞舞的玉石，哈哈

Daniel · 2016-04-21 21:05

基于4.4内核版本，是吧。有个问题，如果4.4版本内核本来就支持某个开发板，是要自己重新再移植一套还是主要就成了文档总结咯？大纲终于出来了，大家都踊跃参与～～

wowo · 2016-04-21 22:49

Daniel 写道： 基于4.4内核版本，是吧。有个问题，如果4.4版本内核本来就支持某个开发板，是要自己重新再移植一套还是主要就成了文档总结咯？大纲终于出来了，大家都踊跃参与～～

我直接从kenrel的mainline上（今天）导出了我们开发的版本（稍等几天我会把开发环境搭建的文章发出来），我们先基于最新版本开发，然后等到一个时间点，再rebase到后续的一个稳定的、long team的版本上（刚好练习一下git的使用）。

我觉得我们要达成一些共识，例如：只要是mainline上有的资源，我们一定要复用，不能重复造轮子。其实嵌入式linux的学习过程，就是一个“模仿-->熟悉-->有自己的想法”的过程。

上海-云 · 2016-04-22 10:11

是不是可以在github上开一个organization？

Common Clock Framework系统结构

Thu, 21 Apr 2016 19:23:38 +0800

之前，wowo同学已经发表了关于CCF（ Common Clock Framework ）的三份文档，相信大家对CCF有一定的了解了，本文就是在阅读那三份文档的基础上，针对Linux 4.4.6内核的内核代码实现，记录自己对CCF的理解，并对CCF进行系统结构层面的归纳和整理。本文内容包括三个部分，第二章给出了整个CCF相关的block diagram图，随后在第三章对各个模块进行功能层面的描述

clk_register和 clk_register_clkdev是不是功能有些重复呢？

Wed, 20 Apr 2016 19:55:48 +0800

本文是原「蜗窝讨论区」的历史存档（2016-04-20），来自版块「Linux kernel技术问答」，共 4 帖。讨论区已停止服务，此处仅供查阅。

T800 · 2016-04-20 19:55

各位大神，在common clock framework中有两个函数：clk_register和 clk_register_clkdev，总是感觉有些功能重复，有没有人给讲一讲？

linuxer · 2016-04-21 00:24

重复吗？我怎么不觉得呢？呵呵~~~我说说我的理解。

1、这两个函数各自的功能是什么呢？虽然名字有点像，但是这两个函数的功能并不像。对于clk_register函数而言，底层（clock provider）可以通过调用该接口注册一个clk（一个抽象的clock device）到common clock framework中。对于clk_register_clkdev而言，它实际上是注册一个struct clk_lookup到common clock framework中，就像数据结构的名字那样，这个操作主要是为了寻找clk。

2、为何需要寻找clk呢？我们可以从clock consumer的角度来看，在其初始化函数中，我们往往需要调用clk_get获取对应的clk，然后才可以指向clk_enable/clk_disable/clk_set_rate等操作。

3、clock consumer怎么寻找clk呢？在没有引入Device tree之前，clock consumer是通过clk的名字来寻找其对应的clk数据结构。我们上面说过了，clock provider驱动中会调用clk_register函数注册到common clock framework中，但是clock consumer并不知道如何定位到该clk，因此clock provider驱动中除了调用clk_register获取clk之外，随后都会立刻调用clk_register_clkdev将该clk和一个名字捆绑起来（看看struct clk_lookup的定义就明白了），并将产生的struct clk_lookup实例挂入一个全局链表中。而clk的名字就是clock consumer获取clk的唯一途径。

4、引入device tree之后，clock consumer怎么寻找clk呢？引入device tree之后，情况发生了一些变化。基本上每一个clock provider都会变成dts中的一个节点，也就是说，每一个clk都有一个设备树中的device node与之对应。在这种情况下，与其捆绑clk和一个“名字”，不如捆绑clk和device node（参考struct of_clk_provider），因此原来的clk_register + clk_register_clkdev的组合变成了clk_register + of_clk_add_provider的组合。

我们再看clock consumer这一侧：这时候，使用名字检索clk已经过时了，毕竟已经有了强大的device tree。我们可以通过clock consumer对应的struct device_node寻找为他提供clock signal那个clock设备对应的device node（clock属性和clock-names属性），当然，如果consumer有多个clock signal来源，那么在寻找的时候需要告知是要找哪一个时钟源（用connection ID标记）。当找了provider对应的device node之后，一切都变得简单了，从全局的clock provide链表中找到对应clk就OK了。

因此，要说功能重复，clk_register_clkdev和of_clk_add_provider重复了，在引入强大的设备树之后，clk_register_clkdev按理说应该退出历史舞台了。

5、但是最新的代码中怎么仍然有clk_register_clkdev的代码呢？很多平台上也用的很欢畅呢？唉，一言难尽啊......家家有本难念的经，SOC厂商往往是急功近利的，他们往往首先考虑的是完成功能，而不是考虑架构的优雅......

T800 · 2016-04-21 08:43

恩，多谢指点，明白了，今天再对着代码仔细想想。

CONFIG_COMMON_CLK和CONFIG_HAVE_CLK这两个配置有什么不同呢？

Wed, 20 Apr 2016 14:48:43 +0800

本文是原「蜗窝讨论区」的历史存档（2016-04-20），来自版块「Linux kernel技术问答」，共 3 帖。讨论区已停止服务，此处仅供查阅。

T800 · 2016-04-20 14:48

最近在看common clock framework，发现有两个配置：CONFIG_COMMON_CLK和CONFIG_HAVE_CLK，那么这两个配置有什么不同呢？

linuxer · 2016-04-20 15:50

CONFIG_HAVE_CLK这个配置项用来控制系统是否使用clk相关的接口，具体的接口包括： 1、struct clk clk_get(struct device dev, const char id); 2、int clk_enable(struct clk clk); 3、unsigned long clk_get_rate(struct clk *clk); ......

CONFIG_COMMON_CLK这个配置项用来控制kernel是否使用common clock framework，当然，使用了common clock framework模块，其实就会选择提供clk相关的接口，也就意味着如果CONFIG_COMMON_CLK＝y的话，那么CONFIG_HAVE_CLK也必定等于y。

当然，你可能问：CONFIG_HAVE_CLK配置项是否有存在的必要？当然有必要，因此我可以配置CONFIG_HAVE_CLK=y而CONFIG_COMMON_CLK＝no。在遥远的过去，没有common clock framework的时候，各种ARM SOC纷纷定义了自己的clk的实现，虽然提供了clk的接口API，但是并没有使用common clock framework。

T800 · 2016-04-21 08:41

恩，原来如此，多谢！

Linux操作命令记录

Wed, 20 Apr 2016 10:36:21 +0800

大学毕业快一年了，经常看别人的博客，看着别人学习都很有条理，学什么都记录下来，所以自己也打算开始写属于自己的学习记录。而且很多时候有些技巧用到的时候上网查一下，下次又忘了，所以希望能够做好整理工作。

为什么级连中断不能线程化呢……

Tue, 19 Apr 2016 23:03:24 +0800

本文是原「蜗窝讨论区」的历史存档（2016-04-19），来自版块「Linux kernel技术问答」，共 6 帖。讨论区已停止服务，此处仅供查阅。

linuxer · 2016-04-19 23:03

在3.18.12内核中，有如下代码：

void __irq_set_handler(unsigned int irq, irq_flow_handler_t handle, int is_chained, const char name) { unsigned long flags; struct irq_desc desc = irq_get_desc_buslock(irq, &flags, 0);

if (!desc)
 return;
if (!handle) {
handle = handle_bad_irq;
} else {
if (WARN_ON(desc-&gt;irq_data.chip == &amp;no_irq_chip))
goto out;
}
/* Uninstall? */
if (handle == handle_bad_irq) {
if (desc-&gt;irq_data.chip != &amp;no_irq_chip)
mask_ack_irq(desc);
irq_state_set_disabled(desc);
desc-&gt;depth = 1;
}
desc-&gt;handle_irq = handle;
desc-&gt;name = name;
if (handle != handle_bad_irq &amp;&amp; is_chained) {
irq_settings_set_noprobe(desc);
irq_settings_set_norequest(desc);
irq_settings_set_nothread(desc);
irq_startup(desc, true);
}

out: irq_put_desc_busunlock(desc, flags); }

当是级联中断的时候（is_chained == true），会通过irq_settings_set_nothread函数将该中断描述符设定为no thread，也就是说该中断handler不能被线程化，为什么呢？

bootloader和linux kernel如何协调MMU、dcache和icache的设定？

Tue, 19 Apr 2016 19:16:02 +0800

本文是原「蜗窝讨论区」的历史存档（2016-04-19），来自版块「Linux kernel技术问答」，共 5 帖。讨论区已停止服务，此处仅供查阅。

linuxer · 2016-04-19 19:16

1、bootloader是否需要开MMU？ bootloader中没有多任务的需求，一般都是单线程的，因此也没有分隔各个任务的地址空间需求，MMU按理说不应该打开。

2、但是有些bootloader为何会打开MMU？之所以在bootloader中打开MMU是因为想要打开dcache。一般而言，MMU和dcache是捆绑在一起的，想要打开dcache必须打开MMU。有的时候，在实际的项目中，为了加快bootloader的运行速度，打开dcache会有帮助，但是打开dcache必须要打开MMU，因此，一般做法是打开MMU，但是建立一致性映射（物理地址等于虚拟地址）。

3、为何MMU和dcache是捆绑在一起的？怎么不和icache捆绑在一起？指令alway在memory中，打开不会产生歧义，而且打开总是能加快执行速度。但是对于数据而言就有些复杂了，有对memory的访问，有对外设的访问，有的需要cache，有的打开cache操作就错误了，因此，dcache的设定是在页表中的，从而和MMU捆绑在一起。

4、bootloader和linux kernel如何协调MMU、dcache和icache的设定？在bootloader把控制权交给kernel的时候，kernel要求：MMU：off，dcache：off，icache：不要求，on或者off皆可。因此，没有特殊要求，一般bootloader只是打开icache，而不会打开dcache。

5、在bootloader中打开icache不会有什么问题吗？对速度的改善如何？ icache操作只是和取指操作相关，当保存指令的介质是慢速设备的时候（例如NOR FLASH），对速度改善非常大（程序都是符合局部性原理的）。即便是代码位于SDRAM或者DDR，速度改善也是很明显的。一般而言，icache在memory hierarchy中处于L0 level，仅次于寄存器，而SDRAM或者DDR处于L3或者L4，每个level都是相差一个数量级，因此，打开icache对速度的影响是非常明显的。

有一点要非常的注意，那就是program copy，这时候，由于打开了icache，要小心一点，不要访问到旧的icache的指令数据。一般而言，copy一段程序之后，立刻将该段icache设置为无效即可。

5、打开了dcache真的能提高执行速度吗？这和bootload中对数据访问的模式相关，如果有很好的局部性，并且操作数据量比较大，打开dcache之后的速度的确会令人沉醉的。

注：该问题来自蜗窝科技的讨论群，这里整理出来，分享给大家。

linglongqion · 2016-04-19 19:25

:lol: Good reply！

弯曲的旅行 · 2016-04-19 21:08

楼主总结的很好，多谢。bootloader做的事情应该比较单纯才是，如果到了需要开cache的地步，是否需要反思呢？

上海-云 · 2016-04-20 09:52

非常棒的总结，特意注册了号来和大家交流 :rolleyes:

Daniel · 2016-04-20 18:09

linuxer研究的范围就是够广，够深啊，佩服

问一个新手最常问的问题：到底怎么样才能学习好linux呢？

Tue, 19 Apr 2016 11:03:39 +0800

本文是原「蜗窝讨论区」的历史存档（2016-04-19），来自版块「Linux kernel技术问答」，共 7 帖。讨论区已停止服务，此处仅供查阅。

菜刀 · 2016-04-19 11:03

做为一个初学者，对linux一无所知，到底有没有一个公式化的方法可以一步一步进入高手的行列呢？

linuxer · 2016-04-19 12:10

做为一个过来人，我谈谈我自己的看法，欢迎大家补充：

首先肯定的一点是：不要一上来就看内核代码，基本上你会很快被挫败感打败。内核正在变得越来越庞大，学习曲线越来越陡峭，当你一无所知的时候冒然进入linux kernel，你会发现处处都是障碍，处处都是大坑，你根本走不下去。最好的方法是把对内核源代码的热情先放在心里，从基本功开始。

我认为的基本功包括两个方面： 1、linux的基本操作。内核中的很多设计都是源于应用，你不理解用户空间的操作，也就不会知道内核空间在干什么。这时候，你需要做的就是在自己的计算机上安装一个GNU/linux操作系统，Debian、Ubuntu什么的都OK，最好去掉其他的OS，这可以强迫你在linux下进行学习，工作，生活。在这个过程中，你可能需要google检索一些信息，安装一些软件，学习使用这些软件，理解一些基本的linux的背景知识......如果你想要从事底层的软件开发，那么尽量在终端下工作，这样会让你和linux kernel更接近一些，从而提供更多关于内核的基础知识。

2、第二个方面是软件相关的基础知识。你最好学习一些软件的逻辑思维，学习掌握一门语言，当然最好是c语言。掌握其基本的语法和语义，然后在linux环境下进行实际训练。这里不得不隆重推出一本经典之作《Unix高级环境编程》，仔细阅读这本书，然后动手实践，编写linux下的小程序，给自己找些乐子。

有了基本功之后，你可以选择强攻Linux kernel，不过呢我还是建议从一个小的RTOS入手，构建下面的知识体系： 1、关于OS的基本概念。什么是进程、什么是线程，什么是中断，什么是文件系统，什么是内存管理，什么是上下文，什么是设备管理等等。

2、关于处理器以及周边硬件的基础知识。可以选择ARM，也可以选择其他的处理器，主要是从软件角度来理解一个处理器，知道CPU的基本组成，知道什么是MMU，TLB，中断处理流程，总线的概念，什么是指令集等等。这时候，相信你会接触一些汇编指令，不一定要能写，但是一定要能读懂。

上面的阶段都没有接触Linux内核，但是不要着急，我们马上就要直面Linux内核了，第一个问题就是选择什么版本，不需要太新，但是越早的内核就会越简单，有助你可以把阅读linux内核代码的习惯持续下去。你有几个选择： 1、配合《Linux内核完全注释》来理解0.12内核。我没有看过这本书，听说不错。 2、配合《Linux内核情景分析》来理解2.4内核。当年就是这本书引领我来阅读内核的，我一直都对其充满感激之情 3、配合《深入理解linux内核》来理解2.6.10内核。非常好的书，强烈推荐，我基本上阅读了好几遍这本书，中文版一遍，英文版3遍，每次都有不同的收获。

阅读代码的过程有些枯燥，可以考虑撰写实际的驱动程序来调节一下，《Linux设备驱动》是不二之选。

最后，整理一些心得： 1、英语很重要、英语很重要、英语很重要。一定要学好英语，尽量看英文版书籍。 2、多动手，多思考，多总结。如果有机会，把自己的心得整理出来并发布，和其他工程师交流，这个过程可以有助于夯实你对Linux kernel的理解。 3、clone linux stable的代码仓库，多读一读git log，那是无穷的宝藏

Daniel · 2016-04-20 18:20

linuxer大神的建议非常好！我当初也是从RTOS开始的，从那里对操作系统有了一个大致的整体的概念，ucosII和ucosIII，推荐大家看看，一共就十几个c文件，麻雀虽小，五脏俱全~~~

菜刀 · 2016-04-21 08:39

收到，看来前路漫漫啊，待我上下求索吧！

Nickisnotnic · 2016-05-02 15:19

victor.guo · 2016-09-19 15:57

3、配合《深入理解linux内核》来理解2.6.10内核。非常好的书，强烈推荐，我基本上阅读了好几遍这本书，中文版一遍，英文版3遍，每次都有不同的收获。

---很牛叉

马六甲2017 · 2016-10-14 07:24

大约1年前开始访问本网站(原先马甲好像不能用了,今天重新注册一个),受益匪浅,不论对我理解linux 还是linux相关的工作帮助都很大. 对linuxer & wowo 再次表示感谢.

对linuxer的下面的建议,我也强烈赞同.

我大约14年前就购买了《Linux内核情景分析》,但当时还是硬件工程师,有些基础背景知识还不充分, 最终无法看懂全书的内容,努力了几次后都没有结果,最终放弃. 大约8年前购买《深入理解linux内核》(影印版), 几次尝试也都不能坚持到底.

后来,从事转行做软件工程师, 由于工作需要和个人兴趣,阅读ARM/X86/coldfile/Tencilica/MIPS的manual,自己补充编译原理/操作系统的知识, 先是从事xworks& freertos开发, 有机会阅读其操作系统的全部原代码. 自己算是掌握的比较彻底.

大约3年前, 重新阅读《深入理解linux内核》(影印版), 感觉自己的背景知识比较充足了. 有些章节可能反复读几遍. 有些到目前只读了一遍(有时间会继续学习). 最近2年,由于工作需要,天天鼓捣linux, 有些topic才比较深入.

对linuxer总结的体会我深有感触, 也非常赞同. 自己跟linuxer的相似之处是(linuxer是谦虚, 我确实不会, 也没精力全部弄通), 对C比较熟悉, 其它编程语言基本不会. 对kernel & CPU 细节问题倒是花费了好多时间. (基本不分周末和假期)

日常工作中, 我也看到很多年轻同事也能解决一些问题, 但确实没有弄清楚为什么要这样解决, 很多时候是试出来的, 对系统稳定性是隐患.

需要送小孩上学去了, 以后再灌水.

linuxer 写道： 做为一个过来人，我谈谈我自己的看法，欢迎大家补充：

阅读代码的过程有些枯燥，可以考虑撰写实际的驱动程序来调节一下，《Linux设备驱动》是不二之选。

第一条灌水，哈哈~~~有没有喜欢看科幻电影的？

Mon, 18 Apr 2016 22:54:58 +0800

本文是原「蜗窝讨论区」的历史存档（2016-04-18），来自版块「灌水区」，共 14 帖。讨论区已停止服务，此处仅供查阅。

菜刀 · 2016-04-18 22:54

前几天看了《彗星来的那一夜》，很喜欢，有没有大神推荐几部？

T800 · 2016-04-19 08:54

看我的名字，你就知道是哪一部了，哈哈

弯曲的旅行 · 2016-04-19 21:04

T800 写道： 看我的名字，你就知道是哪一部了，哈哈

哈哈，终结者？

wowo · 2016-04-19 22:21

我比较喜欢时光旅行性质的，如《时间旅行者的妻子》等。

T800 · 2016-04-19 22:42

弯曲的旅行写道：

T800 写道： 看我的名字，你就知道是哪一部了，哈哈

哈哈，终结者？

对，很老的片子，终结者2，当年（92年）看这部片子的时候，那叫一个震撼啊，我连续看了3遍。即便是20多年后的今天，它仍然是不过时的。

Daniel · 2016-04-20 18:38

对喜欢人工智能类电影的，推荐一部机械姬！你会有很多思考的~~~

弯曲的旅行 · 2016-04-20 21:37

Daniel 写道： 对喜欢人工智能类电影的，推荐一部机械姬！你会有很多思考的~~~

人工智能的话，肯定少不了《人工智能》啊，百看不厌，既有智能，又有温情，再加上时光的哀伤……

菜刀 · 2016-04-21 08:36

收片子啦，呵呵～～～多谢！周末回家看

弯曲的旅行 · 2016-04-23 21:36

最近看过一个电影电视剧，《僧侠断案传奇》，共10集，虽然不是科幻，也强烈推荐给大家！！再加上一条重要提示：千万不要好奇害死猫，先看最后一集《大夜叉》。别问我为什么，泪奔啊……

wowo · 2016-04-23 21:40

我推荐一部，《分歧者》，不知道符合大家的口味不。

wowo · 2016-05-03 09:15

知乎上一篇科幻电影的讨论，写的很好，在这里备份一下： http://daily.zhihu.com/story/4639995

moming · 2016-05-06 15:24

收片子啦，有空看看。

Kerry · 2016-06-22 13:50

弯曲的旅行写道： 最近看过一个电影电视剧，《僧侠断案传奇》，共10集，虽然不是科幻，也强烈推荐给大家！！再加上一条重要提示：千万不要好奇害死猫，先看最后一集《大夜叉》。别问我为什么，泪奔啊……

妈呀，最看不了揪心的。。。。

我原来在蜗窝科技注册的用户名失效了吗？

Mon, 18 Apr 2016 22:44:27 +0800

本文是原「蜗窝讨论区」的历史存档（2016-04-18），来自版块「Linux kernel技术问答」，共 6 帖。讨论区已停止服务，此处仅供查阅。

linuxer · 2016-04-18 22:44

我有两个问题： 1、我原来的用户名和密码都无法登陆了，是不是原来蜗窝注册的用户名密码和论坛的用户名以及密码不能通用？ 2、我在论坛注册的新的用户名密码可以用于博客中发布文章和给出评论吗？

菜刀 · 2016-04-19 08:37

论坛和蜗窝科技是两套系统，根本不能相通的

wowo · 2016-04-19 09:37

hello_world 写道： 我有两个问题： 1、我原来的用户名和密码都无法登陆了，是不是原来蜗窝注册的用户名密码和论坛的用户名以及密码不能通用？ 2、我在论坛注册的新的用户名密码可以用于博客中发布文章和给出评论吗？

原来的蜗窝，本质上是一个博客，因此注册用户和普通的访问者没什么区别（都可以留言、评论），因此论坛建起来之后，就不准备开放蜗窝的注册了（虽然原来的注册用户都会保留）。我本来也想过把之前的用户同步到论坛上，但之前大部分用户没有提供邮箱，这在论坛系统中是不合法的，因此只能麻烦大家重新注册了。抱歉~~~

peter · 2016-04-19 21:37

刚通过论坛注册了一个帐号，但是该帐号无法登录蜗窝科技？以前注册蜗窝科技的帐号登不了了...

wowo · 2016-04-19 21:48

peter 写道： 刚通过论坛注册了一个帐号，但是该帐号无法登录蜗窝科技？以前注册蜗窝科技的帐号登不了了...

以前蜗窝科技的账号，就不要使用了。登录论坛，就用新注册的账号。至于博客，登录没有太大意义，直接评论就行了（我的很多评论，都没有登录）。

peter · 2016-04-19 23:25

AM 写道：

peter 写道： 刚通过论坛注册了一个帐号，但是该帐号无法登录蜗窝科技？以前注册蜗窝科技的帐号登不了了...

好的，谢谢！

关于“X Project”

Mon, 18 Apr 2016 13:08:27 +0800

本文是原「蜗窝讨论区」的历史存档（2016-04-18），来自版块「X Project」，共 97 帖。讨论区已停止服务，此处仅供查阅。

admin · 2016-04-18 13:08

背景

蜗窝在2014年成立之时，就计划在更新博客的同时，和大家一起做一些项目，因此才会有“项目专区”这个分类。遗憾的是，它留空至今。

做项目的原因，是和蜗窝的初衷有关：蜗窝从没有打算做一个单向的分享平台（博客、写书、视频等活动在此列），而是想做一个多向的交流、沟通平台。欲达到此目的，大家一起做一些事情，是一个快捷的方法。

而两年多的时间里，迟迟未做，原因很多，但总结起来，无外乎一个字：懒。不过“懒”病不是绝症，总能治。这不，痛定思痛，准备开始了。

X Project

大家先不用纠结“X Project”这个名字怎么来的（可以先玩一下“猜一猜”游戏，如果后面项目做多了，大家应该能猜到）。简单的说，这个项目就是One Kernel，Everywhere，或者说One Linux on Any Board。也就是说我们希望启动在Linux 4.4.y版本的kernel上面支持大家手中的各种各样的开发板的一个项目。

之所以做这样一个项目，背后的思考如下：

1）目前硬件开源的浪潮风起云涌，很多公司都推出了自己的开发板，方便各种小型公司实现自己的创业梦想。但是，这些板子提供的文档大多是如何使用板子，如何对板子进行二次开发，对于Linux内核的内容着墨非常少。在这样的情况下，对内核以及驱动开发有兴趣的工程师或者学生，在购买开发板之后，简单的玩玩之后便束之高阁，无法真正体会到Linux kernel以及驱动开发的乐趣。

2）目前国内工程师没有形成文档习惯，遇到问题，解决问题，不会全面检视问题背后的源由，知识来的快，去的也快，同样的，问题解决的快，新问题冒出的速度更快，最终累成狗。我们希望通过一个实际的项目来展示优雅的代码、文档以及解决问题的过程。

3）蜗窝是一个深度学习，深度思考Linux技术的网站，博客中发表的文章都是偏理论，不利于初学者理解和学习。因此我们希望通过一个结合硬件实战的实战项目来帮助更多的初阶工程师。理论源于实践，但是要高于实践，因此，在实际的项目中点点滴滴最后会被整理出来，最终会形成有系统的、理论化文档，发表在博客板块，可以指导更多的工程师进行具体的“实践”活动。

因此，我们希望借助“X Project”，唤醒大家手中沉睡的开发板。无论大家手头有什么样子的开发板、旧手机，只要有必要的硬件资料、原理图、知道启动过程控制等，那么只要按照我们的指导写出文档以及代码，通过review之后，即可并入项目的代码库。一方面自己得到实践的乐趣，另外一方面也可以分享自己的成果。

当然，蜗窝会给出示例性的文档和代码，这里我们选择了ARM64的S900处理器和ARM32的RK3128处理器做为范例，我们会提供各种详细的指导性的文档和代码，帮助大家一步一步的完成一个板子的板级支持任务。

目标

我们计划把该项目分为如下几个部分： 1）boot（包括u-boot和kernel boot） 2）linux bsp 3）Debian 4）Android

最终达成如下目标： 1）在4.4.y kernel版本上，尽可能多的支持现有开发板，并提供优秀的代码和文档。 2）整个过程，大家通过学习、讨论、实践等环节，互相提高。 3）代码符合开源社区规范，可以很容易地升级kernel、u-boot等版本。 4）最终将我们的实现代码upstream到u-boot和kernel的mainline上（以每个作者的名义）。

动机和动力

相信大家看到上面的表述之后，肯定会犯嘀咕：工作量太大了吧？做这些事情有什么意思呢？等等。没错，我们也这样想过，这也是我们写这篇文章的原因：需要大家的意见和帮助。在此之前，我先分享一些我的心路历程。

其实在蜗窝成立的前后，我们一直在纠结、迷茫一些事情（“关于蜗窝”中也有流露）：我们的技术环境怎么了？我们的技术人，在带给这个社会日新月异的技术变迁的同时，自己想要什么？满足了吗？

答案毫无疑问是消极的，究其原因，我们最终得出的结论是：社会发展的必经阶段。OK，那我们能做什么？既然是必经阶段，总有一天情况会好转，我们就搬个马扎，等着，5年，10年，总够了吧？这就是蜗窝存在的最原始的驱动力。

把话题拉回，和这个项目有什么关系？我们一直坚信，能给我们这些技术人带来满足和快乐的，唯有技术本身。在这日复一日的工作中，我们唯有爱上它，才能得到解脱和升华。怎么爱呢？用心的、完整的做一件事情，理解它，发现它的优雅和美。这就是“X Project”的初衷。

期望大家的参与

任何理想总归要回到现实中，这个项目必须要在大家的参与和帮助下才能进行，大家可以通过如下方式参与：

1）参与讨论，对我们想法，大家是否认同，是否感兴趣，是否有其它不同的想法和意见，等等。 2）参与开发，如果手上有开发板、旧手机（满足一定条件，如有简单的硬件资料、简单的原理图、可以SD启动等，后面再讨论），按照我们的思路，把它们支持起来，我们提供思路和做法。 3）如果有硬件相关的资源，为我们提供赞助。

最后，希望大家注册账号，并发表对项目的看法，提出自己的建议，参与讨论。如果愿意的话，可以附上简单的信息（也可以不写）：名称；年龄；职业；工作年限；是否赞同；是否愿意参与；其它（随便说）。如：


[== C++ ==]
vim；30；嵌入式liux工程师；8；Y；Y。

菜刀 · 2016-04-18 22:35

在这样一个版块中支持多个板子，如何区分各个开发板的主题帖呢？

linuxer · 2016-04-18 22:40

菜刀写道： 在这样一个版块中支持多个板子，如何区分各个开发板的主题帖呢？

建议每个帖子上的开始都需要标注，例如如果你想要发布的主题是和S900相关的，那么可以主题使用开始的文字，这样大家就比较容易分辨了

蓝牙协议分析(4)_IPv6 Over BLE介绍

Sat, 09 Apr 2016 16:44:31 +0800

蓝牙是个奇葩的家伙：它总是以后来者的身份出现，很喜欢打仗，而且还不落下风（有点像某讯的风格）。90年代末期和Wi-Fi的无线标准之争如此，当前和802.15.4系（ZigBee、RF4CE、Thread等）的IoT之争，也如此。 90年代末期，蓝牙刚出道的时候，就曾叫嚣着把Wi-Fi（802.11）从地球上抹去。反过来，1999年Wi-Fi 802.11b标准发布后，也宣称会把蓝牙干掉。最终，二者

Debian下的WiFi实验（二）：无线网卡自动连接AP

Thu, 24 Mar 2016 18:18:57 +0800

自从我的T450能够WiFi上网之后，在Debian下上网，更新软件包什么的再也不用看老婆的脸色了，哈哈。虽然如此，但是隐隐约约总是觉得很不方便，对了，就是每次开机都需要输入一系列的命令，之后才能愉快的玩耍，唉！如果无线网卡能自动连接AP并且自动分配IP地址就好了。人类就是这么懒惰（当然也可以说是为了提高用户体验），而懒惰也不断的推进技术的进步。本文主要描述Debian 8下面，如何配置无线

Linux I2C framework(3)_I2C consumer

Wed, 23 Mar 2016 22:05:01 +0800

本文从I2C consumer的角度，介绍怎么在linux中，利用I2C framework提供的接口，编写I2C slave device的驱动程序。

systemd：为何要创建一个新的init系统软件

Thu, 17 Mar 2016 18:27:07 +0800

当我把我的电脑升级到Debian 8的时候，赫然发现旧的SysV init的东西似乎是消失了，取而代之的是systemd。当然，它不是个新东西，只不过一方面多年来我只是关注内核，很少理会用户空间的东西，此外，公司的操作系统始终封存在linux2.6.23上，各种rootfs的software package也从未升级，因此我已经和世界脱轨了。不过没有关系，活到老学到老，本文主要解决一个问题：多年

蓝牙协议分析(3)_蓝牙低功耗(BLE)协议栈介绍

Sat, 12 Mar 2016 22:32:44 +0800

通过“ 蓝牙协议分析(2)_协议架构 ”的介绍，大家对蓝牙协议栈应该有了简单的了解，但是，肯定还有“似懂非懂、欲说还休”的感觉。有这种感觉太正常了，毕竟蓝牙协议是一个历史悠久又比较庞大的协议，没那么容易理解。因此，本文将换个视角，从协议栈设计者的角度，思考如下问题：为什么会有蓝牙协议栈（Why）？怎样实现蓝牙协议栈（How）？蓝牙协议栈的最终样子是什么（What）？另外，我们知道，当前的

Debian下的WiFi实验（一）：通过无线网卡连接AP

Tue, 08 Mar 2016 18:42:57 +0800

最近入手了一台T450，顺便在上面安装了Windows和Debian 8。一般而言，在windows下的时候通过WiFi上网毫无压力，当然，做为linuxer，我其实也很少在T450上启动windows，那么问题来了，如何在Debian 8下使用WiFi呢？具体的场景是这样的，我们家的网络是通过ADSL进入internet，ADSL modem的网线连接到了台式机，而台式机经常被夫人霸占，我的

Linux I2C framework(2)_I2C provider

Fri, 26 Feb 2016 22:49:20 +0800

本文从Provider的角度，介绍怎么借助I2C framework管理I2C相关的SOC资源。换句话说，就是怎么编写I2C controller驱动。

Perf book 9.3章节翻译（下）

Fri, 26 Feb 2016 19:36:43 +0800

本文主要是对perfbook 9.3章节的翻译的下半部分，督促自己学习，也顺便分享给大家。本文的英文原文来自perfbook-1c.2015.01.31a.pdf ，为了读者方便，我也嵌入到了文档中，任何问题，欢迎探讨。

Perf book 9.3章节翻译（上）

Thu, 18 Feb 2016 19:07:52 +0800

本文主要是对perfbook 9.3章节的翻译，督促自己学习，也顺便分享给大家。本文的英文原文来自perfbook-1c.2015.01.31a.pdf ，为了读者方便，我也嵌入到了文档中，任何问题，欢迎探讨。

Linux I2C framework(1)_概述

Sun, 14 Feb 2016 22:01:19 +0800

I2C协议是嵌入式系统中广泛使用的一类通信协议，主要用于CPU和各种外设之间的低速数据通信。Linux kernel使用I2C framework抽象、管理相应的资源，并以各种形式，向各类使用者提供API。另外，作为总线（bus）的一种，I2C framework的实现体现了 linux设备模型的精髓，值得研究与学习。这就是攥写“Linux I2C framework”系列文章的缘由和目的。按

Linux2.6.23 ：sleepable RCU的实现

Thu, 04 Feb 2016 18:38:06 +0800

由于曾经在Linux2.6.23上工作了多年，我对这个版本还是非常有感情的（抛开感情因素，本来应该选择longterm的2.6.32版本来分析的，^_^），本文主要就是描述Linux2.6.23内核版本中对RCU有哪些修正。所谓修正主要包括两个部分，一部分是bug fixed，一部分是新增的特性。

显示技术介绍(3)_CRT技术

Sat, 30 Jan 2016 22:18:21 +0800

CRT（Cathode Rays Tube，阴极射线管）是最原始的电子显示技术，在上世纪被广泛运用于模拟电视（Analog television）系统中。本文将以模拟电视系统为背景，介绍CRT显示技术的原理、特性以及一些关键术语。众所周知，CRT显示已经逐步被数字显示取代，已有退出历史舞台之势，本文之所以介绍它，原因有三： 1）模拟电视是我们这一代人童年的记忆，美好又神秘。现在回头去看，发觉其中

Linux2.6.11版本：classic RCU的实现

Wed, 27 Jan 2016 18:31:58 +0800

无论你愿意或者不愿意，linux kernel的版本总是不断的向前推进，做为一个热衷于专研内核的工程师，最大的痛苦莫过于此：当你熟悉了一个版本的内核之后，内核已经推进到一个新的版本，你曾经熟悉的内容可能会变得陌生（这里主要说的是该模块的内部实现，实际上，内核中的每一个子系统都是会尽量保持接口API的不变）。怎么应对这种变化呢？一方面，具体的实现可能千差万别，但是基本的概念是一样的，无论哪一个版

Linux 2.5.43版本的RCU实现（废弃）

Tue, 19 Jan 2016 12:13:03 +0800

RCU的工作原理虽然简单，但是实现产品级别的RCU同步机制并不是一个简单的事情，看看目前kernel中庞大的RCU数据结构，这让我望而却步。蜗窝科技在撰写其他文档的时候，往往喜欢使用最新的内核，本文和其他文章不一样，本文选择了第一个引入RCU的内核版本，即2.5.43。本文主要介绍了linux2.5.43版本上的RCU实现。

蓝牙协议分析(2)_协议架构

Thu, 14 Jan 2016 22:20:28 +0800

本文是蓝牙协议分析的第二篇文章，在“ 蓝牙协议分析(1)_基本概念 ”的基础上，从整体架构的角度，了解蓝牙协议的组成，以便加深对蓝牙的理解。

perfbook memory barrier（14.2章节）中文翻译（下）

Mon, 11 Jan 2016 19:26:48 +0800

终于完成了perfbook中所有关于memory barrier的内容了，站在当前的时间点上，回头看看翻译perfbook之前的我，那时候是多么的幼稚，对memory barrier理解多么肤浅。当然，也许随着时间的流逝，5年之后才回头看看今天的我，也会发现：即便是通读了perfbook的memory barrier的内容，其实仍然肤浅，仍然没有理解其精髓。究其原因，一方面，学习的过程总是螺旋式

Why Memory Barriers中文翻译（下）

Tue, 05 Jan 2016 18:09:04 +0800

在上一篇 why memory barriers 文档中，由于各种原因，有几个章节没有翻译。其实所谓的各种原因总结出一句话就是还没有明白那些章节所要表达的内容。当然，对于一个真正的热爱钻研的 linuxer，不理解的那些章节始终都是一块心病。终于，在一个月黑风高的夜晚，我发了一封邮件给perfbook的作者Paul，请其指点一二。果然是水平越高越平易近人，很快，大神回复了，给出了一些他的意见，

Linux graphic subsystem(2)_DRI介绍

Sun, 27 Dec 2015 22:02:31 +0800

上篇文章（ Linux graphic subsytem(1)_概述）介绍了linux图形子系统基本的软件框架，以及GUI、Windowing system、3D渲染等基本概念。文中提到了linux DRI（Direct Render Infrastructure）框架，但限于篇幅，没有过多介绍。蜗蜗觉得，DRI在当前（或者说将来）的linux图形子系统中，有着举足轻重的地位，甚至可以说是新的

perfbook memory barrier（14.2章节）的中文翻译（上）

Fri, 25 Dec 2015 12:18:24 +0800

perfbook是一本值得反复阅读的好书，这一点是毋庸置疑的，不过你是选择阅读中文版本还是英文版本呢？当然，阅读中文版本相对要简单一些，毕竟是母语，而且最重要的是阅读速度快（注：perfbook已经有了中文版本的翻译，叫做《深入理解并行编程V2.0》，多谢谢宝友/鲁阳/陈渝的辛苦劳动），其实，每次遇到“快”的时候，我都本能的都要停下来再思考一下，我担心欲速则不达。知识的获取不可能是快的，就像看

slub分配器

Mon, 21 Dec 2015 18:51:38 +0800

Linux 的物理内存管理采用了以页为单位的 buddy system （伙伴系统），但是很多情况下，内核仅仅需要一个较小的对象空间，而且这些小块的空间对于不同对象又是变化的、不可预测的，所以需要一种类似用户空间堆内存的管理机制 (malloc/free) 。然而内核对对象的管理又有一定的特殊性，有些对象的访问非常频繁，需要采用缓冲机制；对象的组织需要考虑硬件 cache 的影响；需要考虑多处理器

Linux graphic subsytem(1)_概述

Thu, 17 Dec 2015 22:21:48 +0800

图形子系统是linux系统中比较复杂的子系统之一：对下，它要管理形态各异的、性能各异的显示相关的器件；对上，它要向应用程序提供易用的、友好的、功能强大的图形用户界面（GUI）。因此，它是linux系统中少有的、和用户空间程序（甚至是用户）息息相关的一个子系统。本文是图形子系统分析文章的第一篇，也是提纲挈领的一篇，将会从整体上，对linux图形子系统做一个简单的概述，进而罗列出显示子系统的软件构成

Why Memory Barriers？中文翻译（上）

Thu, 10 Dec 2015 19:11:02 +0800

本文是对perfbook的附录C Why Memory Barrier的翻译，希望通过对大师原文的翻译可以弥补之前译者发布的关于memory barrier的一篇很拙劣的文章的遗憾。本文的翻译不是一一对应的翻译，主要是领会精神，用自己的语言表述，最优先保证的是中文表述的流畅而不是和原文保持一致（希望可以做到）。由于水平有限，欢迎指正。

Linux内核同步机制之（七）：RCU基础

Thu, 03 Dec 2015 12:57:38 +0800

关于RCU的文档包括两份，一份讲基本的原理（也就是本文了），一份讲linux kernel中的实现。第二章描述了为何有RCU这种同步机制，特别是在cpu core数目不断递增的今天，一个性能更好的同步机制是如何解决问题的，当然，再好的工具都有其适用场景，本章也给出了RCU的一些应用限制。第三章的第一小节描述了RCU的设计概念，其实RCU的设计概念比较简单，比较容易理解，比较困难的是产品级别的RC

显示技术介绍(2)_电子显示的前世今生

Mon, 30 Nov 2015 22:19:53 +0800

从1907年证实CRT（Cathode Ray Tube）技术可用于电视显示至今，电子显示技术经历了近100年的发展。100年的时间，说长不长，说短也不短；显示技术的发展，说快不快，说慢也不慢。 CRT技术是最原始的显示技术，但它的生命周期一直持续到2000年后，随着LCD（Liquid Crystal Display）的普及才逐渐退出历史舞台，跨度近90年，这是“不快”的由来。而最近10年，各

ARM64的启动过程之（六）：异常向量表的设定

Tue, 24 Nov 2015 18:22:09 +0800

本文主要描述了4.1.10内核初始化过程中如何初始化异常向量表。当然，首先需要准备一些异常的基础知识，这主要在第二章，如果你非常熟悉 ARM64的异常，那么可以忽略这个章节。第三章描述了ARM64上各种形形色色的异常，第四章描述了ARM64上硬件提供的协助，最后一章描述了代码过程。为了简化，本文对所描述的异常进行了限制： 1、所有的exception level的运行状态都是AArch64，不

Linux进程冻结技术

Tue, 24 Nov 2015 15:01:44 +0800

1 什么是进程冻结进程冻结技术（ freezing of tasks ）是指在系统 hibernate 或者 suspend 的时候，将用户进程和部分内核线程置于“可控”的暂停状态。 2 为什么需要冻结技术假设没有冻结技术，进程可以在任意可调度的点暂停，而且直到 cpu_down 才会暂停并迁移。这会给系统带来很多问题：

显示技术介绍(1)_概述

Sun, 22 Nov 2015 21:44:02 +0800

本文是显示子系统的第一篇文章，介绍嵌入式系统显示有关的硬件组成，进而拆分为相对独立的模块，以便在后续的文章中一一介绍。

进化论、人工智能和外星人

Sun, 15 Nov 2015 22:16:30 +0800

标题有点混乱，主要是最近看书有些杂，从而使一些由来已久的疑惑渐有开朗之势，故而在这儿胡言乱语一番。

linux kernel内存回收机制

Thu, 12 Nov 2015 20:37:32 +0800

无论计算机上有多少内存都是不够的，因而 linux kernel 需要回收一些很少使用的内存页面来保证系统持续有内存使用。页面回收的方式有页回写、页交换和页丢弃三种方式：如果一个很少使用的页的后备存储器是一个块设备（例如文件映射），则可以将内存直接同步到块设备，腾出的页面可以被重用；如果页面没有后备存储器，则可以交换到特定 swap 分区，再次被访问时再交换回内存；如果页面的后备存储器是一个文件，

linux cpufreq framework(5)_ARM big Little driver

Tue, 10 Nov 2015 22:04:33 +0800

也许大家会觉得奇怪：为什么Linux kernel把对ARM big·Lttile的支持放到了cpufreq的框架中？众所周知，ARM的big·Little架构，也称作HMP（具体可参考“ Linux CPU core的电源管理(2)_cpu topology ”中相关的介绍），通过在一个chip中封装两种不同类型的ARM core的方式，达到性能和功耗的平衡。这两类ARM Core，以clus

實作 spinlock on raspberry pi 2

Thu, 05 Nov 2015 09:33:36 +0800

process 同步機制有 spinlock, mutex, semaphore, 我的學習方式是簡化再簡化, 然後用程式碼實作他們, 否則我只會有「名詞」上的理解, 而不會真的理解。有了 spinlock 就有了基本的 process 同步機制。

linux kernel内存碎片防治技术

Mon, 02 Nov 2015 10:24:54 +0800

Linux kernel 组织管理物理内存的方式是 buddy system （伙伴系统），而物理内存碎片正式 buddy system 的弱点之一，为了预防以及解决碎片问题， kernel 采取了一些实用技术，这里将对这些技术进行总结归纳。

ARM64的启动过程之（五）：UEFI

Fri, 30 Oct 2015 19:27:58 +0800

在准备大刀阔斧进入start_kernel之际，我又重新review了一下head.S文件，看看是否有一些遗漏的知识点，很不幸，看到了 CONFIG_EFI这个配置项。当然，在一年前阅读kernel代码的时候就了解过相关的内容，但是，做为一个嵌入式工程师总是或多或少对其有些排斥，因此习惯性的忽略掉CONFIG_EFI相关的代码，逃避总不是办法，在本文中，我们一起来探讨ARM64平台上UEFI相关

Linux 3.18U盘无法正确使用

Wed, 28 Oct 2015 16:20:29 +0800

U盘插入时，内核能正确识别到，但是无法挂载，查看dev下的设备文件为字符设备，而不是块设备：打印如下： usb 1-2: new high-speed USB device number 3 using atmel-ehci Can not be start read in 1s usb 2-2: new full-speed USB device number 3 using at91\ohc

RCU synchronize原理分析

Tue, 27 Oct 2015 19:10:56 +0800

RCU （ Read-Copy Update ）是 Linux 内核比较成熟的新型读写锁，具有较高的读写并发性能，常常用在需要互斥的性能关键路径。在 kernel 中， rcu 有 tiny rcu 和 tree rcu 两种实现， tiny rcu 更加简洁，通常用在小型嵌入式系统中， tree rcu 则被广泛使用在了 server, desktop 以及 android 系统中。本文将以 t

作業系統之前的程式 for rpi2 (1) - mmu (0) : 位址轉換

Tue, 27 Oct 2015 09:00:58 +0800

stm32f4discovery 是很好的 os 練習平台, 不過沒有 mmu 是我覺得可惜的部份, 而 raspberrypi 2 正好可以補足這部份, 然而 rpi2 我目前還不知道怎麼使用 jtag, 在除錯上會比較麻煩, 得用冥想的。沒想到第二個 bare-metal rpi2 程式就要搞 mmu 了, 感覺很硬斗, 我自己覺得還好, 畢竟我已經累積了不少經驗/知識。這就是累積的力量

ARM64的启动过程之（四）：打开MMU

Sat, 24 Oct 2015 12:35:07 +0800

经过漫长的前戏，我们终于迎来了打开MMU的时刻，本文主要描述打开MMU以及跳转到start_kernel之前的代码逻辑。这一节完成之后，我们就会离开痛苦的汇编，进入人民群众喜闻乐见的c代码了。

ARM64的启动过程之（三）：为打开MMU而进行的CPU初始化

Wed, 21 Oct 2015 19:32:14 +0800

上一节主要描述了为了打开MMU而进行的Translation table的建立，本文延续之前的话题，主要是进行CPU的初始化（注：该初始化仅仅为是为了turn on MMU）。本文主要分析ARM64初始化过程中的__cpu_setup函数，代码位于arch/arm64/mm/proc.S中。主要的内容包括： 1、cache和TLB的处理 2、Memory attributes lookup ta

ARM64的启动过程之（二）：创建启动阶段的页表

Tue, 13 Oct 2015 18:18:49 +0800

本文主要描述了ARM64启动过程中，如何建立初始化阶段页表的过程。我们知道，从bootloader到kernel的时候，MMU是off的（顺带的负作用是无法打开data cache），为了提高性能，加快初始化速度，我们必须某个阶段（越早越好）打开MMU和cache，而在此之前，我们必须要设定好页表。在初始化阶段，我们mapping三段地址，一段是identity mapping，其实就是把物

Linux PWM framework(1)_简介和API描述

Sun, 11 Oct 2015 15:45:37 +0800

PWM是Pulse Width Modulation（脉冲宽度调制）的缩写，是利用微处理器的数字输出来对模拟电路进行控制的一种非常有效的技术，其本质是一种对模拟信号电平进行数字编码的方法。在嵌入式设备中，PWM多用于控制马达、LED、振动器等模拟器件。 PWM framework是kernel为了方便PWM driver开发、PWM使用而抽象出来的一套通用API，之所以要分析该framework，

ARM64的启动过程之（一）：内核第一个脚印

Sat, 10 Oct 2015 15:06:00 +0800

kernel的整个启动过程涉及的内容很多，不可能每一个细节都描述清楚，因此我打算针对部分和ARM64相关的启动步骤进行学习、整理，并方便后续查阅。本文实际上描述在系统启动最开始的时候，bootloader和kernel的交互以及kernel如何保存bootloader 传递的参数并进行校验，此外，还有一些最基础的硬件初始化的内容。本文中的source来自4.1.10内核，这是一个long te

Linux vm运行参数之（二）：OOM相关的参数

Mon, 28 Sep 2015 12:10:53 +0800

本文是描述Linux virtual memory运行参数的第二篇，主要是讲OOM相关的参数的。为了理解OOM参数，第二章简单的描述什么是OOM。如果这个名词对你毫无压力，你可以直接进入第三章，这一章是描述具体的参数的，除了描述具体的参数，我们引用了一些具体的内核代码，本文的代码来自4.0内核，如果有兴趣，可以结合代码阅读，为了缩减篇幅，文章中的代码都是删减版本的。按照惯例，最后一章是参考文献

Linux vm运行参数之（一）：overcommit相关的参数

Wed, 23 Sep 2015 18:54:26 +0800

终于可以进入Linux kernel内存管理的世界了，但是从哪里入手是一个问题，当面对一个复杂系统的时候，有时候不知道怎么开始。遵守“一切以人为本”的原则，我最终选择先从从userspace的视角来看内核的内存管理。最开始的系列文章选择了vm运行参数这个主题。执行ls /proc/sys/vm的命令，你可以看到所有的vm运行参数，本文选择了overcommit相关参数来介绍。本文的代码来自4.

Linux CPU core的电源管理(5)_cpu control及cpu hotplug

Sat, 19 Sep 2015 21:39:12 +0800

由“ Linux CPU core的电源管理(1)_概述 ”的描述可知，kernel cpu control位于“.\kernel\cpu.c”中，是一个承上启下的模块，负责屏蔽arch-dependent的实现细节，向上层软件提供控制CPU core的统一API（主要包括cpu_up/cpu_down等接口的实现）。本文将基于这些API，从上到下，分析CPU core从启动到关闭的整个过程（主要

Linux内核同步机制之（六）：Seqlock

Wed, 09 Sep 2015 11:55:00 +0800

普通的spin lock对待reader和writer是一视同仁，RW spin lock给reader赋予了更高的优先级，那么有没有让writer优先的锁的机制呢？答案就是seqlock。本文主要描述linux kernel 4.0中的seqlock的机制，首先是seqlock的工作原理，如果想浅尝辄止，那么了解了概念性的东东就OK了，也就是第二章了，当然，我还是推荐普通的驱动工程师了解seq

linux cpufreq framework(4)_cpufreq governor

Sun, 23 Aug 2015 21:15:39 +0800

由“ linux cpufreq framework(3)_cpufreq core ”的描述可知，cpufreq policy负责设定cpu调频的一个大致范围，而cpu的具体运行频率，则需要由相应的cufreq governor决定（可自行调节频率的CPU除外，后面会再详细介绍）。那到底什么是cpufreq governor？它的运行机制是什么？这就是本文要描述的内容。

Concurrency Managed Workqueue之（四）：workqueue如何处理work

Mon, 17 Aug 2015 19:41:51 +0800

本文主要讲述下面两部分的内容： 1、将work挂入workqueue的处理过程 2、如何处理挂入workqueue的work

Concurrency Managed Workqueue之（三）：创建workqueue代码分析

Thu, 06 Aug 2015 18:22:41 +0800

本文主要以__alloc_workqueue_key函数为主线，描述CMWQ中的创建一个workqueue实例的代码过程。

Concurrency Managed Workqueue之（二）：CMWQ概述

Fri, 31 Jul 2015 12:29:13 +0800

一种新的机制出现的原因往往是为了解决实际的问题，虽然linux kernel中已经提供了workqueue的机制，那么为何还要引入cmwq呢？也就是说：旧的workqueue机制存在什么样的问题？在新的 cmwq又是如何解决这些问题的呢？它接口是如何呈现的呢（驱动工程师最关心这个了）？如何兼容旧的驱动呢？本文希望可以解开这些谜题。本文的代码来自linux kernel 4.0。

linux cpufreq framework(3)_cpufreq core

Thu, 30 Jul 2015 20:58:12 +0800

前文（ Linux cpufreq framework(2)_cpufreq driver ）从平台驱动工程师的角度，简单的介绍了编写一个cpufreq driver的大概步骤。但要更深入理解、更灵活的使用，必须理解其内部的实现逻辑。因此，本文将从cpufreq framework core的角度，对cpufreq framework的内部实现做一个简单的分析。

总结Linux kernel开发中0的巧妙使用

Mon, 20 Jul 2015 17:53:46 +0800

kernel的源代码中，有很多令人拍案叫好的用法，此文简单总结了一下，我所知道的0的巧妙用法，权当抛砖引玉，希望能激发起读者相当更多的0的用法。

Linux CPU core的电源管理(3)_cpu ops

Fri, 17 Jul 2015 22:15:06 +0800

由“ ARMv8-a架构简介 ”中有关的介绍可知，ARMv8（包括ARMv7的一些扩展）引入了Virtualization、Security等概念。在这些概念之下，传统的CPU boot、shutdown、reset、suspend/resume等操作，不再那么简单和单纯。因此，ARM将这些底层操作抽象为一些operations，在以统一的方式向上层软件提供API的同时，可以根据不同的场景，有不同

Concurrency Managed Workqueue之（一）：workqueue的基本概念

Wed, 15 Jul 2015 18:47:28 +0800

workqueue是一个驱动工程师常用的工具，在旧的内核中（指2.6.36之前的内核版本）workqueue代码比较简单（大概800行），在2.6.36内核版本中引入了CMWQ（Concurrency Managed Workqueue），workqueue.c 的代码膨胀到5000多行，为了深入的理解CMWQ，单单一份文档很难将其描述的清楚，因此CMWQ作为一个主题将会产生一系列的文档，本文是这

ARMv8-a架构简介

Tue, 07 Jul 2015 22:31:00 +0800

ARMv8（当前只有A系列，即ARMv8-A）架构，是ARM公司为满足新需求而重新设计的一个架构，是近20年来，ARM架构变动最大的一次。它引入的Execution State、Exception Level、Security State等新特性，已经和我们对旧的ARM架构的认知，有很大差距了。因此，本文从ARMv8-A产生的背景开始，对它进行一个简单的介绍，使大家从整体上，对ARMv8有一个简

linux kernel的中断子系统之（九）：tasklet

Thu, 02 Jul 2015 18:10:49 +0800

对于中断处理而言，linux将其分成了两个部分，一个叫做中断handler（top half），属于不那么紧急需要处理的事情被推迟执行，我们称之deferable task，或者叫做bottom half，。具体如何推迟执行分成下面几种情况： 1、推迟到top half执行完毕 2、推迟到某个指定的时间片（例如40ms）之后执行 3、推迟到某个内核线程被调度的时候执行对于第一种情况，内核中的机制

Linux cpufreq framework(2)_cpufreq driver

Fri, 19 Jun 2015 22:27:34 +0800

本文从平台驱动工程师的角度，介绍怎么编写cpufreq驱动。注1：本文基于 linux-3.18-rc4 内核，其它版本内核可能会稍有不同。

linux cpufreq framework(1)_概述

Sat, 13 Jun 2015 22:20:37 +0800

linux kernel主要通过三类机制实现SMP系统CPU core的电源管理功能： 1）cpu hotplug。根据应用场景，enable/disable CPU core，具体可参考“Linux CPU core的电源管理(4)_cpu control”。 2） cpuidle framework。在没有进程调度的时候，让CPU core进入idle状态，具体可参考“ cpuidle fra

Linux电源管理(15)_PM OPP Interface

Thu, 04 Jun 2015 21:54:14 +0800

本文是分析cpufreq framework之前的一篇前置文章，用于介绍Linux电源管理中的Operating Performance Point (OPP)接口。 OPP是一个单纯的软件library，用于归纳、管理各个硬件模块的、可工作的｛频率｝/ ｛电压｝组合。它不涉及任何硬件，也没有复杂的逻辑，再加上Kernel document（Documentation/power/opp.txt

Linux CPU core的电源管理(2)_cpu topology

Sat, 30 May 2015 21:58:55 +0800

在“ Linux CPU core的电源管理(1)_概述 ”中，我们多次提到SMP、CPU core等概念，虽然硬着头皮写下去了，但是蜗蜗对这些概念总有些似懂非懂的感觉。它们和CPU的进化过程息息相关，最终会体现在CPU topology（拓扑结构）上。因此本文将以CPU topology为主线，介绍CPU有关（主要以ARM CPU为例）的知识。另外，CPU topology除了描述CPU的组成

msm8994 热插拔sim卡导致modem重新启动的流程

Thu, 28 May 2015 15:23:01 +0800

本文分析了msm8994 热插拔sim卡导致modem重新启动的流程，希望对大家有所帮助。

关于蜗窝

Thu, 28 May 2015 14:34:27 +0800

“蜗蜗”从事嵌入式Linux开发工作将近5年了，对博大精深的Linux而言，5年不算多，但对国内Linux技术的现状而言，5年也不算少。还依稀记得，09年为投奔Linux的怀抱，从北国那个风景迷离的滨海小城，义无反顾的来到这个喧嚣的大都市。其实，那是用一个梦想—-面朝大海，春暖花开，换另一个梦想—-Linux技术。这5年来，收获颇丰，从入门，到熟悉，再到有自己的想法，“蜗蜗”在Linux

Linux内核同步机制之（五）：Read/Write spin lock

Fri, 22 May 2015 18:38:22 +0800

在有了强大的spin lock之后，为何还会有rw spin lock呢？无他，仅仅是为了增加内核的并发，从而增加性能而已。spin lock严格的限制只有一个thread可以进入临界区，但是实际中，有些对共享资源的访问可以严格区分读和写的，这时候，其实多个读的thread进入临界区是OK的，使用spin lock则限制一个读thread进入，从而导致性能的下降。本文主要描述RW spin l

Linux时间子系统之（十四）：tick broadcast framework

Thu, 21 May 2015 19:26:10 +0800

在内核中，有cpuidle framework可以控制cpu的节电：当没有进程调度到该cpu上执行的时候，swapper进程粉墨登场，将该cpu会被推入到idle状态。当然 CPU的idle状态有深有浅，当CPU睡的比较深入的时候，有可能会关闭本地的timer硬件。这样就会引入一个很有意思的问题：local timer将无法唤醒CPU，该cpu上的所有的software timer将无法唤醒cpu

Linux下“用户空间修改设备寄存器或者物理内存”的实现

Fri, 15 May 2015 11:21:24 +0800

底层开发过程中，经常需要在终端查看或者修改设备寄存器的值，busybox有一个工具—-devmem，可用于读取或者修改物理寄存器的值，非常方便。但它有一个不足的地方：不能连续操作物理内存（虽然这很危险，但在显示相关的调试中，如果能向指定的物理内存加载一个图片，或者dump指定物理内存的内容，还是很方便的），因此我重新写了一些代码，实现如下功能。

关于内核中的乘法和除法。

Wed, 06 May 2015 22:02:28 +0800

前几天一直在看wowo的时间子系统，一直在思索mult和shift变量，为什么mult要尽量大，shift尽量小。这是由c语言的整数算术运算决定的。 cyn\ mult > shift 在不考虑溢出的情况下，cyn \ mult没有误差，右移shift有误差，损失小数。但是如果cyn > shift \ mult 在不考虑溢出的情况下，误差就会被放大。 10\ 12 / 8 = 15 10 /

Linux CPU core的电源管理(1)_概述

Thu, 30 Apr 2015 21:20:49 +0800

在SMP（Symmetric Multi-Processing）流行起来之前的很长一段时间，Linux kernel的电源管理工作主要集中在外部设备上，和CPU core相关的，顶多就是 CPU idle 。但随着SMP的普及，一个系统中可用的CPU core越来越多，这些core的频率越来越高，处理能力越来越强，功耗也越来越大。因此，CPU core有关的电源管理，在系统设计中就成为必不可少的一

kernel启动优化

Thu, 30 Apr 2015 08:42:26 +0800

本文主要讨论和linux kernel启动优化相关的内容，由于老衲技术水平有限，以下梦话可能会有很多漏洞，希望各位大拿发现bug后，以强大的知识理论碾压老衲，让贫僧能在痛苦中疯狂成长。

蜗窝流量地域统计

Thu, 23 Apr 2015 12:39:39 +0800

针对蜗窝的来自各个省份的访问统计，很有意思，大家可以随意感受一下

Linux内核同步机制之（四）：spin lock

Wed, 22 Apr 2015 12:22:24 +0800

在linux kernel的实现中，经常会遇到这样的场景：共享数据被中断上下文和进程上下文访问，该如何保护呢？如果只有进程上下文的访问，那么可以考虑使用 semaphore或者mutex的锁机制，但是现在中断上下文也参和进来，那些可以导致睡眠的lock就不能使用了，这时候，可以考虑使用spin lock。本文主要介绍了linux kernel中的spin lock的原理以及代码实现。由于spin

spin_lock最简单用法。

Fri, 17 Apr 2015 10:13:32 +0800

最近在思考一个spin\lock的用法，比如在smp系统中，在一个内核控制路径的函数中有一个局部静态变量，对这个局部静态变量有判断，算术运算。那么我们是否要对这个局部静态变量使用spin\lock锁呢？个人意见：需要使用，因为在smp系统中，多个内核控制路径可能同时访问该变量。所谓的共享资源，并不只是多个函数之间共享，在smp系统有可能是自己和自己共享。欢迎大家拍砖。

Linux Regulator Framework(2)_regulator driver

Thu, 16 Apr 2015 22:18:58 +0800

本文从regulator driver的角度，描述怎样基于regulator framework编写regulator驱动。同时，以此为契机，学习、理解regulator有关的物理特性，以便能够更好的使用它们。

linux usb 摄像头测试

Sun, 12 Apr 2015 12:40:35 +0800

在调试一款linux下的usb摄像头，通过配置内核已经支持，log信息如下想要通过luvcview测试下，但是编译时总是通不过，把头文件#include 改成了videodev2.h还是通不过，不知道luvcview能不能在linux3.14下运行？各位是否有什么好的测试摄像头的方法或软件？能否提供下，小弟先行谢过。

ARM CPU性能实验

Thu, 09 Apr 2015 18:13:27 +0800

一般工程师的直觉是当提升了CPU的运行频率，那么性能应该是呈现线性的关系，例如如果CPU跑260MHz，当降低到130MHz后，其性能应该会降低一半。实际情况如何呢？我们来做一个实验看看。

linux 串口调试方法

Wed, 08 Apr 2015 16:41:38 +0800

最近项目上用到linux下的串口，与下级模块的通信出了些问题，所以写了个小程序想要测试下串口，物理连接是PC端串口调试助手通过usb转串口线接到板子的uart，最终的效果是，板子的uart能发不能收，发出去的数据在PC端可以接收到，PC端串口调试助手发送到板子uart的信息，uart不能接收，read函数一直返回-1. 所以想请教下各位有没有什么好的方法测试一下linux的串口？

Linux时间子系统之（十三）：Tick Device layer综述

Thu, 26 Mar 2015 18:50:55 +0800

时间子系统中的tick device layer主要涉及kernel/time/tick-*相关的文件，本文的主要内容就是从high level层次（不纠缠在具体的每行代码）描述tick device layer的运作逻辑。如果说每个.c文件是一个模块的话，我们可以首先简单描述tick device layer的各个模块。tick-common.c描述了tick device的一些通用操作，此

对heziq网友问题的回答

Mon, 23 Mar 2015 19:03:53 +0800

heziq网友在《 linux kernel的中断子系统之（四）：High level irq event handler 》文档中提出了若干个问题，由于在回复中无法图形表达，因此单独出一份文档来回答，希望可以有所帮助。当然，由于他提出的问题和硬件电路设计有关，这里我只是表达我自己的观点（毕竟出身是软件工程师），如果有误，请不吝指出。

Linux Regulator Framework(1)_概述

Fri, 20 Mar 2015 21:42:00 +0800

Regulator，中文名翻译为“稳定器”，在电子工程中，是voltage regulator（稳压器）或者current regulator（稳流器）的简称，指可以自动维持恒定电压（或电流）的装置。 voltage regulator最早应用于功放电路中，主要用于滤除电源纹波（100或者120Hz）和噪声，以及避免“输出电压随负载的变化而变化”的情况。后来，随着IC级别的regulator的出现

Linux power supply class(1)_软件架构及API汇整

Fri, 13 Mar 2015 22:14:23 +0800

power supply class为编写供电设备（power supply，后面简称PSY）的驱动提供了统一的框架，功能包括： 1）抽象PSY设备的共性，向用户空间提供统一的API。 2）为底层PSY驱动的编写，提供简单、统一的方式。同时封装并实现公共逻辑，驱动工程师只需把精力集中在和硬件相关的部分即可。本文将从设计思路、软件架构、API说明以及怎么编写power supply driver四

计算机科学基础知识之（六）：理解栈帧

Thu, 12 Mar 2015 13:00:22 +0800

本文以一个简单的例子来描述ARM linux下的stack frame。本文也是对tigger网友问题的回复。

计算机科学基础知识（五）: 动态链接

Tue, 10 Mar 2015 18:15:32 +0800

本文以类似hello world这样的简单程序为例，描述了动态连接的概念。第二章描述了整个动态链接的大概过程，随后的两章解析了程序访问动态库中的数据和调用动态库中函数的过程。注意：阅读本文之前需要先了解 relocatable object file 、静态链接以及动态库和PIC 这些内容。

Linux时间子系统之（二）：软件架构

Sat, 07 Mar 2015 18:37:48 +0800

本文的主要内容是描述内核时间子系统的软件框架。首先介绍了从旧的时间子系统迁移到新的时间子系统的源由，介绍新的时间子系统的优势。第三章汇整了时间子系统的相关文件以及内核配置。最后描述各种内核配置下的时间子系统的数据流和控制流。

计算机科学基础知识（四）: 动态库和位置无关代码

Fri, 06 Mar 2015 09:39:38 +0800

本文主要描述了动态库以及和动态库有紧密联系的位置无关代码的相关资讯。首先介绍了动态库和位置无关代码的源由，了解这些背景知识有助于理解和学习动态库。随后，我们通过加-fPIC和不加这个编译选项分别编译出两个relocatable object file，看看编译器是如何生成位置无关代码的。最后，我们自己动手编写一个简单的动态库，并解析了一些symbol Visibility、动态符号表等一些相关基

Linux电源管理(14)_从设备驱动的角度看电源管理

Mon, 02 Mar 2015 22:53:52 +0800

相信工作稍微久一点的linux驱动工程师都深有体会：在旧时光里，实现某一个设备的电源管理功能，是非常简单的一件事情。大多数设备都被抽象为platform设备，driver只需要提供suspend/resume/shutdown等回调函数，并注册到kernel即可。kernel会在系统电源状态切换的过程中，调用driver提供的回调函数，切换设备的电源状态。但是在新时代中，设备电源管理有关的操作

Linux PM QoS framework(3)_per-device PM QoS

Thu, 26 Feb 2015 22:44:26 +0800

per-device PM QoS是针对指定设备的QoS framework，背后的思考如下： 1）resume_latency 在 Runtime PM 的框架下，当device的引用计数减为0的时候，RPM会suspend该device。不过，device进入suspend状态以及从suspend状态resume是需要消耗时间的（相关信息保存在 pm domain 中），而系统其它实体（如用户

支持wowo，有这样一块小天地享受技术，感觉棒棒哒！

Wed, 25 Feb 2015 00:21:02 +0800

希望以后都可以没事来看一看，玩一玩，和wowo以及朋友们讨论一些问题！

计算机科学基础知识（三）:静态库和静态链接

Mon, 16 Feb 2015 15:15:07 +0800

本文是编译、链接和加载系列文章中的第二篇，主要描述静态链接

Linux PM QoS framework(2)_PM QoS class

Tue, 10 Feb 2015 23:09:56 +0800

回顾上一篇文章（ Linux PM QoS framework(1)_概述和软件架构），PM QoS framework抽象出4个系统级别的QoS constraint（统称为PM QoS class），分别是cpu&dma latency、network latency、network throughput和memory bandwidth。并提供一系列的接口，动态的搜集、整理系统对这些con

计算机科学基础知识（二）:Relocatable Object File

Mon, 09 Feb 2015 19:17:08 +0800

一个合格的c程序员（也可以叫做软件工程师，这样看起来更高大上，当然，我老婆心情不好的时候总是叫我“死打字的”，基本也能描述这份职业，呵呵）需要理解编译、链接和加载的过程，而不是仅仅关注c语言的语法和词法。本文主要以此为切入点，描述linux系统下，一个普通的hello world程序的生命历程，并借机灌输一些程序编译时和运行时的基本术语和概念。当然，由于我本人是一个linuxer，因此借用lin

Linux PM QoS framework(1)_概述和软件架构

Wed, 04 Feb 2015 23:06:09 +0800

QOS为Quality Of Service（服务质量）的简称，对PM QoS而言，表示Linux kernel电源管理相关的服务质量。那到底什么是服务质量呢？我们知道，Linux PM的主要功能，是节省功耗，但同时，会付出一定的性能代价，例如延迟（latency）增加、吞吐量（throughput）下降。可以把PM当作一种服务，把它对性能的影响，类比为服务的质量（QoS）。对性能的影响越大，Q

Linux时间子系统之（六）：POSIX timer

Thu, 22 Jan 2015 18:12:26 +0800

在用户空间接口函数文档中，我们描述了和POSIX timer相关的操作，主要包括创建一个timer、设定timer、获取timer的状态、获取timer overrun的信息、删除timer。本文将沿着这些用户空间的接口定义来看看内核态的实现。虽然POSIX timer可以基于各种不同的clock创建，本文主要描述real time clock相关的timer。本文第二章描述了POSIX

“极致”神话和产品观念

Mon, 19 Jan 2015 15:30:36 +0800

产品真的有“极致”吗？按照极致的思路来打造产品真的靠谱吗？为什么说创业企业搞极致就是自杀？为什么产品经理讲极致就是作？产品的天性，只是迎合消费者的需要，体现技术的价值而已，无他。其实这些问题我都回答不出来，仅以一篇《程序员》杂志纸质版的最后一刊，2014年12刊上的我的文章和大家讨论好了。

Linux cpuidle framework(4)_menu governor

Sun, 18 Jan 2015 23:14:50 +0800

本文以menu governor为例，进一步理解cpuidle framework中governor的概念，并学习governor的实现方法。在当前的kernel中，有2个governor，分别为ladder和menu（蜗蜗试图理解和查找，为什么会叫这两个名字，暂时还没有答案）。ladder在periodic timer tick system中使用，menu在tickless system中使

Linux cpuidle framework(3)_ARM64 generic CPU idle driver

Tue, 06 Jan 2015 23:13:03 +0800

本文以ARM64平台下的cpuidle driver为例，说明怎样在cpuidle framework的框架下，编写cpuidle driver。另外，本文在描述cpuidle driver的同时，会涉及到CPU hotplug的概念，因此也可作为CPU hotplug的引子。

Linux时间子系统之（五）：POSIX Clock

Mon, 05 Jan 2015 19:03:50 +0800

clock是timer的基础，任何一个timer都需要运作在一个指定的clock上来。内核中维护了若干的clock，本文第二章描述了clock的基本概念和一些静态定义的posix clock。根据计时的特点，clock分成两种：一种是真实世界的时间概念，另外一个是仅仅计算CPU执行时间，这两种clock分别在第三和第四章描述。从clock的生命周期来看，可以分成静态和动态的posix cloc

我的bash shell学习笔记

Thu, 01 Jan 2015 06:56:12 +0800

本文也即《Learning the bash Shell》3rd Edition的第四章Basic Shell Programming之读书笔记，但我们将不限于此。

Linux cpuidle framework(2)_cpuidle core

Tue, 30 Dec 2014 22:38:33 +0800

cpuidle core是cpuidle framework的核心模块，负责抽象出cpuidle device、cpuidle driver和cpuidle governor三个实体，并提供如下功能（可参考“ Linux cpuidle framework(1)_概述和软件架构 ”中的软件架构）： 1）向底层的cpuidle driver模块提供cpudile device和cpuidle dri

Linux时间子系统之（四）：timekeeping

Mon, 29 Dec 2014 18:03:35 +0800

timekeeping模块是一个提供时间服务的基础模块。Linux内核提供各种time line，real time clock，monotonic clock、monotonic raw clock等，timekeeping模块就是负责跟踪、维护这些timeline的，并且向其他模块（timer相关模块、用户空间的时间服务等）提供服务，而timekeeping模块维护timeline的基础是基

Linux电源管理(13)_Driver的电源管理

Fri, 26 Dec 2014 18:31:51 +0800

首先，回想一下wowo电源管理系列文章中提到的几个PM特性： A. Wake Count/Wake Source B. Wake Lock C. Auto Sleep D. Runtime Suspend 这篇文章就简单简单整理一下以上特性的在Driver中的使用场景，理解可能有偏差，大家多指教。

Linux时间子系统之（三）：用户空间接口函数

Wed, 24 Dec 2014 15:48:59 +0800

从应用程序的角度看，内核需要提供的和时间相关的服务有三种： 1、和系统时间相关的服务。例如，在向数据库写入一条记录的时候，需要记录操作时间（何年何月何日何时）。 2、让进程睡眠一段时间 3、和timer相关的服务。在一段指定的时间过去后，kernel要alert用户进程本文主要描述和时间子系统相关的用户空间接口函数知识。

Linux时间子系统之（一）：时间的基本概念

Tue, 23 Dec 2014 12:22:18 +0800

本文使用Q & A的方式来和大家以前探讨一下时间的基本概念

Linux时间子系统系列文章之目录

Tue, 23 Dec 2014 09:59:18 +0800

本文对近期要撰写的Linux时间子系统的相关文章进行规划。另外，需要说明的是这里的时间概念就是牛顿经典力学中的时间，一般而言，当进入微观领域（例如原子或者各种基本粒子级别）或者宏观领域（整个银河系啊、宇宙大爆炸什么的）的时候，时间变成一个相对的概念，不过还是让物理学家去研究吧。

Linux电源管理(12)_Hibernate功能

Mon, 22 Dec 2014 11:51:14 +0800

本文简要分析了Linux一种Hibernation实现机制——Swap Suspend的是实现方法。本文会尽量从机制出发，不会深入代码分析，如果您感兴趣，可以参照附件给出的流程图，阅读内核代码，相信您也可以找到其中乐趣。 A. Swap Suspend的原因 B. 如何实现STF C. Swap Suspend的关键

Linux cpuidle framework(1)_概述和软件架构

Wed, 17 Dec 2014 23:04:23 +0800

在计算机系统中，CPU的功能是执行程序，总结起来就是我们在教科书上学到的：取指、译码、执行。那么问题来了，如果没有程序要执行，CPU要怎么办？也许您会说，停掉就是了啊。确实，是要停掉，但何时停、怎么停，却要仔细斟酌，因为实际的软硬件环境是非常复杂的。我们回到Linux kernel上，Linux系统中，CPU被两类程序占用：一类是进程（或线程），也称进程上下文；另一类是各种中断、异常的处理程序，

关于spin_lock的问题

Fri, 12 Dec 2014 14:10:09 +0800

spin_lock的分析文章Google一下有很多，这里只是分享一些关于spin_lock思考过的问题。

Linux时间子系统之（十二）：periodic tick

Thu, 11 Dec 2014 18:59:02 +0800

tick device layer是clock event core模块的用户，tick device layer利用clock event core模块提供的接口实现了各种tick device功能：周期性tick、tickless mode、broadcast tick等。本文从最简单的周期性tick开始，描述tick device的基本概念以及周期性tick的工作原理。

ARM WFI和WFE指令

Wed, 10 Dec 2014 22:43:43 +0800

蜗蜗很早以前就知道有WFI和WFE这两个指令存在，但一直似懂非懂。最近准备研究CPU idle framework，由于WFI是让CPU进入idle状态的一种方法，就下决心把它们弄清楚。 WFI(Wait for interrupt)和WFE(Wait for event)是两个让ARM核进入low-power standby模式的指令，由ARM architecture定义，由ARM core实

ARM概念梳理：Architecture, Core, CPU，SOC

Tue, 09 Dec 2014 22:54:05 +0800

本文简单梳理一下ARM有关的概念，包括ARM architecture、ARM core、ARM CPU（或MCU）以及ARM Soc。我们这些以ARM平台为主的嵌入式工程师，几乎每天都会和这些概念打交道，也似乎非常理解它们。但仔细想想，却有些说不清道不明的感觉，因而有必要整理一下思路，也就顺手记录下来了。

Linux时间子系统之（十六）：clockevent

Tue, 09 Dec 2014 19:56:16 +0800

clockevent模块的代码位于linux/kernel/time/clockevents.c，是用来管理系统中的能够触发中断的timer硬件资源的一个模块，该模块的功能分成四个部分： 1）向上层的其它driver（我们称之clock event user）提供操作clock event的通用API。 2）实现clock event控制的通用逻辑，这部分和硬件无关，我们也称之clock eve

为什么会有“ARMv8A Architecture”这个分类

Sat, 06 Dec 2014 15:40:14 +0800

2013年9月11日（是的，911），在ARM公司发布UEFI 64-bit之后，ARM社区release了ARMv8A版本的ARM Architecture Reference Manual（我已经下载，感兴趣的同学可以找我要）。在 release note 中，作者给出了这样一个设问句：“Why develop ARMv8-A?”。本文也效仿一下，以自问自答的形式，说明为什么会在博客中增加这样

kobject在字符设备中的使用

Thu, 04 Dec 2014 18:14:44 +0800

关于kobject的基本概念的描述请参考 Linux设备模型(2)_Kobject 中的描述。本文主要以字符设备为例，描述内核中使用kobject的一个场景，以便加深对kobject这个内核神器的理解。

Linux时间子系统之（十七）：ARM generic timer驱动代码分析

Tue, 02 Dec 2014 10:47:58 +0800

关注ARM平台上timer driver（clocksource chip driver和clockevent chip driver）的驱动工程师应该会注意到timer硬件的演化过程。在单核时代，各个SOC vendor厂商购买ARM core的IP，然后自己设计SOC上的peripherals，这里面就包括了timer的硬件。由于没有统一的标准，各个厂商的设计各不相同，这给驱动工程师带来了工

Linux时间子系统之（十五）：clocksource

Mon, 01 Dec 2014 19:03:34 +0800

和洋葱一样，软件也是有层次的，内核往往需要对形形色色的某类型的驱动进行抽象，屏蔽掉其具体的特质，获取该类驱动共同的逻辑，而又根据这些逻辑撰写该类驱动的抽象层。嵌入式系统总是会提供timer的硬件block，软件需要对timer硬件提供的功能进行抽象：linux kernel将timer类型的硬件抽象成两个组件，一是free running的counter，另外一个是指定的counter值上产生中

Linux common clock framework(3)_实现逻辑分析

Mon, 24 Nov 2014 22:31:28 +0800

前面两篇clock framework的分析文章，分别从 clock consumer 和 clock provider 的角度，介绍了Linux kernel怎么管理系统的clock资源，以及device driver怎么使用clock资源。本文将深入到clock framework的内部，分析相关的实现逻辑。注：本文使用的kernel版本为linux-3.10.29。虽然最新版本的kerne

一个技术男眼中的Smartisan T1手机

Mon, 24 Nov 2014 11:03:47 +0800

作者从一个技术人的眼光来看一部颇有争议的Smartisan T1手机，也就是传说中的锤子手机。锤子手机究竟如何？好用吗？锤子手机的情怀究竟为何物？这篇文章给不了你所有的答案，这篇文站只会告诉你，很多事情，要体验，要感受，而且，要有端正的三观作为基础。

从“码农”说起

Tue, 18 Nov 2014 10:53:43 +0800

一个正常的市场经济里，有创意，有技术的人，都是能够得到回报的。现在我们的社会还远远没有到软件供过于求的状态，反而是大量的需求得不到满足，大量的社会协调缺乏软件技术的协助。相信机会总是有的——即使是在中国。

程序员的“纪律性”（《程序员杂志》署名文章）

Tue, 18 Nov 2014 10:46:41 +0800

多问几个为什么一定要这样和为什么不那样，对一个年轻人，尤其对一个有技术追求的年轻人永远有好处。单纯从项目开发的效率来讲，团队里面有这样的软件多面手，有能够提出这样想法的人，比一个外行领导者对于开发者纪律性的要求要有意义，也有效的多。

Linux内核同步机制之（三）：memory barrier

Fri, 14 Nov 2014 19:20:12 +0800

我记得以前上学的时候大家经常说的一个词汇叫做所见即所得，有些编程工具是所见即所得的，给程序员带来极大的方便。对于一个c程序员，我们的编写的代码能所见即所得吗？我们看到的c程序的逻辑是否就是最后CPU运行的结果呢？很遗憾，不是，我们的“所见”和最后的执行结果隔着： 1、编译器 2、CPU取指执行编译器将符合人类思考的逻辑（c代码）翻译成了符合CPU运算规则的汇编指令，编译器了解底层CPU的思维

Linux PM domain framework(1)_概述和使用流程

Thu, 13 Nov 2014 22:09:12 +0800

在复杂的片上系统（SOC）中，设计者一般会将系统的供电分为多个独立的block，这称作电源域（Power Domain），这样做有很多好处，例如： 1）将不同功能模块的供电分开，减小相互之间的干扰（如模拟和数字分开）。 2）不同功能所需的电压大小不同：小电压能量损耗低，但对信号质量的要求较高；大电压能量损耗高，对信号质量的要求较低。因此可以根据实际情况，使用不同的电压供电，例如CPU core只需

我眼中的可穿戴设备

Wed, 05 Nov 2014 14:55:27 +0800

可穿戴设备，一个现在非常火热的话题，它是很多创业者眼中河滩上的宝钻、沙漠中的绿洲、戈壁滩上的金球球…… 作者从一个曾经的创业者、同时也是一个技术人员的观点来看可穿戴设备的市场现状，提出了自己的想法。技术寓言神马的，爱信不信，信也不一定灵。不过看待滚滚红尘中的一波未平一波又起的热潮，作者的冷静值得借鉴……

新技能get: 订阅Linux内核邮件列表

Tue, 04 Nov 2014 22:37:25 +0800

本文给小伙伴们分享一下怎么订阅Linux内核邮件列表（Linux kernel mailing list，LKML）。

linux kernel的中断子系统之（八）：softirq

Fri, 24 Oct 2014 11:53:54 +0800

对于中断处理而言，linux将其分成了两个部分，一个叫做中断handler（top half），是全程关闭中断的，另外一部分是deferable task（bottom half），属于不那么紧急需要处理的事情。在执行bottom half的时候，是开中断的。有多种bottom half的机制，例如：softirq、tasklet、workqueue或是直接创建一个kernel thread来执行

防冲突机制介绍

Fri, 24 Oct 2014 11:35:31 +0800

本文介绍了通讯领域中的两种防冲突机制，CSMA/CD和CSMA/CA.

Linux common clock framework(2)_clock provider

Thu, 23 Oct 2014 23:49:18 +0800

本文接上篇文章，从clock driver的角度，分析怎么借助common clock framework管理系统的时钟资源。换句话说，就是怎么编写一个clock driver。由于kernel称clock driver为clock provider（相应的，clock的使用者为clock consumer），因此本文遵循这个规则，统一以clock provider命名。

arm64 linux移植

Thu, 23 Oct 2014 17:02:05 +0800

arm64大潮来势汹汹，不知道大家有没有在搞64位cpu呢？ arm64 linux 只支持device tree了，大家要努力学好dt啦。可以去参考楼主之前的dt文章。 arm64 架构已经有很大的改变啦，不知道楼主什么时候给大家普及呢？哈哈。 Porting to ARM 64-bit.pdf 32-bit to 64-bit portingv3.pdf 上面两篇pdf在网上可以找到，可以初步

linux内核同步

Tue, 21 Oct 2014 16:41:04 +0800

同步就是避免并发和防止竞争条件。有关临界区的例子我就不举了，随便一本操作系统的书上都有。锁机制的提出也算解决了一些问题，我们待会再说，现在只要知道锁的使用是自愿的，非强制的。linux自身也提供了几种不同的锁机制，区别主要在于当锁被争用时，有些会简单地执行等待，而有些锁会使当前任务睡眠直到锁可用为止，这个后面细说。真正的困难在于发现并辨认出真正需要共享的数据和相应的共享区。先来说一些感性的话：大多

Linux common clock framework(1)_概述

Mon, 20 Oct 2014 23:06:59 +0800

common clock framework是用来管理系统clock资源的子系统，根据职能，可分为三个部分： 1）向其它driver提供操作clocks的通用API。 2）实现clock控制的通用逻辑，这部分和硬件无关。 3）将和硬件相关的clock控制逻辑封装成操作函数集，交由底层的platform开发者实现，由通用逻辑调用。因此，蜗蜗会将clock framework的分析文章分为3篇：第

Linux内核同步机制之（二）：Per-CPU变量

Thu, 16 Oct 2014 11:17:28 +0800

本文主要介绍了linux kernel中的per cpu变量的源由，接口以及具体的实现。

Linux内核同步机制之（一）：原子操作

Fri, 10 Oct 2014 17:56:16 +0800

本文主要描述了ARM linux中的原子操作相关的内容。

Linux电源管理(11)_Runtime PM之功能描述

Wed, 08 Oct 2014 23:32:12 +0800

终于可以写Runtime PM了，说实话，蜗蜗有点小激动。因为从个人的角度讲，我很推崇使用Runtime PM进行日常的动态电源管理，而不是suspend机制。软件工程的基本思想就是模块化：高内聚和低耦合。通俗地讲呢，就是“各人自扫门前雪”，尽量扫好自己的（高内聚），尽量不和别人交互（低耦合）。而Runtime PM正体现了这一思想：每个设备（包括CPU）都处理好自身的电源管理工作，尽量以最低的

Linux设备模型(9)_device resource management

Wed, 24 Sep 2014 23:28:19 +0800

蜗蜗建议，每一个Linux驱动工程师，都能瞄一眼本文。之所以用“瞄”，因此它很简单，几乎不需要花费心思就能理解。之所有这建议，是因为它非常实用，可以解答一些困惑，可以使我们的代码变得简单、简洁。先看一个例子：

Linux kernel中断子系统之（五）：驱动申请中断API

Mon, 22 Sep 2014 18:33:36 +0800

本文主要的议题是作为一个普通的驱动工程师，在撰写自己负责的驱动的时候，如何向Linux Kernel中的中断子系统注册中断处理函数？为了理解注册中断的接口，必须了解一些中断线程化（threaded interrupt handler）的基础知识，这些在第二章描述。第三章主要描述了驱动申请 interrupt line接口API request_threaded_irq的规格。第四章是进入reque

Linux电源管理(10)_autosleep

Thu, 18 Sep 2014 23:42:27 +0800

Autosleep也是从Android wakelocks补丁集中演化而来的（ Linux电源管理(9)_wakelocks ），用于取代Android wakelocks中的自动休眠功能。它基于wakeup source实现，从代码逻辑上讲，autosleep是一个简单的功能，但背后却埋藏着一个值得深思的话题：计算机的休眠（通常是STR、Standby、Hibernate等suspend操作）

Linux电源管理(9)_wakelocks

Sun, 14 Sep 2014 23:17:28 +0800

wakelocks是一个有故事的功能。 wakelocks最初出现在Android为linux kernel打的一个补丁集上，该补丁集实现了一个名称为“wakelocks”的系统调用，该系统调用允许调用者阻止系统进入低功耗模式（如idle、suspend等）。同时，该补丁集更改了Linux kernel原生的电源管理执行过程（kernel/power/main.c中的state_show和stat

Linux电源管理(8)_Wakeup count功能

Fri, 12 Sep 2014 23:35:25 +0800

Wakeup count是 Wakeup events framework 的组成部分，用于解决“system suspend和system wakeup events之间的同步问题”。本文将结合“ Linux电源管理(6)_Generic PM之Suspend功能 ”和“ Linux电源管理(7)_Wakeup events framework ”两篇文章，分析wakeup count的功能、实

Linux电源管理(7)_Wakeup events framework

Tue, 09 Sep 2014 22:43:55 +0800

本文继续“ Linux电源管理(6)_Generic PM之Suspend功能 ”中有关suspend同步以及PM wakeup的话题。这个话题，是近几年Linux kernel最具争议的话题之一，在国外Linux开发论坛，经常可以看到围绕该话题的辩论。辩论的时间跨度和空间跨度可以持续很长，且无法达成一致。 wakeup events framework是这个话题的一个临时性的解决方案，包括wak

linux kernel的中断子系统之（七）：GIC代码分析

Thu, 04 Sep 2014 16:59:06 +0800

GIC（Generic Interrupt Controller）是ARM公司提供的一个通用的中断控制器，其architecture specification目前有四个版本，V1～V4(V2最多支持8个ARM core，V3/V4支持更多的ARM core，主要用于ARM64服务器系统结构）。目前在ARM官方网站只能下载到Version 2的GIC architecture specificat

linux kernel的中断子系统之（四）：High level irq event handler

Thu, 28 Aug 2014 20:00:50 +0800

当外设触发一次中断后，一个大概的处理过程是： 1、具体CPU architecture相关的模块会进行现场保护，然后调用machine driver对应的中断处理handler 2、machine driver对应的中断处理handler中会根据硬件的信息获取HW interrupt ID，并且通过irq domain模块翻译成IRQ number 3、调用该IRQ number对应的high

linux kernel的中断子系统之（三）：IRQ number和中断描述符

Tue, 26 Aug 2014 17:03:06 +0800

本文主要围绕IRQ number和中断描述符（interrupt descriptor）这两个概念描述通用中断处理过程。第二章主要描述基本概念，包括什么是IRQ number，什么是中断描述符等。第三章描述中断描述符数据结构的各个成员。第四章描述了初始化中断描述符相关的接口API。第五章描述中断描述符相关的接口API。

Linux电源管理(6)_Generic PM之Suspend功能

Fri, 22 Aug 2014 21:40:34 +0800

Linux内核提供了三种Suspend: Freeze、Standby和STR(Suspend to RAM)，在用户空间向”/sys/power/state”文件分别写入”freeze”、”standby”和”mem”，即可触发它们。内核中，Suspend及Resume过程涉及到PM Core、Device PM、各个设备的驱动、Platform dependent PM、CPU contro

Linux kernel的中断子系统之（二）：IRQ Domain介绍

Tue, 19 Aug 2014 18:46:30 +0800

在linux kernel中，我们使用下面两个ID来标识一个来自外设的中断： 1、IRQ number。CPU需要为每一个外设中断编号，我们称之IRQ Number。这个IRQ number是一个虚拟的interrupt ID，和硬件无关，仅仅是被CPU用来标识一个外设中断。 2、 HW interrupt ID。对于interrupt controller而言，它收集了多个外设的interrup

DMB DSB ISB以及SMP CPU 乱序

Fri, 15 Aug 2014 16:57:47 +0800

不知道大家对DMB DSB ISB以及SMP CPU 乱序，有没有认识。我想在这个讨论贴上面来跟大家讨论一下。

Linux kernel的中断子系统之（一）：综述

Thu, 14 Aug 2014 19:12:49 +0800

一个合格的linux驱动工程师需要对kernel中的中断子系统有深刻的理解，只有这样，在写具体driver的时候才能： 1、正确的使用linux kernel提供的的API，例如最著名的request_threaded_irq（request_irq）接口 2、正确使用同步机制保护驱动代码中的临界区 3、正确的使用kernel提供的softirq、tasklet、workqueue等机制来完成具体

开源的RF硬件平台

Wed, 13 Aug 2014 09:13:23 +0800

http://greatscottgadgets.com/hackrf/ http://www.hackrf.net/

启动regulator framework分析任务

Tue, 12 Aug 2014 19:36:14 +0800

电源管理也是很有意思的内核模块，原来蜗窝同学写了一些文章，我准备狗尾续貂，启动regulator framework分析任务

建立讨论区的原因

Sun, 10 Aug 2014 23:26:21 +0800

这个网站的名字叫做“蜗窝科技”，所谓蜗窝，就是蜗牛之家的意思，为那些愿意慢下来细细品味linux kernel中各种技术的“蜗牛”提供一个可以交流的平台。不过建站半年来，似乎广大人民群众参与度不够，使得这个网站看起来更像一个个人的博客。一个人的能力是有限的，写文章需要时间，在工作比较忙碌的时候，其实很难保持不断的更新。基于上面的想法，一个叫做讨论区的板块被创建了。发表在其他的板块的文章都会是一个

这是一篇发布在讨论区的测试文章

Sat, 09 Aug 2014 17:52:48 +0800

最终目的不让它出现在首页文章页中。

傅立叶级数（Fourier Series）和周期现象

Thu, 07 Aug 2014 20:09:51 +0800

如果你仔细观察，工作和生活中充满了周期现象：旁边linux driver工程师在调试audio driver的时候播放的1kHz的正弦信号，周末去公园游玩，游船推开水面的波纹，硬件工程师调试硬件电路的时候，示波器显示出来的晶振方波信号…… 所谓周期现象具体包括时间上的周期现象和空间上的周期现象。1kHz的audio当然是时间上的周期信号，而水面的波形就是空间上的周期现象。对于空间上的周期现象，实际

Linux kernel的中断子系统之（六）：ARM中断处理过程

Mon, 04 Aug 2014 18:26:32 +0800

本文主要以ARM体系结构下的中断处理为例，讲述整个中断处理过程中的硬件行为和软件动作。具体整个处理过程分成三个步骤来描述： 1、第二章描述了中断处理的准备过程 2、第三章描述了当发生中的时候，ARM硬件的行为 3、第四章描述了ARM的中断进入过程 4、第五章描述了ARM的中断退出过程本文涉及的代码来自3.14内核。另外，本文注意描述ARM指令集的内容，有些source code为了简短一些，删除

linux内核中的GPIO系统之（2）：pin control subsystem

Sat, 26 Jul 2014 18:24:15 +0800

在linux2.6内核上工作的嵌入式软件工程师在pin control上都会遇到这样的状况：（1）启动一个新的项目后，需要根据硬件平台的设定进行pin control相关的编码。例如：在bootloader中建立一个大的table，描述各个引脚的配置和缺省状态。此外，由于SOC的引脚是可以复用的，因此在各个具体的driver中，也可能会对引脚进行的配置。这些工作都是比较繁琐的工作，需要极大的

Linux内核中的GPIO系统之（3）：pin controller driver代码分析

Tue, 22 Jul 2014 20:37:33 +0800

对于一个嵌入式软件工程师，我们的软件模块经常和硬件打交道，pin control subsystem也不例外，它驱动的硬件叫做pin controller（一般ARM soc的datasheet会把pin controller的内容放入GPIO controller的章节中），主要功能包括：（1）pin multiplexing。基于ARM core的嵌入式处理器一般会提供丰富的功能，例如cam

linux内核中的GPIO系统之（1）：软件框架

Mon, 21 Jul 2014 14:40:58 +0800

作为一个工作多年的系统工程师，免不了做两件事情：培训新员工和给新员工分配任务。对于那些刚刚从学校出来的学生，一般在开始的时候总是分配一些非常简单的任务，例如GPIO driver、LED driver。往往CPU datasheet的关于GPIO或者IO ports的章节都是比较简单的，非常适合刚入行的工程师。虽然GPIO子系统相关的硬件比较简单，没有复杂的协议，不过，对于软件抽象而言，其分层次

ACCESS_ONCE宏定义的解释

Thu, 17 Jul 2014 12:34:37 +0800

在阅读RCU代码的时候遇到了ACCESS_ONCE这个宏定义，感觉比较有意思，因此独立出来一篇文档来描述它。

智慧家庭之我见_多媒体篇

Wed, 09 Jul 2014 09:01:15 +0800

引子：这是一个移动互联的时代，最后的胜者，一定具备超强的整合能力。蜗蜗关注智慧家庭由来已久，只是这些年从事着完全不同的行业，道不同，不相谋。可能是传说中的七年之痒吧，终于决定对自己的工作以及职业规划做出一个变动。以此为契机，将自己对智慧家庭的一些思考，记录于此。可能会很幼稚，希望各位看官不要见笑，并不吝赐教。本文主要是对智慧家庭中的多媒体设备的思考。何为多媒体设备呢？看看下面的事物：智能路由器

GIC驱动代码分析（废弃）

Fri, 04 Jul 2014 14:34:40 +0800

GIC（Generic Interrupt Controller）是ARM公司提供的一个通用的中断控制器。GIC通过AMBA（Advanced Microcontroller Bus Architecture）这样的片上总线连接到一个或者多个ARM processor上。本文主要分析了linux kernel中GIC中断控制器的驱动代码。具体的分析方法是按照source code为索引，逐段分析

在PowerShell中使用Vim

Wed, 18 Jun 2014 11:41:24 +0800

闲来无事，买了一个Win8系统的小平板，带键盘，准备打造成专门用来写博客的工具（本文就是用它写的第一篇）。捣鼓一圈之后，首先要解决的是用什么看代码。在PC时代，习惯了Linux命令行的方式，一般都是Windows系统+VMWare虚拟机+Linux系统+Vim+SecureCRT，但是这个庞大配置，显然不适合小平板。于是蜗蜗就打起PowerShell的主意了。蜗蜗想要的无非就是一个命令行的环境，

基本电路概念之（二）：什么是电容？

Tue, 17 Jun 2014 19:48:47 +0800

我儿子对电路板有一种近乎疯狂的痴迷，每次周末加班的时候，他总是恳求我带他一起到公司，就是为了能够看一看电路板、看一看电路焊接过程。为了不影响工作，我只能是找一些废旧的电路板，加上从蜗窝同学那里搜刮来的电烙铁给小朋友进行电路焊接演示。废旧电路板上有不少的器件，于是问题少年的问题就来了，芯片里面有什么？电路板是几层的？电容的内部结构是什么？……于是乎钳子、起子、剪刀等工具不断的登场，我们家里就是一

计算机科学基础知识（一）:The Memory Hierarchy

Mon, 16 Jun 2014 19:54:13 +0800

一、前言最近一个问题经常萦绕在我的脑海：一个学习电子工程的机械师如何称为优秀的程序员？（注：本文作者本科学习机械设计，研究生转到电子工程系学习，毕业后却选择了系统程序员这样的职业）。经过思考，我认为阻挡我称为一个优秀程序员的障碍是计算机科学的理论知识。自然辩证法告诉我们：理论源于实践，又指导实践，她们是相辅相成的关系。虽然从业十余年，阅code无数，但计算机的理论不成体系，无法指导工程面具体

vim使用技巧摘录

Tue, 10 Jun 2014 16:16:12 +0800

平时读代码、写程序都是在vim（Vi Improved）下进行，总结了一些自己比较喜欢的技巧，贴出来和大家分享一下。注：这些技巧只是蜗蜗比较喜欢，写在这里的主要目的是备份（以后换系统了，直接贴进去就可以了）。而每个人的习惯都不一样，因此仅供大家参考。

Linux电源管理(5)_Hibernate和Sleep功能介绍

Tue, 10 Jun 2014 16:11:19 +0800

Hibernate和Sleep两个功能是Linux Generic PM的核心功能，它们的目的是类似的：暂停使用——>保存上下文——>关闭系统以节电········>恢复系统——>恢复上下文——>继续使用。本文以内核向用户空间提供的接口为突破口，从整体上对这两个功能进行介绍，并会在后续的文章中，分析它们的实现逻辑和执行动作。顺便感概一下，虽然这些机制在Linux系统中存在很久了（类似的概念也存

Device Tree（三）：代码分析

Fri, 06 Jun 2014 16:03:48 +0800

Device Tree总共有三篇，分别是： 1、为何要引入Device Tree，这个机制是用来解决什么问题的？（请参考引入Device Tree的原因） 2、Device Tree的基础概念（请参考 DT基础概念） 3、ARM linux中和Device Tree相关的代码分析（这是本文的主题）本文主要内容是：以Device Tree相关的数据流分析为索引，对ARM linux kern

Device Tree（二）：基本概念

Fri, 30 May 2014 16:47:13 +0800

一些背景知识（例如：为何要引入Device Tree，这个机制是用来解决什么问题的）请参考引入Device Tree的原因，本文主要是介绍Device Tree的基础概念。简单的说，如果要使用Device Tree，首先用户要了解自己的硬件配置和系统运行参数，并把这些信息组织成Device Tree source file。通过DTC（Device Tree Compiler），可以将这些

Linux电源管理(4)_Power Management Interface

Thu, 29 May 2014 15:55:36 +0800

Linux电源管理中，相当多的部分是在处理Hibernate、Suspend、Runtime PM等功能。而这些功能都基于一套相似的逻辑，即“Power management interface”。该Interface的代码实现于“include/linux/pm.h”、“drivers/base/power/main.c”等文件中。主要功能是：对下，定义Device PM相关的回调函数，让各个D

蓝牙协议分析(1)_基本概念

Fri, 23 May 2014 18:15:02 +0800

自1994年由爱立信推出至今，蓝牙技术已经走过了20个岁月。从最初的Bluetooth V1.0，到Bluetooth V4.0（最新的为V4.1，2013年底发布），经历了近9个版本的修订后，发展为当前的状况。说实话，如今的蓝牙4.1，简直是一个大杂烩：BR/EDR沿用旧的蓝牙规范；LE抄袭802.15.4；AMP直接使用802.11。而这一切的目的，就是以兼容性和易用性为基础，在功耗和传输速

Device Tree（一）：背景介绍

Thu, 22 May 2014 16:46:42 +0800

作为一个多年耕耘在linux 2.6.23内核的开发者，各个不同项目中各种不同周边外设驱动的开发以及各种琐碎的、扯皮的俗务占据了大部分的时间。当有机会下载3.14的内核并准备学习的时候，突然发现linux kernel对于我似乎变得非常的陌生了，各种新的机制，各种framework、各种新的概念让我感到阅读内核代码变得举步维艰。还好，剖析内核的热情还在，剩下的就交给时间的。首先进入视线的是De

Linux电源管理(3)_Generic PM之Reboot过程

Mon, 19 May 2014 15:44:43 +0800

在使用计算机的过程中，关机和重启是最先学会的两个操作。同样，这两个操作在Linux中也存在，称作shutdown和restart。这就是本文要描述的对象。在Linux Kernel中，主流的shutdown和restart都是通过“reboot”系统调用（具体可参考kernel/sys.c）来实现的，这也是本文使用“Generic PM之Reboot过程”作为标题的原因。另外，除了我们常用的sh

基本电路概念之（一）：什么是电压？

Fri, 16 May 2014 10:40:37 +0800

我有一个奇葩儿子（4岁），经常问一些奇葩的问题。比如：为什么电子带负电？什么是电压？电路板是怎么生产的？发动机的内部结构是什么？……总之，各种问题层出不穷。有一天回家，他正和他妈妈一起看几张医学的CT片子（他妈妈是医生），他妈妈正详细向他解释该病人颅部血管病变问题，各种专业术语丝毫也没有浇灭儿子的热情，那认真的劲头，我当时就震惊了。为了应付我这个奇葩儿子，为了始终维持爸爸的高大形象，我不得不

SDRAM Internals

Wed, 14 May 2014 16:25:34 +0800

SDRAM（synchronous dynamic random-access memory）是嵌入式系统中经常用到的器件。对于一个嵌入式软件工程师而言，了解SDRAM的机理是有益的。我们可以从下面三个方面理解SDRAM： 1、RAM很好理解，就是可以随机存取的memory。 2、 dynamic 是和static对应的，SRAM就是static random-access memory。SRAM

Linux电源管理(2)_Generic PM之基本概念和软件架构

Tue, 13 May 2014 19:24:07 +0800

这里的Generic PM，是蜗蜗自己起的名字，指Linux系统中那些常规的电源管理手段，包括关机（Power off）、待机（Standby or Hibernate）、重启（Reboot）等。这些手段是在嵌入式Linux普及之前的PC或者服务器时代使用的。在那个计算机科学的蛮荒时代，人类在摩尔定律的刺激下，孜孜追求的是计算机的计算能力、处理性能，因此并不特别关心Power消耗。在这种背景下发

Linux电源管理(1)_整体架构

Wed, 07 May 2014 19:21:03 +0800

在这个世界中，任何系统的运转都需要能量。如树木依靠光能生长，如马儿依靠食物奔跑，如计算机系统依靠电能运行。而能量的获取是有成本的，因此如果能在保证系统运转的基础上，尽量节省对能量的消耗，就会大大提升该系统的生存竞争力。这方面，大自然已经做的很好了，如植物的落叶，如动物的冬眠，等等。而在计算机的世界里（这里以运行Linux OS的嵌入式系统为例），称作电源管理（Power Management）。

Process Creation（二）

Mon, 28 Apr 2014 15:40:44 +0800

本文是 Process Creation（一）的延续，主要内容包括： 1、进程描述符中Realtime Mutex相关数据结构的初始化 2、子进程如何复制父进程的credentials 3、per-task delay accounting的处理 4、子进程如何复制父进程的flag

Linux设备模型(8)_platform设备

Mon, 28 Apr 2014 10:24:20 +0800

在Linux设备模型的抽象中，存在着一类称作“Platform Device”的设备，内核是这样描述它们的（Documentation/driver-model/platform.txt）： Platform devices are devices that typically appear as autonomous entities in the system. This includes l

Linux设备模型(7)_Class

Wed, 23 Apr 2014 15:17:26 +0800

在设备模型中，Bus、Device、Device driver等等，都比较好理解，因为它们对应了实实在在的东西，所有的逻辑都是围绕着这些实体展开的。而本文所要描述的Class就有些不同了，因为它是虚拟出来的，只是为了抽象设备的共性。举个例子，一些年龄相仿、需要获取的知识相似的人，聚在一起学习，就构成了一个班级（Class）。这个班级可以有自己的名称（如295），但如果离开构成它的学生（devic

Process Creation（一）

Wed, 23 Apr 2014 08:39:39 +0800

为什么要写一个关于进程如何创建的文档？其实用do_fork作为关键字进行索引，你会发现网上的相关文档数以万计。作为一个内核工程师，对进程以及进程相关的内容当然是非常感兴趣，但是网上的资料并不能令我非常满意（也许是我没有检索到好的文章），一个简单的例子如下： static void copy_flags(unsigned long clone_flags, struct task_struct *p

Unix的历史

Mon, 21 Apr 2014 20:32:07 +0800

作为一个Linuxer，对unix感兴趣是顺理成章的事情，对unix的了解反过来也可以促进对GNU/Linux的理解。不过在接触unix的过程中，大家一般都会有下面的疑问： 1、unix这个商标是属于哪一个公司或者机构？ 2、为何unix有那么多的变种？为何各个公司都有自己的unix，例如IBM的AIX（Advanced Interactive eXecutive）操作系统、SUN公司的Solar

教育漫谈(1)_《乌合之众》摘录

Sat, 19 Apr 2014 18:44:15 +0800

这些年来，教育问题一直是一个比较热门的话题，任何一个有良知的中国人，都会关注、思考、讨论这个问题，因为它关系到这个国家的未来，关系到这个民族的兴衰。蜗蜗并不是一个爱凑热闹的人，也自知以自己的资历和经验，并无资格讨论这个问题。之所以写《教育漫谈》这一系列的文章，只是想从自己的亲身经历出发，将自己的想法分享出来，供大家讨论。蜗蜗是一个ITer，平时也会参与公司技术人员招聘的事情。而提起招聘，难免会

Linux设备模型(6)_Bus

Tue, 15 Apr 2014 19:21:43 +0800

在Linux设备模型中，Bus（总线）是一类特殊的设备，它是连接处理器和其它设备之间的通道（channel）。为了方便设备模型的实现，内核规定，系统中的每个设备都要连接在一个Bus上，这个Bus可以是一个内部Bus、虚拟Bus或者Platform Bus。内核通过struct bus_type结构，抽象Bus，它是在include/linux/device.h中定义的。本文会围绕该结构，描述Li

Linux设备模型(5)_device和device driver

Wed, 02 Apr 2014 19:28:51 +0800

device和device driver是Linux驱动开发的基本概念。Linux kernel的思路很简单：驱动开发，就是要开发指定的软件（driver）以驱动指定的设备，所以kernel就为设备和驱动它的driver定义了两个数据结构，分别是device和device_driver。因此本文将会围绕这两个数据结构，介绍Linux设备模型的核心逻辑，包括：设备及设备驱动在kernel中的抽象、

process credentials相关的用户空间文件

Wed, 02 Apr 2014 12:54:36 +0800

作为对 linux_fans 提出建议的回应，本文主要描述在用户空间，和 process credentials 相关的内容，具体包括： 1 、 /etc/passwd 文件 2 、 /etc/shadow 文件 3 、 /etc/group 文件 4 、从系统登录过程看如何使用这些文件

留言板

Wed, 26 Mar 2014 17:56:54 +0800

路过的蜗牛们，在这里留个脚印吧～蜗窝欢迎各种言论，谈天说地、技术交流、问题求救、跳槽招聘、牢骚抱怨……哈哈。

process identification

Wed, 26 Mar 2014 12:28:20 +0800

一、概述本文主要描述在 linux kernel 中如何标识一个或者一组和进程（线程）相关的实体，包括： 1 、进程 ID （线程组 ID ） 2 、线程 ID 3 、进程组 ID 4 、 Session ID 需要强调的是本文 focus 在 identification ，很多展开的内容会有一系列文档描述。

process credentials

Fri, 21 Mar 2014 16:32:47 +0800

一、介绍当 linux 系统中的一个进程运行起来的时候，总是要访问系统的资源，访问文件或者向其他的进程发送信号。系统是否允许其进行这些操作？系统是根据什么来判断该进程的权限？这些问题是和进程信任状（ process credentials ）相关。 process credentials 包括一系列的 ID ，如下： 1 、 real user ID 和 real group ID 2 、 ef

Linux设备模型(4)_sysfs

Fri, 14 Mar 2014 18:31:35 +0800

sysfs是一个基于RAM的文件系统，它和Kobject一起，可以将Kernel的数据结构导出到用户空间，以文件目录结构的形式，提供对这些数据结构（以及数据结构的属性）的访问支持。 sysfs具备文件系统的所有属性，而本文主要侧重其设备模型的特性,因此不会涉及过多的文件系统实现细节，而只介绍sysfs在Linux设备模型中的作用和使用方法。具体包括： sysfs和Kobject的关系 attrib

蓝牙协议中LQ和RSSI的原理及应用场景

Wed, 12 Mar 2014 15:59:46 +0800

LQI (Link Quality Indication)，是当前接收到的信号的质量的一种度量。所谓的接收到信号的质量，是接收器通过接收到的信号和理想信号之间的错误累积值估算的。例如，如果使用FSK或者GFSK调制方式，接收器可以将每个bit的频率和期望的频率比较，累积一定数量的symbols（例如64个），就得到了错误累积值。由此可知，由于LQI的测量和调制方式有关，因此它可以相对地给出

Linux设备模型(3)_Uevent

Mon, 10 Mar 2014 20:39:57 +0800

Uevent是Kobject的一部分，用于在Kobject状态发生改变时，例如增加、移除等，通知用户空间程序。用户空间程序收到这样的事件后，会做相应的处理。该机制通常是用来支持热拔插设备的，例如U盘插入后，USB相关的驱动软件会动态创建用于表示该U盘的device结构（相应的也包括其中的kobject），并告知用户空间程序，为该U盘动态的创建/dev/目录下的设备节点，更进一步，可以通知其它的应

调试手段之sys节点

Sun, 09 Mar 2014 12:01:07 +0800

在我们调试自己驱动代码时，常用手段是日志输出，前面窝窝已说到，而且讲得比较深刻。这里我介绍另外一种调试方法，通过sys节点进行查看一些设备状态或者变量多少。通常一个版本release到测试部集成测试时，出现某个bug，还是偶现的，怎么办？不能说，我马上回去给个debug版本，让你重新测试吧，你不嫌麻烦，测试人员也会不高兴的，那么这里就可以把一些常用信息通过sys节点输出出来，现场查看。例如，之前

Linux设备模型(2)_Kobject

Fri, 07 Mar 2014 00:25:42 +0800

Kobject是Linux设备模型的基础，也是设备模型中最难理解的一部分（可参考Documentation/kobject.txt的表述）。因此有必要先把它分析清楚。

Linux设备模型(1)_基本概念

Thu, 27 Feb 2014 17:01:48 +0800

在“ Linux内核的整体架构 ”中，蜗蜗有提到，由于Linux支持世界上几乎所有的、不同功能的硬件设备（这是Linux的优点），导致Linux内核中有一半的代码是设备驱动，而且随着硬件的快速升级换代，设备驱动的代码量也在快速增长。个人意见，这种现象打破了“简洁就是美”的理念，是丑陋的。它导致Linux内核看上去非常臃肿、杂乱、不易维护。但蜗蜗也知道，这不是Linux的错，Linux是一个宏内核，

Linux内核的整体架构

Fri, 21 Feb 2014 13:23:52 +0800

本文是“Linux内核分析”系列文章的第一篇，会以内核的核心功能为出发点，描述Linux内核的整体架构，以及架构之下主要的软件子系统。之后，会介绍Linux内核源文件的目录结构，并和各个软件子系统对应。注：本文和其它的“Linux内核分析”文章都基于如下约定： a) 内核版本为Linux 3.10.29（该版本是一个long term的版本，会被Linux社区持续维护至少2年），可以从下面的链接

由Flappy Bird想到的技术观、哲学观和人生观

Thu, 13 Feb 2014 13:04:15 +0800

最近这只鸟（Flappy Bird）很火！蜗蜗本来不擅于玩各种游戏，这次只所有会关注到这只鸟，完全是因为看到鸟作者的新闻后，作为同路的技术人，钦佩、共鸣等感觉油然而生所致。几天内，断断续续的玩了几十次之后，很有感触，就在此分享一下。

MinGW下安装man工具包

Fri, 24 Jan 2014 18:50:55 +0800

在软件开发方面，蜗蜗是一个坚定的 Linux 追随者， vim 、 make 、 gcc 、 man 、 shell 等等，每一个工具都充满了艺术的气息。因而工作时，电脑都会运行两个操作系统： Windows 是主系统，主要用于日常的邮件收发、文档编写等工作； Linux 运行在虚拟机上，主要负责软件开发。后来发现MinGW这个工具后，可以在Windows系统下完成大部分的Linux操作，并可以

小printf大作用（用日志打印的方式调试程序）

Thu, 23 Jan 2014 20:52:34 +0800

一般来说，初学编程者所写的第一个程序，就是使用printf打印“Hello world”。其实printf的功效远不只这些，在程序调试方面，printf也有非常大的用处。 “蜗蜗”在接触Linux driver开发之前，学习过桌面程序开发（如Turbo C、Visual C等），也从事了一段时间的嵌入式软件开发。这些开发有一个共同点，对调试工具非常依赖，如桌面程序的Debugger（调试器）、嵌入

Windows系统结合MinGW搭建软件开发环境

Wed, 22 Jan 2014 12:16:01 +0800

MinGW ，即 Minimalist GNU For Windows ，它包含了 GNU 工具集的运行环境、 GCC 编译器工具集以及其它的 GNU 程序开发工具（如 make 、 gawk 、 grep 等等）。借用MinGW，可以在Windows操作系统上，使用强大的、丰富多彩的开源工具进行软件开发，例如vim、gcc、python等等。

“蜗窝”使用的软件开发环境介绍

Tue, 21 Jan 2014 14:34:57 +0800

“蜗窝”中的很多文章，会涉及软件开发的内容，包括嵌入式、 ARM 、 C 语言、 Linux 、 DSP 等议题。为了方便大家的测试、学习、使用，我们会尽可能的提供所有软件的 source code 。而软件开发是非常依赖开发环境的，因而有必要事先交代“蜗窝”所使用的开发环境，以此达到 2 个目的： 1. 让“蜗窝”中所有的蜗牛们，使用相同的开发环境，以便互相交流、互相帮助。 2. “蜗窝”的创立

2014年10月

Mon, 01 Jan 0001 00:00:00 +0000

2014年10月共 9 篇。

linux kernel的中断子系统之（八）：softirq 2014-10-24
防冲突机制介绍 2014-10-24
Linux common clock framework(2)_clock provider 2014-10-23
arm64 linux移植 2014-10-23
linux内核同步 2014-10-21
Linux common clock framework(1)_概述 2014-10-20
Linux内核同步机制之（二）：Per-CPU变量 2014-10-16
Linux内核同步机制之（一）：原子操作 2014-10-10
Linux电源管理(11)_Runtime PM之功能描述 2014-10-08

2014年11月

Mon, 01 Jan 0001 00:00:00 +0000

2014年11月共 8 篇。

Linux common clock framework(3)_实现逻辑分析 2014-11-24
一个技术男眼中的Smartisan T1手机 2014-11-24
从“码农”说起 2014-11-18
程序员的“纪律性”（《程序员杂志》署名文章） 2014-11-18
Linux内核同步机制之（三）：memory barrier 2014-11-14
Linux PM domain framework(1)_概述和使用流程 2014-11-13
我眼中的可穿戴设备 2014-11-05
新技能get: 订阅Linux内核邮件列表 2014-11-04

2014年12月

Mon, 01 Jan 0001 00:00:00 +0000

2014年12月共 17 篇。

Linux cpuidle framework(2)_cpuidle core 2014-12-30
Linux时间子系统之（四）：timekeeping 2014-12-29
Linux电源管理(13)_Driver的电源管理 2014-12-26
Linux时间子系统之（三）：用户空间接口函数 2014-12-24
Linux时间子系统之（一）：时间的基本概念 2014-12-23
Linux时间子系统系列文章之目录 2014-12-23
Linux电源管理(12)_Hibernate功能 2014-12-22
Linux cpuidle framework(1)_概述和软件架构 2014-12-17
关于spin_lock的问题 2014-12-12
Linux时间子系统之（十二）：periodic tick 2014-12-11
ARM WFI和WFE指令 2014-12-10
ARM概念梳理：Architecture, Core, CPU，SOC 2014-12-09
Linux时间子系统之（十六）：clockevent 2014-12-09
为什么会有“ARMv8A Architecture”这个分类 2014-12-06
kobject在字符设备中的使用 2014-12-04
Linux时间子系统之（十七）：ARM generic timer驱动代码分析 2014-12-02
Linux时间子系统之（十五）：clocksource 2014-12-01

2014年1月

Mon, 01 Jan 0001 00:00:00 +0000

2014年1月共 4 篇。

2014年2月

Mon, 01 Jan 0001 00:00:00 +0000

2014年2月共 3 篇。

2014年3月

Mon, 01 Jan 0001 00:00:00 +0000

2014年3月共 7 篇。

2014年4月

Mon, 01 Jan 0001 00:00:00 +0000

2014年4月共 9 篇。

Process Creation（二） 2014-04-28
Linux设备模型(8)_platform设备 2014-04-28
Linux设备模型(7)_Class 2014-04-23
Process Creation（一） 2014-04-23
Unix的历史 2014-04-21
教育漫谈(1)_《乌合之众》摘录 2014-04-19
Linux设备模型(6)_Bus 2014-04-15
Linux设备模型(5)_device和device driver 2014-04-02
process credentials相关的用户空间文件 2014-04-02

2014年5月

Mon, 01 Jan 0001 00:00:00 +0000

2014年5月共 9 篇。

Device Tree（二）：基本概念 2014-05-30
Linux电源管理(4)_Power Management Interface 2014-05-29
蓝牙协议分析(1)_基本概念 2014-05-23
Device Tree（一）：背景介绍 2014-05-22
Linux电源管理(3)_Generic PM之Reboot过程 2014-05-19
基本电路概念之（一）：什么是电压？ 2014-05-16
SDRAM Internals 2014-05-14
Linux电源管理(2)_Generic PM之基本概念和软件架构 2014-05-13
Linux电源管理(1)_整体架构 2014-05-07

2014年6月

Mon, 01 Jan 0001 00:00:00 +0000

2014年6月共 6 篇。

在PowerShell中使用Vim 2014-06-18
基本电路概念之（二）：什么是电容？ 2014-06-17
计算机科学基础知识（一）:The Memory Hierarchy 2014-06-16
vim使用技巧摘录 2014-06-10
Linux电源管理(5)_Hibernate和Sleep功能介绍 2014-06-10
Device Tree（三）：代码分析 2014-06-06

2014年7月

Mon, 01 Jan 0001 00:00:00 +0000

2014年7月共 6 篇。

linux内核中的GPIO系统之（2）：pin control subsystem 2014-07-26
Linux内核中的GPIO系统之（3）：pin controller driver代码分析 2014-07-22
linux内核中的GPIO系统之（1）：软件框架 2014-07-21
ACCESS_ONCE宏定义的解释 2014-07-17
智慧家庭之我见_多媒体篇 2014-07-09
GIC驱动代码分析（废弃） 2014-07-04

2014年8月

Mon, 01 Jan 0001 00:00:00 +0000

2014年8月共 12 篇。

linux kernel的中断子系统之（四）：High level irq event handler 2014-08-28
linux kernel的中断子系统之（三）：IRQ number和中断描述符 2014-08-26
Linux电源管理(6)_Generic PM之Suspend功能 2014-08-22
Linux kernel的中断子系统之（二）：IRQ Domain介绍 2014-08-19
DMB DSB ISB以及SMP CPU 乱序 2014-08-15
Linux kernel的中断子系统之（一）：综述 2014-08-14
开源的RF硬件平台 2014-08-13
启动regulator framework分析任务 2014-08-12
建立讨论区的原因 2014-08-10
这是一篇发布在讨论区的测试文章 2014-08-09
傅立叶级数（Fourier Series）和周期现象 2014-08-07
Linux kernel的中断子系统之（六）：ARM中断处理过程 2014-08-04

2014年9月

Mon, 01 Jan 0001 00:00:00 +0000

2014年9月共 7 篇。

Linux设备模型(9)_device resource management 2014-09-24
Linux kernel中断子系统之（五）：驱动申请中断API 2014-09-22
Linux电源管理(10)_autosleep 2014-09-18
Linux电源管理(9)_wakelocks 2014-09-14
Linux电源管理(8)_Wakeup count功能 2014-09-12
Linux电源管理(7)_Wakeup events framework 2014-09-09
linux kernel的中断子系统之（七）：GIC代码分析 2014-09-04

2015年10月

Mon, 01 Jan 0001 00:00:00 +0000

2015年10月共 9 篇。

ARM64的启动过程之（五）：UEFI 2015-10-30
Linux 3.18U盘无法正确使用 2015-10-28
RCU synchronize原理分析 2015-10-27
作業系統之前的程式 for rpi2 (1) - mmu (0) : 位址轉換 2015-10-27
ARM64的启动过程之（四）：打开MMU 2015-10-24
ARM64的启动过程之（三）：为打开MMU而进行的CPU初始化 2015-10-21
ARM64的启动过程之（二）：创建启动阶段的页表 2015-10-13
Linux PWM framework(1)_简介和API描述 2015-10-11
ARM64的启动过程之（一）：内核第一个脚印 2015-10-10

2015年11月

Mon, 01 Jan 0001 00:00:00 +0000

2015年11月共 9 篇。

显示技术介绍(2)_电子显示的前世今生 2015-11-30
ARM64的启动过程之（六）：异常向量表的设定 2015-11-24
Linux进程冻结技术 2015-11-24
显示技术介绍(1)_概述 2015-11-22
进化论、人工智能和外星人 2015-11-15
linux kernel内存回收机制 2015-11-12
linux cpufreq framework(5)_ARM big Little driver 2015-11-10
實作 spinlock on raspberry pi 2 2015-11-05
linux kernel内存碎片防治技术 2015-11-02

2015年12月

Mon, 01 Jan 0001 00:00:00 +0000

2015年12月共 6 篇。

Linux graphic subsystem(2)_DRI介绍 2015-12-27
perfbook memory barrier（14.2章节）的中文翻译（上） 2015-12-25
slub分配器 2015-12-21
Linux graphic subsytem(1)_概述 2015-12-17
Why Memory Barriers？中文翻译（上） 2015-12-10
Linux内核同步机制之（七）：RCU基础 2015-12-03

2015年1月

Mon, 01 Jan 0001 00:00:00 +0000

2015年1月共 6 篇。

Linux时间子系统之（六）：POSIX timer 2015-01-22
“极致”神话和产品观念 2015-01-19
Linux cpuidle framework(4)_menu governor 2015-01-18
Linux cpuidle framework(3)_ARM64 generic CPU idle driver 2015-01-06
Linux时间子系统之（五）：POSIX Clock 2015-01-05
我的bash shell学习笔记 2015-01-01

2015年2月

Mon, 01 Jan 0001 00:00:00 +0000

2015年2月共 6 篇。

Linux PM QoS framework(3)_per-device PM QoS 2015-02-26
支持wowo，有这样一块小天地享受技术，感觉棒棒哒！ 2015-02-25
计算机科学基础知识（三）:静态库和静态链接 2015-02-16
Linux PM QoS framework(2)_PM QoS class 2015-02-10
计算机科学基础知识（二）:Relocatable Object File 2015-02-09
Linux PM QoS framework(1)_概述和软件架构 2015-02-04

2015年3月

Mon, 01 Jan 0001 00:00:00 +0000

2015年3月共 9 篇。

Linux时间子系统之（十三）：Tick Device layer综述 2015-03-26
对heziq网友问题的回答 2015-03-23
Linux Regulator Framework(1)_概述 2015-03-20
Linux power supply class(1)_软件架构及API汇整 2015-03-13
计算机科学基础知识之（六）：理解栈帧 2015-03-12
计算机科学基础知识（五）: 动态链接 2015-03-10
Linux时间子系统之（二）：软件架构 2015-03-07
计算机科学基础知识（四）: 动态库和位置无关代码 2015-03-06
Linux电源管理(14)_从设备驱动的角度看电源管理 2015-03-02

2015年4月

Mon, 01 Jan 0001 00:00:00 +0000

2015年4月共 9 篇。

Linux CPU core的电源管理(1)_概述 2015-04-30
kernel启动优化 2015-04-30
蜗窝流量地域统计 2015-04-23
Linux内核同步机制之（四）：spin lock 2015-04-22
spin_lock最简单用法。 2015-04-17
Linux Regulator Framework(2)_regulator driver 2015-04-16
linux usb 摄像头测试 2015-04-12
ARM CPU性能实验 2015-04-09
linux 串口调试方法 2015-04-08

2015年5月

Mon, 01 Jan 0001 00:00:00 +0000

2015年5月共 6 篇。

Linux CPU core的电源管理(2)_cpu topology 2015-05-30
msm8994 热插拔sim卡导致modem重新启动的流程 2015-05-28
Linux内核同步机制之（五）：Read/Write spin lock 2015-05-22
Linux时间子系统之（十四）：tick broadcast framework 2015-05-21
Linux下“用户空间修改设备寄存器或者物理内存”的实现 2015-05-15
关于内核中的乘法和除法。 2015-05-06

2015年6月

Mon, 01 Jan 0001 00:00:00 +0000

2015年6月共 3 篇。

Linux cpufreq framework(2)_cpufreq driver 2015-06-19
linux cpufreq framework(1)_概述 2015-06-13
Linux电源管理(15)_PM OPP Interface 2015-06-04

2015年7月

Mon, 01 Jan 0001 00:00:00 +0000

2015年7月共 7 篇。

Concurrency Managed Workqueue之（二）：CMWQ概述 2015-07-31
linux cpufreq framework(3)_cpufreq core 2015-07-30
总结Linux kernel开发中0的巧妙使用 2015-07-20
Linux CPU core的电源管理(3)_cpu ops 2015-07-17
Concurrency Managed Workqueue之（一）：workqueue的基本概念 2015-07-15
ARMv8-a架构简介 2015-07-07
linux kernel的中断子系统之（九）：tasklet 2015-07-02

2015年8月

Mon, 01 Jan 0001 00:00:00 +0000

2015年8月共 3 篇。

linux cpufreq framework(4)_cpufreq governor 2015-08-23
Concurrency Managed Workqueue之（四）：workqueue如何处理work 2015-08-17
Concurrency Managed Workqueue之（三）：创建workqueue代码分析 2015-08-06

2015年9月

Mon, 01 Jan 0001 00:00:00 +0000

2015年9月共 4 篇。

Linux vm运行参数之（二）：OOM相关的参数 2015-09-28
Linux vm运行参数之（一）：overcommit相关的参数 2015-09-23
Linux CPU core的电源管理(5)_cpu control及cpu hotplug 2015-09-19
Linux内核同步机制之（六）：Seqlock 2015-09-09

2016年10月

Mon, 01 Jan 0001 00:00:00 +0000

2016年10月共 9 篇。

X-014-KERNEL-ARM GIC driver的移植 2016-10-31
Linux TTY framework(5)_System console driver 2016-10-29
进程管理和终端驱动：基本概念 2016-10-28
Linux TTY framework(4)_TTY driver 2016-10-25
DRAM 原理 5 ：DRAM Devices Organization 2016-10-15
Linux TTY framework(3)_从应用的角度看TTY设备 2016-10-14
内存初始化（上） 2016-10-13
X-013-UBOOT-使能autoboot功能 2016-10-05
X-012-KERNEL-serial early console的移植 2016-10-02

2016年11月

Mon, 01 Jan 0001 00:00:00 +0000

2016年11月共 11 篇。

X-019-KERNEL-串口驱动开发之数据收发 2016-11-29
蓝牙协议分析(9)_BLE安全机制之LL Privacy 2016-11-25
内存初始化代码分析（三）：创建系统内存地址映射 2016-11-24
X-018-KERNEL-串口驱动开发之serial console 2016-11-18
内存初始化代码分析（二）：内存布局 2016-11-18
X-017-KERNEL-串口驱动开发之uart driver框架 2016-11-16
X-016-KERNEL-串口驱动开发之驱动框架 2016-11-10
内存初始化代码分析（一）：identity mapping和kernel image mapping 2016-11-10
蓝牙协议分析(8)_BLE安全机制之白名单 2016-11-10
X-015-KERNEL-ARM generic timer driver的移植 2016-11-02
Linux kernel debug技巧—-开启DEBUG选项 2016-11-01

2016年12月

Mon, 01 Jan 0001 00:00:00 +0000

2016年12月共 6 篇。

MMC/SD/SDIO介绍 2016-12-25
基于Hikey的"Boot from USB"调试 2016-12-20
Linux serial framework(1)_概述 2016-12-12
快讯：蓝牙5.0发布（新特性速览） 2016-12-08
X-021-ROOTFS-基于busybox的最简rootfs的制作 2016-12-05
X-020-ROOTFS-initramfs的制作和测试 2016-12-03

2016年1月

Mon, 01 Jan 0001 00:00:00 +0000

2016年1月共 6 篇。

显示技术介绍(3)_CRT技术 2016-01-30
Linux2.6.11版本：classic RCU的实现 2016-01-27
Linux 2.5.43版本的RCU实现（废弃） 2016-01-19
蓝牙协议分析(2)_协议架构 2016-01-14
perfbook memory barrier（14.2章节）中文翻译（下） 2016-01-11
Why Memory Barriers中文翻译（下） 2016-01-05

2016年2月

Mon, 01 Jan 0001 00:00:00 +0000

2016年2月共 5 篇。

Linux I2C framework(2)_I2C provider 2016-02-26
Perf book 9.3章节翻译（下） 2016-02-26
Perf book 9.3章节翻译（上） 2016-02-18
Linux I2C framework(1)_概述 2016-02-14
Linux2.6.23 ：sleepable RCU的实现 2016-02-04

2016年3月

Mon, 01 Jan 0001 00:00:00 +0000

2016年3月共 5 篇。

Debian下的WiFi实验（二）：无线网卡自动连接AP 2016-03-24
Linux I2C framework(3)_I2C consumer 2016-03-23
systemd：为何要创建一个新的init系统软件 2016-03-17
蓝牙协议分析(3)_蓝牙低功耗(BLE)协议栈介绍 2016-03-12
Debian下的WiFi实验（一）：通过无线网卡连接AP 2016-03-08

2016年4月

Mon, 01 Jan 0001 00:00:00 +0000

2016年4月共 7 篇。

2016年5月

Mon, 01 Jan 0001 00:00:00 +0000

2016年5月共 8 篇。

X-003-UBOOT-基于Bubblegum-96平台的u-boot移植说明 2016-05-29
蓝牙协议分析(5)_BLE广播通信相关的技术分析 2016-05-27
ARMv8之Observability 2016-05-25
u-boot启动流程分析(1)_平台相关部分 2016-05-19
玩转BLE(2)_使用bluepy扫描BLE的广播数据 2016-05-19
ARMv8之memory model 2016-05-18
ARMv8之Atomicity 2016-05-13
X-002-HW-S900芯片boot from USB有关的硬件描述 2016-05-12

2016年6月

Mon, 01 Jan 0001 00:00:00 +0000

2016年6月共 8 篇。

X-005-UBOOT-device tree移植(Bubblegum-96平台) 2016-06-29
串口通信技术浅析 2016-06-24
X-004-UBOOT-串口驱动移植(Bubblegum-96平台) 2016-06-18
DRAM 原理 2 ：DRAM Memory Organization 2016-06-14
通过点亮LED的方法调试嵌入式代码 2016-06-12
DRAM 原理 1 ：DRAM Storage Cell 2016-06-08
u-boot启动流程分析(2)_板级(board)部分 2016-06-07
蓝牙协议分析(6)_BLE地址类型 2016-06-07

2016年7月

Mon, 01 Jan 0001 00:00:00 +0000

2016年7月共 5 篇。

DRAM 原理 3 ：DRAM Device 2016-07-27
X-008-UBOOT-支持命令行(Bubblegum-96平台) 2016-07-27
X-007-UBOOT-DDR的初始化(Bubblegum-96平台) 2016-07-21
X-006-UBOOT-pinctrl driver移植(Bubblegum-96平台) 2016-07-09
蓝牙协议分析(7)_BLE连接有关的技术分析 2016-07-01

2016年8月

Mon, 01 Jan 0001 00:00:00 +0000

2016年8月共 9 篇。

Linux内存模型 2016-08-31
DRAM 原理 4 ：DRAM Timing 2016-08-29
eMMC框架及其初始化 2016-08-25
X-010-UBOOT-使用booti命令启动kernel(Bubblegum-96平台) 2016-08-24
文件缓存回写简述 2016-08-24
X-009-KERNEL-Linux kernel的移植(Bubblegum-96平台) 2016-08-19
Linux kernel内核配置解析(5)_Boot options(基于ARM64架构) 2016-08-12
ARM64架构下地址翻译相关的宏定义 2016-08-12
Linux kernel内核配置解析(1)_概述(基于ARM64架构) 2016-08-10

2016年9月

Mon, 01 Jan 0001 00:00:00 +0000

2016年9月共 6 篇。

Linux TTY framework(2)_软件架构 2016-09-27
TLB flush操作 2016-09-23
Linux TTY framework(1)_基本概念 2016-09-18
X-011-UBOOT-使用bootm命令启动kernel(Bubblegum-96平台) 2016-09-09
Fix-Mapped Addresses 2016-09-09
u-boot FIT image介绍 2016-09-02

2017年10月

Mon, 01 Jan 0001 00:00:00 +0000

2017年10月共 1 篇。

Linux kernel scatterlist API介绍 2017-10-13

2017年11月

Mon, 01 Jan 0001 00:00:00 +0000

2017年11月共 2 篇。

逆向映射的演进 2017-11-17
Linux kernel内存管理的基本概念 2017-11-09

2017年12月

Mon, 01 Jan 0001 00:00:00 +0000

2017年12月共 2 篇。

USB-C(USB Type-C)规范的简单介绍和分析 2017-12-18
进程切换分析（3）：同步处理 2017-12-11

2017年1月

Mon, 01 Jan 0001 00:00:00 +0000

2017年1月共 5 篇。

为什么会有文件系统(一) 2017-01-17
eMMC 原理 2 ：eMMC 简介 2017-01-12
Linux MMC framework(1)_软件架构 2017-01-10
eMMC 原理 1 ：Flash Memory 简介 2017-01-09
X-022-OTHERS-git操作记录之合并远端分支的更新 2017-01-02

2017年2月

Mon, 01 Jan 0001 00:00:00 +0000

2017年2月共 6 篇。

2017年3月

Mon, 01 Jan 0001 00:00:00 +0000

2017年3月共 8 篇。

Linux DMA Engine framework(1)_概述 2017-03-30
蓝牙协议分析(10)_BLE安全机制之LE Encryption 2017-03-28
中断上下文中调度会怎样？ 2017-03-20
Linux调度器：进程优先级 2017-03-14
玩转BLE(3)_使用微信蓝牙精简协议伪造记步数据 2017-03-11
Linux调度器：用户空间接口 2017-03-10
Linux MMC framework(2)_host controller driver 2017-03-08
eMMC 原理 4 ：总线协议 2017-03-01

2017年4月

Mon, 01 Jan 0001 00:00:00 +0000

2017年4月共 1 篇。

系统休眠（System Suspend）和设备中断处理 2017-04-21

2017年5月

Mon, 01 Jan 0001 00:00:00 +0000

2017年5月共 3 篇。

Linux DMA Engine framework(3)_dma controller驱动 2017-05-18
Linux的时钟 2017-05-17
Linux DMA Engine framework(2)_功能介绍及解接口分析 2017-05-02

2017年6月

Mon, 01 Jan 0001 00:00:00 +0000

2017年6月共 3 篇。

CMA模块学习笔记 2017-06-28
linux内核中的GPIO系统之（4）：pinctrl驱动的理解和总结 2017-06-27
为什么会有文件系统(二) 2017-06-27

2017年7月

Mon, 01 Jan 0001 00:00:00 +0000

2017年7月共 4 篇。

X-024-OHTHERS-在windows平台下使用libusb 2017-07-23
Dynamic DMA mapping Guide 2017-07-20
X-023-KERNEL-Linux pinctrl driver的移植 2017-07-14
蜗窝微信群问题整理 2017-07-11

2017年8月

Mon, 01 Jan 0001 00:00:00 +0000

2017年8月共 4 篇。

页面回收的基本概念 2017-08-25
/proc/meminfo分析（一） 2017-08-17
linux内核中的GPIO系统之（5）：gpio subsysem和pinctrl subsystem之间的耦合 2017-08-10
《奔跑吧，Linux内核》已经上架预售了 2017-08-05

2017年9月

Mon, 01 Jan 0001 00:00:00 +0000

2017年9月共 5 篇。

X-026-KERNEL-Linux gpio driver的移植之gpio range 2017-09-27
Device Tree（四）：文件结构解析 2017-09-24
X-025-KERNEL-Linux gpio driver的移植之基本功能 2017-09-13
蓝牙协议分析(11)_BLE安全机制之SM 2017-09-07
Linux reset framework 2017-09-01

2018年10月

Mon, 01 Jan 0001 00:00:00 +0000

2018年10月共 2 篇。

CFS调度器（2）-源码解析 2018-10-21
CFS调度器（1）-基本原理 2018-10-07

2018年11月

Mon, 01 Jan 0001 00:00:00 +0000

2018年11月共 1 篇。

CFS调度器（3）-组调度 2018-11-10

2018年12月

Mon, 01 Jan 0001 00:00:00 +0000

2018年12月共 2 篇。

CFS调度器（5）-带宽控制 2018-12-22
CFS调度器（4）-PELT(per entity load tracking) 2018-12-02

2018年1月

Mon, 01 Jan 0001 00:00:00 +0000

2018年1月共 5 篇。

2018年2月

Mon, 01 Jan 0001 00:00:00 +0000

2018年2月共 4 篇。

2018年4月

Mon, 01 Jan 0001 00:00:00 +0000

2018年4月共 7 篇。

fixmap addresses原理 2018-04-29
文件系统和裸块设备的page cache问题 2018-04-28
一次触摸屏中断调试引发的深入探究 2018-04-23
ARM64 Kernel Image Mapping的变化 2018-04-21
tty驱动分析 2018-04-20
ftrace时间精度issue修复 2018-04-16
致驱动工程师的一封信 2018-04-14

2018年5月

Mon, 01 Jan 0001 00:00:00 +0000

2018年5月共 1 篇。

KASLR 2018-05-06

2018年6月

Mon, 01 Jan 0001 00:00:00 +0000

2018年6月共 1 篇。

Linux中常见同步机制设计原理 2018-06-09

2018年8月

Mon, 01 Jan 0001 00:00:00 +0000

2018年8月共 1 篇。

per-entity load tracking 2018-08-18

2019年12月

Mon, 01 Jan 0001 00:00:00 +0000

2019年12月共 3 篇。

以太网驱动的流程浅析(二)-Ifconfig的详细代码流程 2019-12-27
以太网驱动的流程浅析(三)-ifconfig的-19错误最底层分析 2019-12-27
以太网驱动的流程浅析(一)-Ifconfig主要流程 2019-12-06

2019年1月

Mon, 01 Jan 0001 00:00:00 +0000

2019年1月共 3 篇。

2019年3月

Mon, 01 Jan 0001 00:00:00 +0000

2019年3月共 1 篇。

内存一致性模型 2019-03-24

2019年5月

Mon, 01 Jan 0001 00:00:00 +0000

2019年5月共 4 篇。

2020年1月

Mon, 01 Jan 0001 00:00:00 +0000

2020年1月共 3 篇。

F2FS技术拆解 2020-01-31
以太网驱动的流程浅析(五)-mii_bus初始化以及phy id的获取 2020-01-07
以太网驱动的流程浅析(四)-以太网驱动probe流程 2020-01-07

2020年2月

Mon, 01 Jan 0001 00:00:00 +0000

2020年2月共 2 篇。

Binder从入门到放弃（下） 2020-02-18
Binder从入门到放弃（上） 2020-02-18

2020年3月

Mon, 01 Jan 0001 00:00:00 +0000

2020年3月共 3 篇。

2021年11月

Mon, 01 Jan 0001 00:00:00 +0000

2021年11月共 5 篇。

2021年12月

Mon, 01 Jan 0001 00:00:00 +0000

2021年12月共 1 篇。

CFS任务放置代码详解 2021-12-31

2021年5月

Mon, 01 Jan 0001 00:00:00 +0000

2021年5月共 3 篇。

2021年6月

Mon, 01 Jan 0001 00:00:00 +0000

2021年6月共 1 篇。

一个较复杂dcache问题 2021-06-11

2021年7月

Mon, 01 Jan 0001 00:00:00 +0000

2021年7月共 1 篇。

mellanox的网卡故障分析 2021-07-06

2022年10月

Mon, 01 Jan 0001 00:00:00 +0000

2022年10月共 1 篇。

futex基础问答 2022-10-09

2022年2月

Mon, 01 Jan 0001 00:00:00 +0000

2022年2月共 2 篇。

load_balance函数代码详解 2022-02-16
CPU 多核指令 —— WFE 原理 2022-02-11

2022年4月

Mon, 01 Jan 0001 00:00:00 +0000

2022年4月共 2 篇。

schedutil governor情景分析 2022-04-26
PELT算法浅析 2022-04-07

2022年5月

Mon, 01 Jan 0001 00:00:00 +0000

2022年5月共 1 篇。

Linux内核同步机制之（八）：mutex 2022-05-10

2022年6月

Mon, 01 Jan 0001 00:00:00 +0000

2022年6月共 1 篇。

Linux内核同步机制之（九）：Queued spinlock 2022-06-29

2022年8月

Mon, 01 Jan 0001 00:00:00 +0000

2022年8月共 1 篇。

如何使能500个virtio_blk设备 2022-08-12

2023年5月

Mon, 01 Jan 0001 00:00:00 +0000

2023年5月共 1 篇。

Linux读写锁逻辑解析 2023-05-29

2024年2月

Mon, 01 Jan 0001 00:00:00 +0000

2024年2月共 1 篇。

mmap在arm64背后的那个深坑 2024-02-28

2025年4月

Mon, 01 Jan 0001 00:00:00 +0000

2025年4月共 5 篇。

linux thermal framework(5)_thermal core 2025-04-14
linux thermal framework(4)_thermal governor 2025-04-14
linux thermal framework(3)_thermal cooling device 2025-04-14
linux thermal framework(2)_thermal zone 2025-04-14
linux thermal framework(1)_概述 2025-04-14

ARMv8A Arch

Mon, 01 Jan 0001 00:00:00 +0000

分类「ARMv8A Arch」共 15 篇。

CPU 多核指令 —— WFE 原理 2022-02-11
Atomic operation in aarch64 2021-11-15
ARMv8之Observability 2016-05-25
ARMv8之memory model 2016-05-18
ARMv8之Atomicity 2016-05-13
ARM64的启动过程之（六）：异常向量表的设定 2015-11-24
ARM64的启动过程之（五）：UEFI 2015-10-30
ARM64的启动过程之（四）：打开MMU 2015-10-24
ARM64的启动过程之（三）：为打开MMU而进行的CPU初始化 2015-10-21
ARM64的启动过程之（二）：创建启动阶段的页表 2015-10-13
ARM64的启动过程之（一）：内核第一个脚印 2015-10-10
ARMv8-a架构简介 2015-07-07
ARM WFI和WFE指令 2014-12-10
ARM概念梳理：Architecture, Core, CPU，SOC 2014-12-09
为什么会有“ARMv8A Architecture”这个分类 2014-12-06

GPIO子系统

Mon, 01 Jan 0001 00:00:00 +0000

分类「GPIO子系统」共 5 篇。

linux内核中的GPIO系统之（5）：gpio subsysem和pinctrl subsystem之间的耦合 2017-08-10
linux内核中的GPIO系统之（4）：pinctrl驱动的理解和总结 2017-06-27
linux内核中的GPIO系统之（2）：pin control subsystem 2014-07-26
Linux内核中的GPIO系统之（3）：pin controller driver代码分析 2014-07-22
linux内核中的GPIO系统之（1）：软件框架 2014-07-21

Linux内核分析

Mon, 01 Jan 0001 00:00:00 +0000

分类「Linux内核分析」共 25 篇。

mmap在arm64背后的那个深坑 2024-02-28
如何使能500个virtio_blk设备 2022-08-12
mellanox的网卡故障分析 2021-07-06
一个较复杂dcache问题 2021-06-11
关于java单线程经常占用cpu100%分析 2021-05-08
关于numa loadbance的死锁分析 2021-05-08
一例ext4使用的jbd2模块死锁分析 2021-05-08
一例hardened_usercopy的bug解析 2020-03-30
一例centos7.6内核hardlock的解析 2020-03-30
Binder从入门到放弃（上） 2020-02-18
以太网驱动的流程浅析(五)-mii_bus初始化以及phy id的获取 2020-01-07
以太网驱动的流程浅析(四)-以太网驱动probe流程 2020-01-07
以太网驱动的流程浅析(二)-Ifconfig的详细代码流程 2019-12-27
以太网驱动的流程浅析(三)-ifconfig的-19错误最底层分析 2019-12-27
以太网驱动的流程浅析(一)-Ifconfig主要流程 2019-12-06
一次触摸屏中断调试引发的深入探究 2018-04-23
ftrace时间精度issue修复 2018-04-16
Linux DMA Engine framework(3)_dma controller驱动 2017-05-18
Linux DMA Engine framework(2)_功能介绍及解接口分析 2017-05-02
Linux DMA Engine framework(1)_概述 2017-03-30
Linux kernel内核配置解析(5)_Boot options(基于ARM64架构) 2016-08-12
Linux kernel内核配置解析(1)_概述(基于ARM64架构) 2016-08-10
作業系統之前的程式 for rpi2 (1) - mmu (0) : 位址轉換 2015-10-27
关于spin_lock的问题 2014-12-12
Linux内核的整体架构 2014-02-21

Linux应用技巧

Mon, 01 Jan 0001 00:00:00 +0000

分类「Linux应用技巧」共 13 篇。

Debian8 内核升级实验 2017-02-27
Linux kernel debug技巧—-开启DEBUG选项 2016-11-01
使用pxe方式安装系统 2016-04-23
Linux操作命令记录 2016-04-20
Debian下的WiFi实验（二）：无线网卡自动连接AP 2016-03-24
systemd：为何要创建一个新的init系统软件 2016-03-17
Debian下的WiFi实验（一）：通过无线网卡连接AP 2016-03-08
我的bash shell学习笔记 2015-01-01
新技能get: 订阅Linux内核邮件列表 2014-11-04
vim使用技巧摘录 2014-06-10
process credentials相关的用户空间文件 2014-04-02
调试手段之sys节点 2014-03-09
MinGW下安装man工具包 2014-01-24

TTY子系统

Mon, 01 Jan 0001 00:00:00 +0000

分类「TTY子系统」共 6 篇。

tty驱动分析 2018-04-20
Linux TTY framework(5)_System console driver 2016-10-29
Linux TTY framework(4)_TTY driver 2016-10-25
Linux TTY framework(3)_从应用的角度看TTY设备 2016-10-14
Linux TTY framework(2)_软件架构 2016-09-27
Linux TTY framework(1)_基本概念 2016-09-18

u-boot分析

Mon, 01 Jan 0001 00:00:00 +0000

分类「u-boot分析」共 3 篇。

USB

Mon, 01 Jan 0001 00:00:00 +0000

分类「USB」共 1 篇。

USB-C(USB Type-C)规范的简单介绍和分析 2017-12-18

X Project

Mon, 01 Jan 0001 00:00:00 +0000

分类「X Project」共 28 篇。

X-026-KERNEL-Linux gpio driver的移植之gpio range 2017-09-27
X-025-KERNEL-Linux gpio driver的移植之基本功能 2017-09-13
X-024-OHTHERS-在windows平台下使用libusb 2017-07-23
X-023-KERNEL-Linux pinctrl driver的移植 2017-07-14
X-022-OTHERS-git操作记录之合并远端分支的更新 2017-01-02
基于Hikey的"Boot from USB"调试 2016-12-20
X-021-ROOTFS-基于busybox的最简rootfs的制作 2016-12-05
X-020-ROOTFS-initramfs的制作和测试 2016-12-03
X-019-KERNEL-串口驱动开发之数据收发 2016-11-29
X-018-KERNEL-串口驱动开发之serial console 2016-11-18
X-017-KERNEL-串口驱动开发之uart driver框架 2016-11-16
X-016-KERNEL-串口驱动开发之驱动框架 2016-11-10
X-015-KERNEL-ARM generic timer driver的移植 2016-11-02
X-014-KERNEL-ARM GIC driver的移植 2016-10-31
X-013-UBOOT-使能autoboot功能 2016-10-05
X-012-KERNEL-serial early console的移植 2016-10-02
X-011-UBOOT-使用bootm命令启动kernel(Bubblegum-96平台) 2016-09-09
X-010-UBOOT-使用booti命令启动kernel(Bubblegum-96平台) 2016-08-24
X-009-KERNEL-Linux kernel的移植(Bubblegum-96平台) 2016-08-19
X-008-UBOOT-支持命令行(Bubblegum-96平台) 2016-07-27
X-007-UBOOT-DDR的初始化(Bubblegum-96平台) 2016-07-21
X-006-UBOOT-pinctrl driver移植(Bubblegum-96平台) 2016-07-09
X-005-UBOOT-device tree移植(Bubblegum-96平台) 2016-06-29
X-004-UBOOT-串口驱动移植(Bubblegum-96平台) 2016-06-18
X-003-UBOOT-基于Bubblegum-96平台的u-boot移植说明 2016-05-29
X-002-HW-S900芯片boot from USB有关的硬件描述 2016-05-12
X-001-PRE-git介绍及操作记录 2016-04-26
X-000-PRE-开发环境搭建 2016-04-23

标签：__create_page_tables

Mon, 01 Jan 0001 00:00:00 +0000

带标签「__create_page_tables」的文章共 2 篇。

标签：2D

Mon, 01 Jan 0001 00:00:00 +0000

带标签「2D」的文章共 1 篇。

显示技术介绍(1)_概述 2015-11-22

标签：2M

Mon, 01 Jan 0001 00:00:00 +0000

带标签「2M」的文章共 1 篇。

快讯：蓝牙5.0发布（新特性速览） 2016-12-08

标签：3.1

Mon, 01 Jan 0001 00:00:00 +0000

带标签「3.1」的文章共 1 篇。

USB-C(USB Type-C)规范的简单介绍和分析 2017-12-18

标签：3.18

Mon, 01 Jan 0001 00:00:00 +0000

带标签「3.18」的文章共 1 篇。

Linux 3.18U盘无法正确使用 2015-10-28

标签：3D

Mon, 01 Jan 0001 00:00:00 +0000

带标签「3D」的文章共 1 篇。

显示技术介绍(1)_概述 2015-11-22

标签：5.0

Mon, 01 Jan 0001 00:00:00 +0000

带标签「5.0」的文章共 1 篇。

快讯：蓝牙5.0发布（新特性速览） 2016-12-08

标签：aarch64

Mon, 01 Jan 0001 00:00:00 +0000

带标签「aarch64」的文章共 5 篇。

Atomic operation in aarch64 2021-11-15
irq wakeup in linux 2021-11-15
ARM WFI和WFE指令 2014-12-10
为什么会有“ARMv8A Architecture”这个分类 2014-12-06
arm64 linux移植 2014-10-23

标签：ACCESS_ONCE

Mon, 01 Jan 0001 00:00:00 +0000

带标签「ACCESS_ONCE」的文章共 1 篇。

ACCESS_ONCE宏定义的解释 2014-07-17

标签：add

Mon, 01 Jan 0001 00:00:00 +0000

带标签「add」的文章共 1 篇。

X-022-OTHERS-git操作记录之合并远端分支的更新 2017-01-02

标签：address

Mon, 01 Jan 0001 00:00:00 +0000

带标签「address」的文章共 1 篇。

蓝牙协议分析(6)_BLE地址类型 2016-06-07

标签：advertising

Mon, 01 Jan 0001 00:00:00 +0000

带标签「advertising」的文章共 2 篇。

蓝牙协议分析(5)_BLE广播通信相关的技术分析 2016-05-27
玩转BLE(2)_使用bluepy扫描BLE的广播数据 2016-05-19

标签：airsync

Mon, 01 Jan 0001 00:00:00 +0000

带标签「airsync」的文章共 1 篇。

玩转BLE(3)_使用微信蓝牙精简协议伪造记步数据 2017-03-11

标签：aliases

Mon, 01 Jan 0001 00:00:00 +0000

带标签「aliases」的文章共 1 篇。

X-018-KERNEL-串口驱动开发之serial console 2016-11-18

标签：alloc_workqueue

Mon, 01 Jan 0001 00:00:00 +0000

带标签「alloc_workqueue」的文章共 1 篇。

Concurrency Managed Workqueue之（三）：创建workqueue代码分析 2015-08-06

标签：Allocator

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Allocator」的文章共 1 篇。

CMA模块学习笔记 2017-06-28

标签：AMP

Mon, 01 Jan 0001 00:00:00 +0000

带标签「AMP」的文章共 1 篇。

蓝牙协议分析(1)_基本概念 2014-05-23

标签：Android

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Android」的文章共 1 篇。

Linux电源管理(9)_wakelocks 2014-09-14

标签：API

Mon, 01 Jan 0001 00:00:00 +0000

带标签「API」的文章共 2 篇。

Linux DMA Engine framework(2)_功能介绍及解接口分析 2017-05-02
Linux common clock framework(1)_概述 2014-10-20

标签：Architecture

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Architecture」的文章共 7 篇。

Linux MMC framework(1)_软件架构 2017-01-10
Linux TTY framework(2)_软件架构 2016-09-27
Linux I2C framework(1)_概述 2016-02-14
ARM WFI和WFE指令 2014-12-10
ARM概念梳理：Architecture, Core, CPU，SOC 2014-12-09
为什么会有“ARMv8A Architecture”这个分类 2014-12-06
Linux电源管理(1)_整体架构 2014-05-07

标签：ARM

Mon, 01 Jan 0001 00:00:00 +0000

带标签「ARM」的文章共 6 篇。

CPU 多核指令 —— WFE 原理 2022-02-11
ARM Linux上的系统调用代码分析 2017-02-20
u-boot启动流程分析(1)_平台相关部分 2016-05-19
linux cpufreq framework(5)_ARM big Little driver 2015-11-10
ARM WFI和WFE指令 2014-12-10
ARM概念梳理：Architecture, Core, CPU，SOC 2014-12-09

标签：arm_arch_timer

Mon, 01 Jan 0001 00:00:00 +0000

带标签「arm_arch_timer」的文章共 1 篇。

Linux时间子系统之（十七）：ARM generic timer驱动代码分析 2014-12-02

标签：arm64

Mon, 01 Jan 0001 00:00:00 +0000

带标签「arm64」的文章共 12 篇。

Atomic operation in aarch64 2021-11-15
X-011-UBOOT-使用bootm命令启动kernel(Bubblegum-96平台) 2016-09-09
X-010-UBOOT-使用booti命令启动kernel(Bubblegum-96平台) 2016-08-24
ARM64架构下地址翻译相关的宏定义 2016-08-12
u-boot启动流程分析(1)_平台相关部分 2016-05-19
ARM64的启动过程之（六）：异常向量表的设定 2015-11-24
ARM64的启动过程之（五）：UEFI 2015-10-30
ARM64的启动过程之（一）：内核第一个脚印 2015-10-10
ARMv8-a架构简介 2015-07-07
Linux cpuidle framework(3)_ARM64 generic CPU idle driver 2015-01-06
为什么会有“ARMv8A Architecture”这个分类 2014-12-06
arm64 linux移植 2014-10-23

标签：ARM64启动过程

Mon, 01 Jan 0001 00:00:00 +0000

带标签「ARM64启动过程」的文章共 1 篇。

ARM64的启动过程之（三）：为打开MMU而进行的CPU初始化 2015-10-21

标签：armv7-timer

Mon, 01 Jan 0001 00:00:00 +0000

带标签「armv7-timer」的文章共 1 篇。

Linux时间子系统之（十七）：ARM generic timer驱动代码分析 2014-12-02

标签：ARMv8

Mon, 01 Jan 0001 00:00:00 +0000

带标签「ARMv8」的文章共 2 篇。

ARMv8之Observability 2016-05-25
ARMv8之memory model 2016-05-18

标签：armv8-a

Mon, 01 Jan 0001 00:00:00 +0000

带标签「armv8-a」的文章共 2 篇。

ARMv8-a架构简介 2015-07-07
为什么会有“ARMv8A Architecture”这个分类 2014-12-06

标签：ARM性能

Mon, 01 Jan 0001 00:00:00 +0000

带标签「ARM性能」的文章共 1 篇。

ARM CPU性能实验 2015-04-09

标签：atomic

Mon, 01 Jan 0001 00:00:00 +0000

带标签「atomic」的文章共 2 篇。

Atomic operation in aarch64 2021-11-15
Linux内核同步机制之（一）：原子操作 2014-10-10

标签：atomicity

Mon, 01 Jan 0001 00:00:00 +0000

带标签「atomicity」的文章共 1 篇。

ARMv8之Atomicity 2016-05-13

标签：att

Mon, 01 Jan 0001 00:00:00 +0000

带标签「att」的文章共 1 篇。

蓝牙协议分析(3)_蓝牙低功耗(BLE)协议栈介绍 2016-03-12

标签：authentication

Mon, 01 Jan 0001 00:00:00 +0000

带标签「authentication」的文章共 1 篇。

蓝牙协议分析(11)_BLE安全机制之SM 2017-09-07

标签：autoboot

Mon, 01 Jan 0001 00:00:00 +0000

带标签「autoboot」的文章共 1 篇。

X-013-UBOOT-使能autoboot功能 2016-10-05

标签：autosleep

Mon, 01 Jan 0001 00:00:00 +0000

带标签「autosleep」的文章共 1 篇。

Linux电源管理(10)_autosleep 2014-09-18

标签：back

Mon, 01 Jan 0001 00:00:00 +0000

带标签「back」的文章共 1 篇。

显示技术介绍(3)_CRT技术 2016-01-30

标签：balance

Mon, 01 Jan 0001 00:00:00 +0000

带标签「balance」的文章共 1 篇。

CFS任务的负载均衡（load balance） 2021-11-22

标签：bandwidth

Mon, 01 Jan 0001 00:00:00 +0000

带标签「bandwidth」的文章共 1 篇。

CFS调度器（5）-带宽控制 2018-12-22

标签：barrier

Mon, 01 Jan 0001 00:00:00 +0000

带标签「barrier」的文章共 5 篇。

编译乱序(Compiler Reordering) 2019-01-23
perfbook memory barrier（14.2章节）中文翻译（下） 2016-01-11
Why Memory Barriers中文翻译（下） 2016-01-05
Why Memory Barriers？中文翻译（上） 2015-12-10
Linux内核同步机制之（三）：memory barrier 2014-11-14

标签：baud

Mon, 01 Jan 0001 00:00:00 +0000

带标签「baud」的文章共 1 篇。

串口通信技术浅析 2016-06-24

标签：beacon

Mon, 01 Jan 0001 00:00:00 +0000

带标签「beacon」的文章共 1 篇。

玩转BLE(1)_Eddystone beacon 2016-04-29

标签：big

Mon, 01 Jan 0001 00:00:00 +0000

带标签「big」的文章共 1 篇。

linux cpufreq framework(5)_ARM big Little driver 2015-11-10

标签：binder

Mon, 01 Jan 0001 00:00:00 +0000

带标签「binder」的文章共 2 篇。

Binder从入门到放弃（下） 2020-02-18
Binder从入门到放弃（上） 2020-02-18

标签：Bird

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Bird」的文章共 1 篇。

由Flappy Bird想到的技术观、哲学观和人生观 2014-02-13

标签：blank

Mon, 01 Jan 0001 00:00:00 +0000

带标签「blank」的文章共 1 篇。

显示技术介绍(3)_CRT技术 2016-01-30

标签：BLE

Mon, 01 Jan 0001 00:00:00 +0000

带标签「BLE」的文章共 13 篇。

蓝牙协议分析(11)_BLE安全机制之SM 2017-09-07
蓝牙协议分析(10)_BLE安全机制之LE Encryption 2017-03-28
玩转BLE(3)_使用微信蓝牙精简协议伪造记步数据 2017-03-11
蓝牙协议分析(9)_BLE安全机制之LL Privacy 2016-11-25
蓝牙协议分析(8)_BLE安全机制之白名单 2016-11-10
蓝牙协议分析(7)_BLE连接有关的技术分析 2016-07-01
蓝牙协议分析(6)_BLE地址类型 2016-06-07
蓝牙协议分析(5)_BLE广播通信相关的技术分析 2016-05-27
玩转BLE(2)_使用bluepy扫描BLE的广播数据 2016-05-19
玩转BLE(1)_Eddystone beacon 2016-04-29
蓝牙协议分析(4)_IPv6 Over BLE介绍 2016-04-09
蓝牙协议分析(3)_蓝牙低功耗(BLE)协议栈介绍 2016-03-12
蓝牙协议分析(1)_基本概念 2014-05-23

标签：bluepy

Mon, 01 Jan 0001 00:00:00 +0000

带标签「bluepy」的文章共 1 篇。

玩转BLE(2)_使用bluepy扫描BLE的广播数据 2016-05-19

标签：Bluetooth

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Bluetooth」的文章共 9 篇。

蓝牙协议分析(11)_BLE安全机制之SM 2017-09-07
蓝牙协议分析(10)_BLE安全机制之LE Encryption 2017-03-28
玩转BLE(3)_使用微信蓝牙精简协议伪造记步数据 2017-03-11
快讯：蓝牙5.0发布（新特性速览） 2016-12-08
蓝牙协议分析(8)_BLE安全机制之白名单 2016-11-10
玩转BLE(2)_使用bluepy扫描BLE的广播数据 2016-05-19
蓝牙协议分析(3)_蓝牙低功耗(BLE)协议栈介绍 2016-03-12
蓝牙协议分析(2)_协议架构 2016-01-14
蓝牙协议分析(1)_基本概念 2014-05-23

标签：board

Mon, 01 Jan 0001 00:00:00 +0000

带标签「board」的文章共 1 篇。

u-boot启动流程分析(2)_板级(board)部分 2016-06-07

标签：boot

Mon, 01 Jan 0001 00:00:00 +0000

带标签「boot」的文章共 5 篇。

基于Hikey的"Boot from USB"调试 2016-12-20
X-013-UBOOT-使能autoboot功能 2016-10-05
Linux kernel内核配置解析(5)_Boot options(基于ARM64架构) 2016-08-12
u-boot启动流程分析(1)_平台相关部分 2016-05-19
X-002-HW-S900芯片boot from USB有关的硬件描述 2016-05-12

标签：booti

Mon, 01 Jan 0001 00:00:00 +0000

带标签「booti」的文章共 1 篇。

X-010-UBOOT-使用booti命令启动kernel(Bubblegum-96平台) 2016-08-24

标签：bootm

Mon, 01 Jan 0001 00:00:00 +0000

带标签「bootm」的文章共 3 篇。

X-013-UBOOT-使能autoboot功能 2016-10-05
X-011-UBOOT-使用bootm命令启动kernel(Bubblegum-96平台) 2016-09-09
X-010-UBOOT-使用booti命令启动kernel(Bubblegum-96平台) 2016-08-24

标签：BR

Mon, 01 Jan 0001 00:00:00 +0000

带标签「BR」的文章共 1 篇。

蓝牙协议分析(1)_基本概念 2014-05-23

标签：broadcast

Mon, 01 Jan 0001 00:00:00 +0000

带标签「broadcast」的文章共 1 篇。

Linux时间子系统之（十四）：tick broadcast framework 2015-05-21

标签：bubblegum

Mon, 01 Jan 0001 00:00:00 +0000

带标签「bubblegum」的文章共 1 篇。

X-003-UBOOT-基于Bubblegum-96平台的u-boot移植说明 2016-05-29

标签：build

Mon, 01 Jan 0001 00:00:00 +0000

带标签「build」的文章共 1 篇。

X-000-PRE-开发环境搭建 2016-04-23

标签：bus

Mon, 01 Jan 0001 00:00:00 +0000

带标签「bus」的文章共 1 篇。

Linux设备模型(6)_Bus 2014-04-15

标签：busybox

Mon, 01 Jan 0001 00:00:00 +0000

带标签「busybox」的文章共 1 篇。

X-021-ROOTFS-基于busybox的最简rootfs的制作 2016-12-05

标签：cache

Mon, 01 Jan 0001 00:00:00 +0000

带标签「cache」的文章共 1 篇。

计算机科学基础知识（一）:The Memory Hierarchy 2014-06-16

标签：cdev

Mon, 01 Jan 0001 00:00:00 +0000

带标签「cdev」的文章共 1 篇。

kobject在字符设备中的使用 2014-12-04

标签：CFS

Mon, 01 Jan 0001 00:00:00 +0000

带标签「CFS」的文章共 5 篇。

标签：class

Mon, 01 Jan 0001 00:00:00 +0000

带标签「class」的文章共 2 篇。

Linux power supply class(1)_软件架构及API汇整 2015-03-13
Linux设备模型(7)_Class 2014-04-23

标签：clock

Mon, 01 Jan 0001 00:00:00 +0000

带标签「clock」的文章共 5 篇。

Linux的时钟 2017-05-17
Common Clock Framework系统结构 2016-04-21
Linux common clock framework(3)_实现逻辑分析 2014-11-24
Linux common clock framework(2)_clock provider 2014-10-23
Linux common clock framework(1)_概述 2014-10-20

标签：clockevent

Mon, 01 Jan 0001 00:00:00 +0000

带标签「clockevent」的文章共 1 篇。

Linux时间子系统之（十六）：clockevent 2014-12-09

标签：clocksource

Mon, 01 Jan 0001 00:00:00 +0000

带标签「clocksource」的文章共 1 篇。

Linux时间子系统之（十五）：clocksource 2014-12-01

标签：CMA

Mon, 01 Jan 0001 00:00:00 +0000

带标签「CMA」的文章共 1 篇。

CMA模块学习笔记 2017-06-28

标签：cmdline

Mon, 01 Jan 0001 00:00:00 +0000

带标签「cmdline」的文章共 1 篇。

X-008-UBOOT-支持命令行(Bubblegum-96平台) 2016-07-27

标签：CMWQ

Mon, 01 Jan 0001 00:00:00 +0000

带标签「CMWQ」的文章共 1 篇。

Concurrency Managed Workqueue之（二）：CMWQ概述 2015-07-31

标签：Coherent

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Coherent」的文章共 1 篇。

ARMv8之Atomicity 2016-05-13

标签：commit

Mon, 01 Jan 0001 00:00:00 +0000

带标签「commit」的文章共 1 篇。

X-001-PRE-git介绍及操作记录 2016-04-26

标签：common

Mon, 01 Jan 0001 00:00:00 +0000

带标签「common」的文章共 1 篇。

Common Clock Framework系统结构 2016-04-21

标签：Concurrency

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Concurrency」的文章共 1 篇。

Concurrency Managed Workqueue之（四）：workqueue如何处理work 2015-08-17

标签：connect

Mon, 01 Jan 0001 00:00:00 +0000

带标签「connect」的文章共 1 篇。

蓝牙协议分析(5)_BLE广播通信相关的技术分析 2016-05-27

标签：connection

Mon, 01 Jan 0001 00:00:00 +0000

带标签「connection」的文章共 1 篇。

蓝牙协议分析(7)_BLE连接有关的技术分析 2016-07-01

标签：consistency

Mon, 01 Jan 0001 00:00:00 +0000

带标签「consistency」的文章共 1 篇。

ARMv8之memory model 2016-05-18

标签：console

Mon, 01 Jan 0001 00:00:00 +0000

带标签「console」的文章共 6 篇。

X-018-KERNEL-串口驱动开发之serial console 2016-11-18
X-017-KERNEL-串口驱动开发之uart driver框架 2016-11-16
Linux TTY framework(5)_System console driver 2016-10-29
Linux TTY framework(3)_从应用的角度看TTY设备 2016-10-14
X-012-KERNEL-serial early console的移植 2016-10-02
Linux TTY framework(1)_基本概念 2016-09-18

标签：consumer

Mon, 01 Jan 0001 00:00:00 +0000

带标签「consumer」的文章共 1 篇。

Linux I2C framework(3)_I2C consumer 2016-03-23

标签：context_switch

Mon, 01 Jan 0001 00:00:00 +0000

带标签「context_switch」的文章共 1 篇。

进程切换分析(1)：基本框架 2017-02-04

标签：Contiguous

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Contiguous」的文章共 1 篇。

CMA模块学习笔记 2017-06-28

标签：control

Mon, 01 Jan 0001 00:00:00 +0000

带标签「control」的文章共 1 篇。

linux内核中的GPIO系统之（2）：pin control subsystem 2014-07-26

标签：controller

Mon, 01 Jan 0001 00:00:00 +0000

带标签「controller」的文章共 2 篇。

Linux DMA Engine framework(3)_dma controller驱动 2017-05-18
Linux内核中的GPIO系统之（3）：pin controller driver代码分析 2014-07-22

标签：copy_to_user

Mon, 01 Jan 0001 00:00:00 +0000

带标签「copy_to_user」的文章共 1 篇。

copy_{to,from}_user()的思考 2019-01-27

标签：core

Mon, 01 Jan 0001 00:00:00 +0000

带标签「core」的文章共 4 篇。

linux cpufreq framework(3)_cpufreq core 2015-07-30
Linux CPU core的电源管理(1)_概述 2015-04-30
Linux cpuidle framework(2)_cpuidle core 2014-12-30
ARM概念梳理：Architecture, Core, CPU，SOC 2014-12-09

标签：count

Mon, 01 Jan 0001 00:00:00 +0000

带标签「count」的文章共 1 篇。

Linux电源管理(8)_Wakeup count功能 2014-09-12

标签：cpu

Mon, 01 Jan 0001 00:00:00 +0000

带标签「cpu」的文章共 4 篇。

Linux CPU core的电源管理(5)_cpu control及cpu hotplug 2015-09-19
Linux CPU core的电源管理(3)_cpu ops 2015-07-17
Linux CPU core的电源管理(2)_cpu topology 2015-05-30
Linux CPU core的电源管理(1)_概述 2015-04-30

标签：cpu_down

Mon, 01 Jan 0001 00:00:00 +0000

带标签「cpu_down」的文章共 1 篇。

Linux CPU core的电源管理(5)_cpu control及cpu hotplug 2015-09-19

标签：cpu_up

Mon, 01 Jan 0001 00:00:00 +0000

带标签「cpu_up」的文章共 1 篇。

Linux CPU core的电源管理(5)_cpu control及cpu hotplug 2015-09-19

标签：cpufreq

Mon, 01 Jan 0001 00:00:00 +0000

带标签「cpufreq」的文章共 5 篇。

linux cpufreq framework(5)_ARM big Little driver 2015-11-10
linux cpufreq framework(4)_cpufreq governor 2015-08-23
linux cpufreq framework(3)_cpufreq core 2015-07-30
Linux cpufreq framework(2)_cpufreq driver 2015-06-19
linux cpufreq framework(1)_概述 2015-06-13

标签：cpuidle

Mon, 01 Jan 0001 00:00:00 +0000

带标签「cpuidle」的文章共 4 篇。

Linux cpuidle framework(4)_menu governor 2015-01-18
Linux cpuidle framework(3)_ARM64 generic CPU idle driver 2015-01-06
Linux cpuidle framework(2)_cpuidle core 2014-12-30
Linux cpuidle framework(1)_概述和软件架构 2014-12-17

标签：create_mapping

Mon, 01 Jan 0001 00:00:00 +0000

带标签「create_mapping」的文章共 1 篇。

内存初始化代码分析（三）：创建系统内存地址映射 2016-11-24

标签：CRT

Mon, 01 Jan 0001 00:00:00 +0000

带标签「CRT」的文章共 2 篇。

显示技术介绍(3)_CRT技术 2016-01-30
显示技术介绍(2)_电子显示的前世今生 2015-11-30

标签：CSMA/CA

Mon, 01 Jan 0001 00:00:00 +0000

带标签「CSMA/CA」的文章共 1 篇。

防冲突机制介绍 2014-10-24

标签：ddr

Mon, 01 Jan 0001 00:00:00 +0000

带标签「ddr」的文章共 1 篇。

X-007-UBOOT-DDR的初始化(Bubblegum-96平台) 2016-07-21

标签：Deadline

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Deadline」的文章共 1 篇。

Deadline调度器之（二）：细节和使用方法 2018-02-22

标签：deadline调度器

Mon, 01 Jan 0001 00:00:00 +0000

带标签「deadline调度器」的文章共 1 篇。

deadline调度器之（一）：原理 2018-01-31

标签：debug

Mon, 01 Jan 0001 00:00:00 +0000

带标签「debug」的文章共 3 篇。

Linux kernel debug技巧—-开启DEBUG选项 2016-11-01
通过点亮LED的方法调试嵌入式代码 2016-06-12
小printf大作用（用日志打印的方式调试程序） 2014-01-23

标签：denx

Mon, 01 Jan 0001 00:00:00 +0000

带标签「denx」的文章共 1 篇。

X-022-OTHERS-git操作记录之合并远端分支的更新 2017-01-02

标签：dev_dbg

Mon, 01 Jan 0001 00:00:00 +0000

带标签「dev_dbg」的文章共 1 篇。

Linux kernel debug技巧—-开启DEBUG选项 2016-11-01

标签：dev_pm_ops

Mon, 01 Jan 0001 00:00:00 +0000

带标签「dev_pm_ops」的文章共 1 篇。

Linux电源管理(4)_Power Management Interface 2014-05-29

标签：Device

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Device」的文章共 6 篇。

Linux时间子系统之（十三）：Tick Device layer综述 2015-03-26
Linux电源管理(14)_从设备驱动的角度看电源管理 2015-03-02
Device Tree（二）：基本概念 2014-05-30
Device Tree（一）：背景介绍 2014-05-22
Linux设备模型(5)_device和device driver 2014-04-02
Linux设备模型(1)_基本概念 2014-02-27

标签：device_tree

Mon, 01 Jan 0001 00:00:00 +0000

带标签「device_tree」的文章共 1 篇。

X-005-UBOOT-device tree移植(Bubblegum-96平台) 2016-06-29

标签：devmem

Mon, 01 Jan 0001 00:00:00 +0000

带标签「devmem」的文章共 1 篇。

Linux下“用户空间修改设备寄存器或者物理内存”的实现 2015-05-15

标签：devres

Mon, 01 Jan 0001 00:00:00 +0000

带标签「devres」的文章共 1 篇。

Linux设备模型(9)_device resource management 2014-09-24

标签：dfu

Mon, 01 Jan 0001 00:00:00 +0000

带标签「dfu」的文章共 1 篇。

X-024-OHTHERS-在windows平台下使用libusb 2017-07-23

标签：discover

Mon, 01 Jan 0001 00:00:00 +0000

带标签「discover」的文章共 1 篇。

蓝牙协议分析(5)_BLE广播通信相关的技术分析 2016-05-27

标签：display

Mon, 01 Jan 0001 00:00:00 +0000

带标签「display」的文章共 1 篇。

Linux graphic subsytem(1)_概述 2015-12-17

标签：dma

Mon, 01 Jan 0001 00:00:00 +0000

带标签「dma」的文章共 4 篇。

Dynamic DMA mapping Guide 2017-07-20
Linux DMA Engine framework(3)_dma controller驱动 2017-05-18
Linux DMA Engine framework(2)_功能介绍及解接口分析 2017-05-02
Linux DMA Engine framework(1)_概述 2017-03-30

标签：DMB

Mon, 01 Jan 0001 00:00:00 +0000

带标签「DMB」的文章共 1 篇。

DMB DSB ISB以及SMP CPU 乱序 2014-08-15

标签：do_fork

Mon, 01 Jan 0001 00:00:00 +0000

带标签「do_fork」的文章共 2 篇。

Process Creation（二） 2014-04-28
Process Creation（一） 2014-04-23

标签：domain

Mon, 01 Jan 0001 00:00:00 +0000

带标签「domain」的文章共 1 篇。

Linux PM domain framework(1)_概述和使用流程 2014-11-13

标签：dpm

Mon, 01 Jan 0001 00:00:00 +0000

带标签「dpm」的文章共 1 篇。

Linux电源管理(4)_Power Management Interface 2014-05-29

标签：dram

Mon, 01 Jan 0001 00:00:00 +0000

带标签「dram」的文章共 6 篇。

DRAM 原理 5 ：DRAM Devices Organization 2016-10-15
DRAM 原理 4 ：DRAM Timing 2016-08-29
DRAM 原理 3 ：DRAM Device 2016-07-27
DRAM 原理 2 ：DRAM Memory Organization 2016-06-14
DRAM 原理 1 ：DRAM Storage Cell 2016-06-08
u-boot启动流程分析(2)_板级(board)部分 2016-06-07

标签：DRI

Mon, 01 Jan 0001 00:00:00 +0000

带标签「DRI」的文章共 2 篇。

Linux graphic subsystem(2)_DRI介绍 2015-12-27
Linux graphic subsytem(1)_概述 2015-12-17

标签：driver

Mon, 01 Jan 0001 00:00:00 +0000

带标签「driver」的文章共 23 篇。

X-026-KERNEL-Linux gpio driver的移植之gpio range 2017-09-27
X-025-KERNEL-Linux gpio driver的移植之基本功能 2017-09-13
X-023-KERNEL-Linux pinctrl driver的移植 2017-07-14
linux内核中的GPIO系统之（4）：pinctrl驱动的理解和总结 2017-06-27
Linux DMA Engine framework(3)_dma controller驱动 2017-05-18
Linux MMC framework(2)_host controller driver 2017-03-08
Linux serial framework(1)_概述 2016-12-12
X-019-KERNEL-串口驱动开发之数据收发 2016-11-29
X-018-KERNEL-串口驱动开发之serial console 2016-11-18
X-017-KERNEL-串口驱动开发之uart driver框架 2016-11-16
X-016-KERNEL-串口驱动开发之驱动框架 2016-11-10
X-014-KERNEL-ARM GIC driver的移植 2016-10-31
Linux TTY framework(5)_System console driver 2016-10-29
Linux TTY framework(4)_TTY driver 2016-10-25
Linux I2C framework(2)_I2C provider 2016-02-26
Linux PWM framework(1)_简介和API描述 2015-10-11
Linux cpufreq framework(2)_cpufreq driver 2015-06-19
Linux Regulator Framework(2)_regulator driver 2015-04-16
Linux电源管理(14)_从设备驱动的角度看电源管理 2015-03-02
Linux cpuidle framework(3)_ARM64 generic CPU idle driver 2015-01-06
Linux电源管理(13)_Driver的电源管理 2014-12-26
Linux内核中的GPIO系统之（3）：pin controller driver代码分析 2014-07-22
Linux设备模型(5)_device和device driver 2014-04-02

标签：drm

Mon, 01 Jan 0001 00:00:00 +0000

带标签「drm」的文章共 1 篇。

Linux graphic subsystem(2)_DRI介绍 2015-12-27

标签：DSB

Mon, 01 Jan 0001 00:00:00 +0000

带标签「DSB」的文章共 1 篇。

DMB DSB ISB以及SMP CPU 乱序 2014-08-15

标签：dtb

Mon, 01 Jan 0001 00:00:00 +0000

带标签「dtb」的文章共 3 篇。

X-010-UBOOT-使用booti命令启动kernel(Bubblegum-96平台) 2016-08-24
X-009-KERNEL-Linux kernel的移植(Bubblegum-96平台) 2016-08-19
X-005-UBOOT-device tree移植(Bubblegum-96平台) 2016-06-29

标签：dtc

Mon, 01 Jan 0001 00:00:00 +0000

带标签「dtc」的文章共 1 篇。

X-005-UBOOT-device tree移植(Bubblegum-96平台) 2016-06-29

标签：dts

Mon, 01 Jan 0001 00:00:00 +0000

带标签「dts」的文章共 3 篇。

X-005-UBOOT-device tree移植(Bubblegum-96平台) 2016-06-29
Linux cpuidle framework(3)_ARM64 generic CPU idle driver 2015-01-06
Linux common clock framework(2)_clock provider 2014-10-23

标签：dvfs

Mon, 01 Jan 0001 00:00:00 +0000

带标签「dvfs」的文章共 1 篇。

linux cpufreq framework(1)_概述 2015-06-13

标签：dynamic

Mon, 01 Jan 0001 00:00:00 +0000

带标签「dynamic」的文章共 1 篇。

计算机科学基础知识（五）: 动态链接 2015-03-10

标签：earlycon

Mon, 01 Jan 0001 00:00:00 +0000

带标签「earlycon」的文章共 1 篇。

X-012-KERNEL-serial early console的移植 2016-10-02

标签：eddystone

Mon, 01 Jan 0001 00:00:00 +0000

带标签「eddystone」的文章共 1 篇。

玩转BLE(1)_Eddystone beacon 2016-04-29

标签：EDR

Mon, 01 Jan 0001 00:00:00 +0000

带标签「EDR」的文章共 1 篇。

蓝牙协议分析(1)_基本概念 2014-05-23

标签：elf

Mon, 01 Jan 0001 00:00:00 +0000

带标签「elf」的文章共 1 篇。

X-020-ROOTFS-initramfs的制作和测试 2016-12-03

标签：emmc

Mon, 01 Jan 0001 00:00:00 +0000

带标签「emmc」的文章共 6 篇。

标签：Encryption

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Encryption」的文章共 1 篇。

蓝牙协议分析(10)_BLE安全机制之LE Encryption 2017-03-28

标签：engine

Mon, 01 Jan 0001 00:00:00 +0000

带标签「engine」的文章共 3 篇。

Linux DMA Engine framework(3)_dma controller驱动 2017-05-18
Linux DMA Engine framework(2)_功能介绍及解接口分析 2017-05-02
Linux DMA Engine framework(1)_概述 2017-03-30

标签：environment

Mon, 01 Jan 0001 00:00:00 +0000

带标签「environment」的文章共 1 篇。

X-000-PRE-开发环境搭建 2016-04-23

标签：events

Mon, 01 Jan 0001 00:00:00 +0000

带标签「events」的文章共 1 篇。

Linux电源管理(7)_Wakeup events framework 2014-09-09

标签：exception

Mon, 01 Jan 0001 00:00:00 +0000

带标签「exception」的文章共 1 篇。

ARM64的启动过程之（六）：异常向量表的设定 2015-11-24

标签：exception_level;security;virtualization

Mon, 01 Jan 0001 00:00:00 +0000

带标签「exception_level;security;virtualization」的文章共 1 篇。

ARMv8-a架构简介 2015-07-07

标签：Extensions

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Extensions」的文章共 1 篇。

快讯：蓝牙5.0发布（新特性速览） 2016-12-08

标签：F2FS

Mon, 01 Jan 0001 00:00:00 +0000

带标签「F2FS」的文章共 1 篇。

F2FS技术拆解 2020-01-31

标签：File

Mon, 01 Jan 0001 00:00:00 +0000

带标签「File」的文章共 1 篇。

计算机科学基础知识（二）:Relocatable Object File 2015-02-09

标签：find....

Mon, 01 Jan 0001 00:00:00 +0000

带标签「find….」的文章共 1 篇。

Linux操作命令记录 2016-04-20

标签：fit

Mon, 01 Jan 0001 00:00:00 +0000

带标签「fit」的文章共 2 篇。

X-011-UBOOT-使用bootm命令启动kernel(Bubblegum-96平台) 2016-09-09
u-boot FIT image介绍 2016-09-02

标签：fixmap

Mon, 01 Jan 0001 00:00:00 +0000

带标签「fixmap」的文章共 1 篇。

Fix-Mapped Addresses 2016-09-09

标签：Flappy

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Flappy」的文章共 1 篇。

由Flappy Bird想到的技术观、哲学观和人生观 2014-02-13

标签：flow_control

Mon, 01 Jan 0001 00:00:00 +0000

带标签「flow_control」的文章共 1 篇。

蓝牙协议分析(7)_BLE连接有关的技术分析 2016-07-01

标签：flush

Mon, 01 Jan 0001 00:00:00 +0000

带标签「flush」的文章共 1 篇。

TLB flush操作 2016-09-23

标签：Fourier

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Fourier」的文章共 1 篇。

傅立叶级数（Fourier Series）和周期现象 2014-08-07

标签：frame

Mon, 01 Jan 0001 00:00:00 +0000

带标签「frame」的文章共 1 篇。

计算机科学基础知识之（六）：理解栈帧 2015-03-12

标签：framework

Mon, 01 Jan 0001 00:00:00 +0000

带标签「framework」的文章共 18 篇。

Linux reset framework 2017-09-01
Linux DMA Engine framework(3)_dma controller驱动 2017-05-18
Linux DMA Engine framework(1)_概述 2017-03-30
Linux MMC framework(1)_软件架构 2017-01-10
Linux serial framework(1)_概述 2016-12-12
X-017-KERNEL-串口驱动开发之uart driver框架 2016-11-16
Common Clock Framework系统结构 2016-04-21
Linux I2C framework(1)_概述 2016-02-14
Linux时间子系统之（十四）：tick broadcast framework 2015-05-21
Linux Regulator Framework(2)_regulator driver 2015-04-16
Linux Regulator Framework(1)_概述 2015-03-20
Linux cpuidle framework(2)_cpuidle core 2014-12-30
Linux cpuidle framework(1)_概述和软件架构 2014-12-17
Linux common clock framework(3)_实现逻辑分析 2014-11-24
Linux PM domain framework(1)_概述和使用流程 2014-11-13
Linux common clock framework(2)_clock provider 2014-10-23
Linux common clock framework(1)_概述 2014-10-20
Linux电源管理(7)_Wakeup events framework 2014-09-09

标签：freeze

Mon, 01 Jan 0001 00:00:00 +0000

带标签「freeze」的文章共 1 篇。

Linux进程冻结技术 2015-11-24

标签：front

Mon, 01 Jan 0001 00:00:00 +0000

带标签「front」的文章共 1 篇。

显示技术介绍(3)_CRT技术 2016-01-30

标签：ftrace

Mon, 01 Jan 0001 00:00:00 +0000

带标签「ftrace」的文章共 1 篇。

ftrace时间精度issue修复 2018-04-16

标签：futex

Mon, 01 Jan 0001 00:00:00 +0000

带标签「futex」的文章共 1 篇。

futex基础问答 2022-10-09

标签：gap

Mon, 01 Jan 0001 00:00:00 +0000

带标签「gap」的文章共 2 篇。

蓝牙协议分析(3)_蓝牙低功耗(BLE)协议栈介绍 2016-03-12
蓝牙协议分析(2)_协议架构 2016-01-14

标签：gatt

Mon, 01 Jan 0001 00:00:00 +0000

带标签「gatt」的文章共 1 篇。

蓝牙协议分析(3)_蓝牙低功耗(BLE)协议栈介绍 2016-03-12

标签：generic

Mon, 01 Jan 0001 00:00:00 +0000

带标签「generic」的文章共 1 篇。

X-015-KERNEL-ARM generic timer driver的移植 2016-11-02

标签：gerrit

Mon, 01 Jan 0001 00:00:00 +0000

带标签「gerrit」的文章共 1 篇。

X-000-PRE-开发环境搭建 2016-04-23

标签：GIC

Mon, 01 Jan 0001 00:00:00 +0000

带标签「GIC」的文章共 3 篇。

X-020-ROOTFS-initramfs的制作和测试 2016-12-03
linux kernel的中断子系统之（七）：GIC代码分析 2014-09-04
GIC驱动代码分析（废弃） 2014-07-04

标签：git

Mon, 01 Jan 0001 00:00:00 +0000

带标签「git」的文章共 3 篇。

X-022-OTHERS-git操作记录之合并远端分支的更新 2017-01-02
X-001-PRE-git介绍及操作记录 2016-04-26
X-000-PRE-开发环境搭建 2016-04-23

标签：GNU

Mon, 01 Jan 0001 00:00:00 +0000

带标签「GNU」的文章共 1 篇。

Windows系统结合MinGW搭建软件开发环境 2014-01-22

标签：golang

Mon, 01 Jan 0001 00:00:00 +0000

带标签「golang」的文章共 1 篇。

玩转BLE(3)_使用微信蓝牙精简协议伪造记步数据 2017-03-11

标签：governor

Mon, 01 Jan 0001 00:00:00 +0000

带标签「governor」的文章共 3 篇。

schedutil governor情景分析 2022-04-26
linux cpufreq framework(4)_cpufreq governor 2015-08-23
Linux cpuidle framework(4)_menu governor 2015-01-18

标签：GPIO

Mon, 01 Jan 0001 00:00:00 +0000

带标签「GPIO」的文章共 5 篇。

X-026-KERNEL-Linux gpio driver的移植之gpio range 2017-09-27
X-025-KERNEL-Linux gpio driver的移植之基本功能 2017-09-13
linux内核中的GPIO系统之（5）：gpio subsysem和pinctrl subsystem之间的耦合 2017-08-10
linux内核中的GPIO系统之（4）：pinctrl驱动的理解和总结 2017-06-27
linux内核中的GPIO系统之（1）：软件框架 2014-07-21

标签：gpiolib

Mon, 01 Jan 0001 00:00:00 +0000

带标签「gpiolib」的文章共 1 篇。

X-025-KERNEL-Linux gpio driver的移植之基本功能 2017-09-13

标签：GPU

Mon, 01 Jan 0001 00:00:00 +0000

带标签「GPU」的文章共 1 篇。

显示技术介绍(1)_概述 2015-11-22

标签：grep

Mon, 01 Jan 0001 00:00:00 +0000

带标签「grep」的文章共 1 篇。

Linux操作命令记录 2016-04-20

标签：group

Mon, 01 Jan 0001 00:00:00 +0000

带标签「group」的文章共 1 篇。

进程管理和终端驱动：基本概念 2016-10-28

标签：GUI

Mon, 01 Jan 0001 00:00:00 +0000

带标签「GUI」的文章共 1 篇。

Linux graphic subsytem(1)_概述 2015-12-17

标签：handler

Mon, 01 Jan 0001 00:00:00 +0000

带标签「handler」的文章共 1 篇。

Linux kernel的中断子系统之（六）：ARM中断处理过程 2014-08-04

标签：hci

Mon, 01 Jan 0001 00:00:00 +0000

带标签「hci」的文章共 1 篇。

蓝牙协议分析(2)_协议架构 2016-01-14

标签：hcitool

Mon, 01 Jan 0001 00:00:00 +0000

带标签「hcitool」的文章共 1 篇。

玩转BLE(1)_Eddystone beacon 2016-04-29

标签：Hi6220V100

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Hi6220V100」的文章共 1 篇。

基于Hikey的"Boot from USB"调试 2016-12-20

标签：hibernate

Mon, 01 Jan 0001 00:00:00 +0000

带标签「hibernate」的文章共 1 篇。

Linux电源管理(2)_Generic PM之基本概念和软件架构 2014-05-13

标签：hibernation

Mon, 01 Jan 0001 00:00:00 +0000

带标签「hibernation」的文章共 1 篇。

Linux电源管理(12)_Hibernate功能 2014-12-22

标签：Hierarchy

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Hierarchy」的文章共 1 篇。

计算机科学基础知识（一）:The Memory Hierarchy 2014-06-16

标签：hikey

Mon, 01 Jan 0001 00:00:00 +0000

带标签「hikey」的文章共 1 篇。

基于Hikey的"Boot from USB"调试 2016-12-20

标签：hmp

Mon, 01 Jan 0001 00:00:00 +0000

带标签「hmp」的文章共 2 篇。

linux cpufreq framework(5)_ARM big Little driver 2015-11-10
linux cpufreq framework(1)_概述 2015-06-13

标签：hopping

Mon, 01 Jan 0001 00:00:00 +0000

带标签「hopping」的文章共 1 篇。

蓝牙协议分析(7)_BLE连接有关的技术分析 2016-07-01

标签：host

Mon, 01 Jan 0001 00:00:00 +0000

带标签「host」的文章共 1 篇。

Linux MMC framework(2)_host controller driver 2017-03-08

标签：hotplug

Mon, 01 Jan 0001 00:00:00 +0000

带标签「hotplug」的文章共 1 篇。

Linux CPU core的电源管理(5)_cpu control及cpu hotplug 2015-09-19

标签：hw

Mon, 01 Jan 0001 00:00:00 +0000

带标签「hw」的文章共 1 篇。

X-002-HW-S900芯片boot from USB有关的硬件描述 2016-05-12

标签：I2C

Mon, 01 Jan 0001 00:00:00 +0000

带标签「I2C」的文章共 3 篇。

Linux I2C framework(3)_I2C consumer 2016-03-23
Linux I2C framework(2)_I2C provider 2016-02-26
Linux I2C framework(1)_概述 2016-02-14

标签：Image

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Image」的文章共 1 篇。

X-010-UBOOT-使用booti命令启动kernel(Bubblegum-96平台) 2016-08-24

标签：IMOD

Mon, 01 Jan 0001 00:00:00 +0000

带标签「IMOD」的文章共 1 篇。

显示技术介绍(2)_电子显示的前世今生 2015-11-30

标签：init

Mon, 01 Jan 0001 00:00:00 +0000

带标签「init」的文章共 1 篇。

u-boot启动流程分析(2)_板级(board)部分 2016-06-07

标签：initramfs

Mon, 01 Jan 0001 00:00:00 +0000

带标签「initramfs」的文章共 1 篇。

X-020-ROOTFS-initramfs的制作和测试 2016-12-03

标签：inittab

Mon, 01 Jan 0001 00:00:00 +0000

带标签「inittab」的文章共 1 篇。

X-021-ROOTFS-基于busybox的最简rootfs的制作 2016-12-05

标签：iot

Mon, 01 Jan 0001 00:00:00 +0000

带标签「iot」的文章共 1 篇。

玩转BLE(3)_使用微信蓝牙精简协议伪造记步数据 2017-03-11

标签：ipsp

Mon, 01 Jan 0001 00:00:00 +0000

带标签「ipsp」的文章共 1 篇。

蓝牙协议分析(4)_IPv6 Over BLE介绍 2016-04-09

标签：ipss

Mon, 01 Jan 0001 00:00:00 +0000

带标签「ipss」的文章共 1 篇。

蓝牙协议分析(4)_IPv6 Over BLE介绍 2016-04-09

标签：ipv6

Mon, 01 Jan 0001 00:00:00 +0000

带标签「ipv6」的文章共 1 篇。

蓝牙协议分析(4)_IPv6 Over BLE介绍 2016-04-09

标签：irq

Mon, 01 Jan 0001 00:00:00 +0000

带标签「irq」的文章共 4 篇。

系统休眠（System Suspend）和设备中断处理 2017-04-21
X-019-KERNEL-串口驱动开发之数据收发 2016-11-29
linux kernel的中断子系统之（三）：IRQ number和中断描述符 2014-08-26
Linux kernel的中断子系统之（六）：ARM中断处理过程 2014-08-04

标签：irq_domain

Mon, 01 Jan 0001 00:00:00 +0000

带标签「irq_domain」的文章共 1 篇。

Linux kernel的中断子系统之（二）：IRQ Domain介绍 2014-08-19

标签：ISB

Mon, 01 Jan 0001 00:00:00 +0000

带标签「ISB」的文章共 1 篇。

DMB DSB ISB以及SMP CPU 乱序 2014-08-15

标签：itb

Mon, 01 Jan 0001 00:00:00 +0000

带标签「itb」的文章共 2 篇。

X-011-UBOOT-使用bootm命令启动kernel(Bubblegum-96平台) 2016-09-09
u-boot FIT image介绍 2016-09-02

标签：its

Mon, 01 Jan 0001 00:00:00 +0000

带标签「its」的文章共 2 篇。

X-011-UBOOT-使用bootm命令启动kernel(Bubblegum-96平台) 2016-09-09
u-boot FIT image介绍 2016-09-02

标签：KASAN原理

Mon, 01 Jan 0001 00:00:00 +0000

带标签「KASAN原理」的文章共 1 篇。

KASAN实现原理 2018-02-11

标签：kaslr

Mon, 01 Jan 0001 00:00:00 +0000

带标签「kaslr」的文章共 1 篇。

KASLR 2018-05-06

标签：Kernel

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Kernel」的文章共 35 篇。

linux thermal framework(1)_概述 2025-04-14
Linux kernel内存管理的基本概念 2017-11-09
Linux kernel scatterlist API介绍 2017-10-13
Linux reset framework 2017-09-01
X-023-KERNEL-Linux pinctrl driver的移植 2017-07-14
Linux DMA Engine framework(2)_功能介绍及解接口分析 2017-05-02
Linux DMA Engine framework(1)_概述 2017-03-30
Linux MMC framework(2)_host controller driver 2017-03-08
Linux MMC framework(1)_软件架构 2017-01-10
X-017-KERNEL-串口驱动开发之uart driver框架 2016-11-16
X-015-KERNEL-ARM generic timer driver的移植 2016-11-02
Linux kernel debug技巧—-开启DEBUG选项 2016-11-01
X-014-KERNEL-ARM GIC driver的移植 2016-10-31
Linux TTY framework(5)_System console driver 2016-10-29
Linux TTY framework(4)_TTY driver 2016-10-25
X-012-KERNEL-serial early console的移植 2016-10-02
Linux TTY framework(2)_软件架构 2016-09-27
Linux TTY framework(1)_基本概念 2016-09-18
文件缓存回写简述 2016-08-24
X-009-KERNEL-Linux kernel的移植(Bubblegum-96平台) 2016-08-19
Linux kernel内核配置解析(1)_概述(基于ARM64架构) 2016-08-10
总结Linux kernel开发中0的巧妙使用 2015-07-20
Linux PM QoS framework(3)_per-device PM QoS 2015-02-26
Linux PM QoS framework(2)_PM QoS class 2015-02-10
Linux电源管理(13)_Driver的电源管理 2014-12-26
Linux电源管理(12)_Hibernate功能 2014-12-22
新技能get: 订阅Linux内核邮件列表 2014-11-04
Linux电源管理(1)_整体架构 2014-05-07
Linux设备模型(8)_platform设备 2014-04-28
Linux设备模型(7)_Class 2014-04-23
Linux设备模型(6)_Bus 2014-04-15
Linux设备模型(4)_sysfs 2014-03-14
Linux设备模型(3)_Uevent 2014-03-10
Linux设备模型(1)_基本概念 2014-02-27
Linux内核的整体架构 2014-02-21

标签：kms

Mon, 01 Jan 0001 00:00:00 +0000

带标签「kms」的文章共 1 篇。

Linux graphic subsystem(2)_DRI介绍 2015-12-27

标签：kobj

Mon, 01 Jan 0001 00:00:00 +0000

带标签「kobj」的文章共 1 篇。

统一设备模型：kobj、kset分析 2018-01-09

标签：kobject

Mon, 01 Jan 0001 00:00:00 +0000

带标签「kobject」的文章共 2 篇。

kobject在字符设备中的使用 2014-12-04
Linux设备模型(2)_Kobject 2014-03-07

标签：kset

Mon, 01 Jan 0001 00:00:00 +0000

带标签「kset」的文章共 2 篇。

统一设备模型：kobj、kset分析 2018-01-09
Linux设备模型(2)_Kobject 2014-03-07

标签：ktype

Mon, 01 Jan 0001 00:00:00 +0000

带标签「ktype」的文章共 1 篇。

Linux设备模型(2)_Kobject 2014-03-07

标签：l2cap

Mon, 01 Jan 0001 00:00:00 +0000

带标签「l2cap」的文章共 2 篇。

蓝牙协议分析(3)_蓝牙低功耗(BLE)协议栈介绍 2016-03-12
蓝牙协议分析(2)_协议架构 2016-01-14

标签：Laser

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Laser」的文章共 1 篇。

显示技术介绍(2)_电子显示的前世今生 2015-11-30

标签：layout

Mon, 01 Jan 0001 00:00:00 +0000

带标签「layout」的文章共 1 篇。

内存初始化代码分析（二）：内存布局 2016-11-18

标签：LED

Mon, 01 Jan 0001 00:00:00 +0000

带标签「LED」的文章共 2 篇。

通过点亮LED的方法调试嵌入式代码 2016-06-12
显示技术介绍(2)_电子显示的前世今生 2015-11-30

标签：libusb

Mon, 01 Jan 0001 00:00:00 +0000

带标签「libusb」的文章共 1 篇。

X-024-OHTHERS-在windows平台下使用libusb 2017-07-23

标签：link

Mon, 01 Jan 0001 00:00:00 +0000

带标签「link」的文章共 1 篇。

计算机科学基础知识（五）: 动态链接 2015-03-10

标签：Linux

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Linux」的文章共 79 篇。

Linux内核的自旋锁 2019-05-17
tty驱动分析 2018-04-20
Linux kernel内存管理的基本概念 2017-11-09
Linux kernel scatterlist API介绍 2017-10-13
Linux reset framework 2017-09-01
X-023-KERNEL-Linux pinctrl driver的移植 2017-07-14
linux内核中的GPIO系统之（4）：pinctrl驱动的理解和总结 2017-06-27
Linux DMA Engine framework(2)_功能介绍及解接口分析 2017-05-02
Linux DMA Engine framework(1)_概述 2017-03-30
Linux MMC framework(2)_host controller driver 2017-03-08
Linux MMC framework(1)_软件架构 2017-01-10
Linux serial framework(1)_概述 2016-12-12
X-019-KERNEL-串口驱动开发之数据收发 2016-11-29
X-018-KERNEL-串口驱动开发之serial console 2016-11-18
X-017-KERNEL-串口驱动开发之uart driver框架 2016-11-16
X-015-KERNEL-ARM generic timer driver的移植 2016-11-02
Linux kernel debug技巧—-开启DEBUG选项 2016-11-01
X-014-KERNEL-ARM GIC driver的移植 2016-10-31
Linux TTY framework(5)_System console driver 2016-10-29
Linux TTY framework(4)_TTY driver 2016-10-25
Linux TTY framework(3)_从应用的角度看TTY设备 2016-10-14
X-012-KERNEL-serial early console的移植 2016-10-02
Linux TTY framework(2)_软件架构 2016-09-27
Linux TTY framework(1)_基本概念 2016-09-18
Linux kernel内核配置解析(5)_Boot options(基于ARM64架构) 2016-08-12
Linux kernel内核配置解析(1)_概述(基于ARM64架构) 2016-08-10
Linux I2C framework(3)_I2C consumer 2016-03-23
Linux I2C framework(2)_I2C provider 2016-02-26
Linux I2C framework(1)_概述 2016-02-14
Linux graphic subsytem(1)_概述 2015-12-17
Linux进程冻结技术 2015-11-24
linux cpufreq framework(5)_ARM big Little driver 2015-11-10
Linux 3.18U盘无法正确使用 2015-10-28
Linux PWM framework(1)_简介和API描述 2015-10-11
Linux CPU core的电源管理(5)_cpu control及cpu hotplug 2015-09-19
linux cpufreq framework(4)_cpufreq governor 2015-08-23
linux cpufreq framework(3)_cpufreq core 2015-07-30
Linux CPU core的电源管理(3)_cpu ops 2015-07-17
Linux cpufreq framework(2)_cpufreq driver 2015-06-19
linux cpufreq framework(1)_概述 2015-06-13
Linux电源管理(15)_PM OPP Interface 2015-06-04
Linux CPU core的电源管理(1)_概述 2015-04-30
Linux Regulator Framework(2)_regulator driver 2015-04-16
linux 串口调试方法 2015-04-08
Linux Regulator Framework(1)_概述 2015-03-20
Linux power supply class(1)_软件架构及API汇整 2015-03-13
Linux PM QoS framework(3)_per-device PM QoS 2015-02-26
Linux PM QoS framework(2)_PM QoS class 2015-02-10
Linux PM QoS framework(1)_概述和软件架构 2015-02-04
Linux cpuidle framework(4)_menu governor 2015-01-18
Linux cpuidle framework(2)_cpuidle core 2014-12-30
Linux cpuidle framework(1)_概述和软件架构 2014-12-17
Linux common clock framework(3)_实现逻辑分析 2014-11-24
Linux PM domain framework(1)_概述和使用流程 2014-11-13
新技能get: 订阅Linux内核邮件列表 2014-11-04
Linux common clock framework(2)_clock provider 2014-10-23
arm64 linux移植 2014-10-23
Linux common clock framework(1)_概述 2014-10-20
Linux电源管理(11)_Runtime PM之功能描述 2014-10-08
Linux设备模型(9)_device resource management 2014-09-24
Linux电源管理(10)_autosleep 2014-09-18
Linux电源管理(9)_wakelocks 2014-09-14
Linux电源管理(8)_Wakeup count功能 2014-09-12
Linux电源管理(7)_Wakeup events framework 2014-09-09
Linux电源管理(6)_Generic PM之Suspend功能 2014-08-22
Linux电源管理(5)_Hibernate和Sleep功能介绍 2014-06-10
Linux电源管理(4)_Power Management Interface 2014-05-29
Linux电源管理(3)_Generic PM之Reboot过程 2014-05-19
Linux电源管理(2)_Generic PM之基本概念和软件架构 2014-05-13
Linux设备模型(8)_platform设备 2014-04-28
Linux设备模型(7)_Class 2014-04-23
Linux设备模型(6)_Bus 2014-04-15
Linux设备模型(5)_device和device driver 2014-04-02
Linux设备模型(4)_sysfs 2014-03-14
Linux设备模型(3)_Uevent 2014-03-10
Linux设备模型(2)_Kobject 2014-03-07
Linux内核的整体架构 2014-02-21
MinGW下安装man工具包 2014-01-24
Windows系统结合MinGW搭建软件开发环境 2014-01-22

标签：Linux内核

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Linux内核」的文章共 1 篇。

《奔跑吧，Linux内核》已经上架预售了 2017-08-05

标签：linux摄像头

Mon, 01 Jan 0001 00:00:00 +0000

带标签「linux摄像头」的文章共 1 篇。

linux usb 摄像头测试 2015-04-12

标签：Linux时间子系统

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Linux时间子系统」的文章共 2 篇。

Linux时间子系统之（四）：timekeeping 2014-12-29
Linux时间子系统系列文章之目录 2014-12-23

标签：Linux时间子系统用户空间接口函数

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Linux时间子系统用户空间接口函数」的文章共 1 篇。

Linux时间子系统之（三）：用户空间接口函数 2014-12-24

标签：list

Mon, 01 Jan 0001 00:00:00 +0000

带标签「list」的文章共 1 篇。

新技能get: 订阅Linux内核邮件列表 2014-11-04

标签：little

Mon, 01 Jan 0001 00:00:00 +0000

带标签「little」的文章共 1 篇。

linux cpufreq framework(5)_ARM big Little driver 2015-11-10

标签：LKML

Mon, 01 Jan 0001 00:00:00 +0000

带标签「LKML」的文章共 1 篇。

新技能get: 订阅Linux内核邮件列表 2014-11-04

标签：load

Mon, 01 Jan 0001 00:00:00 +0000

带标签「load」的文章共 2 篇。

CFS任务的负载均衡（load balance） 2021-11-22
per-entity load tracking 2018-08-18

标签：load_balance

Mon, 01 Jan 0001 00:00:00 +0000

带标签「load_balance」的文章共 1 篇。

load_balance函数代码详解 2022-02-16

标签：lock

Mon, 01 Jan 0001 00:00:00 +0000

带标签「lock」的文章共 2 篇。

Linux中常见同步机制设计原理 2018-06-09
Linux内核同步机制之（四）：spin lock 2015-04-22

标签：LQI

Mon, 01 Jan 0001 00:00:00 +0000

带标签「LQI」的文章共 1 篇。

蓝牙协议中LQ和RSSI的原理及应用场景 2014-03-12

标签：luvcview

Mon, 01 Jan 0001 00:00:00 +0000

带标签「luvcview」的文章共 1 篇。

linux usb 摄像头测试 2015-04-12

标签：mailing

Mon, 01 Jan 0001 00:00:00 +0000

带标签「mailing」的文章共 1 篇。

新技能get: 订阅Linux内核邮件列表 2014-11-04

标签：man

Mon, 01 Jan 0001 00:00:00 +0000

带标签「man」的文章共 1 篇。

MinGW下安装man工具包 2014-01-24

标签：Managed

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Managed」的文章共 1 篇。

Concurrency Managed Workqueue之（四）：workqueue如何处理work 2015-08-17

标签：management

Mon, 01 Jan 0001 00:00:00 +0000

带标签「management」的文章共 5 篇。

标签：Mapping

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Mapping」的文章共 2 篇。

逆向映射的演进 2017-11-17
Dynamic DMA mapping Guide 2017-07-20

标签：Meltdown

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Meltdown」的文章共 1 篇。

Meltdown论文翻译 2018-01-19

标签：meminfo

Mon, 01 Jan 0001 00:00:00 +0000

带标签「meminfo」的文章共 1 篇。

/proc/meminfo分析（一） 2017-08-17

标签：Memory

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Memory」的文章共 8 篇。

CMA模块学习笔记 2017-06-28
内存初始化代码分析（二）：内存布局 2016-11-18
Linux内存模型 2016-08-31
perfbook memory barrier（14.2章节）中文翻译（下） 2016-01-11
Why Memory Barriers中文翻译（下） 2016-01-05
Why Memory Barriers？中文翻译（上） 2015-12-10
Linux内核同步机制之（三）：memory barrier 2014-11-14
计算机科学基础知识（一）:The Memory Hierarchy 2014-06-16

标签：menu

Mon, 01 Jan 0001 00:00:00 +0000

带标签「menu」的文章共 1 篇。

Linux cpuidle framework(4)_menu governor 2015-01-18

标签：menuconfig

Mon, 01 Jan 0001 00:00:00 +0000

带标签「menuconfig」的文章共 2 篇。

Linux kernel内核配置解析(5)_Boot options(基于ARM64架构) 2016-08-12
Linux kernel内核配置解析(1)_概述(基于ARM64架构) 2016-08-10

标签：merge

Mon, 01 Jan 0001 00:00:00 +0000

带标签「merge」的文章共 1 篇。

X-022-OTHERS-git操作记录之合并远端分支的更新 2017-01-02

标签：MinGW

Mon, 01 Jan 0001 00:00:00 +0000

带标签「MinGW」的文章共 3 篇。

X-024-OHTHERS-在windows平台下使用libusb 2017-07-23
MinGW下安装man工具包 2014-01-24
Windows系统结合MinGW搭建软件开发环境 2014-01-22

标签：mm

Mon, 01 Jan 0001 00:00:00 +0000

带标签「mm」的文章共 1 篇。

Linux kernel内存管理的基本概念 2017-11-09

标签：mmc

Mon, 01 Jan 0001 00:00:00 +0000

带标签「mmc」的文章共 3 篇。

Linux MMC framework(2)_host controller driver 2017-03-08
Linux MMC framework(1)_软件架构 2017-01-10
MMC/SD/SDIO介绍 2016-12-25

标签：MMU

Mon, 01 Jan 0001 00:00:00 +0000

带标签「MMU」的文章共 2 篇。

作業系統之前的程式 for rpi2 (1) - mmu (0) : 位址轉換 2015-10-27
ARM64的启动过程之（三）：为打开MMU而进行的CPU初始化 2015-10-21

标签：Model

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Model」的文章共 3 篇。

标签：Multi-copy

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Multi-copy」的文章共 1 篇。

ARMv8之Atomicity 2016-05-13

标签：mutex

Mon, 01 Jan 0001 00:00:00 +0000

带标签「mutex」的文章共 2 篇。

Linux内核同步机制之（八）：mutex 2022-05-10
Linux中常见同步机制设计原理 2018-06-09

标签：NO_HZ

Mon, 01 Jan 0001 00:00:00 +0000

带标签「NO_HZ」的文章共 1 篇。

Linux时间子系统之（十三）：Tick Device layer综述 2015-03-26

标签：NUMA

Mon, 01 Jan 0001 00:00:00 +0000

带标签「NUMA」的文章共 1 篇。

Linux CPU core的电源管理(2)_cpu topology 2015-05-30

标签：O(1)

Mon, 01 Jan 0001 00:00:00 +0000

带标签「O(1)」的文章共 1 篇。

O(n)、O(1)和CFS调度器 2018-01-08

标签：O(n)

Mon, 01 Jan 0001 00:00:00 +0000

带标签「O(n)」的文章共 1 篇。

O(n)、O(1)和CFS调度器 2018-01-08

标签：Object

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Object」的文章共 1 篇。

计算机科学基础知识（二）:Relocatable Object File 2015-02-09

标签：observed

Mon, 01 Jan 0001 00:00:00 +0000

带标签「observed」的文章共 1 篇。

ARMv8之Observability 2016-05-25

标签：observer

Mon, 01 Jan 0001 00:00:00 +0000

带标签「observer」的文章共 1 篇。

ARMv8之Observability 2016-05-25

标签：OLED

Mon, 01 Jan 0001 00:00:00 +0000

带标签「OLED」的文章共 1 篇。

显示技术介绍(2)_电子显示的前世今生 2015-11-30

标签：oom

Mon, 01 Jan 0001 00:00:00 +0000

带标签「oom」的文章共 1 篇。

Linux vm运行参数之（二）：OOM相关的参数 2015-09-28

标签：operations

Mon, 01 Jan 0001 00:00:00 +0000

带标签「operations」的文章共 1 篇。

Linux CPU core的电源管理(3)_cpu ops 2015-07-17

标签：opp

Mon, 01 Jan 0001 00:00:00 +0000

带标签「opp」的文章共 1 篇。

Linux电源管理(15)_PM OPP Interface 2015-06-04

标签：origin

Mon, 01 Jan 0001 00:00:00 +0000

带标签「origin」的文章共 1 篇。

X-001-PRE-git介绍及操作记录 2016-04-26

标签：overcommit

Mon, 01 Jan 0001 00:00:00 +0000

带标签「overcommit」的文章共 1 篇。

Linux vm运行参数之（一）：overcommit相关的参数 2015-09-23

标签：pairing

Mon, 01 Jan 0001 00:00:00 +0000

带标签「pairing」的文章共 1 篇。

蓝牙协议分析(11)_BLE安全机制之SM 2017-09-07

标签：panic

Mon, 01 Jan 0001 00:00:00 +0000

带标签「panic」的文章共 1 篇。

总结Linux kernel开发中0的巧妙使用 2015-07-20

标签：pd

Mon, 01 Jan 0001 00:00:00 +0000

带标签「pd」的文章共 1 篇。

USB-C(USB Type-C)规范的简单介绍和分析 2017-12-18

标签：PELT

Mon, 01 Jan 0001 00:00:00 +0000

带标签「PELT」的文章共 3 篇。

PELT算法浅析 2022-04-07
CFS调度器（4）-PELT(per entity load tracking) 2018-12-02
per-entity load tracking 2018-08-18

标签：Per-CPU变量

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Per-CPU变量」的文章共 1 篇。

Linux内核同步机制之（二）：Per-CPU变量 2014-10-16

标签：per-device

Mon, 01 Jan 0001 00:00:00 +0000

带标签「per-device」的文章共 1 篇。

Linux PM QoS framework(3)_per-device PM QoS 2015-02-26

标签：per-entity

Mon, 01 Jan 0001 00:00:00 +0000

带标签「per-entity」的文章共 1 篇。

per-entity load tracking 2018-08-18

标签：perfbook

Mon, 01 Jan 0001 00:00:00 +0000

带标签「perfbook」的文章共 3 篇。

Perf book 9.3章节翻译（下） 2016-02-26
Perf book 9.3章节翻译（上） 2016-02-18
perfbook memory barrier（14.2章节）中文翻译（下） 2016-01-11

标签：periodic

Mon, 01 Jan 0001 00:00:00 +0000

带标签「periodic」的文章共 1 篇。

Linux时间子系统之（十二）：periodic tick 2014-12-11

标签：PIC

Mon, 01 Jan 0001 00:00:00 +0000

带标签「PIC」的文章共 1 篇。

计算机科学基础知识（四）: 动态库和位置无关代码 2015-03-06

标签：pin

Mon, 01 Jan 0001 00:00:00 +0000

带标签「pin」的文章共 2 篇。

linux内核中的GPIO系统之（2）：pin control subsystem 2014-07-26
Linux内核中的GPIO系统之（3）：pin controller driver代码分析 2014-07-22

标签：pinctrl

Mon, 01 Jan 0001 00:00:00 +0000

带标签「pinctrl」的文章共 5 篇。

X-026-KERNEL-Linux gpio driver的移植之gpio range 2017-09-27
linux内核中的GPIO系统之（5）：gpio subsysem和pinctrl subsystem之间的耦合 2017-08-10
X-023-KERNEL-Linux pinctrl driver的移植 2017-07-14
linux内核中的GPIO系统之（4）：pinctrl驱动的理解和总结 2017-06-27
X-006-UBOOT-pinctrl driver移植(Bubblegum-96平台) 2016-07-09

标签：placement

Mon, 01 Jan 0001 00:00:00 +0000

带标签「placement」的文章共 1 篇。

CFS任务放置代码详解 2021-12-31

标签：plan9

Mon, 01 Jan 0001 00:00:00 +0000

带标签「plan9」的文章共 1 篇。

智慧家庭之我见_多媒体篇 2014-07-09

标签：platform_driver

Mon, 01 Jan 0001 00:00:00 +0000

带标签「platform_driver」的文章共 1 篇。

X-016-KERNEL-串口驱动开发之驱动框架 2016-11-10

标签：platform设备

Mon, 01 Jan 0001 00:00:00 +0000

带标签「platform设备」的文章共 1 篇。

Linux设备模型(8)_platform设备 2014-04-28

标签：PM

Mon, 01 Jan 0001 00:00:00 +0000

带标签「PM」的文章共 12 篇。

Linux电源管理(15)_PM OPP Interface 2015-06-04
Linux CPU core的电源管理(1)_概述 2015-04-30
Linux电源管理(14)_从设备驱动的角度看电源管理 2015-03-02
Linux PM QoS framework(1)_概述和软件架构 2015-02-04
Linux PM domain framework(1)_概述和使用流程 2014-11-13
Linux电源管理(11)_Runtime PM之功能描述 2014-10-08
Linux电源管理(10)_autosleep 2014-09-18
Linux电源管理(5)_Hibernate和Sleep功能介绍 2014-06-10
Linux电源管理(4)_Power Management Interface 2014-05-29
Linux电源管理(3)_Generic PM之Reboot过程 2014-05-19
Linux电源管理(2)_Generic PM之基本概念和软件架构 2014-05-13
Linux电源管理(1)_整体架构 2014-05-07

标签：pm_qos

Mon, 01 Jan 0001 00:00:00 +0000

带标签「pm_qos」的文章共 4 篇。

Linux PM QoS framework(3)_per-device PM QoS 2015-02-26
Linux PM QoS framework(2)_PM QoS class 2015-02-10
Linux PM QoS framework(1)_概述和软件架构 2015-02-04
Linux cpuidle framework(4)_menu governor 2015-01-18

标签：porch

Mon, 01 Jan 0001 00:00:00 +0000

带标签「porch」的文章共 1 篇。

显示技术介绍(3)_CRT技术 2016-01-30

标签：porting

Mon, 01 Jan 0001 00:00:00 +0000

带标签「porting」的文章共 10 篇。

X-026-KERNEL-Linux gpio driver的移植之gpio range 2017-09-27
X-025-KERNEL-Linux gpio driver的移植之基本功能 2017-09-13
X-023-KERNEL-Linux pinctrl driver的移植 2017-07-14
X-015-KERNEL-ARM generic timer driver的移植 2016-11-02
X-014-KERNEL-ARM GIC driver的移植 2016-10-31
X-009-KERNEL-Linux kernel的移植(Bubblegum-96平台) 2016-08-19
X-006-UBOOT-pinctrl driver移植(Bubblegum-96平台) 2016-07-09
X-005-UBOOT-device tree移植(Bubblegum-96平台) 2016-06-29
X-004-UBOOT-串口驱动移植(Bubblegum-96平台) 2016-06-18
X-003-UBOOT-基于Bubblegum-96平台的u-boot移植说明 2016-05-29

标签：POSIX

Mon, 01 Jan 0001 00:00:00 +0000

带标签「POSIX」的文章共 1 篇。

Linux时间子系统之（六）：POSIX timer 2015-01-22

标签：posix-clock

Mon, 01 Jan 0001 00:00:00 +0000

带标签「posix-clock」的文章共 1 篇。

Linux时间子系统之（五）：POSIX Clock 2015-01-05

标签：Power

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Power」的文章共 3 篇。

USB-C(USB Type-C)规范的简单介绍和分析 2017-12-18
Linux电源管理(15)_PM OPP Interface 2015-06-04
Linux电源管理(1)_整体架构 2014-05-07

标签：power_off

Mon, 01 Jan 0001 00:00:00 +0000

带标签「power_off」的文章共 1 篇。

Linux电源管理(3)_Generic PM之Reboot过程 2014-05-19

标签：powershell

Mon, 01 Jan 0001 00:00:00 +0000

带标签「powershell」的文章共 1 篇。

在PowerShell中使用Vim 2014-06-18

标签：pr_debug

Mon, 01 Jan 0001 00:00:00 +0000

带标签「pr_debug」的文章共 1 篇。

Linux kernel debug技巧—-开启DEBUG选项 2016-11-01

标签：printf

Mon, 01 Jan 0001 00:00:00 +0000

带标签「printf」的文章共 1 篇。

小printf大作用（用日志打印的方式调试程序） 2014-01-23

标签：printk

Mon, 01 Jan 0001 00:00:00 +0000

带标签「printk」的文章共 2 篇。

Linux kernel debug技巧—-开启DEBUG选项 2016-11-01
X-012-KERNEL-serial early console的移植 2016-10-02

标签：privacy

Mon, 01 Jan 0001 00:00:00 +0000

带标签「privacy」的文章共 1 篇。

蓝牙协议分析(9)_BLE安全机制之LL Privacy 2016-11-25

标签：private

Mon, 01 Jan 0001 00:00:00 +0000

带标签「private」的文章共 1 篇。

蓝牙协议分析(6)_BLE地址类型 2016-06-07

标签：process

Mon, 01 Jan 0001 00:00:00 +0000

带标签「process」的文章共 5 篇。

标签：profile

Mon, 01 Jan 0001 00:00:00 +0000

带标签「profile」的文章共 1 篇。

蓝牙协议分析(2)_协议架构 2016-01-14

标签：project

Mon, 01 Jan 0001 00:00:00 +0000

带标签「project」的文章共 3 篇。

X-009-KERNEL-Linux kernel的移植(Bubblegum-96平台) 2016-08-19
X-004-UBOOT-串口驱动移植(Bubblegum-96平台) 2016-06-18
X-000-PRE-开发环境搭建 2016-04-23

标签：provider

Mon, 01 Jan 0001 00:00:00 +0000

带标签「provider」的文章共 1 篇。

Linux common clock framework(2)_clock provider 2014-10-23

标签：psci

Mon, 01 Jan 0001 00:00:00 +0000

带标签「psci」的文章共 1 篇。

Linux CPU core的电源管理(3)_cpu ops 2015-07-17

标签：psy

Mon, 01 Jan 0001 00:00:00 +0000

带标签「psy」的文章共 1 篇。

Linux power supply class(1)_软件架构及API汇整 2015-03-13

标签：pty

Mon, 01 Jan 0001 00:00:00 +0000

带标签「pty」的文章共 1 篇。

Linux TTY framework(3)_从应用的角度看TTY设备 2016-10-14

标签：public

Mon, 01 Jan 0001 00:00:00 +0000

带标签「public」的文章共 1 篇。

蓝牙协议分析(6)_BLE地址类型 2016-06-07

标签：push

Mon, 01 Jan 0001 00:00:00 +0000

带标签「push」的文章共 1 篇。

X-001-PRE-git介绍及操作记录 2016-04-26

标签：pwm

Mon, 01 Jan 0001 00:00:00 +0000

带标签「pwm」的文章共 1 篇。

Linux PWM framework(1)_简介和API描述 2015-10-11

标签：pxe

Mon, 01 Jan 0001 00:00:00 +0000

带标签「pxe」的文章共 1 篇。

使用pxe方式安装系统 2016-04-23

标签：qemu

Mon, 01 Jan 0001 00:00:00 +0000

带标签「qemu」的文章共 1 篇。

Linux操作命令记录 2016-04-20

标签：qos

Mon, 01 Jan 0001 00:00:00 +0000

带标签「qos」的文章共 2 篇。

Linux PM QoS framework(2)_PM QoS class 2015-02-10
Linux PM QoS framework(1)_概述和软件架构 2015-02-04

标签：queued

Mon, 01 Jan 0001 00:00:00 +0000

带标签「queued」的文章共 1 篇。

Linux内核同步机制之（九）：Queued spinlock 2022-06-29

标签：randisk

Mon, 01 Jan 0001 00:00:00 +0000

带标签「randisk」的文章共 1 篇。

X-020-ROOTFS-initramfs的制作和测试 2016-12-03

标签：random

Mon, 01 Jan 0001 00:00:00 +0000

带标签「random」的文章共 1 篇。

蓝牙协议分析(6)_BLE地址类型 2016-06-07

标签：range

Mon, 01 Jan 0001 00:00:00 +0000

带标签「range」的文章共 2 篇。

标签：rate

Mon, 01 Jan 0001 00:00:00 +0000

带标签「rate」的文章共 1 篇。

串口通信技术浅析 2016-06-24

标签：rcS

Mon, 01 Jan 0001 00:00:00 +0000

带标签「rcS」的文章共 1 篇。

X-021-ROOTFS-基于busybox的最简rootfs的制作 2016-12-05

标签：RCU

Mon, 01 Jan 0001 00:00:00 +0000

带标签「RCU」的文章共 5 篇。

标签：Read-Copy-Update

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Read-Copy-Update」的文章共 1 篇。

Linux2.6.11版本：classic RCU的实现 2016-01-27

标签：reboot

Mon, 01 Jan 0001 00:00:00 +0000

带标签「reboot」的文章共 1 篇。

Linux电源管理(3)_Generic PM之Reboot过程 2014-05-19

标签：regulator

Mon, 01 Jan 0001 00:00:00 +0000

带标签「regulator」的文章共 2 篇。

Linux Regulator Framework(2)_regulator driver 2015-04-16
Linux Regulator Framework(1)_概述 2015-03-20

标签：relaxed

Mon, 01 Jan 0001 00:00:00 +0000

带标签「relaxed」的文章共 1 篇。

ARMv8之memory model 2016-05-18

标签：Relocatable

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Relocatable」的文章共 1 篇。

计算机科学基础知识（二）:Relocatable Object File 2015-02-09

标签：relocate

Mon, 01 Jan 0001 00:00:00 +0000

带标签「relocate」的文章共 1 篇。

u-boot启动流程分析(2)_板级(board)部分 2016-06-07

标签：relocation

Mon, 01 Jan 0001 00:00:00 +0000

带标签「relocation」的文章共 1 篇。

u-boot启动流程分析(2)_板级(board)部分 2016-06-07

标签：remote

Mon, 01 Jan 0001 00:00:00 +0000

带标签「remote」的文章共 2 篇。

X-022-OTHERS-git操作记录之合并远端分支的更新 2017-01-02
X-001-PRE-git介绍及操作记录 2016-04-26

标签：rendering

Mon, 01 Jan 0001 00:00:00 +0000

带标签「rendering」的文章共 1 篇。

Linux graphic subsystem(2)_DRI介绍 2015-12-27

标签：request_threaded_irq

Mon, 01 Jan 0001 00:00:00 +0000

带标签「request_threaded_irq」的文章共 1 篇。

Linux kernel中断子系统之（五）：驱动申请中断API 2014-09-22

标签：reset

Mon, 01 Jan 0001 00:00:00 +0000

带标签「reset」的文章共 1 篇。

Linux reset framework 2017-09-01

标签：resolvable

Mon, 01 Jan 0001 00:00:00 +0000

带标签「resolvable」的文章共 2 篇。

蓝牙协议分析(9)_BLE安全机制之LL Privacy 2016-11-25
蓝牙协议分析(6)_BLE地址类型 2016-06-07

标签：resume

Mon, 01 Jan 0001 00:00:00 +0000

带标签「resume」的文章共 1 篇。

Linux电源管理(6)_Generic PM之Suspend功能 2014-08-22

标签：reverse

Mon, 01 Jan 0001 00:00:00 +0000

带标签「reverse」的文章共 1 篇。

逆向映射的演进 2017-11-17

标签：rootfs

Mon, 01 Jan 0001 00:00:00 +0000

带标签「rootfs」的文章共 2 篇。

X-021-ROOTFS-基于busybox的最简rootfs的制作 2016-12-05
X-020-ROOTFS-initramfs的制作和测试 2016-12-03

标签：rpm

Mon, 01 Jan 0001 00:00:00 +0000

带标签「rpm」的文章共 1 篇。

Linux电源管理(11)_Runtime PM之功能描述 2014-10-08

标签：rpmbuild

Mon, 01 Jan 0001 00:00:00 +0000

带标签「rpmbuild」的文章共 1 篇。

Linux操作命令记录 2016-04-20

标签：RSSI

Mon, 01 Jan 0001 00:00:00 +0000

带标签「RSSI」的文章共 1 篇。

蓝牙协议中LQ和RSSI的原理及应用场景 2014-03-12

标签：runtime

Mon, 01 Jan 0001 00:00:00 +0000

带标签「runtime」的文章共 1 篇。

Linux电源管理(11)_Runtime PM之功能描述 2014-10-08

标签：rw

Mon, 01 Jan 0001 00:00:00 +0000

带标签「rw」的文章共 1 篇。

Linux内核同步机制之（五）：Read/Write spin lock 2015-05-22

标签：rw_lock

Mon, 01 Jan 0001 00:00:00 +0000

带标签「rw_lock」的文章共 1 篇。

Linux中常见同步机制设计原理 2018-06-09

标签：rwsem

Mon, 01 Jan 0001 00:00:00 +0000

带标签「rwsem」的文章共 1 篇。

Linux读写锁逻辑解析 2023-05-29

标签：rx

Mon, 01 Jan 0001 00:00:00 +0000

带标签「rx」的文章共 1 篇。

X-019-KERNEL-串口驱动开发之数据收发 2016-11-29

标签：s900

Mon, 01 Jan 0001 00:00:00 +0000

带标签「s900」的文章共 1 篇。

X-002-HW-S900芯片boot from USB有关的硬件描述 2016-05-12

标签：scan

Mon, 01 Jan 0001 00:00:00 +0000

带标签「scan」的文章共 3 篇。

标签：scatterlist

Mon, 01 Jan 0001 00:00:00 +0000

带标签「scatterlist」的文章共 1 篇。

Linux kernel scatterlist API介绍 2017-10-13

标签：sched_clock

Mon, 01 Jan 0001 00:00:00 +0000

带标签「sched_clock」的文章共 1 篇。

ftrace时间精度issue修复 2018-04-16

标签：schedule

Mon, 01 Jan 0001 00:00:00 +0000

带标签「schedule」的文章共 1 篇。

进程切换分析（3）：同步处理 2017-12-11

标签：scheduler

Mon, 01 Jan 0001 00:00:00 +0000

带标签「scheduler」的文章共 2 篇。

Deadline调度器之（二）：细节和使用方法 2018-02-22
O(n)、O(1)和CFS调度器 2018-01-08

标签：schedutil

Mon, 01 Jan 0001 00:00:00 +0000

带标签「schedutil」的文章共 1 篇。

schedutil governor情景分析 2022-04-26

标签：sd

Mon, 01 Jan 0001 00:00:00 +0000

带标签「sd」的文章共 1 篇。

MMC/SD/SDIO介绍 2016-12-25

标签：sdio

Mon, 01 Jan 0001 00:00:00 +0000

带标签「sdio」的文章共 1 篇。

MMC/SD/SDIO介绍 2016-12-25

标签：SDRAM

Mon, 01 Jan 0001 00:00:00 +0000

带标签「SDRAM」的文章共 7 篇。

DRAM 原理 5 ：DRAM Devices Organization 2016-10-15
DRAM 原理 4 ：DRAM Timing 2016-08-29
DRAM 原理 3 ：DRAM Device 2016-07-27
X-007-UBOOT-DDR的初始化(Bubblegum-96平台) 2016-07-21
DRAM 原理 2 ：DRAM Memory Organization 2016-06-14
DRAM 原理 1 ：DRAM Storage Cell 2016-06-08
SDRAM Internals 2014-05-14

标签：security

Mon, 01 Jan 0001 00:00:00 +0000

带标签「security」的文章共 1 篇。

蓝牙协议分析(11)_BLE安全机制之SM 2017-09-07

标签：Seqlock

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Seqlock」的文章共 1 篇。

Linux内核同步机制之（六）：Seqlock 2015-09-09

标签：sequential

Mon, 01 Jan 0001 00:00:00 +0000

带标签「sequential」的文章共 1 篇。

ARMv8之memory model 2016-05-18

标签：serial

Mon, 01 Jan 0001 00:00:00 +0000

带标签「serial」的文章共 7 篇。

Linux serial framework(1)_概述 2016-12-12
X-019-KERNEL-串口驱动开发之数据收发 2016-11-29
X-018-KERNEL-串口驱动开发之serial console 2016-11-18
X-017-KERNEL-串口驱动开发之uart driver框架 2016-11-16
X-016-KERNEL-串口驱动开发之驱动框架 2016-11-10
串口通信技术浅析 2016-06-24
X-004-UBOOT-串口驱动移植(Bubblegum-96平台) 2016-06-18

标签：Series

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Series」的文章共 1 篇。

傅立叶级数（Fourier Series）和周期现象 2014-08-07

标签：session

Mon, 01 Jan 0001 00:00:00 +0000

带标签「session」的文章共 1 篇。

进程管理和终端驱动：基本概念 2016-10-28

标签：sg_table

Mon, 01 Jan 0001 00:00:00 +0000

带标签「sg_table」的文章共 1 篇。

Linux kernel scatterlist API介绍 2017-10-13

标签：Single-copy

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Single-copy」的文章共 1 篇。

ARMv8之Atomicity 2016-05-13

标签：slab

Mon, 01 Jan 0001 00:00:00 +0000

带标签「slab」的文章共 1 篇。

slub分配器 2015-12-21

标签：slave

Mon, 01 Jan 0001 00:00:00 +0000

带标签「slave」的文章共 1 篇。

Linux I2C framework(3)_I2C consumer 2016-03-23

标签：sleep

Mon, 01 Jan 0001 00:00:00 +0000

带标签「sleep」的文章共 2 篇。

irq wakeup in linux 2021-11-15
Linux电源管理(2)_Generic PM之基本概念和软件架构 2014-05-13

标签：slub

Mon, 01 Jan 0001 00:00:00 +0000

带标签「slub」的文章共 3 篇。

SLUB DEBUG原理 2018-02-22
图解slub 2018-02-22
slub分配器 2015-12-21

标签：Smartisan

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Smartisan」的文章共 1 篇。

一个技术男眼中的Smartisan T1手机 2014-11-24

标签：SMP

Mon, 01 Jan 0001 00:00:00 +0000

带标签「SMP」的文章共 4 篇。

蓝牙协议分析(11)_BLE安全机制之SM 2017-09-07
Linux CPU core的电源管理(3)_cpu ops 2015-07-17
Linux CPU core的电源管理(2)_cpu topology 2015-05-30
DMB DSB ISB以及SMP CPU 乱序 2014-08-15

标签：smpboot

Mon, 01 Jan 0001 00:00:00 +0000

带标签「smpboot」的文章共 1 篇。

Linux CPU core的电源管理(5)_cpu control及cpu hotplug 2015-09-19

标签：SMT

Mon, 01 Jan 0001 00:00:00 +0000

带标签「SMT」的文章共 1 篇。

Linux CPU core的电源管理(2)_cpu topology 2015-05-30

标签：soc

Mon, 01 Jan 0001 00:00:00 +0000

带标签「soc」的文章共 1 篇。

ARM概念梳理：Architecture, Core, CPU，SOC 2014-12-09

标签：softirq

Mon, 01 Jan 0001 00:00:00 +0000

带标签「softirq」的文章共 1 篇。

linux kernel的中断子系统之（八）：softirq 2014-10-24

标签：spin

Mon, 01 Jan 0001 00:00:00 +0000

带标签「spin」的文章共 2 篇。

Linux中常见同步机制设计原理 2018-06-09
Linux内核同步机制之（四）：spin lock 2015-04-22

标签：spin_lock

Mon, 01 Jan 0001 00:00:00 +0000

带标签「spin_lock」的文章共 1 篇。

关于spin_lock的问题 2014-12-12

标签：spin_lock使用

Mon, 01 Jan 0001 00:00:00 +0000

带标签「spin_lock使用」的文章共 1 篇。

spin_lock最简单用法。 2015-04-17

标签：spin_table

Mon, 01 Jan 0001 00:00:00 +0000

带标签「spin_table」的文章共 1 篇。

Linux CPU core的电源管理(3)_cpu ops 2015-07-17

标签：spinlock

Mon, 01 Jan 0001 00:00:00 +0000

带标签「spinlock」的文章共 3 篇。

Linux内核同步机制之（九）：Queued spinlock 2022-06-29
實作 spinlock on raspberry pi 2 2015-11-05
Linux内核同步机制之（五）：Read/Write spin lock 2015-05-22

标签：spl

Mon, 01 Jan 0001 00:00:00 +0000

带标签「spl」的文章共 3 篇。

基于Hikey的"Boot from USB"调试 2016-12-20
X-007-UBOOT-DDR的初始化(Bubblegum-96平台) 2016-07-21
u-boot启动流程分析(1)_平台相关部分 2016-05-19

标签：SRCU

Mon, 01 Jan 0001 00:00:00 +0000

带标签「SRCU」的文章共 1 篇。

Linux2.6.23 ：sleepable RCU的实现 2016-02-04

标签：stack

Mon, 01 Jan 0001 00:00:00 +0000

带标签「stack」的文章共 1 篇。

计算机科学基础知识之（六）：理解栈帧 2015-03-12

标签：static

Mon, 01 Jan 0001 00:00:00 +0000

带标签「static」的文章共 1 篇。

蓝牙协议分析(6)_BLE地址类型 2016-06-07

标签：STD

Mon, 01 Jan 0001 00:00:00 +0000

带标签「STD」的文章共 1 篇。

Linux电源管理(5)_Hibernate和Sleep功能介绍 2014-06-10

标签：STR

Mon, 01 Jan 0001 00:00:00 +0000

带标签「STR」的文章共 1 篇。

Linux电源管理(5)_Hibernate和Sleep功能介绍 2014-06-10

标签：subsystem

Mon, 01 Jan 0001 00:00:00 +0000

带标签「subsystem」的文章共 4 篇。

linux内核中的GPIO系统之（5）：gpio subsysem和pinctrl subsystem之间的耦合 2017-08-10
linux内核中的GPIO系统之（4）：pinctrl驱动的理解和总结 2017-06-27
X-006-UBOOT-pinctrl driver移植(Bubblegum-96平台) 2016-07-09
Linux graphic subsytem(1)_概述 2015-12-17

标签：SurfaceFlinger

Mon, 01 Jan 0001 00:00:00 +0000

带标签「SurfaceFlinger」的文章共 1 篇。

Linux graphic subsytem(1)_概述 2015-12-17

标签：suspend

Mon, 01 Jan 0001 00:00:00 +0000

带标签「suspend」的文章共 4 篇。

irq wakeup in linux 2021-11-15
系统休眠（System Suspend）和设备中断处理 2017-04-21
Linux电源管理(6)_Generic PM之Suspend功能 2014-08-22
Linux电源管理(2)_Generic PM之基本概念和软件架构 2014-05-13

标签：sysfs

Mon, 01 Jan 0001 00:00:00 +0000

带标签「sysfs」的文章共 2 篇。

X-025-KERNEL-Linux gpio driver的移植之基本功能 2017-09-13
Linux设备模型(4)_sysfs 2014-03-14

标签：systemd

Mon, 01 Jan 0001 00:00:00 +0000

带标签「systemd」的文章共 2 篇。

Debian下的WiFi实验（二）：无线网卡自动连接AP 2016-03-24
systemd：为何要创建一个新的init系统软件 2016-03-17

标签：T1

Mon, 01 Jan 0001 00:00:00 +0000

带标签「T1」的文章共 1 篇。

一个技术男眼中的Smartisan T1手机 2014-11-24

标签：task

Mon, 01 Jan 0001 00:00:00 +0000

带标签「task」的文章共 1 篇。

CFS任务放置代码详解 2021-12-31

标签：tasklet

Mon, 01 Jan 0001 00:00:00 +0000

带标签「tasklet」的文章共 1 篇。

linux kernel的中断子系统之（九）：tasklet 2015-07-02

标签：terminal

Mon, 01 Jan 0001 00:00:00 +0000

带标签「terminal」的文章共 1 篇。

Linux TTY framework(1)_基本概念 2016-09-18

标签：thermal

Mon, 01 Jan 0001 00:00:00 +0000

带标签「thermal」的文章共 2 篇。

linux thermal framework(5)_thermal core 2025-04-14
linux thermal framework(4)_thermal governor 2025-04-14

标签：tick

Mon, 01 Jan 0001 00:00:00 +0000

带标签「tick」的文章共 3 篇。

Linux时间子系统之（十四）：tick broadcast framework 2015-05-21
Linux时间子系统之（十三）：Tick Device layer综述 2015-03-26
Linux时间子系统之（十二）：periodic tick 2014-12-11

标签：tickless

Mon, 01 Jan 0001 00:00:00 +0000

带标签「tickless」的文章共 1 篇。

Linux时间子系统之（十三）：Tick Device layer综述 2015-03-26

标签：timekeeping

Mon, 01 Jan 0001 00:00:00 +0000

带标签「timekeeping」的文章共 1 篇。

Linux时间子系统之（四）：timekeeping 2014-12-29

标签：timer

Mon, 01 Jan 0001 00:00:00 +0000

带标签「timer」的文章共 2 篇。

X-015-KERNEL-ARM generic timer driver的移植 2016-11-02
Linux时间子系统之（六）：POSIX timer 2015-01-22

标签：TLB

Mon, 01 Jan 0001 00:00:00 +0000

带标签「TLB」的文章共 2 篇。

进程切换分析（2）：TLB处理 2017-02-09
TLB flush操作 2016-09-23

标签：topology

Mon, 01 Jan 0001 00:00:00 +0000

带标签「topology」的文章共 1 篇。

Linux CPU core的电源管理(2)_cpu topology 2015-05-30

标签：tracking

Mon, 01 Jan 0001 00:00:00 +0000

带标签「tracking」的文章共 1 篇。

per-entity load tracking 2018-08-18

标签：transmit

Mon, 01 Jan 0001 00:00:00 +0000

带标签「transmit」的文章共 1 篇。

X-019-KERNEL-串口驱动开发之数据收发 2016-11-29

标签：tree

Mon, 01 Jan 0001 00:00:00 +0000

带标签「tree」的文章共 2 篇。

Device Tree（二）：基本概念 2014-05-30
Device Tree（一）：背景介绍 2014-05-22

标签：tty

Mon, 01 Jan 0001 00:00:00 +0000

带标签「tty」的文章共 6 篇。

tty驱动分析 2018-04-20
进程管理和终端驱动：基本概念 2016-10-28
Linux TTY framework(4)_TTY driver 2016-10-25
Linux TTY framework(3)_从应用的角度看TTY设备 2016-10-14
Linux TTY framework(2)_软件架构 2016-09-27
Linux TTY framework(1)_基本概念 2016-09-18

标签：tty_port

Mon, 01 Jan 0001 00:00:00 +0000

带标签「tty_port」的文章共 1 篇。

Linux TTY framework(4)_TTY driver 2016-10-25

标签：tty_struct

Mon, 01 Jan 0001 00:00:00 +0000

带标签「tty_struct」的文章共 1 篇。

Linux TTY framework(4)_TTY driver 2016-10-25

标签：tx

Mon, 01 Jan 0001 00:00:00 +0000

带标签「tx」的文章共 1 篇。

X-019-KERNEL-串口驱动开发之数据收发 2016-11-29

标签：type-c

Mon, 01 Jan 0001 00:00:00 +0000

带标签「type-c」的文章共 1 篇。

USB-C(USB Type-C)规范的简单介绍和分析 2017-12-18

标签：typec

Mon, 01 Jan 0001 00:00:00 +0000

带标签「typec」的文章共 1 篇。

USB-C(USB Type-C)规范的简单介绍和分析 2017-12-18

标签：u-boot

Mon, 01 Jan 0001 00:00:00 +0000

带标签「u-boot」的文章共 12 篇。

X-022-OTHERS-git操作记录之合并远端分支的更新 2017-01-02
基于Hikey的"Boot from USB"调试 2016-12-20
X-013-UBOOT-使能autoboot功能 2016-10-05
X-011-UBOOT-使用bootm命令启动kernel(Bubblegum-96平台) 2016-09-09
u-boot FIT image介绍 2016-09-02
X-010-UBOOT-使用booti命令启动kernel(Bubblegum-96平台) 2016-08-24
X-008-UBOOT-支持命令行(Bubblegum-96平台) 2016-07-27
X-007-UBOOT-DDR的初始化(Bubblegum-96平台) 2016-07-21
X-006-UBOOT-pinctrl driver移植(Bubblegum-96平台) 2016-07-09
X-005-UBOOT-device tree移植(Bubblegum-96平台) 2016-06-29
X-004-UBOOT-串口驱动移植(Bubblegum-96平台) 2016-06-18
u-boot启动流程分析(1)_平台相关部分 2016-05-19

标签：uart

Mon, 01 Jan 0001 00:00:00 +0000

带标签「uart」的文章共 3 篇。

串口通信技术浅析 2016-06-24
X-004-UBOOT-串口驱动移植(Bubblegum-96平台) 2016-06-18
linux 串口调试方法 2015-04-08

标签：uart_driver

Mon, 01 Jan 0001 00:00:00 +0000

带标签「uart_driver」的文章共 1 篇。

X-017-KERNEL-串口驱动开发之uart driver框架 2016-11-16

标签：uboot

Mon, 01 Jan 0001 00:00:00 +0000

带标签「uboot」的文章共 4 篇。

X-011-UBOOT-使用bootm命令启动kernel(Bubblegum-96平台) 2016-09-09
X-004-UBOOT-串口驱动移植(Bubblegum-96平台) 2016-06-18
u-boot启动流程分析(2)_板级(board)部分 2016-06-07
X-003-UBOOT-基于Bubblegum-96平台的u-boot移植说明 2016-05-29

标签：udev

Mon, 01 Jan 0001 00:00:00 +0000

带标签「udev」的文章共 1 篇。

Debian下的WiFi实验（二）：无线网卡自动连接AP 2016-03-24

标签：UEFI

Mon, 01 Jan 0001 00:00:00 +0000

带标签「UEFI」的文章共 1 篇。

ARM64的启动过程之（五）：UEFI 2015-10-30

标签：Uevent

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Uevent」的文章共 1 篇。

Linux设备模型(3)_Uevent 2014-03-10

标签：uImage

Mon, 01 Jan 0001 00:00:00 +0000

带标签「uImage」的文章共 2 篇。

X-011-UBOOT-使用bootm命令启动kernel(Bubblegum-96平台) 2016-09-09
u-boot FIT image介绍 2016-09-02

标签：unblank

Mon, 01 Jan 0001 00:00:00 +0000

带标签「unblank」的文章共 1 篇。

显示技术介绍(3)_CRT技术 2016-01-30

标签：unix历史

Mon, 01 Jan 0001 00:00:00 +0000

带标签「unix历史」的文章共 1 篇。

Unix的历史 2014-04-21

标签：USB

Mon, 01 Jan 0001 00:00:00 +0000

带标签「USB」的文章共 4 篇。

USB-C(USB Type-C)规范的简单介绍和分析 2017-12-18
基于Hikey的"Boot from USB"调试 2016-12-20
X-002-HW-S900芯片boot from USB有关的硬件描述 2016-05-12
Linux 3.18U盘无法正确使用 2015-10-28

标签：vim

Mon, 01 Jan 0001 00:00:00 +0000

带标签「vim」的文章共 2 篇。

在PowerShell中使用Vim 2014-06-18
vim使用技巧摘录 2014-06-10

标签：vim_rc

Mon, 01 Jan 0001 00:00:00 +0000

带标签「vim_rc」的文章共 1 篇。

vim使用技巧摘录 2014-06-10

标签：vt

Mon, 01 Jan 0001 00:00:00 +0000

带标签「vt」的文章共 1 篇。

Linux TTY framework(3)_从应用的角度看TTY设备 2016-10-14

标签：wakelock

Mon, 01 Jan 0001 00:00:00 +0000

带标签「wakelock」的文章共 1 篇。

Linux电源管理(9)_wakelocks 2014-09-14

标签：wakeup

Mon, 01 Jan 0001 00:00:00 +0000

带标签「wakeup」的文章共 2 篇。

Linux电源管理(8)_Wakeup count功能 2014-09-12
Linux电源管理(7)_Wakeup events framework 2014-09-09

标签：wakeup_count

Mon, 01 Jan 0001 00:00:00 +0000

带标签「wakeup_count」的文章共 1 篇。

Linux电源管理(5)_Hibernate和Sleep功能介绍 2014-06-10

标签：Wayland

Mon, 01 Jan 0001 00:00:00 +0000

带标签「Wayland」的文章共 1 篇。

Linux graphic subsytem(1)_概述 2015-12-17

标签：wfe

Mon, 01 Jan 0001 00:00:00 +0000

带标签「wfe」的文章共 2 篇。

CPU 多核指令 —— WFE 原理 2022-02-11
ARM WFI和WFE指令 2014-12-10

标签：wfi

Mon, 01 Jan 0001 00:00:00 +0000

带标签「wfi」的文章共 2 篇。

CPU 多核指令 —— WFE 原理 2022-02-11
ARM WFI和WFE指令 2014-12-10

标签：white_list

Mon, 01 Jan 0001 00:00:00 +0000

带标签「white_list」的文章共 1 篇。

蓝牙协议分析(8)_BLE安全机制之白名单 2016-11-10

标签：wifi

Mon, 01 Jan 0001 00:00:00 +0000

带标签「wifi」的文章共 1 篇。

Debian下的WiFi实验（二）：无线网卡自动连接AP 2016-03-24

标签：win8

Mon, 01 Jan 0001 00:00:00 +0000

带标签「win8」的文章共 1 篇。

在PowerShell中使用Vim 2014-06-18

标签：windows

Mon, 01 Jan 0001 00:00:00 +0000

带标签「windows」的文章共 1 篇。

X-024-OHTHERS-在windows平台下使用libusb 2017-07-23

标签：workqueue

Mon, 01 Jan 0001 00:00:00 +0000

带标签「workqueue」的文章共 2 篇。

标签：wpa_supplicant

Mon, 01 Jan 0001 00:00:00 +0000

带标签「wpa_supplicant」的文章共 1 篇。

Debian下的WiFi实验（一）：通过无线网卡连接AP 2016-03-08

标签：writeback

Mon, 01 Jan 0001 00:00:00 +0000

带标签「writeback」的文章共 1 篇。

文件缓存回写简述 2016-08-24

标签：x

Mon, 01 Jan 0001 00:00:00 +0000

带标签「x」的文章共 3 篇。

X-009-KERNEL-Linux kernel的移植(Bubblegum-96平台) 2016-08-19
X-004-UBOOT-串口驱动移植(Bubblegum-96平台) 2016-06-18
X-000-PRE-开发环境搭建 2016-04-23

标签：zadig

Mon, 01 Jan 0001 00:00:00 +0000

带标签「zadig」的文章共 1 篇。

X-024-OHTHERS-在windows平台下使用libusb 2017-07-23

标签：zRAM

Mon, 01 Jan 0001 00:00:00 +0000

带标签「zRAM」的文章共 1 篇。

zRAM内存压缩技术原理与应用 2020-03-08

标签：安全

Mon, 01 Jan 0001 00:00:00 +0000

带标签「安全」的文章共 2 篇。

蓝牙协议分析(10)_BLE安全机制之LE Encryption 2017-03-28
蓝牙协议分析(9)_BLE安全机制之LL Privacy 2016-11-25

标签：白名单

Mon, 01 Jan 0001 00:00:00 +0000

带标签「白名单」的文章共 1 篇。

蓝牙协议分析(8)_BLE安全机制之白名单 2016-11-10

标签：奔跑吧

Mon, 01 Jan 0001 00:00:00 +0000

带标签「奔跑吧」的文章共 1 篇。

《奔跑吧，Linux内核》已经上架预售了 2017-08-05

标签：初始化

Mon, 01 Jan 0001 00:00:00 +0000

带标签「初始化」的文章共 3 篇。

标签：串口

Mon, 01 Jan 0001 00:00:00 +0000

带标签「串口」的文章共 2 篇。

Linux serial framework(1)_概述 2016-12-12
X-016-KERNEL-串口驱动开发之驱动框架 2016-11-10

标签：创业

Mon, 01 Jan 0001 00:00:00 +0000

带标签「创业」的文章共 1 篇。

我眼中的可穿戴设备 2014-11-05

标签：锤子手机

Mon, 01 Jan 0001 00:00:00 +0000

带标签「锤子手机」的文章共 1 篇。

一个技术男眼中的Smartisan T1手机 2014-11-24

标签：存储体系

Mon, 01 Jan 0001 00:00:00 +0000

带标签「存储体系」的文章共 1 篇。

计算机科学基础知识（一）:The Memory Hierarchy 2014-06-16

标签：打开MMU

Mon, 01 Jan 0001 00:00:00 +0000

带标签「打开MMU」的文章共 1 篇。

ARM64的启动过程之（四）：打开MMU 2015-10-24

标签：打印

Mon, 01 Jan 0001 00:00:00 +0000

带标签「打印」的文章共 1 篇。

小printf大作用（用日志打印的方式调试程序） 2014-01-23

标签：代码分析

Mon, 01 Jan 0001 00:00:00 +0000

带标签「代码分析」的文章共 2 篇。

linux kernel的中断子系统之（七）：GIC代码分析 2014-09-04
GIC驱动代码分析（废弃） 2014-07-04

标签：地址翻译

Mon, 01 Jan 0001 00:00:00 +0000

带标签「地址翻译」的文章共 1 篇。

ARM64架构下地址翻译相关的宏定义 2016-08-12

标签：电容

Mon, 01 Jan 0001 00:00:00 +0000

带标签「电容」的文章共 1 篇。

基本电路概念之（二）：什么是电容？ 2014-06-17

标签：电压

Mon, 01 Jan 0001 00:00:00 +0000

带标签「电压」的文章共 1 篇。

基本电路概念之（一）：什么是电压？ 2014-05-16

标签：电源管理

Mon, 01 Jan 0001 00:00:00 +0000

带标签「电源管理」的文章共 12 篇。

irq wakeup in linux 2021-11-15
中断唤醒系统流程 2018-01-01
Linux PM QoS framework(1)_概述和软件架构 2015-02-04
Linux PM domain framework(1)_概述和使用流程 2014-11-13
Linux电源管理(11)_Runtime PM之功能描述 2014-10-08
Linux电源管理(10)_autosleep 2014-09-18
Linux电源管理(9)_wakelocks 2014-09-14
Linux电源管理(8)_Wakeup count功能 2014-09-12
Linux电源管理(7)_Wakeup events framework 2014-09-09
Linux电源管理(6)_Generic PM之Suspend功能 2014-08-22
Linux电源管理(4)_Power Management Interface 2014-05-29
Linux电源管理(3)_Generic PM之Reboot过程 2014-05-19

标签：调度

Mon, 01 Jan 0001 00:00:00 +0000

带标签「调度」的文章共 1 篇。

中断上下文中调度会怎样？ 2017-03-20

标签：调度器

Mon, 01 Jan 0001 00:00:00 +0000

带标签「调度器」的文章共 1 篇。

Linux调度器：用户空间接口 2017-03-10

标签：调试

Mon, 01 Jan 0001 00:00:00 +0000

带标签「调试」的文章共 1 篇。

小printf大作用（用日志打印的方式调试程序） 2014-01-23

标签：动态库

Mon, 01 Jan 0001 00:00:00 +0000

带标签「动态库」的文章共 1 篇。

计算机科学基础知识（四）: 动态库和位置无关代码 2015-03-06

标签：动态链接

Mon, 01 Jan 0001 00:00:00 +0000

带标签「动态链接」的文章共 1 篇。

计算机科学基础知识（五）: 动态链接 2015-03-10

标签：多媒体

Mon, 01 Jan 0001 00:00:00 +0000

带标签「多媒体」的文章共 1 篇。

智慧家庭之我见_多媒体篇 2014-07-09

标签：防冲突

Mon, 01 Jan 0001 00:00:00 +0000

带标签「防冲突」的文章共 1 篇。

防冲突机制介绍 2014-10-24

标签：负载均衡

Mon, 01 Jan 0001 00:00:00 +0000

带标签「负载均衡」的文章共 1 篇。

CFS任务的负载均衡（任务放置） 2021-11-12

标签：傅立叶级数

Mon, 01 Jan 0001 00:00:00 +0000

带标签「傅立叶级数」的文章共 1 篇。

傅立叶级数（Fourier Series）和周期现象 2014-08-07

标签：概念

Mon, 01 Jan 0001 00:00:00 +0000

带标签「概念」的文章共 1 篇。

Linux kernel内存管理的基本概念 2017-11-09

标签：广播

Mon, 01 Jan 0001 00:00:00 +0000

带标签「广播」的文章共 1 篇。

蓝牙协议分析(5)_BLE广播通信相关的技术分析 2016-05-27

标签：回写

Mon, 01 Jan 0001 00:00:00 +0000

带标签「回写」的文章共 1 篇。

文件缓存回写简述 2016-08-24

标签：激励

Mon, 01 Jan 0001 00:00:00 +0000

带标签「激励」的文章共 1 篇。

由Flappy Bird想到的技术观、哲学观和人生观 2014-02-13

标签：架构

Mon, 01 Jan 0001 00:00:00 +0000

带标签「架构」的文章共 3 篇。

标签：简约

Mon, 01 Jan 0001 00:00:00 +0000

带标签「简约」的文章共 1 篇。

由Flappy Bird想到的技术观、哲学观和人生观 2014-02-13

标签：鉴权

Mon, 01 Jan 0001 00:00:00 +0000

带标签「鉴权」的文章共 1 篇。

蓝牙协议分析(11)_BLE安全机制之SM 2017-09-07

标签：教育

Mon, 01 Jan 0001 00:00:00 +0000

带标签「教育」的文章共 1 篇。

教育漫谈(1)_《乌合之众》摘录 2014-04-19

标签：进程ID

Mon, 01 Jan 0001 00:00:00 +0000

带标签「进程ID」的文章共 1 篇。

Linux系统如何标识进程？ 2017-02-23

标签：进程管理

Mon, 01 Jan 0001 00:00:00 +0000

带标签「进程管理」的文章共 2 篇。

CFS任务的负载均衡（概述） 2021-11-05
Linux调度器：用户空间接口 2017-03-10

标签：进程切换

Mon, 01 Jan 0001 00:00:00 +0000

带标签「进程切换」的文章共 2 篇。

进程切换分析（2）：TLB处理 2017-02-09
进程切换分析(1)：基本框架 2017-02-04

标签：进程优先级

Mon, 01 Jan 0001 00:00:00 +0000

带标签「进程优先级」的文章共 1 篇。

Linux调度器：进程优先级 2017-03-14

标签：静态库

Mon, 01 Jan 0001 00:00:00 +0000

带标签「静态库」的文章共 1 篇。

计算机科学基础知识（三）:静态库和静态链接 2015-02-16

标签：静态链接

Mon, 01 Jan 0001 00:00:00 +0000

带标签「静态链接」的文章共 1 篇。

计算机科学基础知识（三）:静态库和静态链接 2015-02-16

标签：开发环境

Mon, 01 Jan 0001 00:00:00 +0000

带标签「开发环境」的文章共 1 篇。

Windows系统结合MinGW搭建软件开发环境 2014-01-22

标签：可穿戴设备

Mon, 01 Jan 0001 00:00:00 +0000

带标签「可穿戴设备」的文章共 1 篇。

我眼中的可穿戴设备 2014-11-05

标签：空指针

Mon, 01 Jan 0001 00:00:00 +0000

带标签「空指针」的文章共 1 篇。

总结Linux kernel开发中0的巧妙使用 2015-07-20

标签：控制台

Mon, 01 Jan 0001 00:00:00 +0000

带标签「控制台」的文章共 1 篇。

Linux TTY framework(1)_基本概念 2016-09-18

标签：控制终端

Mon, 01 Jan 0001 00:00:00 +0000

带标签「控制终端」的文章共 1 篇。

Linux TTY framework(3)_从应用的角度看TTY设备 2016-10-14

标签：框架

Mon, 01 Jan 0001 00:00:00 +0000

带标签「框架」的文章共 3 篇。

标签：蓝牙

Mon, 01 Jan 0001 00:00:00 +0000

带标签「蓝牙」的文章共 11 篇。

蓝牙协议分析(11)_BLE安全机制之SM 2017-09-07
蓝牙协议分析(10)_BLE安全机制之LE Encryption 2017-03-28
玩转BLE(3)_使用微信蓝牙精简协议伪造记步数据 2017-03-11
快讯：蓝牙5.0发布（新特性速览） 2016-12-08
蓝牙协议分析(9)_BLE安全机制之LL Privacy 2016-11-25
蓝牙协议分析(8)_BLE安全机制之白名单 2016-11-10
蓝牙协议分析(7)_BLE连接有关的技术分析 2016-07-01
蓝牙协议分析(6)_BLE地址类型 2016-06-07
蓝牙协议分析(5)_BLE广播通信相关的技术分析 2016-05-27
玩转BLE(2)_使用bluepy扫描BLE的广播数据 2016-05-19
蓝牙协议中LQ和RSSI的原理及应用场景 2014-03-12

标签：蓝牙低功耗

Mon, 01 Jan 0001 00:00:00 +0000

带标签「蓝牙低功耗」的文章共 1 篇。

蓝牙协议分析(3)_蓝牙低功耗(BLE)协议栈介绍 2016-03-12

标签：流控

Mon, 01 Jan 0001 00:00:00 +0000

带标签「流控」的文章共 1 篇。

蓝牙协议分析(7)_BLE连接有关的技术分析 2016-07-01

标签：流量统计

Mon, 01 Jan 0001 00:00:00 +0000

带标签「流量统计」的文章共 1 篇。

蜗窝流量地域统计 2015-04-23

标签：罗永浩

Mon, 01 Jan 0001 00:00:00 +0000

带标签「罗永浩」的文章共 1 篇。

一个技术男眼中的Smartisan T1手机 2014-11-24

标签：码农

Mon, 01 Jan 0001 00:00:00 +0000

带标签「码农」的文章共 1 篇。

从“码农”说起 2014-11-18

标签：模拟串口

Mon, 01 Jan 0001 00:00:00 +0000

带标签「模拟串口」的文章共 1 篇。

tty驱动分析 2018-04-20

标签：内存布局

Mon, 01 Jan 0001 00:00:00 +0000

带标签「内存布局」的文章共 1 篇。

内存初始化代码分析（二）：内存布局 2016-11-18

标签：内存管理

Mon, 01 Jan 0001 00:00:00 +0000

带标签「内存管理」的文章共 4 篇。

标签：内存屏障

Mon, 01 Jan 0001 00:00:00 +0000

带标签「内存屏障」的文章共 4 篇。

perfbook memory barrier（14.2章节）的中文翻译（上） 2015-12-25
Why Memory Barriers？中文翻译（上） 2015-12-10
Linux内核同步机制之（三）：memory barrier 2014-11-14
DMB DSB ISB以及SMP CPU 乱序 2014-08-15

标签：内存碎片

Mon, 01 Jan 0001 00:00:00 +0000

带标签「内存碎片」的文章共 1 篇。

linux kernel内存碎片防治技术 2015-11-02

标签：内存一致性模型

Mon, 01 Jan 0001 00:00:00 +0000

带标签「内存一致性模型」的文章共 1 篇。

内存一致性模型 2019-03-24

标签：内核

Mon, 01 Jan 0001 00:00:00 +0000

带标签「内核」的文章共 23 篇。

Linux kernel内存管理的基本概念 2017-11-09
Linux kernel scatterlist API介绍 2017-10-13
Linux reset framework 2017-09-01
Linux DMA Engine framework(2)_功能介绍及解接口分析 2017-05-02
Linux DMA Engine framework(1)_概述 2017-03-30
Linux MMC framework(2)_host controller driver 2017-03-08
Linux MMC framework(1)_软件架构 2017-01-10
X-015-KERNEL-ARM generic timer driver的移植 2016-11-02
X-014-KERNEL-ARM GIC driver的移植 2016-10-31
Linux TTY framework(5)_System console driver 2016-10-29
Linux TTY framework(4)_TTY driver 2016-10-25
Linux TTY framework(1)_基本概念 2016-09-18
Linux kernel内核配置解析(5)_Boot options(基于ARM64架构) 2016-08-12
Linux kernel内核配置解析(1)_概述(基于ARM64架构) 2016-08-10
Linux电源管理(6)_Generic PM之Suspend功能 2014-08-22
Linux设备模型(7)_Class 2014-04-23
Linux设备模型(6)_Bus 2014-04-15
Linux设备模型(5)_device和device driver 2014-04-02
Linux设备模型(4)_sysfs 2014-03-14
Linux设备模型(3)_Uevent 2014-03-10
Linux设备模型(2)_Kobject 2014-03-07
Linux设备模型(1)_基本概念 2014-02-27
Linux内核的整体架构 2014-02-21

标签：内核升级

Mon, 01 Jan 0001 00:00:00 +0000

带标签「内核升级」的文章共 1 篇。

Debian8 内核升级实验 2017-02-27

标签：内核同步

Mon, 01 Jan 0001 00:00:00 +0000

带标签「内核同步」的文章共 2 篇。

Linux内核同步机制之（二）：Per-CPU变量 2014-10-16
Linux内核同步机制之（一）：原子操作 2014-10-10

标签：逆向映射

Mon, 01 Jan 0001 00:00:00 +0000

带标签「逆向映射」的文章共 1 篇。

逆向映射的演进 2017-11-17

标签：配对

Mon, 01 Jan 0001 00:00:00 +0000

带标签「配对」的文章共 1 篇。

蓝牙协议分析(11)_BLE安全机制之SM 2017-09-07

标签：配置项

Mon, 01 Jan 0001 00:00:00 +0000

带标签「配置项」的文章共 2 篇。

Linux kernel内核配置解析(5)_Boot options(基于ARM64架构) 2016-08-12
Linux kernel内核配置解析(1)_概述(基于ARM64架构) 2016-08-10

标签：驱动

Mon, 01 Jan 0001 00:00:00 +0000

带标签「驱动」的文章共 1 篇。

X-016-KERNEL-串口驱动开发之驱动框架 2016-11-10

标签：驱动开发

Mon, 01 Jan 0001 00:00:00 +0000

带标签「驱动开发」的文章共 1 篇。

Linux设备模型(1)_基本概念 2014-02-27

标签：人力成本

Mon, 01 Jan 0001 00:00:00 +0000

带标签「人力成本」的文章共 1 篇。

从“码农”说起 2014-11-18

标签：任务放置

Mon, 01 Jan 0001 00:00:00 +0000

带标签「任务放置」的文章共 2 篇。

CFS任务放置代码详解 2021-12-31
CFS任务的负载均衡（任务放置） 2021-11-12

标签：日志

Mon, 01 Jan 0001 00:00:00 +0000

带标签「日志」的文章共 1 篇。

小printf大作用（用日志打印的方式调试程序） 2014-01-23

标签：软件架构

Mon, 01 Jan 0001 00:00:00 +0000

带标签「软件架构」的文章共 1 篇。

Linux Regulator Framework(1)_概述 2015-03-20

标签：软件开发

Mon, 01 Jan 0001 00:00:00 +0000

带标签「软件开发」的文章共 1 篇。

“蜗窝”使用的软件开发环境介绍 2014-01-21

标签：软件框架

Mon, 01 Jan 0001 00:00:00 +0000

带标签「软件框架」的文章共 3 篇。

标签：软中断

Mon, 01 Jan 0001 00:00:00 +0000

带标签「软中断」的文章共 1 篇。

linux kernel的中断子系统之（八）：softirq 2014-10-24

标签：三观端正

Mon, 01 Jan 0001 00:00:00 +0000

带标签「三观端正」的文章共 1 篇。

一个技术男眼中的Smartisan T1手机 2014-11-24

标签：上拉电阻

Mon, 01 Jan 0001 00:00:00 +0000

带标签「上拉电阻」的文章共 1 篇。

对heziq网友问题的回答 2015-03-23

标签：设备模型

Mon, 01 Jan 0001 00:00:00 +0000

带标签「设备模型」的文章共 10 篇。

linux thermal framework(1)_概述 2025-04-14
Linux设备模型(9)_device resource management 2014-09-24
Linux设备模型(8)_platform设备 2014-04-28
Linux设备模型(7)_Class 2014-04-23
Linux设备模型(6)_Bus 2014-04-15
Linux设备模型(5)_device和device driver 2014-04-02
Linux设备模型(4)_sysfs 2014-03-14
Linux设备模型(3)_Uevent 2014-03-10
Linux设备模型(2)_Kobject 2014-03-07
Linux设备模型(1)_基本概念 2014-02-27

标签：设备树

Mon, 01 Jan 0001 00:00:00 +0000

带标签「设备树」的文章共 2 篇。

Device Tree（四）：文件结构解析 2017-09-24
Device Tree（三）：代码分析 2014-06-06

标签：设备资源管理

Mon, 01 Jan 0001 00:00:00 +0000

带标签「设备资源管理」的文章共 1 篇。

Linux设备模型(9)_device resource management 2014-09-24

标签：时间基础

Mon, 01 Jan 0001 00:00:00 +0000

带标签「时间基础」的文章共 1 篇。

Linux时间子系统之（一）：时间的基本概念 2014-12-23

标签：时间子系统

Mon, 01 Jan 0001 00:00:00 +0000

带标签「时间子系统」的文章共 2 篇。

Linux时间子系统之（二）：软件架构 2015-03-07
Linux时间子系统之（十五）：clocksource 2014-12-01

标签：实现

Mon, 01 Jan 0001 00:00:00 +0000

带标签「实现」的文章共 1 篇。

Linux common clock framework(3)_实现逻辑分析 2014-11-24

标签：宿命

Mon, 01 Jan 0001 00:00:00 +0000

带标签「宿命」的文章共 1 篇。

从“码农”说起 2014-11-18

标签：锁

Mon, 01 Jan 0001 00:00:00 +0000

带标签「锁」的文章共 1 篇。

Linux内核的自旋锁 2019-05-17

标签：体验

Mon, 01 Jan 0001 00:00:00 +0000

带标签「体验」的文章共 1 篇。

一个技术男眼中的Smartisan T1手机 2014-11-24

标签：跳频

Mon, 01 Jan 0001 00:00:00 +0000

带标签「跳频」的文章共 1 篇。

蓝牙协议分析(7)_BLE连接有关的技术分析 2016-07-01

标签：微信

Mon, 01 Jan 0001 00:00:00 +0000

带标签「微信」的文章共 1 篇。

玩转BLE(3)_使用微信蓝牙精简协议伪造记步数据 2017-03-11

标签：伪终端

Mon, 01 Jan 0001 00:00:00 +0000

带标签「伪终端」的文章共 1 篇。

Linux TTY framework(3)_从应用的角度看TTY设备 2016-10-14

标签：位置无关代码

Mon, 01 Jan 0001 00:00:00 +0000

带标签「位置无关代码」的文章共 1 篇。

计算机科学基础知识（四）: 动态库和位置无关代码 2015-03-06

标签：文件系统

Mon, 01 Jan 0001 00:00:00 +0000

带标签「文件系统」的文章共 2 篇。

为什么会有文件系统(二) 2017-06-27
为什么会有文件系统(一) 2017-01-17

标签：蜗窝

Mon, 01 Jan 0001 00:00:00 +0000

带标签「蜗窝」的文章共 1 篇。

“蜗窝”使用的软件开发环境介绍 2014-01-21

标签：蜗窝微信群

Mon, 01 Jan 0001 00:00:00 +0000

带标签「蜗窝微信群」的文章共 1 篇。

蜗窝微信群问题整理 2017-07-11

标签：乌合之众

Mon, 01 Jan 0001 00:00:00 +0000

带标签「乌合之众」的文章共 1 篇。

教育漫谈(1)_《乌合之众》摘录 2014-04-19

标签：无锁编程

Mon, 01 Jan 0001 00:00:00 +0000

带标签「无锁编程」的文章共 2 篇。

RCU（2）- 使用方法 2019-05-24
RCU（1）- 概述 2019-05-24

标签：系统安装

Mon, 01 Jan 0001 00:00:00 +0000

带标签「系统安装」的文章共 1 篇。

使用pxe方式安装系统 2016-04-23

标签：系统调用

Mon, 01 Jan 0001 00:00:00 +0000

带标签「系统调用」的文章共 1 篇。

ARM Linux上的系统调用代码分析 2017-02-20

标签：下拉电阻

Mon, 01 Jan 0001 00:00:00 +0000

带标签「下拉电阻」的文章共 1 篇。

对heziq网友问题的回答 2015-03-23

标签：显示

Mon, 01 Jan 0001 00:00:00 +0000

带标签「显示」的文章共 1 篇。

显示技术介绍(1)_概述 2015-11-22

标签：虚拟终端

Mon, 01 Jan 0001 00:00:00 +0000

带标签「虚拟终端」的文章共 1 篇。

Linux TTY framework(3)_从应用的角度看TTY设备 2016-10-14

标签：页面回收

Mon, 01 Jan 0001 00:00:00 +0000

带标签「页面回收」的文章共 1 篇。

页面回收的基本概念 2017-08-25

标签：移植

Mon, 01 Jan 0001 00:00:00 +0000

带标签「移植」的文章共 1 篇。

X-014-KERNEL-ARM GIC driver的移植 2016-10-31

标签：原子操作

Mon, 01 Jan 0001 00:00:00 +0000

带标签「原子操作」的文章共 2 篇。

Atomic operation in aarch64 2021-11-15
Linux内核同步机制之（一）：原子操作 2014-10-10

标签：栈帧

Mon, 01 Jan 0001 00:00:00 +0000

带标签「栈帧」的文章共 1 篇。

计算机科学基础知识之（六）：理解栈帧 2015-03-12

标签：招聘

Mon, 01 Jan 0001 00:00:00 +0000

带标签「招聘」的文章共 1 篇。

教育漫谈(1)_《乌合之众》摘录 2014-04-19

标签：整合

Mon, 01 Jan 0001 00:00:00 +0000

带标签「整合」的文章共 1 篇。

智慧家庭之我见_多媒体篇 2014-07-09

标签：智慧家庭

Mon, 01 Jan 0001 00:00:00 +0000

带标签「智慧家庭」的文章共 1 篇。

智慧家庭之我见_多媒体篇 2014-07-09

标签：中断

Mon, 01 Jan 0001 00:00:00 +0000

带标签「中断」的文章共 2 篇。

一次触摸屏中断调试引发的深入探究 2018-04-23
中断上下文中调度会怎样？ 2017-03-20

标签：中断处理

Mon, 01 Jan 0001 00:00:00 +0000

带标签「中断处理」的文章共 3 篇。

中断唤醒系统流程 2018-01-01
linux kernel的中断子系统之（四）：High level irq event handler 2014-08-28
Linux kernel的中断子系统之（六）：ARM中断处理过程 2014-08-04

标签：中断唤醒

Mon, 01 Jan 0001 00:00:00 +0000

带标签「中断唤醒」的文章共 1 篇。

中断唤醒系统流程 2018-01-01

标签：中断描述符

Mon, 01 Jan 0001 00:00:00 +0000

带标签「中断描述符」的文章共 1 篇。

linux kernel的中断子系统之（三）：IRQ number和中断描述符 2014-08-26

标签：中断子系统

Mon, 01 Jan 0001 00:00:00 +0000

带标签「中断子系统」的文章共 4 篇。

irq wakeup in linux 2021-11-15
中断唤醒系统流程 2018-01-01
linux kernel的中断子系统之（三）：IRQ number和中断描述符 2014-08-26
Linux kernel的中断子系统之（一）：综述 2014-08-14

标签：终端

Mon, 01 Jan 0001 00:00:00 +0000

带标签「终端」的文章共 1 篇。

Linux TTY framework(1)_基本概念 2016-09-18

标签：周期性tick

Mon, 01 Jan 0001 00:00:00 +0000

带标签「周期性tick」的文章共 1 篇。

Linux时间子系统之（十二）：periodic tick 2014-12-11

标签：自旋锁

Mon, 01 Jan 0001 00:00:00 +0000

带标签「自旋锁」的文章共 2 篇。

Linux内核的自旋锁 2019-05-17
Linux内核同步机制之（四）：spin lock 2015-04-22

电源管理子系统

Mon, 01 Jan 0001 00:00:00 +0000

分类「电源管理子系统」共 48 篇。

linux thermal framework(5)_thermal core 2025-04-14
linux thermal framework(4)_thermal governor 2025-04-14
linux thermal framework(3)_thermal cooling device 2025-04-14
linux thermal framework(2)_thermal zone 2025-04-14
linux thermal framework(1)_概述 2025-04-14
irq wakeup in linux 2021-11-15
Linux reset framework 2017-09-01
系统休眠（System Suspend）和设备中断处理 2017-04-21
Common Clock Framework系统结构 2016-04-21
Linux进程冻结技术 2015-11-24
linux cpufreq framework(5)_ARM big Little driver 2015-11-10
Linux CPU core的电源管理(5)_cpu control及cpu hotplug 2015-09-19
linux cpufreq framework(4)_cpufreq governor 2015-08-23
linux cpufreq framework(3)_cpufreq core 2015-07-30
Linux CPU core的电源管理(3)_cpu ops 2015-07-17
Linux cpufreq framework(2)_cpufreq driver 2015-06-19
linux cpufreq framework(1)_概述 2015-06-13
Linux电源管理(15)_PM OPP Interface 2015-06-04
Linux CPU core的电源管理(2)_cpu topology 2015-05-30
Linux CPU core的电源管理(1)_概述 2015-04-30
Linux Regulator Framework(2)_regulator driver 2015-04-16
Linux Regulator Framework(1)_概述 2015-03-20
Linux power supply class(1)_软件架构及API汇整 2015-03-13
Linux电源管理(14)_从设备驱动的角度看电源管理 2015-03-02
Linux PM QoS framework(3)_per-device PM QoS 2015-02-26
Linux PM QoS framework(2)_PM QoS class 2015-02-10
Linux PM QoS framework(1)_概述和软件架构 2015-02-04
Linux cpuidle framework(4)_menu governor 2015-01-18
Linux cpuidle framework(3)_ARM64 generic CPU idle driver 2015-01-06
Linux cpuidle framework(2)_cpuidle core 2014-12-30
Linux电源管理(13)_Driver的电源管理 2014-12-26
Linux电源管理(12)_Hibernate功能 2014-12-22
Linux cpuidle framework(1)_概述和软件架构 2014-12-17
Linux common clock framework(3)_实现逻辑分析 2014-11-24
Linux PM domain framework(1)_概述和使用流程 2014-11-13
Linux common clock framework(2)_clock provider 2014-10-23
Linux common clock framework(1)_概述 2014-10-20
Linux电源管理(11)_Runtime PM之功能描述 2014-10-08
Linux电源管理(10)_autosleep 2014-09-18
Linux电源管理(9)_wakelocks 2014-09-14
Linux电源管理(8)_Wakeup count功能 2014-09-12
Linux电源管理(7)_Wakeup events framework 2014-09-09
Linux电源管理(6)_Generic PM之Suspend功能 2014-08-22
Linux电源管理(5)_Hibernate和Sleep功能介绍 2014-06-10
Linux电源管理(4)_Power Management Interface 2014-05-29
Linux电源管理(3)_Generic PM之Reboot过程 2014-05-19
Linux电源管理(2)_Generic PM之基本概念和软件架构 2014-05-13
Linux电源管理(1)_整体架构 2014-05-07

基础技术

Mon, 01 Jan 0001 00:00:00 +0000

分类「基础技术」共 13 篇。

eMMC 原理 4 ：总线协议 2017-03-01
eMMC 原理 3 ：分区管理 2017-02-06
eMMC 原理 2 ：eMMC 简介 2017-01-12
eMMC 原理 1 ：Flash Memory 简介 2017-01-09
MMC/SD/SDIO介绍 2016-12-25
DRAM 原理 5 ：DRAM Devices Organization 2016-10-15
DRAM 原理 4 ：DRAM Timing 2016-08-29
DRAM 原理 3 ：DRAM Device 2016-07-27
串口通信技术浅析 2016-06-24
DRAM 原理 2 ：DRAM Memory Organization 2016-06-14
DRAM 原理 1 ：DRAM Storage Cell 2016-06-08
防冲突机制介绍 2014-10-24
SDRAM Internals 2014-05-14

基础学科

Mon, 01 Jan 0001 00:00:00 +0000

分类「基础学科」共 10 篇。

Meltdown论文翻译 2018-01-19
计算机科学基础知识之（六）：理解栈帧 2015-03-12
计算机科学基础知识（五）: 动态链接 2015-03-10
计算机科学基础知识（四）: 动态库和位置无关代码 2015-03-06
计算机科学基础知识（三）:静态库和静态链接 2015-02-16
计算机科学基础知识（二）:Relocatable Object File 2015-02-09
傅立叶级数（Fourier Series）和周期现象 2014-08-07
基本电路概念之（二）：什么是电容？ 2014-06-17
计算机科学基础知识（一）:The Memory Hierarchy 2014-06-16
基本电路概念之（一）：什么是电压？ 2014-05-16

技术漫谈

Mon, 01 Jan 0001 00:00:00 +0000

分类「技术漫谈」共 12 篇。

进程管理

Mon, 01 Jan 0001 00:00:00 +0000

分类「进程管理」共 31 篇。

schedutil governor情景分析 2022-04-26
PELT算法浅析 2022-04-07
load_balance函数代码详解 2022-02-16
CFS任务放置代码详解 2021-12-31
CFS任务的负载均衡（load balance） 2021-11-22
CFS任务的负载均衡（任务放置） 2021-11-12
CFS任务的负载均衡（概述） 2021-11-05
CFS调度器（6）-总结 2019-01-01
CFS调度器（5）-带宽控制 2018-12-22
CFS调度器（4）-PELT(per entity load tracking) 2018-12-02
CFS调度器（3）-组调度 2018-11-10
CFS调度器（2）-源码解析 2018-10-21
CFS调度器（1）-基本原理 2018-10-07
per-entity load tracking 2018-08-18
Deadline调度器之（二）：细节和使用方法 2018-02-22
deadline调度器之（一）：原理 2018-01-31
O(n)、O(1)和CFS调度器 2018-01-08
进程切换分析（3）：同步处理 2017-12-11
中断上下文中调度会怎样？ 2017-03-20
Linux调度器：进程优先级 2017-03-14
Linux调度器：用户空间接口 2017-03-10
Linux系统如何标识进程？ 2017-02-23
ARM Linux上的系统调用代码分析 2017-02-20
进程切换分析（2）：TLB处理 2017-02-09
进程切换分析(1)：基本框架 2017-02-04
进程管理和终端驱动：基本概念 2016-10-28
ACCESS_ONCE宏定义的解释 2014-07-17
Process Creation（二） 2014-04-28
Process Creation（一） 2014-04-23
process identification 2014-03-26
process credentials 2014-03-21

蓝牙

Mon, 01 Jan 0001 00:00:00 +0000

分类「蓝牙」共 16 篇。

蓝牙协议分析(11)_BLE安全机制之SM 2017-09-07
蓝牙协议分析(10)_BLE安全机制之LE Encryption 2017-03-28
玩转BLE(3)_使用微信蓝牙精简协议伪造记步数据 2017-03-11
快讯：蓝牙5.0发布（新特性速览） 2016-12-08
蓝牙协议分析(9)_BLE安全机制之LL Privacy 2016-11-25
蓝牙协议分析(8)_BLE安全机制之白名单 2016-11-10
蓝牙协议分析(7)_BLE连接有关的技术分析 2016-07-01
蓝牙协议分析(6)_BLE地址类型 2016-06-07
蓝牙协议分析(5)_BLE广播通信相关的技术分析 2016-05-27
玩转BLE(2)_使用bluepy扫描BLE的广播数据 2016-05-19
玩转BLE(1)_Eddystone beacon 2016-04-29
蓝牙协议分析(4)_IPv6 Over BLE介绍 2016-04-09
蓝牙协议分析(3)_蓝牙低功耗(BLE)协议栈介绍 2016-03-12
蓝牙协议分析(2)_协议架构 2016-01-14
蓝牙协议分析(1)_基本概念 2014-05-23
蓝牙协议中LQ和RSSI的原理及应用场景 2014-03-12

内存管理

Mon, 01 Jan 0001 00:00:00 +0000

分类「内存管理」共 31 篇。

zRAM内存压缩技术原理与应用 2020-03-08
浅谈Cache Memory 2019-05-02
内存一致性模型 2019-03-24
copy_{to,from}_user()的思考 2019-01-27
KASLR 2018-05-06
fixmap addresses原理 2018-04-29
ARM64 Kernel Image Mapping的变化 2018-04-21
SLUB DEBUG原理 2018-02-22
图解slub 2018-02-22
KASAN实现原理 2018-02-11
逆向映射的演进 2017-11-17
Linux kernel内存管理的基本概念 2017-11-09
Linux kernel scatterlist API介绍 2017-10-13
页面回收的基本概念 2017-08-25
/proc/meminfo分析（一） 2017-08-17
Dynamic DMA mapping Guide 2017-07-20
CMA模块学习笔记 2017-06-28
内存初始化代码分析（三）：创建系统内存地址映射 2016-11-24
内存初始化代码分析（二）：内存布局 2016-11-18
内存初始化代码分析（一）：identity mapping和kernel image mapping 2016-11-10
内存初始化（上） 2016-10-13
TLB flush操作 2016-09-23
Fix-Mapped Addresses 2016-09-09
Linux内存模型 2016-08-31
文件缓存回写简述 2016-08-24
ARM64架构下地址翻译相关的宏定义 2016-08-12
slub分配器 2015-12-21
linux kernel内存回收机制 2015-11-12
linux kernel内存碎片防治技术 2015-11-02
Linux vm运行参数之（二）：OOM相关的参数 2015-09-28
Linux vm运行参数之（一）：overcommit相关的参数 2015-09-23

内核同步机制

Mon, 01 Jan 0001 00:00:00 +0000

分类「内核同步机制」共 26 篇。

Linux读写锁逻辑解析 2023-05-29
futex基础问答 2022-10-09
Linux内核同步机制之（九）：Queued spinlock 2022-06-29
Linux内核同步机制之（八）：mutex 2022-05-10
RCU（2）- 使用方法 2019-05-24
RCU（1）- 概述 2019-05-24
Linux内核的自旋锁 2019-05-17
编译乱序(Compiler Reordering) 2019-01-23
Linux中常见同步机制设计原理 2018-06-09
Perf book 9.3章节翻译（下） 2016-02-26
Perf book 9.3章节翻译（上） 2016-02-18
Linux2.6.23 ：sleepable RCU的实现 2016-02-04
Linux2.6.11版本：classic RCU的实现 2016-01-27
Linux 2.5.43版本的RCU实现（废弃） 2016-01-19
perfbook memory barrier（14.2章节）中文翻译（下） 2016-01-11
Why Memory Barriers中文翻译（下） 2016-01-05
perfbook memory barrier（14.2章节）的中文翻译（上） 2015-12-25
Why Memory Barriers？中文翻译（上） 2015-12-10
Linux内核同步机制之（七）：RCU基础 2015-12-03
RCU synchronize原理分析 2015-10-27
Linux内核同步机制之（六）：Seqlock 2015-09-09
Linux内核同步机制之（五）：Read/Write spin lock 2015-05-22
Linux内核同步机制之（四）：spin lock 2015-04-22
Linux内核同步机制之（三）：memory barrier 2014-11-14
Linux内核同步机制之（二）：Per-CPU变量 2014-10-16
Linux内核同步机制之（一）：原子操作 2014-10-10

全部评论

Mon, 01 Jan 0001 00:00:00 +0000

全站数据存档

Mon, 01 Jan 0001 00:00:00 +0000

这里存放原站 www.wowotech.net 的完整结构化数据，作为本站之外的第二种存在形式：即使哪天这个站点也不再维护，任何人都可以从这里拿走全部内容，自行重建或镜像。

下载

wowotech-archive.sqlite —— 单文件 SQLite 数据库，含文章正文、评论、讨论区主题与帖子、成员名录、分类、标签、附件索引。已去除邮箱、IP 等个人信息。

表结构

表	内容
`posts`	372 篇文章与页面（含正文 HTML 原文）
`comments`	7,908 条评论，保留父子关系与时间
`forum_topics` / `forum_posts`	原讨论区 163 个真实主题、792 帖
`forum_users`	注册成员（用户名、帖数、注册与到访时间）
`blog_users`	原博客注册用户
`categories` / `tags` / `attachments`	分类、标签与附件索引

许可

内容版权归原作者所有，采用 CC BY-SA 4.0 协议开放，欢迎任何形式的镜像与再发布。

软件开发

Mon, 01 Jan 0001 00:00:00 +0000

分类「软件开发」共 6 篇。

时间子系统

Mon, 01 Jan 0001 00:00:00 +0000

分类「时间子系统」共 14 篇。

Linux的时钟 2017-05-17
Linux时间子系统之（十四）：tick broadcast framework 2015-05-21
Linux时间子系统之（十三）：Tick Device layer综述 2015-03-26
Linux时间子系统之（二）：软件架构 2015-03-07
Linux时间子系统之（六）：POSIX timer 2015-01-22
Linux时间子系统之（五）：POSIX Clock 2015-01-05
Linux时间子系统之（四）：timekeeping 2014-12-29
Linux时间子系统之（三）：用户空间接口函数 2014-12-24
Linux时间子系统之（一）：时间的基本概念 2014-12-23
Linux时间子系统系列文章之目录 2014-12-23
Linux时间子系统之（十二）：periodic tick 2014-12-11
Linux时间子系统之（十六）：clockevent 2014-12-09
Linux时间子系统之（十七）：ARM generic timer驱动代码分析 2014-12-02
Linux时间子系统之（十五）：clocksource 2014-12-01

随便看看

Mon, 01 Jan 0001 00:00:00 +0000

正在随机挑一篇文章……

讨论区成员名录

Mon, 01 Jan 0001 00:00:00 +0000

共有 733 个注册账号，其中 169 位发过言。（邮箱等联系方式不在公开存档中。）

用户名	帖数	注册时间	最后到访
wowo	221	2016-04-18	2018-10-17
linuxer	106	2016-04-18	2017-09-20
ooonebook	36	2016-04-29	2017-02-05
peter	19	2016-04-19	2017-01-11
karma303	14	2016-06-24	2016-11-26
弯曲的旅行	13	2016-04-19	2018-02-24
温柔海洋	12	2016-04-24	2017-07-01
qdzhaozx	12	2016-05-14	2019-03-13
tigger	12	2016-07-27	2017-02-06
cuixiaolei	9	2016-04-28	2017-03-08
calm.xia	9	2016-05-09	2017-03-08
Kerry	9	2016-06-22	2016-11-11
jack	9	2016-11-25	2018-02-02
Taochao	9	2017-01-22	2018-01-23
wpch315	8	2016-04-18	2017-06-08
上海-云	8	2016-04-20	2016-08-05
Codingbelief	8	2016-05-07	2018-02-12
三少	8	2016-06-30	2017-03-01
victor.guo	8	2016-09-19	2016-09-22
西人	8	2016-09-21	2016-11-21
Daniel	7	2016-04-20	2016-06-03
cinmun	7	2016-05-20	2017-04-10
zmnqaz	7	2016-10-16	2016-11-06
tz_999	7	2017-03-07	2017-03-29
菜刀	6	2016-04-18	2016-04-21
T800	6	2016-04-19	2016-04-21
活出自我	6	2016-04-23	2016-11-03
OSer	6	2016-10-29	2016-11-20
yin	5	2016-04-20	2016-04-24
bruno	5	2016-04-22	2016-06-10
728330453	5	2016-08-26	2016-10-04
马六甲2017	5	2016-10-14	2016-11-04
maze	5	2016-12-16	2017-02-17
wangpeng_bj	5	2017-08-21	2018-03-21
linglongqion	4	2016-04-19	2016-05-14
OceanSummer	4	2016-04-19	2016-04-23
anchen	4	2016-06-24	2016-09-26
metro	4	2016-08-22	2017-01-15
ap0904225	4	2016-11-06	2017-02-09
heziq	4	2016-12-17	2016-12-18
sgsg666	4	2017-02-08	2017-02-08
fdm_dec	4	2017-02-11	2017-03-02
showstopper	3	2016-04-20	2017-01-04
时间为贵	3	2016-04-26	2016-05-16
zyro	3	2016-05-10	2016-05-14
darren	3	2016-05-10	2017-06-13
shumanzhou	3	2016-06-04	2016-12-01
Yoking Wang	3	2016-07-08	2016-07-12
HelloBirthday	3	2016-07-30	2020-06-18
alone-wyr	3	2016-08-08	2016-09-10
feison	3	2016-09-08	2016-09-08
electrlife	3	2016-09-13	2016-12-28
wall-E	3	2016-10-20	2017-06-07
巴扎黑	3	2017-02-06	2018-07-31
jackindata	3	2017-02-17	2017-03-01
vlah	3	2017-07-14	2017-11-11
admin	2	2016-04-15	2016-12-16
huoyancool	2	2016-04-19	2016-04-19
Knight	2	2016-04-19	2016-12-16
eco	2	2016-04-22	2016-04-25
Neal Gong	2	2016-04-22	2016-04-22
kadajur	2	2016-04-22	2016-05-06
scnutiger	2	2016-04-22	2016-05-06
jordonwu	2	2016-05-01	2016-05-03
amalgam-silver	2	2016-05-03	2016-08-16
hangkeke052	2	2016-05-13	2016-10-20
pgalxx	2	2016-05-18	2016-05-18
jidai	2	2016-06-09	2016-06-12
XU	2	2016-06-16	2016-06-16
jansion	2	2016-06-29	2017-04-09
lutingleo	2	2016-07-01	2016-07-04
Terryjourneys	2	2016-07-31	2017-03-31
tab	2	2016-08-19	2022-02-15
firephoenix	2	2016-10-12	2017-08-04
xFrank	2	2016-11-05	2018-07-17
ouzhouren	2	2016-11-29	2016-12-01
无心睡眠	2	2016-12-22	2017-01-04
zhan7802	2	2017-01-01	2017-01-11
井中月	2	2017-01-04	2017-01-21
疯狂的锤头100	2	2017-01-19	2017-04-01
Robin	2	2017-03-21	2017-03-30
dycc	2	2017-05-25	2017-06-30
wpeng_35097	2	2017-05-26	2017-07-16
vachel	2	2017-07-21	2018-08-20
AlohaJack	2	2017-07-31	2017-08-01
gjianw217	2	2018-03-13	2018-04-11
清风拂面1230	2	2018-05-28	2018-05-30
coderall	2	2018-08-05	2018-08-15
linbojue	2	2018-08-15	2018-08-15
hxiaoqiang	1	2016-04-20	2016-04-22
wfing123	1	2016-04-22	2016-04-22
YiYu	1	2016-04-22	2016-06-01
borman	1	2016-04-22	2016-04-22
xiongchuan	1	2016-04-22	2016-04-22
mikrobug	1	2016-04-22	2016-04-27
tl230419	1	2016-04-22	2016-04-26
callme_friend	1	2016-04-23	2016-05-06
多功能张大爷	1	2016-04-26	2016-04-26
Leonard	1	2016-04-29	2016-05-03
Nickisnotnic	1	2016-05-01	2016-05-12
Looper	1	2016-05-03	2016-05-03
moming	1	2016-05-04	2016-05-17
泽霖	1	2016-05-06	2016-05-06
barrenlake	1	2016-05-06	2016-05-06
奔跑的蜗牛	1	2016-06-01	2016-06-13
leo.liu	1	2016-06-03	2018-10-16
lypingsh	1	2016-06-08	2016-06-08
East	1	2016-06-14	2016-07-15
ligang23090	1	2016-06-17	2016-07-28
johnson	1	2016-06-27	2016-06-27
mimolock	1	2016-07-01	2016-07-01
jackal	1	2016-07-10	2019-06-30
leefong.chen	1	2016-07-18	2017-08-21
ues123	1	2016-08-09	2016-08-10
sklli	1	2016-08-24	2019-01-11
Allen.G	1	2016-09-06	2017-02-15
负笈追梦	1	2016-09-09	2016-09-09
Assin	1	2016-09-11	2016-09-11
蓝色火焰	1	2016-09-12	2016-09-12
bulunhaimu	1	2016-09-19	2016-09-19
HHP_Low	1	2016-09-28	2016-10-14
unicornx	1	2016-10-01	2016-10-01
soaringrocs	1	2016-10-09	2016-12-27
albuer	1	2016-11-03	2016-11-03
zhuzhiqiang	1	2016-11-15	2016-11-15
CodingSheep	1	2016-11-17	2016-12-23
happain	1	2016-12-07	2017-09-19
BubbleoO	1	2016-12-21	2016-12-21
thatwas	1	2016-12-30	2018-10-22
青春年少	1	2017-01-04	2017-03-10
xiao萧	1	2017-01-05	2017-01-05
elicec	1	2017-01-08	2017-01-20
hony	1	2017-01-14	2017-01-25
大树一棵	1	2017-01-18	2017-02-07
xiaoloudongfeng	1	2017-01-20	2017-01-20
叶念西风	1	2017-01-27	2017-01-29
ZY	1	2017-02-05	2017-02-05
随之风	1	2017-02-07	2017-09-08
pentagon	1	2017-03-05	2017-03-05
Sky@Learn	1	2017-03-07	2017-03-09
Hisenberg	1	2017-03-13	2017-06-29
qwerty	1	2017-03-17	2017-04-06
sfc0907	1	2017-03-27	2017-03-27
zyk	1	2017-03-28	2017-04-18
iwakan	1	2017-03-31	2017-03-31
firo	1	2017-04-29	2019-07-20
fxllsw	1	2017-05-21	2017-05-22
zwskywalker	1	2017-05-27	2017-05-27
小黑竟然9009	1	2017-07-08	2017-07-09
ghostpipi	1	2017-07-19	2017-07-19
mz	1	2017-07-28	2017-07-28
xcl706	1	2017-07-31	2017-08-06
小艾的	1	2017-08-02	2017-08-02
只是为了好玩	1	2017-08-29	2017-08-29
orange	1	2017-10-16	2019-04-18
今夕何夕	1	2017-11-02	2017-11-04
千帆	1	2017-11-03	2017-11-03
harryxp	1	2017-11-17	2017-11-17
李培锋	1	2018-02-06	2018-02-06
seufy	1	2017-12-01	2017-12-01
jeremy	1	2017-12-17	2018-02-26
rtosiDiot	1	2018-01-23	2018-01-24
-n	1	2018-02-02	2018-03-05
xj916ch	1	2018-04-09	2022-05-28
zdc2124288	1	2018-04-20	2018-04-20
LY_Linux	1	2018-04-28	2018-04-28
sexdollforest	1	2018-05-15	2018-05-15
ihexon	1	2018-07-17	2018-07-17
jinfa	1	2018-09-26	2018-10-12