企业官网建设流程全解析

我在帮客户做一款工业网关的时候，光载板就改了三版。原因很简单：第一版用的是A厂商的核心板，第二版想换B公司的模块，结果尺寸对不上、连接器座子对不上、引脚定义更是完全两套逻辑——本质上等于从头再画一次板。这个场景，凡是做过“核心板+底板”方案的硬件工程师应该都不陌生。

所以当看到Linaro把96Boards家族扩展到SOM（System on Module）规范时，我第一反应是：这终于把核心板碎片化的问题摆上台面了。Linaro一口气发布了两个规范：96Boards SOM Specification和96Boards SOM Entry Edition Specification，分别面向不同定位的产品。再加上社区里几乎天天有人问的Linaro交叉编译工具链（比如gcc 7.5-2019.12 arm-linux-gnueabi），整个从规范到落地的开发链路终于完整了。

这篇文章就围绕这两件事展开：第一，两个SOM规范在硬件层面到底定死了什么，为什么它值得做载板的人认真读一遍；第二，拿到SOM之后，开发工作流里最常用的Linaro工具链该怎么配置、怎么避坑。我会结合自己做载板设计和嵌入式BSP的经验，尽量把“为什么”也讲透，不只是给步骤。

1. 两个新规范到底解决了嵌入式开发的什么问题

1.1 SOM是什么，为什么之前一直各家各玩各的

SOM，简单说就是把一块嵌入式产品里“最难做”的部分——主控SoC、DDR内存、eMMC闪存、PMIC电源管理、网络PHY、甚至无线模组——全部集成到一块小板子上。用户拿到的是一块已经验证过的高速数字电路，不需要自己跑DDR布线、不用调PMIC上电时序。你要做的，只是设计一块“载板”，把电源送进去，把对外接口引出来。

这个模式的好处非常明显：DDR等高速信号的PCB设计门槛极高，把这块交给专业模块厂商，产品团队就能把精力集中在自己的业务接口上。问题也肉眼可见——每个模块厂商都有自己的SOM尺寸、连接器类型、引脚定义、电源域划分，换一家供应商，等于重新设计整块载板。我用过某几家主流SOM方案，有的用板对板连接器，有的用类似内存条的金手指插座，引脚定义更是千奇百怪。想跨厂商兼容？几乎不可能。

拿生活里的事情类比，SOM有点像是你买电脑时不买整套主机，而是选了一颗“准系统”级别的CPU模组。问题是每一家模组厂商的“CPU底座”、电源接线、开机按钮定义都不一样，你换一个牌子，整个机箱设计都得推翻。

1.2 96Boards为何在CE/EE之后补上SOM这一课

96Boards是Linaro从2015年开始推动的开发板规范体系，目的就是让不同厂商的ARM开发板在尺寸、接口、固件接口上保持一致。最早它管的是整块开发板，分Consumer Edition（消费级）和Enterprise Edition（企业级）两个方向，后来又加了IoT、AI等细分方向。

但整板规范和SOM规范解决的是两个层面的问题。整板规范面向的是“买一块开发板回来直接跑软件”的开发者；而SOM规范面向的是“我要用这颗SoC做自己的产品，但不想从零做核心板”的硬件团队。这两个需求差异很大，整板规范再成熟，也没法覆盖模块化产品的形态。

Linaro在CE/EE之后补上SOM这一课，逻辑上很顺：96Boards作为一套开放的ARM生态规范，已经建立了软件层的标准化（比如U-Boot、Linux内核、标准化调试串口），现在把硬件模块接口也标准化，就能让“同一张载板，可以插不同厂商的SOM”真正变成现实。这也是我理解中这两个新规范最核心的价值：它不是又定义了一块新的开发板，而是定义了一个可互换的模块硬件接口。

1.3 规范覆盖范围：从机械尺寸到电源管理的边界

拿到96Boards SOM规范之后，你会发现它不像很多厂商的私有SOM文档那样只给一个引脚图，而是把整个模块的物理和电气边界都做了约束。大体上覆盖这五个层面。

第一是机械尺寸与公差。SOM本身的长宽、板厚、连接器位置、安装孔位置都有明确图形，载板设计者拿到规范就能直接建封装，不用等模块实物。

第二是板对板连接器的选型。标准版和Entry版在连接器形态上有明显差异，这个下一节详细说。规范会把插座的封装、推荐焊盘、拔插高度都定下来。

第三是引脚信号分配。这是最花心思的部分。哪些引脚走PCIe、哪些走USB、哪些是GPIO、哪些是电源和地，全部规定死。而且不只是“这个脚是干什么的”，还包括信号分组、差分对位置、引脚间距等细节，目的是让不同厂商的SOM在同一个载板上电气兼容。

第四是电源域和上电时序。SOM上哪个电源轨由载板提供，哪个由模块内部PMIC产生，I/O域电平是1.8V还是3.3V，上电顺序要求是什么，规范里都有明确章节。

第五是调试与烧录接口。规范强制要求SOM上必须引出标准调试串口和烧录通道，并且规定了在载板上的推荐位置，这样调试工具和夹具可以通用。

一句话总结：这个规范试图在硬件层面也做出一套“API兼容”约定，让换成不同厂家的SOM，软件和载板都能大概率无缝衔接。具体细节建议以Linaro官网发布的规范PDF为准，我这里讲的是设计逻辑和落地经验。

2. 标准版与Entry版的分工：两张规范的核心差异

2.1 标准版：为高密度接口和高性能计算预留空间

96Boards SOM标准版，按我个人的理解，它的定位是面向性能敏感的边缘计算场景，比如工业边缘网关、AI推理盒子、医疗设备、机器人的主控制器。这类产品对外接口多、数据吞吐量大，需要把PCIe、USB 3.0、千兆以太网、DSI显示接口、CSI摄像头接口等高速信号完整引出来。

既然要承载高速信号，标准版SOM的引脚密度和连接器品质要求就高一些。载板设计时也要做好差分对等长、阻抗匹配、参考层连续等信号完整性功课。也就是说，这不是一个“随便拉线就能跑”的模块，它给你的是性能上限，同时也要求载板具备相应的设计水平。用标准版做产品，PCB至少四层起步，如果PCIe跑得比较激进，六层板也不稀奇。

我在画这类载板的时候有一个习惯：拿到规范先不画原理图，先把连接器周围的差分对和电源引脚从封装里导出来，检查一下走线扇出空间是否够。很多SOM连接器引脚密度很高，如果在原理图阶段没考虑扇出，到布局布线阶段会非常痛苦。

2.2 Entry版：用更低门槛换低成本载板设计

Entry Edition，从名字就能看出来，它是“入门版”。但这里说的入门不是性能入门，而是成本和设计难度入门。它的目标很明确：让那些不需要太多高速接口的物联网设备、简单HMI、数据采集终端，能用更低的代价使用SOM方案。

Entry版的载板设计门槛明显低一个档次，接口数量少，对信号完整性的要求更宽松，电源树更简单。很多情况下四层板甚至两层板就能搞定，这对成本敏感的量产项目来说吸引力很大。它的连接器方案也比标准版更偏向低成本、易插拔的形态，整块模组的成本也能压得更低。

选标准版还是Entry版，本质上是在回答一个问题：你的产品是真的需要那么多高速接口，还是只需要稳定的主控和有限的几种连接方式。我见过不少团队脑子一热选了标准版，结果产品上只用了串口和以太网，几十个高速引脚全部悬空，成本和设计复杂度却上去了，这是很典型的过度设计。

2.3 一张表看懂两类SOM的定位差别

当然，具体到引脚数量、电气参数这些细节，还是要以官方发布的规范文档为准。这里给的是一个选型框架，不是替代文档。

2.4 载板设计者最该先读哪几个章节

如果你真的有载板设计任务在手，我建议不要从头到尾把规范啃一遍，先重点读这四块。

第一，机械图和连接器封装。这是画封装、定板框的第一手依据，务必按文档给的尺寸建库，不要自己“优化”。

第二，引脚映射表和信号分组。把所有引脚按功能类别分组，确认哪些是默认保留、哪些是可以复用的。先查一遍有没有引脚冲突，再动原理图。

第三，电源时序和电平要求。确认载板需要供入哪些电源、电压多少、时序满足什么条件。SOM无法启动的故障里，电源时序问题占了相当大的比重。

第四，启动配置引脚。很多SOM靠一组BOOT配置引脚来决定从eMMC、SD卡还是SPI Flash启动。这些引脚通常有默认的上拉或下拉要求，载板如果没有按规范处理，模块可能上电后完全没有反应。

3. 规范之后的落地开发：从载板参考设计到交叉编译工具链

3.1 拿到规范先做什么：载板设计的切入顺序

很多人都以为SOM方案来了就能直接画图，其实正确顺序应该是先找参考设计，再动手。96Boards官网通常会提供兼容SOM厂商的参考载板原理图、PCB封装库和设计指南，这些都是花了很多钱验证过的，比自己从零看规范可靠得多。

我的做法是先下载参考载板的原理图PDF，对照规范里的引脚映射表过一遍。重点看三件事：电源树怎么搭、启动配置引脚怎么处理、调试串口引到哪个位置。这三件事确认清楚，载板的主框架就已经有七八成了。接下来再根据自己产品的实际需求，增删对外接口，这样比从空白页开始画要稳得多。

还有一件事容易被忽略：连接器的供货周期。SOM规范里规定的板对板连接器虽然有标准型号，但不同厂牌货期差别很大，建议原理图阶段就锁定具体型号并联系代理商确认库存。否则很可能板子画完了，连接器没货，项目干等一个月。

3.2 为什么开发者手里都离不开Linaro工具链

硬件规范看完，接下来就是软件。96Boards生态和Linaro的关系决定了，你在开发过程中大概率会遇到Linaro的交叉编译工具链。Linaro的GCC工具链不是简单的“从源码编译一遍”，而是针对ARM架构做了大量的稳定化补丁、性能优化和长期测试，很多96Boards板卡的BSP脚本、OpenEmbedded/Yocto构建环境默认都会引用Linaro工具链。

搜索热词里被反复提到的“linaro gcc 7.5-2019.12 arm-linux-gnueabi”，就是Linaro在2019年12月发布的一个工具链版本。GCC 7.5是GCC 7系列的最后一次更新，按嵌入式项目的保守习惯，这反而成了一种可靠性的代名词。很多老项目、老内核（比如Linux 4.14、4.19）配上这个工具链非常稳定，社区里的维护者也从没中断过对这一版本的使用反馈，所以直到现在都还有人在下载和使用。

对于刚接触的朋友，这里先把工具链前缀说清楚：

• arm-linux-gnueabi：32位ARM、软浮点ABI，兼容性最好，适合Cortex-A5、A7这类带不带VFP/NEON的处理器都能跑；
• arm-linux-gnueabihf：32位ARM、硬浮点ABI，性能更好，但要求SoC必须带硬件浮点单元，且整个系统都要用硬浮点编译；
• aarch64-linux-gnu：64位ARM，也就是ARMv8-A架构，对应A53、A72这些大核。

选择哪个前缀，取决于你的SOM用的是哪颗SoC、跑的是什么系统。一般来说，现代96Boards SOM大多是AArch64架构，直接用aarch64-linux-gnu；如果还在维护老产品，32位目标就选arm-linux-gnueabi或arm-linux-gnueabihf，但别混用。

3.3 手把手：下载并配置Linaro GCC 7.5-2019.12工具链

这里以x86_64主机上安装32位ARM软浮点工具链为例，完整走一遍。这个流程我在Ubuntu 18.04和20.04上都跑过，没有遇到额外问题。

mkdir -p ~/toolchains cd ~/toolchains # 下载 32 位 ARM 工具链 wget https://releases.linaro.org/components/toolchain/binaries/7.5-2019.12/arm-linux-gnueabi/gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabi.tar.xz # 解压 tar -xJf gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabi.tar.xz # 把工具链加入 PATH，建议写进 ~/.bashrc export PATH=$PATH:$HOME/toolchains/gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabi/bin # 验证 arm-linux-gnueabi-gcc --version

如果用的是64位ARM目标，把路径里的arm-linux-gnueabi换成aarch64-linux-gnu即可。注意Linaro官网的releases目录结构偶尔会调整，如果链接跳转，直接在releases.linaro.org首页找Components下Toolchain Binaries，选择对应版本和target就能看到。

配置好之后，写一个最简单的C程序验证。

#include <stdio.h> int main(void) { printf("hello 96boards SOM\n"); return 0; }

arm-linux-gnueabi-gcc -static -o hello hello.c file hello

如果file命令显示“ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked”，说明编译链已经通了。这里我特意加了-static，目的是让程序不依赖目标板上可能缺失的动态库，特别是刚开始做目标板调试时，静态编译能少踩很多glibc版本不匹配的坑。

3.4 内核、驱动模块和用户态程序的编译流程

SOM开发中，光编译Hello World是远远不够的。以Linux内核为例，完整流程是这样的。

# 先获取内核源码，假设已经解压到 linux 目录 cd linux # 设置交叉编译环境变量 export ARCH=arm export CROSS_COMPILE=arm-linux-gnueabi- # 生成默认配置，这里以 96Boards 常见配置为例 make defconfig # 编译内核 make -j$(nproc) zImage # 编译设备树 make -j$(nproc) dtbs # 编译驱动模块 make -j$(nproc) modules

这三步分别产出zImage内核镜像、dtb设备树文件和用于后续调试的.ko驱动模块。部署的时候，一般把zImage和dtb放到SD卡的boot分区，或者通过TFTP/NFS方式加载；驱动模块则用scp拷到目标板文件系统后insmod加载。

有一个细节容易踩坑：编译内核模块时，内核源码目录里的版本信息和符号表必须和目标板上运行的内核完全一致。如果你重新编译了内核并烧录，模块也必须在同一份源码目录里重新编译。否则insmod会报“version magic”不匹配，或者“unknown symbol”错误。这个问题跟工具链版本关系不大，但团队协作时经常有人用了别人拷来的旧模块，定位半天才反应过来。

4. 我在SOM载板开发中踩过的坑和排查思路

4.1 工具链前缀选错：程序Illegal instruction的完整排查

有一次我把一个用arm-linux-gnueabi编译好的程序拷到目标板上，运行直接报Illegal instruction，连C库初始化都没跑完。第一反应是目标板硬件问题，拿一个已知正常的程序跑了一下，没问题，说明SoC是好的。

然后用file命令查看出错程序，发现是“ARM, EABI5”动态链接程序，ldd看到依赖的是/lib/ld-linux.so.3。这里有个关键点：目标板文件系统如果是用gnueabihf工具链构建的，它的C库动态链接器可能是ld-linux-armhf.so.3，动态连接路径对不上，就会启动失败。

进一步用readelf查看程序属性：

readelf -A hello | grep Tag_ABI_VFP_args

如果输出“Tag_ABI_VFP_args: VFP registers”，说明这个程序是硬浮点ABI编译的；如果输出“Tag_ABI_VFP_args: NP”之类的，那才是软浮点。当时我检查下来发现，我手头这个程序其实是用硬浮点交叉编译器编出来的，只是我在命令行里记错了前缀，跟目标系统不匹配，才导致指令无法执行。

处理办法很简单：统一工具链前缀，全部用arm-linux-gnueabihf重新编译；或者图省事，直接加-static静态编译，把依赖全打进程序，快速排除动态库问题。这个坑的真实教训是：不要在多个工具链前缀并存的系统里凭记忆敲命令，一定先确认目标板的根文件系统到底是用哪套工具链构建的，在Makefile里写死CROSS_COMPILE，不要再依赖环境变量里的默认值。

4.2 启动介质引脚没按规范接好：模块上电毫无反应的定位

SOM模组上电后完全没反应，串口也没有任何打印。这种情况新手很容易直接怀疑SOM坏了，但在我经验里，更常见的是载板上的BOOT配置引脚没有按规范处理好。

现在的SOM，内部往往同时接了eMMC、SD卡槽、SPI NOR Flash。上电时SoC会采样一组BOOT配置引脚，来决定第一启动介质是什么。96Boards SOM规范里对这部分引脚有明确要求，比如某个引脚必须通过电阻上拉到特定电平、某个引脚默认悬空或下拉。如果载板设计时偷懒，把这组引脚全部悬空，SoC可能默认从某个完全没接Flash的介质启动，结果就是上电后毫无反应。

当时我们的排查链路是这样的：先用示波器测量SOM主电源、核心供电是否正常，排除电源问题；再测复位信号，确认复位已经释放；然后抓住一个关键点——量BOOT配置引脚的电平，跟规范里的默认电平表一对比，果然有几个脚不对。

解决办法也很简单，在载板上给这几个BOOT引脚加上可选的上下拉电阻位，或者用0欧电阻预留配置能力。这样做还有一个好处：量产时如果想从eMMC启动改成SD卡启动，只需要更换电阻，不用重新投板。

4.3 调试口的坑：SOM不像开发板那样什么排针都有

习惯了96Boards整板开发板的人，第一接触SOM载板时最容易忽略调试串口的位置。整板开发板广受好评的地方是排针整齐、丝印清楚、方便接USB转串口调试。但SOM只是一块模组，它上面没有标准排针，调试口必须由载板按规范引出来。

我们有一块载板，当时以为SOM厂商会在模组边缘通过小焊盘引出调试串口，也没细看规范，结果板子回来后发现模组上根本没有方便接线的位置。最后只能飞线到SOM底部的测试点上，非常痛苦。这个坑在后续设计中被彻底纠正：载板原理图第一阶段就把调试串口和调试USB引到板边的标准连接器上。

我现在的建议是：把调试口当作载板上优先级最高的接口之一。它不需要占用很多PCB面积，但一定要按规范要求的位置和电平引出来。没有串口输出，你连U-Boot阶段的信息都看不到，后面的Linux启动、驱动调试都无从谈起。另一个经验是调试电平要确认是1.8V还是3.3V，别直接拿一个5V的USB转串口模块怼上去，容易烧坏SOM上的调试电路。

5. 什么时候该认真考虑96Boards SOM，什么时候别凑热闹

5.1 适合SOM方案的产品路径与团队情况

SOM方案显然不是万能的，但它确实非常适合特定场景。以我接触过的项目来看，最典型的是这几类：工业控制器、边缘网关、医疗电子、机器人主控板。这些产品有几个共同点：生命周期长、批量不算特别大、对外接口需要一定定制、供应链希望保留多个SoC选择。

生命周期这一条尤其关键。嵌入式产品一旦上市，往往要维护五到十年。SoC原厂一颗芯片供货可能只有几年，之后切换芯片会带来巨大的软硬件迁移成本。但如果用了SOM方案，换供应商时只要找到管脚兼容的模块——96Boards SOM规范这张牌在这里就值钱了——载板不变，BSP更新，产品就能续命。

团队情况上，我见过两种最适合SOM的团队：一种是5到20人的小团队，没有专职硬件高速设计工程师，靠模块把DDR部分的风险完全屏蔽；另一种是方案商，手上同时跑着好几个产品，核心板共用一块，载板各画各的，边际成本摊得很薄。这两种团队用SOM方案，ROI都很高。

5.2 不符合SOM规范的另一条路：私有SOM方案

市面上大量成熟的SOM厂商，比如Toradex、Variscite、研华等，它们用的是自己的私有接口规范。这些方案经过多年迭代，可靠性已经很好，但问题也很明显：绑定关系强。

选择了私有SOM方案，意味着你默认接受了这个厂商的产品路线。如果以后想换一家模块，载板和BSP都要重建，跟最初自己画核心板没有本质区别，只是前期省了DDR设计的功夫。兼容性反而是96Boards SOM最核心的加分项，它让你保留了跨厂商横跳的空间。

但也别把话说死。如果产品对性能、功耗、尺寸有极致要求，或者大量到一年几十万台，那么私有SOM方案甚至完全自研核心板反而更合理。因为96Boards SOM标准化必然带来一部分硬件资源冗余，而极致产品是容不下冗余的。

5.3 给独立开发者的小建议

如果你只是想学习嵌入式Linux、或者快速验证一个产品想法，我建议直接买一块完整的96Boards开发板，不要一上来就SOM+载板。完整开发板有现成的排针、USB口、调试器，开箱就能跑，学习成本最低。

但如果你已经明确知道自己要做一个具体产品，而且这个产品需要一些定制接口——比如特定数量的串口、特定的电源输入范围、特定的安装孔位——那就可以考虑SOM+载板的路线。先按96Boards SOM规范画一块简单的载板，把调试口、一个串口、一个网口跑通，再逐步增加功能。这一套流程走完，你对整个系统的理解，比用现成开发板做一百次实验都要深入。

我个人的体会是，SOM规范最值钱的地方不是那几张引脚图，而是把硬件接口“软件化”的思路。当你把模块的物理引脚都视作一个稳定的API，更换SoC就像替换一个实现类，只要接口契约不变，上层应用几乎不用动。这种思维方式的转变，才是Linaro发布这两个规范背后真正值得琢磨的东西。

工具链方面，最后再分享一个经验：我习惯在项目交付文档里固定记录工具链的具体版本号和下载路径，比如“gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabi”，而不是只写“Linaro GCC”。这样半年后客户重新构建环境，或者团队来了新人，也不会因为版本漂移导致编译出来的镜像行为不一致。嵌入式开发里，很多奇怪问题追根溯源，最后都发现是构建环境不一致导致的。把环境固定下来，真的能省掉很多远程Debug的时间。