工业级SBC实战：Gateworks Venice i.MX8M Mini 上部署Ubuntu边缘网关

拿到这块 Gateworks Venice SBC 的时候，我第一反应不是跑评测，而是赶紧往里面刷 Ubuntu。板子核心是 NXP 的 i.MX8M Mini，四核 Cortex-A53 加一颗 Cortex-M4，在 22.04 LTS 下面跑起来很顺。我要把它做成边缘网关的验证平台，所以关注点不只是开机动画，而是这套组合在真实工程环境下能不能扛住长时间运行、掉电重启、容器部署这些日常操作。玩了一个多月，把过程完整梳理一遍，给同样在看这块板子的朋友一个参考。

1. 我为什么把手上的树莓派换成了 Gateworks Venice

1.1 树莓派做不了的活儿

先说清楚，树莓派不是不好，它把原型验证的门槛拉到了极低，这个功劳谁都比不了。但我手上的项目要部署在户外机柜里，要求工作温度范围更宽、供电链路更可靠、网络接口要两个千兆口做内外网隔离，而且需要明确的长周期供货承诺。这几个条件一摆出来，树莓派就有点吃力了。

户外机柜的夏天温度能到五十度以上，冬天又可能零下，普通 SD 卡加商业级板卡在这种环境下连续跑几个月，很容易出现启动失败或者外设失联。另一个痛点是 PoE 供电，虽然树莓派有 PoE HAT，但那等于额外加一层转接板，散热和可靠性都多了一个薄弱点。Gateworks Venice 这类工业级 SBC 把这些需求做成板载能力，省掉的不仅是外设，还有整个项目的结构复杂度和故障排查面。

1.2 Gateworks 的定位

Gateworks 是做工业级和军工级单板计算机的老牌厂商，之前主要是 Ventana 系列，用 NXP 的 i.MX6 和 i.MX8 平台，最近这代 Venice 系列换到了 i.MX8M 家族。它们家的特点有几个很明显的：板子生命周期长，不会像消费级开发板那样半年一换代；软件资料完整，U-Boot 和内核的改动都是开源的；另外就是板卡本身的设计目标就是长期在线运行，不是给人做桌面玩具。

Venice 系列给我的感觉，是面向系统集成商和做产品的团队，而不是学生和极客。它提供的不是一块"能刷系统的板子"，而是一个"能直接塞进产品里的核心模块"。板卡布局、连接器选型、电源设计、看门狗策略，处处都在为产品化做铺垫。这一点，等我自己把板子装进项目机箱的时候体会特别深。

1.3 选型时的横向对比

我在选型时对比了几个方案，包括树莓派 Compute Module 4、其他家的 i.MX8M 工业板卡，以及直接做核心板加底板的方案。这里把几个关键维度列出来：

这个表格不是要说谁赢谁输，而是看你的项目处在什么阶段。如果只是做概念验证，树莓派完全够用；如果要往产品方向走，尤其是环境苛刻、需要长期维护，那 Venice 这类工业板卡的价值就出来了。

2. i.MX8M Mini 处理器：这块板子的性能底座

2.1 四核 A53 加一颗 M4，这个组合有意思

i.MX8M Mini 是 NXP 在 2019 年推出的应用处理器，采用三星 14nm LPC FinFET 制程。里面最核心的计算单元是四个 Cortex-A53 内核，主频最高到 1.8GHz，支持 64 位指令集。A53 这个核心大家应该不陌生，它不像 A72/A76 那样追求极限性能，而是主打能效比，在嵌入式场景里，这个定位非常实用。

更妙的是它还有一颗独立的 Cortex-M4 内核，工作在 400MHz 左右。这颗 M4 和 A53 是异构关系，可以独立跑裸机程序或 RTOS，用来处理实时性要求高的任务，比如电机控制、协议时序、传感器采集。在跑 Ubuntu 的时候，M4 可以一直空着，也可以加载一个 M4 固件分担底层实时事务。我见过有人用 M4 做 PWM 输出和编码器读取，A53 上跑应用和网络服务，两边互不干扰，这种异构设计比外挂一颗 MCU 更省成本和空间。

对于 Ubuntu 来说，四核 A53 加 1~4GB 内存的配置不算豪华，但做网关、边缘计算、数据采集、Web 服务这些典型负载是合适的。A53 的 64 位支持意味着可以跑标准的 arm64 软件包，不需要像 32 位平台那样到处找老版本依赖。

2.2 内存、存储与外部接口的搭配

i.MX8M Mini 支持 LPDDR4 和 DDR4 内存，单通道，典型容量从 1GB 到 4GB 都有。Gateworks 的 Venice 板卡通常配置板载 LPDDR4，容量按型号不同从 1GB 到 4GB 可选。如果你打算跑 Ubuntu 桌面版，建议至少 2GB；如果只是跑 Ubuntu Server 加容器，1GB 也能转，但 2GB 以上会从容很多。

存储方面，处理器支持 eMMC 5.1、SD 卡、SPI NOR，Gateworks 板载了 eMMC 和一个 SPI NOR Flash。eMMC 是主存储，用于放 Ubuntu；SPI NOR 放 U-Boot 环境和一些关键配置。另外还有 SD 卡座，既可以从 SD 卡启动，也可以用来做系统备份和恢复。

接口部分，i.MX8M Mini 自带两个千兆以太网 MAC、USB 2.0、PCIe Gen 2 单通道、CAN FD、多个 UART/I2C/SPI、SAI 音频、MIPI-CSI 和 MIPI-DSI，显示方面有 HDMI 输出。这些接口在 Venice 板卡上基本上都引出来了，做网关、工控、边缘盒子都比较顺手。

2.3 用数据说话：与同门师兄和树莓派 4 的对比

单看 CPU 跑分，树莓派 4 的 A72 内核肯定更强，但威尼斯这块板子选 i.MX8M Mini 本来就不是为了跑分。它的价值在于工业属性、双网口、CAN FD、丰富的 UART/GPIO、以及 NXP 的长期供货承诺。i.MX8M Plus 则是带 NPU 的版本，适合在板端做简单 AI 推理；如果我的项目需要做视觉检测，我会考虑升级到 Plus 版本，但纯网关场景 Mini 已经够了。

3. 开箱与硬件细节：Venice 板卡到底长什么样

3.1 板卡布局和接口盘点

Gateworks Venice 板卡拿到手，第一感觉是紧凑，布局非常规整。板卡采用类似 Pico-ITX 的紧凑尺寸，适合直接固定到机箱内部。正面主要分为几个功能区：核心处理器和内存居中，网络变压器和 RJ45 座在板边，扩展接口像 M.2、mPCIe、SIM 卡座分布在四周，方便走线。

接口方面，两个千兆 RJ45 网口是标配，这对网关类应用是硬需求——一个口接外网，一个口接内网，中间做防火墙或数据转发。USB 是 USB 2.0 接口，数量不算多，但对嵌入式设备也够用了，我在上面接了一个 4G 模块和一个加密狗，都工作正常。板载 M.2 和 mPCIe 插槽是亮点，M.2 可以插 WiFi 模块或者 NVMe 转接卡（取决于具体型号走的是 PCIe 还是 USB 协议），mPCIe 可以接 LTE 模块、CAN 卡、或者 FPGA 板。SIM 卡座和 mPCIe 组合起来，直接就是一台工业路由器。

工业控制常用的 GPIO 排针也引出了很多路，包括 UART、I2C、SPI、GPIO、ADC、PWM。我接了一个环境传感器到 I2C 上，改设备树打开对应节点，读数据非常稳定。对于做物联网网关的人来说，这种"开箱即用"的扩展性比攒一堆 USB 转接棒靠谱得多。

3.2 供电设计：宽压输入与 PoE

供电是工业 SBC 和消费板卡差距最明显的地方。Venice 板卡支持宽压直流输入，我手头这块标称是 8V 到 30V 都可以，意味着可以直接接工业现场的 24V 电源导轨，不需要额外的降压模块。板上有防反接设计和过流保护，电源极性接反了或者瞬时浪涌，板子不会损坏。这一点在实际项目里非常重要，因为现场调试的人不一定每次都那么细心。

PoE 供电也是可选功能，符合 IEEE 802.3at 标准，也就是 PoE+，最大供电功率约 25W。用 PoE 的好处是一根网线同时搞定数据和电力，在有 PoE 交换机的地方部署设备，省掉了电源布线。我在实验室测过，把板子的 DC 电源拔掉，只用 PoE 供电，系统无感切换，功耗大概在 8W 到 12W 之间，取决于负载和温度。这种特性让设备在弱电间、天花板、户外杆塔上部署都方便很多。

3.3 工业级设计的几个细节

简单列几个我比较欣赏的细节：

• 宽温工作：整板设计覆盖 -40℃ 到 +85℃ 温度范围，不同型号可能略有差异。这意味着可以安心放进户外机柜，只要机柜本身有基本的遮阳和通风就行。
• 看门狗：板载硬件看门狗，可以通过软件控制喂狗。系统一旦卡死，看门狗会自动复位，这是长时间在线运行的关键保障。我后面专门测试过这个功能，确实能在内核卡死几秒后自动重启。
• TPM 2.0：板载可信平台模块，BitLocker、密钥存储、安全启动都用得上。做产品的话，有 TPM 等于给安全功能打好了地基。
• 连接器锁定：网口、USB、电源连接器都是工业级选型，配合锁扣设计，震动环境下不容易松脱。

这些细节单看一个可能感觉不到什么，但合在一起，就是"工业级"三个字的分量。它在硬件层面已经替你想好了长期运行会遇到的问题。

4. Ubuntu 系统部署：从镜像到跑起来

4.1 版本选择：为什么我选了 Ubuntu 22.04 LTS

Gateworks 官方提供多种系统支持，Ubuntu 是其中一个主推选项。我在选择时直接锁定了 Ubuntu 22.04 LTS，原因有三点。

第一，LTS 版本有五年安全更新，这对嵌入式产品的维护周期非常友好。你总不希望部署完设备之后，系统停下来不管，或者为了升级系统被迫重新适配整个软件栈。第二，22.04 自带内核 5.15，对 i.MX8M Mini 的上游支持已经很完善了——设备树、驱动、时钟、GPIO、以太网这些基础模块在主线内核中都有良好的覆盖，不需要像早期 i.MX 平台那样到处找 NXP 的 BSP 补丁。第三，软件生态成熟，Docker、Python、Node.js、GCC 这些常见工具链在 Ubuntu 22.04 的 ARM64 软件源里都维护得很好。

我也考虑过 Ubuntu 24.04，新的内核和工具链确实吸引人，但作为产品化项目，我更倾向于选择生态验证时间更久的 LTS 版本。等到下一批产品迭代，再评估是否升级也不迟。

4.2 把系统写进板卡

Gateworks 的 Venice 板卡支持从 SD 卡、eMMC、SPI NOR 等多个介质启动。我的烧录思路是：先用一张 SD 卡做一个临时启动盘，把系统装进板载 eMMC，之后日常运行直接从 eMMC 启动。

具体流程是：

1. 从 Gateworks 官方资源页面下载 Ubuntu 22.04 的镜像，官方提供的是已经针对 Venice 板卡配置好的 Ubuntu Server 镜像。
2. 用写卡工具把镜像写入 SD 卡。在 Ubuntu 桌面上我用的是 balenaEtcher，在命令行下也可以用 dd 直接写。
3. 设置板卡启动开关，让 U-Boot 优先从 SD 卡启动。Venice 板卡上有启动模式拨码开关，拨到对应位置即可。
4. 插入 SD 卡，接好串口线和电源，开机。通过串口终端可以观察到 U-Boot 的启动日志，U-Boot 会自动检测 SD 卡里的启动分区，加载内核和根文件系统。

这里有个小细节：第一次从 SD 卡启动之后，系统会把整个 eMMC 初始化为空白的可写存储，之后你可以选择直接把当前 SD 卡里的系统克隆到 eMMC，或者通过 U-Boot 的网络功能引导网络安装。我采用的是镜像内自带的安装脚本，它能自动完成分区、格式化、文件复制和 U-Boot 环境更新，非常省事。

4.3 第一次开机与基础配置

系统启动进入 Ubuntu 后，默认是命令行界面。第一次登录用的是串口终端，root 权限配置在镜像文档里写得清楚，默认创建了一个带 sudo 权限的用户。建议登录后立刻做几件事：

• 修改密码，并且确认 SSH 服务已启动，这样后续就可以通过网络远程操作，不用一直挂着串口线。
• 查看系统架构信息：

uname -a # Linux gw7300 5.15.0-x-gateworks #1 SMP PREEMPT aarch64 GNU/Linux dpkg --print-architecture # arm64

看到 aarch64 和 arm64 就放心了，整个 ARM64 软件生态都是通的。

• 检查分区和磁盘空间：

lsblk df -h

eMMC 一般不需要额外扩展，但如果你用 SD 卡启动，系统镜像默认只占用了 SD 卡一部分空间，需要用growpart和resize2fs扩展根文件系统。

4.4 安装 Docker 和核心开发环境

Ubuntu 22.04 上安装 Docker 很简单，可以直接用官方脚本，或者从软件源安装。我习惯用 docker.io 的发行版包，稳定且省事：

sudo apt update sudo apt install -y docker.io docker-compose-v2 sudo systemctl enable --now docker

装好之后我跑了一个测试容器：

docker run --rm hello-world

看到 Hello from Docker 输出的时候，说明这套板子的 Linux 内核和容器运行时完全正常。

之后我按项目需要装了 Docker Compose、Python 3、pip、GCC、CMake、Git、Node.js 这些常规工具。整个过程和标准 Ubuntu 服务器没有任何区别，APIs 都能用。如果网络环境访问官方源慢，可以先把/etc/apt/sources.list换成就近的镜像源，这一步对海外板卡在国内网络环境下尤其重要，换完源之后apt update的速度会快很多。

5. 跑起来之后：Ubuntu 在这块板子上的真实表现

5.1 系统资源占用和温度表现

系统刚跑起来，我先用htop看了一下基础资源占用。Ubuntu 22.04 的干净 Server 系统，idle 状态下四核 A53 的负载基本在 0.1 上下，内存占用约 300 到 400MB，剩下的内存都可以给应用用。如果是 2GB 内存版本，跑一个 PostgreSQL、一个 Nginx、加三四个 Python 服务，内存还有富余；如果还要跑 IDA 或者大型 Java 应用，建议选 4GB 版本。

温度方面，我用板载的温度传感器监控 CPU 温度。室温 25℃ 左右，idle 时 CPU 温度在 45℃ 上下，满载编译时能到 70℃ 左右。我加了一个小散热片在处理器上，满载温度能压到 65℃ 附近。整体热表现比我预想的要好，A53 核心的功耗控制确实有一手，运行几个容器加网络转发，整个板卡功耗在 8W 到 10W 之间波动。

5.2 编译、IO 和网络性能实测

为了直观感受 CPU 性能，我做了几个测试。

编译测试，我在板子上编译了 mbedtls 这个加密库，四核并发：

make -j4

整个编译大概用时 1 分 20 秒。同样的代码在我笔记本的 x86 处理器上只要十几秒，但在 1.8GHz 的 A53 上，这个表现符合预期。它对标的是"能不能编译"，而不是"编译有多快"。日常开发的思路是把编译放在 PC 或者 CI 服务器上，板子只跑编译好的产物。

磁盘 IO 方面，eMMC 的实测顺序读取约 280MB/s，写入约 180MB/s，这个性能对系统盘和容器存储来说完全够用。网络方面，两个千兆口实测 iperf3 吞吐都能跑到 940Mbps 左右，接近线速，说明驱动和内核网络栈工作正常，没有明显的性能瓶颈。

5.3 稳定性和掉电测试

我做了几项稳定性验证：

• 连续运行测试：板子带着 Docker 容器跑了一个工作日，期间包括频繁的日志写入、网络请求、数据库操作，系统资源使用稳定，没有出现内存泄漏或者进程崩溃的情况。
• 掉电重启测试：直接在运行状态下断电，再重新上电，U-Boot 启动、内核引导、根文件系统挂载、服务自启，整个流程干净利落，没有出现文件系统损坏。这主要得益于 eMMC 和文件系统的掉电保护机制。
• 硬件看门狗测试：手动停掉喂狗进程，大概 8 秒后板子自动重启，和预期一致。

这些测试做完，我对整个平台在真实环境中的可靠性心里有了底。

6. 把开发板变成产品时，我踩过的那些坑

6.1 Ubuntu 换源与网络配置

第一个绕不过去的坑就是 apt 源。有朋友在虚拟机里装 Ubuntu 习惯了默认源，放到这块板子上发现apt update特别慢。原因很简单，默认软件源的位置离你远，网络延迟高。解决方法是把/etc/apt/sources.list和/etc/apt/sources.list.d/ubuntu.sources里的地址替换成距离近的镜像源。

注意一点，ARM 架构用的是 Ubuntu Ports 源，不是 x86 的普通源。替换时千万别搞混，否则会报错。镜像源里通常都有明确区分 amd64、arm64、armhf 的路径。

网络配置方面，Ubuntu 22.04 用的是 netplan。默认是 DHCP，如果要做产品，最好给设备一个固定 IP：

network: version: 2 ethernets: eth0: dhcp4: no addresses: - 192.168.1.100/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: - 192.168.1.1

保存后执行sudo netplan apply立即生效。

6.2 内核与设备树定制

Ubuntu 的内核是通用的发行版内核，它会包含很多驱动和设备树。但如果你要用到板子上某个特定外设，或者改一个针脚的复用关系，就需要自己去调整设备树。

Gateworks 在这方面的支持非常先进，他们把外部设备配置放到了 U-Boot 环境变量里，有些型号支持通过 U-Boot 命令直接修改设备树，不需要重新编译内核。但我还是建议你花时间学一下设备树的基础知识，因为最终你要面对的可能是自己的载板、自己的传感器、自己的接口映射。

如果要编译自己的内核，流程也清晰：从官方仓库拉内核源码和配置文件，修改配置，编译成 deb 包，然后在目标板子上安装。整个过程在 Ubuntu 上做一次之后，后面就轻车熟路了。

6.3 eMMC 耐用性优化

eMMC 的寿命和 SD 卡不一样，但也不是无限写的。长期运行的系统，日志和数据写入如果持续不断，eMMC 还是有损耗风险的。我用几个方法降低写放大：

• 把日志放到内存盘上，用 tmpfs 挂载/var/log，日志定期存到远端或者放弃持久化。
• 减少关键数据的日志级别，不要什么都往磁盘写。
• 数据库落盘目录放在独立分区，并合理设置写入频率和合并策略。
• 定期检查 eMMC 的健康状态，使用mmc-utils工具查看 eMMC 的 life time 估算值。

这些操作不需要改内核，都是用户态配置，但对 eMMC 的寿命影响很大。

6.4 几条真正好用的产品化技巧

最后几条经验，是我在项目推进过程中觉得最有用的：

• 串口控制台保留：不管系统做成什么样，把 U-Boot 和内核的串口日志引到一个调试口上，出问题的时候能救命。
• 做好 eMMC 全盘备份：用dd把 eMMC 整个镜像备份到 SSD 上，一旦系统被搞坏，可以快速恢复，不需要重新烧系统再调配置。
• 远程升级要有断电保护：做 OTA 的时候，一定要先写一个备用内核和根文件系统分区，升级失败还能回滚，否则远程设备一旦断电卡死在升级过程中，就只能去现场处理了。
• 定期监控看门狗：把看门狗当成系统监控的一部分，不只是防止死机，还可以结合健康检查，比如某个关键服务没响应时自动重启系统。

我实际用下来，最深刻的体会是：在 x86 虚拟机上玩 Ubuntu 和在一颗嵌入式 SoC 上跑生产系统，完全是两码事。前者是练手，后者是把每一个细节都打磨到可以无人值守运行的系统工程。Gateworks Venice 加 i.MX8M Mini 加 Ubuntu 这个组合，难的不是让它跑起来，而是让它稳定地、可维护地在现场跑上几年。如果你也要走这条路，希望上面这些经历能帮你少走几个弯路。