1. 项目概述与选型背景1.1 核心需求解析做边缘计算网关选型这事我前后折腾了将近两个月从最初只看芯片参数、跑分到最后不得不重新审视整个硬件平台方案中间踩了不少坑。今天把这些经历整理出来希望能给正在做RK3568方案选型的朋友一些参考。先交代一下项目背景。我们做的是一款面向工业现场的边缘计算网关主要部署在工厂车间、变电站、园区配电房这类场景承担三件事一是通过RS485、Modbus、CAN等协议采集现场设备数据二是做数据清洗、协议转换和本地逻辑判断三是把处理后的数据通过以太网或4G/5G上传到云端平台。整个项目对算力的要求其实不高不跑复杂的AI模型也做不了高帧率的视频分析核心诉求是多接口、低功耗、高稳定性、宽温工作。选RK3568的原因也很直接这颗芯片在瑞芯微的产品线里属于中端偏下的定位四核A55架构自带1TOPS的NPU支持多路显示和多路网络接口最关键的是价格合适。对比过全志T507、飞腾派、海思Hi3559A等方案之后综合性能和价格RK3568确实是当时最合适的选择。不过回过头来看选型这件事远不是一个芯片型号能解决的。真正的坑或者说真正决定项目成败的是对芯片周边生态的把握对硬件设计细节的掌控对系统软件适配预判。下面把这五个坑逐个展开配上我当时踩坑的具体过程和处理方案。1.2 方案选型的整体思路在展开五个坑之前先说说我当时选型的整体思路这样后面的细节才有上下文。第一明确产品形态。我们做的是无风扇工业网关需要7x24小时运行外壳是铝型材被动散热工作温度要求-20℃到70℃这意味着芯片的TDP热设计功耗不能太高RK3568的功耗范围大概在2W到6W之间符合要求。第二确认外设资源。现场设备采集需要至少2路RS485、1路CAN、双网口一个WAN一个LAN、2路DI、2路DO最好支持4G模块和WiFi。RK3568原生支持丰富的外设接口通过引脚复用可以满足这些需求。第三供应链稳定性。虽然这是2024年的选型但当时海思被制裁后的供应链影响还在持续全志和瑞芯微是少数能稳定供货的国产芯片厂商。瑞芯微的RK3568发布已有几年经历过大规模出货验证生命周期长不用担心半路停产。第四软件生态。RK3568的Linux BSP板级支持包相对成熟官方SDK基于buildroot和Debian社区资料多遇到问题容易查到解决方案。这点在做产品时确实重要芯片再强软件资料一片空白的话开发周期会被无限拉长。方向定下来之后就开始进入实战环节然后才真正体会到什么叫纸上得来终觉浅。2. 核心细节解析与实操要点2.1 坑一芯片选型忽略SKU差异内存封装形式标注不清这是我在选型阶段踩的第一个坑也是很多人容易忽略的。RK3568这颗芯片有不同的封装和内存搭配方案包括RK3568J工业级、RK3568商业级核心板厂商在出方案的时候又有DDR3L、DDR4、LPDDR4、LPDDR4X等多种内存配置。我当时拿到一个核心板厂商的报价看到RK3568加2GB内存以为所有方案都差不多结果在后续测试阶段才发现不同的内存方案在稳定性上有明显差距。具体来说LPDDR4X在高温下的表现比DDR4稳定功耗也更低适合无风扇的封闭式网关环境。而DDR4方案在成本上有优势但颗粒的体积和功耗在紧凑的PCB布局里会带来额外的散热压力。另外部分核心板厂商为了成本用的是二手颗粒或者混合颗粒这在常态环境下可能没什么问题但在高温模拟测试里就原形毕露了。我在选型时踩的坑是只盯着芯片型号没有充分验证内存颗粒的具体型号和来路。第一批样品回来后在70℃高温箱里跑了48小时结果有两台设备出现随机重启查了几天才定位到是内存颗粒在高温下时序不稳定。处理方案比较直接联系核心板厂商要求更换内存颗粒批次同时在核心板选型时就明确要求提供颗粒品牌和型号杜绝来路不明的颗粒。对于工业级产品建议优先选择LPDDR4X方案并且多花一点成本选择瑞芯微官方认证的核心板合作伙伴他们对颗粒筛选和测试更严格。这个坑的教训是选型看芯片没错但芯片只是一颗裸片真正决定产品稳定性的是你选的模组承载了什么颗粒、什么工艺、什么品控。2.2 坑二电源设计与启动时序问题藏在硬件设计细节里第二个坑发生在打板之后表现为主板偶发性不上电按复位键有时候能起来有时候不能。用示波器抓了各路电源的上电时序发现RK3568对电源时序要求比较严格如果各路电源的上电顺序不满足规格书要求会直接导致CPU无法正常启动或者启动后运行不稳定。RK3568参考设计的电源树包括VDD_CPU、VDD_GPU、VDD_LOGIC、VDD_DDR等多路供电每路电源都有明确的上电顺序要求例如VDD_LOGIC必须在VDD_CPU之前稳定DDR电源必须在CPU复位释放之前稳定。我遇到的坑是因为布局空间紧张把VDD_CPU的DC-DC转换器放在了离CPU较远的位置导致在负载波动时该路电源纹波偏大上电瞬间电压建立时间变长间接影响了时序逻辑。虽然原理图完全按照参考设计画的但PCB布局的不规范让电源质量打了折扣。解决方案是调整PCB布局把DC-DC转换器尽量靠近负载端同时增加输入输出电容重新洗板后问题消失。这个坑给我们的教训是RK3568这类多电源轨SoC布局布线对电源完整性的影响被很多人低估了尤其是DC-DC电感容易产生EMI干扰不能随意放置。后来在整理选型清单时我把电源设计检查加入到了硬件评审表里包括各路电源的上电时序是否满足芯片规格书要求DC-DC电感和电容的位置是否合理复位电路是否有延时是否满足复位时序要求3.3V、1.8V等IO电平是否与外围器件的电平匹配对于没有硬件设计经验或者想加快进度的团队我更建议直接买成熟的核心板。核心板厂商已经把CPU、DDR、电源、时钟、启动方式这些最难的硬件部分做好了你只需要关注底板的外围接口设计。虽然核心板整套方案的成本会比自行设计高20块左右但换来的是启动稳定性和更短的开发周期这笔账值得算。注意带宽设计时一定要把整板的总电源预算做宽一些不要卡着典型功耗硬上限来算至少要预留20%的裕量。2.3 坑三设备树选择混乱同名外设引脚冲突排查RK3568的Linux BSP里包含了大量的设备树dts/dtsi文件打开内核源码的arch/arm64/boot/dts/rockchip/目录你会看到成百上千个文件。RK3568相关的有rk3568-evb.dts、rk3568-evb1-ddr4-v10.dts、rk3568-evb2-lp4x-v10.dts、rk3568-nvr-demo.dts等而且不同核心板厂商又会在自己的SDK里加入自己的设备树文件。对于刚上手的人来说看这些文件确实容易懵。我们项目里出现的具体问题是使用某个核心板厂商提供的底板参考设计设备树选的是rk3568-evb.dts编译烧录后系统能启动但RS485串口无法收发数据。排查下来发现RK3568的UART2和UART3引脚默认被复用到了其他功能而EVB设备树里对UART2的控制节点跟我们的底板设计不一致。这个坑的根源是——不同底板对引脚的复用要求不同设备树必须与具体硬件一一对应不能拿来就用。核心板厂商通常会提供配套的底板设备树但如果你自己设计了底板就需要根据实际电路图修改设备树的pinctrl复用关系。在RK3568上每个引脚的复用功能很多同一个物理引脚可能承担UART、CAN、GPIO、I2C等多个功能选项设备树里通过pinctrl节点来配置引脚的复用模式。选用的复用方式与硬件原理图不一致就会出现功能异常而且在系统启动日志里往往只提示failed to get pinctrl或者干脆没有任何提示排查起来非常费劲。解决这个问题的正确步骤如下从核心板厂商拿到对应的设备树源文件优先使用与核心板型号匹配的dts文件而不是通用的EVB文件对照自己底板的原理图逐个确认每个使用到的引脚是否被正确配置为对应的功能模式修改设备树文件后编译生成新的boot.img烧录验证如果修改量大可以先通过uEnv.txt或者bootargs动态加载设备树覆盖文件DTBO方便迭代调试为了方便对照我当时做了一个引脚复用检查表把RK3568涉及到的40多个GPIO/功能引脚都列出来然后与底板原理图逐一核对。虽然刚开始耗时较多但后面排查问题真的能节省大量时间。2.4 坑四网络桥接与网关稳定性的磨合边缘计算网关通常需要至少两个网口一个连接外网上云一个连接内网采集设备数据。我们当时使用了双网口方案其中一个网口直连路由器的LAN口另一个网口连接现场的设备网络。理论上下面的设备通过网关可以实现与其他区域的互通但实际调试的时候出现了网络丢包率偏高、Ping包延迟波动大的问题。这个坑的本质有两个方面一是RK3568的网口驱动配置问题二是系统里的网络桥接配置问题。先看驱动配置。RK3568有两个GMACGigabit Media Access Controller控制器以太网PHY则根据硬件连了不同的型号。如果PHY的中断引脚或者复位引脚在设备树里没有正确配置或者PHY的时钟源选择错误会导致链路协商速度异常。比如明明接的是千兆交换机协商出来的速度却是百兆甚至出现间歇性断连。这类问题在启动日志里一般能看到类似stmmaceth0000:00: PHY reset timed out的提示。再看网络桥接。网关里我一开始用了Linux的bridge模块直接把两个网口桥接在一起以为这样能实现数据透明转发。但实际测试发现桥接模式在大量小数据包的情况下效率不够高延迟抖动明显而且如果两个网口分别在不同VLAN下还需要额外的VLAN配置。后面根据项目实际需求做了调整改用路由器模式wan口通过DHCP或者静态IP连接上层网络lan口使用独立的子网然后启动内核的NAT转发功能。这样隔离了两个网络域还能对lan口做流量控制和防火墙规则稳定性比直接桥接好了很多。关于如何ping网关这个热搜词我这里也顺带说一下。如果你在调试现场发现设备无法Ping通网关优先排查以下几步确认设备的IP地址、子网掩码、网关地址是否设置正确确认网关的物理网口是否处于开启状态网线是否插好用arp命令查看网关MAC地址是否学习到在PC上分别Ping网关IP和网关设备自身的局域网IP判断是链路问题还是设备转发问题提示Ping得通不一定代表网络通Ping不通也不一定代表网络不通。有些设备默认开启了防火墙禁掉了ICMP协议但HTTP、MQTT等业务协议可能正常。判断网络状态时最好结合端口测试和应用层验证一起来做。2.5 坑五调试串口与系统日志的暗坑第五个坑看起来不大但足以让人抓狂——调试串口的输出。RK3568平台默认的调试串口是UART2波特率是15000001.5Mbps。这个波特率不是常规的115200很多工程师在连接调试串口时沿用旧习惯直接设置成115200结果是屏幕上完全不显示任何输出或者显示乱码。我第一次调试的时候也差点踩坑还好后来仔细查阅了瑞芯微的调试手册才把波特率改成1500000。这个细节在瑞芯微平台早年就有了一直延用到现在但仍然有很多人第一次接触时被难住。除了串口波特率系统日志的配置也有讲究。RK3568启动时U-Boot阶段、内核阶段、系统阶段的日志输出分别由不同的参数控制。如果调试串口上只能看到U-Boot输出但内核启动后就看不到日志了通常需要在U-Boot的环境变量里增加consolettyS2,1500000n8的内核启动参数。如果使用Buildroot构建根文件系统还可以通过修改/etc/inittab或者systemd的serial-getty服务来开启串口终端登录方便在无网络环境下临时调试。这个坑的处理非常简单分享出来的价值在于提醒大家拿到新的开发板后先花十分钟确认调试串口的波特率参数而不是盲目沿用旧习惯。硬件平台的差异有时候就在这种小细节。3. 实操过程与核心环节实现3.1 核心板选型实操清单基于前两个坑的经验我整理了一份核心板选型时可以直接对着检查的清单分享给大家。处理器与内存芯片型号确认明确选用RK3568J工业级还是RK3568商业级前者工作温度更宽内存类型优先LPDDR4X其次DDR4避免使用来路不明的颗粒内存容量根据实际业务选择网关做数据转发和轻量处理用2GB足够跑容器或者本地存储则需要4GB及以上eMMC容量建议选择16GB以上因为根文件系统、应用日志、容器镜像都会占用空间接口与扩展性确认核心板引出的接口是否满足底板设计需求包括UART、CAN、I2C、SPI、USB、PCIe、GMAC等确认接口电平是否兼容RK3568大部分IO是3.3V电平但有些引脚支持1.8V模式接错电平会烧毁IO确认核心板是否有引出PCIe接口如果后续要接5G模块或者AI加速卡PCIe通道是刚需电源与功耗确认核心板各路电压是否由核心板自管理还是需要底板提供多路电压确认核心板典型功耗和峰值功耗用于设计整机电源和散热确认供电电压范围工业现场常用24V DC输入需要确认核心板是否能适应宽压输入软件与工具链确认核心板厂商提供的SDK版本包含Uboot、Kernel、Buildroot的版本和补丁状态确认是否提供设备树源文件以及是否支持设备树覆盖功能确认是否有配套的烧录工具支持Windows和Linux双平台确认官方文档是否齐全包括硬件设计指南、软件编译指南、常见问题手册认证与可靠性确认核心板是否通过相关认证如CE、FCC、RoHS等确认核心板厂商是否提供长时间的持续供货承诺防止后期选型更换确认是否有老化测试报告和极端温度测试报告这份清单可以帮助你在选型会议上有据可依同时也是一份采购验收标准。3.2 设备树修改与内核编译设备树修改这一步我实际操作的命令和流程如下使用Linux主机作为编译环境。# 1. 获取SDK以瑞芯微官方SDK为例 # 从官方或核心板厂商获取SDK压缩包解压后进入目录 mkdir rk3568-sdk cd rk3568-sdk # 解压SDK包具体文件名以实际为准 tar xvf rk3568_linux_sdk_v1.2.0.tar.gz # 2. 进入内核源码目录查看设备树文件列表 cd kernel ls arch/arm64/boot/dts/rockchip/ | grep rk3568 # 3. 根据核心板型号复制一份设备树作为底板修改的起点 cp arch/arm64/boot/dts/rockchip/rk3568-evb.dts arch/arm64/boot/dts/rockchip/rk3568-my-gateway.dts # 4. 编译设备树检查语法 make ARCHarm64 rk3568-my-gateway.dtb # 5. 如果编译报error: feature system-pcre2 was enabled之类的错误检查编译工具链版本 # 这类问题通常是宿主机环境与SDK编译要求不匹配导致建议使用Docker环境编译 # 执行make前先确认交叉编译工具链已正确安装 export ARCHarm64 export CROSS_COMPILEaarch64-linux-gnu-在修改设备树时常用的操作是查找引脚复用节点。比如要把UART3的引脚改为UART功能uart3 { status okay; pinctrl-names default; pinctrl-0 uart3m1_xfer; };这里的uart3m1_xfer是预定义的引脚复用选项定义在rk3568-pinctrl.dtsi文件中可以查找确认该复用组具体映射到哪个物理引脚。如果涉及两个外设争用同一个引脚编译器会在生成DTB时给出警告或者直接报冲突。可以在dts中把不需要的外设节点status改为disabled来解除占用。编译完成后把生成的DTB打包进boot.img或者单独烧录到资源分区。单独烧录的方式# 进入SDK的rockdev目录 cd ../rockdev # 查看烧录配置 ls -l # 使用upgrade_tool或者瑞芯微开发工具烧录 # Windows下使用RKDevToolLinux下使用upgrade_tool sudo upgrade_tool di -b boot.img调试期间建议使用SD卡启动方式来验证设备树修改SD卡启动不会覆盖板载eMMC里的原系统方便我做A/B对比。3.3 网络配置实操记录网络配置这部分我们的实际配置过程和命令如下。第一步确认PHY芯片及驱动匹配在设备树里找到gmac1的节点确认phy-mode、phy-handle、复位GPIO等信息与底板原理图一致。gmac1 { status okay; phy-mode rgmii; clock_in_out input; snps,reset-gpio gpio4 RK_PB0 GPIO_ACTIVE_LOW; snps,reset-active-low; snps,reset-delays-us 0 50000 50000; pinctrl-names default; pinctrl-0 gmac1_rgmii_clk gmac1_rgmii_bus; };如果在启动日志里看到MAC挂载成功但PHY一直不工作优先检查复位GPIO和时钟模式。第二步配置网络接口网关的/etc/network/interfacesDebian系配置如下# WAN口连接上级网络 auto eth0 iface eth0 inet dhcp # LAN口固定IP作为内网设备网关 auto eth1 iface eth1 inet static address 192.168.2.1 netmask 255.255.255.0第三步开启NAT转发# 开启内核IP转发 echo 1 /proc/sys/net/ipv4/ip_forward # 配置iptables NAT规则将LAN口流量从WAN口出去 iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT # 保存规则 iptables-save /etc/iptables.rules为了让配置重启后依然生效可以把iptables规则写入启动脚本我这边是通过systemd服务来加载的[Unit] DescriptionLoad iptables rules Afternetwork.target [Service] Typeoneshot ExecStart/sbin/iptables-restore /etc/iptables.rules [Install] WantedBymulti-user.target经过这样调整之后内网设备可以正常通过网关访问外网设备与设备之间的通信也不会受到干扰。这里的关键点在于网关设备不是简单的数据转发工具它是一个具备路由决策能力的边界节点明确不同网络域的职责范围网络稳定性自然就上来了。3.4 网络故障排查命令速查在做网关网络调试时以下命令的使用频率很高整理成了一个速查表。排查目标命令预期结果与说明网络接口是否UPip link show接口状态显示UP且有MAC地址IP地址配置ip addr show eth0确认已分配到正确IP路由表ip route show确认有默认路由网关地址正确网关连通性ping -c 4 192.168.1.1能收到回复说明链路通交换机端口协商ethtool eth0Speed: 1000Mb/sDuplex: FullARP缓存ip neigh show网关IP对应正确的MAC地址端口连通性nc -zv 192.168.1.100 8080能连上说明TCP端口通DNS解析nslookup baidu.com能解析说明DNS正常抓包分析tcpdump -i eth0 host 192.168.1.100观察是否有双向数据流内核日志dmesg | grep -i eth查看网口驱动和PHY相关日志排查网口问题我个人的习惯是按物理链路 - 数据链路 - 网络层 - 传输层的顺序来从下往上逐层推进不要一上来就抓包那是最后一招。3.5 启动常见报错的应对方案RK3568系统启动阶段遇到比较典型的报错我记录了两个案例。第一个是裸金属上电后串口无输出。在确认硬件电源正常的前提下优先检查以下三个地方启动方式配置BOOT引脚的电平组合是否正确调试串口连接的是否为UART2_TX和UART2_RX对应引脚波特率是否设置为1500000如果你用的是核心板加自研底板还要检查核心板与底板之间的连接器是否有引脚虚焊或者错位。这个情况我遇到过一度怀疑是CPU虚焊最后发现是连接器排针有一段氧化导致接触不良。第二个是UBoot阶段报错reading logo失败。通常是因为烧录时logo分区为空或者参数分区中logo的位置配置不对。如果logo不是刚需可以跳过这个报错影响如果需要显示logo则需要用瑞芯微提供的工具把logo图片打包到resource分区。启动完成后要注意的是系统时间漂移问题。有些核心板没有RTC电池网关断电重启后系统时间会恢复到1970年如果云端日志和本地采集数据需要准确时间戳需要外接RTC模块并在系统中配置ntpdate同步时间。我在网关设计之初就预留了RTC的I2C接口位置后面加模块也很方便。4. 常见问题与排查技巧实录4.1 RK3568 调试OV5695摄像头相关问题虽然我们项目里用不到摄像头但社区里对RK3568调试OV5695的讨论热度很高这里也顺带总结一下常见问题。OV5695是500万像素的MIPI摄像头传感器在RK3568平台上调试时经常遇到的问题包括I2C通讯失败排查摄像头的供电是否正常复位和PWDN引脚是否被正确拉高/拉低I2C地址是否匹配MIPI信号不稳定检查设备树中MIPI DPHY的lane数配置、数据率配置是否与sensor输出一致画面偏色或花屏白平衡参数问题或者ISP参数配置错误SDK里有对应的调试工具可以调整帧率不达标检查MIPI时钟频率和sensor输出时序是否符合预期具体的调试路径一般为先确认I2C能正确读取sensor ID然后通过media控制器节点查看mipi通路是否建立最后使用v4l2-ctl采集单帧图像验证。4.2 设备树冲突问题实录前面的设备树坑已经详细说了这里再补充一个我在调试中遇到的样例。我们的网关底板上使用了CAN口和UART4查询RK3568的数据手册发现CAN1和UART4的部分引脚有复用冲突。核心板厂商提供的默认设备树使能了CAN1但没有使能UART4所以系统启动时没有任何错误只是我们无法访问UART4对应的设备节点。解决过程# 查看当前设备树中引脚的复用状态 cd /sys/kernel/debug/pinctrl/pinctrl-rockchip-pinctrl/ cat pinmux-pins # 找到与UART4相关的引脚确认当前的复用功能 # 然后修改设备树将CAN1节点状态改为disabledUART4节点状态改为okay vim ../kernel/arch/arm64/boot/dts/rockchip/rk3568-my-gateway.dts具体修改内容can1 { status disabled; }; uart4 { status okay; pinctrl-names default; pinctrl-0 uart4m0_xfer; };重新编译烧录后/dev/ttyS4节点正常出现UART4收发数据正常。这个问题的难点不在于修改本身而在于定位。看到设备不存在的第一反应往往以为是驱动没有编译进内核很少有人会立刻想到引脚复用冲突。所以排查外设问题时建议先看pinmux再查驱动顺序反了会多走很多弯路。4.3 内核启动后无法挂载rootfs问题用NFS挂载rootfs调试是嵌入式开发中的常见操作我踩过的一个坑是内核启动后无法挂载NFS根文件系统。当时使用的启动参数如下setenv bootargs consolettyS2,1500000n8 root/dev/nfs nfsroot192.168.1.100:/srv/nfs/rootfs,v3,tcp ipdhcp rw saveenv boot启动后卡在VFS: Unable to mount root fs via NFS。排查过程确认服务器NFS服务已开启systemctl status nfs-kernel-server确认开发板与服务器网络互通ping 192.168.1.100确认内核配置了NFS支持检查内核配置CONFIG_ROOT_NFSy确认NFS版本匹配服务器NFS导出版本可能只支持NFSv4而内核默认挂载的参数是v3我的问题就出在服务器NFS导出版本上把启动参数改为nfsvers4之后就正常了setenv bootargs consolettyS2,1500000n8 root/dev/nfs nfsroot192.168.1.100:/srv/nfs/rootfs,v4,tcp ipdhcp rw这类问题比较典型的排查思路是从启动日志逐步回退确认网络层通没通再确认NFS协议协商是否成功最后确认目录权限和路径是否正确。不要一上来就怀疑内核配置日志里会有信息的。5. 避坑清单与选型建议总结5.1 实用避坑清单速查表这篇文章的标题说了附实操清单到这里把前面所有要点整合成一张速查表方便大家选型和调试时对照。坑点检查项落地建议SKU和内存芯片是否工业级、内存颗粒来源优先LPDDR4X要求颗粒品牌可追溯电源与启动电源上电时序、DC-DC布局按照参考设计布局预留20%功耗裕量设备树匹配引脚复用是否与底板一致以核心板厂商配套设备树为基线逐一核对网络稳定性PHY配置正确性、NAT规则使用路由模式而非桥接模式开启iptables串口波特率U-Boot和内核参数确认1500000波特率两处参数保持一致NFS调试服务器NFS版本、网络连通先确认网络层再查NFS协议版本RTC时间是否有掉电保存时钟如果需要时间戳外接RTC模块并配置NTP同步5.2 基于实际经验的选择建议如果逐步完成了原文内容并返回上面这些坑可以说覆盖了RK3568网关方案从选型、硬件设计到软件适配的完整链路。如果说要在这篇文章里留下一些最重要的建议我会说这三条第一优先选择成熟的核心板方案不要从零设计核心板。RK3568的BGA封装和DDR布线不是普通团队能轻松搞定的核心板厂商已经验证过的方案可以直接覆盖大部分风险。如果你有很强的硬件设计能力自行设计核心板也一定要做足仿真和测试。第二拿到开发板后的第一周不要急着跑业务逻辑。先把设备树、启动方式、调试串口、网络互联这些基础环境全部验证一遍做好基线记录。后面的应用开发只有在稳定的基础环境中才有意义。第三不要迷信参考设计要建立自己的检查体系。参考设计是芯片原厂给出的通用方案它不会考虑你产品特有的散热、结构、接口组合等情况。基于参考设计结合自己的产品定义建立一份属于自己项目的检查清单每个环节出了问题都能快速定位。最后选型这件事的本质不是选一颗芯片而是选一整套解决方案和配套生态。RK3568确实是一颗很适合边缘计算网关场景的芯片但它能否在你的产品里发挥价值取决于你如何对待芯片之外的每一个细节。上面的经验来自实际项目里面每一个坑都花过时间和精力去填希望你能把它们提前绕过。