3.5 RK3399项目开发实录-板载RTLinux系统的使用（wulianjishu666）

最新推荐文章于 2024-03-20 08:38:44 发布

vx349014857

最新推荐文章于 2024-03-20 08:38:44 发布

阅读量765

点赞数 23

分类专栏： RK3399实战开发文章标签： linux stm32 嵌入式硬件 arm开发物联网

本文链接：https://blog.csdn.net/vx349014857/article/details/136852662

版权

RK3399实战开发专栏收录该内容

41 篇文章 6 订阅

订阅专栏

STM32F103单片机从零到项目开发程序实例
链接：https://pan.baidu.com/s/1dWNskNinrMk4bxaE-jgHhQ?pwd=ymn3

1. 介绍

为了满足用户对系统实时性的需求，官方在 SDK 源码的内核基础上支持升级 Linux 到 RTLinux。我们RTlinux支持有preempt和xenomai两个版本,下面以preempt版本来测试。

1.1. RTLinux 系统固件支持

preempt版本支持rk356x和rk3588所有系列板子并发布对应固件。如需要源码请联系商务。

1.2. 测试实时效果

测试实时性能需要cyclictest,可以使用apt安装。

apt update
apt install rt-tests

1.2.1. 测试RTLinux的实时效果

使用aio-3568j进行测试，执行以下命令测试每个核心实时响应延迟：

sudo ./cyclictest -S -p 99 -m

T:0 序号为0的线程；P:99 线程优先级为99；C: 9397 计数器。线程的时间间隔每达到一次，计数器加1；I: 1000 时间间隔为1000微秒(us)；Min: 最小延时(us)；Act: 最近一次的延时(us)；Avg：平均延时(us)；Max：最大延时(us)。

在aio-3568j 的系统上同时跑一些压测程序和cyclictest来测试每个核心的最大响应延迟：

# 运行3个cpu压测线程、3个io压测线程和3个内存压测线程
stress --cpu 3 --io 3 --vm 3

同时进行网络压测：

#使用iperf进行上下行同时测试
iperf -c 192.168.1.220 -p 8001 -f m -i100 -d -t 800000

最后再进行gpu压测：

#无限地运行，从最后一个基准循环到第一个基准
glmark2-es2-wayland --run-forever

下图是以上面教程来制造压力环境进行三天的延迟测试结果。如下图可知：

T0实时线程测试最大延迟85us，平均延迟16us，最小延迟3us。
T1实时线程测试最大延迟61us，平均延迟12us，最小延迟3us。
T2实时线程测试最大延迟52us，平均延迟11us，最小延迟3us。
T3实时线程测试最大延迟18us，平均延迟4us，最小延迟3us。

为什么T0测试结果最差？因为arm默认把所有的SPI中断都由cpu0处理，所以延迟测试会比其他核心要差，我们最好不要把实时线程绑定到cpu0运行。为什么T3测试结果比其他3个核心好很多？因为我们默认将CPU3从内核SMP平衡和调度算法中剔除，保留CPU3给RT应用使用。

_images/rtlinux_test.png

1.2.2. Cyclictest标准测试

threads选项(-t)用于指定Cyclictest在检测延迟时将使用的测量线程数。通常，在系统上的每个CPU上只运行一个测量线程是一个标准的测试方案。可以使用亲和性选项(-a)指定线程必须在其上执行的cpu。

这些选项对于最小化运行Cyclictest对观察到的系统的影响至关重要。在使用Cyclictest时，确保在任何给定时间只执行一个测量线程是很重要的。如果两个或多个Cyclictest线程的预期执行时间重叠，则Cyclictest的测量将受到其自己的测量线程所造成的延迟的影响。确保在给定的时间只执行一个测量线程的最好方法是在给定的CPU上只执行一个测量线程。

例如，如果要分析三个特定cpu的延迟，则指定应该使用这些cpu(使用-a选项)，并指定应该使用三个测量线程(使用-t选项)。在这种情况下，为了最小化Cyclictest的开销，请确保收集度量数据的主Cyclictest线程没有运行在三个隔离的cpu之一上。主线程的关联性可以使用taskset程序设置，如下所述。

1.2.2.1. 在评估一组隔离的cpu上的延迟时，减小cyclictest的影响

在测量cpu子集上的延迟时，确保主Cyclictest线程正在未被评估的cpu上运行。例如，如果一个系统有两个CPU，并且正在评估CPU 0上的延迟，那么主Cyclictest线程应该固定在CPU 1上。Cyclictest的主线程不是实时的，但是如果它在被评估的CPU上执行，它可能会对延迟产生影响，因为会有额外的上下文切换。在启动Cyclictest之后，可以使用taskset命令将主线程限制为在cpu的某个子集上执行。例如，针对CPU1到CPU3的延时测试:

#CPU1到CPU3运行实时程序，主线运行在CPU0上
taskset -c 0 ./cyclictest -t3 -p99 -a 1-3

taskset程序还可以用于确保系统上运行的其他程序不会影响隔离CPU上的延迟。例如，启动程序top查看线程并固定到CPU 0上，使用下面的命令:

taskset --cpu 0 top -H -p PID
#top打开之后点击f键，光标移动到 P 选项，空格选中，然后点击 q建退出，便可查看到实时线程在哪些CPU上运行。

1.3. 提高实时策略

1.3.1. 抑制控制台消息及禁止内存过度使用

#可以使用内核参数quiet启动内核，或者启动之后抑制，如下：
echo 1 > /proc/sys/kernel/printk

#禁用内存过度使用以避免 Out-of-Memory Killer产生的延迟
echo 2 > /proc/sys/vm/overcommit_memory

1.3.2. 不使用桌面或者使用轻量级窗口管理器

为了更好的实时，我们不建议使用带桌面的系统，因为这将为CPU延迟带来很大的挑战。建议使用minimal ubuntu、自己的QT程序等。 356x的rt固件默认不使用桌面，而是使用窗口管理器weston，显示协议是Wayland。

1.3.2.1. 切换X11环境

如果你需要X11的环境，可手动切换到X11

sudo set_display_server x11
reboot
#sudo set_display_server weston 可再次切换回weston，重启生效

1.3.2.1.1. 使用openbox 窗口管理器启动

切换到X11环境默认使用桌面，如果需要使用轻量级的窗口管理器在/etc/lightdm/lightdm.conf 指定ession使用openbox窗口管理器：

cat /etc/lightdm/lightdm.conf.d/20-autologin.conf 
[Seat:*]
user-session=openbox
autologin-user=firefly

1.3.2.1.2. 只运行自己的X11程序

若是不用登录管理器启动 X显示服务，可使用xinit手动启动Xorg显示服务。执行xinit和startx时，它们将寻找~/.xinitrc做为shell脚本运行以启动客户端程序。若是~/.xinitrc不存在，startx将运行默认值/etc/X11/xinit/xinitrc(默认的xinitrc启动一个Twm，xorg-xclock和Xterm环境)。

首先关闭lightdm服务

systemctl disable lightdm

然后使用startx启动自己的程序

startx chromium

也可修改默认startx指定的client 的xinitrc文件,默认的会运行Xorg

vim /etc/X11/xinit/xinitrc
-------------------------------------------------------------
#!/bin/sh
  
# /etc/X11/xinit/xinitrc
#
# global xinitrc file, used by all X sessions started by xinit (startx)

# invoke global X session script
#. /etc/X11/Xsession
#chromium --window-size=1920,1080
chromium --start-maximized

1.3.3. 绑定核心

实时要求高的事件固定到某个核心上处理，系统及其它实时要求不高的事件集中到一个核心上处理。例如特定的中断，实时程序等事件可以用专门的核心为他们服务。

1.3.3.1. 任务绑定核心

rt应用可由特定核心处理，将rt应用绑定到cpu3

taskset -c 3 rt_task

1.3.3.2. 中断绑定核心

由于arm将所有外设中断全部由cpu0处理，对于重要的中断可以在系统启动之后将中断绑定到其他核心。例如将eth0中断绑定到cpu2

root@firefly:~# cat /proc/interrupts | grep  eth0
 38:   28600296          0          0          0     GICv3  64 Level     eth0
 39:          0          0          0          0     GICv3  61 Level     eth0

root@firefly:~# cat /proc/irq/38/smp_affinity_list 
0-3

root@firefly:~# echo 2 > /proc/irq/38/smp_affinity_list

root@firefly:~# cat /proc/irq/38/smp_affinity_list 
2
root@firefly:~# cat /proc/interrupts | grep  eth0
 38:   29009292          0      52859          0     GICv3  64 Level     eth0
 39:          0          0          0          0     GICv3  61 Level     eth0

1.3.4. 使用smp+amp方案

对于实时要求更高的，可以使用amp方案，以达到更好的实时控制。 rk3568支持了amp（非对称多核架构），你可以定制某些核心跑定制的系统。比如0～2核心跑kernel，3核心跑rt-thread等；支持 Linux(Kernel-4.19、rt-kernel-4.19)、 Baremetal(HAL)、RTOS(RT-Thread) 组合AMP构建形式，可任意搭配。不同内核之间可以使用核间通信来进行信息交互。