wdfk-prog的个人博客

[TOC] arch/arm/boot: Linux 32位ARM架构的启动基石arch/arm/boot 目录是 Linux 内核源码中专门为 32 位 ARM 架构（AArch32）设计的启动代码所在地。它的核心使命是充当引导加载程序（Bootloader，如 U-Boot）与体系结构无关的通用内核代码之间的桥梁。这个目录下的代码负责处理内核启动最初始、最底层的阶段，为 C 语言环境的建立和主内核的执行做好万全准备。 一、 核心职责arch/arm/boot 目录下的代码和构建脚本共同完成了以下几项至关重要的任务： 生成可启动的内核镜像: 该目录下的 Makefile 是构建过程的核心，它负责将编译好的内核 vmlinux（一个 ELF 格式的文件）进行处理，最终生成 Bootloader 可以直接加载和执行的镜像格式，最常见的有 zImage 和 uImage。 内核解压缩: 为了减小存储体积和加快加载速度，内核镜像通常是经过压缩的。arch/arm/boot 包含了一个微型的、自解压的前端程序（Decompressor）。当 Bootloader...

[TOC] arch/arm/include/asm/cache.h__read_mostly 大多数读取 __read_mostly用于标记大多数读取的变量,在编译时会将该变量放到.data..read_mostly段中 1#define __read_mostly __section(".data..read_mostly") __read_mostly的作用是将变量放到.data..read_mostly段中,该段在内核启动时会被清零,所以该变量在内核启动时会被清零 arch/arm/include/asm/cmpxchg.harch_xchg_relaxed __arch_xchg 交换数据的逻辑都一样 使用ldrexb加载数据,它还会设置一个标志，表示该地址被标记为“独占访问”，以便后续的存储操作可以检查是否有其他处理器访问了该地址。 使用strexb存储数据,如果成功，返回0；如果失败，返回1，并且会清除“独占访问”标志。 如果strexb失败，循环会重新尝试加载...

[TOC] THUMB2指令集THUMB2 指令集深度解析：从入门到精通THUMB2 指令集是在嵌入式系统领域广受欢迎的 ARM 架构的一项关键技术。它巧妙地结合了 16 位指令的紧凑代码密度和 32 位指令的强大性能，为资源受限的设备提供了高效的解决方案。本文将从历史背景、核心原理、应用场景、入门实践、安全考量、生态系统、性能监控和未来趋势等多个维度，为您全面解析 THUMB2 指令集。 一、 历史与背景为了解决什么特定问题而诞生？ THUMB2 技术的诞生主要是为了解决早期 ARM 架构在嵌入式应用中的一个核心矛盾：性能与代码密度之间的权衡。 ARM 指令集：提供强大的 32 位指令，性能出色，但指令均为 32 位定长，导致代码体积较大，对于内存（尤其是昂贵的片上闪存和 RAM）有限的嵌入式系统而言，成本较高。 Thumb 指令集（第一代）：作为对策，ARM 推出了 16 位的 Thumb 指令集，它是 ARM 指令集的一个子集。 这显著减小了代码体积（约 30%-40%），降低了功耗和内存需求。 然而，Thumb 指令集功能有限，性能相比 32 位 ARM 指令集有所下降...

[TOC] arch/arm/kernel/: Linux 32位ARM内核的体系结构特定实现arch/arm/kernel/ 目录是 Linux 内核中专门负责 32 位 ARM 架构体系结构相关代码实现的核心区域。它包含了将通用内核代码与 ARM 处理器及其外围硬件紧密结合的底层逻辑。简单来说，它是 Linux 内核在 ARM 平台上运行的“神经中枢和硬件适配器”。 一、 核心职责arch/arm/kernel/ 目录下的代码负责 Linux 内核在 ARM 架构上运行的所有关键底层功能，包括： 早期 CPU 初始化: 在主内核 C 代码开始执行后，进行更详细的 CPU 模式设置、缓存和 MMU (内存管理单元) 的初始化。 内存管理设置: 建立虚拟内存与物理内存的映射（页表），这是所有后续内存访问的基础。 异常与中断处理: 定义和处理 ARM 处理器产生的各种异常（如数据中止、预取中止、未定义指令、软件中断等）和中断请求。这是内核响应硬件事件和系统调用的核心机制。 系统调用分发: 提供用户空间应用程序通过软件中断（SWI/SVC ...

[TOC] arch/arm/Makefile: 32位ARM架构的构建总指挥arch/arm/Makefile 是 Linux 内核 Kbuild 系统中专门为 32 位 ARM 架构服务的顶级 Makefile。它不是一个独立的可执行脚本，而是被主 Makefile 包含（include）进去的。它的核心职责是定义 ARM 架构独有的构建规则、配置编译选项，并将 Kconfig 中选择的平台配置转化为实际的构建命令。 可以将其视为一个“总指挥官”，它接收来自 .config 文件的战略指令，然后向编译器、链接器等“部队”下达精确的战术命令，以确保最终能为特定的 ARM 平台构建出正确、高效的内核。 一、 核心角色与职责 定制化主构建流程: 内核的主 Makefile 定义了通用的构建目标（如 vmlinux, modules）。arch/arm/Makefile 则对这些目标进行“重载”或“定制”，添加 ARM 架构特有的依赖和命令。 配置翻译官: 将 .config 文件中由 Kconfig 系统生成的高层配置选项（例如 CONFIG_ARCH_BC...

[TOC] arch/arm/include/asm/delay.h该文件的核心原理是提供一个可插拔的、分层的延迟实现机制。它设计了一个抽象的arm_delay_ops操作函数集, 允许在系统启动时根据可用的硬件资源来选择并注册最优的延迟方法。 对于没有精确硬件定时器的旧系统: 它会回退到一种基于”每秒循环数”(loops_per_jiffy)的校准循环方法。内核在启动时会测量在一个系统时钟节拍(jiffy)内, CPU能执行多少次空循环, 从而计算出一个近似值。udelay的实现会根据这个校准值来计算需要执行多少次循环才能达到指定的微秒延迟。 对于拥有高精度硬件定时器的新系统(如STM32H750): 系统启动代码(通常是特定于板卡的平台代码)可以使用register_current_timer_delay函数来注册一个高精度的定时器(例如ARM Cortex-M内核自带的DWT周期计数器CYCCNT)。一旦注册成功, arm_delay_ops中的函数指针就会被更新为指向基于这个硬件定时器的延迟实现。这种实现方式会读取当前定时器计数值...

[TOC] arch/arm/mm: 解剖Linux的NOMMU内存模型arch/arm/mm 目录包含了 ARM 架构的内存管理代码。在典型的带 MMU 的系统中，它的主要职责是处理虚拟内存、页表、TLB 管理等。但是，当内核被配置为在没有 MMU 的处理器（如 ARM Cortex-M 系列）上运行时，这个目录的功能会发生根本性的变化。 在 NOMMU 模式下，arch/arm/mm 的核心任务不再是管理复杂的虚拟地址空间，而是直接管理一个扁平的、统一的物理地址空间。 一、 NOMMU 的核心概念在深入代码之前，必须理解 NOMMU 环境下的几个基本事实： 单一扁平地址空间: 内核、所有用户进程、I/O 内存都共享同一个物理地址空间。不存在虚拟地址到物理地址的转换。一个指针的值就是它在物理内存中的真实地址。 无内存保护: 由于没有 MMU，处理器无法在硬件层面阻止一个进程访问另一个进程或内核的内存。任何一个有缺陷的应用程序都可以直接读写内核内存，导致整个系统崩溃。 受限的进程模型: 传统的 fork() 系统调用（它依赖于写时复制技术，而这又...

[TOC] 介绍drivers/base/class.c 是Linux内核设备模型中一个至关重要的部分，它实现了类（Class）的概念。与根据物理连接对设备进行分组的总线（Bus）不同，类的作用是根据设备的功能对它们进行逻辑上的分组，并为用户空间提供一个统一、简洁的视图，同时它还是自动化创建设备文件（/dev 节点）的核心机制。 历史与背景这项技术是为了解决什么特定问题而诞生的？ 在统一设备模型出现之前，Linux系统管理面临几个难题： 设备发现困难：用户或管理员很难找到所有功能相同的设备。例如，要列出系统中所有的硬盘，需要去检查不同总线（IDE, SCSI, USB）下的设备，没有统一的入口。 静态的 /dev 目录：系统中的设备文件（如 /dev/hda, /dev/ttyS0）通常是通过一个静态的 MAKEDEV 脚本在安装时创建的。这意味着无论硬件是否存在，设备文件都在那里，这造成了 /dev 目录的臃肿和混乱。对于U盘这种即插即用设备，这种方式完全无法工作。 主/次设备号管理：驱动程序需要手动管理和分配主设备号（Major Number），容易产生冲突...

[TOC] processarch/arm/include/asm/current.h 返回__current的值,__current是一个全局变量,在arch/arm/kernel/process.c中定义 __current是一个指向当前进程的指针,在内核中,每个进程都有一个task_struct结构体,该结构体包含了该进程的所有信息 12345678910111213141516171819202122//arch/arm/kernel/process.casmlinkage struct task_struct *__current;EXPORT_SYMBOL(__current);static __always_inline __attribute_const__ struct task_struct *get_current(void){ struct task_struct *cur;#if __has_builtin(__builtin_thread_pointer) && defined(CON...

容器设备(Container Device) 聚合与管理SoC内嵌设备drivers/base/container.c 是Linux内核设备模型中的一个辅助性组件。它的核心功能是提供一个标准的机制，用于将一组逻辑上相关、但不一定在同一物理总线上的设备，聚合到一个统一的“容器设备”之下。这种机制最主要的应用场景是为复杂的片上系统（SoC）创建一个顶层设备节点，从而将构成该SoC的所有独立功能块（如I2C控制器、DMA引擎等）组织成一个清晰的层次结构。 历史与背景这项技术是为了解决什么特定问题而诞生的？ 随着嵌入式系统的发展，现代SoC集成了越来越多的功能单元。在Linux设备模型中，这些单元通常被表示为独立的平台设备（platform_device）。这导致了一个问题： 缺乏层次结构：在sysfs的设备树（/sys/devices）中，一个SoC上的所有平台设备可能都以扁平的方式挂载在 platform 总线下，无法直观地体现出它们都属于同一个物理芯片。 管理困难：当需要对整个SoC进行统一操作时（例如，作为一个整体进行电源管理或状态查询），缺乏一个代表SoC本身的顶层设备节点，...