cx3576：CX3576-Z / Rockchip RK3576
cx3576 是一块硬件板，按产品命名，也是仓库里的移植参考板。它的镜像已发布、
刷写流程已实现，而没有任何自动流程会启动它的镜像——没有套件会启动 FIT 镜像。
有一次实机观察在案，日期为 2026-09-20：在一块 CX3576-Z 上，加载器用本项目的密钥验证了
内核、设备树与 ramdisk，认证的 init 选择并验证了部署，健康门确认了它
（mica-build:boards/cx3576/evidence.json，其中以摘要指名了控制台抓取）。这次抓取是由
加载器发起的热复位，所以它既不是冷启动行也不是热启动行，下面认证矩阵的每一行仍然是
not tested。
状态以状态表为准。
| 项 | 值 |
|---|---|
| SoC | Rockchip RK3576 |
| 架构 | arm64 |
| 启动链 | BootROM → 厂商 DDR/SPL/TF-A → 固定版本的 Mica OS U-Boot → 必须验签的 FIT 配置 → 内核与认证的 native init → SYSTEM → 签名的 verity root/support → systemd |
| 固件形态 | rockchip-loader（U-Boot 写在镜像第 64 扇区，在镜像内） |
| 分区 | FIRMWARE / SYSTEM / DATA |
| 存储介质 | eMMC /dev/mmcblk0（具体型号仍是待测项） |
| 内核与 U-Boot | 厂商 6.1 内核与主线 U-Boot，连同补丁固定在 mica-build:boards/cx3576/bsp.env |
| 支持层级 | bring-up |
| 启动保证等级 | I1 |
启动链里有厂商 blob：DDR init v1.12 与 TF-A bl31 v1.24（来自 Rockchip rkbin）。
软件层面的 FIT 强制验签不能证明这两个可变启动阶段被硬件认证过。
硬件与功能状态
Section titled “硬件与功能状态”BOARD_FEATURES="wifi bluetooth display status-led can usb-gadget containers"。
“声明”指板卡声明了该特性并带着对应的包与初始化逻辑；实机行全部未测。
| 功能 | 状态 | 说明 |
|---|---|---|
| 容器（Podman） | 随镜像发布 | — |
| Wi-Fi | 已声明，实机未测 | 板子是双 SKU：AP6275S（bcmdhd/SDIO）或 AIC8800D80，构建期不区分。只带了 AIC8800D80 的固件，AP6275S 不在本页的声明范围内 |
| 蓝牙 | 已声明，实机未测 | 与 Wi-Fi 同一模组 |
| 出厂接入点 | 随 cx3576.full 发布，实机未测 |
开箱即开、station 关闭；名称和密钥由设备码与产品密钥得出，印在标签上，认领前有效（mica-core:docs/factory-ap-key.md） |
| 设备码 | 发布 | 来源 emmc-cid，即 eMMC 芯片标识；重新烧录后不变 |
| BLE 配网 | 随 cx3576.full 发布，实机未测 |
手机设置 WiFi 网络并认领未认领的设备（首次启动第 5 节） |
| 以太网 | 已声明，实机未测 | Motorcomm YT8531 PHY，内核补丁带着它的初始化序列；MAC 地址由 eMMC CID 与端口在总线拓扑中的位置派生，而不是取自 machine id |
| HDMI 显示 | 已声明，实机未测 | 输出与旋转的默认值记在板卡定义的说明里，镜像流水线目前不读任何显示设置 |
| 开机 logo | 已实现 | Mica OS 图标加字标，构建时渲染 |
| CAN | 已声明，实机未测 | can0 是 micad 里类型为 can 的网络条目；板卡默认值为经典 CAN 250 kbit/s、100 ms 后重启、不开 FD（配置） |
| USB OTG / USB gadget | 已声明，实机未测 | gadget getty 的 udev 规则随包发布 |
| 状态灯 | 已声明，实机未测 | — |
| RTC | 存在性未确认 | 设备树声明 i2c7 上 0x51 的 AT8563/hym8563，board.env 不记录 RTC 事实；驱动与后备电池都没在整机上跑过。时间管理不依赖它：常开 NTP、DATA/state 上的时钟下限与时区设置在完全没有 RTC 的板子上也一样 |
| 物理恢复动作 | 无 | BOARD_RECOVERY_ACTIONS=""。恢复键不是物理在场断言——它只把板卡送进 rockusb loader 模式，没有任何软件恢复流程读它 |
硬件初始化项（BOARD_HWINIT_CONFS="otg bt mac gadget modules"）各有一个 unit 加
一个脚本，板卡包共使能 5 个 unit。
status: board-dependent — evidence:
mica-build:boards/cx3576/board.env,mica-build:boards/cx3576/evidence.json
| 分区 | 范围 | 说明 |
|---|---|---|
FIRMWARE |
扇区 64–36863（18 MiB 之前） | 内含 U-Boot（第 64 扇区，字节偏移 32768 处魔数 RKNS）与两份 64 KiB 带 CRC 的启动记录（16 MiB、17 MiB） |
SYSTEM |
18 MiB 起，1024 MiB | ext4 + verity，不可变组件文件与两份签名部署 |
DATA |
1042 MiB 起，出厂 256 MiB | 首次启动扩展到介质大小 |
完整出厂镜像 1299 MiB = 1 362 100 224 字节（含 GPT 尾部）。GPT 覆盖引导器与两份记录， 所以 DATA 增长不会把它们吃掉。
串口 ttyFIQ0，1500000 波特，earlycon=uart8250,mmio32,0x2ad40000；
net.ifnames=0。
产品是 cx3576.basic（默认）与 cx3576.full（带容器），各自发布为
cx3576.<variant>.<YYYYMMDD-HHMM>，镜像文件名 mica-cx3576.<variant>-<YYYYMMDD-HHMM>.img.gz。
校验方法见获取发布版。
镜像自带引导器：U-Boot 就在镜像第 64 扇区的保护区间内，所以写镜像等于同时写了
引导器——没有单独的 idblock 步骤，也不产出厂商 update.img。
刷机是操作者在 USB 上用 rkdeveloptool 完成的流程；构建树不带刷机工具。镜像必须是解压后的 .img，恰好 1 362 100 224 字节。
设备在 Loader/RockUSB 模式（U-Boot 已运行、gadget 已枚举）：
rkdeveloptool wl 0 mica-cx3576-<stamp>.img # 整盘写入rkdeveloptool rl 0 36864 boot.bin # 先回读引导器与记录区……cmp boot.bin <(head -c $((36864*512)) mica-cx3576-<stamp>.img)rkdeveloptool rl 36864 2623488 rest.bin # ……再回读其余部分cmp rest.bin <(tail -c +$((36864*512+1)) mica-cx3576-<stamp>.img)rkdeveloptool rd # 两次比对都通过后才复位设备在 Maskrom 模式（引导器区间缺失或损坏）：先推送仓库里的厂商 loader，再走上面的 Loader 流程。
sha256sum -c boards/cx3576/loader/MiniLoaderAll.bin.sha256 # 在 mica-build 树内rkdeveloptool db boards/cx3576/loader/MiniLoaderAll.bin- 先单独回读引导器区间（前 36 864 扇区）：这一段的部分写入或损坏是唯一会让板卡跳过恢复键
变砖的失败。比对不一致时不要执行
rd：设备停在 Loader 模式，可以立刻重刷。 - 在
db和rd之间不要断电、拔线或复位板卡。 - 前置条件：
PATH上有rkdeveloptool，以及 USB 访问权限（树里不提供 udev 规则）。macOS 上按docs/hardware/cx3576/rkdeveloptool/README.md原生构建。
未验证：面对真实硬件的每一步、进入 Maskrom 的按键或触点序列、SD 卡启动回退。细节见 刷写 第 5 节。
status: board-dependent — evidence:
mica-build:boards/cx3576/loader/MiniLoaderAll.bin.sha256,docs/hardware/cx3576/rkdeveloptool/README.md,docs/start/flashing.md
DATA 扩容、出厂两份部署、健康门确认，与 UEFI 板一致；区别是启动记录放在固件区域内
冗余的 U-Boot 环境里（tries = 3），而不是 ESP 上的 loader 条目。
U-Boot 在访问 eMMC 之前就启动看门狗，校验当前 GPT 几何，选记录、写入、刷盘、回读 递减后的尝试次数，然后才加载 FIT；持久化失败就拒绝启动。两份记录都耗尽或无效时 进入本地 rockusb 恢复。
发布 full、root、kernel 三种归档，与其它板一样。A/B 是 SYSTEM 上的两份文件式
部署，不是分区槽，所以没有“另一个槽”可刷。见更新与回滚。
注意：这棵树里没有任何东西会启动这块板的镜像，因此整条“写入 → 首次启动 → 更新 → 确认 → 回滚”的链路在这块板上没有一次留下证据的端到端执行。
阶梯与别的板相同，差别在最底下两级：
- 可用：只读诊断、手动回滚、配置重置、应用数据重置、整盘重刷。
- 不可用：凭据恢复与恢复出厂——
BOARD_RECOVERY_ACTIONS=""，物理在场断言产不出来。 - 兜底：rockusb（上电时按恢复键、启动失败时自动落入），loader 区本身没了就用 Maskrom，然后从 Maskrom 整盘重写。代价是全部分区以及设备身份。
- 安全擦除不存在，eMMC 上没有任何被验证过的擦除原语。
见恢复。
- 实机启动、eMMC 断电、看门狗接管与复位原因、完整 USB 刷写、RTC 与外设合格，全部 需要一台具名的本地台架设备。
- DDR init 与 TF-A 是厂商 blob；软件 FIT 强制验签不证明首批可变启动阶段被硬件认证， 也不证明调试通道是关闭的。
- 已接受的射频包针对 AIC8800D80；AP6275S SKU 未合格。
- 确切的 eMMC 型号与板卡版本仍需实物证据。
rkbinblob 与厂商 MiniLoader 的独立 sha256 摘要未归档（intake 规则要求二进制 输入有这个），已记为已知限制。- 开发用的启动/内容/元数据密钥是独立测试输入，没有任何 OTP/熔丝改动或生产密钥仪式。
- 串口控制台上的 U-Boot 仍是交互式的（
BOOTDELAY=1，带fdt、md/mw、go）， 能接触串口的人可以改内存里的控制 DTB 或跑未签名的二进制。
绑定（指名版本规则）：板卡版本 CX3576-Z；eMMC 在 /dev/mmcblk0，具体型号尚未指名；
射频模块 AIC8800D80；BSP 以 mica-build:boards/cx3576/bsp.env 固定的为准。不涵盖
AP6275S 射频变体。
归属：Mica OS 项目负责 BSP 同步、CVE 响应与认证；这块板是仓库里的移植参考板，没有 在案的集成商。
没有在实机上跑过的矩阵在案，所以每一个硬件行都是 not tested。非实机门禁只说明它们
自己的范围，从不算作实机通过：启动记录解析与固件 IO、DATA 扩展，以及 FIT 签名与密钥
轮换的拒绝。
| 行 | 结果 | 日期 | 证据 / 原因 |
|---|---|---|---|
| 冷启动 | not tested | — | 需要台架硬件 |
| 热启动 | not tested | — | 需要台架硬件 |
| A/B 切换与更新 | not tested | — | 需要台架硬件；记录解析与固件 IO 有非实机套件，不是实机结果 |
| 更新中断电 | not tested | — | 需要断电装置 |
| 存储扩展 / 健康 | not tested | — | 需要台架硬件；扩展逻辑有主机侧测试，同样的保留 |
| 网络 / 射频 | not tested | — | 需要带 AIC8800D80 的台架硬件 |
| USB / 现场总线（CAN、OTG/gadget） | not tested | — | 需要台架硬件 |
| RTC | not tested | — | RTC 是否存在本身尚未确认 |
| 温度 / 降频 | not tested | — | 需要在持续负载下的台架硬件 |
| 看门狗 / 复位原因 | not tested | — | 需要台架硬件 |
| 离线服务 | not tested | — | 需要台架硬件 |
| 恢复 | not tested | — | 需要台架硬件；列出的每条路径都只有描述，没有经过装置验证 |
| 安装与首次启动 | not tested | — | 需要台架硬件；rockusb 刷写有文档，但没有在实机上跑过 |
status: board-dependent — evidence:
mica-build:boards/cx3576/evidence.json,mica-build:boards/cx3576/board.env,mica-build:tests/suites/lifecycle-uboot-fit