Hubris项目中主机闪存双槽管理机制的技术解析

背景与问题场景

在基于Gimlet硬件架构的Hubris项目中，主机闪存(host flash)采用双槽设计(QSPI 0和QSPI 1)，通过模拟多路复用器实现启动槽的选择。当前实现中存在一个关键问题：当进行在线固件更新时，若主机意外重启，可能导致系统从半完成的镜像槽启动，造成系统不稳定。

硬件架构基础

系统采用两级信号路由机制：

1. 第一级2:1多路复用器：选择QSPI信号来自服务处理器(SP)或主机
2. 第二级1:2解复用器：将片选信号映射到具体闪存芯片

这种设计通过HostFlash.set_dev和HostFlash.set_mux两个RPC接口分别控制设备选择和信号路由。

现有机制的风险点

当前实现中，控制平面代理(control-plane-agent)执行以下典型操作序列时存在风险：

1. 将启动设备从QSPI 0切换到QSPI 1
2. 开始分块写入新固件镜像
3. 若此时主机意外重启(如内核崩溃或MAPO事件)

此时系统会尝试从可能不完整的QSPI 1镜像启动，导致启动失败或运行异常。

改进方案设计

核心概念分离

新方案引入两个独立逻辑状态：

1. 启动槽(Boot Slot)：系统实际启动时使用的闪存槽
2. 写入槽(Write Slot)：执行固件更新时写入的目标槽

原子化写入操作

关键改进点是实现原子化的"写入目标槽"操作：

1. 在内存中维护目标更新槽状态
2. 写入时临时切换物理多路复用器
3. 写入完成后立即恢复原始启动槽选择

这种设计既保证了写入的正确性，又最大限度减少了槽切换带来的风险窗口。

异常处理增强

结合硬件提供的RESET_L计数器，系统可以：

1. 检测主机意外重启事件
2. 自动回退到安全状态(A2)
3. 根据预设策略决定是否自动恢复运行(A0)

实现考量

1. 向后兼容性：新方案保持与现有Gimlet硬件的兼容
2. 状态持久化：启动槽选择信息需要可靠存储在两块闪存上
3. 错误恢复：与MAPO处理机制协同工作(#607相关)
4. 操作原子性：确保写入过程中的多路复用器状态不会意外保持

预期收益

该改进方案能够：

1. 显著降低固件更新过程中的系统风险
2. 保持硬件兼容性的同时提升可靠性
3. 为后续在线更新功能提供更健壮的基础
4. 改善系统异常情况下的自恢复能力

总结

Hubris项目通过重构主机闪存的双槽管理机制，实现了启动槽与写入槽的逻辑分离，配合原子化写入操作和增强的异常检测，有效提升了系统在固件更新场景下的可靠性。这一改进既解决了现有架构下的潜在风险，又为未来的功能扩展奠定了良好基础。