基于linux5.15.5的IMX 参考手册 --- 3

基于linux5.15.5的IMX 参考手册 — 3

2.6 OProfile
2.6.1介绍
OProfile是一个系统范围的分析器,能够以较低的开销分析所有正在运行的代码。
OProfile由一个内核驱动程序、一个用于收集示例数据的守护进程和几个用于将数据转换为信息的后分析工具组成。
2.6.1.1概述
OProfile利用CPU的硬件性能计数器来支持各种各样有趣的统计信息的分析,这些统计信息也可以用于基本的耗时分析。
分析所有代码:硬件和软件中断处理程序、内核模块、内核、共享库和应用程序。
2.6.1.2特性
OProfile具有以下特性。
•不显眼——不需要特殊的重新编译或包装器库。即使调试符号(gcc中的-g选项)也不是必要的,除非用户想生成带注释的源代码。不需要内核补丁;只需插入模块。
•系统范围的分析——对系统上运行的所有代码进行分析,从而能够分析系统性能。
•性能计数器支持—支持各种低级数据的收集和特定代码部分的关联。
•调用图支持OProfile可以提供gprof风格的调用图评测数据。
•低开销oprofile的典型开销为1-8%,具体取决于采样频率和工作负载。
•档案后分析-档案数据可以在功能级或指令级详细产生。可以创建带有概要信息注释的源树。可以生成整个系统中利用最多CPU时间的应用程序和函数的命中列表。
•系统支持-适用于任何i.MX支持的内核。
2.6.1.3硬件操作
OProfile是一个统计连续分析器。
配置文件是通过定期对每个CPU上的当前寄存器进行采样(从中断处理程序中,存储中断时保存的PC值),并将运行时PC值转换为对程序员有意义的东西来生成的。
OProfile通过获取采样的PC值流,以及中断时正在运行的任务的详细信息,并将这些值转换为针对特定二进制文件的文件偏移量来实现这一点。因此,每个PC值都被转换成二进制图像偏移的元组(组或组)。用户空间工具可以使用这些数据来重构代码的来源,包括特定的汇编指令、符号和源代码行(如果存在,则通过二进制调试信息)。
像这样定期抽样PC值可以接近实际执行的内容和频率,通常情况下,这种统计近似足以反映现实。在普通操作中,每个采样中断之间的时间是由固定数量的时钟周期来调节的。这意味着结果反映了CPU在哪里花费的时间最多。这是性能分析的一个非常有用的信息源。
Arm CPU提供硬件性能计数器,能够在硬件级别测量这些事件。通常,这些计数器在每个事件中递增一次,并在达到一些预定义的事件数时生成中断。OProfile可以使用这些中断来生成样本,配置文件结果是哪个代码导致给定事件的实例数的统计近似值。
2.6.1.4特定于体系结构的组件
OProfile支持特定架构上可用的硬件性能计数器。用于管理设置和管理这些计数器的细节的代码可以位于相关的arch/arm/oprofile目录下的内核源代码树中。特定于体系结构的实现通过在初始化时填充oprofile_operations结构来进行操作。它提供了一组操作,如setup()、start()、stop()等,用于管理性能计数器寄存器中与硬件相关的详细信息。
体系结构代码可用的另一个重要功能是oprofile_add_sample()。这是将中断时获取的特定示例送入通用OProfile驱动程序代码的地方。
2.6.1.5 oprofilefs伪文件系统
OProfile实现了一个名为oprofilefs的伪文件系统,它从用户空间/dev/ OProfile挂载它包含报告和接收用户空间配置的小文件,以及OProfile用户空间接收示例的实际字符设备。在setup()时,特定于体系结构的代码可能会添加与性能计数器详细信息相关的进一步配置文件。文件系统还包含一个stats目录,其中有许多用于各种OProfile事件的有用计数器。
2.6.1.6通用内核驱动
通用内核驱动程序驻留在drivers/oprofile中,形成了oprofile如何在内核中运行的核心。通用内核驱动程序从特定于体系结构的代码中获取示例(通过oprofile_add_sample()),并缓冲该数据(在转换后的配置中),直到通过/dev/oprofile/buffer字符设备将数据释放给用户空间守护进程。
2.6.1.7 OProfile守护进程
OProfile用户空间守护进程获取内核提供的原始数据并将其写入磁盘。它从内核获取单个数据流,并针对许多样例文件(可在/var/lib/oprofile/samples/current/中获得)记录样例数据。为了实现单独的功能,更改了这些示例文件的名称和路径,以反映示例来自哪里。这可以包括线程id、二进制文件路径、使用的事件类型等等。
在从中断到磁盘文件的最后一步之后,数据现在是持久的(也就是说,系统运行中的更改不会使存储的数据失效)。这使得事后分析工具可以在任何时候对这些数据运行(假设原始二进制文件仍然可用且没有改变)。
2.6.1.8后期分析工具
收集的数据必须以有用的形式呈现给用户。这是后期分析工具的工作。通常,它们会整理可用示例文件的一个子集,加载和处理与相关二进制文件相关的每个文件,并生成用户可读的信息。
2.6.1.9中断需求
关于OProfile驱动程序生成的中断数量很多。不需要延迟要求。产生中断的速率取决于事件。
2.6.2软件操作
对于Cortex-A7 i.MX, Oprofile需要添加Cortex-A7事件监视器
2.6.2.1源代码结构
平台相关的Oprofile源文件可以在arch/arm/oprofile中找到
在这里插入图片描述
Oprofile的通用内核驱动程序位于drivers/ Oprofile下
2.6.2.2菜单配置选项
这个模块提供了以下Linux内核配置。
在菜单配置中启用以下模块:
•CONFIG_OPROFILE - oprofile驱动程序的配置选项。在菜单配置中,该选项在下面可用
•General Setup > Profiling support (EXPERIMENTAL)
2.6.2.3编程接口
这个驱动程序实现了配置和控制PMU和L2缓存EVTMON计数器所需的所有方法。
更多信息,请参阅由build生成的Linux文档:make htmldocs。

2.6.2.4软件配置举例
下面的步骤展示了如何配置OProfile的示例:

  1. 使用命令bitbake linux-imx -c menuconfig。在屏幕上,首先转到Package list并选择Oprofile。
  2. 然后,返回到第一个屏幕,选择Configure Kernel,按照Menu Configuration Options的指示,在内核空间中启用Oprofile。
    3.保存配置并开始构建。
  3. 将Oprofile二进制文件复制到目标rootfs。将vmlinux拷贝到“/boot”目录下,执行Oprofile命令
root@ubuntu:/boot# opcontrol --separate=kernel --vmlinux=/boot/vmlinux
root@ubuntu:/boot# opcontrol --reset
Signalling daemon... done
root@ubuntu:/boot# opcontrol --setup --event=CPU_CYCLES:100000
root@ubuntu:/boot# opcontrol --start
Profiler running.
root@ubuntu:/boot# opcontrol --dump
root@ubuntu:/boot# opreport
Overflow stats not available
CPU: ARM V7 PMNC, speed 0 MHz (estimated)
Counted CPU_CYCLES events (Number of CPU cycles) with a unit mask of 0x00 (No un
it mask) count 100000
CPU_CYCLES:100000|
samples| %|
------------------
 4 22.2222 grep
 CPU_CYCLES:100000|
 samples| %|
 ------------------
 4 100.000 libc-2.9.so
 2 11.1111 cat
 CPU_CYCLES:100000|
 samples| %|
 ------------------
 1 50.0000 ld-2.9.so
 1 50.0000 libc-2.9.so
...
root@ubuntu:/boot# opcontrol --stop
Stopping profiling.

2.7脉宽调制器(PWM)
2.7.1介绍
脉宽调制器(PWM)有一个16位计数器,优化后可从存储的音频图像样本产生声音和产生音调。PWM还提供对背光的控制。
PWM具有16位分辨率,并使用4x16数据FIFO产生声音。软件模块由一个Linux驱动程序组成,允许特权用户通过适当的PWM输出(PWMO)信号占空比控制背光。
2.7.2硬件操作
下图是PWM的框图。
基于linux5.15.5的IMX 参考手册 --- 3_第1张图片
PWM遵循IP总线协议与处理器核心接口。除了时钟控制模块(CCM)的时钟和复位输入以及向处理器中断处理程序发送的中断信号外,它不与设备内的任何其他模块接口。PWM包括一个外部输出信号PMWO。PWM包括以下内部信号:
•3个时钟输入
•四条中断线
•一条硬件复位线
•四种低功耗和调试模式信号
•4个扫描信号
•标准IP从总线信号
2.7.3时钟
提供给预分频器的时钟可以从以下选择:
•CCM提供的高频时钟。该时钟可以在低功耗模式下运行PWM。
•低参考时钟- CCM提供的32 KHz低参考时钟。该时钟可以在低功耗模式下运行PWM。
•全局功能时钟-用于正常操作。在低功耗模式下,这个时钟可以关闭。
时钟输入源由PWM控制寄存器的CLKSRC域确定。只有当PWM关闭时,CLKSRC值才可以改变。
第2.7.4软件操作
PWM器件驱动通过改变一系列脉冲到电源的宽度来减少发送到负载的功率。
PWM的一个常见和有效的使用是控制占空比可变的QVGA面板的背光。
下表提供了源代码中接口函数。
基于linux5.15.5的IMX 参考手册 --- 3_第2张图片
函数pwm_config()包括PWM模块的大部分配置任务,包括时钟源选项、PWM输出信号的周期和占空比。建议选择PWM模块的外接时钟,而不是本地功能时钟,因为本地功能时钟会发生变化。
2.7.5驱动特性
PWM驱动器包括以下软件和硬件支持:
•占空比调制
•不同的输出间隔
•两种电源管理模式:full on和full off
2.7.6源代码结构
在这里插入图片描述
2.7.7菜单配置选项
在菜单配置中启用以下模块:

• Device Drivers > Pulse-Width Modulation (PWM) Support > i.MX PWM support
•选择以下选项启用背光驱动:
Device Drivers > Graphics support > Backlight & LCD device support > Generic PWM based Backlight Driver

2.8远程处理器消息传递
2.8.1介绍
通过使用ArmCortex®-A系列处理器和ArmCortex-M系列处理器设计的最新多核架构,工业应用可以实现更高的能效,减少碳足迹。这样可以在不影响性能的前提下降低功耗。
一个同构SoC通常会运行一个控制所有内存的单一操作系统(OS)。操作系统或管理程序将处理可用内核之间的任务管理,以最大化系统利用率。这样的系统被称为对称多处理(SMP)。
异构多核芯片,不同的处理核心运行不同的指令集和不同的操作系统。每个处理核心根据需要处理特定的任务。这样的系统被称为非对称多处理(AMP)。为了理解SMP和AMP系统之间的区别,同质多核SoC可以是AMP系统,但异质多核SoC不能是SMP系统。
多核体系结构给系统设计带来了新的挑战,因为必须重写软件以在可用的核心之间分配任务。此外,所有外围资源都需要合理分配,以避免资源争用,实现核心间数据空间的高效共享。多核SoC也需要可靠的机制运行在不同处理核心上的任务之间的通信和同步。
RPMsg是一个基于virtio的消息总线,它允许内核驱动程序与系统上可用的远程处理器进行通信。反过来,如果需要,驱动程序可以公开适当的用户空间接口。每个RPMsg设备都是一个与远程处理器的通信通道(因此将RPMsg设备称为通道)。通道由文本名称标识并具有本地(“源”)RPMsg地址和远程(“目的”)RPMsg地址。要了解更多信息,请参见www.kernel.org/doc/Documentation/rpmsg.txt。
如下图所示,消息通过双向无连接通信通道在端点之间传递。
基于linux5.15.5的IMX 参考手册 --- 3_第3张图片
2.8.2特性
•为低延迟和低开销操作而设计,并兼容Linux RPMsg框架。
•针对CPU和内存资源受限的嵌入式环境进行了优化。
•通过使用共享内存实现,不需要数据转换或消息头。
•使用客户端-服务器方法进行应用程序通信。
•RPMsg通道的动态分配。
2.8.3源代码
RPMSG驱动程序软件位于drivers/RPMSG中
表20.RPMSG源
基于linux5.15.5的IMX 参考手册 --- 3_第4张图片
2.8.4菜单配置选项
在菜单配置中启用以下模块:

• Device Drivers > IMX RPMSG pingpong driver -- 仅可加载模块 
• Device Drivers > IMX RPMSG tty driver -- 仅可加载模块

2.8.5运行i.m xrpmsg测试程序
运行i.MX RPMsg测试程序需要执行以下操作:

  1. 确保使用了正确的Cortex-M4处理器RTOS和Linux映像。
    例如在i.MX 7Dual平台上:
•rpmsg_pingpong_sdk_7dsdb.bin ->乒乓测试,用于i.MX 7Dual SDB单板
•rpmsg_str_echo_sdk_7dsdb.bin -> tty string echo测试在i.MX 7Dual SDB板上使用
•rpmsg_pingpong_sdk_7dvar .bin ->乒乓测试,用于i.m x7dual 12x12 LPDDR3 Arm2单板
•rpmsg_str_echo_sdk_7dvar .bin -> tty字符串回声测试,用于i.m x7dual 12x12 LPDDR3 Arm2板
  1. 加载Cortex-M4处理器的RTOS图像,并在U-Boot中启动它。
    通过TFTP服务器或U-Boot的可引导SD卡加载Cortex-M4处理器RTOS镜像。
    •通过TFTP服务器加载Cortex-M4处理器RTOS镜像文件。例如,
    a.进入U-Boot并停止。
    b.执行以下命令,将对应的Cortex-M4处理器RTOS镜像文件TFTP并启动。
dhcp 0x7e0000 10.192.242.53:rpmsg_pingpong_sdk_7dval.bin; bootaux 0x7e0000

•通过SD卡加载Cortex-M4处理器的RTOS图像。例如,
a.使用MFGtools工具创建可引导SD卡。然后,将Cortex-M4处理器RTOS文件复制到VFAT文件系统格式化的第一个分区。
b.修改U-Boot默认的Cortex-M4处理器RTOS名称。

setenv m4image '';save

c.设置Cortex-M4处理器使用的引导参数。

setenv run_m4_tcm 'if run loadm4image; then cp.b ${loadaddr} 0x7e0000 0x8000; bootaux 0x7e0000; fi'; save

d.修改原bootcmd,增加“run_m4_tcm”命令。

setenv bootcmd "run run_m4_tcm; "; save

注意:
“uart_from_osc”是i.MX 6SoloX在运行Cortex-M4处理器RTOS映像时的强制要求。
因此U-Boot的mmcargs需要在i.MX 6SoloX上进行修改。

setenv mmcargs 'setenv bootargs console=${console},${baudrate} root=$ {mmcroot}, uart_from_osc';save

3.运行RPMsg测试程序。

a.确保imx_rpmsg_pingpong.ko 和imx_rpmsg_tty.ko都建好了。
b.使用insmod imx_rpmsg_pingpong.ko 或insmod imx_rpmsg_tty.ko来运行测试程序。
请注意:不要同时运行不同的测试程序。
c.执行如下命令,确保启动RPMsg TTY测试时后台运行的是RPMsg TTY接收程序。
/unit_tests/mxc_mcc_tty_test.out /dev/ttyRPMSG30 115200 R 100 1000 &
Linux操作系统侧日志:
insmod imx_rpmsg_tty.ko 
imx_rpmsg_tty rpmsg0: new channel: 0x400 -> 0x1! 
Install rpmsg tty driver! 
echo deadbeaf > /dev/ttyRPMSG30 
imx_rpmsg_tty rpmsg0: msg(<- src 0x1) deadbeaf len 8

2.9热
2.9.1介绍
热驱动是监控和保护SoC的必要驱动。热驱动以一定频率从内部热传感器监测SoC温度。
它定义了两个触发点:关键和被动。冷却装置会根据SoC到达的不同触发点采取措施保护SoC:
•当到达临界点时,冷却装置将关闭系统。
•当到达被动点时,冷却设备将降低CPU频率,并通知GPU/VPU以更低的频率运行。
•当温度降到被动点以下10°C时,冷却装置将释放所有的冷却动作。
热驱动分为两部分:
•热区定义触发点并监测SoC的温度。
•冷却装置根据不同的触发点采取不同的动作。
临界点和被动点阈值在以下文件中配置。

•i.MX 6和i.MX 7 soc在drivers/thermal/imx_thermal.c中配置此功能
•i.m x8m soc在他们的dtsi文件中配置这个,并在defconfig中指定CONFIG_IMX8M_THERMAL。
•i.MX 8和i.MX 8X socs在他们的dtsi文件中配置这个,并在defconfig中指定CONFIG_IMX_SC_THERMAL。

2.9.2软件操作
热驱动器注册一个热区和一个冷却设备。一个名为thermal_zone_device_ops的结构描述了热框架所需的必要接口。该框架将调用相关的热区接口来监测SoC温度并进行冷却保护。
热驱动可以通过以下接口访问:

•/sys/bus/platform/drivers/imx_thermal for i.MX 6和i.MX 7。
•/sys/class/thermal/thermal_zoneX用于i.MX 8和i.MX 8X。
•/sys/bus/platform/drivers/qoriq_thermal for i.MX 8M Quad。
•/sys/class/thermal/thermal_zone0/temp for i.MX 8M Mini。

2.9.3源代码结构
下表显示了drivers/thermal中可用的驱动源文件:
基于linux5.15.5的IMX 参考手册 --- 3_第5张图片
2.9.4菜单配置选项
在菜单配置中启用以下模块:

对于i.MX6和i.MX7: Device Drivers > Generic Thermal sysfs driver > Temperature sensor driver for i.MX SoCs
对于i.MX 8QuadMax和i.MX 8QuadXPlus: Device Drivers > Generic Thermal sysfs driver > thermal sensor driver for NXP i.MX8 SoCs

2.10传感器
2.10.1介绍
传感器包括一组驱动加速度计,压力,陀螺仪,环境光,和磁力计。
每块单板的设备树中配置传感器。
i.MX支持以下SoC的加速计:
•i.MX 6SABRE-SD、6SABRE-AI和6SoloX使用MMA8451传感器
•i.MX 6UltraLite和6ULL EVK使用FXLS8571Q传感器。
•i.MX 7Dual SABRE-SD和i.MX 8QuadMax和i.MX 8QuadXPlus使用FX0S8700传感器。

i.MX支持以下SoC的压力传感器MPL3115:
•i.MX 7 Dual SABRE-SD
•i.MX 8 QuadMax
•i.MX 8 QuadXPlus
i.MX支持以下SoC的陀螺仪传感器FXAS2100:
•i.MX 7 Dual SABRE-SD
i.MX支持以下SoC的环境光传感器ISL29023:
•i.MX 6 SABRE-SD和6 SABRE-AI
•i.MX 6 SoloX
•i.MX 8 QuadMax
•i.MX 8 QuadXPlus。
i.MX支持以下SoC的磁力计传感器MAG3110:
•i.MX 6 SABRE-SD
•i.MX 6 UL EVK
•i.MX 6 ULL EVK
•i.MX 6 solox
2.10.2传感器驱动软件操作

2.10.3源代码结构
下表显示了该目录下可用的驱动源文件:
基于linux5.15.5的IMX 参考手册 --- 3_第6张图片
2.10.4菜单配置选项
在菜单配置中启用以下模块:

• Device Drivers > Misc devices > Intersil ISL29020 ambient light sensor
• Device Drivers > Misc devices > Freescale FXOS8700 M+G combo sensor
• Device Drivers > Misc devices > Freescale FXAS2100X gyroscope sensor
• Device Drivers > Hardware Monitoring support > Freescale MAG3110 e-compass sensor
• Device Drivers > Hardware Monitoring support > MMA8451 device driver

2.11看门狗(WDOG)
2.11.1介绍
看门狗定时器模块通过避免意外挂起或无限循环情况或编程错误,防止系统故障。
一些平台可能有两个WDOG模块,其中一个具有中断能力。i.MX 6和7Dual与i.MX 8M共用同一位看门狗驱动程序。i.MX 7ULP有一个单独的看门狗驱动程序。i.MX 8和i.MX 8X通过系统控制器固件共享虚拟看门狗驱动接口。
2.11.2硬件操作
WDOG定时器被激活后,软件必须定期为其提供服务。
如果服务没有及时进行,WDOG将会超时。超时时,WDOG会根据软件配置,发出wdog_b信号或wdog_rst_b系统复位信号。看门狗模块被激活后无法停用。
2.11.3软件操作
Linux操作系统有一个标准的WDOG接口,它允许为特定平台支持WDOG驱动程序。
WDOG可以分别在STOP/DOZE和WAIT模式下被暂停/恢复。由于WDOG寄存器的某些位在启动后只能一次性可编程,所以要确保正确地编写这些寄存器。
2.11.4通用WDOG
通用的WGOD驱动在drivers/watchdog/imx2_wdt.c文件中实现。
它提供了各种ioctl的函数,以及来自用户级程序的读/写调用来控制WDOG。
2.11.5驱动特性
这个WDOG实现包括以下特性:
•如果重置信号已启用,但未在预定义的超时值(在一个WDOG源文件中以毫秒为单位定义)内提供服务,则生成重置信号
•不产生复位信号,如果它是在一个预定义的超时值服务
•提供标准WDOG子系统所需的IOCTL/读写
2.11.6源代码结构
下表显示了位于drivers/watchdog中的看门狗WDOG驱动程序的源文件。
2.11.7菜单配置选项
在菜单配置中启用以下模块:

Device Drivers > Watchdog Timer Support > IMX2+ Watchdog
Device Drivers > Watchdog Timer Support > IMX7ULP Watchdog
Device Drivers > Watchdog Timer Support > IMX8 Watchdog

2.11.8编程接口
WDOG驱动支持以下ioctl:

•WDIOC_GETSUPPORT
•WDIOC_GETSTATUS
•WDIOC_GETBOOTSTATUS
•WDIOC_KEEPALIVE
•WDIOC_SETTIMEOUT
•WDIOC_GETTIMEOUT

关于ioctl的详细描述,请参见文档/看门狗。

你可能感兴趣的:(NXP芯片,linux驱动,linux)