企业官网建设流程全解析

老读者可能还有印象，96Boards 这几年在开发板圈子里一直挺有存在感，尤其是 Consumer Edition 和 Enterprise Edition 那两条产品线，把 ARM 开发板从“各家各玩各的”往“标准化”方向推了一大步。但嵌入式产品开发真正需要的往往不是一块板子，而是一个能直接集成进自己 PCB 的核心计算模块——也就是 SOM（System on Module，核心板/系统级模块）。Linaro 这次发布的两份 96Boards SOM 规范，补上的正是这么一块拼图，把“平台标准化”从开发板延伸到了产品级核心模块。

这篇文章我会先拆解这两份规范的设计思路和具体规格，再结合我自己用 96Boards 系列模块做产品原型时积累的交叉编译经验，把从工具链选择到系统构建、再到载板设计避坑的完整链路讲清楚。无论你是正准备用 ARM 模块做边缘计算产品，还是纯粹想研究 SOM 方案的选型逻辑，这篇都能给你一个比较完整的参考。我尽量不写那种“官方新闻稿翻译腔”，而是用实际开发中会遇到的问题当主线来聊。

1. 先聊清楚：Linaro 为什么这时候推 SOM 规范，到底解决了什么痛点

开发板市场的成熟度其实很高了，树莓派、各种派，很多人拿来做原型验证非常顺手。但真到了量产阶段，你会发现开发板的形态根本不适合放在产品里——接口位置不对、高度超标、功耗预算对不上、供货周期不保证。更烦人的是，每一家厂商的底板设计都不一样，今天选这家明天换那家，载板基本推倒重来。

SOM 的思路就是把这个矛盾从根上解决：把 CPU、内存、存储、电源管理这些“高难度、高价值”的部分做成一个小模块，通过标准高密度连接器插到你自己的载板上，相当于一台电脑的“主机”和“外设/主板”分离。做产品的人只需要关心自己的载板设计，计算性能、内存颗粒、DDR 走线这些头疼的东西全交给模块厂商去解决。这跟很多人装修房子时的逻辑一样：厨房卫生间这种高风险的硬装部分包给专业团队，自己只需要处理软装和柜子布局。

96Boards SOM 规范的意义在于，它把这个“主机/主板分离”的玩法标准化了。过去的 SOM 市场基本是私有接口，每家的引脚定义、机械尺寸、供电时序都不同，换供应商等于重新设计一轮载板。96Boards SOM 规范定义了统一的机械尺寸、板对板连接器引脚排布、电源时序、启动流程和软件接口，意味着同一张载板理论上可以兼容多个厂商的 SOM 模块，这对供应链安全和成本控制的价值太大了。

Linaro 之所以有资格做这件事，是因为它背后有大量 ARM 生态成员，同时长期维护着 ARM 平台最常用的开源工具链和内核版本。规范推出不是终点，软件生态能不能跟上才是关键。我个人理解，这两份 SOM 规范真正要回答的问题是：怎么让“做硬件的人少画几层板，做软件的人少改几行驱动”，同时让整个行业的供应链从这个标准中获益。

2. 两款 SOM 规范的核心定义：Compute Edition 和 I/O Edition 分别解决什么场景

这次发布实际是两条产品线两条路，分别面向两个很不一样的需求场景，不能混在一起看。我下面逐个拆。

2.1 96Boards SOM Compute Edition：为边缘智能与高密度计算服务

Compute Edition 的逻辑很清晰：把高性能、高集成度放在首位。这个版本面向的是边缘计算网关、AI 推理盒、轻量级服务器以及医疗/工业 HMI 这类场景。规格设计上，它的核心思路是采用高密度板对板连接器，把 DDR 内存走线、高速 PCIe 通道、USB 3.0、千兆以太网、显示输出等统统纳入标准引脚定义。

尺寸方面，这类模块通常会控制在类似 40mm × 60mm 的紧凑尺寸内，具体以厂商实现为准，但机械规格会被规范锁定在某个标准区域内，保证不同厂商的模块能在同一套载板上互换。这种尺寸选型的考虑是：边缘计算盒子的内部空间往往寸土寸金，不像开发板那样摆得开。

接口定义上，有几点值得注意。Compute Edition 往往会预留至少一路 PCIe 3.0 x4，这直接决定了你能不能外接独立的 AI 加速卡、NVMe SSD 或高性能采集卡。显示器输出方面保留至少一个标准 HDMI 或 DP 接口。而 I/O 扩展的 GPIO 反而不是它的重点，因为要追求接口速率和信号完整性，必然会牺牲一部分通用 IO。

电源设计上，这类模块通常由载板提供单一直流电源（比如 5V 或 12V），模块自身完成多路 DC-DC 转换。你别小看这个细节，它意味着模块厂商已经帮你在模块内部处理好了电源上电时序，载板设计者不需要再操心 PMIC 的配置和时序关系。这对硬件工程师来说省了很多事，也大幅降低了新用户的上手门槛。

2.2 96Boards SOM I/O Edition：面向工业互联与丰富外设扩展

另一条产品线是 I/O Edition，看名字就知道了，重点在输入输出外设上。这个版本面向工业控制、智能终端、仪器仪表、传感器采集这类需要接大量外设的场景。

和 Compute Edition 的高速率通道不同，I/O Edition 强调的是一堆“传统但极其有用”的接口：多路 UART、CAN 总线、PWM、ADC、各类通用的 GPIO，再加上对 Modbus、RS-485 这类工业总线友好的电气特性定义。它可能在处理器规格上比 Compute Edition 低一些，但外设扩展能力上毫不吝啬。

I/O Edition 的载板设计自由度更大，因为它对信号速率的要求没有计算级那么苛刻，Layout 容错率更高。刚入门做产品的人如果手头没有高速 PCB 设计经验，从 I/O Edition 入手会友好很多。

不过要提醒一句：I/O 类的接口标准差别很大，电平、速率、上拉电阻、隔离方式都可能不同，规范定义的是“模块和载板之间的信号接口”，载板上怎么对这些信号做防护和转换，还是需要你自己根据最终使用场景设计。这块后续我在载板设计章节会详细说。

2.3 两条规格线的关键差异对比

表格只是快速给个画像，实际选型时肯定要看具体 SoC 的能力边界。如果你的应用既要算力又需要大量外设，那就需要在载板层面做取舍，或者用扩展芯片把接口补足。

3. 拿到 SOM 之后怎么跑起来：交叉编译工具链与系统构建实战

硬件规范讲多了容易飘，回到开发本身，落地性才是关键。做 SOM 开发和直接用开发板最大的区别是：你通常不会把屏幕键盘直接怼到模块上，而是要自己搭建交叉编译环境，在 PC 上编译出目标模块能运行的固件和系统。这中间最基础也最容易踩坑的就是工具链选型。

3.1 工具链选型：Linaro GCC 7.5 为什么是安全牌

说到 ARM 交叉编译工具链，很多老手第一反应是arm-linux-gnueabihf-gcc这类前缀，或者直接用 ARM 官方提供的 GNU-A 系列工具链。但国内开发者接触比较多的其实是 Linaro 维护的 GCC 工具链。Linaro 有一个长期维护的 release 体系，比如我手头常用的就是gcc-linaro-7.5-2019.12-x86_64_arm-linux-gnueabi这套。

为什么 7.5 这个老版本反而成了很多项目的安全牌？一个是稳定，7.5 是 GCC 7 系列的最后一个 release，没有大版本过渡期的毛病。另一个是兼容性和社区积累，很多 BSP（Board Support Package）和 SDK 默认的测试矩阵里就有它，不至于出现编译出来的程序在板子上运行行为异常这种玄学问题。

实际使用中，下载解压后把工具链的bin目录加入PATH：

wget https://releases.linaro.org/components/toolchain/binaries/7.5-2019.12/arm-linux-gnueabi/gcc-linaro-7.5-2019.12-x86_64_arm-linux-gnueabi.tar.xz tar -xf gcc-linaro-7.5-2019.12-x86_64_arm-linux-gnueabi.tar.xz export PATH=$PWD/gcc-linaro-7.5-2019.12-x86_64_arm-linux-gnueabi/bin:$PATH arm-linux-gnueabi-gcc --version

注意版本前缀的选择。如果你的目标模块是 32 位 ARMv7 架构，arm-linux-gnueabihf是常见选择，hf代表硬浮点。如果你的模块是 64 位 ARMv8 架构（现在 96Boards SOM 基本都至少是 ARMv8 起步了），那就要用aarch64-linux-gnu前缀的工具链。很多新人在这一步栽跟头：拿 32 位工具链去编 64 位系统，结果就是各种cannot find crt1.o之类的报错。

3.2 U-Boot 与内核编译的完整流程示例

拿到一个 SOM 模块，第一件事是让它的 Bootloader 和系统能顺利跑起来。96Boards 平台的软件栈基本是标准 Linux 社区流：U-Boot 作为引导程序，内核采用 mainline 或 SoC 厂商提供的 LTS 分支，根文件系统可以用 buildroot、Yocto 或者直接 Debian/Ubuntu rootfs。

U-Boot 的编译流程比较固定：

git clone https://gitlab.denx.de/u-boot/u-boot.git cd u-boot export CROSS_COMPILE=aarch64-linux-gnu- make <your_som_defconfig> make -j8

编出来的u-boot.bin是二进制镜像，具体烧录位置和格式要看模块的启动方式。有些模块是先把 U-Boot 烧到板载 SPI Flash，有些是从 SD 卡或 eMMC 上加载。96Boards SOM 规范对启动介质做了一些统一，但不同厂商实现上还是有差异，必须先看模块对应的硬件手册。

内核编译则需要注意设备树（Device Tree）部分。Linux 内核的 ARM64 设备树文件位于arch/arm64/boot/dts/下，每个 96Boards 模块批量出货后都会把 dts 合并到 mainline 或厂商内核。编译流程：

git clone https://github.com/torvalds/linux.git cd linux make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- <som_defconfig> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8 Image dtbs

重点说下设备树，这是嵌入式需求差异最大的地方。你的载板上接了什么传感器、什么串口设备、什么外设扩展芯片，都需要在设备树里描述给内核。很多新手把设备树当成配置文件随便改，结果设备起不来或者中断冲突。实际上设备树描述的是硬件拓扑和资源分配，必须对应实际接线。比如你的载板通过 I2C0 接了某个温湿度传感器，在 dts 里要写清楚哪个 I2C 总线、什么地址、什么中断引脚，内核才能正确加载驱动。

3.3 根文件系统搭建和启动方式

内核编好只解决了一半问题，还得有根文件系统。最快的路径是直接从 Debian/Ubuntu 的 ARM64 rootfs 解压做基础：

sudo debootstrap --arch=arm64 buster ./rootfs http://deb.debian.org/debian

如果你不喜欢手动折腾，buildroot 是更工程化的选择。它能把交叉编译工具链、Bootloader、内核、rootfs 全串起来，一条命令出完整固件。我第一次用 buildroot 编完整个系统后最直观的感受是：终于不用手动去对齐 glibc 版本和内核模块版本了。Yocto 的定制性更强，但学习曲线格外陡峭，个人项目我一般不会直接上 Yocto。

启动方式上，开发阶段用 TFTP 网络启动最方便，改完内核不用反复烧写，直接在 U-Boot 里设置serverip和bootargs，通过网络加载 Image 和 dtb。到产品化阶段再改成从 eMMC 引导，通过 U-Boot 的mmc write或直接在 Linux 下dd烧写镜像。

4. 载板设计才是真正考验：高速信号、电源与接口保护的要点

SOM 把最难的部分模块化了，但这不意味着载板设计可以随便来。我见过不少团队在“既然用了 SOM，载板应该很简单吧”的念头下栽跟头。载板才是体现产品差异化的地方，也是最容易因为小失误导致整体不稳定的地方。

4.1 电源设计与去耦

96Boards SOM 规范一般会明确载板输入电源的电压范围。就算模块内 PMIC 做得很完备，载板端的 PCB 供电也要认真设计。很多 SOM 负载突变时容易重启，原因常常不是模块本身不行，而是载板供电链路太细、电容太小，大电流瞬间压降超过模块输入范围。

实际做板时，建议模块的电源输入靠近连接器处放足够容量的去耦电容，典型配置是 10uF 和 100nF 配合，电源走线宽度要按模块最大电流计算，通常在 2A 左右需要至少 1mm 以上的走线宽度，同时保持参考地平面完整。

4.2 高速信号布线注意事项

Compute Edition 模块上有 PCIe、USB、HDMI 这类高速信号。这些信号从模块连接器出来到你的接口端子，走线要尽量短、少打过孔，最好有完整的地参考平面。同组的差分信号要做等长处理，比如 USB 3.0 的 TX/RX 差分对内等长控制在 5mil 以内，组间等长控制在 50mil 以内。这些要求对普通工程师来说需要一些高频板设计经验。

如果对高速布线没把握，可以考虑两种策略：一是把高速接口全部用连接器转接到板边口，不延伸太远；二是直接选用带高速连接器的标准化载板参考设计，在这个基础上修改，而不是从零画。

4.3 工业场景的接口保护

说回 I/O Edition，前面提到接口丰富既是优点也是风险。工业现场的静电、浪涌、共模干扰对无防护的外设接口是致命的。RS-485 总线建议加 TVS 管和共模电感，CAN 接口要有专用的 CAN 收发器并预留终端电阻位置，GPIO 输入需要做上拉/下拉和 RC 滤波。

这些保护电路虽小，但直接决定了产品在现场能不能活过一年。SOM 标准能保证模块本身皮实，可外设防护的“最后一公里”永远是载板设计者的责任。

5. 常见问题与排查技巧实录：我在实际开发中踩过的坑

嵌入式开发除了理论正确，更多的是现场排错能力。这里整理几个真实遇到过的典型问题，给大家做个速查参考。

5.1 常见问题速查表

5.2 两个典型的排查案例

第一个案例是年初做的一台工业网关。上电后模块总是无规律重启，开始时怀疑是内核问题，但 U-Boot 阶段也会重启，这就把问题锁定在硬件和电源。用示波器抓载板 12V 输入轨，发现负载变化时电压会瞬间跌到 8V 以下，低于模块最大允许范围。排查后发现稳压器输出电容容量不足，输入走线也偏细。换用更低 ESR 的电容并联并加粗走线后，问题消失。这个案例的教训是：预研阶段低功耗不代表满负载稳定，任何模块的供电设计都该按最大功耗留出余量。

第二个案例和 GPIO 冲突有关。客户反映 I/O Edition 模块的某一路 GPIO 时而有效时而失效，我远程登录到设备上查看时发现该引脚在启动阶段被一个spi设备驱动占用了，而这个 SPI 总线在载板上根本没接设备，纯粹是 Pinmux 配置错误。修改设备树把该节点的status改为disabled，GPIO 恢复正常。嵌入式里同类问题非常多，设备树里面的默认配置往往是为了模块自身的功能服务的，你必须按照实际载板设计裁剪，而不是照搬。

6. 应用场景与选型建议：先知道自己要什么，再谈硬件

SOM 规范发布了，市面上支持的模块会有更多选择，但选型时不能只看算力。我自己做选型时会按下面这个顺序过一遍：

先确认硬件形态和尺寸限制。产品外壳空间是方是圆，模块加载板总高度有没有限制。然后是接口清单，把所有必须的接口拉出来，看看 Compute 和 I/O 哪条产品线能覆盖。接着是算力与功耗预算，边缘 AI 推理选 Compute Edition，但电池供电的设备就得认真衡量。软件生态最后看，模块有没有长期内核维护，BSP 是不是 mainline 友好，因为 commit 停更的模块会让人很焦虑。

从项目定位角度，我个人建议是：如果做的是产品预研，选 Compute Edition 看未来算力扩展；如果是做一个成熟、稳定的工业控制设备，I/O Edition 的外设覆盖面更实用。两种规范共存的生态其实给了开发者一个很好的缓冲，你可以先做一块兼容两种版本的载板，前期验证 I/O，后期升级算力，这和当年电脑主板上能插不同 CPU 是一样的思路。

关于供应链也有个细节值得留意，规范只能统一接口，不能统一货源。选模块厂商时除了看芯片供货周期，还要关注模块本身是否有第二个可替代来源。96Boards SOM 规范要解决的正是“载板不变、模块可换”的问题，但前提是你选的所有模块必须严格遵循同一份规范。建议选型时把模块拿到手先做一次“互换测试”，用同一张载板分别跑不同模块，验证固件和驱动的兼容性，提前暴露风险。

另外，散热设计不要寄希望于模块自己解决。边缘智能盒子一般功耗都不低，模块的热量最终要通过载板的地平面和散热孔导走，建议散热焊盘开孔阵列，通过模组底板或金属中框把热量传导出去。这部分在选型阶段就要和外壳设计并行规划，不然样机出来后才发现散热瓶颈，整个项目周期都会被拖累。

最后再分享一个我个人的小经验：每次拿到新的 SOM 模块，第一件事不是急着设计载板，而是把模块官方提供的参考载板原理图和 PCB 干干净净地看一遍。重点看它们怎么处理电源链路、每个高速接口的走线策略、连接器周围的机械结构。这些参考设计背后都是厂商工程师踩过的坑，比你从零开始画省太多时间。看懂了这些再看 96Boards 规范文档里的那条硬件设计指南，你的感觉会完全不一样——规范里的每一句话都有它对应的现实原因，而此时你已经站在那些坑的边上看清楚了。