RK3588 Stage-0启动原理：内核、init与应用服务怎样分层

文章正文技术基础

串口能进入shell，不代表图形界面、应用服务或外设已经完成验收。判断RK3588 Stage-0启动，应把内核、init与上层服务分开记录，再检查它们之间的依赖。这里的Stage-0沿用原案例定义，表示最小无界面验证阶段。

原案例能支持什么结论

原中文案例记录公开了指定板卡、Build22及SD启动条件下的OpenHarmony启动验证。本文解释这些记录应怎样分层阅读，不增加新的板卡测试结果。

层级	主要职责	建议核对的证据	不能据此推导
启动加载与设备描述	装载内核，传递启动参数和硬件描述	镜像哈希、介质、启动参数、DTB版本	所有板型均可启动
内核	初始化处理器、驱动和基础资源	串口启动日志、驱动错误、根文件系统挂载记录	应用服务已正常运行
init	按配置启动用户态进程并组织依赖	init配置、进程启动及退出记录	图形桌面和业务应用已验收
应用服务	提供界面、设备功能或业务接口	服务日志、接口响应、场景测试记录	长期稳定及全部外设兼容

先确认同一板卡、镜像和介质能够复现，再沿日志找最早的失败点。驱动初始化错误、文件系统路径错误与服务反复重启应分别归类。上层服务退出时，要核对它依赖的资源是否就绪，避免只改重启次数掩盖前置故障。

建议形成“构建版本→镜像哈希→启动配置→串口日志→判定条目”的追溯链。一次启动采集与持续运行测试应单列，未做的图形、外设和可靠性验证保留为待办。

委托方可提供板型与修订、原系统、启动介质、现有源码、串口日志及目标功能。先约定本阶段覆盖到哪一层，再讨论后续工作包与验收。相关范围可参考原中文RK3588开发服务；init机制可核对OpenHarmony启动子系统源码。