rk3588和fpga的pcie通信

pcie xdma

驱动编译

SHELL = /bin/bash # # optional makefile parameters: # - DEBUG=<0|1>, enable verbose debug print-out in the driver # - config_bar_num=, xdma pci config bar number # - xvc_bar_num=, xvc pci bar # # - xvc_bar_offset=, xvc register base offset # ​ DEBUG=0 #config_bar_num=1 # xvc_bar_num=1 ​ ifneq ($(xvc_bar_num),) XVC_FLAGS += -D__XVC_BAR_NUM__=$(xvc_bar_num) endif ​ ifneq ($(xvc_bar_offset),) XVC_FLAGS += -D__XVC_BAR_OFFSET__=$(xvc_bar_offset) endif ​ $(warning XVC_FLAGS: $(XVC_FLAGS).) ​ topdir := $(shell cd $(src)/.. && pwd) ​ TARGET_MODULE:=xdma ​ EXTRA_CFLAGS := -I$(topdir)/include $(XVC_FLAGS) ifeq ($(DEBUG),1) EXTRA_CFLAGS += -D__LIBXDMA_DEBUG__ endif ifneq ($(config_bar_num),) EXTRA_CFLAGS += -DXDMA_CONFIG_BAR_NUM=$(config_bar_num) endif #EXTRA_CFLAGS += -DINTERNAL_TESTING KERNELRELEASE:=/3588/kernel ​ # ifneq ($(KERNELRELEASE),) # $(TARGET_MODULE)-objs := libxdma.o xdma_cdev.o cdev_ctrl.o cdev_events.o cdev_sgdma.o cdev_xvc.o cdev_bypass.o xdma_mod.o xdma_thread.o # obj-m := $(TARGET_MODULE).o # else # BUILDSYSTEM_DIR:=/lib/modules/$(shell uname -r)/build # PWD:=$(shell pwd) ​ $(TARGET_MODULE)-objs := libxdma.o xdma_cdev.o cdev_ctrl.o cdev_events.o cdev_sgdma.o cdev_xvc.o cdev_bypass.o xdma_mod.o xdma_thread.o obj-m := $(TARGET_MODULE).o ​ # linux 源码目录 BUILDSYSTEM_DIR:=/sdk/06_rk3588_241027/61_moEr_d2k_3588/kernel PWD:=$(shell pwd) ​ CROSS_COMPLIE_3588:=/3588/prebuilts/gcc/linux-x86/aarch64/gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- ​ all : $(MAKE) -C $(BUILDSYSTEM_DIR) M=$(PWD) modules ARCH=arm64 CROSS_COMPILE=$(CROSS_COMPLIE_3588) ​ clean: #$(MAKE) -C $(BUILDSYSTEM_DIR) M=$(PWD) clean @/bin/rm -f *.ko modules.order *.mod.c *.o *.o.ur-safe .*.o.cmd ​ install: all @rm -f /lib/modules/5.15.0-67-generic/extra/xdma.ko @echo "installing kernel modules to /lib/modules/$(shell uname -r)/xdma ..." @mkdir -p -m 755 /lib/modules/$(shell uname -r)/xdma @install -v -m 644 *.ko /lib/modules/$(shell uname -r)/xdma @depmod -a || true ​ uninstall: @echo "Un-installing /lib/modules/$(shell uname -r)/xdma ..." @/bin/rm -rf /lib/modules/$(shell uname -r)/xdma @depmod -a ​ ​

驱动加载

[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[root@rk3588-buildroot /opt/00_test/pcie]#: 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. ​ [root@rk3588-buildroot /opt/00_test/pcie]#

设备节点

[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, 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, 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, 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 [root@rk3588-buildroot /opt/00_test/pcie]#xdma0_c2h 是card ---> host 有两个通道 xdma0_h2c 是host ---> card 有两个通道 ​ xdma0_control 驱动里对应的是dma相关的bar1 BAR1 at 0xf0300000 xdma0_user   驱动里对应的是自定义的bar0 BAR0 at 0xf0200000 xdma0_events   感觉是自定义的一些中断,类似于card拉高某个gpio,card端然后触发中断相关的操作,继续触发pcie中断通知host,驱动里就响应中断,判断相关                 event中断寄存器。个人感觉需要card配合才能使用。

关键api解读

  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;   } ​ 简单测试了下aperture的,传输速度要比下面的慢,后面就没用上面的接口传输了。暂时没理解上面传输的优缺点。read_to_buffer(devname, fpga_fd, buffer, size, addr) write_from_buffer(devname, fpga_fd, buffer, size, addr); ​ 两个api类似,注意最后的addr是card端的地址,从该addr获取或者放数据。假设card是fpga,该addr是ddr的地址。reg_rw工具移植到代码里的修改 ​ 第一次是这么修改的,只map一次,在map上偏移地址,去读取bar0上的值,发现不能读取的不对,应该是没有映射到bar0。   m_file_fd_user = open(m_devname_user, O_RDWR | O_SYNC); ​ ​ off_t target = 0x00; off_t pgsz, target_aligned, offset; ​ /* check for target page alignment */ pgsz = sysconf(_SC_PAGESIZE); offset = target & (pgsz - 1); target_aligned = target & (~(pgsz - 1)); ​ ​   //address: 0x0 (0x0+0x0), access read. ​ ​ m_map_user = mmap(NULL, offset + 4, PROT_READ | PROT_WRITE, MAP_SHARED, m_file_fd_user, target_aligned); ​ ​ 第二次,每次读取或者设置寄存器都先mmap,再用指针去操作,最后unmap,发现还是不行。 ​ 第三次,参考海思的工具himm,先知道bar0的物理地址,然后每次操作该bar空间的内存时就先open(/dev/mem),然后mmap,再偏移,操作完后unmap、close。这样子操作和使用reg_rw工具操作的值是一样的。

h2c 和 c2h的数据传输应该是h和c之间是有互动的,即通过user(bar0)来传递信息,大数据就通过dma传输。

Read more

【论文阅读】DreamZero:World Action Models are Zero-shot Policies

【论文阅读】DreamZero:World Action Models are Zero-shot Policies

快速了解部分 基础信息(英文): 题目: World Action Models are Zero-shot Policies 时间: 2026.02 机构: NVIDIA 3个英文关键词: World Action Models (WAMs), Zero-shot Generalization, Video Diffusion paper 1句话通俗总结本文干了什么事情 本文提出了一种名为DreamZero的机器人基础模型,通过同时预测视频和动作(world action model),让机器人能像人类一样通过“脑补”画面来规划动作,从而在从未见过的任务和环境中实现零样本泛化。 研究痛点:现有研究不足 / 要解决的具体问题 现有的视觉语言动作模型(VLAs)虽然擅长语义理解,但缺乏对物理世界动态(如几何、动力学)的理解,难以泛化到从未见过的新动作或新环境,且通常需要大量重复的演示数据。 核心方法:关键技术、模型或研究设计(

VLA机器人革命:解析当下10篇最关键的视觉-语言-动作模型论文

VLA机器人革命:解析当下10篇最关键的视觉-语言-动作模型论文

VLA机器人革命:解析当下10篇最关键的视觉-语言-动作模型论文 概览 2024-2026年,机器人领域正经历一场范式转换:从传统的任务特定编程转向视觉-语言-动作(Vision-Language-Action, VLA)模型。这些模型将视觉感知、自然语言理解和动作执行统一在单一框架中,让机器人能够像人类一样理解指令、推理场景并执行复杂操作。 本文精选5篇最fundamental的基础性论文和5篇热度最高的前沿论文,深入剖析VLA领域的核心思想、技术演进和未来方向。这些论文代表了从Google DeepMind、NVIDIA、斯坦福、Physical Intelligence等顶尖机构的最新突破,涵盖了从单臂操作到双臂人形机器人、从模拟环境到真实家庭场景的全方位进展。 Part I: 五篇Fundamental基础性论文 这些论文奠定了VLA领域的理论基础和技术范式,是理解整个领域发展脉络的关键。 1. RT-2: New Model Translates Vision and Language into Action 发表机构:Google DeepMind 时间:

云开发 Copilot:AI 赋能的低代码革命

云开发 Copilot:AI 赋能的低代码革命

前些天发现了一个巨牛的人工智能学习网站,通俗易懂,风趣幽默,忍不住分享一下给大家。点击跳转到网站。 云开发 Copilot:AI 赋能的低代码革命 目录: * 一、引言:AI 时代的开发新纪元 * 1.1 低代码与AI的完美融合 * 1.2 云开发 Copilot的革命性意义 * 二、云开发 Copilot 的核心特性解析 * 2.1 快速生成应用功能 * 2.2 低代码与AI的深度结合 * 三、实战演练:云开发 Copilot 的应用案例 * 3.1 从需求到实现的快速迭代 * 3.2 低代码页面的AI生成 * 四、云开发 Copilot 的技术亮点 * 4.1 全栈开发支持 * 4.

机器人标准DH(SDH)与改进DH(MDH)

机器人标准DH(SDH)与改进DH(MDH)

首先说一下为什么要写这一篇博客,就是为了提醒大家要明确区分标准DH和改进DH。很多机器人初学者只知道用DH法建立串联机器人连杆坐标系,然后在看书或者使用DH的时候很糊涂的就模糊了这标准DH和改进DH的区别,最大的坑就是:一些比较老的机器人学教科书用的是标准DH,而现在比较新的机器人书或者说我们大部分用的都是改进DH,这就导致老的教科书里面的一些公式推导和新的网上找的代码不一致,就会比较麻烦。 一:改进DH法 建立连杆坐标系: 使用改进D-H参数,将 坐标系定义在i 连杆的前端关节: 二:标准DH与改进DH法的区别 我们知道一个连杆有两端,一端离基座近,一端离基座远。简单的来说,标准DH将坐标系i建立在连杆i离基座近的一端,改进DH建立在离基座远的一端。 2.1 机器人连杆与关节的标号 先标号,再建系。 连杆编号:基座为杆0,从基座往后依次定义为杆1,杆2,…,杆i; 关节编号:杆i离基座近的一端(近端)的关节为关节i,远的一端(远端)为关节i+1。 为便于理解,这里我把连杆的近端用绿色表示,远端用橙色表示,且远端驱动近端转动。大家只要记住一句话,连杆近端关节