修改RK3588设备树,解决因引脚复用导致IO口不足问题Device or resource busy

问题描述:

        本人在做电机驱动时遇到了引脚不足的情况,想去找到一个空闲引脚做为IO口控制电机,却因为RK3588的高度集成化导致原本就少的可怜的外露引脚都被复用了,所以需要通过修改设备树来屏蔽掉原本引脚复用的功能。这里我使用的是创龙的RK3588评估板。

解决步骤:

        首先查看自己的目标引脚的GPIO口是什么,我们可以通过开发板的供应商提供的原理图和引脚复用资料来查看对应引脚的GPIO口。

        这里我使用的引脚是GPIO4_A7_d,这个引脚的复用功能也在图表中写出。

        在瑞芯微中,引脚编号的计算方法是(如GPIO4_A7):4×32+0×8+7=135。具体计算方法是Bank×32 + Group×8 + 组内编号。在Group中(A=0,B=1,C=2,D=3)。

        如果此时我们直接在开发板上使用sysfs接口导出gpio引脚,如echo 135 > /sys/class/gpio/expor可能会出现Device or resource busy资源正在被占用且无法删除的情况,这也就是本文所遇到的问题。

        此时我们进入开发板中,执行如下指令可查看此时的引脚复用状态。

cat /sys/kernel/debug/pinctrl/pinctrl-rockchip-pinctrl/pinmux-pins

        会输出如图所示的状态,找到你的目标引脚,查看当前被什么复用。之后进入官方(你的开发板是那个商家的,找那个商家要设备树,一般会随着开发资料一起发给你)提供的设备树文件(一般都是dts文件,需要使用vim或nano编辑,不能使用图形化界面打开),找到正在占用的功能,将它的status改为disabled。 并在其中加入pinctrl使得引脚能够作为普通的IO使用。(至于加入的pinctrl可以交给deepseek根据你的实际需求来写)

        这是我已经修改好的设备树文件,我将设备树中所有的dsi1 状态改为disabled(需要注意一点就是要确定你修改的引脚,所复用的功能是你用不到的,避免相互冲突)。

        之后保存、退出设备树,编译设备树文件生成boot.img文件,之后再转为FIT格式,拷贝到开发板内,执行镜像替换指令,之后再强制写入数据,最后重启。如果修改成功的话开发板会正常重启,如果重启失败说明设备树修改失败,需要你把错误信息喂给AI分析,或者自己具备读英文日志的能力,能够自己分析出问题。

设备树编译方法:

        之前我没有仔细的看过官方提供的编译方法,因此一直不懂怎么编译。这里我按照创龙那边的编译方法,把一些基本用不到但是依旧写在了编译文档中的内容省略掉。

        在修改完设备树之后,回到Kernel文件下(注意是在虚拟机中的Kernel,不是开发板的),配置你的内核编译选项,如下图为创龙的步骤。

 配置好之后,回到Kernel目录下(一定要回到Kernel,指令前名字确保为)执行编译指令。最后对生成的boot.img转换成FIT格式。转换代码如下:

#!/bin/bash -e

TARGET_IMG=boot.img
ITS=boot.its
KERNEL_IMG=arch/arm64/boot/Image
KERNEL_DTB=arch/arm64/boot/dts/rockchip/tl3588-evm.dtb
RESOURCE_IMG=resource.img

if [ ! -f "$TARGET_IMG" ]; then
	echo "$TARGET_IMG not exists!"
	exit 1
fi

if [ ! -f "$ITS" ]; then
	echo "$ITS not exists!"
	exit 1
fi

if [ ! -f "$KERNEL_IMG" ]; then
	echo "$KERNEL_IMG not exists!"
	exit 1
fi

if [ ! -f "$KERNEL_DTB" ]; then
	echo "$KERNEL_DTB not exists!"
	exit 1
fi

if [ ! -f "$RESOURCE_IMG" ]; then
	echo "$RESOURCE_IMG not exists!"
	exit 1
fi

sed -i -e "s~@KERNEL_DTB@~$(realpath -q "$KERNEL_DTB")~" \
	-e "s~@KERNEL_IMG@~$(realpath -q "$KERNEL_IMG")~" \
	-e "s~@RESOURCE_IMG@~$(realpath -q "$RESOURCE_IMG")~" "$ITS"

rkbin/tools/mkimage -f "$ITS"  -E -p 0x800 "$TARGET_IMG"

### RK摄像头驱动中VIDIOC_DQBUF错误16的解决方案 在RK摄像头驱动开发过程中,遇到 `VIDIOC_DQBUF` 错误代码为 16(设备或资源忙)时,通常表示当前缓冲区正在被其他进程使用或未正确释放。以下是可能的原因及解决方法: #### 1. 缓冲区未正确释放 如果在调用 `VIDIOC_DQBUF` 前未正确释放先前分配的缓冲区,可能导致资源占用问题。确保在每次操作后正确释放缓冲区[^1]。 ```c for (int i = 0; i < buffer_count; i++) { struct v4l2_buffer buf; CLEAR(buf); buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; buf.memory = V4L2_MEMORY_MMAP; buf.index = i; if (-1 == xioctl(fd, VIDIOC_QBUF, &buf)) { perror("VIDIOC_QBUF"); } } ``` #### 2. 多线程竞争问题 当多个线程同时访问摄像头设备时,可能会导致资源冲突。建议使用互斥锁(mutex)来同步对设备的访问[^2]。 ```c pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; void *capture_thread(void *arg) { pthread_mutex_lock(&mutex); // 摄像头捕获逻辑 pthread_mutex_unlock(&mutex); return NULL; } ``` #### 3. 设备未正确关闭 如果在程序退出时未正确关闭设备文件描述符,可能导致资源未释放。确保在程序结束前调用 `close(fd)`[^3]。 ```c if (-1 == close(fd)) { perror("close"); } fd = -1; ``` #### 4. 驱动程序中的BUG 某些情况下,可能是驱动程序本身存在缺陷。检查内核版本是否为最新,并更新到支持该硬件的稳定版本[^4]。 ```bash uname -r apt-get update && apt-get upgrade ``` #### 5. 资源限制 如果系统中打开的文件描述符过多,也可能导致资源忙。可以调整系统的文件描述符限制[^5]。 ```bash ulimit -n 4096 ``` ### 注意事项 - 确保所有缓冲区操作遵循正确的顺序:请求缓冲区、映射缓冲区、排队缓冲区、取消队列缓冲区。 - 在调试时,可以启用 V4L2 的日志功能以获取更多详细信息。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值