本帖最后由 gztwdz4379 于 2025-8-29 09:26 编辑
前言：在 RK3588 平台开发过程中，你是否遇到过这样的窘境：明明 PCIe 总线上挂好了网卡模块，lspci 能识别到芯片，可驱动就是加载失败，排查半天找不到关键问题？别慌！本文将带你一步步解决这个棘手问题。
一、案例背景
使用眺望电子 RK3588核心板的PCIE20_0/1/2接口挂载裕太微yt6801芯片扩展网卡为例，看看问题到底有多棘手。 通过lspci命令查看设备状态时，能清晰看到 yt6801 芯片的存在，三个网卡设备均显示为 “Ethernet controller: Device 1f0a:6801 (rev 01)”，从表面看似乎一切正常。
可当执行insmod yt6801.ko加载驱动时，报错信息却接连弹出驱动加载直接失败，网卡根本无法使用。
明明硬件连接没问题，设备也能被识别，为什么驱动就是 “不听话”？这背后肯定藏着我们没注意到的关键细节。
二、根源分析
问题不能看表面，深入日志查原因
查看系统日志时发现，出问题的 PCIe 设备与正常设备的 class 类型截然不同。正常工作的两个 PCIe 设备（0002:20:00.0 和 0001:10:00.0），class 类型均为 0x060400；而加载驱动失败的 PCIe 设备（0004:40:00.0），class 类型却显示为 0x000000。
在SDK/kernel/include/linux/pci_ids.h文件中定义了不同class类别。其中0x000000为PCI_CLASS_NOT_DEFINED，即为未定义；而0x060400为PCI_CLASS_BRIDGE_PCI，即为PCIe桥。只有正确识别设备类型，内核才能进行后续的资源分配和驱动加载。 由于该 PCIe 设备的 class 类型非法（未定义），系统无法正确识别其功能属性，导致 Memory BAR 资源分配异常（lspci 中 BAR 资源会显示 unassigned 状态），最终造成网卡驱动加载失败。 找到根源后，解决问题就有了明确方向。
三、解决方案
想要解决这个问题，最根本的方式是联系模块供应商，让其对模块的 class 类型进行正确配置。但如果遇到无法修改硬件配置，或需要临时应急的情况，可以参考下文尝试对模块的class类型进行软件修复，具体只需如下3步： 3.1 定位修改文件 打开RK3588的SDK，找到内核中的kernel/drivers/pci/quirks.c文件。该文件主要用于处理 PCI 设备的特殊配置和兼容性问题，是我们进行软件修复的关键位置。 3.2 添加修复代码 在quirks.c文件中，新增以下两段代码：
1.定义 class 类型修复函数
- static void quirk_class_id_fixup(struct pci_dev *dev)
- {
- dev->class = 0x060400; // 将class类型设置为标准PCIe桥类型
- }
2.注册修复逻辑
- DECLARE_PCI_FIXUP_CLASS_EARLY(0x1d87, 0x3588, PCI_CLASS_NOT_DEFINED, 8, quirk_class_id_fixup);
这里需要注意：0x1d87是 RK3588 的 Vendor ID（厂商 ID），0x3588是对应的 Device ID（设备 ID），PCI_CLASS_NOT_DEFINED指定针对未定义 class 类型的设备进行修复，0x060400则是我们要修复到的正确 class 类型。 3.3 加修复代码 代码添加完成后，重新编译内核镜像，将编译好的镜像烧录到 RK3588 核心板中，通过命令验证修复效果： 1、执行lspci命令，已正确显示为 “PCI bridge: Fuzhou Rockchip Electronics Co., Ltd Device 3588 (rev 01)”，class 类型修复成功。 2、执行insmod yt6801.ko加载驱动，此时不再出现报错信息，驱动加载成功。 3、执行ifconfig命令，能看到新增的网卡接口（如 enP4p65s0），且接口状态正常，支持 UP、BROADCAST、MULTICAST 等模式，说明网卡已能正常工作。
至此，RK3588 PCIe 非法class类型导致的网卡驱动无法加载问题，已完全解决。 四、小结
本文提供的解决方案基于特定硬件平台验证，实际应用中需根据具体设备调整VID/PID及class类型参数。如果你在 RK3588 平台或者我司核心板开发中还遇到过其他 PCIe 相关难题，请关注眺望电子或在评论区留言分享，我们一起交流探讨！
| 
