摘要：嵌入式Linux是工业、医疗、汽车设备的核心底座。2026年，Yocto LTS的四年支持承诺、RISC-V平台的上游化加速、以及CRA合规对长期维护的硬性要求，正在形成一个工程三角。本文从Yocto LTS、RISC-V上游化、SBOM与CVE追踪三个维度，分析嵌入式Linux团队面临的新挑战与新工具。

一、Yocto 6.0“Wrynose”：四年支持不是锦上添花，是合规刚需

2026年5月，Yocto项目发布了6.0版本，代号“Wrynose”。这是Yocto的新一代长期支持版本，将维护至2030年4月。

四年支持周期意味着什么？对于嵌入式产品团队而言，这意味着一个在2026年基于Wrynose启动的项目，可以在不升级Yocto基线的前提下，覆盖产品从开发到量产的完整生命周期。产品团队面临长认证窗口和法规压力时，LTS是最务实的答案。

Wrynose搭载Linux 6.18 LTS内核，距离上一代5.0“Scarthgap”（Linux 6.6 LTS）大约两年。自5.3“Whinlatter”以来，已有超过240位贡献者提交了超过4000次提交。

但Wrynose最值得关注的改进，是SBOM和CVE追踪功能。Yocto项目明确表示，Wrynose带来了“更安全的默认配置，以简化即将到来的欧盟《网络弹性法案》（CRA）合规”。

这不是巧合。CRA要求制造商建立持续漏洞管理机制，而SBOM是漏洞管理的起点。Yocto LTS将SBOM生成和CVE追踪集成到构建系统中，意味着嵌入式Linux团队不需要再自己搭建一套工具链来满足合规要求。

对于使用Yocto的团队而言，这意味着两件事：第一，如果还在用非LTS版本，升级到Wrynose应该排在优先级列表的前列；第二，SBOM不再是“额外工作”，而是构建流程的标准输出。

二、RISC-V上游化：从“能不能跑”到“能不能长期维护”

RISC-V在Yocto生态中的定位正在发生根本性变化。Yocto项目在Embedded World 2026上的表述很明确：RISC-V“现在感觉更具战略性，而非实验性”。

这个转变的核心推动力来自RISE项目。RISE（RISC-V Software Ecosystem）是一个由Linux基金会欧洲托管的合作项目，目标是确保Yocto对RISC-V的“就绪度”——通过提供开发者支持来分类RISC-V特有问题，同时改进meta-riscv层的测试覆盖和板级支持。

RISE项目已经部署了一组基于RVA22标准的开发板，配合Forgejo和Labgrid实现了周期性的构建和测试流水线。这意味着RISC-V的Yocto构建不再依赖个人开发者手工验证，而是有了自动化的持续集成基础设施。

RISE的板级农场（Board Farm）策略值得关注。在欧洲，RISE与Scaleway合作建设构建农场；在美国，与俄勒冈州立大学开源实验室（OSU OSL）合作建设板级农场。这种地理分布式的测试基础设施，是RISC-V走向“可长期维护”的关键一步。

对于嵌入式工程师而言，这意味着RISC-V的Yocto支持正在从“能不能编译”走向“能不能在CI/CD中稳定运行”。如果你在做RISC-V平台的嵌入式Linux开发，现在可以认真考虑将Yocto作为构建系统的基础，而不是继续依赖厂商提供的定制化SDK。

三、SpacemiT K3：RISC-V的RK3588时刻

RISC-V在嵌入式Linux领域的另一个关键变化，是硬件性能的跃升。

进迭时空的SpacemiT K3是首批符合RVA23规范的RISC-V处理器之一。其8个64位RISC-V X100M核心最高主频2.4GHz，单节点可提供130 KDMIPS的通用算力，性能定位与Rockchip RK3588处于同一级别。

这个性能水平的意义不在于“跑分”，而在于产品定义的可行性。当RISC-V SoC的性能达到ARM主流SoC的水平时，嵌入式Linux团队在选型时就有了真正的替代方案。Firefly已经基于K3推出了48节点的AI服务器CSC2-N48SPK3，采用ARM板（RK3588）作为远程管理控制器（BMC），形成了RISC-V计算节点+ARM管理节点的混合架构。

对于嵌入式Linux开发者而言，这意味着需要开始认真对待RISC-V的工具链和内核支持。Yocto的meta-riscv层、RISE项目的板级支持、以及SpacemiT K3的RVA23兼容性，共同构成了一个可用的RISC-V嵌入式Linux开发环境。

四、三角困局的工程解法

Yocto LTS、RISC-V上游化、CRA合规三者之间，存在一个看似矛盾的三角：

• Yocto LTS要求稳定，四年不换基线
• RISC-V上游化要求更新，持续跟进内核和工具链的最新支持
• CRA合规要求可追溯，每个组件版本和漏洞状态都要记录

工程解法是分层策略：

基线层用LTS。 Yocto Wrynose作为构建基线，四年不变。内核用Linux 6.18 LTS，稳定性有保障。

硬件适配层用RISE维护的meta-riscv。 RISE项目正在持续改进meta-riscv层的板级支持和测试覆盖。使用RISE维护的BSP，而不是厂商自己维护的分支，可以获得更长的维护窗口和更好的上游化程度。

合规层用Yocto内置的SBOM和CVE追踪。 Wrynose的SBOM生成是构建流程的标准输出，不需要额外工具。CVE追踪与Yocto的recipe系统集成，当某个组件的CVE被披露时，可以快速定位哪些产品受到影响。

RISC-V平台选型看RVA23。 RVA23是RISC-V的标准化基线。选择符合RVA23的芯片（如SpacemiT K3），可以最大程度降低软件移植成本，并确保长期的生态兼容性。

五、给嵌入式Linux工程师的建议

第一，升级到Yocto Wrynose。 四年支持周期和内置SBOM功能，对于面向欧盟市场的产品是刚需。

第二，关注RISE项目。 RISE的板级农场和测试流水线正在成为RISC-V Yocto支持的“上游”。如果你的RISC-V BSP来自芯片厂商的私有分支，考虑逐步迁移到meta-riscv。

第三，理解SBOM不是一次性文档。 SBOM需要与产品型号、固件版本、交付包形成可追溯关系。Yocto的SBOM输出是起点，不是终点。

第四，RISC-V不再是“实验平台”。 SpacemiT K3的性能水平已经达到主流ARM SoC的级别。如果你在做新的嵌入式Linux项目，RISC-V应该进入选型列表。