Skip to main content
Ubuntu 是通往”它能跑起来”的快速路径。Qualcomm Linux（QLI）是一个面向 Qualcomm 硬件的、基于 Yocto 的嵌入式 Linux 发行版。它的参考发行版、元数据 layer、recipe 和示例代码可以帮助客户构建和维护自己的设备软件。 这一区分很重要。Ubuntu 给开发者一条通往 SSH、apt、pip、Python 脚本、AI Hub 下载、LiteRT 测试、GenieX 以及在 Dragonwing EVK 上快速迭代的短路径。选择基于 Yocto 系统的团队则承担另一种工作：
本文描述了从标准 Ubuntu 到使用 QLI 的基于 Yocto 系统的一种可能过渡。它不把 QLI 呈现为唯一的生产路径、成品的客户产品镜像，或 Qualcomm 代客户运营和维护的软件。Qualcomm 维护平台的部分内容，包括 Qualcomm 特定的内核和硬件启用工作，但客户仍负责选择、适配、集成、验证、保护、更新和维护其最终产品软件。 本文不替代 Qualcomm Linux 设置文档。请使用官方 Dragonwing Linux 页面来处理烧录、开发板设置、软件更新和设备特定的细节： 这里的迁移问题更窄：在 Ubuntu EVK 演示工作之后，当迁移到使用 QLI 资源构建的客户自维护基于 Yocto 的系统时，必须重新验证什么？在贯穿的案例研究中，这是第 6 部分那个智能摄像头包从 EVK 演示改编为版本化客户镜像的过程。 在开始之前：

​
两个里程碑

一次 Qualcomm 迁移有两个不同的成功里程碑。
常见的错误是把里程碑 1 当成里程碑 2。演示证明可行性；一个客户自维护的软件候选需要可重复的构建、验证、安全流程和明确的维护所有者。QLI 参考代码不会把这些责任转移给 Qualcomm。

​
为什么 Ubuntu 在早期有用

Ubuntu 是一个强大的第 0 天和开发环境，因为它为开发者速度优化：
当悬而未决的问题是这些时，那正是你想要的：
对于原型、实验室演示、内部工具和评估，Ubuntu 可能是暂时留下来的正确位置。

​
客户为什么可能选择 QLI 资源

QLI 是一个面向 Qualcomm 硬件的、基于 Yocto 的嵌入式 Linux 发行版。Dragonwing 文档描述了一个经过策划的技术栈，并为诸如 AI、GPU、DSP、摄像头和多媒体等领域提供参考发行版、layer、recipe、设置指导和硬件启用。文档称 QLI 面向生产；那描述的是它的设计目标，而不是产品所有权或维护责任从客户到 Qualcomm 的转移。 那可以帮助客户组装一个产品软件候选： 重点不是 Ubuntu “不对”，QLI 也不是一个强制目的地。客户可以留在 Ubuntu 上、使用 QLI 构建，或选择适合其硬件和产品的另一种 OS 策略。决策取决于客户的需求、维护模型、安全流程、合规义务和支持安排。

​
迁移前应证明什么

太早迁移会让每个问题看起来都像 OS 问题。太晚迁移会让原型假设渗入产品。 一个好的过渡点是当这些在 EVK 上为真时：
到那时，迁移问题从”这能运行吗？“变为”这能在产品软件上反复运行吗？“

​
迁移期间会变什么

应用不应有太大变化。围绕它的环境会变化。 最安全的方式是让应用契约保持稳定，同时让 OS 变化。

​
重新验证运行时包和工件

AI 运行时工件绑定的不仅仅是模型。记录准确的矩阵：
在下列任一变化时重建或至少重新验证：
对于 QNN/QAIRT 上下文二进制文件，假设目标敏感。更安全的做法是为客户所选的 OS/BSP/运行时组合重新生成和验证，而不是花两天调试一个陈旧的二进制。客户拥有这个重建和验证流程。

​
把演示变成一个包

在 Ubuntu 上，演示可能位于 home 目录中：
对于 QLI，让运行时包显式化：
示例清单字段：
那个清单是有意无聊的。当出现现场问题时，无聊就是极好的。

​
让它成为一项服务

一条终端命令对第 0 天是可以的。产品需要一个进程模型。 一份最小服务契约：
一个小的 systemd 形态可能是这样：
保持服务包装器薄。应用应拥有健康和清晰的错误消息；监督者应拥有重启策略。

​
在基于 QLI 的镜像上重新运行第 0 天检查

从第 2 部分继续沿用同样的健全性检查：
这避免了一个常见陷阱：在新 OS 镜像上证明基础运行时之前就调试自定义应用。

​
持续验证胜过峰值数字

产品验证应包括无聊的运行，而不仅是激动人心的基准测试。 运行应用足够长时间以捕捉：
建议的关口： 峰值 FPS 有用。持续行为才是可交付的。

​
及早规划更新和回滚

如果产品包含 AI，我们建议及早规划更新。模型会变。阈值会变。运行时包会变。安全修复会发生。 定义什么可以独立更新：
然后定义回滚触发器：
只要客户拥有并运营构建、安全和更新流程，客户自维护的 Yocto/QLI 系统就可以为这种产品更新故事提供比松散开发镜像更受控的基础。 安全和更新细节不需要在首个产品候选中很详尽，但它们应该是显式的。诸如《欧盟网络弹性法案》之类的法规可以对包含数字元素的产品施加生命周期、漏洞处理和更新义务。客户的法务和安全团队必须确定哪些要求适用，并确保产品组织——而不是未修改的参考发行版——被指派为满足这些要求负责。

​
客户自维护系统检查表

在演示成为产品候选之前：

​
智能摄像头案例研究的迁移账本

通过记录每个 Jetson 部件在 Dragonwing 上变成了什么来结束迁移： 测量状态应该是显式的。如果实验室运行尚未完成，就直说，而不是暗示结果：

​
结论

Ubuntu EVK 演示是一个有用的首个里程碑。它在不预定客户最终 OS 策略的情况下，快速证明模型、运行时和应用形态。 如果客户选择 QLI，其发行版、layer、recipe 和参考材料可以支持这一过渡，但它们不会自动把演示变成产品。客户的工程组织必须把那些输入变成一个受控的产品候选：版本化的 OS、锁定的运行时、可复现的包、服务管理、持续验证和更新故事。 保持应用契约稳定、重建或重新验证目标敏感的工件，并让每个版本都可见。最重要的是，为 OS 维护、漏洞响应、更新、回滚和适用的监管/合规工作分配所有权。那才是从”它能跑”到客户自维护产品候选的路径。