我在帮客户做一款工业网关的时候光载板就改了三版。原因很简单第一版用的是A厂商的核心板第二版想换B公司的模块结果尺寸对不上、连接器座子对不上、引脚定义更是完全两套逻辑——本质上等于从头再画一次板。这个场景凡是做过“核心板底板”方案的硬件工程师应该都不陌生。所以当看到Linaro把96Boards家族扩展到SOMSystem 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的定位差别对比维度96Boards SOM 标准版96Boards SOM Entry版目标场景边缘计算、工业控制器、AI网关IoT网关、简单HMI、数据采集接口密度高包含PCIe、USB3、千兆网等高速信号低以UART、USB2、百兆/千兆为主载板设计复杂度需关注信号完整性建议四层以上设计宽松四层即可甚至两层够用连接器方案高密度板对板连接器简化连接器成本低插拔方便成本敏感度中高适合性能优先高适合成本优先对开发者要求需要一定的硬件高速设计经验对新手和大批量产品更友好当然具体到引脚数量、电气参数这些细节还是要以官方发布的规范文档为准。这里给的是一个选型框架不是替代文档。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-gnueabi32位ARM、软浮点ABI兼容性最好适合Cortex-A5、A7这类带不带VFP/NEON的处理器都能跑arm-linux-gnueabihf32位ARM、硬浮点ABI性能更好但要求SoC必须带硬件浮点单元且整个系统都要用硬浮点编译aarch64-linux-gnu64位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 ARCHarm export CROSS_COMPILEarm-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的时间。