• 如果 TC 和 TM 都由同一份 XML、同一套 EdsLib 代码生成和解析，测试有可能只是“自己同意自己”。引入不读取 EDS XML 的 puslib，才算多了一条相对独立的检查路径。

• 本地打包后立刻在同一个函数里解包，只能说明基本接口能调用。把发送端和接收端拆成两个进程，中间真的走一次 UDP，测试边界会清晰很多。

• 真正开始写服务类型 17 的 EDS XML 后才发现，难点不在 XML 语法，而在于区分标准固定内容和任务需要自行声明的内容。把公共包头、服务约束和业务字段分层后，文件会清楚很多。

• PUS 不是另一种链路协议，而是建立在 CCSDS 空间包之上的应用层使用规则。先把协议分层、包头字段和几种 ID 拆开，再读 PUS 服务类型 17，很多看似相似的名词就不会混在一起。

• EdsLib 的接口很多，但固定长度消息的核心闭环并不复杂：取得类型 ID，初始化 native object，查询尺寸，完整打包，再按同一数据契约完整解包。真正容易出错的是对象表示、长度单位和验证边界。

• 最开始把 EDS 理解成“用 XML 生成结构体”。真正顺着源码跑完一次才发现，结构体只是给 C 程序看的外壳，保存类型、位宽、约束和编解码规则的数据库，才是 EdsLib 能工作的核心。

• 第一次同时看到 EDS、SEDS、EdsLib、CCSDS、PUS、TC、TM 这些词时，很容易把它们理解成同一套协议里的不同模块。实际上，它们分属“数据描述”“线包结构”“应用服务”和“实现工具”几个层次。先把边界理清，后面写 XML、调用 EdsLib 和验证服务类型 17 才不会越学越乱。

• 在 Arch Linux 环境中使用笔记本内置 Realtek RTL8852BD 无线网卡时，发现WiFi 功能正常，但是蓝牙适配器无法正常使用。

本章记录什么

最后一章不再增加新的架构功能，而是把整条系统路径重新走一遍，并建立一套可复用的验证与排错方法。目标是让“能够运行”变成一组可以复查的证据：ELF 段与符号正确，启动输出按阶段出现，任务切换有双向进展，Timer IRQ 能重复触发，设备清源与 EOI 都发生，MMU/Cache 状态可读，CPU1 能完成 SGI 往返。

在这一章之前做了什么

前十章已经依次建立处理器状态、ABI、启动、协同上下文、异常现场、GIC/Timer、抢占、MMU、Cache 和双核底座。系统越完整，故障越不适合靠“多加几行打印”猜测，因为串口本身可能不可重入，读取 IAR 还有副作用，Cache 又可能让共享状态的观察滞后。

本章按照静态检查、分层断点、寄存器观察、串口证据和已知 Bug 五条线组织。文章末尾给出能力边界，避免把教学闭环夸大成完整产品操作系统。

本章记录什么

这一章把单核可运行系统扩展为 Cortex-A9 双核启动底座。重点是共享状态和每核状态的边界：BSS、页表和 Distributor 只能由主核负责共享初始化；模式栈、GICC、PPI、CP15、TLB 和 L1 Cache 则必须由每个 CPU 分别建立。

在这一章之前做了什么

单核路径已经能够启动 MMU、Cache、GIC 和任务调度，但直接让 CPU1 执行同一入口会引入竞争：两个核可能同时清 BSS、重复初始化全局对象，或者共用一份 SVC/IRQ 栈。为此启动入口先读取 MPIDR 分流，CPU1 在 release flag 上等待，CPU0 完成发布后再用 cache clean、屏障和事件唤醒次核。

本章给出启动时序、SGI 往返验证和次核初始化代码，同时明确“第二个核在线”不等于“已经完成 SMP 调度器”。