数据组织方式​

Linux的hwmon子系统将所有硬件传感器（温度、风扇、电压等）以​​文件形式​​暴露在/sys/class/hwmon/目录下，每个传感器设备对应一个hwmonX目录（如hwmon0、hwmon7等）。
每个目录中包含以下关键文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

ls -alh  /sys/class/hwmon/hwmon*/name
cat /sys/class/hwmon/hwmon*/name

ls -alh  /sys/class/hwmon/hwmon*/*label
cat  /sys/class/hwmon/hwmon*/*label


(base) john@john-HLYL-WXX9:/sys/class/hwmon/hwmon4$ ls -alh  /sys/class/hwmon/hwmon*/name
-r--r--r-- 1 root root 4.0K  4月 20 15:55 /sys/class/hwmon/hwmon0/name
-r--r--r-- 1 root root 4.0K  4月 20 15:55 /sys/class/hwmon/hwmon1/name
-r--r--r-- 1 root root 4.0K  4月 20 15:55 /sys/class/hwmon/hwmon2/name
-r--r--r-- 1 root root 4.0K  4月 20 15:55 /sys/class/hwmon/hwmon3/name
-r--r--r-- 1 root root 4.0K  4月 20 15:55 /sys/class/hwmon/hwmon4/name
-r--r--r-- 1 root root 4.0K  4月 20 15:55 /sys/class/hwmon/hwmon5/name
(base) john@john-HLYL-WXX9:/sys/class/hwmon/hwmon4$ cat /sys/class/hwmon/hwmon*/name
ACAD
BAT1
nvme
k10temp
amdgpu
hidpp_battery_0

(base) john@john-HLYL-WXX9:/sys/class/hwmon/hwmon4$ ls -alh  /sys/class/hwmon/hwmon*/*label
-r--r--r-- 1 root root 4.0K  4月 20 15:55 /sys/class/hwmon/hwmon2/temp1_label
-r--r--r-- 1 root root 4.0K  4月 20 15:55 /sys/class/hwmon/hwmon2/temp2_label
-r--r--r-- 1 root root 4.0K  4月 20 15:55 /sys/class/hwmon/hwmon2/temp3_label
-r--r--r-- 1 root root 4.0K  4月 20 15:55 /sys/class/hwmon/hwmon3/temp1_label
-r--r--r-- 1 root root 4.0K  4月 20 15:55 /sys/class/hwmon/hwmon4/freq1_label
-r--r--r-- 1 root root 4.0K  4月 20 15:55 /sys/class/hwmon/hwmon4/in0_label
-r--r--r-- 1 root root 4.0K  4月 20 15:55 /sys/class/hwmon/hwmon4/in1_label
-r--r--r-- 1 root root 4.0K  4月 20 15:55 /sys/class/hwmon/hwmon4/power1_label
-r--r--r-- 1 root root 4.0K  4月 20 15:55 /sys/class/hwmon/hwmon4/temp1_label
(base) john@john-HLYL-WXX9:/sys/class/hwmon/hwmon4$ cat  /sys/class/hwmon/hwmon*/*label
Composite
Sensor 1
Sensor 2
Tctl
sclk
vddgfx
vddnb
PPT
edge
(base) john@john-HLYL-WXX9:/sys/class/hwmon/hwmon4$

温度数据有哪些

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

综合命令：
ls /sys/class/hwmon/hwmon*/ | grep -i "temp"
cat  /sys/class/hwmon/hwmon*/temp*


(base) john@john-HLYL-WXX9:/sys/class/hwmon/hwmon4$ ls /sys/class/hwmon/hwmon*/ | grep -i "temp"
temp1_alarm
temp1_crit
temp1_input
temp1_label
temp1_max
temp1_min
temp2_input
temp2_label
temp2_max
temp2_min
temp3_input
temp3_label
temp3_max
temp3_min
temp1_input
temp1_label
temp1_input
temp1_label
(base) john@john-HLYL-WXX9:/sys/class/hwmon/hwmon4$ cat  /sys/class/hwmon/hwmon*/temp*
0
84850
43850
Composite
83850
-273150
43850
Sensor 1
65261850
-273150
40850
Sensor 2
65261850
-273150
41000
Tctl
40000
edge
(base) john@john-HLYL-WXX9:/sys/class/hwmon/hwmon4$

参考

Linux hwmon子系统分析之一 系统框架说明：https://blog.csdn.net/lickylin/article/details/106449262
Linux hwmon 子系统分析之三 新版本hwmon子系统说明；https://blog.csdn.net/lickylin/article/details/106449418

在电子工程中，SCH图（原理图）和PCB（印刷电路板布局）是设计过程中两个重要的部分，它们各自承担不同的功能和作用。以下是它们之间的主要区别和侧重点：

1. 定义与功能

• SCH图（原理图）：

  • 定义：原理图是电子电路的图形表示，显示了电路中各个组件的连接关系。
  • 功能：用于描述电路的逻辑和功能，包含电路元件（如电阻、电容、IC等）及其引脚连接，同时显示信号流向和电气特性。
  • 侧重：重点在于电路的功能和信号的流动，不涉及物理尺寸和位置。

• PCB（印刷电路板布局）：

  • 定义：PCB 是将电路设计转化为实际电路板的布局，包含元件的物理位置、连接线和电源层等信息。
  • 功能：用于制造实际的电路板，最终实现电路的物理实现，确保电气连接和机械稳定性。
  • 侧重：重点在于物理布局、信号完整性、散热、制造可行性等。

2. 内容与细节

• SCH图：

  • 包含电路元件符号（如电阻、电容、IC的符号）。
  • 显示逻辑连接关系（如电源、地线、信号线）。
  • 不涉及物理尺寸、元件位置、布线宽度等细节。
  • 通常会包含一些注释、参数和电气特性说明。

• PCB：

  • 包含元件的真实形状、尺寸和引脚布局（如元件封装）。
  • 显示电路板的层次结构（如电源层、信号层、接地层）。
  • 包含布线信息（如走线宽度、走线间距）和焊盘信息。
  • 可能包括标识、丝印层、测试点等额外信息。

3. 设计流程中的位置

• 设计流程：
  • 通常，设计流程是先绘制原理图（SCH图），然后基于原理图生成PCB布局。
  • 原理图完成后，通过电子设计自动化（EDA）工具进行元件布局和布线，最终生成PCB设计。

4. 工具与软件

• SCH图设计：常用软件包括 Altium Designer、Eagle、OrCAD、KiCAD 等。
• PCB设计：同样的软件也可以用于PCB设计，但在布局和布线的细节上会有所不同。

总结

• SCH图 侧重于电路的功能和逻辑连接，是设计电子电路的基础。
• PCB 侧重于实际的物理布局和制造，是将原理图转化为可实际使用的电路板的步骤。

这两者是互补的，原理图为PCB设计提供必要的逻辑基础，而PCB设计则将这些逻辑转化为实际的硬件实施。

som核心板的接口类型和定义(长什么样，一般包含哪些必须信息)

在设计和使用系统级封装（SoM，System on Module）核心板时，接口类型和定义文档是非常重要的，它帮助工程师理解各个接口的功能、连接方式及其用法。以下是SoM核心板接口类型和定义的常见内容，以及文档通常包含的信息。

1. 接口类型

SoM核心板通常会包含多种接口，以下是一些常见的接口类型：

• 电源接口：

  • 定义电源输入的电压和极性。
  • 可能包括电源管理功能，如电源开关、稳压器等。

• 数据接口：

  • 串行接口（UART、SPI、I2C）：
    • 用于串行通讯的接口，定义数据传输速率、协议和引脚配置。
  • USB接口：
    • USB Host或Device接口，定义USB版本（如USB 2.0、USB 3.0），以及电源和数据引脚的配置。
  • 网络接口（Ethernet、Wi-Fi）：
    • 定义网络连接的接口，包括以太网接口、Wi-Fi模块等。

• 视频接口：

  • HDMI、DisplayPort、LVDS等视频输出接口，定义视频信号及其质量要求。

• 音频接口：

  • 定义音频输入/输出接口，如音频插孔、I2S接口等。

• GPIO接口：

  • 通用输入输出接口，定义每个引脚的功能，如输入、输出、PWM等。

• 存储接口：

  • SD卡、eMMC、NAND等存储接口，定义存储介质的连接方式和协议。

2. 文档内容

SoM核心板的接口定义文档通常包括以下内容：

• 封面：

  • 文档标题、版本号、日期和作者信息。

• 目录：

  • 列出文档中各部分的目录和页码。

• 引言：

  • 简要介绍SoM核心板的功能和用途。

• 接口概述：

  • 总体描述所有接口的类型与功能。

• 接口详细定义：

  • 电源接口：
    • 接口引脚定义、输入电压范围、最大电流、连接方式等。
  • 数据接口：
    • 每种数据接口的引脚定义、信号描述、协议细节和时序要求。
  • 视频和音频接口：
    • 接口类型、引脚功能、信号标准等。
  • GPIO接口：
    • 每个GPIO引脚的功能、配置及电气特性。
  • 存储接口：
    • 存储设备类型、连接引脚及协议。

• 引脚分配图：

  • 图示化的引脚定义，通常包括所有接口，引脚编号，功能标记等。

• 机械与电气特性：

  • 物理尺寸、连接器类型、引脚间距等信息。

• 测试点和调试信息：

  • 提供调试和测试所需的特殊引脚定义和说明。

• 使用注意事项：

  • 对接口使用的一些建议和注意事项，例如最大负载、接地要求等。

• 附录：

  • 相关参考文献、标准、术语表等。

文档示例

一个SoM核心板的接口定义文档可能会按照以下结构组织：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

SoM核心板接口定义文档

版本：1.0
日期：2024年11月
作者：XXX

目录
1. 引言
2. 接口概述
3. 接口详细定义
   3.1 电源接口
   3.2 数据接口
       3.2.1 UART
       3.2.2 SPI
       3.2.3 I2C
   3.3 视频接口
   3.4 音频接口
   3.5 GPIO接口
   3.6 存储接口
4. 引脚分配图
5. 机械与电气特性
6. 测试点和调试信息
7. 使用注意事项
8. 附录

SoM核心板的接口定义文档是了解和使用该模块的重要资料，包含了电源、数据、视频、音频、GPIO和存储接口的详细定义，并提供了图示和电气特性信息。这些信息能够帮助开发人员正确连接和使用SoM核心板，确保系统的正常运行。

芯片功能模块(外设接口)解释

用于与外部设备或其他芯片进行通信或实现特定功能。具体来说：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

SPI（Serial Peripheral Interface）：用于与外围设备进行高速通信。  
Nand：NAND Flash接口，用于连接NAND闪存。  
I2C（Inter-Integrated Circuit）：用于连接低速外设。  
LCD：液晶显示屏接口，用于驱动显示屏。  
HDMI：高清多媒体接口，用于传输音视频信号。 
SDIO 3.0：用于连接SD卡或其他SDIO设备。(sd卡)   
UART（Universal Asynchronous Receiver/Transmitter）：用于串行通信。  
PCIe x2（Peripheral Component Interconnect Express）：高速接口，用于连接外部设备。  
USB 2.0：通用串行总线接口，用于连接USB设备。  
ISP（Image Signal Processor）：图像信号处理器，用于处理图像数据（一般返回原始yuv，rgb等数据，非编码数据）。  
Audio Codec：音频编解码器，用于处理音频信号。  

IR（Infrared）通常指**红外接口**，用于红外通信；  
PMW（Pulse Width Modulation）是**脉宽调制**，常用于控制电机或调节LED亮度等。它们与上述外设接口一起，构成了芯片的多样化功能模块。

这些模块共同构成了SoC的外设接口或功能单元，使芯片能够与外部设备交互并实现多种功能。

uart,jtag区别

UART 是一种简单的串行通信接口，适合设备间的数据传输。
JTAG 是一种复杂的调试和测试接口，主要用于芯片开发和硬件调试。
两者在功能、复杂度和应用场景上有显著区别，通常不会互相替代。

芯片逻辑框图

LSADCs（Low-Speed Analog-to-Digital Converters，低速模数转换器）：
功能：将模拟信号转换为数字信号。
应用场景：适用于对采样速度要求不高的场景，如温度、压力等慢变信号的采集。

SSPs（Synchronous Serial Ports，同步串行端口）：
功能：实现同步串行通信，支持 SPI、I2C 等协议。
应用场景：用于与外部设备进行数据传输，如传感器、存储器等。

GMAC（Gigabit Media Access Control，千兆媒体访问控制）：
功能：控制以太网数据传输，确保数据在网络中的可靠传输。
应用场景：用于支持千兆以太网通信的芯片中，如网络处理器、SoC 等。

GPU@MP2：
GPU（Graphics Processing Unit）：图形处理单元，用于处理图形和图像相关的计算任务。
MP2（Multi-Processor 2）：可能指双核或多核处理器架构。
整体表示一个双核或多核的图形处理单元。

DSP/NNIE/IVE：
DSP（Digital Signal Processor）：数字信号处理器，用于处理音频、视频等信号。
NNIE（Neural Network Inference Engine）：神经网络推理引擎，用于加速深度学习模型的推理任务。
IVE（Intelligent Video Engine）：智能视频引擎，用于视频分析和处理（如运动检测、目标跟踪等）。

VPSS+VGS+GDC+AVSP：
VPSS（Video Processing Sub-System）：视频处理子系统，负责视频的输入、输出和预处理。
VGS（Video Graphics System）：视频图形系统，用于图形叠加和显示。
GDC（Geometric Distortion Correction）：几何失真校正，用于校正镜头畸变。
AVSP（Advanced Video Signal Processing）：高级视频信号处理，可能包括降噪、增强等功能。

ISP(3a/WDR)：
ISP（Image Signal Processor）：图像信号处理器，用于处理从摄像头传感器捕获的原始图像数据。
3A（Auto Exposure/Auto Focus/Auto White Balance）：自动曝光、自动对焦、自动白平衡。
WDR（Wide Dynamic Range）：宽动态范围，用于处理高对比度场景。

HDMI/MIPI/LCD：
HDMI（High-Definition Multimedia Interface）：高清多媒体接口，用于传输高清视频和音频信号。
MIPI（Mobile Industry Processor Interface）：移动行业处理器接口，用于连接摄像头、显示屏等。
LCD（Liquid Crystal Display）：液晶显示屏。

MIPI/LVDS/hIsPI：
LVDS（Low-Voltage Differential Signaling）：低压差分信号，用于高速数据传输。
hIsPI（High-Speed Serial Pixel Interface）：高速串行像素接口，用于传输图像数据。

slvs-EC：
SLVS-EC（Scalable Low-Voltage Signaling with Embedded Clock）：一种低功耗、高速的串行接口，用于传输图像和视频数据，通常用于摄像头模块。

接口和协议

I2C通信：I2C接口定义了SDA（数据线）和SCL（时钟线）的物理连接，而I2C协议定义了主从设备之间的数据传输规则。
以太网：以太网接口（如RJ45）提供了物理连接，而以太网协议定义了数据包的格式和传输规则。
接口和协议在硬件通信中密不可分，接口是协议的物理基础，而协议是接口功能的逻辑实现。理解它们的区别和联系对于设计和分析硬件系统非常重要。

1.4启动和升级方式

1.5 地址空间映射

这个是干嘛用的？（为何需要些这个，做什么的时候用户需要了解，查阅这部分信息）

在SOC（System on Chip，片上系统）用户手册中，这样的地址表单主要是用来描述SOC芯片中各个功能模块的寄存器地址范围及其用途。以下是它的作用和用户需要了解的原因：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

1. **寄存器地址映射**
- SOC芯片中有许多功能模块（如VGS1、VEDU0、JPGE等），每个模块都有其对应的寄存器，用于控制和配置模块的行为。
- 地址表单清晰地划分了每个模块的寄存器在内存地址空间中的范围。例如：
    - `0x0_1130_0000` 到 `0x0_1130_FFFF` 是 VEDU0 寄存器的地址范围。
    - `0x0_1132_0000` 到 `0x0_1132_FFFF` 是 JPGE 寄存器的地址范围。
- 这种映射使得开发者能够准确地访问和控制这些寄存器。

2. **保留区域**
- 地址表单中标注为“保留”的区域表示这些地址范围目前未分配给任何功能模块，可能是为未来扩展或特定用途预留的。
- 用户需要避免访问这些区域，以防止意外行为或错误。

3. **寄存器大小**
- 地址表单中通常还会标注每个模块的寄存器大小（如64KB、128KB）。这有助于开发者了解每个模块的寄存器空间大小，从而合理分配资源。
- 
4. **硬件编程和调试**
- 在开发嵌入式系统或驱动程序时，开发者需要直接与硬件寄存器交互，以配置和控制SOC的功能模块。
- 例如，如果开发者需要配置JPGE模块（JPEG编解码器），他们需要查阅地址表单，找到JPGE寄存器的地址范围，然后根据手册中的寄存器描述进行编程。

比如，0x0_1132_0000 0x0_1132_FFFF JPGE 寄存器。 64KB 为例
是否意味着最大处理jpeg图片为64kb？而且寄存器控制硬件行为时，需要精准的知道地址，而非这么庞大的地址范围。怎么理解呢？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

从以下几个方面来理解：
1. **最大处理 JPEG 图片的大小**
- 这个地址范围的大小（64KB）并不直接决定 JPEG 图片的最大处理大小。JPEG 图片的处理能力通常由硬件解码器的设计、内存带宽、处理器的性能等因素决定。
- 如果这个地址范围是用于存储 JPEG 解码器的寄存器或数据缓冲区，那么 64KB 可能只是用来存放解码过程中的中间数据，而不是整个 JPEG 图片。
- 实际的 JPEG 图片可能远远大于 64KB，解码器通常会分块处理图片数据，而不是一次性加载整个图片。

2. **寄存器控制硬件行为**
- 寄存器是硬件设备中用于控制和配置的小块内存区域。每个寄存器通常只有几字节大小，但它们的作用非常重要。
- 你提到的地址范围（如 `0x0_1132_0000` 到 `0x0_1132_FFFF`）可能是一个寄存器组（Register Bank）的地址范围，而不是单个寄存器。寄存器组中可能包含多个寄存器，每个寄存器有特定的地址偏移。
- 硬件驱动程序或固件在操作寄存器时，需要精确地知道每个寄存器的地址偏移。例如，如果寄存器组的基地址是 `0x0_1132_0000`，那么某个特定的寄存器可能是基地址加上一个偏移量，比如 `0x0_1132_0004`。

3. **地址范围的庞大性**
- 地址范围看起来很大，但实际上它只是硬件地址空间的一部分。硬件地址空间通常被划分为不同的区域，每个区域对应不同的硬件功能（如内存、寄存器、外设等）。
- 在设计硬件时，地址范围的大小是为了预留足够的空间，以便未来扩展或支持更多的功能。实际使用的寄存器可能只占用了地址范围的一小部分。

总结
- 64KB 的地址范围并不直接限制 JPEG 图片的处理大小，它可能只是用于存放解码过程中的数据或寄存器组。
- 寄存器控制硬件时需要精确的地址，但这些地址通常是基地址加上一个小的偏移量，而不是整个庞大的地址范围。
- 地址范围的设计是为了预留空间和支持灵活性，实际使用的寄存器可能只占其中的一小部分。

2硬件特性

2.1封装(各角度视图)和管脚分布

2.2焊接工艺，潮敏

2.5电气性能,典型场景和功耗信息,

2.6接口时序

3系统

3.1复位

3.2时钟

3.3处理器子系统

3.4中断系统

3.5 系统控制器

4存储器接口

todo找个简单模块看下主要讲的啥

百度文库：
https://wenku.baidu.com/view/0ffea690ba0d4a7302763a7c.html?_wkts_=1740049575128&bdQuery=Hi3559AV100R001+%E4%BA%A4%E4%BB%98%E4%BB%B6%E6%B8%85%E5%8D%95.xlsx

Hi3559AV100ES 芯片硬件资料分享：助力高效硬件设计：https://blog.csdn.net/gitblog_09782/article/details/143297828

老工程师经验分享：一套完整的硬件电路设计该怎么做？：Site Unreachable

EVT,DVT,PVT

EVT、DVT和PVT是产品开发流程中的关键验证阶段，分别对应工程验证、设计验证和生产验证。以下是它们的详细解析：

​1. EVT（Engineering Verification Test，工程验证测试）​

• ​目标：验证产品的核心功能与工程设计的可行性。
• ​阶段特点：
  • ​早期原型：制作少量工程样机（可能手工组装），测试基本功能。
  • ​问题排查：发现并修复重大设计缺陷（如电路设计、结构问题）。
  • ​快速迭代：设计频繁调整，可能进行多轮测试。
• ​测试内容：
  • 功能性测试（如硬件通电、软件基础功能）。
  • 初步环境测试（温湿度、振动等）。
  • 兼容性与安全性初步评估。

​2. DVT（Design Verification Test，设计验证测试）​

• ​目标：全面验证产品设计是否符合规格与用户需求。
• ​阶段特点：
  • ​接近量产的设计：样机采用量产材料与工艺，外观和结构定型。
  • ​严格验证：通过大量测试确保设计可靠性。
  • ​认证准备：启动法规认证（如CE、FCC）。
• ​测试内容：
  • 性能参数全面测试（如电池续航、信号强度）。
  • 环境与寿命测试（高低温循环、跌落测试）。
  • 用户场景模拟（实际使用条件下的稳定性）。

​3. PVT（Production Verification Test，生产验证测试）​

• ​目标：验证生产工艺的稳定性和量产可行性。
• ​阶段特点：
  • ​试量产：小批量生产（数百至千台），使用正式生产线。
  • ​流程优化：解决装配效率、良率问题，优化质量控制。
  • ​供应链验证：确保零部件供应稳定，供应商协作顺畅。
• ​测试内容：
  • 生产线压力测试（如产能、故障率统计）。
  • 产品一致性检查（尺寸、功能批次差异）。
  • 包装与物流测试（运输损耗评估）。

​阶段对比与关联

​典型问题与过渡

• ​EVT→DVT：需解决所有关键设计问题，如散热不足需重新设计散热模块。
• ​DVT→PVT：完成所有设计冻结，确保生产文档（如BOM、工艺图）完备。
• ​PVT→MP（量产）​：通过良率目标（如95%以上），方可进入大规模生产。

pin,pad,ball,bump

DIE是一种半导体加工工艺，也就是说DIE完了以后直接拿出来的芯片叫裸DIE，是不能直接使用的，没有引脚，没有散热片。
Bumping?是指将凸点（Bump）添加到芯片的焊盘上，通常用于倒装芯片（Flip-chip）封装。在芯片制造过程中，Bumping是一个重要的步骤，它通过在芯片的焊盘上生长凸点，实现芯片与封装基板之间的电气连接。这些凸点通常由金属材料制成，如金、锡铅或无铅材料等?
在Bumping之后，裸die（裸芯片）需要进行封装。封装是将裸芯片放入一个保护外壳中，以保护芯片并使其能够与其他电子组件连接。常见的封装技术包括引线键合和凸点连接等?
具体到倒装芯片封装，Bumping后的裸die会通过凸点与封装基板进行连接，从而实现芯片的功能和性能?

pin pad ball bump区别
pin一般指封装上的引脚
pad一般指die上面的金属开窗，可以通过金线与pin相连
ball一般指bga封装基板下面的锡球
bump一般指pad上面长出来的锡球

PIN指芯片封装好后的管脚，即用户看到的管脚；
PAD是硅片的管脚，是封装在芯片内部的，用户看不到。
PAD到PIN之间还有一段导线连接的。
芯片(Chip)可直接在电路板面上进行反扣焊接(Filp Chip on Board)，以完成芯片与电路板的组装互连。这种反扣式的COB覆晶法，可以省掉芯片许多先行封装 (Package) 的制程及成本。但其与板面之各接点，除PCB需先备妥对应之焊接基地外，芯片本身之外围各对应点，也须先做上各种圆形或方形的微型”焊锡凸块”，当其凸块只安置在”芯片”四周外围时称为FCOB，若芯片全表面各处都有凸块皆布时，则其覆晶反扣焊法特称为”Controlled Collapsed Chip Connection”简称C4法。

pin pad ball bump区别：https://blog.csdn.net/weixin_50518899/article/details/139361566
芯片资料中的pad,pin,bump:https://blog.csdn.net/qq_34110120/article/details/82690884/

原理图,NETLIST,PCB,BOM（物料清单）

硬件电路设计的三个部分：原理图、PCB和物料清单（BOM）表
原理图设计，其实就是将前面的思路转化为电路原理图，它很像我们教科书上的电路图。
pcb涉及到实际的电路板，它根据原理图转化而来的netlist(网表是沟通原理图和pcb之间的桥梁)，而将具体的元器件的封装放置(布局)在电路板上，然后根据飞线(也叫预拉线)连接其电信号(布线)。完成了pcb布局布线后，要用到哪些元器件应该有所归纳，所以我们将用到BOM表。
netlist是原理图与pcb之间的桥梁。原理图是我们能认知的形式，电脑要将其转化为pcb，就必须将原理图转化它认识的形式netlist，然后再处理、转化为pcb。

layout,bom,钢网

Layout（PCB设计）​​

​​Layout​​ 是指 ​​PCB（印刷电路板）的物理设计​​，包括元件布局、走线、层叠结构等。通常使用EDA工具（如Altium Designer、Cadence Allegro、KiCad）完成。
​​作用​​

1
2

决定电路板的 ​​电气性能、信号完整性、散热、EMC（电磁兼容性）​​。 
生成 ​​Gerber文件​​（用于PCB生产）和 ​​坐标文件​​（用于SMT贴片）。

​​关键输出​​

1
2
3

​​Gerber文件​​（各层铜箔、丝印、阻焊等）  
​​钻孔文件​​（Drill File）  
​​Pick & Place文件​​（元件坐标和角度）

​

2. BOM（物料清单，Bill of Materials）​​

​​BOM​​ 是 ​​所有元器件的详细清单​​，包括型号、数量、封装、供应商等信息。
通常由工程师在PCB设计完成后整理。
​​作用​​

1
2

指导采购部门购买元器件。
确保SMT贴片时使用正确的元件。

​​关键内容​

钢网（Stencil）​​

​​钢网​​ 是一块 ​​带有镂空图案的不锈钢薄片​​，用于在PCB焊盘上 ​​印刷锡膏​​。
根据PCB的 ​​Gerber文件（通常是阻焊层或焊盘层）​​ 制作。
​​作用​​

1
2

在SMT贴片前，将锡膏精准涂覆到焊盘上。
影响焊接质量（如少锡、连锡等问题）。

​​关键参数​​

三者的区别与联系​

文件/etc/passwd 和/etc/shadow，内容解析

在Linux系统中，/etc/passwd和/etc/shadow是存储用户账户信息的核心文件，二者配合实现用户认证。以下是它们的详细解析：

uboot的bootargs，bootcmd区别

协同工作流程​​
​​U-Boot启动​​ → 执行bootcmd中的命令
（例如：从网络加载内核镜像zImage和设备树dtb到内存）
​​加载内核​​ → 通过bootm/bootz命令启动内核
​​参数传递​​ → 将bootargs的内容传递给内核
​​内核初始化​​ → 根据bootargs配置硬件和挂载根文件系统

打印所有环境变量

printenv

单独查看

printenv bootargs
printenv bootcmd

SDK 安装及升级使用说明

sudo dpkg-reconfigure dash，这个命令什么意思

sudo dpkg-reconfigure dash 是一个用于 ​​重新配置系统默认 /bin/sh 解释器​​ 的 Debian/Ubuntu 系统命令。它的作用和工作原理如下：
安装系统时​​
Debian/Ubuntu 安装程序会默认将 /bin/sh 链接到 dash（而非 bash），因为：

1
2

dash 更快​​：启动速度快、内存占用低（适合系统初始化阶段）。  
​​dash 更严格​​：遵循 POSIX 标准，避免脚本中依赖 bash 特有语法。

​​

1,关系表

2, 协作关系（启动流程）​

1

系统上电 → U-Boot → 加载内核和设备树 → 内核启动 → 解析设备树 → 挂载 rootfs → 启动用户空间（如 systemd）

3,关键步骤详解​

1. ​U-Boot 阶段

• 初始化 CPU、内存、存储设备（如 eMMC、SD 卡）、串口等基础硬件。
• 从存储设备（或网络）加载 ​内核镜像（Image）​ 和 ​设备树二进制（.dtb）​ 到内存。
• 通过 bootm 或 bootz 命令启动内核，并传递设备树的内存地址。

2. ​Linux 内核阶段

• 解析设备树（.dtb），识别 CPU 架构、外设地址、中断号等硬件信息。
• 初始化驱动（如网卡、存储控制器），挂载 ​rootfs​（从硬盘、网络或内存加载）。
• 启动第一个用户空间进程（如 init 或 systemd）。

3. ​rootfs 阶段

• 提供用户空间程序运行环境（如 bash、systemd、应用程序）。
• 包含动态链接库（/lib）、配置文件（/etc）、设备节点（/dev）等。

rootfs生成脚本(mmdebstrap,chroot)

1
2
3
4
5
6
7
8

mmdebstrap --architectures=riscv64 \
      --include="$PACKAGE_LIST" \
      --skip check/empty \
      sid $1 \  # $1参数为构建目标目录
      "deb [trusted=yes] https://mirror.iscas.ac.cn/rockos/20250130/rockos-gles/ rockos-gles main" \
      "deb [trusted=yes] https://mirror.iscas.ac.cn/rockos/20250130/rockos-kernels/ rockos-kernels main" \
      "deb [trusted=yes] https://mirror.iscas.ac.cn/rockos/20250130/rockos-addons/ rockos-addons main" \
      "deb [trusted=yes] https://mirror.iscas.ac.cn/rockos/20250130/rockos-base/ sid main contrib non-free non-free-firmware"

问题

1
2
3
4
5
6
7
8
9

这部分代码：
    # 挂载系统目录（构建chroot环境）
    mount -t proc /proc "$CHROOT_TARGET"/proc    # 进程信息
    mount --bind /sys "$CHROOT_TARGET"/sys       # 系统信息
    mount --bind /run "$CHROOT_TARGET"/run       # 运行时文件
    mount --bind /dev "$CHROOT_TARGET"/dev       # 设备文件
    mount --bind /dev/pts "$CHROOT_TARGET"/dev/pts # 伪终端

将宿主机的的sys,run,dev等挂载到"$CHROOT_TARGET"/sys    （chroot的类虚拟机环境）不会有问题么？一个x86架构，一个riscv架构。，这么做为啥不报错，以及为何这么做（这么做目的时什么）

1. 为什么不报错？—— 内核接口的架构无关性

​虚拟文件系统的本质

• /proc、/sys、dev 等目录是 Linux 内核暴露给用户空间的 ​虚拟文件系统（Virtual File Systems）​：
  • /proc: 提供进程、系统状态等运行时信息（如 cpuinfo）。
  • /sys: 暴露硬件设备、驱动、内核参数等层级化配置。
  • /dev: 设备节点文件（如 /dev/sda）。
• ​这些文件系统的内容由内核动态生成，与用户空间的 CPU 架构无关。例如：
  • cat /proc/cpuinfo 在 x86 和 RISC-V 上都会返回当前运行内核的 CPU 信息。
  • /sys/devices 展示的是内核管理的设备树，与用户空间程序架构无关。
• 架构无感知性*
• ​挂载操作只是映射内核接口，不涉及任何二进制代码执行。
• 即使宿主架构（x86）和目标架构（RISC-V）不同，内核仍能正确生成这些虚拟文件系统的内容，因为这些内容由宿主机的内核管理。

​2. 为什么需要挂载？—— Chroot 环境的完整性

构建根文件系统的需求

在 chroot 环境中执行操作（如安装软件、配置服务）时，需要：

1. ​设备访问：如挂载 /dev 以便在 chroot 内创建设备节点。
2. ​系统信息查询：如通过 /proc 获取进程信息。
3. ​依赖内核功能：如通过 /sys 配置硬件参数。

跨架构构建的特殊性

• 虽然宿主架构和目标架构不同，但 ​所有用户空间操作（如 apt install）实际由宿主机的内核通过二进制翻译（如 QEMU）执行：

  1 2 3

  # 宿主机的内核通过 binfmt_misc 识别 RISC-V 二进制 # 并调用 qemu-riscv64-static 解释执行 $ sudo update-binfmts --enable qemu-riscv64

• 挂载宿主机的 /proc、/sys 到 chroot 环境后：

  • ​用户空间程序（RISC-V）通过 QEMU 翻译执行。
  • ​内核接口（如 sysfs）仍由宿主机内核提供，但用户空间程序会按 RISC-V 的预期解析这些接口。

​3. 潜在问题与规避

​架构相关路径的冲突

极少数情况下，内核接口的路径可能因架构不同产生差异，例如：

• ​设备树路径：RISC-V 设备树路径 /sys/firmware/devicetree/base 可能与 x86 不同。
• ​CPU 拓扑信息：/sys/devices/system/cpu 的结构可能因架构而异。

​解决方案

• ​动态生成配置：在 chroot 环境内通过脚本动态生成架构相关配置。
• ​避免硬编码路径：使用抽象接口（如 lscpu 替代直接读取 /proc/cpuinfo）。
• ​隔离关键目录：在构建完成后卸载宿主机的虚拟文件系统，确保目标系统首次启动时重新挂载自身的虚拟文件系统。

​4. 操作的目的总结

1
2
3
4
5
6

宿主机 (x86_64)                          chroot 环境 (riscv64)
+-----------------------------------+     +------------------------------+
| 1. 挂载宿主机的 /proc, /sys, /dev      | → | 提供内核接口，不依赖架构       |
| 2. 通过 QEMU 解释执行 RISC-V 程序 | → | apt install 安装 RISC-V 软件包 |
| 3. 卸载宿主机的虚拟文件系统        | ← | 生成完整的 riscv64 根文件系统  |
+-----------------------------------+     +------------------------------+

2、环境变量操作命令

环境变量的操作涉及到两个命令：setenv和saveenv。
setenv命令用于创建、修改环境变量的值，也可以用于删除环境变量；
saveenv命令用于保存修改后的环境变量。
一般环境变量是存放在外部flash中的，uboot启动的时候会将环境变量从flash读取到DRAM中，所以使用命令setenv修改的是DRAM中的环境变量值，修改后需使用saveenv命令将环境变量保存到flash中。
场景​​：误修改 bootcmd 导致无法启动，需恢复默认环境。

1
2
3
4

# 进入 U-Boot 命令行
=> env default -a    # 恢复所有变量
=> saveenv           # 保存到存储设备
=> reset             # 重启（可选）

3、内存操作命令

内存操作命令就是用于直接对 DRAM 进行读写操作的，常用的内存操作命令有 md、 nm、mm、 mw、 cp 和 cmp。

4、网络操作命令

uboot是支持网口的，在移植uboot的时候都要调通网络的功能，因为在移植linux内核的时候需要用到uboot的网络功能做调试。uboot支持的网络相关的命令有：dhcp、ping、nfs、ftfpboot。
使用网络调试前需先设置好下列几个环境变量。

环境变量	描述
ipaddr	开发板的IP地址，可以通过dhcp命令从路由器获取IP
ethaddr	开发板的MAC地址，一定要设置
gatewayip	网关地址
netmask	子网掩码
serverip	服务器IP地址，也就是ubuntu主机的IP地址，用于调试
1 2 3 4 5 6 setenv ipaddr 192.168.1.50 setenv ethaddr b8:ae:1d:01:00:00 setenv gatewayip 192.168.1.1 setenv netmask 255.255.255.0 setenv serverip 192.168.1.253 saveenv

5、EMMC和SD卡操作命令

uboot支持EMMC和SD卡，提供了EMMC和SD卡的操作命令。一般认为EMMC和SD卡就是同一个东西，所以没有特殊说明，统一使用MMC来代指EMMC和SD卡。uboot中常用于操作MMC设备的命令为：mmc。

mmc是一系列的命令，后面可以跟不同的参数，输入“? mmc”即可查看mmc有关的命令。如下图所示：

mmc后面跟不同的参数可以实现不同的功能。

mmc rescan 命令
mmc rescan 命令用于扫描当前开发板上所有的 MMC 设备，包括 EMMC 和 SD 卡，输入“mmc rescan”即可。

mmc list 命令
mmc list 命令用于来查看当前开发板一共有几个 MMC 设备，输入“mmc list”

可以看出当前开发板有两个 MMC 设备： FSL_SDHC:0 (SD)和 FSL_SDHC:1 (eMMC)，这是因为我现在用的是 EMMC 版本的核心板，加上 SD 卡一共有两个 MMC 设备， FSL_SDHC:0 是 SD卡， FSL_SDHC:1(eMMC)是 EMMC，。默认会将 EMMC 设置为当前 MMC 设备，要想查看 EMMC信息，就要使用命令“mmc dev”来将 EMMC卡设置为当前的 MMC 设备

mmc dev 命令
mmc dev 命令用于切换当前 MMC 设备，使用如下命令切换到 EMMC：

mmc info 命令
mmc info 命令用于输出当前选中的 mmc info 设备的信息，输入命令“mmc info”即可，如下图所示:

从上图可以看出，当前选中的 MMC设备是 SD卡，版本为 3.0，容量为 14.8GiB(EMMC为 4GB)，速度为 50000000Hz=50MHz， 4 位宽的总线。还有一个与 mmc info 命令相同功能的命令： mmcinfo，“mmc”和“info”之间没有空格。

mmc part 命令
有时候 SD 卡或者 EMMC 会有多个分区，可以使用命令“mmc part”来查看其分区，比如查看 EMMC 的分区情况，输入如下命令,结果如下图所示:

从上图中可以看出，此时 EMMC 有两个分区，扇区 20480~ 262144 为第一个分区，扇区 282644~14987264 为第二个分区。如果 EMMC 里面烧写了 Linux 系统的话， EMMC 是有3 个分区的，第 0 个分区存放 uboot，第 1 个分区存放 Linux 镜像文件和设备树，第 2 个分区存放根文件系统。但是在图中只有两个分区，那是因为第 0 个分区没有格式化，所以识别不出来，实际上第 0 个分区是存在的。一个新的 SD 卡默认只有一个分区，那就是分区 0.

参考：
u-boot常用命令：https://blog.csdn.net/helaisun/article/details/128166820
史上最全的Uboot常用命令汇总（超全面！超详细！）收藏这一篇就够了「建议收藏」：https://cloud.tencent.cn/developer/article/2102295
U-Boot命令使用：https://blog.csdn.net/cike626/article/details/128430824
U-Boot命令之EMMC和SD卡操作命令：https://blog.csdn.net/weixin_45309916/article/details/109178989

uboot环境变量解析

样例信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

> printenv
arch=riscv
baudrate=115200
board=eic7700_d314
board_name=eic7700_d314
boot_conf_addr_r=0xc0000000
boot_conf_file=/extlinux/extlinux.conf
bootargs=root=/dev/nfs init=/linuxrc ip=dhcp rw nfsroot=10.10.192.205:/srv/nfs_server,proto=tcp,nfsvers=3,nolock console-ttyS0
bootcmd=sysboot mmc ${emmc_dev}:1 any $boot_conf_addr_r $boot_conf_file;
bootdelay=2
console=ttyS0
cpu=eic770x
emmc_dev=0
ethact=ethernet@50400000
ethaddr=8c:1f:64:13:c0:9c
fdt_addr=ed511150
fdt_addr_r=0x88000000
fdt_high=0xffffffffffffffff
fdtaddr=ed511150
fdtcontroladdr=ed511150
fdtfile=eswin/eic7700-d314.dtb
gpt_partition=gpt write mmc ${emmc_dev} $partitions
initrd_high=0xffffffffffffffff
kernel_addr_r=0x84000000
kernel_comp_addr_r=0xa0000000
kernel_comp_size=0x4000000
loadaddr=0x80200000
loadimage=dhcp 0x90000000 fitImage
nfsargs=setenv bootargs root=/dev/nfs init=/linuxrc ip=dhcp rw nfsroot=10.10.192.205:/srv/nfs_server,proto=tcp,nfsvers=3,nolock
nfsboot=echo Set nfs parameter ...;run nfsargs;run setimageload;run loadimage
partitions=name=boot,start=1MiB,size=512MiB,type=${typeid_efi},uuid=${uuid_boot};name=swap,size=4096MiB,type=${typeid_swap},uuid=${uuid_swap};name=root,size=-,type=${typeid_filesystem},uuid=${uuid_root}
preboot=setenv fdt_addr ${fdtcontroladdr};fdt addr ${fdtcontroladdr};usb start;sata init;nvme scan
pxefile_addr_r=0x88200000
ram_size=16
ramdisk_addr_r=0x88300000
scriptaddr=0x88100000
sdupdate=ext4load mmc 1:1 0x90000000 sdupdate.scr;source 0x90000000
serverip=10.10.192.205
setimageload=setenv loadimage dhcp 0x90000000 fitImage
silent=1
splashimage=0xe0000000
splashpos=1660,0
stderr=vidconsole,serial
stdin=serial,usbkbd
stdout=serial
typeid_efi=C12A7328-F81F-11D2-BA4B-00A0C93EC93B
typeid_filesystem=0FC63DAF-8483-4772-8E79-3D69D8477DE4
typeid_swap=0657FD6D-A4AB-43C4-84E5-0933C84B4F4F
usbupdate=ext4load usb 0 0x90000000 usbupdate.scr;source 0x90000000
uuid_boot=44b7cb94-f58c-4ba6-bfa4-7d2dce09a3a5
uuid_root=80a5a8e9-c744-491a-93c1-4f4194fd690a
uuid_swap=5ebcaaf0-e098-43b9-beef-1f8deedd135e
vendor=eswin

Environment size: 2020/524284 bytes

4大部分

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

1. 硬件初始化
   - 加载设备树: fdtfile=eswin/eic7700-d314.dtb
   - 初始化存储: emmc_dev=0, sata/nvme

2. 启动方式选择
   - 默认启动: bootcmd → 从 eMMC 的 extlinux 配置启动
   - NFS 启动: nfsboot → 从服务器 10.10.192.205 加载内核和根文件系统

3. 内核加载
   - 内核地址: kernel_addr_r=0x84000000
   - 设备树地址: fdt_addr_r=0x88000000

4. 根文件系统挂载
   - NFS 挂载: root=/dev/nfs, nfsroot=10.10.192.205:/srv/nfs_server
   - 本地挂载: root=UUID=80a5a8e9... (需配置 fstab)

1. 系统基础信息

2. 启动流程控制

3. 存储与分区

​4. 网络配置

6. 高级功能

设备树和驱动

设备树与驱动的联系

• 设备树为驱动提供硬件信息：

  • 驱动通过设备树获取硬件的寄存器地址、中断号、时钟等资源。
  • 设备树中的 compatible 属性用于匹配驱动和设备。

• 驱动依赖设备树：

  • 在嵌入式 Linux 中，设备树是驱动获取硬件信息的主要方式。
  • 驱动通过内核提供的 API（如 of_* 系列函数）从设备树中读取信息。

• 共同完成硬件管理：

  • 设备树描述硬件，驱动操作硬件，二者协作完成硬件的初始化和控制。

    例子_简单版

    设备树（.dts）

    1 2 3 4 5 6 7

    &i2c1 { status = "okay"; eeprom@50 { compatible = "atmel,24c02"; reg = <0x50>; }; };

    驱动（.c）

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

    #include <linux/module.h> #include <linux/i2c.h> #include <linux/of.h> static int eeprom_probe(struct i2c_client *client, const struct i2c_device_id *id) { printk("EEPROM probed!\n"); // 初始化硬件 return 0; } static int eeprom_remove(struct i2c_client *client) { printk("EEPROM removed!\n"); // 释放资源 return 0; } static const struct of_device_id eeprom_match[] = { { .compatible = "atmel,24c02" }, { } }; MODULE_DEVICE_TABLE(of, eeprom_match); static struct i2c_driver eeprom_driver = { .probe = eeprom_probe, .remove = eeprom_remove, .driver = { .name = "eeprom", .of_match_table = eeprom_match, }, }; module_i2c_driver(eeprom_driver); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Your Name"); MODULE_DESCRIPTION("EEPROM Driver");

    总结
    设备树 描述硬件信息，驱动 控制硬件设备。
    设备树通过 compatible 属性与驱动匹配，驱动通过设备树获取硬件资源。
    二者共同协作，完成硬件的初始化和操作。

    例子_复杂版

    举例子稍微复杂例子，能体现出，设备树的配置信息如何被驱动识别，解析，处理的。

这个例子将涉及一个假设的 多功能设备，它包含以下功能：
一个 I2C 接口 的传感器。
一个 GPIO 引脚 用于控制设备状态。
一个 中断引脚 用于触发事件。
设备树（.dts）
设备树描述硬件信息，包括 I2C 地址、GPIO 引脚、中断号等。

1
2
3
4
5
6
7
8
9
10
11
12
13

{
    compatible = "mycompany,myboard";
    model = "MyBoard";

    sensor: sensor@50 {
        compatible = "mycompany,my-sensor";
        reg = <0x50>; // I2C 地址
        interrupt-parent = <&gpio1>; // 中断控制器
        interrupts = <5 IRQ_TYPE_EDGE_RISING>; // GPIO1_5，上升沿触发
        vdd-supply = <&vdd_3v3>; // 电源
        gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>; // GPIO2_3，用于控制设备状态
    };
};

设备树解析
compatible：”mycompany,my-sensor”，用于匹配驱动。
reg：I2C 设备的地址为 0x50。
interrupt-parent：中断控制器是 gpio1。
interrupts：中断引脚是 gpio1 的第 5 个引脚，触发方式为上升沿。
vdd-supply：设备的电源由 vdd_3v3 提供。
gpios：设备的控制引脚是 gpio2 的第 3 个引脚，高电平有效。

驱动（.c）
驱动通过设备树获取硬件信息，并初始化设备。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108

#include <linux/module.h>
#include <linux/i2c.h>
#include <linux/gpio/consumer.h>
#include <linux/interrupt.h>
#include <linux/of.h>
#include <linux/regulator/consumer.h>

struct my_sensor_data {
    struct i2c_client *client;
    struct gpio_desc *ctrl_gpio;
    struct regulator *vdd;
    int irq;
};

static irqreturn_t my_sensor_interrupt(int irq, void *dev_id) {
    printk("Interrupt triggered!\n");
    // 处理中断事件
    return IRQ_HANDLED;
}

static int my_sensor_probe(struct i2c_client *client, const struct i2c_device_id *id) {
    struct device *dev = &client->dev;
    struct my_sensor_data *data;
    int ret;

    // 分配设备数据结构
    data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
    if (!data)
        return -ENOMEM;

    data->client = client;

    // 获取 GPIO 控制引脚
    data->ctrl_gpio = devm_gpiod_get(dev, NULL, GPIOD_OUT_LOW);
    if (IS_ERR(data->ctrl_gpio)) {
        dev_err(dev, "Failed to get control GPIO\n");
        return PTR_ERR(data->ctrl_gpio);
    }

    // 获取电源
    data->vdd = devm_regulator_get(dev, "vdd");
    if (IS_ERR(data->vdd)) {
        dev_err(dev, "Failed to get regulator\n");
        return PTR_ERR(data->vdd);
    }

    // 使能电源
    ret = regulator_enable(data->vdd);
    if (ret) {
        dev_err(dev, "Failed to enable regulator\n");
        return ret;
    }

    // 获取中断号
    data->irq = gpiod_to_irq(data->ctrl_gpio);
    if (data->irq < 0) {
        dev_err(dev, "Failed to get IRQ number\n");
        return data->irq;
    }

    // 注册中断处理函数
    ret = devm_request_irq(dev, data->irq, my_sensor_interrupt,
                           IRQF_TRIGGER_RISING, "my-sensor", data);
    if (ret) {
        dev_err(dev, "Failed to request IRQ\n");
        return ret;
    }

    // 初始化设备
    gpiod_set_value(data->ctrl_gpio, 1); // 设置 GPIO 为高电平
    printk("Sensor initialized!\n");

    return 0;
}

static int my_sensor_remove(struct i2c_client *client) {
    struct my_sensor_data *data = i2c_get_clientdata(client);

    // 关闭电源
    regulator_disable(data->vdd);

    // 设置 GPIO 为低电平
    gpiod_set_value(data->ctrl_gpio, 0);

    printk("Sensor removed!\n");
    return 0;
}

static const struct of_device_id my_sensor_of_match[] = {
    { .compatible = "mycompany,my-sensor" },
    { }
};
MODULE_DEVICE_TABLE(of, my_sensor_of_match);

static struct i2c_driver my_sensor_driver = {
    .probe = my_sensor_probe,
    .remove = my_sensor_remove,
    .driver = {
        .name = "my-sensor",
        .of_match_table = my_sensor_of_match,
    },
};

module_i2c_driver(my_sensor_driver);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Your Name");
MODULE_DESCRIPTION("My Sensor Driver");

驱动解析设备树的过程
匹配设备：
驱动通过 of_device_id 中的 compatible 属性与设备树中的节点匹配。
匹配成功后，调用 probe 函数。

获取 GPIO：
使用 devm_gpiod_get 从设备树中获取 GPIO 控制引脚。

获取电源：
使用 devm_regulator_get 从设备树中获取电源。

获取中断：
使用 gpiod_to_irq 将 GPIO 引脚转换为中断号。
使用 devm_request_irq 注册中断处理函数。

初始化设备：
设置 GPIO 引脚状态。
使能电源。

总结
设备树 描述了硬件的详细信息（如 I2C 地址、GPIO 引脚、中断号等）。
驱动 通过内核提供的 API（如 devm_gpiod_get、devm_regulator_get、gpiod_to_irq 等）解析设备树中的信息，并初始化硬件。
设备树和驱动共同协作，完成硬件的配置和管理。
通过这个复杂一点的例子，可以更清楚地看到设备树和驱动如何配合工作，实现硬件的识别、解析和处理。

dts和硬件层的衔接

dts文件，靠软件层衔接的是驱动，那么另一层次呢？靠近硬件那一层和谁是关联（或者什么文档，也就是谁来决定dts的，或者dts应该根据谁来写类似这样的关联方）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

在Linux系统中，设备树（Device Tree）用于描述硬件平台的配置信息，特别是对于嵌入式系统。设备树的描述文件通常以`.dts`（Device Tree Source）格式存在，并通过设备树编译器（DTC）编译为二进制格式的`.dtb`（Device Tree Blob），供内核在启动时使用。

### 设备树的两层关系：
1. **软件层（驱动层）**：
   - 设备树通过内核的设备树解析机制与驱动程序进行衔接。
   - 内核会根据设备树中的节点信息，匹配对应的驱动程序，并初始化硬件设备。
   - 驱动程序通过设备树接口（如`of_*`系列函数）从设备树中获取硬件配置信息。

2. **硬件层**：
   - 设备树描述的是硬件平台的配置，因此它需要与硬件的实际设计保持一致。
   - 设备树的内容通常由硬件设计团队或硬件工程师提供，他们根据硬件的实际设计（如SoC芯片手册、外设连接方式等）来决定设备树的内容。
   - 设备树的编写需要参考硬件的技术文档，如芯片手册（Datasheet）、参考设计（Reference Design）等。

### 设备树的编写依据：
- **硬件设计文档**：设备树的编写需要根据硬件设计文档来进行，这些文档包括：
  - SoC芯片手册（Datasheet）：描述了芯片的寄存器、外设、中断等信息。
  - 硬件原理图（Schematic）：描述了硬件平台的电路连接方式。
  - 参考设计（Reference Design）：提供了标准的硬件配置和连接方式。
  
- **硬件工程师**：硬件工程师通常会根据硬件设计文档提供设备树的初始版本，或者与软件工程师合作完成设备树的编写。

### 设备树的决定因素：
- **硬件设计**：设备树的节点和属性必须与硬件设计一致，硬件设计决定了设备树的内容。
- **内核支持**：内核的驱动程序需要能够识别和解析设备树中的节点和属性，因此设备树的编写也需要考虑内核的支持情况。

### 设备树的维护：
- **硬件团队**：负责提供硬件设计的更新信息，确保设备树与硬件设计一致。
- **软件团队**：负责根据硬件设计更新设备树，并确保内核能够正确解析和使用设备树。

总结来说，设备树的编写主要依赖于硬件设计文档和硬件工程师的输入，同时需要与内核的驱动支持保持兼容。硬件设计是设备树的最终决定因素，而软件层（内核和驱动）则是设备树的使用方。

举例_硬件和dts

硬件结构
1个双核ARM Cortex-A932位处理器；
ARM本地总线上的内存映射区域分布有两个串口（分别位于0x101F1000和0x101F2000）
GPIO控制器（位于0x101F3000）
SPI控制器（位于0x10170000）
中断控制器（位于0x10140000）
外部总线桥上连接的设备如下：
SMC SMC91111以太网（位于0x10100000）
I2C控制器（位于0x10160000）
64MB NOR Flash（位于0x30000000）
外部总线桥上连接的I2C控制器所对应的I2C总线上又连接了Maxim DS1338实时钟（I2C地址为0x58）
具体如下图所示；

设备树dts文件
那么，如何将上面的硬件结构，通过设备树语言描述成dts文件呢？具体我实现在下图，并且做出了详细的解释。其中需要注意的有以下几个属性：

• compatitable：兼容性属性；
• #address-cells,#size-cells：地址编码所采用的格式；
• 节点名称@节点地址：例如gpio@101f3000，这里名称和地址要和实际的对应起来；
• 标签：例如interrupt-parent = <&intc>;，这这里的intc就是一个标签(label)，通过&可以获取它的值，这里可以简单的理解成一个变量，然后在下面需要对这个标签进行另外的解析，例如intc:interrupt-controller@10140000；所以，这两个地方的intc都是对应起来的。
  最后，具体的实现可以参考下图；
  

参考

设备树与驱动的关系、设备树参数的介绍:https://zhuanlan.zhihu.com/p/8598598018
linux设备树dts文件详解：https://blog.csdn.net/weixin_42031299/article/details/125813060
linux 驱动简单案例：https://www.cnblogs.com/han-guang-xue/p/15769229.html
在Linux下写一个简单的驱动程序:https://www.cnblogs.com/kn-zheng/p/17168166.html
Linux 设备树语法（.dts）及如何从设备树获取节点信息：https://www.cnblogs.com/fortunely/p/16405592.html#a-of_get_property
Linux dts 设备树详解(二) 动手编写设备树dts：https://blog.csdn.net/u010632165/article/details/91488811
Device Tree (一) - dts基本概念和语法：https://blog.csdn.net/u011456016/article/details/136665769
Linux driver dts使用，实例驱动编写：https://blog.csdn.net/songyulong8888/article/details/78115512

常见图片格式基本知识及转换、显示工具:https://blog.csdn.net/sjnjab/article/details/134507551
矢量图、位图、RGB、YUV、JPEG、PNG的理解：https://blog.csdn.net/kcstrong/article/details/81705693
【FPGA图像处理实战】- YUV444与YUV422互转：https://fpga.eetrend.com/blog/2024/100579119.html

BMP,PNG,JPG

JPG：使用一种失真的压缩标准算法，可以选择压缩率，默认的压缩率在70%左右。一张图片在多次压缩解压后，会肉眼可见地失真。
PNG：无损数据压缩格式，包含8位、24位、32位三种格式，32位支持透明形式（多了8bits透明度alpha）。
BMP：原始图像数据，一般有header标识数据的存储结构。
同一张图片三种格式的占用空间:BMP>PNG>JPG

raw原始数据文件

raw原始pixel数据文件主要包含RGB和YUV两种数据格式，这两种数据格式的相关介绍很多，这里不再赘述。RGB包含RGB565，RGB888，ARGB8888，ABGR8888等，YUV包含YUV444，YUV422，YUV420等。
YUV的存储方式包含packed和planner两种方式。
packed：连续存储Y分量，然后依次交叉存储UV分量，常见的有NV12，NV21等；
planner：连续存储Y分量，然后再连续存储U分量（或V分量），最后存储V分量（或U分量）,常见的有I420，YV12等。

RGB,YUV

YUV的优势

便于压缩编码。RGB表示的每种颜色都是由红光、绿光、蓝光组合而成的，我们分别使用R、G、B三个分量来表示红光、绿光、蓝光，每个像素的三个分量之间存在着相关性。所以通常会把RGB转换成YUV进行压缩。
数据量相对RGB来说更小。前面我们有分析过，同样分辨率的图像，YUV444存储的数据量与RGB相同，但YUV422和YUV420却只需要存储RGB的数据量的 2/3 和 1/2 。
能够兼容老式黑白电视。Y分量单独显示是其实就是黑白图像，因此YUV由彩色转黑白只需要去除UV相关的数据就可以了。

YUV与RGB之间的转换

YUV与RGB之间的转换是存在标准的，常见的标准有：

1
2
3

ITU-R BT.601（标清）
ITU-R BT.709（高清）
ITU-R BT.2020（超高清）。

不同的标准有不同的准换公式，同时还要区分不同的Color Range。
Color Range用于指定RGB分量的取值范围，可分为Full Range（取值范围为0255）和Limited Range（取值范围为16235）。

yuv444,422,420

以黑点表示采样该像素点的Y分量，以空心圆圈表示采用该像素点的UV分量，如下图所示。
4:4:4 表示不降低色度（UV）通道的采样率。每个 Y 分量对应一组 UV 分量。
4:2:2 表示 2:1 水平下采样，没有垂直下采样。每两个 Y 分量共享一组 UV 分量。
4:2:0 表示 2:1 水平下采样，同时 2:1 垂直下采样。每四个 Y 分量共享一组 UV 分量。

YUV420,YUV420P,YUV420SP(,NV12,NV21)

常见的基于 YUV 4:2:0 采样的格式如下表：

基于 YUV 4:2:0 采样的格式主要有 YUV 420P 和 YUV 420SP 两种类型，每个类型又对应其他具体格式。

1
2
3
4
5
6

YUV 420P 类型
YU12 格式
YV12 格式
YUV 420SP 类型
NV12 格式
NV21 格式

YUV 420P 和 YUV 420SP 都是基于 Planar 平面格式 进行存储的，先存储所有的 Y 分量后， YUV420P 类型就会先存储所有的 U 分量或者 V 分量，而 YUV420SP 则是按照 UV 或者 VU 的交替顺序进行存储了，具体查看看下图

YUV420P 和YUV420SP

YUV420P 的格式：

其在码流中的表现形式为：

YUV420SP的格式：

其在码流中的表现形式为：

YU12和YV12格式

YU12 和 YV12 格式都属于 YUV 420P 类型，即先存储 Y 分量，再存储 U、V 分量，区别在于：YU12 是先 Y 再 U 后 V，而 YV12 是先 Y 再 V 后 U 。YV 12 的存储格式如下图所示：

YU 12 又称作 I420 格式，它的存储格式就是把 V 和 U 反过来了。

NV12和NV21格式

NV12 和 NV21 格式都属于 YUV420SP 类型。它也是先存储了 Y 分量，但接下来并不是再存储所有的 U 或者 V 分量，而是把 UV 分量交替连续存储。

需要注意的是，
NV12是iOS中有的模式，它的存储顺序是先存Y分量，再YV进行交替存储。
NV21是Android中有的模式，它的存储顺序是先存Y分量，再VU交替存储。

参考

视频图像格式 NV21-NV12-YUV420P 的区别:https://blog.csdn.net/linda012518/article/details/106636942
音视频编解码: YUV存储格式中的YUV420P,YUV420SP,NV12, NV21理解(转):https://www.cnblogs.com/yongdaimi/p/10696214.html

V4L2全称video for linux 2，是linux系统之中用于处理视频设备的内核驱动程序接口。它提供了一种标准化的方式，使用户空间程序能够与视频设备（e.g. 摄像头、视频采集卡等）进行通信和交互。
understanding：就是屏蔽掉底层摄像头的不同驱动实现，提供给用户空间统一的接口调用
工作原理：在linux系统中所有的外设都被看成是一种特殊的文件，V4L2将一个视频采集设备以一个文件描述符给到用户空间。在V4L2的封装下，其支持三种方式来采集图像，内存映射方式（mmap）、直接读取方式（read）、用户指针。其中，read方式需要大量的复制操作，带来开销；用户指针方式对驱动工作较难，故一般采用mmap方式。此外，V4L2的一些重要数据结构都在#include<linux/videodev2.h>文件中进行定义（linux系统在内核编译阶段可以配置集成V4L2的能力）

V4L2的buffer管理是通过videobuf2来完成的，他充当用户空间和驱动之间的中间件，提供模块化的内存管理功能。
videobuf2其中主要包含以下数据结构：

1
2
3
4

vb2_queue：用于描述buffer的队列，描述buffer节点以及buffer的入队与出队
vb2_buf_ops：buffer操作集
vb2_mem_ops：内存buffer分配函数接口
vb2_ops：vb2队列操作函数集

其buffer的循环流程如下图

V4L2的API以及操作主要包括

参考

V4L2学习理解：https://zhuanlan.zhihu.com/p/668015169
v4l2应用程序接口：https://blog.csdn.net/weixin_68782273/article/details/126827820

ffmpeg从v4l2获取frame数据：
FFMPEG（二） v4l2 数据格式装换：https://blog.csdn.net/li_wen01/article/details/67631687
v4l2采集视频：https://blog.csdn.net/weixin_43147845/article/details/136899272

驱动源码(固定pattern,略)

方法一：整编内核

01，源码复制到特目录：demo_driver.c程序拷贝到…/linux-2.6.32.2/drivers/char目录下
02，增加编译选项，触发新增源码的编译，修改…/linux-2.6.32.2/drivers/char目录下Makefile文件，在Makefile中增加如下代码：

1

obj-m += demo_driver.o

03,启动内核编译 ，回到linux内核源码根目下…/linux-2.6.32.2 ，执行编译指令

1

make

等待内核编译约20分钟…
最终得到demo_driver.ko

整编内核的模式示意图如下：

方法二：单编ko

01,make modules 指令为编译内核模块指令：该指令的功能是编译内核中所有配置为模块的程序得到模块ko文件，make modules 命令只能在内核源码顶层目录下执行。

make modules是编译所有的内核模块，如何单独编译一个指定的模块呢？加M参数

1

make  M=DIR modules

“M=”参数的作用是以内核源码为基础编译一个外部模块。命令中“M=DIR”，程序会自动跳转到所指定的DIR目录中查找模块源码，编译生成ko文件。

02：编写Makefile： 单编KO的Makefile文件如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# .PHONY来显示地指明main clean是伪目标
.PHONY:    main  clean

# 定义了KERNELDIR ，PWD ，CROSS_ARCH 三个变量。
KERNELDIR   :=   /home/liwei/v3_work/project/linux-2.6.32.2
PWD   :=   $(shell pwd)
CROSS_ARCH := /home/liwei/v3_work/tools/arm-linux-gcc-4.4.3/opt/FriendlyARM/toolschain/4.4.3/bin/arm-linux-gcc

# 指定将demo_driver.c编译成demo_driver.ko文件。
obj-m   +=   demo_driver.o

# main:是第一个伪目标，也就是默认目标
main: 
$(MAKE) $(CROSS_ARCH) -C  $(KERNELDIR)   M=$(PWD)   modules 

# clean是执行清除工作的伪目标。
clean: 
rm   -rf   *.o   *~   core   .depend   .*.cmd   *.ko   *.mod.c   .tmp_versions *.symvers *.d *.markers *.order

• $(MAKE) 为make
• $(CROSS_ARCH) 为指定的编译工具
• -C (KERNELDIR) 选项的作用是将工作目录转移到指定的KERNELDIR位置
• -M=(PWD) modules ，作用是以内核源码为基础编译一个外部模块
  将demo_driver.c和上述的Makefile文件放在同一个目录下（路径为任何路径，不需要一定放在内核目录中），执行make指令。

大约3秒钟，编译得到demo_driver.ko文件，单编KO的优势就是快（3秒钟）
最终得到了demo_driver.ko文件，我们将文件传输到开发板中并测试驱动ko文件。

1
2

执行加载驱动：insmod demo_driver.ko 
查看驱动设备：cat /proc/devices

单编KO的模式如下：

参考

debian环境 源码如何编译为ko 驱动
【转】如何编译linux驱动ko：https://blog.csdn.net/weixin_45264425/article/details/130394724
Linux编译ko文件详细教程 (linux 怎么编译ko文件):https://www.idc.net/help/123153/
Linux 内核模块ko在内核源码外部编译的方法：https://blog.csdn.net/m0_67686953/article/details/128952347
Linux编译内核模块生成.KO驱动示例:https://blog.csdn.net/u011436603/article/details/138486727
在kernel中添加自定义驱动、无线网卡/声卡的配置：https://blog.csdn.net/weixin_38019025/article/details/103966224
12-如何向Linux内核添加新的设备驱动：https://blog.csdn.net/weixin_42135087/article/details/139903669

关系图

需要注意的是上图中：pcie，sata既是总线，其实也是接口（所以下部的接口图中，其实是少了pcie的，借用别人的图，意思大致理解就行）

M.2，U.2，AIC，Half slim，mSATA，2.5in等这些指的是SSD形态（尺寸），是根据不同的应用场景进行设计。
PCIe，SATA和SAS指的是SSD接口的形态，即数据传输通路，接口不同传输速率不同，即每秒能传输的数据量不同。
NVMe，AHCI是应用于数据传输通路上的协议。其中由于NVMe协议允许多队列，并且队列深度高，可以同时并行在多个数据传输通路上进行数据传输，可以更好地利用PCIe多通道的性能。AHCI只允许单队列，并且队列深度低，一次只能发送一个通道的数据，传输速率低。

简单理解：(物理)接口(M2,U2,AIC)=》总线(PCIe，SATA)=》协议(NVMe，AHCI)
其中pcie和nvme高度相关，SAta和AHCI高度相关，

总线(通道)标准：SATA与PCIe

实际上，SATA与PCIe既可以说是总线（通道）标准，也可以说是接口。
当SATA和PCIe作为总线（通道）标准时，可以理解为它们就是数据走的通道或者“路”，数据是通过这个“通道”传输至固态硬盘存储区或者是PC端的。二者的区别是SATA“窄”/PCIe“宽”，因此使用PCIe的固态硬盘要比SATA固态硬盘数据传输要快得多，目前主流SSD使用的也是PCIe总线（通道）标准。

PCIe和SATA是两种不同的接口标准，二者的本质的区别是通信架构的不同，PCIe属于全双工模式，而SATA是半双工模式。
简单的来说，全双工模式允许数据双向传输，而半双工模式只允许数据单向传输。全双工模式传输的优势就是传输速度快，延迟低。
从系统架构上来说，PCIe比SATA要简单。PCIe SSD硬盘在直接连在CPU上，不过，准确的来说，是CPU的小蜜，Root Complex。CPU作为系统的大脑，事务繁忙，日理万机。RC端帮助CPU处理与设备之间的交互。
PCIE和SATA当然有自己的插槽形硬件接口，但现在都普遍用M.2接口，兼容PCIE和SATA，M.2接口一般金手指结构，金手指一般指内存条的金黄色导电触片。
与SATA接口(总线)对接系统接口AHCI(协议)不同，PCIe接口(总线)上层对接的系统接口标准是NVMe(协议)。NVMe与AHCI相比，具有很多的优势。延迟低，最大支持64K队列，命令执行更简单等等。这些优势存在让PCIe是如鱼得水。带NVMe的带领下，PCIe SSD拥有的更快的速度，更低的延迟。

传输协议：NVMe与AHCI

如果说SATA和PCIe是传输数据的“路”，那么NVMe与AHCI就是保证“路”有秩序的交通规则，同样也是固态硬盘性能和速度的保证。关系上传输协议与通道标准是一一对应的，AHCI对应SATA、NVMe对应PCIe（PCIe通道实际上是可以采用AHCI协议的，但是此类产品市面上几乎没有了）。
AHCI无法很好地为采用高速PCIe通道的SSD提供服务，因此针对PCIe通道设计了NVMe传输协议，专为PCIe的SSD服务。目前NVMe已经升级到1.3、1.4版本，低延迟、高性能。
总结一下，SATA和PCIe是传输数据的“路”，SATA（1.0、2.0、3.0）与PCIe（M.2、U.2、AIC）是物理接口，而NVMe与AHCI则是“交通规则”。

NVMe，AHCI是应用于数据传输通路上的协议。其中由于NVMe协议允许多队列，并且队列深度高，可以同时并行在多个数据传输通路上进行数据传输，可以更好地利用PCIe多通道的性能。AHCI只允许单队列，并且队列深度低，一次只能发送一个通道的数据，传输速率低。

sata,msata,m2,pcie物理形态

接口性能/速度是否满足的计算样例

问题：已知有一个sdi转接pcie的设备，通过pcie取得nv12格式的sdi原始视频raw数据，1080p@60fps，,pcie gen2.0 x4(4通道)是否可以支撑这个传输需求，请给出计算步骤

01，计算视频数据带宽（NV12 格式）​​
​​NV12 是 YUV 4:2:0 格式，每个像素占用 ​​1.5 字节​​（Y 分量 1 字节，UV 分量共 0.5 字节）。
​​分辨率​​：1920 × 1080（1080p）
​​帧率​​：60 FPS

1
2
3
4
5
6
7
8
9

​​计算单帧数据量​​:单帧数据量=宽度×高度×每像素字节数
=1920×1080×1.5字节
=3,110,400字节≈2.97MB
​​计算每秒数据量（带宽需求）​​
带宽=单帧数据量×帧率
=2.97MB×60FPS
=178.2MB/s
​​换算成比特率（bit/s）：​​
178.2MB/s×8=1,425.6Mbps

02，计算 PCIe Gen2.0 x4 的理论带宽​​
​​
带宽对比​​

1,425.6Mbps<16,000Mbps
​​结论​​
​​PCIe Gen2.0 x4 的理论带宽（16 Gbps）远高于 1080p@60fps NV12 视频的带宽需求（1.425 Gbps）。​​
​​实际传输时，PCIe 2.0 x4 完全可以满足需求，甚至还有大量余量。​

常见的MCU/MPU/SoC/DSP/FPGA的差别

在芯片领域，​​MCU、MPU、SoC、DSP​​ 和 ​​FPGA​​ 是常见的处理器类型，它们各有特点，适用于不同场景。以下是它们的核心区别和联系：

​1. MCU（Microcontroller Unit，微控制器）​​

• ​​特点​​：
  • ​​高度集成​​：将 CPU、内存（RAM/Flash）、外设（GPIO、ADC、UART等）集成在单一芯片上。
  • ​​低功耗​​：适合电池供电设备。
  • ​​实时性​​：通常运行 RTOS（如 FreeRTOS）或裸机程序。
• ​​应用场景​​：
  • 家电控制（如洗衣机）、传感器节点、小型嵌入式设备。
• ​​代表型号​​：
  • STM32（ST）、ESP32（乐鑫）、PIC（Microchip）。

​​2. MPU（Microprocessor Unit，微处理器）​​

• ​​特点​​：
  • ​​强计算能力​​：高性能 CPU 核心（如 ARM Cortex-A、x86），但需外接内存（DDR）和外围芯片。
  • ​​运行操作系统​​：支持 Linux、Android 等复杂 OS。
  • ​​高功耗​​：通常需要主动散热。
• ​​应用场景​​：
  • 工业计算机、智能终端（如 POS 机）、边缘计算。
• ​​代表型号​​：
  • Raspberry Pi（博通 BCM）、i.MX（NXP）、Intel Atom。

​​3. SoC（System on Chip，片上系统）​​

• ​​特点​​：
  • ​​超高度集成​​：在单芯片上集成 CPU、GPU、NPU、内存控制器、高速接口（USB/PCIe）等。
  • ​​异构计算​​：可能包含多个 CPU/GPU/DSP 核心。
  • ​​定制化​​：部分 SoC 可针对特定场景优化（如 AI 芯片）。
• ​​应用场景​​：
  • 智能手机（如骁龙、麒麟）、自动驾驶、AI 加速。
• ​​代表型号​​：
  • 高通骁龙、华为麒麟、NVIDIA Jetson。

​​4. DSP（Digital Signal Processor，数字信号处理器）​​

• ​​特点​​：
  • ​​专用计算​​：优化数字信号处理（如 FFT、滤波），擅长高吞吐量数学运算。
  • ​​低延迟​​：硬件加速特定算法（如音频编解码）。
  • ​​通常作为协处理器​​：与 MCU/MPU 协同工作。
• ​​应用场景​​：
  • 音频处理（如降噪）、图像处理（如摄像头）、通信（5G 基带）。
• ​​代表型号​​：
  • TI C6000 系列、ADI SHARC。

​​5. FPGA（Field Programmable Gate Array，现场可编程门阵列）​​

• ​​特点​​：
  • ​​硬件可编程​​：通过 HDL（Verilog/VHDL）配置逻辑电路，灵活性极高。
  • ​​并行计算​​：适合高速信号处理、协议加速。
  • ​​高功耗​​：动态功耗随逻辑复杂度增加。
• ​​应用场景​​：
  • 通信协议处理（如 5G）、原型验证、ASIC 流片前的替代方案。
• ​​代表型号​​：
  • Xilinx Zynq（SoC+FPGA）、Intel Cyclone。

对比总结

​​SoC 可能包含 MCU/MPU/DSP​​
例如：手机 SoC（如骁龙）包含 Cortex-A（MPU）、Cortex-M（MCU）、DSP 和 GPU。

​​FPGA 可与 MCU/MPU 协同​​
例如：Xilinx Zynq 集成了 ARM Cortex-A（MPU）和 FPGA 逻辑。

​​DSP 常作为协处理器​​
例如：摄像头模组用 MCU 控制，DSP 处理图像。

​​如何选择？ ​​
​​需要低功耗控制？​​ → ​​MCU​​
​​需要跑 Linux？​​ → ​​MPU/SoC​​
​​要做音视频处理？​​ → ​​DSP​​
​​需要灵活硬件加速？​​ → ​​FPGA​​
​​全功能智能设备？​​ → ​​SoC​

参考

M.2 PCIe NVMe三者的关系：https://blog.csdn.net/weixin_46129187/article/details/143429683
小a科普｜固态硬盘术语：SATA、PCIe、AIC、U2、M.2、NVMe和AHCI:https://baijiahao.baidu.com/s?id=1711659897646763096&wfr=spider&for=pc
选购固态硬盘别犯难：一文搞懂 M.2、SATA、PCIe 和 NVMe：https://baijiahao.baidu.com/s?id=1804753527384413243&wfr=spider&for=pc
PCIe、SATA，M.2，NVMe、AHCI、IDE到底都是 些啥？（于2018.04）:https://www.douban.com/note/684877015/?_i=1403373xdAUCBL
硬盘MSATA和SATA和M2接口定义:https://post.smzdm.com/p/a94og7g5/

LTTng: (Linux Trace Toolkit Next Generation),它是用于跟踪Linux内核、应用程序以及库的系统软件包.LTTng 主要由内核模块和动态链接库(用于应用程序和动态链接库的跟踪)组成。它由一个会话守护进程控制,该守护进程接受来自命令行接口的命令。babeltrace项目允许将追踪信息翻译成用户可读的日志,并提供一个读追踪库,即libbabletrace。ceph代码中大量嵌入了tracepoint，使用lttng进行跟踪。它整合了内核和用户态跟踪，对于大量的跟踪事件流有非常高的性能，并且有一系列的分析和抓取工具。
对于目前的Linux内核来说，LTTng只不过是众多Tracing工具的一个，它制造了太多重复的工作比如Rring Buffer(内核中已经有两个Ring buffer被perf和ftrace使用)，并且自己的系统调用接口(内核已经有此类的接口)，增加LTTng意味着更混乱的Tracing ABI在内核中。
相比较而言，LTTng进入内核比SystemTap和utrace更困难。

lttng展示可跟踪位置

lttng跟踪必定是需要进程一直在运行状态，像mon、osd的自不必多说，如果跟踪是librbd就必须保证加载 librbd.so进程是在运行。

1
2

./rbd_example ##一直在跑  
lttng list –u

命令行参数

嵌入式 lttng使用详细说明：https://blog.csdn.net/skdkjzz/article/details/44564951

跟踪并获取信息

1
2
3
4
5
6
7
8
9

mkdir -p traces ##创建存放  
lttng create -o traces librbd ## 创建trace session  
lttng enable-event -u 'librbd:*' ## 使能感兴趣的event  
lttng add-context -u -t pthread_id ## 加入 线程信息  
lttng start ## 开始跟踪  

# run RBD workload here  
lttng stop ## 停止trace  
lttng destroy ##销毁 session

可以查看traces目录，是否有对应的记录生成

首先执行程序：

1

./self-ust

然后开启跟踪：

1
2
3
4
5
6
7

lttng-sessiond --daemonize  
lttng create myself-lttng-ust  
lttng enable-event --userspace 'self\_lttng\_ust:main_tracepoint'  
lttng start  

# wait  
lttng destroy

3.3 查看跟踪信息

1

babeltrace2 ~/lttng-traces/myself-lttng-ust*

使用babeltrace读取结果

1
2
3
4
5
6

babeltrace traces > result.all  
\[10:17:31.802322370\] (+?.?????????) XXXXXXXXX librbd:aio\_complete\_enter: { cpu\_id = 2 }, { pthread\_id = 139658738509568 }, { completion = 0x5635FA045920, rval = 0 }  
\[10:17:31.802361060\] (+0.000038690) XXXXXXXXX librbd:aio\_get\_return\_value\_enter: { cpu\_id = 2 }, { pthread\_id = 139658738509568 }, { completion = 0x5635FA045920 }  
\[10:17:31.802362582\] (+0.000001522) XXXXXXXXX librbd:aio\_get\_return\_value\_exit: { cpu\_id = 2 }, { pthread\_id = 139658738509568 }, { retval = 0 }  
\[10:17:31.802399704\] (+0.000037122) XXXXXXXXX librbd:aio\_complete\_exit: { cpu\_id = 2 }, { pthread\_id = 139658738509568 }, { }  
\[10:17:31.802522131\] (+0.000122427) XXXXXXXXX librbd:write\_exit: { cpu\_id = 2 }, { pthread_id = 139659290902208 }, { retval = 10485760 }

Error: Unable to list kernel events: Kernel tracer not available

1
2
3

lttng list --kernel  
Linux Trace Tool lttng on Raspbian: Kernel tracer not available:https://stackoverflow.com/questions/52386448/linux-trace-tool-lttng-on-raspbian-kernel-tracer-not-available  
cat /boot/config-\`uname -r\` > myconfig

查看当前Linux系统的内核编译config文件，生成编译驱动所需的内核头文件：https://blog.csdn.net/dumgeewang/article/details/128528790
相关编译选项的核实

2.0 LTTng需要的内核配置（通过读取LTTng-module文档中的README了解）：https://www.shuzhiduo.com/A/QW5YBQMedm/

1
2
3
4
5
6
7
8
9
10
11
12

missing the kernel header for the 4.4.0-98-generic kernel.  
sudo apt-get install linux-headers-4.4.0-98-generic  
[https://lttng-dev.lttng.narkive.com/7bDtQAkg/error-unable-to-list-kernel-events-kernel-tracer-not-available](https://lttng-dev.lttng.narkive.com/7bDtQAkg/error-unable-to-list-kernel-events-kernel-tracer-not-available)  
Download, build, and install the latest LTTng-modules 2.13:  
cd $(mktemp -d) &&  
wget https://lttng.org/files/lttng-modules/lttng-modules-latest-2.13.tar.bz2 &&  
tar -xf lttng-modules-latest-2.13.tar.bz2 &&  
cd lttng-modules-2.13.* &&  
make &&  
sudo make modules_install &&  
sudo depmod –a  
[https://stackoverflow.com/questions/52386448/linux-trace-tool-lttng-on-raspbian-kernel-tracer-not-available](https://stackoverflow.com/questions/52386448/linux-trace-tool-lttng-on-raspbian-kernel-tracer-not-available)

Function tracing (LTTng-UST helper)

https://lttng.org/man/3/lttng-ust-cyg-profile/v2.10/
c c++ 函数入口和出口的hook(gcc 编译选项)，然后打印出函数调用关系的方法:https://www.cnblogs.com/welhzh/p/4904874.html

enter,exit函数拦截

集成到自己程序则不行

追踪规则

1) 追踪内核所有的探测点和所有的系统调用事件(-k/–kernel)：
# lttng enable-event -a –k
2) 追踪探测点事件，这里我们追踪 sched_switch和sched_wakeup为例 (-k/–kernel) 。
# lttng enable-event sched_switch,sched_wakeup -k
或者追踪所有的探测点事件：
# lttng enable-event -a -k –tracepoint
3) 追踪所有的系统调用：
# lttng enable-event -a -k –syscall
4) 使用 kprobes 以及 （或） 其他追踪器作为lttng的源：
这是一个LTTng2.0内核追踪器的一个新特性，你可以使用一个动态probe作为源，probe的追踪结果会显示在lttng的追踪结果中。
# lttng enable-event aname -k –probe symbol+0x0
or
# lttng enable-event aname -k –probe 0xffff7260695
可以为probe制定一个准确的地址0xffff7260695或者 symbol+offset。
你也可以使用功能追踪（使用的Ftrace API），追踪结果也会显示在lttng的追踪结果中：
# lttng enable-event aname -k –function
5) 打开一个事件的上下文信息：
这也是一个新特性，可以让你添加一个事件的上下文信息。比如说你可以添加PID：
# lttng add-context -k -e sched_switch -t pid
你也可以使用多个上下文信息：
# lttng add-context -k -e sched_switch -t pid -t nice -t tid
你可以使用’ lttng add-context –help ‘ 学习所有的上下文格式的用法。
6) 打开事件的Perf计数器：
这也是一个新的很强大的特性，为每个追踪的事件添加Perf计数器数据（使用Perf的API）。下面实例为为每个事件添加CPU周期：
# lttng add-context -k -e sched_switch -t perf:cpu-cycles
注： 你需要使用 add-context 的help学习所有的perf计数器值的含义。

专题function追踪

官方文档的只言片语

https://lttng.org/docs/v2.13/#doc-liblttng-ust-cyg-profile

测试01:修改源码，不包含lttng任何信息

g++ -lpthread -c multi_thread.cpp
g++ -o app multi_thread.o -ldl -lpthread

测试02:案例test02

测试03:funcs

编译：g++ -o app multi_thread.o my_lttng_ele.o my_lttng_gst.o -llttng-ust -ldl -lpthread -finstrument-functions

编译：g++ -o app multi_thread.o -ldl -lpthread -finstrument-functions
运行：LD_PRELOAD=liblttng-ust-cyg-profile.so ./app

此基础上开启采集
836 lttng enable-event –userspace ‘lttng_ust_cyg_profile:func_exit’
837 lttng enable-event –userspace ‘lttng_ust_cyg_profile:func_entry’
838 lttng enable-event -a -k –syscall

未采集到
这有一篇文章展示了 大概思路：
采集MySQL trace数据：https://www.hikunpeng.com/document/detail/zh/kunpengdevkithistory/vscodehistory/2.5.5/kunpengidevscode\_10\_0350.html
调整代码循环内调用函数


添加采集字段，添加采集scehd切换信息
LD_PRELOAD=liblttng-ust-cyg-profile.so ./app
lttng create test03096
lttng enable-event –kernel sched_switch
lttng enable-event –userspace ‘lttng_ust_cyg_profile:func_exit’
lttng enable-event –userspace ‘lttng_ust_cyg_profile:func_entry’
lttng add-context –kernel –type=pid –type=tid –type=procname
lttng add-context –userspace –type=ip –type=pthread_id –type=procname
lttng start
lttng destroy
babeltrace2 ~/lttng-traces/test03096* | grep lttng_ust_cyg_profile

图形工具

数据导入

数据含义分析

Timestamp Channel CPU Event type Contents TID Prio PID Source
10:38:11.978 045 845 channel0_1 1 irq_handler_entry irq=27, name=virtio2-req.0, context.packet_seq_num=1, context.cpu_id=1 0 20



Timestamp Channel CPU Event type Contents TID Prio PID Source
10:38:11.958 232 111 channel0_1 1 x86_irq_vectors_local_timer_entry vector=236, context.packet_seq_num=1, context.cpu_id=1

不同参数和现象

项目：Test4_ak
lttng enable-event -a –k
lttng enable-event –userspace ‘provider_my:enter_app’
323 lttng add-context –kernel –type=pid –type=tid –type=procname
324 lttng add-context –userspace –type=pthread_id

项目：test03_k_syscall
lttng enable-event -a -k –syscall
lttng add-context –kernel –type=pid –type=tid –type=procname
lttng add-context –userspace –type=pthread_id

问题

关于时间区间来源：减法规则
关于关注的事件
Event 和syscall区别

Function追踪，知道具有功能，怎么用没例子

使用模拟方法gst，ele，tracepiont报异常

其他结果分析软件

[LTTng学习之旅]——Trace View初探
View and analyze the recorded events
Once you have completed the Record Linux kernel events and Record user application events tutorials, you can inspect the recorded events.
There are many tools you can use to read LTTng traces:
Babeltrace 2
A rich, flexible trace manipulation toolkit which includes a versatile command-line interface (babeltrace2(1)), a C library, and Python 3 bindings so that you can easily process or convert an LTTng trace with your own script.
The Babeltrace 2 project ships with a plugin (babeltrace2-plugin-ctf(7)) which supports the format of the traces which LTTng produces, CTF.
Trace Compass
A graphical user interface for viewing and analyzing any type of logs or traces, including those of LTTng.
LTTng analyses
An experimental project which includes many high-level analyses of LTTng kernel traces, like scheduling statistics, interrupt frequency distribution, top CPU usage, and more.
Babeltrace我没尝试，看起来像是一个命令行工具。而且是LTTng自己出品的。
我们做技术研究的，一方面要向老板汇报。可视化当然要生动明确。另一方面要技术推广。太难上手也不行。即开即用最好。
我们直接来使用第二个 Trace Compass.
Trace Compass (eclipse.org)
icon-default.png?t=M4ADhttps://www.eclipse.org/tracecompass/
打开这个网页，下载一个对于host 操作系统版本的软件。
打开软件 新建 trace工程。然后导入之前生成Trace log 的目录。
就可以看了。。。。很容易。

几招教你如何使用lttng以及log分析cpeh:https://mp.weixin.qq.com/s/FY3ibq3ncDYq8V59B8nVxw
Linux内核之Tracepoint机制:https://zhuanlan.zhihu.com/p/547477490
lttng：简单易上手的 tracef:https://zhuanlan.zhihu.com/p/506236943
lttng：自定义 tracepoint:https://zhuanlan.zhihu.com/p/509848662
其他
原理，复杂，没懂
使用LTTng链接内核和用户空间应用程序追踪:https://blog.csdn.net/longerzone/article/details/12623359
[LTTng学习之旅]——Trace 数据提取和格式转换—Babeltrace 2 C 应用程序开发
https://blog.csdn.net/kuno_y/article/details/125081883
嵌入式设备源码编译
[LTTng学习之旅]——环境搭建:https://blog.csdn.net/kuno_y/article/details/124764840
Lttng接口使用吐槽
比最差的API(ETW)更差的API(LTTng)是如何炼成的, 谈如何写一个好的接口：https://www.cnblogs.com/zkweb/p/8126303.html
尝试使用LTTng+TraceCompass分析一下进程周期偏移：https://blog.csdn.net/kuno_y/article/details/128372695
Versal ACAP AI 引擎编程环境 用户指南 (UG1076)
https://docs.xilinx.com/r/2022.1-简体中文/ug1076-ai-engine-environment/Vitis-分析器中的-FIFO-深度可视化
Zephyr Tracing 追踪调试指南
https://docs.panchip.com/pan1080dk-doc/0.5.0/04\_dev\_guides/zephyr\_tracing\_guidance.html
test02
[LTTng学习之旅]——在用户程序中简单的添加一个trace点
https://blog.csdn.net/kuno_y/article/details/124983044
使用trace compass分析ftrace
https://pkemb.com/2022/09/analyze-ftrace-with-trace-compass/
如何使用lttng检查多线程用户应用程序的调度？https://cloud.tencent.com/developer/ask/sof/1800581/answer/2449880/comments
【LTTng】lttng-gen-tp — Generate LTTng-UST tracepoint provider code
https://blog.csdn.net/kuno_y/article/details/126853032
https://lttng.org/docs/v2.13/#doc-tracing-the-linux-kernel
https://wiki.eclipse.org/Linux_Tools_Project/LTTng2/User_Guide#LTTng_Tracer
https://xy2401.com/local-doc-help.eclipse.org-2019-06.zh/org.eclipse.tracecompass.doc.user/doc/LTTng-Kernel-Analysis.html
https://xy2401.com/local-doc-help.eclipse.org-2019-06.zh/org.eclipse.tracecompass.doc.user/doc/LTTng-Tracer-Control.html
https://xy2401.com/local-doc-help.eclipse.org-2019-06.zh/org.eclipse.tracecompass.doc.user/doc/Trace-Compass-Main-Features.html#Project_Explorer_View
https://xy2401.com/local-doc-help.eclipse.org-2019-06.zh/org.eclipse.tracecompass.doc.user/doc/LTTng-Kernel-Analysis.html#Resources_View

源码安装,ok,demo,ok

sudo apt install libpopt-dev
sudo apt install libxml2-dev
wget https://lttng.org/files/lttng-tools/lttng-tools-latest-2.13.tar.bz2
tar -xf lttng-tools-latest-2.13.tar.bz2
cd lttng-tools-2.13.*
./configure
make
sudo make install
sudo ldconfig
补充安装包
apt install pkg-config

安装liburcu

这里说明liburcu库没有安装
liburcu库官方网址：http://lttng.org/urcu
我们安装一下：
压缩包下载地址：https://lttng.org/files/urcu/?O=D
我选择了https://lttng.org/files/urcu/userspace-rcu-0.13.0.tar.bz2
在这里插入图片描述
解压并编译安装：

1
2
3
4
5
6

wget https://lttng.org/files/urcu/userspace-rcu-0.13.0.tar.bz2  
tar -xf userspace-rcu-0.13.0.tar.bz2  
cd userspace-rcu-0.13.0/  
./configure  
make  
make install

返回执行：LTTng-tools configure

错误:configure: error: Package requirements (lttng-ust >= 2.13) were not met

LTTng-UST

1
2
3
4
5
6

wget https://lttng.org/files/lttng-ust/lttng-ust-latest-2.13.tar.bz2  
tar -xf lttng-ust-latest-2.13.tar.bz2  
cd lttng-ust-2.13.*  
./configure --disable-numa  
make  
make install

补充安装：
apt-get install libnuma-dev(略)
返回执行：LTTng-tools configure，ok

继续执行LTTng-tools make

继续执行LTTng-tools make install

安装babeltrace2

1
2
3

apt-add-repository ppa:lttng/ppa  
apt-get update  
apt-get install babeltrace2

样例lttng_ust_tracef()，ok

简洁安装,安装ok,demo报错make error

从Ubuntu 12.04开始，LTTng的包可以直接从包管理器的仓库里找到，所以安装变得非常简单：
sudo aptitude install lttng-tools

lttng_ust_tracef()

aptitude install lttng-tools liblttng-ust-dev
再次make

Tracef用途说明

简单来说，分析程序各函数的运行准确时间，最简单的strace,但只能分析内核态的，无法分析用户态的。另一个常用的perf工具，存在较大缺陷（可以分析相对时间占比，但无法分析函数的绝对时间起点终点）。所以需要用户态的类似strace的工具，
找到这篇文章
用户空间程序的函数跟踪器 (Function Tracer)：https://www.cnblogs.com/slgkaifa/p/6919967.html

源码下载解压

下载地址：https://i-red.info/docs/rpm/stray_rpms/tracef/
解压：tar -xzvf tracef-0.16.org.tar.gz
后续安装流程

1
2
3
4

$ cd tracef-0.xx  
$ ./configure  
$ cd src  
$ make

make结果生成的 src/tracef 就是追踪器。

configure报错解决

报错：configure: error: libdwarf is not found

解决：ubuntu中安装libdwarf：www.360doc.com/content/12/0530/10/9012802_214677679.shtml
sudo apt-get install elfutils

报错：configure: error: libiberty is not found

GCC编译器原理（一）03——GCC 工具：gprof、ld、libbfd、libiberty 和libopcodes:https://www.cnblogs.com/kele-dad/p/9471248.html
sudo apt-get install libiberty-dev
sudo apt-get install binutils-dev

报错：configure: error: libboost is not found

sudo apt-get install libboost-all-dev

报错：configure: error: libelf is not found

sudo apt install libelf-dev.

又回到这个问题：configure: error: libdwarf is not found

参考：
编译安装 libdwarf 记录:https://blog.csdn.net/m0_47696151/article/details/121641019
还是不行，
再参考：
Install libdwarf.so on Ubuntu:https://askubuntu.com/questions/502749/install-libdwarf-so-on-ubuntu
sudo apt-get install libelf-dev libdwarf-dev

至此./configure执行ok

Make报错解决

报错：prototype_add_elf

解决：
修改源码，ftrace/prototype.cpp第 38 和 53 行elf& 改为 hoge::elf&

报错：asm/user.h

解决：
修改源码，printer.cpp将第 17 行更改#include <asm/user.h>为#include <sys/user.h>

解决：同上，修改文件trace.cpp

报错：CHAR_BIT

解决：trace.cpp，增加#include

报错：print_insn_i386_att

Compiler error on Fedora:https://github.com/ThoughtGang/opdis/issues/20
尝试：低版本gcc，不好使，脚本使用编译命令是g++
使用低版本g++，7.x不行，6.5不行，5.5

g++5.5报错:uintprt_t

问题：uintptr_t，修改mani.c增加#include <stdint.h>
再次编译,问题依旧在。

根据之前参考文章，这个报错主要原因是头文件应该是opcodes/disassemble.h而非当前dis-asm.h，但本机其实没有opcodes/ disassemble.h

安装opcodes/ disassemble.h

尝试01:安装binutils

https://sourceware.org/legacy-ml/gdb-patches/2017-06/msg00303.html

1
2
3
4
5
6
7
8
9
10
11
12

As a result, these print\_insn\_XXX are not used  
out of opcodes, so this patch also moves their declarations from  
include/dis-asm.h to opcodes/disassemble.h. With this change,  
GDB doesn't use any print\_insn\_XXX directly any more.  
opcodes/disassemble.h.=》  
https://fossies.org/linux/binutils/opcodes/disassemble.h  

**binutils-2.40.tar.xz**:  
=>  
Linux下载安装Binutils工具集:https://blog.csdn.net/qq_40994908/article/details/123708345  
安装后还是没有opcodes/disassemble.h  
此路不通。

尝试02：安装binutils-gdb.git

我想制作 tracef(hogetrce)。错误：未声明 print_insn_i386_att：https://teratail.com/questions/207929
=》
显然，函数 print_insn_i386_att 已从头文件 <dis-asm.h> 移至另一个头文件。
将 print_insn_XXX 移动到操作码内部标头
也许在目的地读取头文件会更好，但如果不存在这样的文件，即使包含似乎是目的地的 opcodes/disassemble.h 也会出错。
=》
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=88c1242dc0a1e1ab582a65ea8bd05eb5f244c59b
make install报错了，
尝试搜索disassemble.h，

依然找不到。所以说明还是不行

云机器01

sudo apt-get install libelf-dev
sudo apt-get install binutils-dev
sudo apt-get install elfutils
sudo apt-get install libboost-all-dev
sudo apt-get install libelf-dev libdwarf-dev
sudo apt-get install libiberty-dev
sudo apt-get install binutils-dev
下载源码：
wget https://i-red.info/docs/rpm/stray_rpms/tracef/tracef-0.16.org.tar.gz

configure ok

Make

这个是之前遇到过的问题，解决方案同上，类似问题全部忽略，按照之前处理方式即可

报错：print_insn_i386_att

尝试01: 安装binutils

Linux下载安装Binutils工具集：https://blog.csdn.net/qq_40994908/article/details/123708345

1
2
3
4
5
6

wget http://ftp.gnu.org/gnu/binutils/binutils-2.40.tar.gz \# 下载  
tar -xzvf binutils-2.40.tar.gz \# 解压  
cd binutils-2.40/ \# 定位到Binutils的目录  
./configure --prefix=/usr/local/binutils # 设置安装目录    
make \# GNU中的工具  
make install \# 执行安装命令

执行make命令时报错：

报错makeinfo

解决：sudo apt-get install texinfo

报错：bison

解决：

1
2
3
4
5
6
7

jq configure: error: You need bison version 3.0 or greater:https://blog.cpming.top/p/configure-error-need-bison-version-30-or-greater  
$ wget ftp://ftp.gnu.org/gnu/bison/bison-3.6.tar.xz  
$ tar xf bison-3.6.tar.xz  
$ cd bison-3.6  
$ ./configure  
$ make  
$ make install

成功执行，说明bison安装本身是成功的

继续binutil

Make
核实：binutils里面确实有我们需要的h头文件

但不包含再include中，所以
cp –r opcodes include/ #希望make install时自动带过去
make成功

Make install成功

但是，安装后核实，发现好像依然没有disassemble.h文件。

修改：xelf.h文件

Make尝试编译：

通过拷贝头文件，文件夹的方式越过这个问题，可以认为安装binutils的目的达到了。

报错： cannot convert ‘bfd* const’ to ‘const asection’ {aka ‘const bfd_section’}

tracef make操作
xelf.cpp:248:33: error: cannot convert ‘bfd* const’ to ‘const asection’ {aka ‘const bfd_section’}

通过这几个参考
Build failure with binutils@2.34 #242:https://github.com/HPCToolkit/hpctoolkit/issues/242
OProfile Bugs：https://sourceforge.net/p/oprofile/bugs/292/

binutils版本问题

典型版本界限:2.33，2.34，

尝试2.32

1
2
3
4
5
6
7
8
9
10
11

wget http://ftp.gnu.org/gnu/binutils/binutils-2.32.tar.gz \# 下载  
tar -xzvf binutils-2.32.tar.gz \# 解压  
cd binutils-2.32/ \# 定位到Binutils的目录  
./configure --prefix=/usr/local/binutils # 设置安装目录    
make \# GNU中的工具  
make install \# 执行安装命令  
头文件覆盖：  
cd /usr/include; rm -rf opcodes/  
cd ~/binutils-2.32; cp -r opcodes /usr/include/  
cd /root/tracef-0.16;./configure;cd src;  
make clean;make

同样的问题

尝试2.34

1
2
3
4
5
6
7
8
9
10
11

wget http://ftp.gnu.org/gnu/binutils/binutils-2.34.tar.gz \# 下载  
tar -xzvf binutils-2.34.tar.gz \# 解压  
cd binutils-2.34/ \# 定位到Binutils的目录  
./configure --prefix=/usr/local/binutils # 设置安装目录    
make \# GNU中的工具  
make install \# 执行安装命令  
头文件覆盖：  
cd /usr/include; rm -rf opcodes/  
cd ~/binutils-2.34; cp -r opcodes /usr/include/  
cd /root/tracef-0.16;./configure;cd src;  
make clean;make

同样问题

V3报错:checking size of void *… configure: error: cannot compute sizeof (void *), 77

重新解压出新的tracef代码，然后编译，还是这个问题，说明底层某些东西已经不对了。
Gcc，G++版本都是采用较新的，一样的问题

云机器02

Make

报错：print_insn_i386_att

通过apt下载源码binutils-dev

1
2
3

root@iZ2ze18upen0x3frvar3bsZ:~/binutils-2.34# find . -name disassemble.h  
./opcodes/disassemble.h  
cp -rf opcodes /usr/include/

修改：xelf.h文件

Make尝试编译：

报错: cannot convert ‘bfd* const’ to ‘const asection’ {aka ‘const bfd_section’}

更新binutil版本
https://launchpad.net/ubuntu/+source/binutils/2.40-2ubuntu1
下载2.40

1
2
3
4
5
6

tar xvJf binutils_2.40.orig.tar.xz  
cd binutils-2.40/  
apt-get install texinfo  
sudo apt-get install bison  
make  
make install

头文件覆盖: cp -rf opcodes /usr/include/
回到~/tracef-0.16/src#,依然报错

错误更多了

参考信息

CentOS 7 へ 関数コールトレーサ tracef (hogetrace) をインストール：https://qiita.com/kanejun_x/items/455d2d5dc6cde4d8c337

源码：https://cdn.kernel.org/pub/linux/kernel/tools/perf/v5.9.0/perf-5.9.0.tar.gz
或者：linux-tools-common,linux-tools-4.4.0-62-generic
在线手册：https://man7.org/linux/man-pages/man1/perf-stat.1.html
命令大全手册：Linux性能分析工具合集之——perf（一）：命令介绍：https://zhuanlan.zhihu.com/p/544496209
支持多线程，支持内核态，用户态

基础原理

ftrace的跟踪方法是一种总体跟踪法，换句话说，你统计了一个事件到下一个事件所有的时间长度，然后把它们放到时间轴上，你可以知道整个系统运行在时间轴上的分布（这部分可参考，参考文献，一文搞懂 | Ftrace 的实现原理）。这种方法准确度很高，但跟踪成本也很高。
perf提供的是一种抽样形态的跟踪方法。其原理是：每隔一个固定的时间，就在CPU上（每个核上都有）产生一个中断，在中断上看看，当前是哪个pid，哪个函数，然后给对应的pid和函数加一个统计值，这样，我们就知道CPU有百分几的时间在某个pid，或者某个函数上了。这个原理图示如下：

perf使用更多是CPU的PMU计数器，PMU计数器是大部分CPU都有的功能，它们可以用来统计比如L1 Cache失效的次数，分支预测失败的次数等。PMU可以在这些计数器的计数超过一个特定的值的时候产生一个中断，这个中断，我们可以用和时钟一样的方法，来抽样判断系统中哪个函数发生了最多的Cache失效，分支预测失效等。
通过改变采样的触发条件可以获得不同的统计数据：
　　以时间点 ( 如 tick) 作为事件触发采样便可以获知程序运行时间的分布。
以 cache miss 事件触发采样便可以知道 cache miss 的分布，即 cache 失效经常发生在哪些程序代码中。如此等等。
perf 中能够触发采样的事件有哪些。
事件分为以下三种：
　　1）Hardware Event 是由 PMU 硬件产生的事件，比如 cache 命中，当您需要了解程序对硬件特性的使用情况时，便需要对这些事件进行采样；
　　2）Software Event 是内核软件产生的事件，比如进程切换，tick 数等 ;
　　3）Tracepoint event 是内核中的静态 tracepoint 所触发的事件，这些 tracepoint 用来判断程序运行期间内核的行为细节，比如 slab 分配器的分配次数等。
上述每一个事件都可以用于采样，并生成一项统计数据，时至今日，尚没有文档对每一个 event 的含义进行详细解释。

命令概况

全局性概况：
perf list**查看当前系统支持的性能事件；**
perf bench对系统性能进行摸底；
perf test对系统进行健全性测试；
perf stat**对全局性能进行统计；**
全局细节：
perf top可以实时查看当前系统进程函数占用率情况；
perf probe可以自定义动态事件；
特定功能分析：
perf kmem针对slab的系统性能分析；
perf kvm针对kvm虚拟化分析；
perf lock分析锁性能；
perf mem分析内存slab性能；
perf sched分析内核调度器性能；
perf trace记录系统调用轨迹；
最常用功能perf record，可以系统全局，也可以具体到某个进程，更可以具体到某一进程某一事件；可宏观，也可以很微观。
pref record记录信息到perf.data；
perf report生成报告；
perf diff对两个记录进行diff；
perf evlist列出记录的性能事件；
perf annotate**显示perf.data函数代码；**
perf archive将相关符号打包，方便在其它机器进行分析；
perf script将perf.data输出可读性文本；
可视化工具perf timechart
perf timechart record记录事件；
perf timechart生成output.svg文档；
由于涉及命令太对，不可能依次研究测试，仅测试加粗体部分。

命令详情

perf list

简介

列出当前系统支持的所有性能事件。包括硬件性能事件、软件性能事件以及检查点。
perf list不能完全显示所有支持的事件类型，需要sudo perf list。同时还可以显示特定模块支持的perf事件：hw/cache/pmu都是硬件相关的；tracepoint基于内核的ftrace；sw实际上是内核计数器。
参数：
hw/hardware显示支持的硬件事件相关，如：sudo perf list hardware
sw/software显示支持的软件事件列表：
cache/hwcache显示硬件cache相关事件列表：
pmu显示支持的PMU事件列表：
tracepoint显示支持的所有tracepoint列表，这个列表就比较庞大：
常见命令：
sudo perf list
sudo perf list hardware

示例

sudo perf list

sudo perf list hardware

sudo perf list sw

page fault缺页异常
major page fault，这种类型的缺页可以通过 Disk IO来满足，
minor page fault，这种缺页可以直接利用内存中的缓存页满足。
为什么数据已经被加载内核中的Page Cache了，理论上说直接访问就行了，为什么还要触发一次minor fault呢？
这里给出答案，懂得人可以略过，主要是因为虚拟地址和物理地址的映射关系并没有建立，我们知道Linux进程访问一块内存实际上使用的是虚拟内存，必须把对应虚拟地址空间和物理页面进行了映射才能够正常访问，那么vma结构体实际仅仅表示一个虚拟地址空间，必须把内核中Page Cache中的物理地址与进程vma虚拟地址空间进行映射才能正常被进程访问到
关于cpu-clock和taks-clock

1
2
3
4

PERF\_COUNT\_SW\_CPU\_CLOCK  
This reports the CPU clock, a high-resolution per-CPU timer.  
PERF\_COUNT\_SW\_TASK\_CLOCK  
This reports a clock count specific to the task that is running.

Stackoverflow上的解释:

1
2
3
4

1) By default, **perf stat shows task-clock,** and does not show cpu-clock. Therefore we can tell task-clock was expected to be **much more useful.**  
2) cpu-clock was simply **broken**, and **has not been fixed for many years. It is best to ignore it**.  
It was intended that **cpu-clock of sleep 1 would show about 1 second. In contrast, task-clock would show close to zero**. It would have made sense to use cpu-clock to read wall clock time. You could then look at the ratio between cpu-clock and task-clock.  
But **in the current implementation, cpu-clock is equivalent to task-clock**. It is even possible that "fixing" the existing counter might break some userspace program. If there is such a program, Linux might not be able to "fix" this counter. Linux might need to define a new counter instead.

perf stat

简介

执行某个命令，收集特定进程的性能概况，包括CPI、Cache丢失率等。虽然perf top也可以指定pid，但是必须先启动应用才能查看信息。perf stat能完整统计应用整个生命周期的信息。
参数：

1
2
3
4
5
6
7
8
9

-e：选择性能事件  
-i：禁止子任务继承父任务的性能计数器。  
-r：重复执行 n 次目标程序，并给出性能指标在n 次执行中的变化范围。  
-n：仅输出目标程序的执行时间，而不开启任何性能计数器。  
-a：指定全部cpu  
-C：指定某个cpu  
-A：将给出每个处理器上相应的信息  
-p：指定待分析的进程id  
-t：指定待分析的线程id

常用命令：

1
2
3

分析系统：sudo perf stat -a ^C  
特定应用：sudo perf stat -a gst-launch-1.0 videotestsrc ! Autovideosink  
采集特定进程：perf stat -p 997 #997最好是长时间运行程序

测量多个事件，只需提供一个用逗号分隔的列表，其中没有空格：

1

perf stat -e cycles,instructions,cache-misses \[...\]

示例

1
2
3
4
5
6
7
8
9

 Task-clock-msecs：CPU 利用率，该值高，说明程序的多数时间花费在 CPU 计算上而非 IO。  
 Context-switches：进程切换次数，记录了程序运行过程中发生了多少次进程切换，频繁的进程切换是应该避免的。  
 Cache-misses：程序运行过程中总体的 cache 利用情况，如果该值过高，说明程序的 cache 利用不好  
 CPU-migrations：表示进程 t1 运行过程中发生了多少次 CPU 迁移，即被调度器从一个 CPU 转移到另外一个 CPU 上运行。  
 Cycles：处理器时钟，一条机器指令可能需要多个 cycles，  
Instructions: 机器指令数目。  
 IPC：是 Instructions/Cycles 的比值，该值越大越好，说明程序充分利用了处理器的特性。  
Cache-references: cache 命中的次数  
Cache-misses: cache 失效的次数。

仅测量用户级别，有增加一个修饰词

所有用户态，用*:u？实测不行

perf record

简介

收集采样信息，并将其记录在数据文件perf.data中。随后可通过perf report对数据文件进行分析。
perf record和perf report可以更精确的分析一个应用，perf record可以精确到函数级别。并且在函数里面混合显示汇编语言和代码。
参数：

1
2
3
4
5
6
7
8
9
10

-e：选择性能事件  
-p：待分析进程的id  
-t：待分析线程的id  
-a：分析整个系统的性能  
-C：只采集指定CPU数据  
-c：事件的采样周期  
-o：指定输出文件，默认为perf.data  
-A：以append的方式写输出文件  
-f：以OverWrite的方式写输出文件  
-g：记录函数间的调用关系

常见命令：

1
2
3
4
5

sudo perf record -a -g ./demo6  
sudo perf record -a -g ./demo6：会在当前目录生成perf.data文件。  
sudo perf report --call-graph none结果如下,后面结合perf timechart分析.  
sudo perf report --call-graph none -c fork  
perf record -p \`pgrep -d ',' nginx\` #记录nginx进程的性能数据

特定频率采样特定进程：

1

perf record -F 999 -p 997 #采样频率设置为999Hz，每秒采样999次

示例

perf report

简介

读取perf record创建的perf.data数据文件，并给出热点分析结果。
参数：

1
2
3

-i：输入的数据文件  
-c：只显示指定cpu采样信息  
-p, --parent <regex> regex filter to identify parent, see: '--sort parent'

常用命令：

1
2

sudo perf report -i perf.data  
sudo perf report -c fork-g #问题，上面的是全家桶信息分析，下面的时特定app的分析，那么report 后选Zoom into fork-g

thread后界面和上面命令，当前命令区别是啥
或者直接annotate
annotate 来单独分析函数信息：sudo perf annotate func2

示例

sudo perf report

字段含义：

1
2
3
4
5
6
7
8
9
10
11

Children：总时间（包含调用其他函数事件）  
Self：单纯函数自身执行时间（调用其他函数的不算）  
敲击Enter键，perf给出了一些选项。通过这些选项，我们可以进一步分析这个函数。  
Annotate print --\- 分析print函数中指令或者代码的性能  
Zoom into test thread --\- 聚焦到线程 test  
Zoom into test DSO --\- 聚焦到动态共享对象test  
Browse map details --\- 查看map  
Run scripts for samples of thread \[test\]--- 针对test线程的采样运行脚本  
Run scripts for samples of symbol \[test\] --- 针对函数的采样运行脚本    
Run scripts for all samples --\- 针对所有采样运行脚步  
Switch to another data file in PWD --- 切换到当前目录中另一个数据文件

问题：report -c demo6 进去在出来后不同（单进程的）
sudo perf report -c demo6，显示左1
之后进到main中，再zoom into demo6 thread，则显示左二，二者应该是相同的吧。

1
2

sudo perf report -D  
 -D, --dump-raw-trace dump raw trace in ASCII

问题：这个和perf script结果差异较大

根据paraent过滤：sudo perf report -g -c demo6 –parent main
问题：右侧和other也会混进来，而且main也不会那么多

导出到文件：perf report -i perf.data > perf.txt
控制显示字段

1

sudo perf report -g -c demo6 -F sample,period,pid,symbol,parent,cpu,transaction,trace,time,local_weight,weight,trace

不好理解：demo6而言libc_start_main只会执行一次，为何下面这么多？Func1，func2一样的。

显示超过一定阈值的记录

1
2
3

sudo perf report -c demo6 --percent-limit 1.0  
--percentage <relative|absolute>  
 how to display percentage of filtered entries

显示总时间，采集次数
sudo perf report -c demo6 –show-total-period –n

限制采集层次
sudo perf report -c demo6 –percent-limit 1.0 –show-total-period -n –max-stack 4

问题：不用-g进行编译，一样可以分析出结果，todo why

使用-g编译，分析出结果

想进一步切入函数内部？汇编级别解析。
annotate 来单独分析函数信息：sudo perf annotate func2

perf timechart

简介

针对测试期间系统行为进行可视化的工具。

1
2
3
4

perf timechart record <option> <command>用于记录整个系统或者一个应用的事件，还可以加option记录指定类型的事件。  
perf timechart用于将perf.data转换成SVG格式的文件，SVG可以通过Inkscape或者浏览器打开。  
perf timechart record可以指定特定类型的事件：  
perf timechart用于将perf timechart record录取的perf.data转换成output.svg。

-w调整输出的svg文件长度，可以查看更多细节。
-p可以指定只查看某些进程输出，使用方式：sudo perf timechart -p test1 -p thermald
当线程太多影响svg解析速度的时候，可以通过-p指定特定线程进行分析。如果需要几个线程，每个线程采用-p xxx。
sudo perf timechart record -T ./demo6 && sudo perf timechart –p demo6

示例

1
2
3
4
5
6
7
8
9

# 运行测试程序  
 root:/# ./test &  
# 采样  
 root:/# perf timechart record  
 ^C\[ perf record: Woken up 0 times to write data \]  
 [ perf record: Captured and wrote 3.140 MB perf.data (30458 samples) \]  
# 生成svg文件  
 root:/# perf timechart  
 Written 0.6 seconds of trace to output.svg.

只能做基础的缩放动作，其他动作均不响应。

1
2
3
4
5
6
7
8
9

sudo perf timechart record –T  
-P, --power-only  
 Record only power-related events  
-T, --tasks-only  
 Record only tasks-related events  
-I, --io-only  
 Record only io-related events  
-g, --callchain  
 Do call-graph (stack chain/backtrace) recording

问题：上面几个图和参数的关系，感觉参数含义注解和图含义对应不起来
sudo perf timechart –highlight demo6

采集特定的app，命令行传入app或指定pid
问题：采集特定app，支持，但实际依然是全局采集，还需要结合pid过滤

采集特定pid：可采用显示时过滤方式，
-p, –process
Select the processes to display, by name or PID
sudo perf timechart record ;sudo perf timechart -p 1330371

上部的cpu部分并没有少（直观理解应该只显示demo6相关进程），但底部的app变少了。
sudo perf timechart -p demo6

和上面结果还是有差异的，截图底部少了一个进程，主要是bash进程。

xperf script

简介

执行perl或python写的功能扩展脚本、生成脚本框架、读取数据文件中的数据信息等。
Tom Zanussi 将 perl 和 python 解析器嵌入到 perf 程序中，从而使得 perf 能够自动执行 perl 或者 python 脚本进一步进行处理，从而为 perf 提供了强大的扩展能力。因为任何人都可以编写新的脚本，对 perf 的原始输出数据进行所需要的进一步处理。这个特性所带来的好处很类似于 plug-in 之于 eclipse。
参数:

1
2
3
4
5
6

 --header，实测多了无用的header信息  
 --deltatime Show time stamps relative to previous event，多了一个时间列  
--show-info display extended information from perf.data file ，实测无变化  
 --list list available scripts，报错如下  
 open(/usr/libexec/perf-core/scripts) failed.  
 Check "PERF\_EXEC\_PATH" env to set scripts dir.

示例

基础命令，解析perf.data内容

字段含义：

perf probe

用于定义动态检查点。
详情参考：暂不做重点研究，不可能每个函数手工添加检查点
perf probe笔记:https://blog.csdn.net/qq_38349235/article/details/126143881

简介

能够动态地在想查看的地方插入动态监测点
root@VM-0-9-ubuntu:~#perf probe schedule:12 cpu
上例利用 probe 命令在内核函数 schedule() 的第 12 行处加入了一个动态 probe 点，和 tracepoint 的功能一样，内核一旦运行到该 probe 点时，便会通知 perf。可以理解为动态增加了一个新的 tracepoint

示例

定义追踪的事件：sudo perf probe –add tcp_sendmsg –f
追踪1s内的系统事件：sudo perf record -e probe:tcp_sendmsg_1 -aR sleep 1
查看结果：perf script

各字段含义：
Name pid CPU time/us group:event address
test 15423 [002] 12704.994176 probe_test:show_entry (555b8f07b4)

xperf sched

简介

perf sched提供了许多工具来分析内核CPU调度器的行为。你可以用它来识别和量化调度器延迟的问题。
参数：

1
2
3
4
5
6

record <command>：记录测试过程中的调度事件  
latency：报告线程调度延时和其他调度相关属性  
script：查看执行过程中详细的trace信息  
replay：回放record录制的执行过程  
map:用字符表示打印上下文切换  
perf sched timehist：每一次任务切换的信息都展现出来，就更能知道每一次延迟是怎样发生的。

统计每轮 task switch 时，之前在 CPU 上运行的那个 “prev” 线程得到的执行时间 (run time) ，以及该线程在获得这次执行机会前的休眠态等待 (wait time) 和运行态等待 (sch delay) 时间

示例

perf sched latency

Task：进程的名字和 pid
Runtime：实际运行时间
Switches：进程切换的次数
Average delay：平均的调度延迟
调度延迟：调度延迟是保证每一个可运行进程都至少运行一次的时间间隔，翻译一下，是指一个task的状态变成了TASK_RUNNING，然后从进入 CPU 的runqueue开始，到真正执行（获得 CPU 的执行权）的这段时间间隔。
调度周期，调度周期的含义就是所有可运行的task都在CPU上执行一遍的时间周期，而Linux CFS中这个值是不固定的，当进程数量小于8的时候，sched period就是一个固定值6ms，如果runqueue数量超过了8个，那么就保证每个task都必须运行一定的时间，这个一定的时间还叫最小粒度时间，CFS的默认最小粒度时间是0.75ms，使用sysctl_sched_min_granularity保存。
Maximum delay：最大延迟
perf sched timehist：每次任务切换的信息都展现出来

更详细的任务切换信息

问题：字段解析样例，没看懂

此处也用到了 “sched_wakeup” 和 “sched_switch” 这 2 个 tracepoint，后者的时间点（上图红框部分）和前面 “timehist” 输出的第一列完全吻合，而如果 “wakeup” 和 “switch” 是前后连在一起的，那两者的时间差正好是 “timehist” 输出中第五列 “sch delay” 的时长。
另外，”script” 还包括了 “sched_stat_runtime”，其统计的是每两次 task switch 之间的 “runtime”（上图蓝框部分），求和的话，就正好等于 “timehist” 输出中第六列 “run time” 的时长。
update_curr() –> trace_sched_stat_runtime
事实上，在使用 “timehist” 功能时，如果加上 “-wn –state” 的参数，也能显示一个任务被 awaken 的时刻，和作为 “prev” 的线程 schedule-out 后的状态。

perf trace

简介

strace inspired tool（类似strace）。
参数：

1
2
3
4
5
6
7
8

-p, --pid <pid> trace events on existing process id  
-s, --summary Show only syscall summary with statistics  
-t, --tid <tid> trace events on existing thread id  
--filter <filter> event filter  
--filter-pids <CSV list of pids> pids to filter (by the kernel)  
-D msecs, --delay msecs After starting the program, wait msecs before measuring. This is useful to filter out the startup phase of the program, which is often very different.  
-o, --output= Output file name.  
sudo perf trace –s

特定进程：perf trace -p $PID -s

示例

sudo perf trace –s

sudo perf trace ls

问题：字段含义找不到相关说明

问题：都是系统调用，没有针对用户态函数的统计

strace

简介

strace 究竟能做什么呢？
它能够打开应用进程的这个黑盒，通过系统调用的线索，告诉你进程大概在干嘛。
strace 有两种运行模式。
一种是通过它启动要跟踪的进程。用法很简单，在原本的命令前加上 strace 即可。比如我们要跟踪 “ls -lh /var/log/messages” 这个命令的执行，可以这样：
strace ls -lh /var/log/messages
另外一种运行模式，是跟踪已经在运行的进程，在不中断进程执行的情况下，理解它在干嘛。 这种情况，给 strace 传递个 -p pid 选项即可。
Strace典型使用场景，参考：
strace 可以解决什么问题？ | Linux 中国:https://zhuanlan.zhihu.com/p/362348075
案例三：用调试工具掌握软件的工作原理：https://blog.51cto.com/ahuo/5317283
Strace的介绍与使用:https://www.cnblogs.com/skandbug/p/16264609.html

示例

strace -c 统计系统调用分析的结果

strace -T 打印每个系统调用所花的时间

字段含义：函数，入参，返回值

使用方法步骤

其他

工具的宏观理解
两部分：
第一部分：非严谨采样方法，某个特定事件，总发生再哪些地方，
特例：如果这个特定时间是时钟周期，那么统计就是各函数的运行时间
第二部分：严谨的统计方法，特定系统函数(接口)的调用次数，各次调用时间，以及基于此的相关统计量。
Perf是对一系列内核工具的封装的简易接口（工具），或者和其他工具的对标。
常见问题：
问题01
Perf report为例，实际调用链应该非常深的，实际看起来还行，主要原因是只会在对内核态的采集，只会再检查点检查，并非所有函数都显示。
目前测试结果看，用户态的是全部显示的，可以采用层次过滤，稍微控制下
问题02

事件可以指定后缀，比如我想只跟踪发生在用户态时产生的分支预测失败，我可以这样：
sudo perf top -e branch-misses:u,cycles
全部事件都有这个要求，我还可以：
sudo perf top -e ‘{branch-misses,cycles}:u’
看看perf-list的手册，会找到更多的后缀，后缀我也用得比较少，读者对这个有兴趣，可以自己深入挖掘一下，如果有什么好的使用经验，希望也可以告诉我。
火焰图：参考，https://blog.csdn.net/xuhaitao23/article/details/124016932
perf sched replay 这个工具更是专门为调度器开发人员所设计，它试图重放 perf.data 文件中所记录的调度场景。很多情况下，一般用户假如发现调度器的奇怪行为，他们也无法准确说明发生该情形的场景，或者一些测试场景不容易再次重现，或者仅仅是出于“偷懒”的目的，使用 perf replay，perf 将模拟 perf.data 中的场景，无需开发人员花费很多的时间去重现过去，这尤其利于调试过程，因为需要一而再，再而三地重复新的修改是否能改善原始的调度场景所发现的问题。
perf 记录的默认行为是什么？：https://qa.1r1g.com/sf/ask/4744087631/

锁

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# perf lock record ls #记录  
# perf lock report #报告  
 Name acquired contended total wait (ns)  max wait (ns) min wait (ns)  
 &mm->page\_table\_... 382 0 0 0 0  
 &mm->page\_table\_... 72 0 0 0 0  
 &fs->lock 64 0 0 0 0  
 dcache_lock 62 0 0 0 0  
 vfsmount_lock 43 0 0  0 0  
  &newf->file_lock... 41 0 0 0 0  
Name：内核锁的名字。  
aquired：该锁被直接获得的次数，因为没有其它内核路径占用该锁，此时不用等待。  
contended：该锁等待后获得的次数，此时被其它内核路径占用，需要等待。  
total wait：为了获得该锁，总共的等待时间。  
max wait：为了获得该锁，最大的等待时间。  
min wait：为了获得该锁，最小的等待时间。

内存

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# perf kmem record ls #记录  
# perf kmem stat --caller --alloc -l 20 #报告  
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-  
 Callsite | Total\_alloc/Per | Total\_req/Per | Hit | Ping-pong | Frag  
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-  
 perf\_event\_mmap+ec | 311296/8192 | 155952/4104 | 38 |    0 | 49.902%  
 proc\_reg\_open+41 | 64/64 | 40/40 | 1 | 0 | 37.500%  
 \_\_kmalloc\_node+4d | 1024/1024 | 664/664 | 1 | 0 | 35.156%  
 ext3_readdir+5bd    | 64/64 | 48/48 | 1 | 0 | 25.000%  
 load\_elf\_binary+8ec | 512/512 | 392/392 | 1 | 0 | 23.438%  
Callsite：内核代码中调用kmalloc和kfree的地方。  
Total_alloc/Per：总共分配的内存大小，平均每次分配的内存大小。  
Total_req/Per：总共请求的内存大小，平均每次请求的内存大小。  
Hit：调用的次数。  
Ping-pong：kmalloc和kfree不被同一个CPU执行时的次数，这会导致cache效率降低。  
Frag：碎片所占的百分比，碎片 = 分配的内存 \- 请求的内存，这部分是浪费的。  
有使用--alloc选项，还会看到Alloc Ptr，即所分配内存的地址。

调度

1
2
3
4
5
6
7
8
9
10

# perf sched record sleep 10     
# perf report latency --sort max     
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-  
Task | Runtime ms | Switches | Average delay ms | Maximum delay ms | Maximum delay at |  
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-  
events/10:61 | 0.655 ms | 10 | avg: 0.045 ms | max: 0.161 ms | max at: 9804.958730 s  
sleep:11156 | 2.263 ms | 4 | avg: 0.052 ms | max: 0.118 ms | max at: 9804.865552 s  
edac-poller:1125 | 0.598 ms | 10 | avg: 0.042 ms | max: 0.113 ms | max at: 9804.958698 s  
events/2:53 | 0.676 ms | 10 | avg: 0.037 ms | max: 0.102 ms | max at: 9814.751605 s  
perf:11155 | 2.109 ms | 1 | avg: 0.068 ms | max: 0.068 ms | max at: 9814.867918 s

TASK：进程名和pid。
Runtime：实际的运行时间。
Switches：进程切换的次数。
Average delay：平均的调度延迟。
Maximum delay：最大的调度延迟。
Maximum delay at：最大调度延迟发生的时刻。

原理：堆栈分析

在Linux下做性能分析3：perf:https://zhuanlan.zhihu.com/p/22194920
==堆栈跟踪==
perf的跟踪有一个错觉需要我们注意，假设我们有一个函数abc()，调用另一个函数def()，在perf的统计中，这两者是分开统计的，就是说，执行def的时间，是不计算abc的时间的，图示如下：

这里，abc()被击中5次，def()被击中5次，ghi被击中1次。这会给我们不少错觉，似乎abc的计算压力不大，实际上不是，你要把def和ghi计算在内才行。
但这又带来另一个问题：可能def不仅仅是abc这个函数调用啊，别人也会调用它呢，这种情况，我们怎么知道是谁导致的？
这种情况我们可以启动堆栈跟踪，也就是每次击中的时候，向上回溯一下调用栈，让调用者也会被击中，这样就就更容易看出问题来，这个原理类似这样：

这种情况，abc击中了11次，def击中了6次，而ghi击中了1次。这样我们可以在一定程度上更容易判断瓶颈的位置。-g命令可以实现这样的跟踪，下面是一个例子：

使用堆栈跟踪后，start_thread上升到前面去了，因为正是它调的heavy_cal。
使用堆栈跟踪要注意的是，堆栈跟踪受扫描深度的限制，太深的堆栈可能回溯不过去，这是有可能影响结果的。
另一个问题是，有些我们从源代码看来是函数调用的，其实在汇编一级并不是函数调用。比如inline函数，宏，都不是函数调用。另外，gcc在很多平台中，会自动把很短的函数变成inline函数，这也不产生函数调用。还有一种是，fastcall函数，通过寄存器传递参数，不会产生调用栈，也有可能不产生调用栈，这个通过调用栈回溯是有可能看不到的。
还有一种更奇葩的情况是，部分平台使用简化的堆栈回溯机制，在堆栈中看见一个地址像是代码段的地址，就认为是调用栈，这些情况都会引起堆栈跟踪上的严重错误。使用者应该对系统的ABI非常熟悉，才能很好驾驭堆栈跟踪这个功能的。
问题：这里的perf原理的函数嵌套和实际测试不大相符，进一步验证
Perf的原理、编译以及使用：https://blog.csdn.net/u013983194/article/details/112209853
每隔一个固定时间，CPU上产生一个中断，看当前是哪个进程、哪个函数，然后给对应的进程和函数加一个统计值，这样就知道CPU有多少时间在某个进程或某个函数上了。具体原作原理就是直接通过系统调用syscall/ioctl或者监听SW的event来看性能。
在Linux下做性能分析3：perf：https://zhuanlan.zhihu.com/p/22194920
读取和解析perf.data：https://qa.1r1g.com/sf/ask/834528971/
读取和解析perf.data
我正在使用命令perf record来记录性能计数器frm linux。
我想将结果perf.data用作其他编程应用程序的输入。您知道如何读取和解析其中的数据perf.data吗？有没有办法将其转换为.text文件或.csv？
带有子命令“script”的linux工具的工具中有内置的perf.data解析器和打印机perf。
转换perf.data文件
perf script > perf.data.txt
要在其他文件 ( perf record -o filename.data) 中转换 perf 记录的输出，请使用-i选项：
perf script -i filename.data > filename.data.txt
perf script记录在man perf-script，可在http://man7.org/linux/man-pages/man1/perf-script.1.html在线获得
perf-script - Read perf.data (created by perf record) and display
trace output
This command reads the input file and displays the trace recorded.
‘perf script’ to see a detailed trace of the workload that was
recorded.
`perf script` 的输出是文本并且是可读的，但是用 python/perl/awk/something 脚本解析它可能并不容易。 (2认同)
`perf script` 特别允许使用 python 和 perl 脚本处理 pref 事件。见[`man perf-script-python`](https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/perf-script-python.txt) (2认同)
问题：内核态用户态，event:u解决，全部的用户态事件？未知
perf list,perf evnlist关系
evlist事件和采样频率的联动

其他工具
linux 高级测试性能工具：https://www.lmlphp.com/user/12842/article/item/431835/
无水干货-如何快速分析Linux服务器的性能问题:https://www.linuxprobe.com/performance-issues-linux-servers.html

参考

page fault的两种区别（major、minor）：https://blog.csdn.net/rikeyone/article/details/108623187
Linux perf events: cpu-clock and task-clock - what is the difference:https://stackoverflow.com/questions/23965363/linux-perf-events-cpu-clock-and-task-clock-what-is-the-difference
手把手教你系统级性能分析工具perf的介绍与使用（超详细）:https://blog.csdn.net/youzhangjing_/article/details/124671286
学会使用perf性能分析工具–这一篇就够了：https://qmiller.blog.csdn.net/article/details/123048333?spm=1001.2101.3001.6661.1
用Perf寻找程序中的性能热点（perf step by step）：https://zhuanlan.zhihu.com/p/134721612
【开发工具】【perf】性能分析工具perf的编译和使用说明:https://blog.csdn.net/Ivan804638781/article/details/122700909
一文搞懂 | Ftrace 的实现原理：https://blog.csdn.net/melody157398/article/details/120124294
简洁说明
perf –help之后可以看到perf的二级命令。
序号 命令 作用
1 annotate 解析perf record生成的perf.data文件，显示被注释的代码。
2 archive 根据数据文件记录的build-id，将所有被采样到的elf文件打包。利用此压缩包，可以再任何机器上分析数据文件中记录的采样数据。
3 bench perf中内置的benchmark，目前包括两套针对调度器和内存管理子系统的benchmark。
4 buildid-cache 管理perf的buildid缓存，每个elf文件都有一个独一无二的buildid。buildid被perf用来关联性能数据与elf文件。
5 buildid-list 列出数据文件中记录的所有buildid。
6 diff 对比两个数据文件的差异。能够给出每个符号（函数）在热点分析上的具体差异。
7 evlist 列出数据文件perf.data中所有性能事件。
8 inject 该工具读取perf record工具记录的事件流，并将其定向到标准输出。在被分析代码中的任何一点，都可以向事件流中注入其它事件。
9 kmem 针对内核内存（slab）子系统进行追踪测量的工具
10 kvm 用来追踪测试运行在KVM虚拟机上的Guest OS。
11 list 列出当前系统支持的所有性能事件。包括硬件性能事件、软件性能事件以及检查点。
12 lock 分析内核中的锁信息，包括锁的争用情况，等待延迟等。
13 mem 内存存取情况
14 record 收集采样信息，并将其记录在数据文件中。随后可通过其它工具对数据文件进行分析。
15 report 读取perf record创建的数据文件，并给出热点分析结果。
16 sched 针对调度器子系统的分析工具。
17 script 执行perl或python写的功能扩展脚本、生成脚本框架、读取数据文件中的数据信息等。
18 stat 执行某个命令，收集特定进程的性能概况，包括CPI、Cache丢失率等。
19 test perf对当前软硬件平台进行健全性测试，可用此工具测试当前的软硬件平台是否能支持perf的所有功能。
20 timechart 针对测试期间系统行为进行可视化的工具
21 top 类似于linux的top命令，对系统性能进行实时分析。
22 trace 关于syscall的工具。
23 probe 用于定义动态检查点。

Demo6.cpp源码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

#include <iostream>  
using namespace std;  
void func1() {  
 int i = 0;  
 while (i < 10) {  
 ++i;  
 }  
}  
void func2() {  
 int i = 0;  
 while (i < 20) {  
 ++i;  
 }  
}  
void func3() {  
 for (int i = 0; i < 100; ++i) {  
 func1();  
 func2();  
 }  
}  
void func4() {  
 for (int i = 0; i < 10; ++i) {  
 func3();  
 }  
}  
void func5() {  
 for (int i = 0; i < 10; ++i) {  
 func4();  
 }  
}  
void func6() {  
 for (int i = 0; i < 10; ++i) {  
 func5();  
 }  
}  
void func7() {  
 for (int i = 0; i < 10; ++i) {  
 func6();  
 }  
}  
int main(){  
 func7();  
 return 0;  
}

关于最大采样频率

相关参数：

1
2
3
4
5
6
7

/proc/sys/kernel/  
perf\_cpu\_time\_max\_percent： perf分析工具最大能够占用CPU性能的百分比0：不限制1~100：百分比值  
perf\_event\_max\_sample\_rate：  设置perf_event的最大取样速率，默认值为100000  
perf采样使用会占用cpu，所以默认限制最大是perf\_cpu\_time\_max\_percent=25，超过就会触发告警，并调整采样速率，保持不要超过限制perf\_event\_max\_sample\_rate。  
perf\_cpu\_time\_max\_percent设置为0，此时就不会在去监控cpu的占用率了。  
参考信息: linux - perf 支持的最大采样频率：[https://www.coder.work/article/1509862](https://www.coder.work/article/1509862)  
perf参数问题处理:https://blog.csdn.net/megan_free/article/details/84993547

概述

CPU性能指标
  （1）CPU使用率：
1） 用户态CPU使用率（包括用户态 user 和低优先级用户态 nice）、
2） 系统CPU使用率、
3） 等待 I/O 的CPU使用率、
4） 软中断和硬中断的CPU使用率、
5） 虚拟机占用的CPU使用率。
  （2）平均负载 Load Average：过去 1 分钟、过去 5 分钟和过去 15 分钟的平均负载
  （3）进程上下文切换：
1） 无法获取资源而导致的自愿上下文切换；
2） 被系统强制调度导致的非自愿上下文切换。
  （4）CPU缓存命中率：因为CPU处理速度比内存访问速度快得多，则需要等待内存的响应。为了协调两者性能差距，出现了CPU的多级缓存。缓存命中率，衡量的是CPU缓存的复用情况，命中率越高、复用越多，性能越好。

把提供CPU性能指标的工具做成了一个表格，方便你梳理关系和理解记忆，当然，你也可以当成一个”指标工具”指南来使用。

第二个维度，从工具出发。也就是当你已经安装了某个工具后，要知道这个工具能提供哪些指标。

注意，我在这个图中只列出了最核心的几个性能工具，并没有列出所有。这么做，一方面是不想用大量的工具列表吓到你。在学习之初就接触所有或核心或小众的工具，不见得是好事。另一方面，是希望你能先把重心放在核心工具上，毕竟熟练掌握它们，就可以解决大多数问题。
我相信到这一步，你对CPU的性能指标已经非常熟悉，也清楚每种性能指标分别能用什么工具来获取。
那是不是说，每次碰到CPU的性能问题，你都要把上面这些工具全跑一遍，然后再把所有的CPU 性能指标全分析一遍呢?
你估计觉得这种简单查找的方式，就像是在傻找。不过，别笑话，因为最早的时候我就是这么做的。把所有的指标都查出来再统一分析，当然是可以的，也很可能找到系统的潜在瓶颈。但是这种方法的效率真的太低了! 耗时耗力不说，在庞大的指标体系面前，你一不小心可能就忽路了某个细节，导致白干一场。我就吃过好多次这样的苦。
所以，在实际生产环境中，我们通常都希望尽可能快地定位系统的瓶颈，然后尽可能快地优化性能，也就是要又快又准地解决性能问题。
那有没有什么方法，可以又快又准找出系统瓶颈呢?答案是肯定的。
虽然CPU的性能指标比较多，但要知道，既然都是描述系统的CPU性能，它们就不会是完全孤立的，很多指标间都有一定的关联。想弄清楚性能指标的关联性，就要通晓每种性能指标的工作原理。这也是为什么我在介绍每个性能指标时，都要穿插讲解相关的系统原理，希望你能记住这一点。
举个例子，用户CPU使用率高，我们应该去排查进程的用户态而不是内核态。因为用户CPU 使用率反映的就是用户态的CPU 使用情况，而内核态的CPU使用情况只会反映到系统CPU使用率上。
你看，有这样的基本认识，我们就可以缩小排查的范围，省时省力。
所以，为了缩小排查范围，我通常会先运行几个支持指标较多的工具，如top、vmstat 和pidstat。为什么是这三个工具呢?仔细看看下面这张图，你就清楚了。
这张图里，我列出了 top、vmstat和pidstat 分别提供的重要的CPU指标，并用虚线表示关联关系，对应出了性能分析下一步的方向。
通过这张图你可以发现，这三个命令，几乎包含了所有重要的CPU性能指标比如∶
● 从 top的输出可以得到各种CPU使用率以及僵尸进程和平均负载等信息。
● 从vmstat的输出可以得到上下文切换次数、中断次数、运行状态和不可中断状态的进程数。
● 从 pidstat的输出可以得到进程的用户CPU使用率、系统CPU使用率、以及自愿上下文切换和非自愿上下文切换情况。

CPU使用率

相关命令：top，vmstat，mpstat，iostat -c

平均负载 Load Average

相关命令：uptime,top
系统的平均活跃进程数。Uptime

统计系统当前的运行状况，输出的信息依次为：系统现在的时间、系统从上次开机到现在运行了多长时间、系统目前有多少登陆用户、系统在一分钟内、五分钟内、十五分钟内的平均负载。
这里需要注意的是load average这个输出值，这三个值的大小一般不能大于系统CPU的个数，例如，本输出中系统有8个CPU,如果load average的三个值长期大于8时，说明CPU很繁忙，负载很高，可能会影响系统性能，但是偶尔大于8时，倒不用担心，一般不会影响系统性能。相反，如果load average的输出值小于CPU的个数，则表示CPU还有空闲的时间片，比如本例中的输出，CPU是非常空闲的。

进程上下文切换

相关命令：vmstat，pidstat

CPU缓存命中率（暂无）

相关命令：没找到

案例

CPU使用率过高的总体分析步骤
  Step1：通过 top、pidstat 找到哪个进程CPU使用率过高；
  Step2：通过 perf 找到该进程中具体哪个函数使用过高。$ perf top -g -p
  Step3：通过 grep 查看该函数中的具体内容。$ grep -nr “<function_name>” <file_path>
性能问题：
  （1）用户 CPU 和 Nice CPU 高，说明用户态进程占用了较多的 CPU，所以应该着重排查进程的性能问题。
  （2）系统 CPU 高，说明内核态占用了较多的 CPU，所以应该着重排查内核线程或者系统调用的性能问题。
  （3）I/O 等待 CPU 高，说明等待 I/O 的时间比较长，所以应该着重排查系统存储是不是出现了 I/O 问题。
  （4）软中断和硬中断高，说明软中断或硬中断的处理程序占用了较多的CPU，所以应该着重排查内核中的中断服务程序。
样例01，pidstat 输出的进程用户CPU使用率升高，会导致 top输出的用户 CPU使用率升高。所以，当发现 top输出的用户CPU使用率有问题时，可以跟 pidstat的输出做对比，观察是否是某个进程导致的问题。
而找出导致性能问题的进程后，就要用进程分析工具来分析进程的行为，比如使用 strace 分析系统调用情况，以及使用 perf分析调用链中各级函数的执行情况。
样例02，top输出的平均负载升高，可以跟 vmstat输出的运行状态和不可中断状态的进程数做对比，观察是哪种进程导致的负载升高。
● 如果是不可中断进程数增多了，那么就需要做I/O的分析，也就是用dstat或sar等工具，进一步分析I/0的情况。
● 如果是运行状态进程数增多了，那就需要回到 top和 pidstat，找出这些处于运行状态的到底是什么进程，然后再用进程分析工具，做进一步分析。
样例03，当发现 top输出的软中断 CPU使用率升高时，可以查看/proc/softirqs 文件中各种类型软中断的变化情况，确定到底是哪种软中断出的问题。比如，发现是网络接收中断导致的问题，那就可以继续用网络分析工具 sar和 tcpdump 来分析。
样例04，系统的CPU使用率升高的案例。我们先用 top观察到了系统CPU升高，但通过 top 和 pidstat，却找不出高CPU使用率的进程。于是，我们重新审视 top的输出，又从CPU使用率不高但处于Running状态的进程入手，找出了可疑之处，最终通过 perf record和 perf report，发现原来是短时进程在捣鬼。
样例05，系统的 CPU 使用率很高，却找不到高 CPU 的应用
  系统的 CPU 使用率，不仅包括进程用户态和内核态的运行，还包括中断处理、等待 I/O 以及内核线程等。所以，当你发现系统的 CPU 使用率很高的时候，不一定能找到相对应的高 CPU 使用率的进程。
  如下系统总CPU使用率80.8%，而单个进程的CPU使用率都较小。需要通过 top 、pidstat 等交叉确认系统和各进程的CPU使用率。
  并且仔细观察进程列表中的状态S，查看R、S等状态的进程是否正常。

1
2
3
4
5
6

$ top  
%Cpu(s): 80.8 us, 15.1 sy, 0.0 ni, 2.8 id, 0.0 wa, 0.0 hi, 1.3 si, 0.0 st  
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND  
6882 root 20 0 8456 5052 3884 S 2.7 0.1 0:04.78 docker-containe  
6947 systemd+ 20 0 33104 3716 2340 S 2.7 0.0 0:04.92 nginx  
7494 daemon 20 0 336696 15012 7332 S 2.0 0.2 0:03.55 php-fpm

发生以上情况的原因：
（1）进程在不停地崩溃重启，比如因为段错误、配置错误等等，这时，进程在退出后可能又被监控系统自动重启了，而启动过程的资源初始化，很可能会占用相当多的 CPU。
（2）这些进程都是短时进程，也就是在其他应用内部通过 exec 调用的外面命令。这些命令一般都只运行很短的时间就会结束，你很难用 top 这种间隔时间比较长的工具发现。
发送上述问题的解决方法是找到父进程，从父进程入手，排查问题：
方法一：
（1）通过 top、pidstat 等找到可疑进程；
（2）通过 pstree 用树状形式显示该进程与其他进程的关系；
（3）通过 grep 找到具体调用代码
方法二：
（1）通过 perf record -g // 记录性能事件，等待大约 几秒后按 Ctrl+C 退出
（2）通过 perf report
方法三：
execsnoop 就是一个专为短时进程设计的工具，一般用于分析 Linux 内核的运行时行为。它通过 ftrace 实时监控进程的 exec() 行为，并输出短时进程的基本信息，包括进程 PID、父进程 PID、命令行参数以及执行的结果。
  https://github.com/brendangregg/perf-tools/blob/master/execsnoop
样例06，系统中出现大量不可中断进程和僵尸进程
 不可中断状态，是为了保证进程数据与硬件状态一致，并且正常情况下，不可中断状态在很短时间内就会结束。所以，短时的不可中断状态进程，我们一般可以忽略。但如果系统或硬件发生了故障，进程可能会在不可中断状态保持很久，甚至导致系统中出现大量不可中断进程。这时系统可能出现了 I/O 等性能问题。
  僵尸进程，这是多进程应用很容易碰到的问题。正常情况下，当一个进程创建了子进程后，它应该通过系统调用 wait() 或者 waitpid() 等待子进程结束，回收子进程的资源；而子进程在结束时，会向它的父进程发送 SIGCHLD 信号，所以，父进程还可以注册 SIGCHLD 信号的处理函数，异步回收资源。如果父进程没这么做，或是子进程执行太快，父进程还没来得及处理子进程状态，子进程就已经提前退出，那这时的子进程就会变成僵尸进程。
  通常，僵尸进程持续的时间都比较短，在父进程回收它的资源后就会消亡；或者在父进程退出后，由 init 进程回收后也会消亡。但是一旦父进程没有处理子进程的终止，还一直保持运行状态，那么子进程就会一直处于僵尸状态。大量的僵尸进程会用尽 PID 进程号，导致新进程不能创建。

第一点， iowait 太高了，导致系统的平均负载升高，甚至达到了系统 CPU 的个数。
第二点，僵尸进程在不断增多，说明有程序没能正确清理子进程的资源。
僵尸进程分析
既然僵尸进程是因为父进程没有回收子进程的资源而出现的，那么，也就是找出父进程的问题。
（1）通过 pstree -aps 找出当前进程的父进程。// -a 表示输出命令行选项 p 表示 PID s 表示指定进程的父进程
（2）查看父进程的代码，看看子进程结束的处理是否正确，比如有没有调用 wait() 或 waitpid() ，或是，有没有注册 SIGCHLD 信号的处理函数。
故障分析 | 大量短时进程导致 cpu 负载过高案例一则:https://cloud.tencent.com/developer/article/2010964
性能分析（3）- 短时进程导致用户 CPU 使用率过高案例:www.manongjc.com/detail/57-ocypedxbsyhbphv.html
短时进程，我还介绍了一个专门的工具 execsnoop，它可以实时监控进程调用的外部命令。

内存

概述

下面这张图，就是一个迅速定位内存瓶颈的流程。我们可以通过 free 和 vmstat 输出的性能指标，确认内存瓶颈；然后，再根据内存问题的类型，进一步分析内存的使用、分配、泄漏以及缓 存等，最后找出问题的来源。

很多内存的性能指标，也来源于 /proc 文件系统(比如 /proc/meminfo、/proc/slabinfo 等)，它们也都应该通过监控系统监控起来。这样，当收到内存告警时，就可以从监控系统中，直接得到上图中的各项性能指标，从而加快性能问题的定位过程。
比如说，当收到内存不足的告警时，首先可以从监控系统中。找出占用内存最多的几个进程。 然后，再根据这些进程的内存占用历史，观察是否存在内存泄漏问题。确定出最可疑的进程后， 再登录到进程所在的 Linux 服务器中，分析该进程的内存空间或者内存分配，最后弄清楚进程为什么会占用大量内存。

各部分空间分布

相关命令：free

Mem 行是内存的使用情况。
buffers/cache 行是物理内存的缓存统计情况。
Swap 行是交换空间的使用情况。
前面分别介绍过了物理内存和Swap分区。这里再介绍一下buffers和cache。
free 与 available 的区别
free 是真正尚未被使用的物理内存数量。
available 是应用程序认为可用内存数量，available = free + buffer + cache (注：只是大概的计算方法)
Linux 为了提升读写性能，会消耗一部分内存资源缓存磁盘数据，对于内核来说，buffer 和 cache 其实都属于已经被使用的内存。但当应用程序申请内存时，如果 free 内存不够，内核就会回收 buffer 和 cache 的内存来满足应用程序的请求。
当free内存接近零时，有些人会非常担心。但是接近零的free内存很酷，这实际上意味着您的内核正在将内存用于诸如缓存之类的良好用途。
buffer与cache
A buffer is something that has yet to be “written” to disk.
A cache is something that has been “read” from the disk and stored for later use.
简单点说：
buffers 就是存放要输出到disk（块设备）的数据，缓冲满了一次写，提高IO性能（内存 -> 磁盘）
cached 就是存放从disk上读出的数据，常用的缓存起来，减少IO（磁盘 -> 内存）
buffer 和 cache，两者都是RAM中的数据。简单来说，buffer是即将要被写入磁盘的，cache是被从磁盘中读出来的。
这里也有不同意见
结论：读文件时数据会缓存到 Cache 中，而读磁盘时数据会缓存到 Buffer 中。
Buffer 既可以用作“将要写入磁盘数据的缓存”，也可以用作“从磁盘读取数据的缓存”。
Cache 既可以用作“从文件读取数据的页缓存”，也可以用作“写文件的页缓存”。
  简单来说，Buffer 是对磁盘数据的缓存，而 Cache 是文件内容数据的缓存，它们既会用在读请求中，也会用在写请求中。
来自：Linux性能优化从入门到实战：09 内存篇：Buffer和Cache:https://blog.csdn.net/qccz123456/article/details/95369115

特定进程占用swap

相关命令：Cat /proc//smaps

缓存的读写命中(系统)

相关命令：cachestat

TOTAL ，表示总的 I/O 次数；
MISSES ，表示缓存未命中的次数；
HITS ，表示缓存命中的次数；
DIRTIES， 表示新增到缓存中的脏页数；
BUFFERS_MB 表示 Buffers 的大小，以 MB 为单位；
CACHED_MB 表示 Cache 的大小，以 MB 为单位。

进程的缓存命中（进程）

相关命令:cachetop

默认按照缓存的命中次数（HITS）排序，展示了每个进程的缓存命中情况。具体到每一个指标，这里的 HITS、MISSES和DIRTIES ，跟 cachestat 里的含义一样，分别代表间隔时间内的缓存命中次数、未命中次数以及新增到缓存中的脏页数。
而 READ_HIT 和 WRITE_HIT ，分别表示读和写的缓存命中率。

特定文件的缓存大小

相关命令： ​pcstat​​
pcstat 是一个基于 Go 语言开发的工具，所以安装它之前，你首先应该安装 Go 语言，下面就是一个 pcstat 运行的示例，它展示了 /bin/ls 这个文件的缓存情况：

这个输出中，Cached 就是 /bin/ls 在缓存中的大小，而 Percent 则是缓存的百分比。你看到它们都是 0，这说明 /bin/ls 并不在缓存中。
接着，如果你执行一下 ls 命令，再运行相同的命令来查看的话，就会发现 /bin/ls 都在缓存中了：

进程内存占用详情

相关命令：pmap
显示进程的内存映射，显示它们的大小、权限及映射对象。

内存带宽

相关命令: mbw -q -n 10 256

3种method类型含义

Io

概述

使用 iostat ，发现磁盘 I/O 存在性能瓶颈(比如 I/O 使用率过高、 响应时间过长或者等待队列长度突然增大等)后，可以再通过 pidstat、 vmstat 等，确认 I/O 的来源。接着，再根据来源的不同，进一步分析文件系统和磁盘的使用率、缓存以及进程的 I/O 等，从而揪出 I/O 问题的真凶。

同 CPU 和内存性能类似，很多磁盘和文件系统的性能指标，也来源于 /proc 和 /sys 文件系统 (比如 /proc/diskstats、/sys/block/sda/stat 等)。自然，它们也应该通过监控系统监控起 来。这样，当收到 I/O 性能告警时，就可以从监控系统中，直接得到上图中的各项性能指标， 从而加快性能定位的过程。
比如，当发现某块磁盘的 I/O 使用率为 100% 时，首先可以从监控系统中。找出 I/O 最多的进程。然后，再登录到进程所在的 Linux 服务器中，借助 strace、lsof、perf 等工具，分析该进程的 I/O 行为。最后，再结合应用程序的原理，找出大量 I/O 的原因。

磁盘角度的io负载

相关命令: iostat

结果解析:
tps 该设备每秒的传输次数，“一次传输”意思是“一次I/O请求”。多个逻辑请求可能会被合并为“一次I/O请求”，“一次传输”请求的大小是未知的
kB_read/s 每秒从设备（drive expressed）读取的数据量
kB_wrtn/s 每秒向设备（drive expressed）写入的数据量
kB_read 读取的总数据量
kB_wrtn 写入的总数据量

结果解析：
rrqm/s 每秒合并读操作的次数，如果两个读操作读取相邻的数据块时，可以被合并成一个，以提高效率。合并的操作通常是I/O scheduler（也叫elevator）负责的。
wrqm/s 每秒合并写操作的次数
r/s 每秒读操作的次数
w/s 每秒写操作的次数
rkB/s 每秒读取的字节数（KB）
wkB/s 每秒写入的字节数（KB）
avgrq-sz 每个IO的平均扇区数，即所有请求的平均大小，以扇区（512字节）为单位
avgqu-sz 平均未完成的IO请求数量，即平均意义上的请求队列长度
await 平均每个IO所需要的时间，包括在队列等待的时间，也包括磁盘控制器处理本次请求的有效时间
r_await 每个读操作平均所需要的时间，不仅包括硬盘设备读操作的时间，也包括在内核队列中的时间
w_await 每个写操平均所需要的时间，不仅包括硬盘设备写操作的时间，也包括在队列中等待的时间
svctm 表面看是每个IO请求的服务时间，不包括等待时间，但是实际上，这个指标已经废弃。实际上，iostat工具没有任何一输出项表示的是硬盘设备平均每次IO的时间
%util 表示该设备有I/O（即非空闲）的时间比率，不考虑I/O有多少，只考虑有没有，由于硬盘设备有并行处理多个i/o请求的能力，所以%util即使达到100%也不意味着设备饱和了。
举个简化的例子：某硬盘处理单个I/O需要0.1秒，有能力同时处理10个I/O请求，那么当10个I/O请求依次顺序提交的时候，需要1秒才能全部完成，在1秒的采样周期里%util达到100%；而如果10个I/O请求一次性提交的话，0.1秒就全部完成，在1秒的采样周期里%util只有10%。可见，即使%util高达100%，硬盘也仍然有可能还有余力处理更多的I/O请求，即没有达到饱和状态。
不足
iostat 的输出结果大多数是 一段时间内的平均值，因此难以反映峰值情况；
iostat 仅能对 系统整体情况进行分析汇报，却不能针对某个进程进行深入分析；
iostat 未单独统计IO处理信息，而是 将IO处理时间 和 IO等待时间 合并统计，因此包括await在内的指标并不能非常准确地衡量磁盘性能表现。

进程io

相关命令：iotop，pidstat，ioprofile

pidstat -p xxx -d 1 10

进程打开文件列表: lsof -p

线程io

相关命令: pidstat
分析应用程序中哪一个线程占用的io比较高
shell> pidstat -dt -p 73739 1 执行两三秒即可
Average: 1000 - 73823 0.00 233133.98 0.00 |mysqld
Average: 1000 - 74674 0.00 174291.26 0.00 |mysqld
11:56:18 PM 1000 - 74770 124928.00 74688.00 0.00 |mysqld
11:56:17 PM 1000 - 74770 124603.77 73358.49 0.00 |mysqld
Average: 1000 - 74770 124761.17 74003.88 0.00 |__mysqld
由上可知：74770这个线程占用的io比较高

Net

概述

网络性能，其实包含两类资源，即网络接口和内核资源。网络性能的分析，要从 Linux 网络协议栈的原理来切入。下面这张图，就是 Linux 网络协议栈的基本原理，包括应用层、套机字接口、传输层、网络层以及链路层等。

而要分析网络的性能，自然也是要从这几个协议层入手，通过使用率、饱和度以及错误数这几类 性能指标，观察是否存在性能问题。比如：
在链路层，可以从网络接口的吞吐量、丢包、错误以及软中断和网络功能卸载等角度分析；
在网络层，可以从路由、分片、叠加网络等角度进行分析；
在传输层，可以从 TCP、UDP 的协议原理出发，从连接数、吞吐量、延迟、重传等角度进行 分析；
在应用层，可以从应用层协议(如 HTTP 和 DNS)、请求数(QPS)、套接字缓存等角度进 行分析。
同前面几种资源类似，网络的性能指标也都来源于内核，包括 /proc 文件系统(如 /proc/net)、网络接口以及 conntrack 等内核模块。这些指标同样需要被监控系统监控。这样，当收到网络告警时，就可以从监控系统中，查询这些协议层的各项性能指标，从而更快定位出性能问题。
比如，当我们收到网络不通的告警时，就可以从监控系统中，查找各个协议层的丢包指标，确认丢包所在的协议层。然后，从监控系统的数据中，确认网络带宽、缓冲区、连接跟踪数等软硬件， 是否存在性能瓶颈。最后，再登录到发生问题的 Linux 服务器中，借助 netstat、tcpdump、 bcc 等工具，分析网络的收发数据，并且结合内核中的网络选项以及 TCP 等网络协议的原理，找出问题的来源。

连通性测试

相关命令：ping

累计流量

相关命令：ifconfig

RX= =receive，接收，从开启到现在接收封包的情况，是下行流量。
TX= =Transmit，发送，从开启到现在发送封包的情况，是上行流量。

实时流量

相关命令:nload

Nload –m

网络连接分析

相关命令： Iftop

第一行，是带宽，下面带有标尺，用来标示每个连接上的实时流量占用的带宽
中间部分，是所有的连接，默认显示的是主机名，可以通过参数显示ip，箭头表示数据方向
中间右侧三列，分别是该连接2s、10s、40s的平均流量
底部三行，分别表示发送、接收、汇总的流量
底部三行第2列，为iftop启动到现在的流量汇总
底部三行第3列，为峰值速率
第4列，为平均值
注意，流量单位为bit，非Byte
可以看到，通过iftop可以很容易看到各个连接的流量使用情况。

进程占用流量

端口定位法：iftop(-P )+lsof(-i:xx)


命令：nethogs

网卡性能测试

ethtool，物理属性速度
dmesg|grep eno2 | grep up，物理速度属性
speedtest-cli：针对固定ip的测试
nload：实际流量测试
iftop,nethogs：进程流量统计
iperf：双网卡直连方式测试
两个网卡用网线连接到同一个交换机上，或者直连，交换机交换最大速率不能低于待测试网卡的标称速率。
在两台机器上分别运行命令：
服务端命令：iperf -s -P 0 -i 1 -p 5001 -w 2M -f k
客户端命令：iperf -c 192.168.1.3 -i 1 -w 2M -t 600(服务端IP地址：192.168.1.3)

其他

系统资源瓶颈识别和定位

在系统监控的综合思路篇中，系统资源的瓶颈，可以通过 USE 法，即使用率、饱和度以及错误数这三类指标来衡量。系统的资源，可以分为硬件资源和软件资源两类。
硬件资源：CPU、内存、磁盘和文件系统以及网络等
软件资源：文件描述符数、连接跟踪数、套接字缓冲区大小等
在收到监控系统的告警时，可以对照这些资源列表，再根据不同的指标来进行定位。
其中，硬件资源瓶颈相对容易定位，cpu占用率，内存使用率等明确且清晰。软件资源由于不同应用的差异，并没有明确的界限区别正常还是异常。一个对A程序属于正常范畴的指标，对B程序则是异常，只能具体问题具体分析。

应用程序瓶颈

部分瓶颈，直接来自应用程序。比如，最典型的应用程序性能问题，就是吞吐量(并发请求数)下降、错误率升高以及响应时间增大。
这些应用程序性能问题虽然各种各样，但就其本质来源，实际上只有三种，也就是资源瓶颈、依赖服务瓶颈以及应用自身的瓶颈。
第一种资源瓶颈，其实还是指刚才提到的 CPU、内存、磁盘和文件系统 I/O、网络以及内核资源等各类软硬件资源出现了瓶颈，从而导致应用程序的运行受限。对于这种情况，我们就可以用前面系统资源瓶颈模块提到的各种方法来分析。
第二种依赖服务的瓶颈，也就是诸如数据库、分布式缓存、中间件等应用程序，直接或者间接调用的服务出现了性能问题，从而导致应用程序的响应变慢，或者错误率升高。这说白了就是跨应用的性能问题，使用全链路跟踪系统，就可以帮你快速定位这类问题的根源。
最后一种，应用程序自身的性能问题，包括了多线程处理不当、死锁、业务算法的复杂度过高等等。对于这类问题，在应用程序指标监控以及日志监控中，观察关键环节的耗时和内部执行过程中的错误，就可以帮你缩小问题的范围。
不过，由于这是应用程序内部的状态，外部通常不能直接获取详细的性能数据，所以就需要应用程序在设计和开发时，就提供出这些指标，以便监控系统可以了解应用程序的内部运行状态。
如果这些手段过后还是无法找出瓶颈，我们还可以用系统资源模块提到的各类进程分析工具，来进行分析定位。比如：
可以用 strace，观察系统调用；
使用 perf 和火焰图，分析热点函数；
甚至使用动态追踪技术，来分析进程的执行状态。
当然，系统资源和应用程序本来就是相互影响、相辅相成的一个整体。实际上，很多资源瓶颈， 也是应用程序自身运行导致的。比如，进程的内存泄漏，会导致系统内存不足；进程过多的 I/O 请求，会拖慢整个系统的 I/O 请求等。
所以，很多情况下，资源瓶颈和应用自身瓶颈，其实都是同一个问题导致的，并不需要我们重复分析。

性能分析工具集特征

工具体系非常庞大，围绕硬件的(英伟达nsight，英特尔Vtune等)，围绕系统的（vmstat,mpstat），围绕app的(perf,gprof,strace内核态)，围绕语言的(go的gprof,java,pyton等均有特定工具)
不同层次工具之间，功能上存在交叉
没有严谨的方法论，比如：按照一个手册12345后，就得得到确定结论，大多都需要具体问题具体分析

问题排查,定位进程->线程->gstack线程堆栈现场

CPU飙高排查步骤：https://blog.csdn.net/weixin_50914566/article/details/141939462
性能分析之CPU分析-从CPU调用高到具体代码行（C/C++）：https://www.cnblogs.com/GaoLou/p/14897144.html

命令响应解析

Top

命令参考
一文辨析，性能分析top命令中进程NI和PR:https://zhuanlan.zhihu.com/p/503042646
理解virt、res、shr之间的关系（linux系统篇）:https://baijiahao.baidu.com/s?id=1743908545937632735&wfr=spider&for=pc

mpstat

针对多核问题，比如多线程程序任务分配不均匀，无法充分利用cpu等
mpstat -P ALL

参考：
系统调优–mpstat命令详解：https://blog.csdn.net/weixin_44175418/article/details/124986740

Vmstat

上面每项的输出解释如下：
 procs
 r列表示运行和等待cpu时间片的进程数，这个值如果长期大于系统CPU的个数，说明CPU不足，需要增加CPU。
 b列表示在等待资源的进程数，比如正在等待I/O、或者内存交换等。
 memory
 swpd列表示切换到内存交换区的内存数量（以k为单位）。如果swpd的值不为0，或者比较大，只要si、so的值长期为0，这种情况下一般不用担心，不会影响系统性能。
 free列表示当前空闲的物理内存数量（以k为单位）
 buff列表示buffers cache的内存数量，一般对块设备的读写才需要缓冲。
 cache列表示page cached的内存数量，一般作为文件系统cached，频繁访问的文件都会被cached，如果cache值较大，说明cached的文件数较多，如果此时IO中bi比较小，说明文件系统效率比较好。
 swap
 si列表示由磁盘调入内存，也就是内存进入内存交换区的数量。
 so列表示由内存调入磁盘，也就是内存交换区进入内存的数量。
一般情况下，si、so的值都为0，如果si、so的值长期不为0，则表示系统内存不足。需要增加系统内存。
 IO
磁盘读写状况
 Bi列表示从块设备读入数据的总量（即读磁盘）（每秒kb）。
 Bo列表示写入到块设备的数据总量（即写磁盘）（每秒kb）
这里我们设置的bi+bo参考值为1000，如果超过1000，而且wa值较大，则表示系统磁盘IO有问题，应该考虑提高磁盘的读写性能。
 system
采集间隔内发生的中断数
 in列表示在某一时间间隔中观测到的每秒设备中断数。
 cs列表示每秒产生的上下文切换次数。
上面这2个值越大，会看到由内核消耗的CPU时间会越多。
 CPU
CPU的使用状态，此列是我们关注的重点。
 us列显示了用户进程消耗的CPU 时间百分比。us的值比较高时，说明用户进程消耗的cpu时间多，但是如果长期大于50%，就需要考虑优化程序或算法。
 sy列显示了内核进程消耗的CPU时间百分比。Sy的值较高时，说明内核消耗的CPU资源很多。
根据经验，us+sy的参考值为80%，如果us+sy大于 80%说明可能存在CPU资源不足。
 id 列显示了CPU处在空闲状态的时间百分比。
 wa列显示了IO等待所占用的CPU时间百分比。wa值越高，说明IO等待越严重，根据经验，wa的参考值为20%，如果wa超过20%，说明IO等待严重，引起IO等待的原因可能是磁盘大量随机读写造成的，也可能是磁盘或者磁盘控制器的带宽瓶颈造成的（主要是块操作）。
综上所述，在对CPU的评估中，需要重点注意的是procs项r列的值和CPU项中us、sy和id列的值。

NetData

安装
sudo apt-get install zlib1g-dev uuid-dev libuv1-dev liblz4-dev libjudy-dev libssl-dev libmnl-dev gcc make git autoconf autoconf-archive autogen
sudo apt-get install netdata
基本操作

1
2
3
4
5
6
7
8
9
10
11

# 启动NetData服务，并设置开机启动  
sudo systemctl enable netdata  
sudo systemctl start netdata  
# 重启服务  
sudo systemctl restart netdata  
# 停止NetData服务  
sudo systemctl stop netdata  
# 更新NetData服务（重新拉去，重新运行）  
cd netdata  
git pull  
sudo ./netdata-installer.sh

功能开关
修改文件：/etc/netdata/netdata.conf
修改[plugins]中的配置。原配置文件中大部分默认开启的，如果我们不需要某些图表的话，可以将注释去掉，改为no。然后重启服务，就可以禁用相应的图表。
降低内存占用
修改文件：/etc/netdata/netdata.conf
核心配置中的数据刷新率。

1
2
3
4
5
6
7

# 降低cpu占用：  
# 编辑：vim netdata.conf  
 \[global\]  
 update every = 2  
# 或者只修改apps部分：  
 \[plugin:apps\]  
 update every = 2

第三方扩展插件（NVIDIA-SMI）

1
2
3
4
5
6
7

# 使用官方提供的脚本，生成对应文件的配置文件  
cd /etc/netdata    
sudo ./edit-config python.d/nvidia_smi.conf  
修改文档内容  
# 官方文档提供样例  
loop_mode : yes \# 默认为yes。 如果设置为yes，则使用-l选项在单独的线程中执行nvidia-smi。  
poll_seconds : 1 \# 默认为1。设置循环查询nvidia-smi工具的频率（秒数）。

监控数据的保存
存入mongdb后端
sudo ./edit-config mongodb.conf
设置MongoDB URI，数据库名称和集合名称

Glances