基于linux5.15.5的IMX 参考手册 --- 8
Posted chocolate2018
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了基于linux5.15.5的IMX 参考手册 --- 8相关的知识，希望对你有一定的参考价值。
基于linux5.15.5的IMX 参考手册 — 8
4.12蓝牙
4.12.1蓝牙无线技术介绍
蓝牙技术是一种低成本、低功耗、短距离的无线技术。它被设计为电缆和其他短程技术如IrDA的替代品。蓝牙无线技术的个人区域范围通常可达10米。有关蓝牙无线技术的更多信息，请参见www.bluetooth.com/。
对于i.MX，蓝牙支持多个供应商。详细信息，请参见i.MX Linux®用户指南(IMXLUG)中的“蓝牙无线技术和Wi-Fi连接”章节。
4.12.2蓝牙驱动简介
i.MX使用开源蓝牙驱动程序。蓝牙软件分为以下四个部分:
•4线UART和TTY驱动程序:是与蓝牙模块的通信接口。
•蓝牙HCI设备驱动程序:UART (H4)是蓝牙设备和主机之间通信的串行协议。大多数具有UART接口的蓝牙设备都需要此协议。
•蓝牙内核栈:蓝牙框架和协议实现。
•蓝牙用户栈:提供几个用户空间实用程序，并集成许多用例配置文件。
4.12.3蓝牙驱动文件
蓝牙驱动程序源文件在内核源目录中。
•蓝牙HCI设备驱动:
— drivers/bluetooth/hci_h4.c
— drivers/bluetooth/hci_ldisc.c
•蓝牙内核栈:
- net/bluetooth/ *
4.12.4蓝牙协议栈
BlueZ是Linux官方标准蓝牙协议栈，它是5.x的最新版本，是基于Linux内核的操作系统系列的蓝牙协议栈。它的目标是为Linux编程实现蓝牙无线标准规范。要使用Linux蓝牙子系统，您需要几个用户空间实用程序，比如hciconfig和bluetoothd。BlueZ包中提供了这些实用程序和蓝牙内核模块的更新。要了解更多信息，请参见www.bluez.org/。
BlueZ的源代码可以在git: git://git.kernel.org/pub/scm/bluetooth/bluez.git中获得。当前的BSP包测试通过了BlueZ 5.56。
4.12.5菜单配置选项
这个模块提供了以下Linux内核配置选项:
•UART接口:
——CONFIG_SERIAL_IMX
——CONFIG_TTY
•HCI接口:
——CONFIG_BT_HCIUART
——CONFIG_BT_HCIUART_H4
——CONFIG_BT_HCIUART_BCM
•蓝牙栈:
——CONFIG_BT
——CONFIG_BT_RFCOMM
——CONFIG_BT_RFCOMM_TTY
——CONFIG_BT_BNEP
——CONFIG_BT_BNEP_MC_FILTER
——CONFIG_BT_BNEP_PROTO_FILTER
——CONFIG_BT_HIDP
4.13 Wi-Fi
4.13.1介绍
通过板载芯片解决方案和外部硬件，i.MX支持蓝牙和Wi-Fi。对于各种板载芯片和外部解决方案，请参阅i.MX Linux®用户指南(IMXLUG)中的“蓝牙无线技术和Wi-Fi连接”章节。
4.13.2软件操作
BSP支持:
•从5.4.47-2.2.0版本开始，所有Linux BSP中可用的i.MX芯片组都支持NXP Wi-Fi驱动模块。有关支持的Wi-Fi芯片组列表，请参阅每个i.MX Linux BSP发行版的发行说明。
4.13.3驱动特性
NXP Wi-Fi驱动支持CFG80211、NL80211内核接口。驱动支持AP模式、STA模式和Wi-Fi直通模式。
NXP Wi-Fi soc需要在上电/复位时加载固件镜像。所支持的Wi-Fi soc的固件镜像位于以下rootfs目录:/lib/firmware/nxp.
4.13.4源代码结构
NXP onedrive的源代码文件可以在codeurora.org上找到。
4.13.5菜单配置选项
这个模块提供了以下Linux内核配置选项:
•CONFIG_MAC80211 = y
•COCONFIG_NL80211_TESTMODE = y
•CONFIG_CFG80211_WEXT = y
•CONFIG_HOSTAP = y
•CONFIG_CFG80211_INTERNAL_REGDB = y
4.13.6配置用户空间WLAN
以工作站模式连接AP
下面的命令组用于将WLAN连接到给定的SSID。
modprobe moal mod_para=nxp/wifi_mod_para.conf
head -n 4 /etc/wpa_supplicant.conf > /etc/wpa_supplicant.conf.tmp
wpa_passphrase ssid password >> /etc/wpa_supplicant.conf.tmp
mv /etc/wpa_supplicant.conf /etc/wpa_supplicant.conf.bak
mv /etc/wpa_supplicant.conf.tmp /etc/wpa_supplicant.conf
wpa_supplicant -B -i mlan0 -c /etc/wpa_supplicant.conf -D nl80211
下面是wpa_supplicant.conf的示例:
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
update_config=1
network=
ssid="NETGEAR73"
#psk="freshbutter"
psk=eb0376fc14ee5d1e6ce129ad54da038adab……
获取IP地址
获取wlan0的IP地址的命令如下:
udhcpc -i mlan0
第五章 图形
5.1 图形处理单元（GPU）
5.1.1介绍
图形处理单元(GPU)是一款针对嵌入式2D/3D图形应用的图形加速器。GPU3D (3D graphics processing unit)是一款嵌入式引擎，用于对OpenGL ES 1.1、OpenGL ES 2.0、OpenGL ES 3.0和OpenCL 1.1 ep等用户级图形接口进行加速。2D图形处理单元(GPU2D)是针对图形用户界面(GUI)渲染加速的嵌入式2D图形加速器。
VG图形处理单元(GPUVG)是一种嵌入式矢量图形加速器，用于支持OpenVG 1.1图形API和特性集。GPU驱动内核模块源代码在内核源树中，但库仅以二进制形式下发。
注意：
•GC400T不支持OpenGL ES 3.0。
•GC880/GC400T不支持OpenCL 1.1EP。GC2000和GC2000+支持OpenCL 1.1 EP。
•GC7000XSVX支持OpenCL 1.2 FP、OpenVX 1.0.1和Vulkan 1.0。
5.1.2驱动特性
GPU驱动使该单板能够提供以下软硬件支持:
•EGL (EGL是Khronos渲染API(如OpenGL ES或OpenVG)和底层原生平台窗口系统之间的接口) 1.5 API，由Khronos集团定义。
•OpenGL ES（OpenGL®ES是一种免版税的跨平台API，用于嵌入式系统上的全功能2D和3D图形）1.1 API，由Khronos Group定义。
•Khronos Group定义的OpenGL ES 2.0 API。
•由Khronos Group定义的OpenGL ES 3.0/3.1/3.2 API。
•OpenVG (OpenVG是一个免版税的跨平台API，为Flash和SVG等矢量图形库提供底层硬件加速接口) 1.1 API，由Khronos集团定义。
•OpenCL (OpenCL是现代处理器的第一个开放的、免版税的跨平台并行编程标准。)1.1EP API，由Khronos集团定义。
•Khronos Group定义的openGL 2.1 API。
•自动3D内核减速，当热驱动的热通知激活时，3D内核将以1/64时钟运行。
•由Khronos Group定义的OpenCL1.1/1.2FP API。
•由Khronos Group定义的OpenVX 1.0.1 API。
•由Khronos Group定义的Vulkan 1.0 API。
5.1.3硬件操作
详细的硬件操作请参见《应用处理器参考手册》中SoC相关的GPU章节。
5.1.4软件操作
GPU驱动分为两层。第一层以内核模式运行，充当整个堆栈的基本驱动程序。
这一层提供了基本的硬件访问、设备管理、内存管理、命令队列管理、上下文管理和电源管理。第二层运行在用户模式，实现堆栈逻辑，向上层应用提供如下api:
•OpenGL ES 1.1, 2.0和3.0 API
•egl 1.5 API
•OpenGL ES11/20/30/31/32
•OpenCL 1.1/1.2 FP
•OpenVX 1.0.1
•Vulkan 1.0
•OpenGL 4.0
•WebGL 1.0.2
•OpenVG 1.1 API
•OpenCL 1.1 EP API
5.1.5源代码结构
GPU驱动内核模块源结构如下表所示:
drivers/mxc/gpu-viv
5.1.6库结构
GPU驱动用户模式库结构如下表所示:
/usr/lib
**SONAME用于libEGL.so, libGLESv2.so, libGLESv1_CM.so, libGLESv1_CL.so, libGL.so。
libOpenVG.so，OpenVG特性有两个库。libOpenVG.3d基于GC7000XSVX/GC2000+/GC2000/GC880/ gc400的OpenVG库也是如此。libOpenVG.2d基于gc355的OpenVG库也是如此。
•对于i.MX 6DualPlus/QuadPlus和i.MX 6Dual/Quad，都是libOpenVG.3d.so, libOpenVG.2d.so可以用。
•对于i.MX 6DualLite和i.MX 6SoloX，只有libOpenVG.3d.so可以用。
•如果没有SOC限制，对于x11后端，libOpenVG.3d.so默认情况下是链接的。
•如果没有SOC限制，对于framebuffer, directFB和Wayland后端，默认的openVG库链接到libOpenVG.2d.so。
这可以通过使用下面的命令序列来完成:
cd /usr/lib
sudo ln -s libOpenVG_355.so libOpenVG.so
5.1.7 API参考
有关详细规格，请参阅以下网站:
• OpenGL ES 1.1, 2.0, and 3.0 API: www.khronos.org/opengles/
• OpenCL 1.1 EP www.khronos.org/opencl/
• EGL 1.4 API: www.khronos.org/egl/
• OpenVG 1.1 API: www.khronos.org/openvg/
• OpenGL ES API: www.khronos.org/opengles/
• OpenCL API: www.khronos.org/opencl/
• OpenVX API: www.khronos.org/openvx/
• Vulkan API: www.khronos.org/vulkan/
• OpenGL API: www.khronos.org/opengl/
• WebGL API: www.khronos.org/webgl
5.1.8菜单配置选项
在菜单配置中为GPU驱动启用以下模块:
CONFIG_MXC_GPU_VIV是GPU驱动的配置选项。在菜单配置中，该选项在设备驱动程序下可用
MXC support drivers > MXC Vivante GPU support > MXC Vivante GPU support.
在弹出的界面中，选择“配置内核”，选择Device Drivers > MXC support drivers > MXC Vivante GPU support > MXC Vivante GPU support,，然后退出。进入下一界面时，请选择以下选项开启图形处理器驱动:
•Package list > imx-gpu-viv
•这个包提供专有的二进制库，以及从GPU构建的测试代码，用于帧缓冲区
5.2 Wayland
5.2.1介绍
Wayland是一种合成器与客户端通信的协议，也是该协议的C库实现。合成器可以是一个独立的显示服务器，运行在Linux内核模式设置和evdev输入设备上，一个X应用程序，或者一个Wayland客户端本身。客户机可以是传统应用程序、X服务器或其他显示服务器。
Wayland项目的一部分也是Wayland合成器的Weston参考实现。Weston合成器是一个最小和快速的合成器，适用于许多嵌入式和移动的用例。
本章介绍如何在i.MX系列设备上使能Wayland/Weston支持。
5.2.2软件操作
此版本基于Wayland 1.16版本和Weston 5.0.0版本。
5.2.3 Yocto构建说明
Yocto项目的构建说明如下:
- 准备一个Yocto构建目录，并按照i.MX Yocto项目用户指南(IMXLXYOCTOUG)中的设置说明为DISTRO Wayland。
- 在构建目录中为Wayland设置Yocto:
$ MACHINE = DISTRO=fsl-imx-xwayland source imx-setup-release.sh -b build-wayland
3.建立一个映像。
$ bitbake imx-image-multimedia
5.2.4定制Weston
i.MX Weston包括两个合成器。一个是EGL3D合成器，它由3D内核加速。另一种是用2D BLT引擎加速的G2D合成。
Weston选项可以在文件“/etc/init.d/ Weston”中更新。
Weston支持多显示器
仅支持G2D合成器中支持多显示。添加以下选项来启动Weston:
weston --tty=1 --device=/dev/fb0,/dev/fb2 --use-g2d=1 &
Weston支持多缓冲区
Weston服务器支持单缓存和多缓存。在单一缓冲中，损坏区域被渲染到屏幕外表面，并被小块显示到前缓冲。屏幕外表面用于避免闪烁。默认情况下，Weston服务器以单个缓冲启动。
在多重缓冲中，不是渲染到屏幕外，而是将受损区域渲染到后台缓冲区并进行翻转，但帧率将受到显示率的限制。最多支持三个缓冲区。
在启动Weston服务器之前，导出FB_MULTI_BUFFER来控制要使用的缓冲区数量。
单个缓冲的环境变量:
export FB_MULTI_BUFFER=1
双缓冲的环境变量:
export FB_MULTI_BUFFER=2
5.2.5运行Weston
运行Weston需要执行如下操作:
- 启动i.MX设备。
- 要运行客户端，顶部栏中的第二个按钮将运行weston-terminal，从中您可以运行客户端。在Weston构建目录中有一些可用的演示客户端，但它们都非常简单，主要用于测试Wayland协议中的特定功能:
•“weston-terminal”是一个简单的终端模拟器，不是很兼容，但对bash来说足够好了。
•“weston-flower”在屏幕上绘制一朵花，测试框架协议。
•“weston-smoke”测试SHM缓冲区共享。
•“weston-image”加载通过命令行传递的图像文件并显示它们。
5.3 X Windows加速
5.3.1介绍
X- windows系统(又名X11或X)是一种可移植的、基于客户机-服务器的图形显示系统。X11仅支持i.MX 6。
X-Windows系统可以使用一个默认的帧缓冲驱动程序来处理所有到主显示器的绘图操作。因为有2D GPU(图形处理单元)可用，所以一些绘图操作可以加速。高级的X操作可以分解为低级的绘图操作，这些操作在X- windows系统中是加速的。
5.3.2硬件操作
X-Windows系统在i.MX上的加速使用了Vivante GC320 2D GPU。
加速度也依赖于帧缓冲存储器。
5.3.3软件操作
X- windows加速支持X.org X Server 1.11版本。支持EXA接口2.5版本。
下面的列表总结了X11加速的操作类型。所有操作都涉及到帧缓冲存储器，可以在屏幕上，也可以在屏幕外:
•矩形的实心填充。
•将系统内存中的图像上传到视频内存中。
•复制一个具有相同像素格式的矩形，可能的源目标矩形重叠。
复制一个支持大多数XRender合成操作的矩形:
—像素格式转换。
-重复模式源。
- Porter-Duff混合源与目标。
-源alpha屏蔽。
以下列表包括X-Windows加速支持的附加功能:
•直接在帧缓冲内存中分配X像素图。
•EGL交换缓冲区，其中EGL窗口表面是x窗口。
•X-窗口可以被合成为X像素图，可以直接用作任何EGL表面。
5.3.4 X-Windows加速架构
下面的框图显示了X-Windows系统加速所涉及的组件:
绿色显示的组件是作为Vivante 2D/3D GPU驱动支持的一部分提供的，包括OpenGL/ES和EGL。浅灰色显示的组件是X-Windows系统中没有加速的标准组件。橙色显示的组件是为支持X-Windows系统加速而添加的组件，这里对其进行了简要描述。
i.MX X驱动程序库模块(vivante-drv.so)由X服务器加载，包含X- windows加速接口的高级实现，用于包含GC320 2D GPU核心的i.MX平台。在/dev/fb0中的整个线性连续帧缓冲内存用于为X在屏幕上和屏幕外分配像素图。驱动程序支持一个自定义的X扩展，它允许X客户端查询存储在帧缓冲内存中的任何X像素图的GPU地址。
libGAL.so库模块(libGAL.so)包含到GC320 GPU模块的寄存器级编程接口。这包括将寄存器编程命令存储到数据包中，这些数据包可以流媒体传输到设备。libGAL.so库中的函数是由i.MX X驱动程序代码调用的。
EGL- X库模块(libEGL.so)包含底层EGL平台特定支持功能的X-Windows实现。这允许X-window和X pixmap对象被用作EGL窗口和pixmap表面。EGL-X库在其实现中使用Xlib函数调用以及i.MX X Driver模块的X扩展来查询存储在帧缓冲内存中的X像素图的GPU地址。
5.3.5 i.MX驱动程序for X-Windows系统
i.MX X驱动，称为vivante-drv.so，实现了X服务器的EXA接口来提供加速。
Vivante X 驱动，简称vivante-drv.so，实现了X服务器的EXA接口来提供加速。
下面的列表描述了这个实现的具体细节:
•实现建立在X的fbdev帧缓冲驱动的源代码上，这样当加速被禁用时，它可以作为回退。
•实现基于X server EXA version 2.5.0。
•EXA实体填充操作会加速，除非源/目标绘制包含小于300x300像素的情况下，这种情况下的回退是软件渲染。
•EXA复制操作会加速，除非源/目标绘制包含小于400x120像素，这种情况下的回退是软件渲染。
•EXA putimage(上传至显存)加速，除非源绘制包含小于400x400像素的情况下，这种情况下的回退是软件渲染。对于EXA实心填充和复制操作，只有实心平面蒙版和只有GXcopy光栅操作被加速。
•对于EXA复制操作，栅格操作(gxandreverse, GXnor, GXorReverse, GXorReverse, GXnand)不加速。
•EXA合成允许许多选项和源/掩码/目标的组合来渲染。
•大多数(常用的)EXA复合操作都是加速的。
以下类型的EXA复合操作是加速的:
•源/目标绘制包含至少640像素的复合操作。如果小于640像素，则复合路径落在软件上。
•当源/目标绘制包含超过200x200像素时，使用简单的源合成操作(不支持带掩码的操作)。
•恒定的源(带或不带alpha掩模)与目标复合。
•重复模式源(带或不带alpha掩码)与目标复合。
•只有这些混合函数:SOURCE, OVER, IN, IN- reverse, OUT-REVERSE和ADD(其中一些需要支持加速的组件alpha混合)。
•一般来说，以下几种(不太常用的)EXA复合操作是不加速的:
-转换(缩放，旋转)源和蒙版
-梯度源
-带有重复图案的Alpha掩码
该实现通过EXA回调接口处理X的所有pixmap分配。第一次尝试分配内存，它可以被物理GPU地址访问。如果剩余的GPU可访问内存不足，这个尝试可能会失败，但当为像素图请求的每像素位小于8时，它也可能失败。如果尝试从GPU可访问内存分配失败，那么内存将从系统中分配。如果pixmap内存是从系统中分配的，那么这个pixmap不能参与GPU加速选项。用于访问pixmap内存的字节数可能不同，这取决于它是从GPU可访问内存中分配还是从系统中分配。一旦为X像素图分配内存，无论它是来自GPU可访问内存还是来自系统，像素图都将被锁定，并且永远不能迁移到其他类型的内存。从GPU可访问内存到系统内存的Pixmap迁移是不必要的，因为系统虚拟地址对于GPU可访问内存总是可用的。目前还没有实现从系统内存到GPU可访问内存的Pixmap迁移，但只会在初始分配时GPU可访问内存不足，但稍后会有更多可用内存(通过回收分配)的情况下有帮助。Vivante 2D GPU的GPU可访问内存间距(水平)对齐是8像素。因为内存可以从GPU可访问内存中分配，这些像素可以在EGL中用于OpenGL/ES绘制操作。所有分配给/dev/fb0的内存都可用于基于EXA中使用的内部线性屏幕外内存管理器。超出屏幕内存的部分内存可用于分配X像素图，其中这个内存区域是GPU可访问的。分配给/dev/fb0的内存数量需要比屏幕所需的内存数量多几个MB。实际需要的数量取决于X- windows和使用的像素图的数量，X像素图作为纹理的可能使用情况，以及X- windows是否使用XComposite扩展。提供了一个X扩展，即图1所示的VIVEXT，以便X客户端可以查询与X像素图相关的物理GPU地址，如果该X像素图被分配在GPU可访问内存中。
5.3.6 X-Windows系统的i.MX直接渲染基础设施(DRI)
直接渲染基础设施，也被称为DRI，是一个允许在X窗口系统下以安全有效的方式直接访问图形硬件的框架。它包括对X服务器、几个客户机库和内核(DRM、直接渲染管理器)的更改。DRI最重要的活动是创建快速OpenGL和OpenGL ES实现，直接渲染到帧缓冲区内存。如果没有DRI, OpenGL驱动必须依赖X服务器进行最终渲染(间接渲染)，这大大降低了整体性能。
Vivante的DRI OpenGL实现组件包括:
•DRM (Direct Rendering Manager)是一个内核模块，为用户提供api来同步访问硬件，并管理不同类别的显存缓冲区。Vivante的DRI实现使用选定的DRM api来打开/关闭DRI设备，并锁定/解锁FB。大多数其他缓冲区管理和DMA管理函数由Vivante特定的内核模块处理:galcore.ko。
•EXA驱动程序是一个支持DRI的DDX 2D驱动程序，在X服务器启动时初始化DRM。由于所有X Window pixmap缓冲区都是由EXA驱动程序从GPU内存中分配的，如果缓冲区信息从X服务器进程正确地传递给X客户端进程(GL或GLES应用程序)，GPU可以直接渲染到这些缓冲区。
•vivante特定的X扩展“vivext”将缓冲区信息从X服务器传递到X客户端。这个Vivante X扩展包括以下三个接口: - DrawableFlush，允许X客户端通知X服务器为一个可绘制的表面刷新GPU缓存。
- DrawableInfo，允许X客户端从X服务器查询可绘制的信息(位置，大小，物理地址，步幅，剪贴板等)。
—PixmapPhysAddr，允许X客户端从X服务器查询pixmap缓冲区的物理地址和步数。
通过以下步骤实现GL/GLES应用窗口与Ubuntu Unity2D桌面的集成:
•GL/GLES应用程序将帧渲染到EXA驱动程序中分配的pixmap缓冲区中。
•在SwapBuffers实现中，驱动程序通过Xdamage和Xfixes api通知X服务器pixmap缓冲区被破坏。
•然后X服务器将呈现最新的pixmap缓冲区给Unity2D桌面，同时相对于桌面上的其他窗口保持适当的窗口重叠特征。
在合成X桌面，如Ubuntu Unity 2D, GLES/GL应用程序总是呈现到窗口的完整矩形后缓冲区中。不需要裁剪窗口。因此，Vivante DRI实现可以利用GPU的解析功能，并直接渲染到窗口后缓冲区。
在传统的X窗口桌面，如Gnome、Xwin等，GLES/GL应用程序必须直接渲染到帧缓冲区表面。因此，DRI驱动程序使用VIVEXT扩展中的DrawableInfo接口来获取窗口的剪贴列表，然后根据剪贴列表将渲染目标的子区域复制到帧缓冲区。这将确保GLES/GL窗口与桌面其他Windows重叠。然而，将渲染目标子区域复制到帧缓冲区必须由CPU完成，因为子区域的起始地址和对齐可能不满足GPU的复制要求。
Vivante DRI实现可以在运行时检测X窗口管理器的类型(合成桌面管理器或遗留桌面管理器)，并为GLES/GL应用程序使用适当的DRI呈现路径。
5.3.7 EGL- X库
当在X窗口系统中使用时，EGL-X库实现了低级EGL接口。下面的列表描述了细节
具体而言:
•eglDisplay本机显示类型为X中的“display *”。
•eglWindowSurfacenative窗口表面类型是“窗口”在X。
•eglPixmapSurface原生pixmap表面类型是“pixmap”在X。
当一个eglWindowSurface被创建时，用于双缓存的回缓冲区可以有不同于窗口表面的表示(基于所选的eglConfig)。当调用eglSwapBuffers时，尝试使用向窗口表面提供最有效的返回缓冲区内容的表示来创建每个返回缓冲区。
通过创建必要大小的X像素图来分配后台缓冲区。使用Vivante X Driver模块的X扩展来查询这个X像素图的物理帧缓冲区地址，如果它是在屏幕外的帧缓冲区内存中分配的。
5.3.8 xorg.conf for i.MX
使用i.MX 6x驱动需要正确配置/etc/X11/xorg.conf文件。
使用Vivante X Driver需要正确配置“/etc/X11/xorg.conf”文件。此配置出现在文件的“设备”部分，其中包含一些必需条目和一些可选条目。下面的例子显示了使用Vivante X驱动程序的首选配置:
Section "ServerLayout"
Identifier "Default Layout"
Screen "Default Screen"
EndSection
Section "Module"
Load "dbe"
Load "extmod"
Load "freetype"
Load "glx"
Load "dri"
EndSection
Section "InputDevice"
Identifier "Generic Keyboard"
Driver "kbd"
Option "XkbLayout" "us"
Option "XkbModel" "pc105"
Option "XkbRules" "xorg"
EndSection
Section "InputDevice"
Identifier "Configured Mouse"
Driver "mouse"
Option "CorePointer"
EndSection
Section "Device"
Identifier "Your Accelerated Framebuffer Device"
Driver "vivante"
Option "fbdev" "/dev/fb0"
Option "vivante_fbdev" "/dev/fb0"
Option "HWcursor" "false"
EndSection
Section "Monitor"
Identifier "Configured Monitor"
EndSection
Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Your Accelerated Framebuffer Device"
DefaultDepth 24
EndSection
Section "DRI"
Mode 0666
EndSection
强制性的字符串
以下是Vivante X驱动程序识别的一些重要条目。
设备标识符和屏幕设备字符串
设备部分中的必选标识符条目指定与此图形设备相关联的唯一名称。
Section "Device"
Identifier "Your Accelerated Framebuffer Device"
下面的条目将特定的图形设备绑定到屏幕上。设备标识符字符串必须与xorg.conf文件的屏幕部分中的设备字符串匹配。例如:
Section "Screen"
Identifier "Default Screen"
<other entries>
Device "Your Accelerated Framebuffer Device"
<other entries>
EndSection
设备驱动程序的字符串
必须的Driver条目指定可加载的Vivante X驱动程序的名称。
驱动“vivante”
设备fbdevPath字符串
必选条目fbdev和vivante_dev指定了要使用的帧缓冲区设备的路径。
Section "Device"
Identifier "Your Accelerated Framebuffer Device"
Driver "vivante"
Option "fbdev" "/dev/fb0"
Option "vivante_fbdev" "/dev/fb0"
<other entries>
EndSection
5.3.9在Yocto上设置X-Windows系统加速
先决条件:
•xserver-xorg-video-imx-viv-(ver).tar.gz，基于GPU驱动的Vivante EXA插件源代码
•drm-update-arm.patch添加了libdrm xf86drm.h的Arm锁实现。注意，来自libdrm的原始xh86drm.h头文件没有支持Arm架构的锁。该补丁位于社区Yocto Project layers Yocto build/sources/meta-freescale/recipes-graphics/drm/libdrm/mx6中，如下图所示:
drm-update-arm.patch:
+#elif defined(__arm__)
+ #undef DRM_DEV_MODE
+ #define DRM_DEV_MODE (S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH)
+
+ #define DRM_CAS(lock,old,new,__ret) \\
+ do \\
+ __asm__ __volatile__ ( \\
+ "1: ldrex %0, [%1]\\n" \\
+ " teq %0, %2\\n" \\
+ " strexeq %0, %3, [%1]\\n" \\
+ : "r" (__ret) \\
+ : "r" (lock), "r" (old), "r" (new) \\
+ : "cc","memory"); \\
+ while (0)
+
#endif /* architecture */
#endif /* __GNUC__ >= 2 */
构建和安装说明:
•在Yocto环境中，在适当的位置和正确的配方安装必备模块或补丁。
•使用正确的drm头文件(xf86drm.h)构建XServer。目的是创建正确的dri模块
•使用’ bitbake xf86-video-imxfb-vivante '命令构建GPU EXA模块。vivante_drv.so将与成功的构建一起生成，然后将其与xorg和libdri库一起安装在/usr/lib/xorg/modules中的目标板rootfs中/
•在目标板rootfs中安装预yocto构建的imx-gpu-viv二进制文件。为了加速X11，需要X11后端
•现在准备在目标板上运行X11应用程序。
注意：如果不使用Arm核心版本xf86drm.h, x11应用程序将关闭。
5.3.10 X Window系统加速设置
•安装适合您平台的任何软件包。
•检查设备文件/dev/galcore是否存在。
•检查/etc/X11/xorg.conf文件是否包含了上一节中描述的正确条目。
•假设上述步骤已经执行，执行以下操作来验证X Window系统加速确实在运行。
•检查日志文件/var/log/Xorg.0.log，确认存在以下行。
[ 41.752] (II) Loading /usr/lib/xorg/modules/drivers/vivante_drv.so
[ 41.752] (II) VIVANTE(0): using default device
[ 41.752] (II) VIVANTE(0): Creating default Display subsection in Screen section
"Default Screen" for depth/fbbpp 24/32
[ 41.752] (**) VIVANTE(0): Depth 24, (--) framebufferbpp 32
[ 41.752] (==) VIVANTE(0): RGB weight 888
[ 41.752] (==) VIVANTE(0): Default visual is TrueColor
[ 41.753] (==) VIVANTE(0): Using gamma correction (1.0, 1.0, 1.0)
[ 41.753] (II) VIVANTE(0): hardware: DISP3 BG (video memory: 8100kB)
[ 41.753] (II) VIVANTE(0): checking modes against framebuffer device...
[ 41.753] (II) VIVANTE(0): checking modes against monitor...
[ 41.753] (--) VIVANTE(0): Virtual size is 1920x1080 (pitch 1920)
[ 41.753] (**) VIVANTE(0): Built-in mode "current": 148.5 MHz, 67.5 kHz, 60.0 Hz
[ 41.753] (II) VIVANTE(0): Modeline "current"x0.0 148.50 1920 2008 2052 2200 1080
1084 1089 1125 +hsync +
vsync -csync (67.5 kHz)
[ 41.753] (==) VIVANTE(0): DPI set to (96, 96)
[ 41.753] (II) Loading sub module "fb"
[ 41.753] (II) LoadModule: "fb"
[ 41.754] (II) Loading /usr/lib/xorg/modules/libfb.so
[ 41.755] (II) Module fb: vendor="X.Org Foundation"
[ 41.755] compiled for 1.10.4, module version = 1.0.0
[ 41.755] ABI class: X.Org ANSI C Emulation, version 0.4
[ 41.755] (II) Loading sub module "exa"
[ 41.755] (II) LoadModule: "exa"
[ 41.756] (II) Loading /usr/lib/xorg/modules/libexa.so
[ 41.756] (II) Module exa: vendor="X.Org Foundation"
[ 41.756] compiled for 1.10.4, module version = 2.5.0
[ 41.756] ABI class: X.Org Video Driver, version 10.
[ 41.756] (--) Depth 24 pixmap format is 32 bpp
[ 41.797] (II) VIVANTE(0): FB Start = 0x33142000 FB Base = 0x33142000 FB Offset = (nil)
[ 41.797] (II) VIVANTE(0): test Initializing EXA
[ 41.798] (II) EXA(0): Driver allocated offscreenpixmaps
[ 41.798] (II) EXA(0): Driver registered support for the following operations:
[ 41.798] (II) Solid
[ 41.798] (II) Copy
[ 41.798] (II) Composite (RENDER acceleration)
[ 41.798] (II) UploadToScreen
[ 42.075] (==) VIVANTE(0): Backing store disabled
[ 42.084] (==) VIVANTE(0): DPMS enabled
5.3.11故障排除
- Framebuffer设备可以由环境变量指定。当有多个framebuffer设备时，这尤其有用。
export FB_FRAMEBUFFER_0=/dev/fb2 - 如果以上方法都不能解决问题:
•如果DRM正常启动，请检查/var/log/X11.n日志文件(N表示实例号)以获取更多信息。
•如果DRM没有正确引导，检查内核模式驱动程序安装。(请参阅上文第6.4.2和6.4.3节)。
3.窗口被创建，但没有绘制任何东西
•如果你运行一个OpenGL应用程序，发现创建了一个窗口，但没有绘制任何东西，尝试导出KaTeX parse error: Expected group after '_' at position 2: _̲_GL_DEV_FB环境变量…FB_FRAMEBUFFER_0。 - 无法打开显示消息
•如果你有一个类似于“Cannot open Display”的消息，使用以下命令来检查X是否运行在:0或:1实例，使用:
$ ps -ef |grep X
•然后根据返回的实例号，添加以下环境变量
export DISPLAY=:n
•然后再次运行。 - UART终端无法使用lightdm运行GPU应用程序
•使用ssh终端代替。 - EXA构建脚本失败
•检查日志文件，确保您的系统时间设置正确。 - 无效的MIT-MAGIC-COOKIE-1密钥错误消息
•某些GPU应用不允许使用root用户运行。使用备用账户代替。 - GPU应用运行过程中出现段故障
检查dev/galcore的属性是否应该更新为666。
•要在系统启动时自动更新此属性，
•找到并编辑文件/etc/udev/rules.d/。
•添加: “KERNEL==”galcore”,MODE=”0666””
最后，确保你的内核和GPU驱动是匹配的。 - 检查Compiz是否运行
•如果你的主机或目标在安装表6中的OpenGL开发包后有问题，检查compiz是否运行以下命令:
$ ps -ef |grep compiz
•如果compiz正在运行，那么Ubuntu默认使用Unity3D。将默认窗口管理器设置为Unity2D:
•找到并编辑文件/var/lib/AccountsService/users/。
•将“ubuntu”修改为“ubuntu -2d”。
以上是关于基于linux5.15.5的IMX 参考手册 --- 8的主要内容，如果未能解决你的问题，请参考以下文章