RK3588 与 FPGA 基于 XDMA 的 PCIe 通信实践

驱动加载

编译完成后，使用 insmod 加载模块并观察 dmesg 日志，确认 BAR 映射及设备初始化状态。

[root@rk3588-buildroot /opt/00_test/pcie]# insmod xdma.ko
[   20.349214] xdma: loading out-of-tree module taints kernel.
[   20.351795] xdma:xdma_mod_init: Xilinx XDMA Reference Driver xdma v2020.2.2
[   20.351818] xdma:xdma_mod_init: desc_blen_max: 0xfffffff/268435455, timeout: h2c 10 c2h 10 sec.
[   20.352450] xdma:xdma_device_open: xdma device 0000:01:00.0, 0x00000000405154b7.
[   20.352498] xdma 0000:01:00.0: enabling device (0000 -> 0002)
[   20.352599] xdma:map_single_bar: BAR0 at 0xf0200000 mapped at 0x00000000708655f0, length=1048576(/1048576)
[   20.352616] xdma:map_single_bar: BAR1 at 0xf0300000 mapped at 0x000000006b5b942f, length=65536(/65536)
[   20.352625] xdma:map_bars: config bar 1, pos 1.
[   20.352633] xdma:identify_bars: 2 BARs: config 1, user 0, bypass -1.
[   20.354467] xdma:pci_keep_intx_enabled: 0000:01:00.0: clear INTX_DISABLE, 0x406 -> 0x6.
[   20.354548] xdma:probe_one: 0000:01:00.0 xdma0, pdev 0x00000000405154b7, xdev 0x00000000a58ffaf7, 0x00000000cc9a9c39, usr 16, ch 2,2.
[   20.358004] xdma:cdev_xvc_init: xcdev 0x0000000005eef4e4, bar 0, offset 0x40000.

设备节点解析

驱动加载成功后，/dev 下会生成对应的字符设备节点。通过 ls 命令查看可了解各节点的用途。

[root@rk3588-buildroot /opt/00_test/pcie]# ls /dev/xdma0_* -lh
crw------- 1 root root 234, 36 Jan 1 08:00 /dev/xdma0_c2h_0
crw------- 1 root root 234, 37 Jan 1 08:00 /dev/xdma0_c2h_1
crw------- 1 root root 234, 1 Jan 1 08:00 /dev/xdma0_control
crw------- 1 root root 234, 10 Jan 1 08:00 /dev/xdma0_events_0
crw------- 1 root root 234, 11 Jan 1 08:00 /dev/xdma0_events_1
crw------- 1 root root 234, 12 Jan 1 08:00 /dev/xdma0_events_2
crw------- 1 root root 234, 13 Jan 1 08:00 /dev/xdma0_events_3
crw------- 1 root root 234, 14 Jan 1 08:00 /dev/xdma0_events_4
crw------- 1 root root 234, 15 Jan 1 08:00 /dev/xdma0_events_5
crw------- 1 root root 234, 16 Jan 1 08:00 /dev/xdma0_events_6
crw------- 1 root root 234, 17 Jan 1 08:00 /dev/xdma0_events_7
crw------- 1 root root 234, 18 Jan 1 08:00 /dev/xdma0_events_8
crw------- 1 root root 234, 19 Jan 1 08:00 /dev/xdma0_events_9
crw------- 1 root root 234, 20 Jan 1 08:00 /dev/xdma0_events_10
crw------- 1 root root 234, 21 Jan 1 08:00 /dev/xdma0_events_11
crw------- 1 root root 234, 22 Jan 1 08:00 /dev/xdma0_events_12
crw------- 1 root root 234, 23 Jan 1 08:00 /dev/xdma0_events_13
crw------- 1 root root 234, 24 Jan 1 08:00 /dev/xdma0_events_14
crw------- 1 root root 234, 25 Jan 1 08:00 /dev/xdma0_events_15
crw------- 1 root root 234, 32 Jan 1 08:00 /dev/xdma0_h2c_0
crw------- 1 root root 234, 33 Jan 1 08:00 /dev/xdma0_h2c_1
crw------- 1 root root 234, 0 Jan 1 08:00 /dev/xdma0_user
crw------- 1 root root 234, 2 Jan 1 08:00 /dev/xdma0_xvc

各节点功能说明：

• xdma0_c2h：Card 到 Host 传输通道（共两个）。
• xdma0_h2c：Host 到 Card 传输通道（共两个）。
• xdma0_control：对应驱动中的 DMA 控制 BAR1（地址 0xf0300000）。
• xdma0_user：对应自定义 BAR0（地址 0xf0200000），用于用户态交互。
• xdma0_events：中断事件通知，通常由 Card 端触发 GPIO 拉高，经 PCIe 中断通知 Host，驱动响应后写入相关寄存器。此类机制通常需要端侧配合才能生效。

关键 API 与内存映射

在用户态进行数据传输时，主要涉及 aperture 接口和 buffer 读写接口。实测发现 aperture 接口性能不如直接 buffer 读写，后续未采用该方式。

核心代码逻辑如下：

if (aperture)
{
    struct xdma_aperture_ioctl io;
    io.buffer = (unsigned long)buffer;
    io.len = size;
    io.ep_addr = addr;
    io.aperture = aperture;
    io.done = 0UL;
    rc = ioctl(fpga_fd, IOCTL_XDMA_APERTURE_R, &io);
    if (rc < 0 || io.error)
    {
        log_pcie("aperture R failed %d,%d.\n", rc, io.error);
        goto out;
    }
    bytes_done = io.done;
}
else
{
    rc = read_to_buffer(devname, fpga_fd, buffer, size, addr);
    if (rc < 0)
        goto out;
    bytes_done = rc;
}

其中 read_to_buffer 和 write_from_buffer 是常用接口，最后的 addr 参数指定 Card 端的物理地址（如 DDR 地址）。

关于寄存器访问（reg_rw 类功能），在调试过程中我们经历了几个阶段：

1. 初次尝试：仅 map 一次，在映射基础上偏移地址读取 BAR0 值，结果数据不对，推测是未正确映射到 BAR0 空间。
2. 二次尝试：每次读取或设置寄存器前都先 mmap，操作完 unmap，发现仍无法获取正确值。
3. 最终方案：参考海思工具 himm 的实现思路，先获取 BAR0 的物理地址，每次操作该 BAR 空间内存时，先 open /dev/mem，再 mmap 并偏移，操作完后 unmap 并 close。这种方式与 reg_rw 工具的操作结果一致，验证了通过 /dev/mem 动态映射 BAR 空间的可行性。

总体而言，H2C 和 C2H 的大数据传输依赖 DMA 通道，而 H 和 C 之间的控制信息交互则通过 User 空间（BAR0）传递。