シリアル シェルが動作しても、グラフィックス、アプリケーション サービス、または周辺機器が承認に合格したことは証明されません。カーネル、init、および上位レベルのサービスを分離し、それらの依存関係を確認することで、RK3588 Stage-0 ブートを確認します。ここでのステージ 0 は、元のケース定義 (最小限のヘッドレス検証) に従います。
公開されたプロジェクト記録によって確立されるもの
中国語で公開されたプロジェクト レコードでは、指定されたボード、Build22、および SD ブート条件に対する OpenHarmony ブート検証が報告されています。このガイドでは、その証拠をレイヤーごとに読み取る方法を説明します。追加のボードテストは報告されていません。
ブートレイヤーと証拠
| レイヤー | 責任 | 確認すべき証拠 | サポートされていない推論 |
|---|---|---|---|
| ブートローディングとデバイスの説明 | カーネルをロードし、ブートパラメータとハードウェアの説明を指定します。 | イメージ ハッシュ、メディア、ブート パラメータ、DTB バージョン | すべてのボードバリアントをブート可能 |
| カーネル | プロセッサー、ドライバー、および基本リソースを初期化する | シリアルブートログ、ドライバーエラー、ルートファイルシステムのマウント | アプリケーションサービスは稼働中です |
| 初期化 | ユーザー空間プロセスを開始し、依存関係を整理する | 初期設定とプロセスの開始/終了レコード | グラフィックスおよびビジネス アプリケーションは承認を通過しました |
| アプリケーションサービス | インターフェイス、デバイス機能、またはビジネス API を提供する | サービスログ、APIレスポンス、シナリオテスト記録 | 長期的な安定性とすべての周辺機器の互換性 |
レイヤ全体にわたる障害の特定
まず、同じボード、イメージ、メディアを使用して問題を再現します。ログ内で最も古い障害を見つけます。ドライバーの初期化エラー、ファイルシステム パスのエラー、サービスの再起動ループを個別に分類します。サービスが終了したら、単に再起動の試行回数を増やすのではなく、必要なリソースの準備ができているかどうかを確認します。
ビルド バージョンからイメージ ハッシュ、ブート構成、シリアル ログ、および承認項目までのトレースを維持します。継続的な動作テストとは別に、単一のブート キャプチャを記録します。未テストのグラフィックス、周辺機器、信頼性に関する作業はオープンのままにしておきます。
適応評価のための入力
ボードのリビジョン、元のシステム、ブート メディア、利用可能なソース、シリアル ログ、およびターゲット機能を提供します。後の作業パッケージと受け入れを定義する前に、現在のフェーズがカバーするレイヤーに同意します。元の中国の RK3588 サービス スコープと OpenHarmony スタートアップ サブシステム ソースを参照してください。
相談
電話
WeChat
トップに戻る