MICROCHIP PIC64GX 64 ビット RISC-V クアッドコア マイクロプロセッサ

製品情報

仕様:

• 製品名: マイクロチップ PIC64GX
• ブートプロセス: SMPと AMP サポートされているワークロード
• 特別な機能: ウォッチドッグサポート、ロックダウンモード

製品使用説明書

1. ブートプロセス
   1. 起動に関係するソフトウェアコンポーネント
      システムの起動プロセスには、次のソフトウェア コンポーネントが関与します。
      • ハートソフトウェアサービス（HSS）：ゼロstagブートローダー、システムモニター、およびアプリケーションのランタイムサービスのプロバイダー。
   2. 起動フロー
      システム ブート フローのシーケンスは次のとおりです。
      1. Hart ソフトウェア サービス (HSS) の初期化
      2. ブートローダの実行
      3. アプリケーションの起動
2. ウォッチ・ドッグス
   1. PIC64GX ウォッチドッグ
      PIC64GX には、システムの動作を監視し、システム障害が発生した場合にアクションをトリガーするウォッチドッグ機能が搭載されています。
3. ロックダウンモード
   ロックダウン モードは、起動後のシステム アクションを完全に制御する必要があるお客様向けに設計されています。このモードでは、E51 システム モニターの機能が制限されます。

よくある質問

• Q: Hart Software Services (HSS) の目的は何ですか?
  A: HSSはゼロSとして機能しますtagブートローダー、システムモニター、およびブートプロセス中のアプリケーションのランタイムサービスのプロバイダー。
• Q: PIC64GX ウォッチドッグ機能はどのように動作しますか?
  A: PIC64GX ウォッチドッグはシステムの動作を監視し、システム障害が発生した場合に事前定義されたアクションを実行してシステムの信頼性を確保します。

導入

このホワイトペーパーでは、マイクロチップPIC64GXがアプリケーションワークロードを起動する方法と、SMPとSMPの両方で同じように動作するシステムブートプロセスについて説明します。 AMP さらに、SMPと AMP ワークロード、PIC64GX のウォッチドッグ、およびシステム起動後に E51 システム モニターの動作を制限する完全な制御を顧客が望むシステム向けの特別なロックダウン モード。

ブートプロセス

まず、システムの起動に関係するさまざまなソフトウェア コンポーネントを確認し、その後、システムの起動フロー自体のシーケンスを詳しく見ていきましょう。

起動に関係するソフトウェアコンポーネント
システムの起動プロセスには、次のコンポーネントが関与します。

図1.1. 起動コンポーネント

• ハート ソフトウェア サービス (HSS)
  Hart Software Services（HSS）はゼロからtagHSS は、ブートローダー、システムモニター、およびアプリケーション用のランタイムサービスのプロバイダーです。HSS は、初期のシステムセットアップ、DDR トレーニング、ハードウェアの初期化/構成をサポートします。主に E51 で実行され、少量のマシンモードレベルの機能は各 U54 で実行されます。ブートメディアからアプリケーションの「ペイロード」をロードして XNUMX つ以上のコンテキストを起動し、オペレーティングシステムカーネル用のプラットフォームランタイムサービス/スーパーバイザ実行環境 (SEE) を提供します。セキュアブートをサポートし、ハードウェアのパーティション分割/分離を保証する重要なコンポーネントです。 AMP コンテキスト。
• ダス U-Boot (U-Boot)
  Das U-Boot (U-Boot) は、オープンソースのユニバーサル スクリプト可能ブート ローダーです。さまざまなソース (SD カードやネットワークを含む) からブート イメージを取得できるシンプルな CLI をサポートしています。U-Boot は Linux をロードします。必要に応じて UEFI 環境を提供できます。通常は Linux が起動したら終了して邪魔になりません。つまり、起動後に常駐することはありません。
• Linuxカーネル
  Linuxカーネルは、世界で最も人気のあるオペレーティングシステムカーネルです。アプリケーションのユーザーランドと組み合わせると、一般的にLinuxオペレーティングシステムと呼ばれるものになります。Linuxオペレーティングシステムは、豊富なPOSIX APIと開発環境を提供します。ampPython、Perl、Tcl、Rust、C/C++、Tclなどの言語とツール、OpenSSL、OpenCV、OpenMP、OPC/UA、OpenなどのライブラリAMP (RPmsg および RemoteProc)。
  YoctoとBuildrootはLinuxシステムビルダーであり、特注のカスタマイズされたLinuxシステムを生成するために使用できます。Yoctoは、豊富な機能を備えたLinuxディストリビューションを出力します。
  アプリケーション、ツール、ライブラリ、およびオプションのパッケージ管理のセット。Buildrootは、より最小限のルートを出力します。 fileシステムと、永続的なストレージを必要とせず、完全にRAMから実行されるシステムをターゲットにすることができます（Linuxのイニシャルサポートを使用して、たとえばample）。
• ゼファー
  Zephyr は、小型のオープンソースのリアルタイム オペレーティング システム (RTOS) です。Linux への RPMsg-lite 通信チャネルを備えた、オーバーヘッドの少ないリアルタイム フレームワークを提供します。カーネル、ライブラリ、デバイス ドライバー、プロトコル スタックなどが含まれています。 fileシステム、ファームウェア更新のメカニズムなどが追加され、PIC64GX でよりベアメタルに近いエクスペリエンスを求める顧客に最適です。

起動フロー
PIC64GX には、64 ビット E51 システム モニター ハートと 4 つの 64 ビット U54 アプリケーション ハートを含む RISC-V コアプレックスが含まれています。RISC-V 用語では、ハートはレジスタのフルセットを含み、コードを独立して実行する RISC-V 実行コンテキストです。これは、ハードウェア スレッドまたは単一の CPU と考えることができます。単一のコア内のハートのグループは、多くの場合、コンプレックスと呼ばれます。このトピックでは、E64 システム モニター ハートと U51 アプリケーション ハートを含む PIC54GX コアプレックスを初期化する手順について説明します。

1. PIC64GX コアプレックスの電源を入れます。
   電源投入時に、RISC-V コアプレックス内のすべてのハートはセキュリティ コントローラによってリセットから解放されます。
2. オンチップ eNVM フラッシュ メモリから HSS コードを実行します。
   最初に、各ハートはオンチップ eNVM フラッシュ メモリから HSS コードの実行を開始します。このコードにより、すべての U54 アプリケーション ハートがスピンして命令を待機し、E51 モニター ハートがコードを実行してシステムを初期化して起動できるようになります。
3. HSS コードを eNVM から L2-Scratch メモリに解凍します。
   ビルド時の構成に応じて、HSS は通常、eNVM フラッシュ メモリ自体の容量よりも大きくなります。そのため、E51 で実行される HSS コードが最初に行うことは、図 2 と図 1.2 に示すように、eNVM から L1.3 スクラッチ メモリに HSS コードを解凍することです。
   図1.2. HSSはeNVMからL2スクラッチに解凍する
   図1.3. 解凍中のHSSメモリマップ
4. 次の図に示すように、eNVM から L2-Scratch にジャンプして実行可能ファイルに入ります。
   図 1.4. HSS は解凍後に eNVM から L2Scratch のコードにジャンプします。
   実行可能ファイルは 3 つのコンポーネントで構成されます。
   • ハードウェア抽象化レイヤー（HAL）、低レベルコード、ベアメタルドライバー
   • RISC-V OpenSBIのローカルHSSフォーク（PIC64GXのアップストリームからわずかに変更） AMP 目的）
   • HSSランタイムサービス（ステートマシンはスーパーループで実行される）
5. OpenSBI で使用されるハードウェアとデータ構造を初期化します。
   この初期化は、HSS サービス「Startup」が担当します。
6. 外部ストレージからアプリケーションワークロード（payload.bin）イメージを取得します。これは図1.5と図1.6に示されています。
   重要: PIC64GX Curiosity Kit の場合、これは SD カードからのものになります。
   図 1.5. 外部ストレージから payload.bin ワークロード イメージを取得する
   図 1.6. payload.bin を取得した後の HSS メモリマップ
7. payload.binからさまざまなセクションを実行時の宛先にコピーします。payload.binは、SMPまたは AMP ワークロード。コード、データ、記述子テーブルが含まれており、HSS は、さまざまなアプリケーション ワークロードを実行するために必要な場所にコードとデータ セクションを適切に配置できます。
   図1.7. payload.binが宛先アドレスにコピーされる
8. 関連する U54 に実行開始アドレスにジャンプするように指示します。この開始アドレス情報は、payload.bin に含まれています。
9. U54アプリケーションを起動し、任意の秒数tageブートローダー。例：ample、U-Boot は Linux を起動します。

リブート

システムブートの概念に関連して、再起動の必要性があります。PIC64GXアプリケーションのワークロードを考えるとき、再起動では対称型マルチプロセッシング（SMP）と非対称型マルチプロセッシング（AMP）シナリオ：

1. SMP システムの場合、別のコンテキストで考慮すべき追加のワークロードがないため、再起動によってシステム全体を安全にコールド リブートできます。
2. の場合 AMP システムによっては、ワークロードに自身の再起動のみが許可される（他のコンテキストに干渉しない）場合もあれば、システム全体の再起動を実行できる特権が与えられる場合もあります。

再起動して AMP
SMPを有効にして AMP 再起動シナリオでは、HSS はコンテキストに割り当てることができるウォーム リブート権限とコールド リブート権限の概念をサポートしています。ウォーム リブート権限を持つコンテキストはそれ自体の再起動のみが可能で、コールド リブート権限を持つコンテキストは完全なシステム リブートを実行できます。例:ampたとえば、次の代表的なシナリオを考えてみましょう。

• 完全なシステム再起動を要求できる単一コンテキストのSMPワークロード
• このシナリオでは、コンテキストにコールド リブート権限が許可されます。
• 2つの文脈 AMP ワークロードでは、コンテキストAはシステム全体の再起動を要求することができ（すべてのコンテキストに影響します）、コンテキストBは自分自身の再起動のみが許可されます。
• このシナリオでは、コンテキスト A にコールド リブート権限が許可され、コンテキスト B にウォーム リブート権限が許可されます。
• 2つの文脈 AMP ワークロード。コンテキスト A と B は、それ自体の再起動のみが許可されます (他のコンテキストには影響しません)。
• このシナリオでは、両方のコンテキストにウォーム リブート権限のみが許可されます。
• 2つの文脈 AMP ワークロード、コンテキストAとBの両方が完全なシステム再起動を要求できる
• このシナリオでは、両方のコンテキストにコールド リブート権限が許可されます。
• さらに、ビルド時の HSS では常にコールド リブート権限を許可し、コールド リブート権限をまったく許可しないことも可能です。

関連する HSS Kconfig オプション
Kconfig はソフトウェア ビルド構成システムです。ビルド時のオプションを選択したり、機能を有効または無効にしたりするためによく使用されます。Linux カーネルで開発されましたが、現在では Linux カーネル以外のプロジェクト (U-Boot、Zephyr、PIC64GX HSS など) でも使用されています。

HSS には、HSS の観点から再起動機能を制御する 2 つの Kconfig オプションが含まれています。

• CONFIG_ALLOW_COLD 再起動
  これが有効になっている場合、コンテキストはコールドリブートの呼び出しをグローバルに実行できます。無効になっている場合は、ウォームリブートのみが許可されます。このオプションを有効にすることに加えて、ペイロードジェネレータYAMLを通じてコン​​テキストにコールドリブートの発行権限を付与する必要があります。 file または次の Kconfig オプション。
• CONFIG_ALLOW_COLD REBOOT_ALWAYS
  • この機能を有効にすると、payload.bin フラグの権限に関係なく、すべてのコンテキストがコールド リブート ECAA をグローバルに発行できるようになります。
  • さらに、payload.bin 自体には、特定のコンテキストがコールド リブートを発行する権限があることを示すコンテキストごとのフラグを含めることができます。
    • コンテキストが別のコンテキストをウォームリブートできるようにするには、YAML記述にallow-reboot: warmオプションを追加します。 file payload.binを作成するために使用
    • システム全体のコンテキスト コールド リブートを許可するには、allow-reboot: cold オプションを追加します。デフォルトでは、allow-reboot を指定しないと、コンテキスト自体のウォーム リブートのみが許可されます。このフラグの設定に関係なく、HSS で CONFIG_ALLOW_COLDREBOOT が有効になっていない場合、HSS はすべてのコールド リブート要求をウォーム (コンテキストごと) リブートに再処理します。

再起動の詳細
このセクションでは、再起動がどのように機能するかを詳細に説明します。まず OpenSBI レイヤー (最下位の M モード レイヤー) から始め、次にこの OpenSBI レイヤー機能が RTOS アプリケーションまたは Linux などのリッチ OS からどのようにトリガーされるかについて説明します。

OpenSBI 再起動コール

• RISC-V スーパーバイザ バイナリ インターフェイス (SBI) 仕様は、プラットフォームの初期化とファームウェア ランタイム サービス用の標準化されたハードウェア抽象化レイヤーを記述します。SBI の主な目的は、さまざまな RISC-V 実装間での移植性と互換性を実現することです。
• OpenSBI (Open Source Supervisor Binary Interface) は、SBI 仕様のリファレンス実装を提供するオープンソース プロジェクトです。OpenSBI は、割り込み処理、タイマー管理、コンソール I/O などのランタイム サービスも提供しており、これらは上位レベルのソフトウェア レイヤーで利用できます。
• OpenSBI は HSS の一部として含まれており、マシン モード レベルで実行されます。オペレーティング システムまたはアプリケーションがトラップを発生させると、そのトラップは OpenSBI に渡されて処理されます。OpenSBI は、ecall と呼ばれる特定のトラップ メカニズムを通じて、特定のシステム コール タイプの機能をソフトウェアの上位層に公開します。
• システム リセット (EID 0x53525354) は、上位層ソフトウェアがシステム レベルの再起動またはシャットダウンを要求できるようにする包括的なシステム コール機能を提供します。この ecall が U54 によって呼び出されると、その U54 でマシン モードで実行されている HSS ソフトウェアによってトラップされ、対応する再起動要求が E51 に送信され、コンテキストの権限に応じてコンテキストまたはシステム全体が再起動されます。

詳細については、 RISC-V スーパーバイザ バイナリ インターフェース仕様 特に システム リセット拡張 (EID #0x53525354 “SRST”).

Linuxの再起動

具体的な例としてamp言い換えると、Linux では、shutdown コマンドはシステムを停止または再起動するために使用されます。このコマンドには通常、halt、power off、reboot など、多くのエイリアスがあります。これらのエイリアスは、シャットダウン時にマシンを停止するか、シャットダウン時にマシンの電源をオフにするか、シャットダウン時にマシンを再起動するかを指定します。

• これらのユーザー空間コマンドは、Linux に再起動システム コールを発行します。これはカーネルによってトラップされ、SBI ecall と連携されます。
• 再起動には様々なレベルがあります – REBOOT_WARM、REBOOT_COLD、REBOOT_HARD – これらはカーネルにコマンドライン引数として渡すことができます（例：ample、reboot=w[arm]はREBOOT_WARM用です。Linuxカーネルソースコードの詳細については、 ドキュメント/管理者ガイド/カーネルパラメータ.txt.
• あるいは、/sys/kernel/reboot が有効になっている場合は、その下のハンドラを読み取って現在のシステム再起動設定を取得し、書き込んで変更することができます。Linux カーネルのソースコードの詳細については、以下を参照してください。 ドキュメント/ABI/テスト/sysfs-kernel-reboot.

ウォッチ・ドッグス

• システムの起動と再起動に関連するもう 1 つの概念は、ウォッチドッグ タイマーの起動によるシステムの回復です。ウォッチドッグ タイマーは、一時的なハードウェア障害から自動的に回復し、誤ったソフトウェアや悪意のあるソフトウェアがシステムの動作を妨害するのを防ぐために、組み込みシステムで広く使用されています。
• PIC64GX には、システムの実行中に個々のハートを監視するためのハードウェア ウォッチドッグ サポートが含まれています。ウォッチドッグは、回復不可能なソフトウェア エラーが原因でハートが応答しない場合に、ハートを再起動できるようにします。
• PIC64GXには、システムのロックアップを検出するために使用するウォッチドッグタイマーハードウェアブロックのインスタンスがXNUMXつ含まれており、各ハートにXNUMXつずつあります。混合非対称マルチプロセッシング（AMP) ワークロードでは、HSS はウォッチドッグの起動の監視と対応をサポートします。

PIC64GX ウォッチドッグ

• HSSは、電源投入時にアプリケーションハートを起動し、任意のタイミングで（個別または一括して）再起動する役割を担っています。tagつまり、必要または希望する場合です。この結果、PIC64GX 上のウォッチドッグ イベントへの反応は HSS によって処理されます。
• 「仮想ウォッチドッグ」モニターは HSS ステート マシン サービスとして実装され、その役割は U54 の個々のウォッチドッグ ハードウェア モニターのステータスを監視することです。これらの U54 ウォッチドッグの 54 つがトリップすると、HSS はこれを検出し、必要に応じて U54 を再起動します。UXNUMX が SMP コンテキストの一部である場合、コンテキストにウォーム リブート権限があれば、コンテキスト全体が再起動の対象となります。コンテキストにコールド リブート権限がある場合は、システム全体が再起動されます。

関連するKconfigオプション

• ウォッチドッグ サポートは、リリースされた HSS ビルドにデフォルトで含まれています。カスタム HSS をビルドする場合、このセクションでは、ウォッチドッグ サポートが有効になっていることを確認するための構成メカニズムについて説明します。
• HSSはKconfig構成システムを使用して構成されます。トップレベルの.config file HSS ビルドにコンパイルされるサービスまたは HSS ビルドからコンパイルされないサービスを選択するために必要です。
• まず、最上位の CONFIG_SERVICE_WDOG オプションを有効にする必要があります (make config による「仮想ウォッチドッグ サポート」)。

これにより、Watchdog サポートに依存する次のサブオプションが公開されます。

• CONFIG_SERVICE_WD OG_DEBUG
  仮想ウォッチドッグ サービスからの情報/デバッグ メッセージのサポートを有効にします。
• CONFIG_SERVICE_WD OG_DEBUG_TIMEOUT_SECS
  HSS によってウォッチドッグ デバッグ メッセージが出力される周期 (秒単位) を決定します。
• CONFIG_SERVICE_WD OG_ENABLE_E51
  U51 に加えて E54 モニターのウォッチドッグを有効にし、HSS 自体の動作を保護します。

E51 ウォッチドッグが有効になっている場合、HSS は定期的にウォッチドッグに書き込み、ウォッチドッグを更新して起動を防止します。何らかの理由で E51 ハートがロックまたはクラッシュし、E51 ウォッチドッグが有効になっている場合、常にシステム全体がリセットされます。

ウォッチドッグ作戦
ウォッチドッグ ハードウェアはダウン カウンターを実装します。ウォッチドッグのリフレッシュが許可される最大値 (MVRP) を設定することで、リフレッシュ禁止ウィンドウを作成できます。

• ウォッチドッグ タイマーの現在の値が MVRP 値より大きい場合、ウォッチドッグのリフレッシュは禁止されます。禁止されたウィンドウでウォッチドッグ タイマーをリフレッシュしようとすると、タイムアウト割り込みがアサートされます。
• MVRP 値とトリガー値 (TRIG) の間でウォッチドッグを更新すると、カウンターが正常に更新され、ウォッチドッグが起動するのを防ぐことができます。
• ウォッチドッグ タイマー値が TRIG 値を下回ると、ウォッチドッグが起動します。

ウォッチドッグステートマシン

• ウォッチドッグ ステート マシンは非常に単純です。E51 のウォッチドッグが有効な場合は設定して起動し、アイドル状態から監視状態に移行します。スーパーループを一周するたびに、この監視状態が呼び出され、各 U54 ウォッチドッグの状態がチェックされます。
• ウォッチドッグ ステート マシンは、ハートがウォッチドッグを時間内に更新できなかったことを検出すると、ブート ステート マシンと対話してハート (およびそのブート セット内にある他のハート) を再起動します。

ロックダウンモード

通常（特に AMP アプリケーションでは、HSS が U54 上で M モードで常駐し、コンテキストごとの再起動 (つまり、チップ全体の再起動なしで XNUMX つのコンテキストのみを再起動) を可能にし、HSS が状態 (ECC、ロック ステータス ビット、バス エラー、SBI エラー、PMP 違反など) を監視できるようになることが期待されます。

• 再起動機能を提供するため、AMP コンテキスト ベースで (システム全体を再起動する必要なく)、E51 は通常、システムのメモリ空間全体への特権メモリ アクセスを持ちます。ただし、これが望ましくない状況もあり、システムが正常に起動した後、E51 HSS ファームウェアの動作を制限することをお客様が希望する場合があります。この場合、U54 アプリケーション ハートが起動したら、HSS をロックダウン モードにすることができます。
• これは、HSS Kconfig オプション CONFIG_SERVICE_LOCKDOWN を使用して有効にできます。
• ロックダウン サービスは、U54 アプリケーション Harts を起動した後、HSS のアクティビティを制限できるようにすることを目的としています。

図4.2 HSSロックダウンモード

ロックダウン モードが開始すると、他のすべての HSS サービス ステート マシンの実行が停止されます。2 つの弱結合関数が呼び出されます。

• e51_pmp_lockdown()、および
• e51_ロックダウン()

これらの関数は、ボード固有のコードによってオーバーライドされるように設計されています。51 つ目は、この時点で BSP が E51 をアプリケーション ペイロードからロックアウトするようにカスタマイズできるようにする構成可能なトリガー関数です。この関数の弱くバインドされたデフォルトの実装は空です。54 つ目は、その時点から実行される機能です。弱くバインドされたデフォルトの実装は、EXNUMX のこの時点でウォッチドッグにサービスを提供し、UXNUMX ウォッチドッグが起動すると再起動します。詳細については、services/lockdown/lockdown_service.c の HSS ソース コードを参照してください。 file.

付録

HSS payload.bin 形式

• このセクションではpayload.binについて説明します file HSSがPIC64GX SMPを起動するために使用するフォーマットとイメージ AMP アプリケーション。
• payload.bin はフォーマットされたバイナリ (図 A.10) で、ヘッド、さまざまな記述子テーブル、およびアプリケーション ワークロードの各部分のコードとデータ セクションを含むさまざまなチャンクで構成されています。チャンクは、任意のサイズの連続したメモリ ブロックと考えることができます。

図A.10. payload.binフォーマット

ヘッダー部分（図A.11参照）には、payload.binを識別するためのマジック値といくつかのハウスキーピング情報、および各デバイスで実行されるイメージの詳細が含まれています。
U54 アプリケーション コード。個々の U54 ハートの起動方法と、起動可能なイメージのセット全体を記述します。ハウスキーピング情報には、ヘッダー サイズを拡張できるように、さまざまな記述子のテーブルへのポインターが含まれています。

図A.11. payload.binヘッダー

• コードと初期化された定数データは読み取り専用と見なされ、ヘッダー記述子によって指される読み取り専用セクションに格納されます。
• ゼロ以外の初期化データ変数は読み取り/書き込みデータですが、起動時に読み取り専用チャンクから初期化値がコピーされます。これらも読み取り専用セクションに保存されます。
• 読み取り専用のペイロードデータセクションは、コードとデータのチャンク記述子のテーブルによって記述されます。このテーブルの各チャンク記述子には、「ハート所有者」（ターゲットとなるコンテキスト内のメインハート）が含まれます。
  これには、ロード オフセット (payload.bin 内のオフセット)、実行アドレス (PIC64GX メモリ内の宛先アドレス)、およびサイズとチェックサムが含まれます。これは図 A.12 に示されています。

図 A.12. 読み取り専用チャンク記述子とペイロードチャンクデータ

前述のチャンクに加えて、ゼロに初期化されるデータ変数に対応するメモリ チャンクもあります。これらは payload.bin にデータとして保存されるのではなく、起動時にゼロに設定する RAM のアドレスと長さを指定する、ゼロで初期化された特別なチャンク ディスクリプタのセットです。これは図 A.13 に示されています。

図A.13. ZIチャンク

hss ペイロード ジェネレーター
HSSペイロードジェネレータツールは、Hart Software Serviceゼロs用のフォーマットされたペイロードイメージを作成します。tagPIC64GXのブートローダー、設定が与えられている file ELFのセット filesおよび/またはバイナリ。構成 file ELF バイナリまたはバイナリ BLOB を個々のアプリケーション ハート (U54) にマッピングするために使用されます。

図 B.14. hss-payload-generator フロー

このツールは構成の構造について基本的な健全性チェックを実行します。 file 自身と ELF イメージの両方に適用されます。ELF イメージは RISC-V 実行可能ファイルである必要があります。

Exampルラン

• hss-payload-generatorツールをsで実行するにはampファイル構成 file とELF files:
  $ ./hss-payload-generator -c test/config.yaml 出力.bin
• 既存のイメージに関する診断を印刷するには、次のコマンドを使用します。
  $ ./hss-ペイロードジェネレータ -d 出力.bin
• セキュア ブート認証 (イメージ署名経由) を有効にするには、-p を使用して、楕円曲線 P-509 (SECP384r384) の X.1 秘密キーの場所を指定します。
  $ ./hss-payload-generator -c test/config.yaml ペイロード.bin -p /path/to/private.pem

詳細については、セキュア ブート認証のドキュメントを参照してください。

設定 File Example

• まず、オプションでイメージの名前を設定できます。設定しない場合は、動的に作成されます。
  セット名: 'PIC64-HSS::TestImage'
• 次に、各ハートのエントリ ポイント アドレスを次のように定義します。
  hart-entry-points: {u54_1: ‘0x80200000’, u54_2: ‘0x80200000’, u54_3: ‘0xB0000000′, u54_4:’0x80200000’}

ELFソースイメージはエントリポイントを指定できますが、必要に応じてハートのセカンダリエントリポイントをサポートできるようにしたいと考えています。たとえば、amp複数のハートが同じイメージを起動することを意図している場合、それらは個別のエントリポイントを持つ可能性があります。これをサポートするために、構成で実際のエントリポイントアドレスを指定します。 file 自体。

ペイロード（ソースELF）を定義できるようになりました fileペイロードセクションは、キーワードpayloadsと、それに続くいくつかの個別のペイロード記述子で定義されます。各ペイロードには名前（そのペイロードへのパス）があります。 file）、オーナーハート、およびオプションで 1 ～ 3 個のセカンダリハート。

さらに、ペイロードには実行を開始する特権モードがあります。有効な特権モードは PRV_M、PRV_S、および PRV_U で、次のように定義されます。

• PRV_M マシンモード
• PRV_S スーパーバイザーモード
• PRV_U ユーザーモード

次の例ではamp上：

• test/zephyr.elf は、U54_3 で実行され、PRV_M 特権モードで起動する Zephyr アプリケーションであると想定されています。
• test/u-boot-dtb.bin は Das U-Boot ブートローダ アプリケーションであり、U54_1、U54_2、および U54_4 で実行されます。PRV_S 特権モードで起動することを想定しています。

重要：
U-Bootの出力はELFを作成する fileただし、通常は .elf 拡張子は付加されません。この場合、CONFIG_OF_SEPARATE によって作成されたバイナリが使用され、デバイス ツリー ブロブが U-Boot バイナリに追加されます。

これが元ampペイロード構成 file:

• テスト/zephyr.elf:
  {exec-addr: '0xB0000000'、所有者ハート: u54_3、特権モード: prv_m、opensbi スキップ: true}
• テスト/u-boot-dtb.bin:
  {exec-addr: '0x80200000'、所有者ハート: u54_1、セカンダリハート: u54_2、セカンダリハート: u54_4、priv-mode: prv_s}

重要：
ケースは、 file キーワードではなくパス名です。たとえば、u54_1 は U54_1 と同じとみなされ、exec-addr は EXEC-ADDR と同じとみなされます。.elf または .bin 拡張子が存在する場合は、構成に含める必要があります。 file.

• OpenSBIを気にしたくないベアメタルアプリケーションの場合、オプションskip-opensがtrueの場合、そのハートのペイロードは単純なmretを使用して呼び出されます。
  OpenSBI sbi_init() 呼び出しよりも高速です。つまり、心臓は OpenSBI HSM の考慮に関係なくベアメタルコードの実行を開始します。これは、心臓が使用できないことも意味します。
  OpenSBI 機能を呼び出すために ecalls を使用します。skip-opens オプションはオプションであり、デフォルトは false です。
• 別のコンテキストのコンテキスト ウォーム リブートを許可するには、オプション allow reboot: warm を追加します。システム全体のコンテキスト コールド リブートを許可するには、オプション allow-reboot: cold を追加します。デフォルトでは、allow-reboot を指定しないと、コンテキストは自身のウォーム リブートのみ許可されます。
• 各ペイロードに補助データを関連付けることも可能である。例えば、ample、DeviceTree Blob (DTB) file補助データを指定して file次のように名前を付けます。
  test/u-boot.bin: { exec-addr: '0x80200000'、所有者ハート: u54_1、セカンダリハート: u54_2、セカンダリハート: u54_3、セカンダリハート: u54_4、特権モード: prv_s、補助データ: test/pic64gx.dtb }
• この補助データはペイロード（メインデータの直後に配置される）に含まれます。 file 実行ファイル内
  スペースに格納され、そのアドレスは next_arg1 フィールド (起動時にイメージの $a1 レジスタに渡される) で OpenSBI に渡されます。
• HSS がコンテキストを自動的に起動しないようにするには (たとえば、代わりに remoteProc を使用してコンテキストに制御を委任する場合)、skip-autoboot フラグを使用します。
  test/zephyr.elf: {exec-addr: '0xB0000000'、所有者ハート: u54_3、特権モード: prv_m、opensbi のスキップ: true、自動ブートのスキップ: true}
• 最後に、payload-nameオプションを使用して、個々のペイロードの名前を上書きすることもできます。例：amp上：
  test/u-boot.bin: { exec-addr: '0x80200000'、所有者ハート: u54_1、セカンダリハート: u54_2、セカンダリハート: u54_3、セカンダリハート: u54_4、特権モード: prv_s、補助データ: test/pic64gx.dtb、ペイロード名: 'u-boot' }

YoctoおよびBuildroot Linuxビルダーはhss-payload-をビルド、構成、実行します。
アプリケーションイメージを生成するために必要に応じてジェネレータを使用します。さらに、pic64gx-curiosity-kit-amp Yoctoのマシンターゲットは、hss-payload-generatorツールを使用してアプリケーションイメージを生成します。 AMPLinux は 3 つのハートで実行され、Zephyr は 1 つのハートで実行されます。

改訂履歴
改訂履歴には、ドキュメントに実装された変更内容が記述されます。変更内容は、最新の出版物から順に改訂順にリストされます。

リビジョン	日付	説明
A	07/2024	初期改訂

マイクロチップ情報

マイクロチップ Webサイト
マイクロチップは、 webサイト www.microchip.com/。 これ webサイトは file顧客が簡単に利用できる情報を提供します。 利用可能なコンテンツには次のようなものがあります。

• 製品サポート –データセットと正誤表、アプリケーションノートとampleプログラム、設計リソース、ユーザーガイド、ハードウェアサポートドキュメント、最新のソフトウェアリリース、アーカイブされたソフトウェア
• 一般的なテクニカルサポート –よくある質問（FAQ）、テクニカルサポートリクエスト、オンラインディスカッショングループ、マイクロチップデザインパートナープログラムのメンバーリスト
• マイクロチップの事業 – 製品セレクターと注文ガイド、最新のマイクロチップのプレスリリース、セミナーとイベントのリスト、マイクロチップの営業所、販売代理店、工場担当者のリスト

製品変更通知サービス

• マイクロチップの製品変更通知サービスは、マイクロチップ製品の最新情報を顧客に提供するのに役立ちます。 サブスクライバーは、特定の製品ファミリまたは対象の開発ツールに関連する変更、更新、改訂、または正誤表があるたびに電子メール通知を受け取ります。
• 登録するには、 www.microchip.com/pcn 登録手順に従ってください。

カスタマーサポート
Microchip 製品のユーザーは、いくつかのチャネルを通じてサポートを受けることができます。

• 販売代理店または代理店
• 現地営業所
• エンベデッドソリューションエンジニア（ESE）
• テクニカルサポート

お客様は、販売代理店、担当者、またはESEにサポートを依頼する必要があります。 地元の営業所もお客様をサポ​​ートするために利用できます。 このドキュメントには、営業所と場所のリストが含まれています。
テクニカルサポートは、 webサイト: サポート.

マイクロチップデバイスのコード保護機能
Microchip 製品のコード保護機能に関する次の詳細に注意してください。

• Microchip 製品は、それぞれの Microchip データ シートに記載されている仕様を満たしています。
• Microchip 社は、意図された方法で、動作仕様の範囲内で、通常の条件下で使用される場合、同社の製品ファミリは安全であると考えています。
• Microchip 社は知的財産権を重視し、積極的に保護しています。Microchip 社の製品のコード保護機能を侵害する行為は固く禁じられており、デジタル ミレニアム著作権法に違反する可能性があります。
• Microchip 社も他の半導体メーカーも、自社のコードのセキュリティを保証することはできません。コード保護は、製品が「破られない」ことを保証するものではありません。コード保護は常に進化しています。Microchip 社は、自社製品のコード保護機能を継続的に改善することに尽力しています。

法的通知
この出版物およびここに記載されている情報は、マイクロチップ製品の設計、テスト、およびお客様のアプリケーションとの統合を含め、マイクロチップ製品でのみ使用できます。 この情報を他の方法で使用することは、これらの規約に違反します。 デバイス アプリケーションに関する情報は、お客様の利便性を目的としてのみ提供されており、アップデートによって置き換えられる場合があります。 アプリケーションが仕様を満たしていることを確認するのはあなたの責任です。 追加のサポートについては、最寄りの Microchip 営業所にお問い合わせいただくか、次の URL で追加サポートを入手してください。 www.microchip.com/en-us/support/design-help/client-support-services.

この情報はマイクロチップによって「現状のまま」提供されます。マイクロチップは、明示的か黙示的か、書面か口頭か、法定かその他かを問わず、情報に関連するいかなる種類の表明または保証も行いません。これには、非侵害、商品性、特定目的への適合性に関する黙示の保証、またはその状態、品質、性能に関する保証が含まれますが、これらに限定されません。

いかなる場合においても、マイクロチップは、情報またはその使用に関連して生じたいかなる間接的、特別、懲罰的、付随的、結果的損失、損害、費用、または出費について、たとえマイクロチップが次のことについて知らされていたとしても、一切の責任を負いません。可能性または損害が予見可能である場合。法律で認められる最大限の範囲で、情報またはその使用に関連するあらゆる請求に対する MICROCHIP の総責任は、お客様がその情報に対して MICROCHIP に直接支払った料金（ある場合）を超えないものとします。

Microchip 社のデバイスを生命維持および/または安全アプリケーションで使用する場合のリスクはすべて購入者の責任であり、購入者は、そのような使用から生じるすべての損害、請求、訴訟、または費用から Microchip 社を防御し、補償し、免責することに同意するものとします。特に明記されていない限り、Microchip 社の知的財産権に基づくライセンスは、暗黙的またはその他の方法で譲渡されることはありません。

商標
Microchip の名前とロゴ、Microchip ロゴ、Adaptec、AVR、AVR ロゴ、AVR Freaks、BesTime、BitCloud、CryptoMemory、CryptoRF、dsPIC、flexPWR、HELDO、IGLOO、JukeBlox、KeeLoq、Kleer、LANCheck、LinkMD、maXStylus、maXTouch、 MediaLB、megaAVR、Microsemi、Microsemi ロゴ、MOST、MOST ロゴ、MPLAB、OptoLyzer、PIC、picoPower、PICSTART、PIC32 ロゴ、PolarFire、Prochip Designer、QTouch、SAM-BA、SenGenuity、SpyNIC、SST、SST ロゴ、SuperFlash、Symmetricom 、SyncServer、Tachyon、TimeSource、tinyAVR、UNI/O、Vectron、および XMEGA は、米国およびその他の国における Microchip Technology Incorporated の登録商標です。

AgileSwitch、ClockWorks、The Embedded Control Solutions Company、EtherSynch、Flashtec、Hyper Speed Control、HyperLight Load、Libero、モーターベンチ、mTouch、Powermite 3、Precision Edge、ProASIC、ProASIC Plus、ProASIC Plus ロゴ、Quiet-Wire、SmartFusion、SyncWorld 、TimeCesium、TimeHub、TimePictra、TimeProvider、および ZL は、米国 Microchip Technology Incorporated の登録商標です。

隣接キー抑制、AKS、デジタル時代のアナログ、Any Capacitor、AnyIn、AnyOut、拡張スイッチング、BlueSky、BodyCom、Clockstudio、CodeGuard、CryptoAuthentication、CryptoAutomotive、CryptoCompanion、CryptoController、dsPICDEM、dsPICDEM.net、動的平均マッチング、DAM、ECAN、Espresso T1S、EtherGREEN、EyeOpen、GridTime、IdealBridge、
IGaT、インサーキット シリアル プログラミング、ICSP、INICnet、インテリジェント パラレル化、IntelliMOS、チップ間接続、JitterBlocker、ノブ オン ディスプレイ、MarginLink、maxCrypto、maxView、memBrain、Mindi、MiWi、MPASM、MPF、MPLAB 認定ロゴ、MPLIB、MPLINK、mSiC、MultiTRAK、NetDetach、Omniscient Code Generation、PICDEM、PICDEM.net、PICkit、PICtail、Power MOS IV、Power MOS 7、PowerSmart、PureSilicon、QMatrix、REAL ICE、Ripple Blocker、RTAX、RTG4、SAM-ICE、Serial Quad I/O、シンプル マップ、SimpliPHY、SmartBuffer、SmartHLS、SMART-IS、storClad、SQI、SuperSwitcher、SuperSwitcher II、Switchtec、SynchroPHY、Total Endurance、Trusted Time、TSHARC、Turing、USBCheck、VariSense、VectorBlox、VeriPHY、 ViewSpan、WiperLock、XpressConnect、ZENA は、米国およびその他の国における Microchip Technology Incorporated の商標です。

• SQTPは米国Microchip Technology Incorporatedのサービスマークです。
• Adaptecのロゴ、Frequency on Demand、Silicon Storage Technology、およびSymmcomは、他の国におけるMicrochipTechnologyInc.の登録商標です。
• GestIC は、Microchip Technology Inc. の子会社である Microchip Technology Germany II GmbH & Co. KG の他の国における登録商標です。

ここに記載されているその他すべての商標は、それぞれの会社の財産です。© 2024、Microchip Technology Incorporated およびその子会社。無断複写・転載を禁じます。

• 品番: 978-1-6683-4890-1

品質管理システム
マイクロチップの品質管理システムの詳細については、 www.microchip.com/quality.

世界的な販売とサービス

アメリカ大陸	アジア太平洋	アジア太平洋	ヨーロッパ
企業 オフィス 2355 West Chandler Blvd. チャンドラー、アリゾナ州 85224-6199 電話: 480-792-7200 ファックス： 480-792-7277 テクニカルサポート： サポート Web 住所： マイクロチップ アトランタ ジョージア州ダルース 電話: 678-957-9614 ファックス： 678-957-1455 オースティン、テキサス州 電話: 512-257-3370 ボストン マサチューセッツ州ウェストボロ 電話: 774-760-0087 ファックス： 774-760-0088 シカゴ イリノイ州イタスカ 電話: 630-285-0071 ファックス： 630-285-0075 ダラス アディソン、テキサス州 電話: 972-818-7423 ファックス： 972-818-2924 デトロイト ミシガン州ノバイ 電話: 248-848-4000 ヒューストン、 TX 電話: 281-894-5983 インディアナポリス インディアナ州ノーブルズビル 電話番号: 317-773-8323 ファックス： 317-773-5453 電話: 317-536-2380 ロサンゼルス カリフォルニア州ミッションビエホ 電話: 949-462-9523 ファックス： 949-462-9608 電話: 951-273-7800 ローリー、 NC 電話: 919-844-7510 ニューヨーク、ニューヨーク州 電話: 631-435-6000 サン ホセ、 CA 電話: 408-735-9110 電話: 408-436-4270 カナダ – トロント 電話: 905-695-1980 ファックス： 905-695-2078	オーストラリア – シドニー 電話: 61-2-9868-6733 中国 – 北京 電話: 86-10-8569-7000 中国–成都 電話: 86-28-8665-5511 中国 – 重慶 電話: 86-23-8980-9588 中国–東莞 電話: 86-769-8702-9880 中国 – 広州 電話: 86-20-8755-8029 中国–杭州 電話: 86-571-8792-8115 中国 – ホン コング ロシア 電話: 852-2943-5100 中国–南京 電話: 86-25-8473-2460 中国–青島 電話: 86-532-8502-7355 中国 – 上海 電話: 86-21-3326-8000 中国–瀋陽 電話: 86-24-2334-2829 中国–深セン 電話: 86-755-8864-2200 中国–蘇州 電話: 86-186-6233-1526 中国–武漢 電話: 86-27-5980-5300 中国–西安 電話: 86-29-8833-7252 中国–厦門 電話: 86-592-2388138 中国–朱海 電話: 86-756-3210040	インド – バンガロール 電話: 91-80-3090-4444 インド–ニューデリー 電話: 91-11-4160-8631 インド – プネ 電話: 91-20-4121-0141 日本 – 大阪 電話: 81-6-6152-7160 日本 – 東京 Tel：81-3-6880-3770 韓国–大邱 電話: 82-53-744-4301 韓国–ソウル 電話: 82-2-554-7200 マレーシア – クアラ ルンプール 電話: 60-3-7651-7906 マレーシア–ペナン 電話: 60-4-227-8870 フィリピン – マニラ 電話: 63-2-634-9065 シンガポール 電話: 65-6334-8870 台湾 – シン・チュー 電話: 886-3-577-8366 台湾–高雄 電話: 886-7-213-7830 台湾–台北 電話: 886-2-2508-8600 タイ – バンコク 電話: 66-2-694-1351 ベトナム–ホーチミン 電話: 84-28-5448-2100	オーストリア – ヴェルス 電話: 43-7242-2244-39 ファックス: 43-7242-2244-393 デンマーク – コペンハーゲン 電話: 45-4485-5910 ファックス: 45-4485-2829 フィンランド – エスポー 電話: 358-9-4520-820 フランス – パリ Tel: 33-1-69-53-63-20 Fax: 33-1-69-30-90-79 ドイツ – ガーチング 電話: 49-8931-9700 ドイツ – ハーン 電話: 49-2129-3766400 ドイツ – ハイルブロン 電話: 49-7131-72400 ドイツ – カールスルーエ 電話: 49-721-625370 ドイツ – ミュンヘン Tel: 49-89-627-144-0 Fax: 49-89-627-144-44 ドイツ – ローゼンハイム 電話: 49-8031-354-560 イスラエル – ホド・ハシャロン 電話: 972-9-775-5100 イタリア–ミラノ 電話: 39-0331-742611 ファックス: 39-0331-466781 イタリア–パドヴァ 電話: 39-049-7625286 オランダ– Drunen 電話: 31-416-690399 ファックス: 31-416-690340 ノルウェー – トロンハイム 電話: 47-72884388 ポーランド – ワルシャワ 電話: 48-22-3325737 ルーマニア – ブカレスト Tel: 40-21-407-87-50 スペイン–マドリード Tel: 34-91-708-08-90 Fax: 34-91-708-08-91 スウェーデン – ヨーテボリ Tel: 46-31-704-60-40 スウェーデン – ストックホルム 電話: 46-8-5090-4654 英国–ウォーキンガム 電話: 44-118-921-5800 ファックス: 44-118-921-5820

© 2024 Microchip Technology Inc. およびその子会社。

ドキュメント / リソース

MICROCHIP PIC64GX 64 ビット RISC-V クアッドコア マイクロプロセッサ [pdf] ユーザーガイド PIC64GX、PIC64GX 64 ビット RISC-V クアッドコア マイクロプロセッサ、64 ビット RISC-V クアッドコア マイクロプロセッサ、RISC-V クアッドコア マイクロプロセッサ、クアッドコア マイクロプロセッサ、マイクロプロセッサ

参考文献

• ユーザーマニュアル