Bootgen ユーザーガイド - Xilinx

Bootgen ユーザーガイドUG1283 (v2020.2) 2020 年 12 月 15 日

この資料は表記のバージョンの英語版を翻訳したもので、内容に相違が生じる場合には原文を優先します。資料によっては英語版の更新に対応していないものがあります。日本語版は参考用としてご使用の上、最新情報につきましては、必ず最新英語版をご参照ください。

すべてのバージョンを表示

https://www.xilinx.com

https://japan.xilinx.com/bin/public/docSeeAllVersions?productType=DesignTools&documentId=UG1283

目次改訂履歴..........................................................................................................................................................................6

第 1 章: 概要................................................................................................................................................................. 7この資料に関連する設計プロセス................................................................................................................................. 7Bootgen のインストール............................................................................................................................................... 8ブート時のセキュリティ................................................................................................................................................ 8

第 2 章: ブートイメージレイアウト........................................................................................................ 9Zynq-7000 SoC のブートおよびコンフィギュレーション ........................................................................................... 9Zynq UltraScale+ MPSoC のブートおよびコンフィギュレーション ........................................................................ 18Versal ACAP ブートイメージの形式...........................................................................................................................30

第 3 章: ブートイメージの作成................................................................................................................. 43ブートイメージフォーマット (BIF)........................................................................................................................... 43BIF 構文およびサポートされるファイルの種類..........................................................................................................44属性................................................................................................................................................................................48

第 4 章: Bootgen インターフェイスの使用...................................................................................... 59Bootgen GUI のオプション......................................................................................................................................... 59コマンドラインで Bootgen を使用............................................................................................................................ 60コマンドおよび説明......................................................................................................................................................60

第 5 章: ブート時のセキュリティ ............................................................................................................. 65暗号化の使用.................................................................................................................................................................66認証の使用.....................................................................................................................................................................76HSM モードの使用........................................................................................................................................................88

第 6 章: FPGA のサポート.............................................................................................................................. 116暗号化および認証....................................................................................................................................................... 116HSM モード.................................................................................................................................................................117

第 7 章: ユースケースおよび例.................................................................................................................120Zynq MPSoC ユースケース.......................................................................................................................................120Versal ACAP のユースケース.................................................................................................................................... 129

第 8 章: BIF 属性のリファレンス............................................................................................................ 140aarch32_mode............................................................................................................................................................140aeskeyfile....................................................................................................................................................................141

UG1283 (v2020.2) 2020 年 12 月 15 日 japan.xilinx.comBootgen ユーザーガイド 2

https://japan.xilinx.com

https://japan.xilinx.com/about/feedback/document-feedback.html?docType=User_Guides&docId=UG1283&Title=Bootgen%20%26%2312518%3B%26%2312540%3B%26%2312470%3B%26%2312540%3B%20%26%2312460%3B%26%2312452%3B%26%2312489%3B&releaseVersion=2020.2&docPage=2

a_hwrot....................................................................................................................................................................... 144alignment................................................................................................................................................................... 144auth_params.............................................................................................................................................................. 145authentication............................................................................................................................................................147big_endian.................................................................................................................................................................. 148bbram_kek_iv............................................................................................................................................................. 149bh_kek_iv.....................................................................................................................................................................150bh_keyfile....................................................................................................................................................................150bh_key_iv.....................................................................................................................................................................151bhsignature................................................................................................................................................................152blocks.......................................................................................................................................................................... 152boot_device................................................................................................................................................................ 154bootimage.................................................................................................................................................................. 156bootloader..................................................................................................................................................................158bootvectors................................................................................................................................................................ 159boot_config.................................................................................................................................................................159checksum....................................................................................................................................................................160copy.............................................................................................................................................................................161core............................................................................................................................................................................. 161delay_handoff............................................................................................................................................................ 162delay_load...................................................................................................................................................................163destination_cpu......................................................................................................................................................... 163destination_device.....................................................................................................................................................164early_handoff............................................................................................................................................................. 165efuse_kek_iv................................................................................................................................................................165efuse_user_kek0_iv.................................................................................................................................................... 166efuse_user_kek1_iv.................................................................................................................................................... 166encryption.................................................................................................................................................................. 166exception_level...........................................................................................................................................................168familykey.................................................................................................................................................................... 169file................................................................................................................................................................................170fsbl_config.................................................................................................................................................................. 170headersignature........................................................................................................................................................ 171hivec............................................................................................................................................................................ 172id..................................................................................................................................................................................173image.......................................................................................................................................................................... 174init................................................................................................................................................................................174keysrc.......................................................................................................................................................................... 175keysrc_encryption......................................................................................................................................................176load............................................................................................................................................................................. 177metaheader................................................................................................................................................................178name........................................................................................................................................................................... 179offset........................................................................................................................................................................... 179parent_id.....................................................................................................................................................................180partition...................................................................................................................................................................... 181partition_owner、owner...........................................................................................................................................182partition_type.............................................................................................................................................................183




pid................................................................................................................................................................................184pmufw_image............................................................................................................................................................ 184ppkfile......................................................................................................................................................................... 185presign........................................................................................................................................................................186pskfile..........................................................................................................................................................................186puf_file........................................................................................................................................................................ 187reserve........................................................................................................................................................................ 188s_hwrot....................................................................................................................................................................... 189split..............................................................................................................................................................................190spkfile..........................................................................................................................................................................191spksignature.............................................................................................................................................................. 192spk_select................................................................................................................................................................... 193sskfile.......................................................................................................................................................................... 194startup........................................................................................................................................................................ 195TrustZone................................................................................................................................................................... 196type............................................................................................................................................................................. 197udf_bh......................................................................................................................................................................... 197udf_data......................................................................................................................................................................198xip_mode.................................................................................................................................................................... 199

第 9 章: コマンドリファレンス............................................................................................................... 200arch............................................................................................................................................................................. 200authenticatedjtag...................................................................................................................................................... 200bif_help....................................................................................................................................................................... 201dual_ospi_mode......................................................................................................................................................... 201dual_qspi_mode.........................................................................................................................................................202dump...........................................................................................................................................................................202dump_dir.................................................................................................................................................................... 203efuseppkbits...............................................................................................................................................................203encrypt........................................................................................................................................................................204encryption_dump...................................................................................................................................................... 204fill................................................................................................................................................................................. 205generate_hashes....................................................................................................................................................... 205generate_keys............................................................................................................................................................ 206h、help....................................................................................................................................................................... 207image.......................................................................................................................................................................... 207log................................................................................................................................................................................208nonbooting.................................................................................................................................................................209o...................................................................................................................................................................................209p...................................................................................................................................................................................210padimageheader....................................................................................................................................................... 210process_bitstream..................................................................................................................................................... 211read............................................................................................................................................................................. 211spksignature.............................................................................................................................................................. 212split..............................................................................................................................................................................212verify........................................................................................................................................................................... 213verify_kdf.................................................................................................................................................................... 213




w.................................................................................................................................................................................. 214zynqmpes1................................................................................................................................................................. 214

第 10 章: 初期化ペアおよび INIT ファイルの属性...................................................................... 215

第 11 章: CDO ユーティリティ .................................................................................................................. 216アクセス...................................................................................................................................................................... 216使用法..........................................................................................................................................................................216例................................................................................................................................................................................. 217

第 12 章: Bootgen ユーティリティ ........................................................................................................ 219

付録 A: その他のリソースおよび法的通知........................................................................................221Documentation Navigator およびデザインハブ.................................................................................................... 221ザイリンクスリソース...............................................................................................................................................221その他のリソース....................................................................................................................................................... 221お読みください: 重要な法的通知...............................................................................................................................222




改訂履歴次の表に、この文書の改訂履歴を示します。

セクション改訂内容2020 年 12 月 15 日バージョン 2020.2

Versal 認証サポートマイナーな修正。2020 年 11 月 24 日バージョン 2020.2

資料全体グレー/難読化キーは、Versal™ デバイスでは廃止予定。authenticatedjtag securedebugimage を authenticatedjtag コマンドに置換。HSM を使用した Versal デバイスブートイメージの作成新しいセクションを追加。a_hwrot および s_hwrot 新規属性。資料全体 BIF コードの新しい例を追加。既存 PDI への新規パーティションの追加手順をアップデート。既存 PDI での PLM の置換手順をアップデート。

2020 年 6 月 3 日バージョン 2020.1

資料全体マイナーな編集上の変更。NIST SHA-3 のサポート認証署名の表をアップデート。HSM モードを使用した Zynq-7000 SoC デバイスブートイメージの作成セクションをアップデート。

オフセット属性を使用した分割新しいセクションを追加。aeskeyfile セクションをアップデート。

2019 年 10 月 30 日バージョン 2019.2

資料全体マイナーな編集上の変更。第 2 章 Zynq UltraScale+ MPSoC セキュアヘッダーが追加されています。第 5 章 HSM モードを使用した Zynq-7000 SoC デバイスブートイメージの作成を更新。付録 B 次の属性を追加:

• aarch32_mode

• big_endian

付録 C verify_kdf コマンドを追加。HSM モードの使用ステージ 0 エレメントに PPK 入力を追加

2019 年 5 月 22 日バージョン 2019.1

資料全体マイナーな編集上の変更。

改訂履歴




第 1 章

概要ザイリンクス FPGA およびシステムオンチップ (SoC) デバイス、ACAP (Adaptive Compute Acceleration Platform) には、設計どおりにブートおよび機能するようにするため、通常複数のハードウェアおよびソフトウェアバイナリが含まれます。これらのバイナリには、FPGA ビットストリーム、ファームウェアイメージ、ブートローダー、オペレーティングシステム、およびユーザー指定のアプリケーションが含まれ、非セキュアな方法とセキュアな方法の両方でロード可能です。Bootgen は、バイナリファイルを統合してデバイスブートイメージを生成するザイリンクスツールです。このツールは、ザイリンクスデバイスで使用するブートイメージの作成時に入力される複数のプロパティ、属性、およびパラメーターを定義します。ザイリンクスデバイスのセキュアブート機能には、公開キーおよび秘密キーの暗号化アルゴリズムを使用します。Bootgen は、各パーティションに特定のデスティネーションメモリアドレスとアライメント要件を指定します。また、暗号化の使用および認証の使用で説明するように、暗号化と認証もサポートされます。より高度な認証フローとキー管理オプションについては、HSM モードの使用で説明されています。HSM モードでは、Bootgen で秘密キーを使用してオフラインで署名可能な中間ハッシュファイルを出力し、ブートイメージに含まれる認証証明に署名できます。このプログラムは、パーティションリストにヘッダーブロックを加えることによりブートイメージを構築します。オプションで、各パーティションを Bootgen で暗号化および認証できます。出力は、システムのブートフラッシュメモリに直接プログラム可能な 1 つのファイルです。認証および暗号化をサポートするさまざまな入力ファイルも、このツールで生成できます。詳細は、BIF 構文およびサポートされるファイルの種類を参照してください。Bootgen には、GUI インターフェイスとコマンドラインオプションがあります。Bootgen は Vitis™ 統合開発環境(IDE) に統合されており、基本的なブートイメージは GUI で生成できますが、Bootgen オプションの大部分はコマンドラインで指定します。コマンドラインオプションはスクリプトに記述できます。Bootgen ツールには、ブートイメージフォーマット (BIF) コンフィギュレーションファイル (*.bif) を入力します。Bootgen では、ザイリンクスSoC および ACAP に加え、ザイリンクス 7 シリーズ以降の FPGA のパーティションを暗号化および認証できます(FPGA のサポートを参照)。ブートイメージの動作を定義するコマンドおよび属性がサポートされているだけでなく、Bootgen での作業に役立つユーティリティもあります。Bootgen のコードは、GitHub から入手できます。

この資料に関連する設計プロセスザイリンクスの資料は、開発タスクに関連する内容を見つけやすいように、標準設計プロセスに基づいて構成されています。この資料では、次の設計プロセスについて説明します。• システム/ソリューションプランニング: システムレベルのコンポーネント、パフォーマンス、I/O、およびデータ転送要件を特定します。ソリューションの PS、PL、および AI エンジンへのアプリケーションマップも含まれます。

• エンベデッドソフトウェア開発: ハードウェアプラットフォームからソフトウェアプラットフォームを作成し、エンベデッド CPU を使用してアプリケーションを開発します。XRT および Graph API も含まれます。

第 1 章: 概要


https://github.com/Xilinx/bootgen



Bootgen のインストールブートイメージを簡単に作成するには Bootgen を GUI モードで使用し、より複雑なブートイメージを作成する場合はコマンドラインモードで使用します。Bootgen は、Vivado Design Suite インストーラーでインストールできます。Vivado® Design Suite をインストールすると、Vitis ソフトウェアプラットフォームが使用できるようになります。または、個別にダウンロードしてインストールすることも可能です。可能なすべてのインストールオプションの詳細は、『Vivado Design Suite ユーザーガイド: リリースノート、インストール、およびライセンス』 (UG973) を参照してください。Vivado から Bootgen をインストールするには、ザイリンクスダウンロードサイトに移動し、Vivado 自己解凍型インストーラーを選択します。Vivado をインストールする際に Vitis をインストールするオプションを選択します。Bootgen は Vitis と共に含まれます。また、Vitis インストーラーから Bootgen をインストールすることもできます。Vitis 自己解凍型インストーラーは、ザイリンクスダウンロードサイトにあります。Vitis と Bootgen をインストールしたら、Vitis GUI または XSCT からこのツールを呼び出して使用できます。SDK GUI オプションには、短時間での開発および試行を可能にする最も一般的なアクションが含まれています。コマンドラインオプションには、ブートイメージを作成するためのさらに多くのオプションが用意されています。GUI およびコマンドラインオプションの詳細は、第 4 章: Bootgen インターフェイスの使用を参照してください。• Vitis GUI からの起動および使用は、Bootgen の GUI オプションを参照してください。• コマンドラインからの使用は、コマンドラインでの Bootgen オプションの使用を参照してください。

ブート時のセキュリティ最新の認証方法によるセキュアブートは、ザイリンクスデバイス上で認証されていないコードまたは変更されたコードが実行されないようにし、さまざまな暗号化テクニックがロードされるためイメージにアクセスできるのは承認されたプログラムのみとなります。デバイス固有のハードウェアセキュリティ機能の詳細は、次の資料を参照してください。• 『Zynq-7000 SoC テクニカルリファレンスマニュアル』 (UG585: 英語版、日本語版)

• 『Zynq UltraScale+ デバイステクニカルリファレンスマニュアル』 (UG1085: 英語版、日本語版)

• 『Versal ACAP テクニカルリファレンスマニュアル』 (AM011)

Bootgen を使用する場合のコンテンツの暗号化および認証の詳細は、暗号化の使用および認証の使用を参照してください。Bootgen ハードウェアセキュリティモニター (HSM) モードでは、BIF 属性は RSA 秘密キーではなく公開キーを使用するため、キー処理のセキュリティが向上します。HSM はセキュアキー/署名生成デバイスであり、秘密キーを生成し、秘密キーを使用してパーティションの暗号化を実行し、RSA キーの公開部分を Bootgen に供給します。秘密キーが HSM の外部に出ることはありません。Bootgen HSM モードでの場合は、BIF は HSM によって生成された公開キーと署名を使用します。詳細は、HSM モードの使用を参照してください。

第 1 章: 概要


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2020.2;t=vivado+install+guide

https://japan.xilinx.com/support/download/index.html/content/xilinx/ja/downloadNav/vivado-design-tools.html

https://japan.xilinx.com/support/download/index.html/content/xilinx/ja/downloadNav/embedded-design-tools.html

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug585-Zynq-7000-TRM.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug585-Zynq-7000-TRM.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug1085-zynq-ultrascale-trm.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=architecture-manuals;d=am011-versal-acap-trm.pdf



第 2 章

ブートイメージレイアウトこのセクションでは、各アーキテクチャのブートイメージのフォーマットについて説明します。• Zynq-7000 デバイスでの Bootgen の使用に関しては、Zynq-7000 SoC のブートおよびコンフィギュレーションを参照してください。

• Zynq® UltraScale+™ MPSoC デバイスでの Bootgen の使用に関しては、Zynq UltraScale+ MPSoC のブートおよびコンフィギュレーションを参照してください。

• ザイリンクスデバイスでの Bootgen の使用方法に関しては、第 6 章: FPGA のサポートを参照してください。• Versal™ ACAP の詳細は、Versal ACAP ブートイメージの形式を参照してください。ブートイメージをビルドするには、次の手順を実行します。1. BIF ファイルを作成します。2. ブートイメージを作成する Bootgen 実行ファイルを実行します。注記: Quick Emulator (QEMU) では、バイナリファイルをブートデバイスに対応するイメージフォーマットに変換する必要があります。

入力ファイルは必ずしもデバイスごとに異なるわけではありませんが (たとえば、すべてのデバイスで ELF ファイルを入力ファイルとしてブートイメージの一部に含めることが可能)、ブートイメージの形式は異なります。次のトピックでは、各デバイスに必要なブートヘッダー、イメージヘッダー、パーティションヘッダー、初期化、および認証証明ヘッダーのフォーマットについて説明します。

Zynq-7000 SoC のブートおよびコンフィギュレーションこのセクションでは、Zynq®-7000 SoC のブートおよびコンフィギュレーションシーケンスについて説明します。使用可能な FSBL (第 1 段階ブートローダー) 構造の詳細は、『Zynq-7000 SoC テクニカルリファレンスマニュアル』(UG585: 英語版、日本語版) を参照してください。

Zynq-7000 SoC の bootROM

bootROM は、アプリケーションプロセッシングユニット (APU) で実行する最初のソフトウェアです。bootROM は最初の Cortex™ プロセッサ A9-0 で実行され、同時に 2 番目のプロセッサである Cortex A9-1 によって WFE (Waitfor Event) 命令が実行されます。bootROM の主なタスクは、システムをコンフィギュレーションし、FSBL をブートデバイスからオンチップメモリ (OCM) にコピーした後、コードの実行を OCM に分岐します。

第 2 章: ブートイメージレイアウト






非セキュアな環境では、FSBL を Quad-SPI または NOR デバイスから直接実行するオプションもあります。マスターブートデバイスは、1 つまたは複数のブートイメージを保持します。1 つのブートイメージは、ブートヘッダーとFSBL (第 1 段階ブートローダー) で構成されます。ブートイメージにはさらに、プログラマブルロジック (PL)、SSBL(第 2 段階ブートローダー)、およびエンベデッドオペレーティングシステムとアプリケーションが含まれます。ただし、bootROM はこれらにアクセスできません。bootROM の実行フローは、ブートモードのピンストラップ設定、ブートヘッダー、およびシステムの影響を受けます。bootROM は、暗号化された FSBL を使用するセキュアな環境または非セキュアな環境のいずれでも実行できます。サポートされるブートモードは次のとおりです。• 開発およびデバッグのプライマリモードは JTAG です。• デバイスのブートには、NAND、パラレル NOR、シリアル NOR (Quad-SPI)、およびセキュアデジタル (SD) フラッシュメモリが使用されます。これらのブートモードの詳細は、『Zynq-7000 SoC テクニカルリファレンスマニュアル』 (UG585: 英語版、日本語版) を参照してください。一般的なブートおよびコンフィギュレーションに関する質問および回答は、Zynq-7000 - ブートおよびコンフィギュレーション (ザイリンクスアンサー 52538) を参照してください。

Zynq-7000 SoC のブートイメージレイアウト次の図に、Zynq®-7000 SoC ブートイメージに含まれるコンポーネントを示します。

図 1: ブートヘッダー

Boot Header

Register Initialization Table

Image Header Table

.

.

.

Header Authentication Certificate (Optional)

Partition 1 (FSBL)

Image Header 1 _ _ _

AC(Optional)

Image Header 2 Image Header n

Partition Header 1 _ _ _Partition Header 2 Partition Header n

Partition 2 AC(Optional)

Partition n AC(Optional)





https://japan.xilinx.com/support/answers/52538.html



Zynq-7000 SoC のブートヘッダーBootgen は、ブートイメージの先頭にブートヘッダーを追加します。ブートヘッダーテーブルは、FSBL などのプライマリブートローダーのブートに関連する情報を含む構造です。ブートイメージには、このような構造が 1 つだけあります。bootROM はこのテーブルを解析して、FSBL がフラッシュのどこに格納されていて、OCM のどこにロードする必要があるかを判断します。一部の暗号化および認証に関連するパラメーターもここに格納されます。その他のブートイメージコンポーネントは次のとおりです。• Zynq-7000 SoC のレジスタ初期化テーブル• Zynq-7000 SoC イメージヘッダーテーブル• Zynq-7000 SoC のイメージヘッダー• Zynq-7000 SoC のパーティションヘッダー• Zynq-7000 SoC の認証証明ブートヘッダーには、Zynq-7000 SoC のレジスタ初期化テーブルも含まれます。bootROM は、ブートヘッダーを使用して、FSBL の位置と長さ、および FSBL に制御を渡す前にシステムを初期化するために必要なその他の情報を検索します。次の表に、Zynq®-7000 SoC ブートヘッダーのアドレスオフセット、パラメーター、および説明を示します。表 1: Zynq-7000 SoC ブートヘッダーアドレスオフセットパラメーター説明

0x00 〜 0x1F Arm® ベクターテーブル Bootgen によりダミーベクターテーブルが挿入されます(Arm オペコード 0xEAFFFFFE、初期化されていないベクターの検出を目的とした分岐-セルフ間の無限ループ)。

0x20 幅検出ワード QSPI フラッシュがシングル/デュアルスタックモードであるか、デュアルパラレルモードであるかを識別します (必須)。これは、リトルエンディアンフォーマットでは0xAA995566 です。

0x24 ヘッダー署名 4 バイト X、N、L、X をバイト順で含みます。これは、リトルエンディアンフォーマットでは 0x584c4e58 です。0x28 キーソースデバイス内の暗号化キーの場所:

0x3A5C3C5A: BBRAM に格納されている暗号化キー。0xA5C3C5A3: eFUSE に格納されている暗号化キー。0x00000000: 暗号化なし。

0x2C ヘッダーバージョン 0x01010000

0x30 ソースオフセットこのイメージファイル内の FSBL (ブートローダー) の場所。0x34 FSBL イメージの長さ復号化後の FSBL の長さ。0x38 FSBL ロードアドレス (RAM) デスティネーション RAM アドレス。このアドレスに FSBLをコピーします。0x3C FSBL 実行アドレス (RAM) FSBL 実行のエントリベクター。0x40 FSBL イメージ全体の長さ暗号化後の FSBL の合計サイズ、認証証明 (ある場合) およびパディングを含みます。0x44 QSPI コンフィギュレーションワード 0x00000001 にハードコード化されます。0x48 ブートヘッダーチェックサムオフセット 0x20 〜 0x44 のワードの合計。ワードはリトルエンディアンと見なされます。

0x4c 〜 0x97 ユーザー定義フィールド 76 バイト





表 1: Zynq-7000 SoC ブートヘッダー (続き)

アドレスオフセットパラメーター説明0x98 イメージヘッダーテーブルオフセットイメージヘッダーテーブルを指すポインター0x9C パーティションヘッダーテーブルオフセットパーティションヘッダーテーブルを指すポインター

Zynq-7000 SoC のレジスタ初期化テーブルBootgen のレジスタ初期化テーブルの構造は、MIO マルチプレクサーおよびフラッシュクロックの PS レジスタを初期化するために使用する 256 のアドレスと値のペアです。詳細は、レジスタ初期化ペアおよび INT ファイルの属性についてを参照してください。表 2: Zynq-7000 SoC のレジスタ初期化テーブル

アドレスオフセットパラメーター説明0xA0 〜 0x89C レジスタ初期化ペア: <address>:<value>: アドレス = 0xFFFFFFFF の場合、そのレジスタはスキップされ、値は無視されます。

未使用のレジスタフィールドはすべて、 Address=0xFFFFFFFF およびvalue = 0x0 に設定する必要があります。

Zynq-7000 SoC イメージヘッダーテーブルBootgen は、ELF ファイル、ビットストリーム、データファイルなどからデータを抽出してブートイメージを作成します。データが抽出されるこれらのファイルは、イメージと呼ばれます。各イメージには、1 つまたは複数のパーティションを含めることができます。イメージヘッダーテーブルは、これらすべてのイメージに共通する情報と、イメージの数、ブートイメージに含まれるパーティション、およびほかのヘッダーテーブルへのポインターといった情報を含む構造です。次の表に、Zynq®-7000 SoC デバイスのアドレスオフセット、パラメーター、および説明を示します。表 3: Zynq-7000 SoC のイメージヘッダーテーブルアドレスオフセットパラメーター説明

0x00 バージョン 0x01010000: 使用可能なフィールドは 0x0、0x4、0x8、0xC、およびパディングです。0x01020000: 0x10 フィールドが追加されます。

0x04 イメージヘッダー数イメージヘッダーの数を指定します。0x08 第一パーティションヘッダーオフセット第一パーティションヘッダーを指すポインター。(ワードオフセット)。0x0C 第一イメージヘッダーオフセット第一イメージヘッダーを指すポインター。(ワードオフセット)。

0x10 ヘッダー認証証明オフセット認証証明ヘッダーを指すポインター。(ワードオフセット)。

0x14 予約デフォルトは 0xFFFFFFFF です。





Zynq-7000 SoC のイメージヘッダーイメージヘッダーは、ELF ファイル、ビットストリーム、データファイルなど、各イメージに関連する情報を含む構造の配列です。各イメージに複数のパーティションを含めることができます。たとえば、ELF には複数のロード可能なセクションを含めることができ、それぞれがブートイメージ内にパーティションを形成します。テーブルには、イメージに関連するパーティション数の情報も含まれます。次の表に、Zynq®-7000 SoC デバイスのアドレスオフセット、パラメーター、および説明を示します。表 4: Zynq-7000 SoC のイメージヘッダー

アドレスオフセットパラメーター説明0x00 次のイメージヘッダー。次のイメージヘッダーにリンクします。最後のイメージヘッダーの場合は 0 となります (ワードオフセット)。0x04 対応するパーティションヘッダー。最初に関連付けられたパーティションヘッダーにリンクします (ワードオフセット)。0x08 予約常に 0。0x0C パーティション数このイメージに関連付けられたパーティションの数。

0x10 〜 N イメージの名前ビッグエンディアン順に圧縮されます。文字列を再構築するため、一度に 4 バイトを解凍し、順序を逆にして連結します。たとえば、文字列「FSBL10.ELF」は 0x10:‘L’,’B’,’S’,’F’, 0x14: ’E’,’.’,’0’,’1’, 0x18: ’\0’,’\0’,’F’,’L’ のように圧縮されます。圧縮されたイメージ名は 4 の倍数バイトです。

N ストリングターミネーター (終端名) 0x00000000

N+4 予約デフォルトで、64 バイト境界まで0xFFFFFFFF でパディングされます。

Zynq-7000 SoC のパーティションヘッダーパーティションヘッダーは、各パーティションに関連する情報を含む構造の配列です。各パーティションヘッダーテーブルは、ブートローダーによって解析されます。このテーブルには、パーティションサイズ、フラッシュ内のアドレス、RAM 内のロードアドレス、暗号化/署名などの情報が含まれます。FSBL を含め、各パーティションにこのような構造が 1 つあります。テーブル内の最後の構造は、すべて NULL 値となります (チェックサムを除く)。次の表に、Zynq®-7000 SoC パーティションヘッダーのオフセット、名前、および説明を示しています。注記: ロード可能なセクションが 3 つある ELF ファイルには、1 つのイメージヘッダーと 3 つのパーティションヘッダーテーブルが含まれます。表 5: Zynq-7000 SoC のパーティションヘッダー

オフセット名前説明0x00 暗号化されたパーティションの長さ暗号化されたパーティションデータの長さ。0x04 暗号化されていないパーティションの長さ暗号化されていないデータの長さ。

0x08 合計パーティションワード長 (認証証明を含む)。Zynq-7000 SoC の認証証明を参照してください。合計パーティションワード長は、パディング付きの暗号化された情報、拡張、および認証の各長さの合計です。





表 5: Zynq-7000 SoC のパーティションヘッダー (続き)

オフセット名前説明0x0C デスティネーションロードアドレス。このパーティションがロードされる RAM アドレス。

0x10 デスティネーション実行アドレス。実行時のこのパーティションのエントリポイント。0x14 イメージのデータワードオフセットブートイメージの開始に対するパーティションデータの位置。0x18 属性ビット Zynq-7000 SoC のパーティション属性ビット参照0x1C セクション数シングルパーティション内のセクション数。0x20 チェックサムワードオフセットブートイメージ内の該当するチェックサムワードの位置。0x24 イメージヘッダーのワードオフセットブートイメージ内の該当するイメージヘッダーの位置。0x28 認証証明ワードオフセットブートイメージ内の該当する認証証明の位置。

0x2C-0x38 予約予約済み0x3C ヘッダーチェックサムパーティションヘッダーの以前のワードの合計値。

Zynq-7000 SoC のパーティション属性ビット次の表に、Zynq®-7000 SoC デバイスのパーティションヘッダーテーブルのパーティション属性ビットを示します。表 6: Zynq-7000 SoC のパーティション属性ビット

ビットフィールド説明説明31:18 予約不使用17:16 パーティションオーナー

0: FSBL1: UBOOT2、3: 予約

15 RSA 署名の有無0: RSA 認証証明なし1: RSA 認証証明あり

14:12 チェックサムタイプ0: なし1: MD52-7: 予約

11:8 予約不使用7:4 デスティネーションデバイス

0: なし1: PS2: PL3: INT4-15: 予約

3:2 予約不使用1:0 予約不使用





Zynq-7000 SoC の認証証明認証証明は、パーティションの認証に関連するすべての情報を含む構造です。この構造には、公開キーと、bootROM/FSBL による検証が必要なすべての署名が含まれます。各認証証明には認証ヘッダーがあります。このヘッダーは、キーサイズ、署名に使用するアルゴリズムなどの情報を提供します。認証証明は、認証が有効になっている実際のパーティションに追加されます。認証が有効になっているすべてのパーティションに対して、ヘッダーテーブルも認証する必要があります。ヘッダーテーブル認証証明は、ヘッダーテーブルのコンテンツの最後に追加されます。Zynq®-7000 SoC は SHA-256 ハッシュアルゴリズムによる RSA-2048 認証を使用するため、プライマリキーおよびセカンダリキーのサイズは 2048 ビットとなります。SHA-256 はセキュアハッシュアルゴリズムとして使用されるため、FSBL、パーティション、および認証証明は 512 ビット境界にパディングする必要があります。次の表に、Zynq®-7000 SoC の認証証明のフォーマットを示します。表 7: Zynq-7000 SoC の認証証明

認証証明ビット説明0x00 認証ヘッダー = 0x0101000。Zynq-7000 SoC の認証証明ヘッダーを参照してください。0x04 証明のサイズ0x08 UDF (56 バイト)

0x40 PPK Mod (256 バイト)

0x140 Mod Ext (256 バイト)

0x240 Exponent

0x244 Pad (60 バイト)

0x280 SPK Mod (256 バイト)


0x480 Exponent (4 バイト)

0x484 Pad (60 バイト)

0x4C0 SPK 署名 = RSA-2048 (PSK、パディング || SHA-256(SPK))

0x5C0 FSBL パーティション署名 = RSA-2048 (SSK、SHA-256 (ブートヘッダー || FSBL パーティション)

0x5C0 その他パーティション署名 = RSA-2048 (SSK、SHA-256 (パーティション || パディング || 認証ヘッダー || PPK || SPK || SPK 署名)

Zynq-7000 SoC の認証証明ヘッダー次の表に、Zynq®-7000 SoC の認証証明ヘッダーを説明します。表 8: Zynq-7000 SoC の認証証明ヘッダー

ビットオフセットフィールド名説明31:16 予約 0

15:14 認証証明フォーマット 00: PKCS #1 v1.5

13:12 認証証明バージョン 00: 現在の AC

11 PPK キータイプ 0: ハッシュキー10:9 PPK キーソース 0: eFUSE

8 SPK イネーブル 1: SPK イネーブル





表 8: Zynq-7000 SoC の認証証明ヘッダー (続き)

ビットオフセットフィールド名説明7:4 公開キー強度 0:2048

3:2 ハッシュアルゴリズム 0: SHA256

Zynq-7000 SoC のブートイメージブロック図次の図に、Zynq®-7000 SoC ブートイメージに含まれるコンポーネントを示します。





図 2: Zynq-7000 SoC のブートイメージブロック図

X21320-081718





Zynq UltraScale+ MPSoC のブートおよびコンフィギュレーション

概要Zynq® UltraScale+™ MPSoC は、QSPI フラッシュ、SD カード、USB デバイスファームウェアアップグレード (DFU)ホスト、NAND フラッシュドライブなどからのブートをサポートしています。この章では、セキュアモードと非セキュアモードの両方における各種デバイスからのブートアッププロセスについて説明します。ブートプロセスは、プラットフォーム管理ユニット (PMU) およびコンフィギュレーションセキュリティユニット (CSU) により管理および実行されます。初期ブート時に、次の手順が実行されます。• パワーオンリセット (POR) により PMU がリセット状態から復帰します。• PMU が PMU ROM からのコードを実行します。• PMU が SYSMON とブートに必要な PLL を初期化し、低電力ドメインとフル電力ドメインをクリアして CSU のリセットを開放します。

PMU により CSU が開放されると、CSU は次を実行します。• FSBL またはユーザーアプリケーションによって認証が要求されているかを確認します。• 認証チェックを実行し、このチェックが成功した場合のみ次に進みます。そして、イメージに暗号化されたパーティションがあるかどうかをチェックします。

• CSU は、暗号化されたパーティションを検出すると復号化を実行して OCM を初期化し、ブートモード設定を判断して、FSBL のロードとオプションの PMU ファームウェアのロードを実行します。

• CSU ROM コードの実行後、FSBL に制御を渡します。FSBL は、PCAP インターフェイス経由でビットストリームで PL をプログラムします。

ここからは、FSBL がシステムを管理します。CSU および PMU の詳細は、『Zynq UltraScale+ デバイステクニカルリファレンスマニュアル』 (UG1085: 英語版、日本語版) を参照してください。CSU の詳細は、『Zynq UltraScale+MPSoC: ソフトウェア開発者向けガイド』 (UG1137) の「コンフィギュレーションセキュリティユニット」セクションを参照してください。

Zynq UltraScale+ MPSoC のブートイメージ次の図に、Zynq® UltraScale+™ MPSoC のブートイメージを示します。





https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2020.2;d=ug1137-zynq-ultrascale-mpsoc-swdev.pdf



図 3: Zynq UltraScale+ MPSoC のブートイメージ

Boot Header

Register Initialization Table

Image Header Table

.

.

.

Header Authentication Certificate (Optional)

Image Header 1

_ _ _Image

Header 2Image Header

n

Partition Header 1

_ _ _Partition Header 2

Partition Header n

Partition n AC(Optional)

Partition 2 AC(Optional)

Partition 1 (FSBL) AC(Optional)

PUF Helper Data (Optional)

PMU FW(Optional)

X23449-102919

Zynq UltraScale+ MPSoC のブートヘッダーブートヘッダーについてBootgen は、ブートイメージの先頭にブートヘッダーを追加します。ブートヘッダーテーブルは、FSBL などのプライマリブートローダーのブートに関連する情報を含む構造です。ブートイメージには、このような構造が 1 つだけあります。bootROM はこのテーブルを解析して、FSBL がフラッシュのどこに格納されていて、OCM のどこにロードする必要があるかを判断します。一部の暗号化および認証に関連するパラメーターもここに格納されます。ブートイメージには、次のコンポーネントが含まれます。• Zynq UltraScale+ MPSoC のブートヘッダー (Zynq UltraScale+ MPSoC のブートヘッダー属性ビットも含む)

• Zynq UltraScale+ MPSoC のレジスタ初期化テーブル





• Zynq UltraScale+ MPSoC の PUF ヘルパーデータ• Zynq UltraScale+ MPSoC イメージヘッダーテーブル• Zynq UltraScale+ MPSoC のイメージヘッダー• Zynq UltraScale+ MPSoC の認証証明• Zynq UltraScale+ MPSoC のパーティションヘッダーbootROM は、ブートヘッダーを使用して、FSBL の位置と長さ、および FSBL に制御を渡す前にシステムを初期化するために必要なその他の情報を検索します。次の表に、Zynq® UltraScale+™ MPSoC デバイスのアドレスオフセット、パラメーター、および説明を示します。表 9: Zynq UltraScale+ MPSoC デバイスのブートヘッダーアドレスオフセットパラメーター説明

0x00-0x1F Arm® ベクターテーブル XIP ELF ベクターテーブル:

0xEAFFFFFE: Cortex™-R5F および Cortex A53 (32 ビット) の場合0x14000000: Cortex A53 (64 ビット) の場合

0x20 幅検出ワード QSPI の幅検出に使用されます。これは、リトルエンディアンフォーマットでは 0xAA995566 です。0x24 ヘッダー署名 4 バイト ‘X’,’N’,’L’,’X’ をバイト順で含みます。これは、リトルエンディアンフォーマットでは 0x584c4e58 です。0x28 キーソース

0x00000000 (暗号化なし)0xA5C3C5A5 (eFUSE に格納されているブラックキー)0xA5C3C5A7 (eFUSE に格納されている難読化キー)0x3A5C3C5A (BBRAM に格納されているレッドキー)0xA5C3C5A3 (eFUSE に格納されているレッドキー)0xA35C7CA5 (ブートヘッダーに格納されている難読化キー)0xA3A5C3C5 (ブートヘッダーに格納されているユーザーキー)0xA35C7C53 (ブートヘッダーに格納されているブラックキー)

0x2C FSBL 実行アドレス(RAM)

OCM 内の FSBL 実行アドレスまたは XIP ベースアドレス。

0x30 ソースオフセット PMUFW がない場合は、FSBL の開始オフセットです。PMUFW がない場合は、FSBLPMUFW の開始です。

0x34 PMU イメージの長さ PMU ファームウェアの元のイメージの長さ (バイト)。(0〜128KB)。サイズ > 0 の場合、PMUFW は FSBL の前に付きます。サイズ = 0 の場合、PMUFW イメージはなしです。

0x38 PMU FW 全体の長さ PMUFW イメージ全体の長さ.(PMUFW 長 + 暗号化オーバーヘッド)

0x3C FSBL イメージの長さ元の FSBL イメージの長さ (バイト)。(0〜250KB)。0 の場合、XIP ブートイメージと見なされます。0x40 FSBL イメージ全体の長さ FSBL イメージの長さ + FSBL イメージの暗号化オーバーヘッド + 認証証明 + 64バイトアライメント + ハッシュサイズ (インテグリティチェック)。0x44 FSBL イメージ属性属性ビットを参照してください。0x48 ブートヘッダーチェックサムオフセット 0x20 〜 0x44 のワードの合計。ワードはリトルエンディアンと見なされます。





表 9: Zynq UltraScale+ MPSoC デバイスのブートヘッダー (続き)

アドレスオフセットパラメーター説明0x4C-0x68 難読化/ブラックキーの格納難読化キーまたはブラックキーを格納します。

0x6C シャッター値 PUF でシャッターオフセット時間およびシャッターオープン時間を設定する32 ビットの PUF_SHUT レジスタ値。

0x70 〜 0x94 ユーザー定義フィールド (UDF)40 バイト。

0x98 イメージヘッダーテーブルオフセットイメージヘッダーテーブルを指すポインター。

0x9C パーティションヘッダーテーブルオフセットパーティションヘッダーを指すポインター。

0xA0-0xA8 セキュアヘッダーIV

ブートローダーパーティションのセキュアヘッダー用 IV。

0x0AC-0xB4 難読化/ブラックキー IV難読化キーまたはブラックキーの IV。

Zynq UltraScale+ MPSoC のブートヘッダー属性ビット表 10: Zynq UltraScale+ MPSoC のブートヘッダー属性ビットフィールド名ビットオフセット幅デフォルト説明

予約 31:16 16 0x0 予約。必ず 0。BHDR RSA 15:14 2 0x0

0x3: PPK ハッシュと SPK IDの検証を除き、ブートイメージの RSA 認証が実行されます。その他すべて : RSA 認証はeFUSE RSA ビットに基づいて決定されます。

予約 13:12 2 0x0 なしCPU 選択 11:10 2 0x0

0x0: R5 シングル。0x1: A53 シングル 32 ビット0x2: A53 シングル 64 ビット0x3: R5 デュアル

ハッシュ処理選択 9:8 2 0x00x0、0x1: インテグリティチェックなし。0x3: BI インテグリティチェック用の SHA3。

PUF-HD 7:6 2 0x00x3: PUF HD はブートヘッダーに格納されています。その他すべて : PUF HD はeFUSE に格納されています。

予約 5:0 6 0x0 今後の使用のため予約。必ず 0。





Zynq UltraScale+ MPSoC のレジスタ初期化テーブルBootgen のレジスタ初期化テーブルの構造は、MIO マルチプレクサーの PS レジスタおよびフラッシュデバイスのクロックを初期化するのに使用される 256 のアドレスと値のペアです。詳細は、第 10 章: 初期化ペアおよび INIT ファイルの属性を参照してください。表 11: Zynq UltraScale+ MPSoC のレジスタ初期化テーブル

アドレスオフセットパラメーター説明0xB8 〜 0x8B4 レジスタ初期化ペア:

<address>:<value>:

(2048 バイト)

アドレスが 0xFFFFFFFF に設定されている場合、そのレジスタはスキップされ、値は無視されます。未使用のレジスタフィールドはすべて、アドレス = 0xFFFFFFFF および値 =0x0 に設定する必要があります。

Zynq UltraScale+ MPSoC の PUF ヘルパーデータPUF はヘルパーデータを使用して、デバイスの有効期間中、保証された動作温度および電圧範囲において元の KEK値を再度作成できます。ヘルパーデータは、<syndrome_value>、<aux_value>、および <chash_value> で構成されます。ヘルパーデータは、eFUSE またはブートイメージのいずれかに格納できます。詳細は、puf_fileを参照してください。『Zynq UltraScale+ デバイステクニカルリファレンスマニュアル』 (UG1085: 英語版、日本語版) の「PUF ヘルパーデータ」も参照してください。表 12: Zynq UltraScale+ MPSoC の PUF ヘルパーデータ

アドレスオフセットパラメーター説明0x8B8 〜 0xEC0 PUF ヘルパーデータ (1544 バイト)

ブートヘッダーオフセット 0x44 (ビット 7:6) == 0x3 の場合にのみ有効です。PUF HD が挿入されていない場合、ブートヘッダーのサイズは 2048 バイトです。PUF ヘッダーデータが挿入されている場合、ブートヘッダーのサイズは 3584 バイトです。PUF HD サイズ = 合計サイズ =1536 バイトの PUFHD + 4 バイトの CHASH + 2 バイトのAUX + 1 バイトアライメント = 1544 バイト。

Zynq UltraScale+ MPSoC イメージヘッダーテーブルBootgen は、ELF ファイル、ビットストリーム、データファイルなどからデータを抽出してブートイメージを作成します。データが抽出されるこれらのファイルは、イメージと呼ばれます。各イメージには、1 つまたは複数のパーティションを含めることができます。イメージヘッダーテーブルは、これらすべてのイメージに共通する情報と、イメージの数、ブートイメージに含まれるパーティション、およびほかのヘッダーテーブルへのポインターといった情報を含む構造です。表 13: Zynq UltraScale+ MPSoC デバイスのイメージヘッダーテーブル

アドレスオフセットパラメーター説明0x00 バージョン

0x010100000x01020000: 0x10 フィールドが追加されます。

0x04 イメージヘッダー数イメージヘッダーの数を指定します。0x08 第一パーティションヘッダーオフセット第一パーティションヘッダーを指すポインター (ワードオフセット)。





https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xPUFHelperData



表 13: Zynq UltraScale+ MPSoC デバイスのイメージヘッダーテーブル (続き)

アドレスオフセットパラメーター説明0x0C 第一イメージオフセットヘッダー第一イメージヘッダーを指すポインター (ワードオフセット)。0x10 ヘッダー認証証明ヘッダー認証証明を指すポインター (ワードオフセット)。0x14 セカンダリブートデバイスオプションは次のとおりです。

0: 同じブートデバイス1: QSPI-322: QSPI-243: NAND4: SD05: SD16: SDLS7: MMC8: USB9: ETHERNET10: PCIE11: SATA

0x18 〜 0x38 パディング予約 (0x0)

0x3C チェックサムイメージヘッダーの以前のワードすべての合計値。

Zynq UltraScale+ MPSoC のイメージヘッダーイメージヘッダーについてイメージヘッダーは、ELF ファイル、ビットストリーム、データファイルなど、各イメージに関連する情報を含む構造の配列です。各イメージに複数のパーティションを含めることができます。たとえば、ELF には複数のロード可能なセクションを含めることができ、それぞれがブートイメージ内にパーティションを形成します。テーブルには、イメージに関連するパーティション数の情報も含まれます。次の表に、Zynq® UltraScale+™ MPSoC のアドレスオフセット、パラメーター、および説明を示します。表 14: Zynq UltraScale+ MPSoC デバイスのイメージヘッダー

アドレスオフセットパラメーター説明0x00 次のイメージヘッダーオフセット次のイメージヘッダーにリンクします。最後のイメージヘッダーの場合は 0 となります(ワードオフセット)。0x04 対応するパーティションヘッダー最初に関連付けられたパーティションヘッダーへのリンク(ワードオフセット)。0x08 予約常に 0。0x0C パーティション数実際のパーティション数の値。

0x10 - N イメージの名前ビッグエンディアン順に圧縮されます。文字列を再構築するため、一度に 4 バイトを解凍し、順序を逆にして連結されます。たとえば、文字列 FSBL10.ELF は 0x10:‘L’,’B’,’S’,’F’, 0x14: ’E’,’.’,’0’,’1’,0x18: ’\0’,’\0’,’F’,’L’ として圧縮されます。圧縮されたイメージ名は 4 の倍数バイトです。





表 14: Zynq UltraScale+ MPSoC デバイスのイメージヘッダー (続き)

アドレスオフセットパラメーター説明不定ストリングターミネーター (終端名)

0x00000

不定パディングデフォルトで、64 バイト境界まで 0xFFFFFFF でパディングされます。

Zynq UltraScale+ MPSoC のパーティションヘッダーパーティションヘッダーについてパーティションヘッダーは、各パーティションに関連する情報を含む構造の配列です。各パーティションヘッダーテーブルは、ブートローダーによって解析されます。このテーブルには、パーティションサイズ、フラッシュ内のアドレス、RAM 内のロードアドレス、暗号化/署名などの情報が含まれます。FSBL を含め、各パーティションにこのような構造が 1 つあります。テーブル内の最後の構造は、すべて NULL 値となります (チェックサムを除く)。次の表に、Zynq® UltraScale+™ MPSoC のオフセット、名前、および説明を示しています。表 15: Zynq UltraScale+ MPSoC デバイスのパーティションヘッダー

オフセット名前説明0x0 暗号化されたパーティションデータワード長暗号化されたパーティションデータの長さ。

0x04 復号化されていないデータワード長暗号化されていないデータの長さ。

0x08 合計パーティションワード長 (認証証明を含む)。認証証明を参照。暗号化、パディング、拡張、認証をすべて合計した長さ。

0x0C 次のパーティションヘッダーオフセット次のパーティションヘッダーの位置 (ワードオフセット)。

0x10 デスティネーション実行アドレスLO

ロード後のこのパーティションの実行可能アドレスの下位 32 ビット。0x14 デスティネーション実行アドレス

HIロード後のこのパーティションの実行可能アドレスの上位 32 ビット。

0x18 デスティネーションロードアドレス LOこのパーティションがロードされる RAM アドレスの下位 32 ビット。

0x1C デスティネーションロードアドレス HIこのパーティションがロードされる RAM アドレスの上位 32 ビット。

0x20 実パーティションワードオフセットブートイメージの開始に対するパーティションデータの位置(ワードオフセット)。0x24 属性 Zynq UltraScale+ MPSoC のパーティション属性ビット参照0x28 セクション数このパーティションに関連付けられたセクション数。0x2C チェックサムワードオフセットブートイメージ内のチェックサムイメージの位置 (ワードオフセット)。0x30 イメージヘッダーのワードオフセットブートイメージ内の該当するイメージヘッダーの位置 (ワードオフセット)。0x34 AC オフセットある場合は、ブートイメージ内の認証証明の位置 (ワードオフセット)

0x38 パーティション番号/ID パーティション ID。0x3C ヘッダーチェックサムパーティションヘッダーの以前のワードの合計値。





Zynq UltraScale+ MPSoC のパーティション属性ビット次の表に、Zynq® UltraScale+™ MPSoC のパーティションヘッダーテーブルのパーティション属性ビットを示します。表 16: Zynq® UltraScale+™ MPSoC デバイスのパーティション属性ビット

ビットオフセットフィールド名説明31:24 予約

23 ベクターの位置例外ベクターの位置。0: LOVEC (デフォルト)1: HIVEC

22:20 予約19 早期ハンドオフロード直後のハンドオフ:

0: 早期ハンドオフなし1: 早期ハンドオフが有効

18 エンディアン0: リトルエンディアン1: ビッグエンディアン

17:16 パーティションオーナー0: FSBL1: U-Boot2、3: 予約

15 RSA 認証証明フォーマット0: RSA 認証証明なし1: RSA 認証証明あり

14:12 チェックサムタイプ0: なし1 〜 2: 予約3: SHA34 〜 7: 予約

11:8 デスティネーション CPU0: なし1: A53-02: A53-13: A53-24: A53-35: R5-06: R5-17: R5-ロックステップ8: PMU9 〜 15: 予約

7 暗号化の有無0: 暗号化なし1: 暗号化あり





表 16: Zynq® UltraScale+™ MPSoC デバイスのパーティション属性ビット (続き)

ビットオフセットフィールド名説明6:4 デスティネーションデバイス

0: なし1: PS2: PL3 〜 15: 予約

3 A5X 実行ステート0: AARCH64 (デフォルト)1: AARCH32

2:1 例外レベル0: EL01: EL12: EL23: EL3

0 TrustZone0: 非セキュア1: セキュア

Zynq UltraScale+ MPSoC の認証証明認証証明は、パーティションの認証に関連するすべての情報を含む構造です。この構造には、公開キーと、bootROM/FSBL による検証が必要な署名が含まれます。各認証証明には認証ヘッダーがあります。このヘッダーは、キーサイズ、署名に使用するアルゴリズムなどの情報を提供します。認証証明は、認証が有効になっている実際のパーティションに追加されます。認証が有効になっているすべてのパーティションに対して、ヘッダーテーブルも認証する必要があります。ヘッダーテーブル認証証明は、ヘッダーテーブルのコンテンツの最後に追加されます。Zynq® UltraScale+™ MPSoC は RSA-4096 認証を使用するため、プライマリキーおよびセカンダリキーのサイズは4096 ビットとなります。次の表に、Zynq UltraScale+ MPSoC デバイスの認証証明のフォーマットを示します。表 17: Zynq UltraScale+ MPSoC デバイスの認証証明

認証証明0x00 認証ヘッダー = 0x0101000。Zynq UltraScale+ MPSoC の認証証明ヘッダーを参照してください。0x04 SPK ID

0x08 UDF (56 バイト)

0x40 PPK Mod (512)

0x240 Mod Ext (512)


0x444 Pad (60 バイト)




0x884 Pad (60 バイト)

0x8C0 SPK 署名 = RSA-4096 (PSK、パディング || SHA-384 (SPK + 認証ヘッダー + SPK-ID))





表 17: Zynq UltraScale+ MPSoC デバイスの認証証明 (続き)

認証証明0xAC0 ブートヘッダー署名 = RSA-4096 (SSK、パディング || SHA-384 (ブートヘッダー))

0xCC0 パーティション署名 = RSA-4096 (SSK、パディング || SHA-384 (パーティション || パディング || 認証ヘッダー || UDF || PPK || SPK || SPK 署名))

注記: FSBL 署名は、次のように計算されます。FSBL Signature = RSA-4096 ( SSK, Padding || SHA-384 (PMUFW || FSBL ||Padding || Authentication Header || UDF || PPK || SPK || SPK Signature)

Zynq UltraScale+ MPSoC の認証証明ヘッダー次の表に、Zynq® UltraScale+™ MPSoC デバイスの認証証明ビットフィールドを示します。表 18: 認証ヘッダービットフィールドビットフィールド説明説明

31:20 予約 0

19:18 SPK/ユーザー eFUSE 選択01: SPK eFUSE10: ユーザー eFUSE

17:16 PPK キー選択0: PPK01: PPK1

15:14 認証証明フォーマット 00: PKCS #1 v1.5

13:12 認証証明バージョン 00: 現在の AC

11 PPK キータイプ 0: ハッシュキー10:9 PPK キーソース 0: eFUSE

8 SPK イネーブル 1: SPK イネーブル7:4 公開キー強度

0: 2048b1: 40962 〜 3: 予約

3:2 ハッシュアルゴリズム1: SHA3/3842 〜 3: 予約

1:0 公開キーアルゴリズム0: 予約1: RSA2: 予約3: 予約





Zynq UltraScale+ MPSoC セキュアヘッダーパーティションを暗号化するように選択すると、Bootgen がそのパーティションにセキュアヘッダーを追加します。セキュアヘッダーには、実際のパーティションを暗号化するのに使用されるキー/IV が含まれます。この後、このヘッダーがデバイスキーおよび IV を使用して暗号化されます。次の表は、Zynq UltraScale+ MPSoC のセキュアヘッダーを示しています。

図 4: Zynq UltraScale+ MPSoC のセキュアヘッダー

AES

Partition#0 (FSBL) Partition#1 Partition#2

Contents Contents Contents

Secure Header Key0 IV0 - IV1 Key0 IV0+0x01 Key1 IV1 Key0 IV0+0x02 Key1 IV1

Block #0 Key0 IV1 - - Key1 IV1 - - Key1 IV1 - -

AES with Key rolling

Partition#0 (FSBL) Partition#1 Partition#2

Contents Contents Contents

Secure Header Key0 IV0 - IV1 Key0 IV0+0x01 Key1 IV1 Key0 IV0+0x02 Key1 IV1

Block #0 Key0 IV1 Key 2 IV2 Key1 IV1 Key2 IV2 Key1 IV1 Key2 IV2

Block #1 Key2 IV2 Key 3 IV3 Key2 IV2 Key 3 IV3 Key2 IV2 Key 3 IV3

Block #2 Key3 IV3 Key 4 IV4 Key3 IV3 Key 4 IV4 Key3 IV3 Key 4 IV4

… … … … … … … … … … … … …

EncryptedUsing

EncryptedUsing

EncryptedUsing

EncryptedUsing

EncryptedUsing

EncryptedUsing

Zynq UltraScale+ MPSoC のブートイメージブロック図次の図に、Zynq® UltraScale+™ MPSoC ブートイメージに含まれるコンポーネントを示します。





図 5: Zynq UltraScale+ MPSoC デバイスのブートイメージブロック図

Boot Header 0x000-0xEC0

Image Header TableImage Headers (IH1-Ihn)

Partition Header 1

Partition Header nHeader AC

BootLoader(FSBL and PMUFW (opt))

BootLoader AC

Partition 1

Partition 1 AC

Partition(n)

Partition(n) AC

BootLoader AC

Partition 1 AC

Partition n AC

AC HeaderSPK IDHeader

SPKHeader

SPK SignatureBH Signature

Partition Signature

Header AC

User Defined FieldPPK

AC HeaderSPK IDBootLoader

SPKBootLoader


Partition Signature


AC HeaderSPK IDPartition1

SPKPartition1


Partition Signature


AC HeaderSPK IDPartition(n)

SPKPartition(n)


Partition Signature


X#####-122118X18916-081518





Versal ACAP ブートイメージの形式次の図は、プログラマブルデバイスイメージ (PDI) と呼ばれる Versal™ ACAP ブートイメージに含まれるコンポーネントを示しています。

プラットフォーム管理コントローラーVersal ACAP のプラットフォーム管理コントローラー (PMC) は、ブートおよびコンフィギュレーションといったVersal ACAP のプラットフォーム管理を担います。この章では、2 つの PMC MicroBlaze プロセッサ、ROM コードユニット (RCU) とプラットフォーム処理ユニット (PPU) で処理されるブートイメージ形式について主に説明しています。• RCU: ROM コードユニットには、三重冗長 MicroBlaze プロセッサと、bootROM 実行ファイルが格納される ROM

(読み出し専用メモリ) があります。bootROM 実行ファイルは、メタルマスクされており、変更できません。RCUの MicroBlaze プロセッサは、bootROM 実行ファイルの検証と実行に使用されます。また、RCU は起動後のセキュリティ監視と PUF (Physical Unclonable Function) 管理も担います。

• PPU: プラットフォーム処理ユニットには、三重冗長 MicroBlaze プロセッサと 384 KB の専用 PPU RAM があります。PPU の MicroBlaze は、PLM (プラットフォームローダーおよびマネージャー) を駆動します。

図 6: Versal ACAP のブートイメージブロック図

Boot Header

PMC CDO

Meta Headers

Partition 1 _ _ _Partition 2 Partition i

Partition 1 _ _ _Partition 2 Partition j

PLM

Image Header Table

Image Header 1 _ _ _Image Header 2 Image Header n

Partition Header 1 _ _ _Partition Header 2 Partition Header i

Partition 1 _ _ _Partition 2 Partition k

Partition Header 1 _ _ _Partition Header 2 Partition Header jImage 1

Image 2

Image n

Image 1

Image 2

Image n

..

Partition Header 1 _ _ _Partition

Header 2Partition Header

k

X22829-101520

Versal ACAP ブートヘッダーブートヘッダーは、PMC bootROM で使用されます。PMC bootROM は、ブートヘッダーの属性設定に基づいて、PLM (Platform Loader and Manager) を検証して PPU RAM に読み込みます。最初の 16 バイトは SelectMAP Bus の検出に使用されます。PMC bootROM および PLM ではこのデータが無視されるので、Bootgen はチェックサム/SHA/RSA/暗号化などのどの動作にもこのデータを含めません。次のコードは、SelectMAP Bus 幅検出パターンビットの例を示しています。Bootgen は、選択した幅ごとに、最初の 16 バイトへ次のデータを配置します。次のリストは、このイメージヘッダー幅と該当するビットをそれぞれ示しています。





• X8: [LSB] 00 00 00 DD 11 22 33 44 55 66 77 88 99 AA BB CC [MSB]

• X16: [LSB] 00 00 DD 00 22 11 44 33 66 55 88 77 AA 99 CC BB [MSB]

• X32: [LSB] DD 00 00 00 44 33 22 11 88 77 66 55 CC BB AA 99 [MSB]

注記: デフォルトの SelectMAP 幅は X32 です。次の表は、Versal™ ACAP のブートヘッダー形式を示しています。表 19: Versal ACAP のブートヘッダーフォーマット

オフセット (16 進数) サイズ (バイト) 説明詳細0x00 16 SelectMAP バス幅 SelectMAP バス幅を x8、x16、

x32 から指定します。0x10 4 QSPI バス幅 QSPI バス幅の記述。これは、

QSPI フラッシュがシングル/デュアルスタックモードであるか、デュアルパラレルモードであるかを識別するために必要です。これはリトルエンディアンフォーマットの0xAA995566 です。

0x14 4 イメージ ID ブートイメージの ID 文字列。バイト順に 4 バイトの「X」、「N」、「L」、「X」を含みます。これは、リトルエンディアンフォーマットの 0x584c4e58です。0x18 4 暗号化キーソースこのフィールドは、AES キーソース 0x00000000 を識別するために使用します。

0x00000000: 暗号化なし0xA5C3C5A3: eFUSE レッドキー0xA5C3C5A5: eFUSE ブラックキー0x3A5C3C5A: BBRAM レッドキー0x3A5C3C59: BBRAM ブラックキー0xA35C7C53: ブートヘッダーブラックキー

0x1C 4 PLM ソースオフセット PDI の PLM ソース開始アドレス0x20 4 PMC データ読み込みアドレス読み込む PMC CDO アドレス0x24 4 PMC データ長 PMC CDO 長0x28 4 合計 PMC データ長認証および暗号化オーバーヘッドを含む PMC CDO 長0x2C 4 PLM 長 PLM の元のイメージサイズ0x30 4 合計 PLM 長認証および暗号化オーバーヘッドを含む PLM イメージサイズ0x34 4 ブートヘッダー属性ブートヘッダー属性





表 19: Versal ACAP のブートヘッダーフォーマット (続き)

オフセット (16 進数) サイズ (バイト) 説明詳細0x38 32 ブラックキー 256 ビットのキーで、ブートヘッダーで暗号化ステータスがブラックキーに設定されている場合にのみ使用可能です。0x58 12 ブラック IV ブラックキーを復号化する際に使用する初期化ベクター0x64 12 セキュアヘッダー IV セキュアヘッダーの初期化ベクター0x70 4 PUF シャッター値 PUF がシャッターを閉じる前にサンプリングする時間の長さ

注記: このシャッター値は、PUF 登録中に使用されたシャッター値と一致している必要があります。

0x74 12 PMC データのセキュアヘッダー IVPMC データのセキュアヘッダーを復号化する際に使用される IV。

0x80 68 予約すべて 0 で生成されます。0xC4 4 メタヘッダーオフセットメタヘッダーの開始のオフセット。0xC8-0x124 88 予約0x128 2048 レジスタ初期化システムレジスタ初期化用のレジスタ書き込みペアを格納0x928 1544 PUF ヘルパーデータ PUF ヘルパーデータ0xF30 4 チェックサムヘッダーチェックサム0xF34 76 SHA3 パディング SHA3 標準パディング

ブートヘッダー属性次の表に、イメージ属性を示します。表 20: Versal ACAP のブートヘッダー属性

フィールド名ビットオフセット幅デフォルト説明予約 [31:18] 14 0x0 今後の使用のため予約、

0 にする必要あり。PUF モード [17:16] 2 0x0 0x3: PUF 4K モード。

0x0: PUF 12K モード。ブートヘッダー認証 [15:14] 2 0x0 0x3: PPK ハッシュと

SPK ID の検証を除き、ブートイメージの認証が実行されます。その他すべて : 認証はeFUSE RSA/ECDSA ビットに基づいて決定されます。





表 20: Versal ACAP のブートヘッダー属性 (続き)

フィールド名ビットオフセット幅デフォルト説明

予約 [13:12] 2 0x0 今後の使用のために予約済みで、0 にする必要あり。DPA カウンター値 [11:10] 2 0x0 0x3: イネーブル

それ以外はディスエーブル (eFUSE がこれよりも優先)

チェックサムの選択 [9:8] 2 0x0 0x0、0x1、0x2: 予約0x3: SHA3 をチェックサムを実行するハッシュ関数として使用

PUF HD [7:6] 2 0x0 0x3: PUF HD はブートヘッダーに格納その他すべて : PUF HDは eFUSE に格納

予約 [5:0] 6 0x0 予約

Versal ACAP イメージヘッダーテーブル次の表に、PDI イメージに関する一般情報を示します。表 21: Versal ACAP イメージヘッダーテーブル

オフセット名前説明0x0 バージョン 0x00030000(v3.0): セキュアチャンクサイズを 64 KB から 32 KB に変更します。

0x00020000(v2.00)

0x4 イメージの合計数 PDI に含まれるイメージの総数。0x8 イメージヘッダーのオフセット最初のイメージヘッダーを開始するアドレス0xC パーティションの合計数 PDI に含まれるパーティションの総数。0x10 パーティションヘッダーのオフセットパーティションヘッダーの開始までのオフセット0x14 セカンダリブートデバイスアドレスセカンダリイメージのあるアドレスを示します。

属性にセカンダリブートデバイスがある場合にのみ使用できます。0x1C イメージヘッダーテーブルの属性表 22: Versal ACAP イメージヘッダーテーブルの属性を参照してください。0x20 PDI ID PDI の識別子0x24 親 ID 初期ブート PDI の ID。ブート PDI の場合、PDI ID と同じになります。0x28 ID 文字列ブートヘッダーが含まれるフル PDI -

FPDIパーシャル/サブシステム PDI – PPDI





表 21: Versal ACAP イメージヘッダーテーブル (続き)

オフセット名前説明0x2C ヘッダーのサイズ 0 〜 7: イメージヘッダーテーブルのサイズ (ワード数)

8 〜 15: イメージヘッダーのサイズ (ワード数)16 〜 23: パーティションヘッダーのサイズ (ワード数)24 〜 31: 予約済み

0x30 メタヘッダーの合計長認証および暗号化オーバーヘッドを含みます (IHT は含まず AC は含む)。0x34 〜 0x3C メタヘッダーの暗号化用の IV ヘッダーテーブルの SH 暗号化用の IV

0x40 暗号化ステータス暗号化キーソース。PLM に使用されるキーソースのみがメタヘッダーで有効になります。0x00000000: 暗号化なし0xA5C3C5A3: eFuse レッドキー0xA5C3C5A5: eFUSE ブラックキー0x3A5C3C5A: BBRAM レッドキー0x3A5C3C59: BBRAM ブラックキー0xA35C7C53: ブートヘッダーブラックキー

0x48 メタヘッダー AC オフセット (ワード) メタヘッダー認証証明へのワードオフセット0x4c メタヘッダーブラック/IV メタヘッダーを暗号化するのに使用したブラックキーを暗号化するのに使用する

IV。0x44 ~ 0x78 予約 0x0

0x7C チェックサムイメージヘッダーテーブルの前のワードの合計

イメージヘッダーテーブルの属性次の表に、イメージヘッダーテーブルについて説明します。表 22: Versal ACAP イメージヘッダーテーブルの属性

ビットフィールド名前説明31:14 予約 0

14 PUF ヘルパーデータのディレクトリ PUF ヘルパーデータ efuse/BH のディレクトリ12 dpacm enable DPA カウンター測定をイネーブルにするかしないかを指定します。





表 22: Versal ACAP イメージヘッダーテーブルの属性 (続き)

ビットフィールド名前説明11:6 セカンダリブートデバイス残りのデータを含めるデバイスを指定します。

0: 同じブートデバイス (デフォルト)1: QSPI322: QSPI243: NAND4: SD05: SD16: SDLS7: MMC8: USB9: ETHERNET10: PCIe11: SATA12: OSPI13: SMAP14: SBI15: SD0RAW16: SD1RAW17: SDLSRAW18: MMCRAW19: MMC020: MMC0RAWその他はすべて予約注記: これらのオプションは、Bootgen のさまざまなデバイスでサポートされます。デバイスでサポートされるセカンダリブートデバイスのリストについては、該当するデバイスの SSDG を参照してください。

5:0 予約

Versal ACAP イメージヘッダーイメージヘッダーは、ELF ファイル、CFI、CDO、データファイルなど、各イメージに関連する情報を含む構造の配列です。各イメージに複数のパーティションを含めることができます。たとえば、ELF には複数のロード可能なセクションを含めることができ、それぞれがブートイメージ内にパーティションを形成します。イメージヘッダーは、このイメージに関連付けられたパーティション (パーティションヘッダー) を指定します。BIF キーワード image を使用すると、複数のパーティションファイルを 1 つのイメージにグループ化できます。これは、共通のサブシステムまたは関数に関連するパーティションを 1 つのグループにまとめるのに便利です。Bootgen は各ファイルに必要なパーティションを作成して、そのイメージに共通のイメージヘッダーを作成します。次の表には、イメージに関連するパーティション数の情報も含まれます。表 23: Versal ACAP イメージヘッダー

オフセット名前説明0x0 第 1 パーティションヘッダー第 1 パーティションヘッダーまでのワードオフセット





表 23: Versal ACAP イメージヘッダー (続き)

オフセット名前説明0x4 パーティションの数このイメージのパーティション数0x8 取り消し ID メタヘッダーの取り消し ID

0xC イメージ属性イメージ属性の表を参照0x10 〜 0x1C イメージの名前イメージの ASCII 名。最大 16 文字まで。パディングが必要な場合は 0 で埋められます。

0x20 イメージ/ノード ID イメージを初期化するリソースノードを定義します。0x24 固有 ID デバイスリソースで必要な場合にアフィニティ/互換性指示子を定義します。0x28 親の固有 ID イメージのコンフィギュレーション内容に必要な親リソース UID を定義します

(必要な場合)。0x2c 関数 ID イメージコンフィギュレーションデータの固有関数をキャプチャするために使用される識別子0x30 イメージコピーの DDR 下位アドレス BIF で memcpy がイネーブルの場合にイメージをコピーする必要のある DDR の下位 32 ビットアドレス0.34 イメージコピーの DDR 上位アドレス BIF で memcpy がイネーブルの場合にイメージをコピーする必要のある DDR の上位 32 ビットアドレス0x38 予約0x3C チェックサム前のワードすべての合計。

次の表に、イメージヘッダーの属性を示します。表 24: Versal ACAP イメージヘッダーの属性

ビットフィールド名前説明31:9 予約 0

8 遅延ハンドオフ 0: イメージを今すぐハンドオフします(デフォルト)。1: イメージを後でハンドオフします。

7 遅延読み込み 0: イメージを今すぐ読み込みます (デフォルト)。1: イメージを後で読み込みます。

6 メモリへのコピー 0: メモリにコピーしません (デフォルト)。1: イメージをメモリにコピーします。

5:3 イメージオーナー 0: PLM (デフォルト)1: PLM 以外2 〜 7: 予約

2:0 予約 0

Versal ACAP パーティションヘッダーパーティションヘッダーには、次の表に示すパーティションの詳細が含まれます。





表 25: Versal ACAP パーティションヘッダーテーブルオフセット名前説明

0x0 パーティションのデータワード長暗号化されたパーティションデータの長さ。0x4 抽出されたデータワード長暗号化されていないデータの長さ。0x8 パーティションの合計ワード長 (認証証明を含む)

暗号化、パディング、拡張、認証を加算した合計長さ。0xC 次のパーティションヘッダーオフセット次のパーティションヘッダーのオフセット。0x10 デスティネーション実行アドレス (下位半分)

ロード後のこのパーティションの実行可能アドレスの下位 32 ビット。0x14 デスティネーション実行アドレス (上位半分)

ロード後のこのパーティションの実行可能アドレスの上位 32 ビット。0x18 デスティネーション読み込みアドレス (下位半分)

このパーティションがロードされる RAMアドレスの下位 32 ビット。ELF ファイルの場合、Bootgen が自動的に ELF フォーマットから読み出されます。RAW データを使用する場合は、読み込み先を指定する必要があります。CFI およびコンフィギュレーションデータの場合は、0xFFFF_FFFF にする必要があります。

0x1C デスティネーション読み込みアドレス (上位半分)このパーティションがロードされる RAMアドレスの上位 32 ビット。ELF ファイルの場合、Bootgen が自動的に ELF フォーマットから読み出されます。RAW データを使用する場合は、読み込み先を指定する必要があります。CFI およびコンフィギュレーションデータの場合は、0xFFFF_FFFF にする必要があります。

0x20 イメージのデータワードオフセットブートイメージの開始に対するパーティションデータの位置。0x24 属性ビットパーティション属性の表を参照。0x28 セクション数イメージタイプが ELF の場合は、この

ELF にさらにいくつのパーティションが関連付けられているかが示されます。0x2C チェックサムワードオフセットブートイメージ内のチェックサムワードの位置。0x30 パーティション ID パーティション ID。0x34 認証証明ワードオフセットブートイメージ内の認証証明の位置。

0x38 〜 0x40 IV パーティションのセキュアヘッダー用IV。





表 25: Versal ACAP パーティションヘッダーテーブル (続き)

オフセット名前説明0x44 暗号化キーセレクト暗号化ステータス:

0x00000000: 暗号化なし0xA5C3C5A3: eFuse レッドキー0xA5C3C5A5: eFuse ブラックキー0x3A5C3C5A: BBRAM レッドキー0x3A5C3C59: BBRAM ブラックキー0xA35C7C53: ブートヘッダーブラックキー0xC5C3A5A3: ユーザーキー 00xC3A5C5B3: ユーザーキー 10xC5C3A5C3: ユーザーキー 20xC3A5C5D3: ユーザーキー 30xC5C3A5E3: ユーザーキー 40xC3A5C5F3: ユーザーキー 50xC5C3A563: ユーザーキー 60xC3A5C573: ユーザーキー 70x5C3CA5A3: eFuse ユーザーキー 00x5C3CA5A5: eFuse ユーザーブラックキー 00xC3A5C5A3: eFuse ユーザーキー 10xC3A5C5A5: eFuse ユーザーブラックキー 1

0x48 ブラック IV そのパーティションのキーを暗号化するために使用される IV。0x54 取り消し ID パーティション取り消し ID

0x58 〜 0x78 予約 0

0x7C ヘッダーチェックサムパーティションヘッダーの以前のワードの合計値。

次の表に、パーティションヘッダーテーブルの属性をリストします。表 26: Versal ACAP パーティションヘッダーテーブル属性

ビットフィールド名前説明31:29 予約 0x0

28:27 DPA CM イネーブル 0: ディスエーブル1: イネーブル

26:24 パーティションタイプ 0: 予約1: ELF2: コンフィギュレーションデータオブジェクト3: Cframe データ (PL データ)4: 生のデータ5: 生の ELF6: CFI GSR CSC アンマスクフレーム7: CFI GSR CSC マスクフレーム





表 26: Versal ACAP パーティションヘッダーテーブル属性 (続き)

ビットフィールド名前説明23 HiVec RPU/APU (32 ビット) プロセッサの

VInitHi 設定0: LoVec1: HiVec

22:19 予約 0

18 エンディアン 0: リトルエンディアン (デフォルト)1: ビッグエンディアン

17:16 パーティションオーナー 0: PLM (デフォルト)1: PLM 以外2、3: 予約

15:14 PUF HD の場所 0: eFuse1: ブートヘッダー

13:12 チェックサムタイプ 000b: チェックサムなし (デフォルト)011b: SHA3

11:8 デスティネーション CPU 0: なし (ELF 以外のファイルのデフォルト)1: A72-02: A72-13: 予約4: 予約5: R5-06: R5-17: R5-L8: PSM9: AIE10 〜 15: 予約

3 A72 CPU 実行ステート 0: Aarch64 (デフォルト)1: Aarch32

2:1 A72 コアを設定する必要のある例外レベル (EL)00b: EL001b: EL110b: EL211b: EL3 (デフォルト)

0 TZ セキュアパーティション 0: 非セキュア (デフォルト)1: セキュアこのビットは、PLM を設定する必要のある (このパーティションを実行する必要のある) コアを TrustZone セキュアとして設定するかしないかを指定します。デフォルトではこれは 0 になっているはずです。





Versal ACAP 認証証明認証証明は、パーティションの認証に関連するすべての情報を含む構造です。この構造には、公開キーと、bootROM/PLM による検証が必要な署名が含まれます。各認証証明には認証ヘッダーがあります。このヘッダーは、キーサイズ、署名に使用するアルゴリズムなどの情報を提供します。ほかのデバイスとは異なり、認証証明は認証が有効になっているパーティションの先頭に追加されます。Bootgen でメタヘッダーに対して認証を実行するには、metaheader BIF 属性で明示的に指定します。使用方法の詳細は、第 8 章: BIF 属性のリファレンスを参照してください。Versal ACAP では RSA-4096 認証および認証用の ECDSA アルゴリズムが使用されます。次の表に、Versal ACAP の認証証明のフォーマットを示します。表 27: Versal ACAP 認証証明 – ECDSA p384

認証証明ビット説明0x00 認証ヘッダー。Versal ACAP 認証証明ヘッダーを参照してください。0x04 Revoke ID


0x40 PPK x (48 バイト)

y (48 バイト)

パッド 0x00 (932 バイト)

0x444 PPK SHA3 パッド (12 バイト)

0x450 SPK x (48 バイト)

y (48 バイト)

パッド 0x00 (932 バイト)

0x854 SPK SHA3 パッド (4 バイト)

0x858 アライメント (8 バイト)

0x860 SPK 署名 (r+s+パッド)(48+48+416))

0xA60 BH/IHT 署名 (r+s+パッド)(48+48+416))

0xC60 パーティション署名 (r+s+パッド)(48+48+416))

表 28: Versal ACAP 認証証明 – ECDSA p521



0x40 PPK PPK x (66 バイト)

y (66 バイト)

パッド 0x00 (896 バイト)


0x450 SPK SPK x (66 バイト)

y (66 バイト)

パッド 0x00 (896 バイト)






表 28: Versal ACAP 認証証明 – ECDSA p521 (続き)

認証証明ビット説明0x858 アライメント (8 バイト)

0x860 SPK 署名 (r+s+パッド)(66+66+380))

0xA60 BH/IHT 署名 (r+s+パッド)(66+66+380))

0xC60 パーティション署名 (r+s+パッド)(66+66+380))

表 29: Versal ACAP 認証証明 – RSA



0x40 PPK Mod (512 バイト)

Mod Ext (512 バイト)

Exponent (4 バイト)



Mod Ext (512 バイト)

Exponent (4 バイト)


0x858 アライメント (8 バイト)

0x860 SPK 署名0xA60 BH/IHT 署名0xC60 パーティション署名

Versal ACAP 認証証明ヘッダー次の表に、Versal ACAP の認証証明ビットフィールドを示します。表 30: 認証ヘッダービットフィールド

ビットフィールド説明注記31:16 予約 0

15 〜 14 認証証明フォーマット 00: RSAPSS

13 〜 12 認証証明バージョン 00: 現在の AC

11 PPK キータイプ 0: ハッシュキー10 〜 9 PPK キーソース 0: eFUSE

8 SPK イネーブル 1: SPK イネーブル7 〜 4 公開キー強度 0: ECDSA p384

1: RSA 40962: ECDSA p521

3 〜 2 ハッシュアルゴリズム 1: SHA3





表 30: 認証ヘッダービットフィールド (続き)

ビットフィールド説明注記1 〜 0 公開キーアルゴリズム 1: RSA

2: ECDSA

注記:1. ブートローダーパーティション:

a. AC のオフセット 0xA60 にはブートヘッダー署名が含まれます。b. AC のオフセット 0xC60 には PLM および PMCDATA 署名が含まれます。

2. ヘッダーテーブル:a. AC のオフセット 0xA60 には IHT 署名が含まれます。b. AC のオフセット 0xC60 には IHT 以外のすべてのヘッダーの署名が含まれます。

3. その他のパーティション:a. AC のオフセット 0xA60 は 0 で埋められます。b. AC のオフセット 0xC60 にはそのパーティションの署名が含まれます。





第 3 章

ブートイメージの作成ブートイメージフォーマット (BIF)

ザイリンクスのブートイメージレイアウトには、ファイル、ファイルの種類、およびサポートするヘッダーが複数あり、これらのファイルはブートローダーによって解析されます。Bootgen は、ブートイメージを生成するための属性を定義し、ファイルで渡された値に基づいて解釈してブートイメージを生成します。使用可能なコマンドと属性は複数あるため、Bootgen はそれらの入力を含むブートイメージフォーマット (BIF) を定義します。BIF は次のもので構成されています。• セキュア/非セキュアブートイメージを作成するためのコンフィギュレーション属性• ブートローダー

○ Zynq® デバイスおよび Zynq® UltraScale+™ MPSoC の第 1 段階ブートローダー (FSBL)

○ Versal™ ACAP のプラットフォームローダーおよびマネージャー (PLM)

• 1 つまたは複数のパーティションイメージBootgen は、プロパティおよび属性に加えて、複数のコマンドを使用してビヘイビアーを定義し、ブートイメージを作成します。たとえば、認定されている FPGA デバイス、Zynq®-7000 SoC デバイス、Versal™ ACAP または Zynq®

UltraScale+™ MPSoC デバイスのブートイメージを作成するには、Bootgen に適切な arch コマンドオプションを指定する必要があります。次の付録で、Bootgen ビヘイビアーを指示する際に使用可能なオプションをリストして説明しています。• 第 7 章: ユースケースおよび例• 第 8 章: BIF 属性のリファレンス• 第 9 章: コマンドリファレンスBIF は、ハードウェア要件とソフトウェア要件の両方に対応します。ブートヘッダーは、1 つのパーティション (通常はブートローダー) をロードする bootROM ローダーで必要です。その他のブートイメージは、ブートローダーによってロードされて処理されます。Bootgen は一連のパーティションを組み合わせてブートイメージを生成します。次のパーティションが考えられます。• FSBL または PLM

• U-Boot といった SSBL (第 2 段階ブートローダー)

• ビットストリーム、PL、.cfi、または .npi データ• Linux

• プロセッサ上で実行するソフトウェアアプリケーション• ユーザーデータ

第 3 章: ブートイメージの作成




• Bootgen で生成されたブートイメージ。これは、前に生成されたブートイメージに新しいパーティションを追加する際に便利です。

BIF 構文およびサポートされるファイルの種類BIF ファイルは、ブートイメージの各コンポーネントをブート順に指定し、オプションで各イメージコンポーネントに属性を適用できるようにします。イメージコンポーネントがメモリ内で連続していない場合、コンポーネントは複数のパーティションにマップできます。たとえば、ELF ファイルに複数のロード可能な非連続のセクションが含まれる場合、各セクションを個別のパーティションにすることができます。BIF ファイルの構文は次の形式となります。new_bif:{ id = 0x5 id_code = 0x04ca8093 extended_id_code = 0x01 image { name = pmc_subsys, id = 0x1c000001 partition { id = 0x11, type = bootloader, file = /path/to/plm.elf } partition { type = pmcdata, load = 0xf2000000, file = /path/to/pmc_cdo.bin } }}

注記: 上記の形式は、Versal™ デバイスにのみ使用できます。<image_name>:{ // common attributes [attribute1] <argument1> // partition attributes [attribute2, attribute3=<argument>] <elf> [attribute2, attribute3=<argument>, attibute4=<argument] <bit> [attribute3] <elf> <bin>}

• <image_name> と {...} (グループ化) を使用し、ROM 内のパーティションに分類するファイルをまとめます。• {...} には 1 つまたは複数のデータファイルがリストされます。• 各パーティションのデータファイルには、ファイル名の前に構文 [attribute, attribute=<argument>] を使用して、オプションの属性を指定できます。

• 属性によって、データファイルに何らかの特性が適用されます。• 複数の属性がある場合は、カンマ (,) で区切って並べることができます。その場合の順序は重要ではありません。属性は、1 つのキーワードまたはクォーテーションで囲んだ複数のキーワードとなります。





• 現在のディレクトリにファイルがない場合は、ファイル名を含むファイルパスを追加できます。ファイルのリスト方法は自由形式で、1 行にすべてをリスト (スペースで区切る、最低 1 スペースは必要) しても、1 つずつと改行してもかまいません。

• スペースは無視されるため、読みやすいように追加しても問題ありません。• C 形式のブロックコメント /*...*/、または C++ 形式の行コメント // を使用できます。





次に、読みやすいように空白と改行を追加した BIF の例を示します。<bootimage_name>:{ /* common attributes */ [attribute1] <argument1> /* bootloader */ [attribute2, attribute3, attribute4=<argument> ] <elf> /* pl bitstream */ [ attribute2, attribute3, attribute4=<argument>, attibute=<argument> ] <bit> /* another elf partition */ [ attribute3 ] <elf> /* bin partition */ <bin>}

Bootgen でサポートされるファイル次の表に、Bootgen でサポートされるファイルを示します。表 31: Bootgen でサポートされるファイルサポートされるデバイス拡張子説明注記

すべてのデバイスでサポート

.bin バイナリ未処理のバイナリファイル。

.dtb バイナリ未処理のバイナリファイル。image.gz バイナリ未処理のバイナリファイル。.elf 実行可能リンクファイル

(ELF)シンボルとヘッダーを除く。

.int レジスタ初期化ファイル

.nky AES キー

.pub/.pem RSA キー

.sig 署名ファイル Bootgen または HSM によって生成される署名ファイル。

Versal

.cfi/.rcfi CFI ファイル Versal デバイスのみ。

.cdo/.rcdo/.npi/ .rnpi CDO ファイルコンフィギュレーションデータオブジェクトファイル。Versal デバイスのみ。

.bin/.pdi ブートイメージ Bootgen を使用して生成したブートイメージ。Zynq-7000/Zynq UltraScale+MPSoC/FPGA

.bit/.rbt ビットストリーム BIT ファイルヘッダーを除く。





Versal ACAP デバイスの BIF 構文次の例に、パーティションをまとめて BIF を詳細に記述する方法を示します。BIF 構文は Versal ACAP 用に変更されており、複数のパーティションをまとめて 1 つのイメージを形成するサブシステムのコンセプト (1 つのイメージヘッダーのサブシステムとも呼ばれる) がサポートされるようになっています。new_bif:{ id_code = 0x04ca8093 extended_id_code = 0x01 id = 0x2 image { name = pmc_subsys id = 0x1c000001 partition { id = 0x01 type = bootloader file = gen_files/executable.elf } partition { id = 0x09 type = pmcdata, load = 0xf2000000 file = topology_xcvc1902.v2.cdo file = gen_files/pmc_data.cdo } } image { name = lpd id = 0x4210002 partition { id = 0x0C type = cdo file = gen_files/lpd_data.cdo } partition { id = 0x0B core = psm file = static_files/psm_fw.elf } } image { name = pl_cfi id = 0x18700000 partition { id = 0x03 type = cdo file = system.rcdo } partition { id = 0x05 type = cdo file = system.rnpi }





} image { name = fpd id = 0x420c003 partition { id = 0x08 type = cdo file = gen_files/fpd_data.cdo } }}

次の例に、パーティションをまとめて BIF を簡潔に記述する方法を示します。new_bif:{ id_code = 0x04ca8093 extended_id_code = 0x01 id = 0x2 image { name = pmc_subsys, id = 0x1c000001 { id = 0x01, type = bootloader, file = gen_files/executable.elf } { id = 0x09, type = pmcdata, load = 0xf2000000, file = topology_xcvc1902.v2.cdo, file = gen_files/pmc_data.cdo } } image { name = lpd, id = 0x4210002 { id = 0x0C, type = cdo, file = gen_files/lpd_data.cdo } { id = 0x0B, core = psm, file = static_files/psm_fw.elf } } image { name = pl_cfi, id = 0x18700000 { id = 0x03, type = cdo, file = system.rcdo } { id = 0x05, type = cdo, file = system.rnpi } } image { name = fpd, id = 0x420c003 { id = 0x08, type = cdo, file = gen_files/fpd_data.cdo } }}

属性次の表に、Bootgen の属性を示します。この表では簡単な説明を記載しており、詳細は各属性のリンクをクリックすると参照できます。アーキテクチャ名は、属性を使用するザイリンクスデバイスを示します。• zynq: Zynq-7000 SoC デバイス• zynqmp: Zynq® UltraScale+™ MPSoC デバイス• fpga: 7 シリーズおよびそれ以上のデバイス





• versal: Versal™ ACAP

詳細は、第 8 章: BIF 属性のリファレンスを参照してください。表 32: Bootgen の属性と説明

オプション/属性説明属性を使用するデバイスaarch32_mode 32 ビットモードで実行されるバイナリファイルを指定します。 zynqmp

versal

aeskeyfile <aes_key_filepath> AES キーファイルへのパスです。キーファイルには、パーティションの暗号化に使用される AES キーが含まれます。ファイルの内容は eFUSE または BBRAM に書き込む必要があります。キーファイルが指定されたパスに存在しない場合、Bootgen が暗号化に使用される新しいキーを生成します。たとえば BIF ファイルでビットストリームの暗号化を選択した場合、出力は暗号化されたビットストリームとなります。

すべて

a_hwrot 非対称ハードウェアの信頼のルート (A-HWRoT) ブートモード。Bootgen で A-HWRoT ブートモードのデザインルールがチェックされます。プロダクション PDI でのみ有効です。versal

alignment <byte> バイトアライメントを設定します。パーティションは、この値の倍数値に揃えられるまでパディングされます。この属性はオフセットと共に使用することはできません。zynqzynqmp

auth_params <options> 認証の追加オプションは次のとおりです。ppk_select: 0 = 2 つの PPK のうち 1 つをサポート、1 = 2つの PPK のうち 1 つをサポート。spk_id: SPK を識別するための 32 ビット ID。spk_select: SPK とユーザー eFUSE を識別。デフォルトは spk-efuse。header_auth: パーティションが認証されていない場合のヘッダーを認証。

zynqmp

authentication <option> 認証されるパーティションを指定します。Zynq の認証は、RSA-2048 を使用して実行されます。Zynq UltraScale+ MPSoC の認証は、RSA-4096 を使用して実行されます。Versal ACAP の認証は、RSA-4096 を使用して実行されます。

引数は次のとおりです。none: パーティションは署名されません。ecdsa-p384: パーティションは ecdsa-p384 を使用して署名されます。ecdsa-p521: パーティションは ecdsa-p521 を使用して署名されます。rsa: パーティションは RSA アルゴリズムを使用して署名されます。

すべて

bbram_kek_iv 該当するキーを暗号化するために使用する IV を指定します。bbram_kek_iv は、keysrc=bbram_blk_key の場合にのみ有効です。

versal

bh_kek_iv 該当するキーを暗号化するために使用する IV を指定します。bh_kek_iv は、keysrc=bh_blk_key の場合にのみ有効です。 versal





表 32: Bootgen の属性と説明 (続き)

オプション/属性説明属性を使用するデバイスbh_key_iv <filename> 難読化キーまたはブラックキーを復号化する際に使用する初期化ベクター。 zynqmp

bh_keyfile <filename> ブートヘッダーに格納される 256 ビットの難読化キーまたはブラックキー。これは、暗号化の keysrc が bh_gry_key または bh_blk_key の場合にのみ有効です。注記: 難読化キーは、Versal デバイスではサポートされません。

zynqmpversal

bhsignature <filename> ブートヘッダーの署名を認証証明にインポートします。これは、秘密キー PSK を共有しない場合に使用できます。署名を作成して Bootgen に供給できます。ファイルフォーマットは bootheader.sha384.sig です。zynqmpversal

big_endian バイナリファイルをビッグエンディアン形式に指定します。zynqmpversal

blocks <block sizes> 暗号化の際のキーローリング機能のブロックサイズを指定します。各モジュールは独自のキーを使用して暗号化されます。最初のキーはデバイスのキーソースで格納され、後続の各ブロックのキーは直前のモジュール内で暗号化 (ラップ) されます。

zynqmpversal

boot_config <options> ブートイメージのコンフィギュレーションに使用するパラメーターを指定します。 versal






オプション/属性説明属性を使用するデバイスboot_device <options> セカンダリブートデバイスを指定します。パーティションが存在するデバイスを示します。オプションは次のとおりです。

qspi32qspi24nandsd0sd1sd-lsmmcusbethernetpciesataospismapsbisd0-rawsd1-rawsd-ls-rawmmc-rawmmc0mmc0-raw

注記: これらのオプションは、Bootgen のさまざまなデバイスでサポートされます。セカンダリブートオプションのリストは、『Versal ACAP システムソフトウェア開発者向けガイド』(UG1304) を参照してください。ハードウェア/レジスタ/インターフェイス情報およびプライマリブートモードについては、該当するテクニカルリファレンスマニュアルを参照してください。

zynqmpversal

bootimage <filename.bin> リストされた入力ファイルが Bootgen によって作成されたブートイメージであることを示します。 zynqzynqmpversal

bootloader <partition> パーティションがブートローダー (FSBL/PLM) であることを指定します。この属性は、ほかのパーティションの BIF 属性と共に指定されます。zynqzynqmpversal

bootvectors <vector_values> XIP (eXecute In Place) のベクターテーブルを指定します。zynqmp



https://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug1304-versal-acap-ssdg.pdf




オプション/属性説明属性を使用するデバイスchecksum <options> パーティションのチェックサムが必要であることを指定します。このオプションを認証や暗号化などのよりセキュアな機能と共に使用することはできません。チェックサムアルゴリズムは次のとおりです。

none: チェックサムなし。md5: Zynq®-7000 SoC デバイスの場合。sha3: Zynq® UltraScale+™ MPSoC および Versal デバイスの場合。

注記: Zynq デバイスでは、ブートローダーのチェックサムはサポートされません。Zynq UltraScale+ MPSoC およびVersal ACAP ではブートローダーのチェックサムがサポートされます。

zynqzynqmpversal

copy イメージがメモリの指定したアドレスにコピーされます。versal

core <options> パーティションをどのコアで実行するかを指定します。次のオプションがあります。*a72-0a72-1r5-0r5-1psmaie

versal

delay_handoff <delay_handoff> サブシステム/イメージへのハンドオフを遅延します。versal

delay_load <delay_load> サブシステム/イメージの読み込みを遅延します。versal

destination_device <device_type> パーティションのターゲットを PS または PL のいずれかに指定します。次のオプションがあります。ps: パーティションのターゲットは PS (デフォルト)。pl: パーティションのターゲットは PL (ビットストリームの場合)。

zynqmp

destination_cpu <device_core> パーティションを実行するコアを指定します。a53-0a53-1a53-2a53-3r5-0 (デフォルト)r5-1pmur5-lockstep

zynqmp






オプション/属性説明属性を使用するデバイスearly_handoff このフラグは、パーティションのロード直後に重要なアプリケーションへのハンドオフが確実に実行されるようにします。このオプションを使用しない場合は、最初にすべてのパーティションが順にロードされ、続いてハンドオフが順に実行されます。

zynqmp

efuse_kek_iv 該当するキーを暗号化するために使用する IV を指定します。efuse_kek_iv は、keysrc=efuse_blk_key の場合にのみ有効です。

versal

efuse_user_kek0_iv 該当するキーを暗号化するために使用する IV を指定します。efuse_user_kek0_iv は、keysrc=efuse_user_blk_key0 の場合にのみ有効です。

versal

efuse_user_kek1_iv 該当するキーを暗号化するために使用する IV を指定します。efuse_user_kek1_iv は、keysrc=efuse_user_blk_key1 の場合にのみ有効です。

versal

encryption <option> 暗号化するパーティションを指定します。使用される暗号化アルゴリズムは、zynq では AES-CBC、zynqmp および Versalでは AES-GCM です。パーティションのオプションは次のとおりです。

none: パーティションは暗号化されない。aes: パーティションは AES アルゴリズムを使用して暗号化される。

すべて

exception_level <options> コアに設定する例外レベルを指定します。オプションは次のとおりです。

el-0el-1el-2el-3

zynqmpversal

familykey ファミリキーを指定します。zynqmpfpga

file <path/to/file> パーティションを作成するためのファイルを指定します。versal






オプション/属性説明属性を使用するデバイスfsbl_config ブートイメージのコンフィギュレーションに使用するサブ属性を指定します。サブ属性は次のとおりです。

bh_auth_enable: PPK ハッシュと SPK ID の検証を除くブートイメージの RSA 認証を実行します。auth_only: ブートイメージの RSA 署名のみを実行します。FSBL の復号化は実行しません。opt_key: block-0 の復号化に操作キーを使用します。操作キーはセキュアヘッダーにあります。pufhd_bh: PUF ヘルパーデータをブートヘッダーに格納します (デフォルトは efuse)。PUF ヘルパーデータファイルは、[puf_file] オプションを使用して Bootgen に渡されます。puf4kmode: PUF を 4k ビットコンフィギュレーションでの使用に合わせて調整します (デフォルトは 12k ビット)。shutter = <value>: PUF でシャッターオフセット時間およびシャッターオープン時間を設定する 32 ビットの PUF_SHUT レジスタ値を指定します。このシャッター値は、PUF 登録中に使用されたシャッター値と一致している必要があります。

zynqmp

headersignature <signature_file> ヘッダーの署名を認証証明にインポートします。これは、秘密キーを共有しない場合に使用できます。署名を作成してBootgen に供給できます。

zynqzynqmpversal

hivec 例外ベクターテーブルの場所を hivec (Hi-Vector) として指定します。デフォルトは lovec (Low-Vector) です。これは、A53 (32 ビット) および R5 コアにのみ適用されます。

hivec: 0xFFFF0000 の例外ベクターテーブル。lovec: 0x00000000 の例外ベクターテーブル。

zynqmpversal

id = <id> 定義した場所に基づいて次の ID を指定します。• pdi id: 一番外側の PDI かっこ内• image id: イメージかっこ内• partition id: パーティションかっこ内

versal

image サブシステム/イメージを定義します。versal

init <filename> ブートローダーの最後にあるレジスタ初期化ブロックであり、init (.int) ファイルの仕様を解析して構築されます。最大256 のアドレスと値の初期化ペアが許可されます。init ファイルには特定のフォーマットがあります。

zynqzynqmpversal






オプション/属性説明属性を使用するデバイスkeysrc Versal ACAP の暗号化のキーソースを指定します。keysrcは、パーティションごとに指定できます。

efuse_red_keyefuse_blk_keybbram_red_keybbram_blk_keybh_blk_keyuser_key0user_key1user_key2user_key3user_key4user_key5user_key6user_key7efuse_user_key0efuse_user_blk_key0efuse_user_key1efuse_user_blk_key1

versal

keysrc_encryptionefuse_gry_key: eFUSE に格納されているグレー (難読化) キー。グレー/難読化キーを参照してください。bh_gry_key: ブートヘッダーに格納されているグレー(難読化) キー。bh_blk_key: ブートヘッダーに格納されているブラックキー。ブラックキー/PUF キーを参照してください。efuse_blk_key: eFUSE に格納されているブラックキー。kup_key: ユーザーキー。efuse_red_key: eFUSE に格納されているレッドキー。キーの差し替えを参照してください。bbram_red_key: BBRAM に格納されているレッドキー。

zynqzynqmp

load <partition_address> メモリ内のパーティションのロードアドレスを設定します。zynqzynqmpversal

metaheader キー、キーソースなどのメタヘッダーの暗号化および認証属性を定義するために使用します。暗号化に使用するキーソースを指定します。キーは次のとおりです。versal

name <name> イメージ/サブシステムの名前を指定します。versal

load <offset_address> ブートイメージ内のパーティションの絶対オフセットを設定します。 zynqzynqmpversal

parent_id=<id> 親 PDI の ID を指定します。親 PDI とそれに該当するブートPDI 間の関係を識別するために使用します。 versal






オプション/属性説明属性を使用するデバイスpartition パーティションを定義します。BIF を短く読みやすくするためのオプションの属性です。 versal

partition_owner、owner <option> パーティションをロードするパーティションオーナー。オプションは次のとおりです。fsbl: パーティションは FSBL によってロードされます。uboot: パーティションは U-Boot によってロードされます。

versal

plm: パーティションは PLM によってロードされます。non-plm: パーティションは PLM によってロードされませんが、U-Boot のような別のエンティティでロードされます。

zynqzynqmpversal

pid <ID> パーティション ID を指定します。PID は 32 ビット値 (0〜0xFFFFFFFF) に設定できます。 zynqmp

pmufw_image <image_name> FSBL をロードする前に bootROM によってロードされるPMU ファームウェアイメージです。 zynqmp

ppkfile <key filename> プライマリ公開キー (PPK)。ブートイメージ内のパーティションの認証に使用します。詳細は、認証の使用を参照してください。

zynqzynqmpversal

presign <sig_filename> パーティション署名 (.sig) ファイル。zynqzynqmpfpga

pskfile <key filename> プライマリ秘密キー (PSK)。ブートイメージ内のパーティションの認証に使用します。詳細は、認証の使用を参照してください。

zynqzynqmpversal

puf_file <filename> PUF ヘルパーデータファイル。PUF は、暗号化キーソースとしてブラックキーと共に使用されます。PUF ヘルパーデータは 1544 バイトです。1536 バイトの PUF HD + 4 バイトの HASH + 3 バイトの AUX + 1 バイトアライメント。zynqmpversal

reserve <size in bytes> パーティションのメモリサイズを維持します。このサイズになるまでパーティションにパディングが追加されます。 zynqzynqmpversal

s_hwrot 非対称ハードウェアの信頼のルート (S-HWRoT) ブートモード。Bootgen で S-HWRoT ブートモードのデザインルールがチェックされます。プロダクション PDI でのみ有効です。versal

spk_select <SPK_ID> ユーザー eFUSE の SPK ID を指定します。zynqmp

spkfile <filename> ブートイメージ内のパーティションの認証に使用するキーです。詳細は、認証の使用を参照してください。SPK はセカンダリ公開キーです。すべて






オプション/属性説明属性を使用するデバイスspksignature <signature_file> SPK の署名を認証証明にインポートします。認証の使用を参照してください。これは、秘密キー (PSK) を共有しない場合に使用できます。署名を作成して Bootgen に供給できます。

zynqzynqmpversal

split <options> モードに基づいてイメージを分割します。split オプションは次のとおりです。slaveboot: Zynq UltraScale+ MPSoC でのみサポートされています。次のように分割します。ブートヘッダー + ブートローダーイメージヘッダーおよびパーティションヘッダー残りのパーティションnormal: zynq、zynqmp、および versal でサポートされています。次のように分割します。ブートヘッダー + イメージヘッダー + パーティションヘッダー + ブートローダーPartition1パーティション 2、以下同様

分割 (split) モードでは、出力フォーマットも bin または mcsに設定できます。注記: オプションの split の normal モードは、コマンドラインオプションの split と同じです。このコマンドラインオプションは推奨されていません。split slaveboot は、ZynqUltraScale+ MPSoC でのみサポートされます。

zynqzynqmpversal

sskfile <key filename> セカンダリ秘密キー (SSK) は、ブートイメージ内のパーティションを認証するために使用されます。プライマリキーはセカンダリキーを認証し、セカンダリキーはパーティションを認証します。すべて

startup=<address> ロード後のパーティションのエントリアドレスを設定します。この識別子は、実行しないパーティションでは無視されます。zynqzynqmpversal

TrustZone= <option> TrustZone オプションは次のとおりです。securenonsecure

zynqmpversal

type <options> パーティションのタイプを指定します。次のオプションがあります。bootloaderpmcdatacdocficfi-gscbootimage

versal






オプション/属性説明属性を使用するデバイスudf_bh <data_file> ブートヘッダーのユーザー定義フィールドにコピーされるデータのファイルをインポートします。UDF は、16 進数文字列フォーマットのテキストファイルで提供されます。UDF の総バイト数は、zynq = 76 バイトで、zynqmp = 40 バイトです。

zynqzynqmp

udf_data <data_file> 最大 56 バイトのデータを含むファイルを認証証明のユーザー定義フィールド (UDF) にインポートします。 zynqzynqmp

xip_mode FSBL が QSPI フラッシュから直接実行されるよう XIP(eXecute-In-Place) を示します。 zynq

zynqmp





第 4 章

Bootgen インターフェイスの使用Bootgen には GUI とコマンドラインの 2 つのオプションがあります。GUI オプションは、 Vitis でウィザードとして利用できます。GUI の機能は、ブートイメージを作成する際の最も標準的な機能に限定されます。Bootgen コマンドラインではすべてのコマンドを使用でき、システム用に複雑なブートイメージを作成できます。

Bootgen GUI のオプションVitis™ GUI の [Create Boot Image] ウィザードでは、ブートイメージ生成に使用できる Bootgen オプションに制限があります。注記: Versal™ ACAP の場合、Bootgen GUI のオプションはまだサポートされていません。GUI を使用してブートイメージを作成するには、次の手順に従います。1. [Project Navigator] または [C/C++ Projects] ビューでアプリケーションプロジェクトを選択し、[Create Boot

Image] を右クリックします。または、[Xilinx] → [Create Boot Image] をクリックします。[Create Boot Image] ページが開き、選択した C プロジェクトのコンテキストからあらかじめ選択されているデフォルト値が取り込まれて表示されます。次の点に注意してください。• アプリケーションに対して [Create Boot Image] を初めて実行する場合、このページに FSBL ELF ファイルへのパス、選択したハードウェアのビットストリーム (ハードウェアプロジェクトにある場合)、および選択したアプリケーションの ELF ファイルへのパスが入力されます。

• アプリケーションのブートイメージを既に作成しており、BIF ファイルが存在する場合は、このページに /bif フォルダーからの値が入力されます。

• Zynq®-7000 SoC または Zynq® UltraScale+™ MPSoC アーキテクチャ用のブートイメージを作成できるようになりました。

重要: ブートイメージ用に入力するデータは、オフセットが 0x4c の最大 76 バイト (Zynq-7000 SoCの場合)、およびオフセットが 0x70 の最大 40 バイト (Zynq UltraScale+ MPSoC の場合) である必要があります。これは Zynq アーキテクチャに基づく厳格な制限です。

2. [Create Boot Image] ページに次の情報を入力します。注記: Versal デバイスの場合、Vitis GUI のオプションはまだサポートされていません。a. [Architecture] ドロップダウンから、使用するアーキテクチャを選択します。b. [ Create a BIF file] または [Import an existing BIF file] のいずれかをオンにします。c. [Basic] ビューで、[Output BIF file path] に出力 BIF ファイルへのパスを指定します。d. 該当する場合は、[UDF data] を指定します。このオプションの詳細は、udf_data を参照してください。e. [Output path] に出力パスを指定します。

第 4 章: Bootgen インターフェイスの使用




3. [Boot image partitions] で [Add] をクリックし、その他のパーティションイメージを追加します。4. 必要に応じて、ブートイメージ内のパーティションのオフセット値、アラインメント値、および割り当て値を作

成します。デフォルトでは、出力ファイルのパスは選択したアプリケーションプロジェクトの /bif フォルダーに設定されます。

5. [Security] ビューで、セキュアイメージを作成するための属性を指定できます。このセキュリティは、必要に応じて個々のパーティションに適用できます。a. パーティションの認証を有効にするには、[Use Authentication] をオンにし、[PPK]、[SPK]、[PSK]、および

[SSK] の値を指定します。詳細は、認証を参照してください。b. パーティションの暗号化を有効にするには、[Encryption] ビューを選択し、[Use Encryption] をオンにします。詳細は、暗号化の使用を参照してください。

6. ブートローダーから開始して、BIF ファイルのブートイメージを 1 つずつ作成またはインポートします。パーティションリストには、BIF ファイル内のパーティションの概要が表示されます。ファイルパス、暗号化設定、および認証設定が表示されます。この領域を使用して、パーティションの追加、削除、変更、並べ替えを実行します。また、暗号化、認証、チェックサムを有効にするための値を設定し、[Load]、[Alignment]、[Offset] など、一部のその他のパーティションに関連する値を指定することもできます。

コマンドラインで Bootgen を使用コマンドラインで Bootgen オプションを指定すると、GUI で提供されるオプションよりも多くのオプションを利用できます。Vitis ソフトウェアプラットフォームの標準インストールでは、XSCT (ザイリンクスソフトウェアコマンドラインツール) が対話型のコマンドライン環境として入手可能で、これをスクリプト作成に使用することもできます。XSCT では、Bootgen コマンドを実行できます。XSCT は別のツールである Bootgen 実行ファイルにアクセスします。この Bootgen 実行ファイルは、Bootgen のインストールで説明されているように、スタンドアロンでインストールできます。これは XSCT から呼び出されるツールと同じものなので、ここで開発されたスクリプトまたは XSCTで作成されたスクリプトは、いずれもどちらのツールでも動作します。このツールの説明は、『Vitis 統合ソフトウェアプラットフォームの資料』 (UG1416) のエンベデッドソフトウェア開発フローのザイリンクスソフトウェアコマンドラインツールを参照してください。XSCT で Bootgen コマンドを使用する例は、「XSCT ユースケース」の章を参照してください。

コマンドおよび説明次の表に、Bootgen コマンドオプションを示します。各オプションは、一番左の列にあるリンクから詳細な説明を参照できます。その右側の列には簡単な説明を記載しています。アーキテクチャ名は、コマンドを使用するザイリンクスデバイスを示します。• zynq: Zynq®-7000 SoC デバイス• zynqmp: Zynq® UltraScale+™ MPSoC デバイス• fpga: 7 シリーズおよびそれ以上のデバイス• versal: Versal™ ACAP

詳細は、第 9 章: コマンドリファレンスを参照してください。



https://japan.xilinx.com/cgi-bin/docs/rdoc?t=vitis+doc;v=2020.2;d=jed1590410655455.html



表 33: Bootgen コマンドおよび説明コマンド説明およびオプションコマンドを使用するデバイス

arch <type> ザイリンクスデバイスアーキテクチャ: オプションは次のとおりです。zynq (デフォルト)zynqmpfpgaversal

すべて

bif_help BIF ヘルプサマリをプリントアウトします。すべてdual_qspi_mode <configuration> Dual QSPI コンフィギュレーションの場合は 2 つの出力ファイルを生成します。

parallelstacked <size>

zynqzynqmpversal

dual_ospi_mode stacked <size> スタックドコンフィギュレーションの場合は 2 つの出力ファイルを生成します。 versal

dump <options> オプションを指定するたびにパーティションまたはブートヘッダーをダンプします。empty: パーティションをバイナリファイルとしてダンプします。bh: ブートヘッダーをバイナリファイルとしてダンプします。plm: PLM をバイナリファイルとしてダンプします。pmc_cdo: PMC CDO をバイナリファイルとしてダンプします。boot_files: ブートヘッダー、PLM、および PMCCDO を 3 つのバイナリファイルとしてダンプします。

versal

dump_dir 指定したディレクトリのコンポーネントをダンプします。 versal

efuseppkbits <PPK_filename> eFUSE 用の PPK ハッシュを生成します。zynqzynqmpversal

encrypt <options> デバイス内での AES キーの格納場所。オプションは次のとおりです。bbram (デフォルト)eFuse

zynqfpga

encryption_dump 暗号ログファイル aes_log.txt を生成します。zynqmpversal





表 33: Bootgen コマンドおよび説明 (続き)

コマンド説明およびオプションコマンドを使用するデバイスfill <hex_byte> パディング用に使用するバイトを指定します。

zynqzynqmpversal

generate_hashes パディングされたハッシュを含むファイルを生成します。Zynq デバイス: PKCS#1v1.5 パディングスキームを使用した SHA-2Zynq UltraScale+ MPSoC: PKCS#1v1.5 パディングスキームを使用した SHA-3Versal ACAP: PSS パディングスキームを使用したSHA-3

zynqzynqmpversal

generate_keys <key_type> 認証キーを生成します。オプションは次のとおりです。pemrsaobfuscatedkey

zynqzynqmp

h、help ヘルプサマリをプリントアウトします。すべてimage <filename(.bif)> ブートイメージフォーマット (.bif) ファイルを指定します。すべてlog<level_type> 現在の作業ディレクトリに次のメッセージタイプのログファイルを生成します。

errorwarning (デフォルト)infodebugtrace

すべて

nonbooting 中間のブートイメージを作成します。zynqzynqmp

o <filename> 出力ファイルを指定します。ファイルフォーマットは、ファイル名の拡張子によって決まります。有効な拡張子は次のとおりです。.bin (デフォルト).mcs.pdi

すべて

p <partname> 暗号化キーの生成に使用するパーツ名を指定します。すべて






コマンド説明およびオプションコマンドを使用するデバイスpadimageheader <option> イメージヘッダーをパディングして、続くパーティションを強制的に揃えます。オプションは次のとおりです。

01 (デフォルト)

zynqzynqmp

process_bitstream <option> ビットストリームを .bin または .mcs ファイルのいずれで処理および出力するかを指定します。たとえば BIF ファイルのビットストリームに暗号化を選択した場合、出力は暗号化されたビットストリームとなります。

zynqzynqmp

read <options> オプションに基づいて、ブートヘッダー、イメージヘッダー、およびパーティションヘッダーを読み出すのに使用されます。bh: bootimage からブートヘッダーを人間が読める形式で読み出します。iht: bootimage からイメージヘッダーテーブルを読み出します。ih: bootimage からイメージヘッダーを読み出します。pht: bootimage からパーティションヘッダーを読み出します。ac: bootimage から認証証明を読み出します。

zynqzynqmpversal

authenticatedjtag <options> セキュアブート中に JTAG をイネーブルにします。引数は次のとおりです。rsaecdsa

versal

split <options> ブートイメージをパーティションに分割し、ファイルを .bin または .mcs として出力します。• ブートヘッダー + イメージヘッダー + パーティションヘッダー + Fsbl.elf

• Partition1.bit

• Partition2.elf

zynqzynqmpversal

spksignature <filename> SPK 署名ファイルを生成します。zynqzynqmp

verify このオプションは、ブートイメージの認証を検証するために使用します。ブートイメージ内の認証証明がすべて使用可能なパーティションに対して検証されます。zynqzynqmp

verify_kdf このオプションは、AES キーを生成するために Bootgenで使用される Counter Mode KDF を検証するために使用します。zynqmpversal






コマンド説明およびオプションコマンドを使用するデバイスw <option> 出力ファイルを上書きするかどうかを指定します。

on (デフォルト)off

注記: -w にオプションを指定しない場合は、–w on として解釈されます。

すべて

zynqmpes1 ES1 (1.0) 用のブートイメージを生成します。デフォルトのパディング方式は ES2 (2.0) です。 zynqmp

BIF 属性の詳細は、ヘルプを参照してください。



https://confluence.xilinx.com/display/PSSANONECC/Help+of+BIF+attributes



第 5 章

ブート時のセキュリティザイリンクスでは、最新の認証方法を使用して、すべてのデバイスのセキュアなブートをサポートし、ザイリンクスデバイス上で認証されていないコードまたは変更されたコードが実行されないようにしています。ザイリンクスでは、認証されたプログラムのみがイメージにアクセスするよう、さまざまな暗号化技術をサポートしています。デバイスごとのハードウェアセキュリティ機能の詳細は、次の各セクションを参照してください。

Zynq-7000 SoC デバイスのセキュアモードおよび非セキュアモードセキュリティ上の理由により、PS の全マスターモジュールの中で CPU 0 が最初にリセット状態を終了します。CPU1 は WFE ステートを維持します。bootROM が実行されている間は、安全性を確保するためにリセットの種類に関係なく JTAG は常に無効となります。bootROM の実行が完了した後、ブートモードが非セキュアな場合は JTAG が有効になります。bootROM コードには、FSBL/ユーザーコードをロードする役目もあります。bootROM がステージ 1 へ制御をリリースすると、ユーザーソフトウェアがシステム全体を完全に制御します。bootROM を再度実行するには、システムリセットのいずれかを実行する以外に方法はありません。FSBL/ユーザーコードのサイズは、暗号化/非暗号化ともに192 KB までに制限されています。この制限は、非セキュアの XIP (eXecute-In-Place) オプションを使用する場合は適用されません。PS ブートソースは BOOT_MODE ストラップピン (弱いプルアップまたはプルダウン抵抗で指定) を使用して選択します。このピンは、パワーオンリセット (POR) 時に 1 回サンプリングされます。サンプリングされた値は、slcr.BOOT_MODE レジスタに格納されます。bootROM は暗号化/認証されたイメージ (セキュアブート) と暗号化していないイメージ (非セキュアブート) をサポートしています。また、非セキュアブートイメージのみを対象とした場合、XIP (eXecute-In-Place、xip_mode) オプションを使用してステージ 1 イメージを NOR または Quad-SPI から直接実行できます。XIP (eXecute-In-Place) は、NOR および Quad-SPI ブートモードでのみ利用できます。• セキュアブートの場合、bootROM コードを実行している CPU は、ブートデバイス上のユーザー PS イメージを復号化/認証して OCM に格納した後、このイメージに分岐します。

• 非セキュアブートの場合、bootROM を実行している CPU は、PL 内の AES ユニットなどすべてのセキュアブート機能を無効にした後、OCM メモリまたはフラッシュデバイス (XIP (eXecute-In-Place) を使用した場合) 内のユーザーイメージに分岐します。

これ以降の PS または PL に対するブートステージは開発者であるユーザーの責任で、ユーザー制御下で実行する必要があります。bootROM コードにはユーザーからはアクセスできません。ステージ 1 ブートがセキュアブートの場合、その後のブートステージはセキュアまたは非セキュアのどちらも可能です。ステージ 1 ブートが非セキュアブートの場合、その後のブートステージは非セキュアブートしか実行できません。

Zynq UltraScale+ MPSoC デバイスのセキュリティZynq® UltraScale+™ MPSoC デバイスでは、ハードウェアルートオブトラストのブートメカニズムを使用してセキュアブートが実行されます。これにより、すべてのブートファイルまたはコンフィギュレーションファイルも暗号化されます。このアーキテクチャは、アプリケーションの安全性を最大限に確保するために必要な機密性、完全性、および認証を提供します。

第 5 章: ブート時のセキュリティ




詳細は、『Zynq UltraScale+ デバイステクニカルリファレンスマニュアル』 (UG1085: 英語版、日本語版) のこのセクションを参照してください。

Versal ACAP セキュリティVersal™ ACAP では、セキュアブートにより、デバイスにロードされるファームウェアおよびソフトウェアの機密性、完全性、および認証が保たれるようになっています。ルートオブトラストは、PLM ソフトウェアの認証/復号化を認証する PMC ROM から開始します。PLM ソフトウェアが信頼できるようになったので、PLM でファームウェアおよびソフトウェアの残りが安全な方法でロードされます。また、セキュアブートが必要ない場合でも、ソフトウェアは少なくともシンプルなチェックサムを使用して認証できます。詳細は、『Versal ACAP テクニカルリファレンスマニュアル』 (AM011) を参照してください。

暗号化の使用セキュアブートは、デバイス上のイメージの実行が許可される前にこれらを検証するため、フィールドで展開されているほとんどの電子デバイスにとって不可欠な機能となっています。暗号化については、ザイリンクスでは AES(Advanced Encryption Standard) アルゴリズムによる AES 暗号化をサポートしています。AES では、対称型キー暗号 (暗号化と復号化の両方に対応する 1 つのキー定義) が提供されます。暗号化と復号化の両方を逆の順序で完了する場合も、同じステップが実行されます。AES は反復式の対称型ブロック暗号であり、次のように動作します。• 同じ定義されたステップを複数回繰り返して動作する。• 秘密キーの暗号化アルゴリズムを使用する。• 固定バイト数で動作する。

暗号化プロセスBootgen は、BIF ファイルでユーザーが提供する暗号化コマンドおよび属性に基づいてブートイメージパーティションを暗号化できます。AES は対称キー暗号化手法であり、暗号化および復号化に同じキーを使用します。ブートイメージの暗号化に使用するキーは、デバイスがそのブートイメージでブート中、復号化プロセス用にデバイスで使用可能であることが求められます。一般に、キーは eFUSE または BBRAM のいずれかに格納され、キーソースはブートイメージの作成時に BIF 属性を介して選択できます (次の図参照)。





https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xSecurity

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xSecurity




図 7: 暗号化プロセスの図

Key

AES Encryption

eFUSE

BBRAM

Partition Encrypted Partition

OR

X21274-062320

復号化プロセスSoC デバイスの場合、ブートサイクル中に bootROM および FSBL によってパーティションが復号化されます。bootROM は、フラッシュから FSBL を読み出し、復号化し、ロードし、制御を FSBL に渡します。FSBL の実行が開始されると、残りのパーティションが読み込まれ、復号化され、ロードされます。パーティションの復号化に必要なAES キーは、eFUSE または BBRAM のいずれかから取得できます。暗号化キーのソースを把握するために、ブートイメージ内のブートヘッダーテーブルのキーソースフィールドが読み出されます。暗号化されたパーティションはそれぞれ、AES ハードウェアエンジンを使用して復号化されます。

図 8: 復号化プロセスの図

Key

AES Decryption

eFUSE

BBRAM

Partition Decrypted Partition

OR

X21274-062320





Zynq-7000 デバイスのパーティションの暗号化Zynq®-7000 SoC デバイスは、内蔵型でプログラマブルロジック (PL) ベースの HMAC (Hash-based MessageAuthentication Code)、および Cipher Block Chaining (CBC) モードの Advanced Encryption Standard (AES) モジュールを使用します。

BIF ファイルの例暗号化されたパーティションを持つブートイメージを作成するには、aeskeyfile 属性を使用して BIF で AES キーファイルを指定します。暗号化する BIF ファイルにリストされている各イメージファイルに対して encryption=aes属性を指定します。BIF ファイル (secure.bif) の例を次に示します。image: { [aeskeyfile] secretkey.nky [keysrc_encryption] efuse [bootloader, encryption=aes] fsbl.elf [encryption=aes] uboot.elf}

コマンドラインから、次のコマンドを使用して、暗号化された fsbl.elf および uboot.elf を含むブートイメージを生成します。bootgen -arch zynq -image secure.bif -w -o BOOT.bin

キーの生成Bootgen は AES-CBC キーを生成できます。Bootgen は、BIF で指定された AES キーファイルを使用し、パーティションを暗号化します。キーファイルが空または存在しない場合、Bootgen は BIF ファイルで指定されたファイルにキーを生成します。キーファイルが BIF で指定されておらず、いずれかのパーティションに対して暗号化が要求されている場合、Bootgen は BIF と同じディレクトリに拡張子 .nky の BIF ファイル名を用いたキーファイルを生成します。次に、キーファイルの例を示します。

図 9: キーファイルの例

Zynq MPSoC デバイスのパーティションの暗号化Zynq® UltraScale+™ MPSoC デバイスは、AES-GCM コアを使用します。このコアは 32 ビットワードベースのデータインターフェイスを備えており、256 ビットキーをサポートします。AES-GCM モードは、暗号化と復号化、複数のキーソース、内蔵のメッセージインテグリティチェックをサポートします。

操作キー優れたキー管理の方法の 1 つは、秘密キーの使用を最小限に抑えることです。このためには、Bootgen で有効になっている操作キーオプションを使用します。





Bootgen は、暗号化された安全なヘッダーを作成します。このヘッダーには、ユーザー指定の操作キー (opt_key)と、Bootgen が有効のときにコンフィギュレーションファイルの最初のブロックに必要な初期化ベクトル (IV) が含まれます。このため、BBRAM または eFUSE のいずれかに格納された AES キーは 384 ビットのみで使用され、サイドチャネル攻撃にさらされる可能性が大幅に制限されます。opt_key 属性は、操作キーの使用方法を指定します。fsbl_config 属性の引数である opt_key 値の詳細は、fsbl_config を参照してください。次に、opt_key 属性の使用例を示します。image:{ [fsbl_config] opt_key [keysrc_encryption] bbram_red_key [bootloader, destination_cpu = a53-0, encryption = aes, aeskeyfile = aes_p1.nky]fsbl.elf [destination_cpu = a53-3, encryption = aes, aeskeyfile = aes_p2.nky]hello.elf }

操作キーは、次に示すように、AES キー (.nky) ファイルで Key Opt を使用して指定します。図 10: 操作キー

Bootgen は暗号化キーファイルを生成します。前の例に示すように、BIF ファイルで opt_key が有効になっている場合、操作キー opt_key が .nkyファイルで生成されます。操作キーを使用するその他の例は、開発環境での操作キーを使用したデバイスキーの保護を参照してください。この機能の詳細は、『Zynq UltraScale+ デバイステクニカルリファレンスマニュアル』 (UG1085: 英語版、日本語版)の「セキュリティ」章のキー管理を参照してください。

キーの差し替えAES-GCM は、暗号化されたイメージ全体をより小規模な AES 暗号化ブロック/モジュール単位で表すキー差し替え機能もサポートしています。各モジュールは独自のキーを使用して暗号化されます。最初のキーはデバイスのキーソースで格納され、後続の各モジュールのキーは直前のモジュール内で暗号化 (ラップ) されます。キー差し替えをサポートするブートイメージは、Bootgen を使用して生成できます。BIF の属性 (blocks) を使用して、暗号化用に複数の小さなブロックを作成するためのパターンを指定します。image:{ [keysrc_encryption] bbram_red_key [ bootloader,





https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xKeyManagement



destination_cpu = a53-0, encryption = aes, aeskeyfile = aes_p1.nky, blocks = 1024(2);2048;4096(2);8192(2);4096;2048;1024 ] fsbl.elf [ destination_cpu = a53-3, encryption = aes, aeskeyfile = aes_p2.nky, blocks = 4096(1);1024 ] hello.elf}

注記:

• キーファイル内のキーの数は、暗号化されるブロックの数と常に一致する必要があります。○ キーの数が暗号化されるブロック数より少ない場合、Bootgen はエラーを返します。○ キーの数が暗号化されるブロック数より多い場合、Bootgen は余分なキーを無視します (読み込みません)。

• 複数のキー/IV ペアを指定する場合は、no. of blocks + 1 ペアを指定する必要があります。○ 余ったキー/IV ペアは、セキュアヘッダーの暗号化に使用されます。○ Key0 と IV0 以外のキーと IV のペアは、1 つの BIF で指定されるどの aes キーファイルでも繰り返さないようにしてください。

グレー/難読化キーユーザーキーは、ファミリキーで暗号化されており、デバイスの金属層に埋め込まれています。このファミリキーは、Zynq® UltraScale+™ MPSoC のすべてのデバイスで同じであり、結果、難読化キーとして使用されます。難読化キーは、認証されたブートヘッダーまたは eFUSE のいずれかに配置できます。image:{ [keysrc_encryption] efuse_gry_key [bh_key_iv] bhiv.txt [ bootloader, destination_cpu = a53-0, encryption = aes, aeskeyfile = aes_p1.nky ] fsbl.elf [ destination_cpu = r5-0, encryption = aes, aeskeyfile = aes_p2.nky ] hello.elf}

Bootgen は、イメージの作成中に次を実行します。1. ブートヘッダーの BH IV フィールドに bhiv.txt の IV を配置します。2. ブートヘッダーのセキュアヘッダー IV フィールドに aes.nky の IV 0 を配置します。3. aes.nky の Key0 および IV0 を使用して、パーティションを暗号化します。グレー/ファミリキーを使用する別の例は、第 7 章: ユースケースおよび例を参照してください。





この機能の詳細は、『Zynq UltraScale+ デバイステクニカルリファレンスマニュアル』 (UG1085: 英語版、日本語版)を参照してください。

キーの生成Bootgen には、AES-GCM キーを生成する機能があります。Bootgen は、NIST が認定する Counter Mode KDF を使用し、CMAC を疑似ランダム関数として使用します。ユーザーがキーローリングのためにシードから複数のキーを派生させる場合、Bootgen はシードを入力として受け取ります。シードが指定されている場合、これを使用してキーが生成されます。シードが指定されていない場合、Key0 に基づいてキーが生成されます。空のキーファイルが指定されている場合、Bootgen は時間ベースのランダム化 (KDF ではない) でシードを生成します。これは KDF がほかのキー/IV ペアを生成するための入力となります。注記:

• 1 つの暗号化ファイルが指定され、ほかの暗号化ファイルが生成される場合、Bootgen は最初のパーティションの暗号化ファイルにある Key0/IV0 ペアと同じものを生成されたキーに使用できます。

• 最初のパーティションに暗号化ファイルが生成され、それ以降のパーティションには Key0/IV0 を含むほかの暗号化ファイルが指定されると、Bootgen は終了し、誤った Key0/IV0 ペアが使用されたというエラーを返します。

キーの生成キーファイルのサンプルを次に示します。

図 11: キーファイルの例

難読化キーの生成Bootgen は、ファミリキーと、ユーザー提供の IV を用いてレッドキーを暗号化することで難読化キーを生成できます。ファミリキーは、ザイリンクスセキュリティグループが提供します。詳細は、familykey を参照してください。難読化キーを生成するために、Bootgen は BIF ファイルから次の入力を取得します。obf_key:{ [aeskeyfile] aes.nky [familykey] familyKey.cfg [bh_key_iv] bhiv.txt}

難読化キーを生成する構文は、次のとおりです。bootgen -arch zynqmp -image all.bif -generate_keys obfuscatedkey







ブラックキー/PUF キーブラックキーのストレージソリューションは、PUF から生成された暗号強度の高い KEK (key encryption key) を使用し、ユーザーキーを暗号化します。生成されたブラックキーは、eFUSE に格納するか、認証されたブートヘッダーの一部として格納できます。image:{ [puf_file] pufdata.txt [bh_key_iv] black_iv.txt [bh_keyfile] black_key.txt [fsbl_config] puf4kmode, shutter=0x0100005E, pufhd_bh [keysrc_encryption] bh_blk_key [ bootloader, destination_cpu = a53-0, encryption = aes, aeskeyfile = aes_p1.nky ] fsbl.elf [ destination_cpu = r5-0, encryption = aes, aeskeyfile = aes_p2.nky ] hello.elf}

ブラックキーを使用するその他の例は、第 7 章: ユースケースおよび例を参照してください。

複数の暗号化キーファイル以前のバージョンの Bootgen では、1 つの暗号化キーで複数のパーティションを暗号化してブートイメージを作成できました。この場合、各パーティションで同じキーが繰り返し使用されます。これはセキュリティの脆弱性の要因となるため、推奨されていません。各キーの使用は、フローで一度だけとする必要があります。Bootgen は、パーティションごとに個別の暗号化キーをサポートしています。キーファイルが複数ある場合、各暗号化キーファイルで同じ Key0 (デバイスキー)、IV0、および操作キーが使用されるようにしてください。各暗号化キーファイルでブートイメージが異なると、Bootgen でブートイメージを作成できません。ユーザーが複数の暗号化キーファイル (イメージ内の各パーティションに 1 つずつ) を指定する必要があります。パーティションは、各パーティションに指定されたキーを使用して暗号化されます。注記: ロード可能なセクションが複数あるために複数のパーティションが作成されている場合、同じディレクトリにあるファイル名に .1、.2、.n などが付いたキーファイルを指定することにより、各パーティションに固有のキーファイルを指定できます。次に、暗号化キーファイルの例の抜粋を示します。all:{ [keysrc_encryption] bbram_red_key // FSBL (Partition-0) [ bootloader, destination_cpu = a53-0, encryption = aes, aeskeyfile = key_p0.nky





]fsbla53.elf // application (Partition-1) [ destination_cpu = a53-0, encryption = aes, aeskeyfile = key_p1.nky ]hello.elf }

• fsbla53.elf パーティションは、key_p0.nky ファイルのキーを使用して暗号化されます。• hello.elf にロード可能なセクションが 3 つあるため 3 つのパーティションが存在するとした場合、

hello.elf.0 パーティションは test2.nky ファイルのキーを使用して暗号化されます。• その後 hello.elf.1 パーティションが test2.1.nky のキーを使用して暗号化されます。• hello.elf.2 パーティションは test2.2.nky からキーを使用して暗号化されます。

Versal デバイスのパーティションの暗号化Versal™ デバイスは、256 ビットキーをサポートする AES-GCM コアを使用します。セキュアイメージを作成する際、オプションでブートイメージ内の各パーティションを暗号化できます。暗号化には、キーソースおよび aes キーファイルがあらかじめ必要です。注記: Versal ACAP で暗号化をイネーブルにする場合、AES キーファイルと各パーティションのキーソースを指定する必要があります。使用されるキーソースに基づいて、それぞれ指定された aes キーファイルで同じキー 0 を使用する必要があります (逆もまた同様です)。キー管理優れたキー管理の方法の 1 つは、秘密キーの使用を最小限に抑えることです。これには、ブートイメージ内の異なるパーティション間で異なるキー/IV を使用します。このため、BBRAM または eFUSE のいずれかに格納された AES キーは 384 ビットのみで使用され、サイドチャネル攻撃にさらされる可能性が大幅に制限されます。all: { image { {type=bootloader, encryption=aes, keysrc=bbram_red_key, aeskeyfile=plm.nky, dpacm_enable, file=plm.elf} {type=pmcdata, load=0xf2000000, aeskeyfile = pmc_data.nky, file=pmc_data.cdo} {core=psm, file=psm.elf} {type=cdo, encryption=aes, keysrc=bbram_red_key, aeskeyfile=ps_data.nky, file=ps_data.cdo} {type=cdo, file=subsystem.cdo} {core=a72-0, exception_level = el-3, file=a72-app.elf} }}

キーの差し替えAES-GCM は、暗号化されたイメージ全体をより小規模な AES 暗号化ブロック/モジュール単位で表すキー差し替え機能もサポートしています。各モジュールは独自のキーを使用して暗号化されます。最初のキーはデバイスのキーソースで格納され、後続の各モジュールのキーは直前のモジュール内で暗号化 (ラップ) されます。Bootgen を使用すると、キーローリングを含むブートイメージを生成できます。BIF の属性 (blocks) を使用して、暗号化用に複数の小さなブロックを作成するためのパターンを指定します。





注記: Versal ACAP の場合、デフォルトのキーローリングは 32 KB のデータで実行されます。属性 blocks で選択したキーローリングが各 32 KB に適用されます。これは、使用するハッシュスキームに合わせるためです。DPA キーローリング対策をイネーブルにすると、ブート時間に影響します。ブート時間の見積もりは、ブート時間見積もりスプレッドシートを参照してください。all:{ id_code = 0x04ca8093 extended_id_code = 0x01 id = 0x2

metaheader { encryption = aes, keysrc = bbram_red_key, aeskeyfile = efuse_red_metaheader_key.nky, dpacm_enable }

image { name = pmc_subsys, id = 0x1c000001 partition { id = 0x01, type = bootloader, encryption = aes, keysrc = bbram_red_key, aeskeyfile = bbram_red_key.nky, dpacm_enable, blocks = 4096(2);1024;2048(2);4096(*), file = executable.elf } partition { id = 0x09, type = pmcdata, load = 0xf2000000, aeskeyfile = pmcdata.nky, file = topology_xcvc1902.v1.cdo, file = pmc_data.cdo } }

image { name = lpd, id = 0x4210002 partition { id = 0x0C, type = cdo, encryption = aes, keysrc = bbram_red_key, aeskeyfile = key1.nky, dpacm_enable, blocks = 8192(20);4096(*), file = lpd_data.cdo } partition { id = 0x0B, core = psm, encryption = aes, keysrc = bbram_red_key, aeskeyfile = key2.nky, dpacm_enable, blocks = 4096(2);1024;2048(2);4096(*), file = psm_fw.elf





} }

image { name = fpd, id = 0x420c003 partition { id = 0x08, type = cdo, encryption = aes, keysrc = bbram_red_key, aeskeyfile = key5.nky, dpacm_enable, blocks = 8192(20);4096(*), file = fpd_data.cdo } }}

注記:• キーファイル内のキーの数は、暗号化されるブロックの数と常に一致する必要があります。• キーの数が暗号化されるブロック数より少ない場合、Bootgen はエラーを返します。• キーの数が暗号化されるブロック数より多い場合、Bootgen は余分なキーを無視します。

キーの生成Bootgen は AES-GCM キーを生成できます。Bootgen は、NIST が認定する Counter Mode KDF を使用し、CMAC を疑似ランダム関数として使用します。ユーザーがキーローリングのためにシードから複数のキーを派生させる場合、Bootgen はシードを入力として受け取ります。シードが指定されている場合、これを使用してキーが生成されます。シードが指定されていない場合、Key0 に基づいてキーが生成されます。空のキーファイルが指定されている場合、Bootgen は時間ベースのランダム化 (KDF ではない) でシードを生成します。これは KDF がほかのキー/IV ペアを生成するための入力となります。次の条件が適用されます。• 1 つの暗号化ファイルが指定され、ほかの暗号化ファイルが生成される場合、Bootgen は最初のパーティションの暗号化ファイルにある Key0/IV0 ペアと同じものを生成されたキーに使用できます。

• 最初のパーティションに暗号化ファイルが生成され、それ以降のパーティションには Key0/IV0 を含むほかの暗号化ファイルが指定されると、Bootgen は終了し、誤った Key0/IV0 ペアが使用されたというエラーを返します。

• キーファイルが指定されず、暗号化が 1 つのパーティションにない場合、Bootgen はデフォルトでそのパーティション名の付いた aes キーファイルを生成します。これによりパーティションごとに別の aeskeyfile が使用されるようになります。

• ファイル名に ".1", ".2"...".n" を付けたキーファイルを該当パーティションのキーファイルの同じディレクトリに読み込んだり生成することで、ロード可能なセクションが複数あるために作成された各パーティションに対して一意のキーファイルを使用できます。

ブラックキー/PUF キーブラックキーのストレージソリューションは、PUF から生成された暗号強度の高い KEK (key encryption key) を使用し、ユーザーキーを暗号化します。生成されたブラックキーは、eFUSE に格納するか、認証されたブートヘッダーの一部として格納できます。例:

test:{ bh_kek_iv = black_iv.txt bh_keyfile = black_key.txt puf_file = pufdata.txt





boot_config {puf4kmode} image { {type=bootloader, encryption = aes, keysrc=bh_blk_key, pufhd_bh, aeskeyfile = red_grey.nky, file=plm.elf} {type=pmcdata,load=0xf2000000, aeskeyfile = pmcdata.nky, file=pmc_data.cdo} {core=psm, file=psm.elf} {type=cdo, file=ps_data.cdo} {type=cdo, file=subsystem.cdo} {core=a72-0, exception_level = el-3, file=hello_world.elf} }}

メタヘッダーの暗号化Versal ACAP の場合、暗号化が metaheader 属性の下で指定されると、Bootgen がメタヘッダーを暗号化します。使用する aeskeyfile は、[metaheader] の下のパラメーターを使用して bif で指定できます。次は、その使用例です。metaheader{ encryption = aes, keysrc = bbram_red_key, aeskeyfile = headerkey.nky,}

次の条件が適用されます。• 特定の aeskeyfile がメタヘッダーに指定されていない場合、Bootgen は meta_header.nky というファイルを生成して、暗号化中に使用します。

• ブートローダーが bif に含まれる場合は、ブートローダーを暗号化してメタヘッダーを暗号化する必要があります。パーシャル PDI の場合、メタヘッダーの暗号化はオプションです。

認証の使用AES 暗号化は対称キーを用いた自己認証アルゴリズムで、暗号化と復号化に同じキーを使用します。したがって、このキーは非公開キーとして保護する必要があり、キーを格納するための領域が内部に必要になります。RSA (RivestShamir Adleman) による認証手段もあります。RSA は非対称アルゴリズムで、署名に使用するキーと検証に使用するキーが異なります。認証には一対のキーが必要です。• 署名には、秘密キーを使用します。• 検証には、公開キーを使用します。この公開キーは保護の必要がないため、セキュアな格納領域は不要です。この認証方式と暗号化を組み合わせることにより、真正性と機密性の両方を確保できます。RSA は、暗号化されているパーティションと暗号化されていないパーティションのいずれにも使用可能です。RSA のメリットは、公開キーを使用することだけではなく、復号化する前に認証を実行できることが挙げられます。RSA 公開キーのハッシュ値は eFUSE に格納する必要があります。ザイリンクス SoC デバイスでは、パーティションデータは AES 復号化エンジンに送信される前に認証されます。この方法では、パーティションデータの真正性を確認してから復号化を実行することになるため、復号化エンジンへの攻撃を防ぐことができます。





ザイリンクス SoC では、公開キーと秘密キーの 2 つのペアが使用されます (プライマリおよびセカンダリ)。プライマリ公開/秘密キーは、セカンダリ公開/秘密キーペアを認証します。セカンダリキーは、パーティションを署名/検証します。キーを示す頭文字の最初のアルファベットは、プライマリの場合 P、セカンダリの場合 S となります。キーを示す頭文字の 2 番目のアルファベットは、公開の場合 P、秘密の場合 S となります。キーの種類は次の 4 つです。• PPK = プライマリ公開キー• PSK = プライマリ秘密キー• SPK = セカンダリ公開キー• SSK = セカンダリ秘密キーBootgen は、次の 2 つの方法で認証証明を作成できます。• PSK と SSK を供給します。これらの 2 つの入力を使用し、SPK 署名がオンザフライで計算されます。• PPK、SSK、および SPK 署名を入力として供給します。この方法は、PSK がわからない場合に使用されます。プライマリキーはハッシュ化されて eFUSE 内に格納されます。このハッシュ値は、FSBL によってブートイメージに格納されたプライマリキーのハッシュ値と比較されます。このハッシュは、Vitis に付属するスタンドアロンドライバーを使用して PS の eFUSE メモリに書き込むことができます。BIF ファイルの例を次に示します。image:{ [pskfile]primarykey.pem [sskfile]secondarykey.pem [bootloader,authentication=rsa] fsbl.elf [authentication=rsa]uboot.elf}

デバイス固有の認証の詳細は、次の資料を参照してください。• Zynq-7000 SoC デバイスの認証証明• Zynq UltraScale+ MPSoC デバイスの認証証明• Versal ACAP 認証証明

署名次の図に、パーティションの RSA 署名プロセスを示します。セキュアな施設から Bootgen により秘密キーを使用してパーティションに署名します。署名プロセスの手順は、次のとおりです。1. PPK および SPK を認証証明 (AC) に格納します。2. PSK を使用して SPK に署名し、SPK 署名を取得します。これは、AC の一部としても格納されます。3. SSK を使用してパーティションに署名し、パーティション署名を取得し、AC に格納します。4. デバイスによって認証が選択されている各パーティションの先頭または末尾に AC を追加します。5. PPK をハッシュ化し、eFUSE 内に格納します。





図 12: パーティションの RSA 署名プロセス

Hash

eFUSE

Hash + RSA

Hash + RSA

Prim

ary

Keys PPK

PSK

Seco

ndar

y Ke

ys SPK

SSK

Partition

Authentication Header

PPK

SPK

SPKSignature

PartitionSignature

PartitionAuthentication

Certificate

Partition

AuthenticationCertificate

Partition Headers

Boot Header

Secret Key

Secret Key

X21278-080618

次の表に、認証のオプションを示します。表 34: 認証キーに対してサポートされているファイルフォーマット

キー名前説明サポートされているファイルフォーマットPPK プライマリ公開キーパーティションを認証するために使用するキーです。

パーティションの認証時に必ず指定する必要があります。

*.txt*.pem*.pub*.pk1

PSK プライマリ秘密キーパーティションを認証するために使用するキーです。パーティションの認証時に必ず指定する必要があります。

*.txt*.pem*.pk1

SPK セカンダリ公開キーこのキーを指定した場合、パーティションの認証に使用されます。 *.txt*.pem*.pub*.pk1





表 34: 認証キーに対してサポートされているファイルフォーマット (続き)

キー名前説明サポートされているファイルフォーマットSSK セカンダリ秘密キーこのキーを指定した場合、パーティションの認証に使用されます。 *.txt

*.pem*.pk1

検証デバイス内では、公開キーを使用して、bootROM が FSBL を検証し、FSBL または U-Boot のいずれかが続くパーティションを検証します。1. PPK の検証: この手順では、プライマリキーの認証が確立されます。プライマリキーは、セカンダリキーの認証に使用します。a. ブートイメージの AC から PPK が読み出されます。b. PPK ハッシュ値を生成します。c. ハッシュ化された PPK と、eFUSE から取得された PPK ハッシュ値を比較します。d. 同じ場合はプライマリキーが信頼されます。そうでない場合はセキュアブートエラーとなります。

2. セカンダリキーの検証 - この手順では、セカンダリキーの認証が確立されます。セカンダリキーはパーティションの認証に使用します。a. ブートイメージの AC から SPK が読み出されます。b. SPK ハッシュ値を生成します。c. PPK を使用して AC に格納されている SPK 署名を検証し、SPK ハッシュ値を取得します。d. ステップ (b) およびステップ (c) からのハッシュ値を比較します。e. 同じ場合はセカンダリキーが信頼されます。そうでない場合はセキュアブートエラーとなります。

3. パーティションの検証: この手順では、ブートされているパーティションの信頼性を確立します。a. ブートイメージからパーティションが読み出されます。b. パーティションのハッシュ値を生成します。c. SPK を使用して AC に格納されているパーティション署名を検証し、パーティションハッシュ値を取得しま

す。d. ステップ (b) およびステップ (c) からのハッシュ値を比較します。e. 同じ場合はパーティションが信頼されます。そうでない場合はセキュアブートエラーとなります。





図 13: 検証のフロー図

Hash

eFUSE

Hash + RSA

Hash + RSA

Prim

ary

Keys PPK

PSK

Seco

ndar

y Ke

ys SPK

SSK

Partition

Authentication Header

PPK

SPK

SPKSignature

PartitionSignature

PartitionAuthentication

Certificate

Partition

AuthenticationCertificate

Partition Headers

Boot Header

Secret Key

Secret Key

X21278-080618

Bootgen は、次の 2 つの方法で認証証明を作成できます。• PSK と SSK を供給します。これらの 2 つの入力を使用し、SPK 署名がオンザフライで計算されます。• PPK、SSK、および SPK 署名を入力として供給します。この方法は、PSK がわからない場合に使用されます。

Zynq UltraScale+ MPSoC の認証サポートZynq® UltraScale+™ MPSoC デバイスは RSA-4096 認証を使用するため、プライマリキーおよびセカンダリキーのサイズは 4096 ビットとなります。

NIST SHA-3 のサポート注記: SHA-3 認証では、ブートヘッダー、PPK、およびブートイメージのハッシュ値の計算に Keccak SHA-3 が常に使用されます。ROM によってロードされないその他すべてのパーティションには、NIST-SHA3 が使用されます。生成された署名は、次の表に基づいて Keccak-SHA3 または NIST-SHA3 を使用します。





表 35: 認証署名

認証証明 (AC) の種類署名 SHA アルゴリズムおよび SPKeFUSE 署名の生成に使用される秘密キー

パーティションヘッダー AC(FSBL/FW によってロードされる)

SPK 署名 SPKID eFUSE の場合 Keccak、ユーザー eFUSE の場合はNIST

PSK

BH 署名常に Keccak SSKheader

ヘッダー署名常に NIST SSKheader

ブートローダー (FSBL) AC(ROM によってロードされる)

SPK 署名常に Keccak、常に SPK 用のSPKID eFUSE

PSK

BH 署名常に Keccak SSKBootloader

FSBL 署名常に Keccak SSKBootloader

その他のパーティション AC(FSBL FW によってロードされる)

SPK 署名 SPKID eFUSE の場合 Keccak、ユーザー eFUSE の場合はNIST

PSK

BH 署名常に Keccak パディング SSKPartition

パーティション署名常に NIST パディング SSKPartition

例例 1: 1 つのキーファイルセットでパーティションを認証するための BIF ファイルimage:{ [fsbl_config] bh_auth_enable [auth_params] ppk_select=0; spk_id=0x00000000 [pskfile] primary_4096.pem [sskfile] secondary_4096.pem [pmufw_image] pmufw.elf [bootloader, authentication=rsa, destination_cpu=a53-0] fsbl.elf [authenication=rsa, destination_cpu=r5-0] hello.elf}





例 2: パーティションごとに個別のセカンダリキーを使用してパーティションを認証するための BIF ファイルimage:{ [auth_params] ppk_select=1 [pskfile] primary_4096.pem [sskfile] secondary_4096.pem // FSBL (Partition-0) [ bootloader, destination_cpu = a53-0, authentication = rsa, spk_id = 0x01, sskfile = secondary_p1.pem ] fsbla53.elf

// ATF (Partition-1) [ destination_cpu = a53-0, authentication = rsa, exception_level = el-3, trustzone = secure, spk_id = 0x01, sskfile = secondary_p2.pem ] bl31.elf // UBOOT (Partition-2) [ destination_cpu = a53-0, authentication = rsa, exception_level = el-2, spk_id = 0x01, sskfile = secondary_p3.pem ] u-boot.elf}

外部メモリを使用したビットストリーム認証ビットストリームの認証は、その他のパーティションとは異なります。FSBL は、OCM 内にすべて含めることが可能であるため、デバイス内部で認証して復号化できます。ビットストリームの場合は、ファイルサイズが非常に大きいためデバイス内にすべてを含めることができず、外部メモリを使用する必要があります。外部メモリを使用すると、攻撃者がこの外部メモリに侵入する可能性があるため、セキュリティ管理という課題が生じます。ビットストリームの認証が要求されると、Bootgen はビットストリーム全体を 8MB ブロックに分割し、各ブロックに認証証明が与えられます。ビットストリームが 8MB の倍数でない場合は、最後のブロックに残りのビットストリームデータが含まれます。認証と暗号化の両方が有効の場合は、最初にビットストリームの暗号化が実行されます。その後、Bootgenは暗号化されたデータをブロックに分割して、各ブロックに認証証明を提供します。





図 14: 外部メモリを使用したビットストリーム認証

ユーザー eFUSE サポートおよび RSA キー取り消しの改善RSA キー取り消しサポートの改善RSA キーは、すべてのパーティションのセカンダリキーを取り消すことなく、1 つのパーティションのセカンダリキーを取り消すことができます。注記: プライマリキーは、すべてのパーティションで同じものである必要があります。これには、USER_FUSE0 〜 USER_FUSE7 の eFUSE と、BIF パラメーターの spk_select を使用します。注記: すべてのキーを使用する必要がない場合は、最大で 256 個のキーを取り消すことができます。次の BIF ファイルの例は、改善されたユーザー eFUSE 取り消しを示しています。イメージヘッダーおよび FSBL は、下記の例を BIF へ追加することで、認証に異なる SSK を使用します (それぞれ ssk1.pem および ssk2.pem)。the_ROM_image:{ [auth_params]ppk_select = 0 [pskfile]psk.pem [sskfile]ssk1.pem [ bootloader, authentication = rsa, spk_select = spk-efuse, spk_id = 0x8, sskfile = ssk2.pem ] zynqmp_fsbl.elf [ destination_cpu = a53-0, authentication = rsa, spk_select = user-efuse, spk_id = 0x100, sskfile = ssk3.pem ] application.elf [ destination_cpu = a53-0, authentication = rsa,





spk_select = spk-efuse, spk_id = 0x8, sskfile = ssk4.pem ] application2.elf}

• spk_select = spk-efuse の場合、そのパーティションに spk_id eFUSE が使用されることを意味します。• spk_select = user-efuse の場合、そのパーティションにユーザー eFUSE が使用されることを意味します。CSU ROM によってロードされるパーティションは、常に spk_efuse を使用します。注記: spk_id eFUSE は、どのキーが有効であるかを指定します。したがって、ROM は spk_id eFUSE のフィールド全体を SPK ID と照合してビットが一致することを確認します。ユーザー eFUSE は、どのキー ID が有効でない (取り消された) かを指定します。したがって、ファームウェア (ROM以外) は、SPK ID を表すそのユーザー eFUSE がプログラムされているかどうかをチェックします。

キーの生成Bootgen には RSA キーを生成する機能があります。または、OpenSSL などの外部ツールを使用してキーを作成することもできます。Bootgen は BIF ファイルで指定したパスにキーを作成します。次の図は、RSA 秘密キーファイルの例です。





図 15: RSA 秘密キーファイルの例

注記: 公開コンポーネントには、通常拡張子 .pub が使用されます。これは、公開コンポーネントおよび秘密コンポーネント両方を含む秘密キーから抽出できます。秘密キーには、通常拡張子 .pem が使用されます。公開キーコンポーネントを生成するには、上記の例の pskfile/sskfile の代わりに ppkfile/spkfile を使用します。





BIF の例BIF ファイルの例 generate_pem.bif を次に示します。generate_pem:{ [pskfile] psk0.pem [sskfile] ssk0.pem}

コマンドキーを生成する構文は、次のとおりです。bootgen -generate_keys pem -arch zynqmp -image generate_pem.bif

eFUSE 用の PPK ハッシュBootgen は、PPK が信頼されることを確実にすることを目的とした、eFUSE に格納するための PPK ハッシュを生成します。次に示す手順は、eFUSE モードの RSA 認証でのみ実行する必要があり、Zynq® UltraScale+™ MPSoC デバイスの RSA ブートヘッダー認証ではスキップできます。efuseppksha.txt からの値は、eFUSE にプログラムして、eFUSE モードの RSA 認証に使用できます。BBRAM および eFUSE プログラミングの詳細は、『BBRAM および eFUSE のプログラミング』 (XAPP1319: 英語版、日本語版) を参照してください。

BIF ファイルの例BIF ファイルの例 (generate_hash_ppk.bif) を次に示します。generate_hash_ppk:{ [pskfile] psk0.pem [sskfile] ssk0.pem [bootloader, destination_cpu=a53-0, authentication=rsa] fsbl_a53.elf}

コマンドeFUSE プログラミング用の PPK ハッシュを生成するコマンドは次のとおりです。bootgen –image generate_hash_ppk.bif –arch zynqmp –w –o /test.bin –efuseppkbits efuseppksha.txt

Versal 認証サポートBootgen では、Versal ACAP の認証に RSA-4096 および ECDSA P384 と P521 がサポートされます。すべてのパーティション/ヘッダーのハッシュを計算するには、NIST SHA-3 が使用されます。ハッシュで計算される署名は、PDI に含まれます。注記: Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合と異なり、Versal ACAP では認証証明がパーティションよりも前に含まれます。ECDSA P521 曲線は、ブートローダーパーティション (PLM) ではサポートされていません。bootROM では、RSA-4096 または ECDSA-P384 認証のみがサポートされます。その他のパーティションの認証には、P521 を使用できます。



https://japan.xilinx.com/cgi-bin/docs/ndoc?t=application_notes;d=xapp1319-zynq-usp-prog-nvm.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=application_notes;d=j_xapp1319-zynq-usp-prog-nvm.pdf



メタヘッダー認証Versal ACAP では、BIF 属性 metaheader のパラメーターに基づいて、Bootgen でメタヘッダーが認証されます。次は、その使用例です。metaheader{ authentication = rsa, pskfile = psk.pem, sskfile = ssk.pem}

eFUSE 用の PPK ハッシュBootgen は、PPK が信頼されることを確実にすることを目的とした、eFUSE に格納するための PPK ハッシュを生成します。次に示す手順は、eFUSE モードの認証でのみ実行する必要があり、ブートヘッダー認証ではスキップできます。efuseppksha.txt からの値は、eFUSE にプログラムして eFUSE モードの認証に使用できます。

BIF ファイルの例BIF ファイルの例 (generate_hash_ppk.bif) を次に示します。generate_hash_ppk:{ pskfile = primary0.pem sskfile = secondary0.pem image { name = pmc_ss, id = 0x1c000001 { type=bootloader, authentication=rsa, file=plm.elf} { type=pmcdata, load=0xf2000000, file=pmc_cdo.bin} }}

コマンドeFUSE プログラミング用の PPK ハッシュを生成するコマンドは次のとおりです。bootgen –image generate_hash_ppk.bif –arch versal –w –o test.bin –efuseppkbits efuseppksha.txt

Versal ACAP の累積セキュアブート表 36: 累加的なセキュアブート動作

ブートタイプ動作ハードウェア暗号化エンジン認証復号化完全性 (チェックサム検証)

非セキュアブートなしなしなしなし非対称のハードウェアによる信頼のルート (A-HWRoT)

はい (必須) なしなし RSA/ECDSA と SHA3





表 36: 累加的なセキュアブート動作 (続き)

ブートタイプ動作ハードウェア暗号化エンジン認証復号化完全性 (チェックサム検証)

対称のハードウェアによる信頼のルート (S-HWRoT) (PDI の復号化には強制的に eFUSE ブラックキーを使用)

なしあり (PLM とメタヘッダーは eFUSE KEK で暗号化する必要あり)

なし AES-GCM

A-HWRoT + S-HWRoT はい (必須) はい (必須) なし RSA/ECDSA と SHA3 および AES-GCM

PDI の認証と復号化あり Yes (キーソースはBBRAM または eFUSE)

なし RSA/ECDSA と SHA3 および AES-GCM

復号化 (ユーザーが選択したキーを使用。キーソースは、BBRAM/BHDR または eFUSE など任意のものを使用可能)

なしありなし AES-GCM

チェックサム検査なしなし Yes SHA3

HSM モードの使用現在の暗号技術では、すべてのアルゴリズムが公開されているため、秘密キーの保護が重要です。ハードウェアセキュリティモジュール (HSM) は、暗号化キーのライフサイクルを保護するために特別に設計された専用の暗号処理デバイスであり、Bootgen に公開キーのみを渡して秘密キーを渡さないようにすることでキー処理のセキュリティを向上します。標準モードも使用可能です。このモードでは、キーを渡す必要はありません。組織によっては、情報セキュリティ担当者がセキュアエンベデッド製品のプロダクションリリースを担当します。情報セキュリティ担当者が、デジタル署名に HSM を使用し、暗号化には別のセキュアサーバーを使用することがあります。HSM とセキュアサーバーは、通常はセキュアエリア内に配置されます。HSM はセキュアキー/署名生成デバイスであり、秘密キーを生成し、秘密キーを使用してパーティションに署名し、RSA キーの公開部分を Bootgen に供給します。秘密キーは、HSM にのみ配置されます。HSM モードの Bootgen は、RSA 公開キーと、ブートイメージを生成するために HSM によって作成された署名のみを使用します。HSM は、Bootgen によって生成されたパーティションのハッシュ値を受信し、ハッシュ値と RSA 秘密キーに基づいて署名ブロックを返します。HSM モードとは異なり、標準モードの Bootgen では、イメージ内のパーティションの暗号化および認証に、BIF ファイルで提供される AES 暗号化キーと RSA 秘密キーがそれぞれ使用されます。出力は 1 つのブートイメージであり、暗号化および認証されています。ユーザーは、認証用に公開キーと秘密キーの両方を提供する必要があります。Bootgen は秘密キーを使用してパーティションに署名し、署名を作成します。これらの署名は公開キーと共に最終的なブートイメージに埋め込まれます。FPGA の HSM モードの詳細は、FPGA の HSM モードを参照してください。

高度なキー管理オプションの使用秘密キーに関連付けられている公開キーは、ppk.pub および spk.pub です。HSM は、Bootgen によって生成されたパーティションのハッシュ値を受信し、ハッシュ値と秘密キーに基づいて署名ブロックを返します。





HSM モードを使用したブートイメージの作成: PSK の共有なし次の図に、HSM モードを使用するステージ 0 〜ステージ 2 のブートスタックを示します。SSK を配布することでステップ数が削減されています。この図では、Zynq® UltraScale+™ MPSoC デバイスを使用して各ステージを説明しています。

図 16: 一般的な 3 ステージブートイメージ

HSM Mode

Stag

e-1 PSK hash

Generate SPKsignature

SPK hashSPK signature

BOOTGEN

Stag

e-0 SPK ID

Generate SPKHash

SPK hash

BOOTGEN

Stag

e-2

Generate Boot Image

PPK and SSKFinal Boot

ImageFSBLpartitions

NKY Key

SPK signature

SPK

AC header

PSK

SPK ID

X21359-052120

ブートプロセスHSM モードを使用したブートイメージの作成は、次の BIF ファイルを使用して標準フローでブートイメージを作成するのと似ています。all:{ [auth_params] ppk_select=1;spk_id=0x8 [keysrc_encryption]bbram_red_key [pskfile]primary.pem [sskfile]secondary.pem [ bootloader, encryption=aes, aeskeyfile=aes.nky, authentication=rsa ]fsbl.elf [destination_cpu=a53-0,authentication=rsa]hello_a53_0_64.elf}





ステージ 0: HSM モードを使用してブートイメージを作成信頼されている個人が、プライマリ秘密キーを使用して SPK 署名を作成します。SPK 署名は、認証証明ヘッダー、SPK、および SPK にあります。上記のためのハッシュを生成するには、次の BIF ファイルの抜粋を使用します。stage 0:{ [auth_params] ppk_select=1;spk_id=0x3 [spkfile]keys/secondary.pub}

Bootgen コマンドは次のとおりです。bootgen -arch zynqmp -image stage0.bif -generate_hashes

このコマンドの出力は secondary.pub.sha384 です。

ステージ 1: SPK 署名を配布信頼されている個人が SPK 署名を開発チームに配布します。openssl rsautl -raw -sign -inkey keys/primary0.pem -in secondary.pub.sha384 > secondary.pub.sha384.sig

このコマンドの出力は secondary.pub.sha384.sig です。

ステージ 2: FSBL で AES を使用して暗号化開発チームが Bootgen を使用して必要な数のブートイメージを作成します。開発チームは次を使用します。• 信頼されている個人からの SPK 署名。• セカンダリ秘密キー (SSK)、SPK、および SPKID

Stage2:{ [keysrc_encryption]bbram_red_key [auth_params] ppk_select=1;spk_id=0x3 [ppkfile]keys/primary.pub [sskfile]keys/secondary0.pem [spksignature]secondary.pub.sha384.sig [bootloader,destination_cpu=a53-0, encryption=aes, aeskeyfile=aes0.nky, authentication=rsa] fsbl.elf [destination_cpu=a53-0, authentication=rsa] hello_a53_0_64.elf }

Bootgen コマンドは次のとおりです。bootgen -arch zynqmp -image stage2.bif -o final.bin

HSM モードを使用した Zynq-7000 SoC デバイスブートイメージの作成次の図に、Zynq®-7000 SoC デバイスの HSM モードのブートイメージを示します。この図の後にブートイメージを作成する手順を示します。





図 17: ステージ 0 〜 8 のブートプロセス

Stage-2b

BOOTGEN

Stag

e-7a

PPK & SPKFSBL with auth certificateencrypted

FSBL

SPK sign

BOOTGEN

Stag

e-7a

PPK & SPKFSBL with auth certificateencrypted

FSBL

SPK sign

HSM

Stag

e-1 PSK hash

Generate SPKsignature

SPK hashSPK signature

nky key

HSM

Stag

e-4a

Generate FSBL Signature

FSBL hash FSBL Signature

BOOTGEN

Stag

e-5a

PPK & SPK

FSBL Signatureencrypted FSBL

SPK signature

BOOTGENSt

age-

0

Generate SPKHash

SPK

SPK hash

BOOTGEN

Stag

e-6

Generate header Table

hash

Header Table hash

HSM

Stag

e-7

Generate Header Table

signatureHeader

Table hash

Header Table Signature

Stag

e-8 Generate

bootmage

final bootimage


PSK

Generate FSBL hashe

PPK & SPKFSBL hashencrypted

FSBL

SPK signature

Stage-3b

Generate FSBLHash

Stage-4b

Stage-5b

Partions with Authenticated

Certificates

Stag

e-3a

BOOTGEN

Stag

e-2a

Encrypt FSBLFSBL

nky Key

encrypted FSBL

BOOTGEN

Stage- 3a

SSK

FSBL signature

InsertFSBL Signature

SSK

BOOTGEN

Stag

e-8 Generate Boot

ImageFinal Boot Image

Partions with Authenticated

Certificates


AC header

SPK ID

X21416-052120





HSM モードを使用して Zynq®-7000 SoC デバイスのブートイメージを作成するプロセスは、次の BIF ファイルを使用して標準フローでブートイメージを作成するのと似ています。これらの例は、必要に応じてハッシュファイルを生成するために OpenSSL プログラムを使用します。all:{ [aeskeyfile]my_efuse.nky [pskfile]primary.pem [sskfile]secondary.pem [bootloader,encryption=aes,authentication=rsa] zynq_fsbl_0.elf [authentication=rsa]system.bit}

ステージ 0: SPK のハッシュを生成このステージは、SPK キーのハッシュを生成します。stage0:{ [ppkfile] primary.pub [spkfile] secondary.pub}

Bootgen コマンドは次のとおりです。bootgen -image stage0.bif –w -generate_hashes

ステージ 1: SPK ハッシュに署名このステージは SPK ハッシュにサインして署名を作成します。xil_rsa_sign.exe -gensig -sk primary.pem -data secondary.pub.sha256 -out secondary.pub.sha256.sig

または、OpenSSL プログラムを使用して署名を作成します。#Swap the bytes in SPK hashobjcopy -I binary -O binary --reverse-bytes=256 secondary.pub.sha256

#Generate SPK signature using OpenSSLopenssl rsautl -raw -sign -inkey primary.pem -in secondary.pub.sha256 > secondary.pub.sha256.sig

#Swap the bytes in SPK signatureobjcopy -I binary -O binary --reverse-bytes=256 secondary.pub.sha256.sig

ステージ 2: AES を使用して暗号化このステージはパーティションを暗号化します。stage2.bif は次のとおりです。stage2:{ [aeskeyfile] my_efuse.nky [bootloader, encryption=aes] zynq_fsbl_0.elf}





Bootgen コマンドは次のとおりです。bootgen -image stage2.bif -w -o fsbl_e.bin -encrypt efuse

出力は、暗号化されたファイル (fsbl_e.bin) です。

ステージ 3: パーティションのハッシュを生成このステージは、さまざまなパーティションのハッシュを生成します。ステージ 3a: FSBL ハッシュを生成BIF ファイルは次のとおりです。stage3a:{ [ppkfile] primary.pub [spkfile] secondary.pub [spksignature] secondary.pub.sha256.sig [bootimage, authentication=rsa] fsbl_e.bin}

Bootgen コマンドは次のとおりです。bootgen -image stage3a.bif -w -generate_hashes

出力は、ハッシュファイル (zynq_fsbl_0.elf.0.sha256) です。ステージ 3b: ビットストリームハッシュを生成このステージの BIF ファイルは次のとおりです。stage3b:{ [ppkfile] primary.pub [spkfile] secondary.pub [spksignature] secondary.pub.sha256.sig [authentication=rsa] system.bit}

Bootgen コマンドは次のとおりです。bootgen -image stage3b.bif -w -generate_hashes

出力は、ハッシュファイル (system.bit.0.sha256) です。ステージ 4: ハッシュに署名このステージは作成したパーティションハッシュファイルから署名を作成します。ステージ 4a: FSBL パーティションハッシュに署名xil_rsa_sign.exe -gensig -sk secondary.pem -data zynq_fsbl_0.elf.0.sha256 -out zynq_fsbl_0.elf.0.sha256.sig





または、OpenSSL プログラムを使用して署名を作成します。#Swap the bytes in FSBL hashobjcopy -I binary -O binary --reverse-bytes=256 zynq_fsbl_0.elf.0.sha256

#Generate FSBL signature using OpenSSLopenssl rsautl -raw -sign -inkey secondary.pem -in zynq_fsbl_0.elf.0.sha256 > zynq_fsbl_0.elf.0.sha256.sig

#Swap the bytes in FSBL signatureobjcopy -I binary -O binary --reverse-bytes=256 zynq_fsbl_0.elf.0.sha256.sig

出力は、署名ファイル (zynq_fsbl_0.elf.0.sha256.sig) です。ステージ 4b: ビットストリームハッシュに署名xil_rsa_sign.exe -gensig -sk secondary.pem -data system.bit.0.sha256 -out system.bit.0.sha256.sig

または、OpenSSL プログラムを使用して署名を作成します。#Swap the bytes in bitstream hashobjcopy -I binary -O binary --reverse-bytes=256 system.bit.0.sha256

#Generate bitstream signature using OpenSSLopenssl rsautl -raw -sign -inkey secondary.pem -in system.bit.0.sha256 > system.bit.0.sha256.sig

#Swap the bytes in bitstream signatureobjcopy -I binary -O binary --reverse-bytes=256 system.bit.0.sha256.sig

出力は、署名ファイル (system.bit.0.sha256.sig) です。ステージ 5: パーティションの署名を挿入上記のステージで作成したパーティションの署名を挿入し、認証証明に変更します。ステージ 5a: FSBL 署名を挿入stage5a.bif は次のとおりです。stage5a:{ [ppkfile] primary.pub [spkfile] secondary.pub [spksignature] secondary.pub.sha256.sig [bootimage, authentication=rsa, presign=zynq_fsbl_0.elf.0.sha256.sig] fsbl_e.bin}

Bootgen コマンドは次のとおりです。bootgen -image stage5a.bif -w -o fsbl_e_ac.bin -efuseppkbits efuseppkbits.txt -nonbooting

認証された出力ファイルは、fsbl_e_ac.bin および efuseppkbits.txt です。ステージ 5b: ビットストリーム署名を挿入





stage5b.bif は次のとおりです。stage5b:{ [ppkfile] primary.pub [spkfile] secondary.pub [spksignature] secondary.pub.sha256.sig [authentication=rsa, presign=system.bit.0.sha256.sig] system.bit}

Bootgen コマンドは次のとおりです。bootgen -image stage5b.bif -o system_e_ac.bin –nonbooting

認証された出力ファイルは system_e_ac.bin です。ステージ 6: ヘッダーテーブルのハッシュを生成このステージは、ヘッダーテーブルのハッシュを生成します。stage6.bif は次のとおりです。stage6:{ [bootimage] fsbl_e_ac.bin [bootimage] system_e_ac.bin}

Bootgen コマンドは次のとおりです。bootgen -image stage6.bif -generate_hashes

出力ハッシュファイルは ImageHeaderTable.sha256 です。ステージ 7: ヘッダーテーブル署名を生成このステージは、ヘッダーテーブル署名を生成します。xil_rsa_sign.exe -gensig -sk secondary.pem -data ImageHeaderTable.sha256 -out ImageHeaderTable.sha256.sig

または、OpenSSL プログラムを使用して署名を作成します。#Swap the bytes in header table hashobjcopy -I binary -O binary --reverse-bytes=256 ImageHeaderTable.sha256

#Generate header table signature using OpenSSLopenssl rsautl -raw -sign -inkey secondary.pem -in ImageHeaderTable.sha256 > ImageHeaderTable.sha256.sig

#Swap the bytes in header table signatureobjcopy -I binary -O binary --reverse-bytes=256 ImageHeaderTable.sha256.sig

出力は、署名ファイル (ImageHeaderTable.sha256.sig) です。





ステージ 8: パーティションを結合し、ヘッダーテーブル署名を挿入するstage8.bif は次のとおりです。stage8:{ [headersignature] ImageHeaderTable.sha256.sig [bootimage] fsbl_e_ac.bin [bootimage] system_e_ac.bin}

Bootgen コマンドは次のとおりです。bootgen -image stage8.bif -w -o final.bin

出力は、ブートイメージファイル (final.bin) です。

HSM モードを使用した Zynq UltraScale+ MPSoC デバイスブートイメージの作成次の図に、HSM モードのブートイメージの図を示します。





図 18: 0 〜 10 ステージのブートプロセス

BH hash

BOOTGEN

Stag

e-7a

Encrypt FSBL

PPK & SPK FSBL with

auth certificate

encrypted FSBL

SPK signBOOTGEN

Stag

e-7a

Encrypt FSBL

PPK & SPK

encrypted FSBL

SPK sign

BOOTGEN

Generate SPKHash

FSBLnky key

BOOTGEN

Stage-2b

Generate SPKHash

FSBLnky key

HSM

Stag

e-1

Generate SPK

signatureSPK hash SPK

signature

BOOTGEN

Stag

e-2a

Encrypt FSBL

FSBLencrypted FSBLnky key

BOOTGEN

Stag

e-3 Generate

BHhash

PPK & SPK BH hash

Encrypted FSBL

HSM

Stag

e-4

Generate BH

signature

BH hashBH signature

BOOTGEN

Stag

e-5 Generate

partition hashes

PPK & SPKpartition hashesencrypted

partitions

SPK signature BH signature

HSM

Stag

e-6

Generate partition

signaturespartition hashes

partition signatures

BOOTGEN

Stag

e-7a

PPK & SPK

FSBL with authentication certificate

encrypted FSBL

SPK signature BH signature*BOOTGEN

Stag

e-0 SPK

Generate SPKHash

SPK

SPK hash

BOOTGEN

Stag

e-8

Generate Header

Table hash

Partitions with Authenticated

Certificate

Header Table hash

HSM

Stag

e-9

Generate headerTable

signature

Header Table hash

Header Table signature

BOOTGEN

Stag

e-10

Generate bootmage


Certificate

final bootimage

header Table signatureSPK Signature

Insert FSBLSignature

Stage-7bStage-7c

Stage-2c

SSK

SSK

SSK

AC header

SPK ID

X21547-052120

HSM モードを使用した Zynq® UltraScale+™ MPSoC デバイスのブートイメージの作成は、次の BIF ファイルを使用して標準フローでブートイメージを作成するのと似ています。これらの例は、必要に応じてハッシュファイルを生成するために OpenSSL プログラムを使用します。all:{ [fsbl_config] bh_auth_enable [keysrc_encryption] bbram_red_key [pskfile] primary0.pem





[sskfile] secondary0.pem [ bootloader, destination_cpu=a53-0, encryption=aes, aeskeyfile=aes0.nky, authentication=rsa ] fsbl.elf

[ destination_device=pl, encryption=aes, aeskeyfile=aes1.nky, authentication=rsa ] system.bit

[ destination_cpu=a53-0, authentication=rsa, exception_level=el-3, trustzone=secure ] bl31.elf

[ destination_cpu=a53-0, authentication=rsa, exception_level=el-2 ] u-boot.elf}

注記: HSM フローで pmufw_image を使用するには、上記の BIF に [pmufw_image] pmufw.elf を追加します。同様の行の場合、これは FSBL が暗号化される stage2a bif に追加する必要があります。フローの残りは、同じままになります。ステージ 0: SPK のハッシュを生成次に、BIF ファイルの抜粋を示します。stage0:{ [ppkfile]primary.pub [spkfile]secondary.pub}

Bootgen コマンドは次のとおりです。bootgen -arch zynqmp -image stage0.bif -generate_hashes -w on -log error

ステージ 1: SPK ハッシュに署名 (パーティションを暗号化)

次に、OpenSSL を使用して SPK ハッシュを生成するコードの抜粋を示します。openssl rsautl -raw -sign -inkey primary0.pem -in secondary.pub.sha384 > secondary.pub.sha384.sig

このコマンドの出力は secondary.pub.sha384.sig です。





ステージ 2a: FSBL を暗号化次の BIF ファイルの抜粋部分を使用して FSBL を暗号化します。Stage 2a:{ [keysrc_encryption] bbram_red_key

[ bootloader,destination_cpu=a53-0, encryption=aes, aeskeyfile=aes0.nky ] fsbl.elf}

Bootgen コマンドは次のとおりです。bootgen -arch zynqmp -image stage2a.bif -o fsbl_e.bin -w on -log error

ステージ 2b: ビットストリームを暗号化次の BIF ファイルエントリを生成します。stage2b:{ [ encryption=aes, aeskeyfile=aes1.nky, destination_device=pl, pid=1 ] system.bit}

Bootgen コマンドは次のとおりです。bootgen -arch zynqmp -image stage2b.bif -o system_e.bin -w on -log error

ステージ 3: ブートヘッダーハッシュを生成次の BIF ファイルを使用してブートヘッダーハッシュを生成します。stage3:{ [fsbl_config] bh_auth_enable [ppkfile] primary.pub [spkfile] secondary.pub [spksignature]secondary.pub.sha384.sig [bootimage,authentication=rsa]fsbl_e.bin}






ステージ 4: ブートヘッダーハッシュに署名次の OpenSSL コマンドを使用して、ブートヘッダーハッシュを生成します。openssl rsautl -raw -sign -inkey secondary0.pem -in bootheader.sha384 > bootheader.sha384.sig

ステージ 5: パーティションハッシュを取得BIF ファイルの次のコマンドを使用して、パーティションハッシュを取得します。stage5:{ [ppkfile]primary.pub [spkfile]secondary.pub [spksignature]secondary.pub.sha384.sig [bhsignature]bootheader.sha384.sig [bootimage,authentication=rsa]fsbl_e.bin [bootimage,authentication=rsa]system_e.bin [ destination_cpu=a53-0, authentication=rsa, exception_level=el-3, trustzone=secure ] bl31.elf

[ destination_cpu=a53-0, authentication=rsa, exception_level=el-2 ] u-boot.elf}


ビットストリームパーティション用に複数のハッシュが生成されます。詳細は、外部メモリを使用したビットストリーム認証を参照してください。ブートヘッダーハッシュもこのステージ 5 で生成されます。ステージ 5 では bh_auth_enable が使用されないので、このハッシュはステージ 3 で生成されたものとは異なります。これは必要に応じてステージ 5 に追加できますが、ステージ 3 で生成されたブートヘッダーハッシュはステージ 4 で署名され、この署名は HSM モードフローでしか使用されないので、大きな影響はありません。

ステージ 6: パーティションハッシュに署名OpenSSL を使用して次のファイルを作成します。openssl rsautl -raw -sign -inkey secondary0.pem -in fsbl.elf.0.sha384 > fsbl.elf.0.sha384.sigopenssl rsautl -raw -sign -inkey secondary0.pem -in system.bit.0.sha384 > system.bit.0.sha384.sigopenssl rsautl -raw -sign -inkey secondary0.pem -in system.bit.1.sha384 > system.bit.1.sha384.sigopenssl rsautl -raw -sign -inkey secondary0.pem -in system.bit.2.sha384 > system.bit.2.sha384.sig





openssl rsautl -raw -sign -inkey secondary0.pem -in system.bit.3.sha384 > system.bit.3.sha384.sigopenssl rsautl -raw -sign -inkey secondary0.pem -in u-boot.elf.0.sha384 > u-boot.elf.0.sha384.sigopenssl rsautl -raw -sign -inkey secondary0.pem -in bl31.elf.0.sha384 > bl31.elf.0.sha384.sigopenssl rsautl -raw -sign -inkey secondary0.pem -in bl31.elf.1.sha384 > bl31.elf.1.sha384.sig

ステージ 7: パーティション署名を認証証明に挿入ステージ 7a: 次のコードを BIF ファイルに追加して FSBL 署名を挿入します。Stage7a:{ [fsbl_config] bh_auth_enable [ppkfile] primary.pub [spkfile] secondary.pub [spksignature]secondary.pub.sha384.sig [bhsignature]bootheader.sha384.sig [bootimage,authentication=rsa,presign=fsbl.elf.0.sha384.sig]fsbl_e.bin}

Bootgen コマンドは次のとおりです。bootgen -arch zynqmp -image stage7a.bif -o fsbl_e_ac.bin -efuseppkbits efuseppkbits.txt -nonbooting -w on -log error

ステージ 7b: BIF ファイルに次を追加してビットストリーム署名を挿入します。stage7b:{ [ppkfile]primary.pub [spkfile]secondary.pub [spksignature]secondary.pub.sha384.sig [bhsignature]bootheader.sha384.sig [ bootimage, authentication=rsa, presign=system.bit.0.sha384.sig ] system_e.bin}

Bootgen コマンドは次のとおりです。bootgen -arch zynqmp -image stage7b.bif -o system_e_ac.bin -nonbooting -w on -log error

ステージ 7c: BIF ファイルに次を追加して U-Boot 署名を挿入します。stage7c:{ [ppkfile] primary.pub [spkfile] secondary.pub [spksignature]secondary.pub.sha384.sig [bhsignature]bootheader.sha384.sig [ destination_cpu=a53-0,





authentication=rsa, exception_level=el-2, presign=u-boot.elf.0.sha384.sig ] u-boot.elf}

Bootgen コマンドは次のとおりです。bootgen -arch zynqmp -image stage7c.bif -o u-boot_ac.bin -nonbooting -w on -log error

ステージ 7d: BIF ファイルに次を追加して ATF 署名を挿入します。stage7d:{ [ppkfile] primary.pub [spkfile] secondary.pub [spksignature]secondary.pub.sha384.sig [bhsignature]bootheader.sha384.sig [ destination_cpu=a53-0, authentication=rsa, exception_level=el-3, trustzone=secure, presign=bl31.elf.0.sha384.sig ] bl31.elf}

Bootgen コマンドは次のとおりです。bootgen -arch zynqmp -image stage7d.bif -o bl31_ac.bin -nonbooting -w on -log error

ステージ 8: パーティションを結合し、ヘッダーテーブルハッシュを取得BIF ファイルに次を追加します。stage8: { [bootimage]fsbl_e_ac.bin [bootimage]system_e_ac.bin [bootimage]bl31_ac.bin [bootimage]u-boot_ac.bin}

Bootgen コマンドは次のとおりです。bootgen -arch zynqmp -image stage8.bif -generate_hashes -o stage8.bin -w on -log error

ステージ 9: ヘッダーテーブルハッシュに署名OpenSSL を使用して次のファイルを生成します。openssl rsautl -raw -sign -inkey secondary0.pem -in ImageHeaderTable.sha384 > ImageHeaderTable.sha384.sig





ステージ 10: パーティションを結合し、ヘッダーテーブル署名を挿入BIF ファイルに次を追加します。stage10: { [headersignature]ImageHeaderTable.sha384.sig [bootimage]fsbl_e_ac.bin [bootimage]system_e_ac.bin [bootimage]bl31_ac.bin [bootimage]u-boot_ac.bin}

Bootgen コマンドは次のとおりです。bootgen -arch zynqmp -image stage10.bif -o final.bin -w on -log error

注記: 現時点では、Versal デバイスでは HSM モードはサポートされていません。

HSM を使用した Versal デバイスブートイメージの作成次の図に、Versal デバイスの HSM モードのブートイメージを示します。





図 19: 0 〜 12 ステージのブートプロセス

Stage-1cStage-1b

Stage-0c

BOOTGEN Generate SPKHashFSBL

nky key

Stage-0b

BH hash

BOOTGEN

Stag

e-7a

Encrypt FSBL

PPK & SPK FSBL with

auth certificate

encrypted FSBL

SPK signBOOTGEN

Stag

e-7a

Encrypt FSBL

PPK & SPK

encrypted FSBL

SPK sign

nky key

HSM

Stag

e-1a

Generate SPK

signatureSPK hash SPK

signature

BOOTGEN

Stage-2b

Stag

e-2a

Encrypt PMC

Subsystem

PMC Subsystem

Encrypted PMC Subsystem

nky key

BOOTGEN

Stag

e-3 Generate

BHHash

PPK & SPK BH hash

Encrypted PMC Subsystem

HSM

Stag

e-4

Generate BH

signature

BH hashBH signature

BOOTGEN

Stag

e-5 Generate

partition hashes

PPK & SPKpartition hashesencrypted

partitions

SPK signature BH signature

HSM

Stag

e-6

Generate partition

signaturespartition hashes

partition signatures

BOOTGEN

Stag

e-7a

PPK & SPK

PMC Subsystem with authentication certificate

encrypted PLM

SPK signature BH signature*BOOTGEN

Stag

e-0a

SPKGenerate

SPKHash

SPK

SPK hash

HSM

Stag

e-9

Generate IHT

SignatureIHT Hash

IHT Signature

BOOTGEN

Stag

e-10

Generate Meta

Header Hash

IHT Signature

Meta Header Hash

BOOTGEN

Stag

e-12 Generate

bootmage


Certificate

final bootimage

Meta Header Signature

SPK Signature

Insert PMC Subsystem Signature

Stage-7bStage-7c

Stage-2c

SSK

SSK

PPK & SPK

AC header

SPK ID

HSM

Generate Meta

Header Signature

Meta Header Hash

Meta Header Signature

SSK

BOOTGEN

Generate Image Header

Table Hash

PPK & SPKImage Header Table Hash

nky key

SPK signature

nky key

IHT Signature

IHT Signature

SPK Signature

nky key

PPK & SPK

Stag

e-11

Stag

e-8

SPK signature

X21547-111020

注記: PMC サブシステムには、PLM、PMC_CDO、およびトポロジ CDO が含まれます。





PDI の生成標準 BIF を使用して PDI を生成します。command : bootgen -arch versal -image all.bif -w on -o final_ref.bin -log error all:{ id_code = 0x04ca8093 extended_id_code = 0x01 id = 0x2 boot_config {bh_auth_enable} metaheader { authentication = rsa, pskfile = rsa-keys/PSK2.pem, sskfile = rsa-keys/SSK2.pem encryption = aes, keysrc = bbram_red_key, aeskeyfile = enc_keys/efuse_red_metaheader_key.nky, dpacm_enable } image { name = pmc_subsys, id = 0x1c000001 partition { id = 0x01, type = bootloader, authentication = rsa, pskfile = rsa-keys/PSK1.pem, sskfile = rsa-keys/SSK1.pem, encryption = aes, keysrc = bbram_red_key, aeskeyfile = encr_keys/bbram_red_key.nky, dpacm_enable, file = images/gen_files/executable.elf } partition { id = 0x09, type = pmcdata, load = 0xf2000000, aeskeyfile = gen_keys/pmcdata.nky, file = images/gen_files/topology_xcvc1902.v1.cdo, file = images/gen_files/pmc_data.cdo } } image { name = lpd, id = 0x4210002 partition { id = 0x0C, type = cdo, authentication = rsa, pskfile = rsa-keys/PSK3.pem, sskfile = rsa-keys/SSK3.pem, encryption = aes, keysrc = bbram_red_key, aeskeyfile = gen_keys/key1.nky,





dpacm_enable, file = images/gen_files/lpd_data.cdo } partition { id = 0x0B, core = psm, authentication = rsa, pskfile = rsa-keys/PSK1.pem, sskfile = rsa-keys/SSK1.pem, encryption = aes, keysrc = bbram_red_key, aeskeyfile = gen_keys/key2.nky, dpacm_enable, blocks = 8192(20);4096(*), file = images/static_files/psm_fw.elf } } image { name = fpd, id = 0x420c003 partition { id = 0x08, type = cdo, authentication = rsa, pskfile = rsa-keys/PSK3.pem, sskfile = rsa-keys/SSK3.pem, encryption = aes, keysrc = bbram_red_key, aeskeyfile = gen_keys/key5.nky, dpacm_enable, file = images/gen_files/fpd_data.cdo } } image { name = ss, id = 0x1c000033 partition { id = 0x0D, type = cdo, authentication = rsa, pskfile = rsa-keys/PSK2.pem, sskfile = rsa-keys/SSK2.pem, encryption = aes, keysrc = bbram_red_key, aeskeyfile = gen_keys/key6.nky, dpacm_enable, file = images/gen_files/subsystem.cdo } }}





HSM モードの手順ステージ 0: SPK ハッシュを生成SSK1 のハッシュ値を生成:

command : bootgen -arch versal -image stage0-SSK1.bif -generate_hashes -w on -log error stage0-SSK1:{ spkfile = rsa-keys/SSK1.pub}

SSK2 のハッシュ値を生成:


SSK3 のハッシュ値を生成:


ステージ 1: SPK ハッシュに署名生成されたハッシュに署名:

openssl rsautl -raw -sign -inkey rsa-keys/PSK1.pem -in SSK1.pub.sha384 > SSK1.pub.sha384.sigopenssl rsautl -raw -sign -inkey rsa-keys/PSK2.pem -in SSK2.pub.sha384 > SSK2.pub.sha384.sigopenssl rsautl -raw -sign -inkey rsa-keys/PSK3.pem -in SSK3.pub.sha384 > SSK3.pub.sha384.sig

ステージ 2: 個々のパーティションを暗号化パーティション 1 を暗号化:

command : bootgen -arch versal -image stage2a.bif -o pmc_subsys_e.bin -w on -log error stage2a:{ image { name = pmc_subsys, id = 0x1c000001 partition





{ id = 0x01, type = bootloader, encryption=aes, keysrc = bbram_red_key, aeskeyfile = encr_keys/bbram_red_key.nky, dpacm_enable, file = images/gen_files/executable.elf } partition { id = 0x09, type = pmcdata, load = 0xf2000000, aeskeyfile = encr_keys/pmcdata.nky, file = images/gen_files/topology_xcvc1902.v1.cdo, file = images/gen_files/pmc_data.cdo } }}

パーティション 2 を暗号化:

command : bootgen -arch versal -image stage2b-1.bif -o lpd_lpd_data_e.bin -w on -log error stage2b-1:{ image { name = lpd, id = 0x4210002 partition { id = 0x0C, type = cdo, encryption=aes, keysrc = bbram_red_key, aeskeyfile = encr_keys/key1.nky, dpacm_enable, file = images/gen_files/lpd_data.cdo } }}


command : bootgen -arch versal -image stage2b-2.bif -o lpd_psm_fw_e.bin -w on -log error stage2b-2:{ image { name = lpd, id = 0x4210002 partition { id = 0x0B, core = psm, encryption = aes, keysrc = bbram_red_key, aeskeyfile = encr_keys/key2.nky, dpacm_enable, file = images/static_files/psm_fw.elf } }}






command : bootgen -arch versal -image stage2c.bif -o fpd_e.bin -w on -log error stage2c:{ image { name = fpd, id = 0x420c003 partition { id = 0x08, type = cdo, encryption=aes, keysrc = bbram_red_key, aeskeyfile = encr_keys/key5.nky, dpacm_enable, file = images/gen_files/fpd_data.cdo } }}

ステージ 3: ブートヘッダーハッシュを生成command : bootgen -arch versal -image stage3.bif -generate_hashes -w on -log error stage3:{ image_config {bh_auth_enable} image { name = pmc_subsys, id = 0x1c000001 { type = bootimage, authentication=rsa, ppkfile = rsa-keys/PSK1.pub, spkfile = rsa-keys/SSK1.pub, spksignature = SSK1.pub.sha384.sig, file = pmc_subsys_e.bin } }}

ステージ 4: ブートヘッダーハッシュに署名生成されたハッシュに署名:

openssl rsautl -raw -sign -inkey rsa-keys/SSK1.pem -in bootheader.sha384 > bootheader.sha384.sig

ステージ 5: パーティションのハッシュを生成command : bootgen -arch versal -image stage5.bif -generate_hashes -w on -log error stage5:{ bhsignature = bootheader.sha384.sig





image { name = pmc_subsys, id = 0x1c000001 { type = bootimage, authentication=rsa, ppkfile = rsa-keys/PSK1.pub, spkfile = rsa-keys/SSK1.pub, spksignature = SSK1.pub.sha384.sig, file = pmc_subsys_e.bin } } image { name = lpd, id = 0x4210002 partition { type = bootimage, authentication = rsa, ppkfile = rsa-keys/PSK3.pub, spkfile = rsa-keys/SSK3.pub, spksignature = SSK3.pub.sha384.sig, file = lpd_lpd_data_e.bin } partition { type = bootimage, authentication = rsa, ppkfile = rsa-keys/PSK1.pub, spkfile = rsa-keys/SSK1.pub, spksignature = SSK1.pub.sha384.sig, file = lpd_psm_fw_e.bin } } image { id = 0x1c000000, name = fpd { type = bootimage, authentication=rsa, ppkfile = rsa-keys/PSK3.pub, spkfile = rsa-keys/SSK3.pub, spksignature = SSK3.pub.sha384.sig, file = fpd_e.bin } } image { id = 0x1c000033, name = ss { type = bootimage, authentication = rsa, ppkfile = rsa-keys/PSK2.pub, spkfile = rsa-keys/SSK2.pub, spksignature = SSK2.pub.sha384.sig, file = subsystem_e.bin } }}





ステージ 6: パーティションハッシュに署名openssl rsautl -raw -sign -inkey rsa-keys/SSK1.pem -in pmc_subsys_1.0.sha384 > pmc_subsys.0.sha384.sig openssl rsautl -raw -sign -inkey rsa-keys/SSK3.pem -in lpd_12.0.sha384 > lpd.0.sha384.sigopenssl rsautl -raw -sign -inkey rsa-keys/SSK1.pem -in lpd_11.0.sha384 > psm.0.sha384.sigopenssl rsautl -raw -sign -inkey rsa-keys/SSK1.pem -in lpd_11.1.sha384 > psm.1.sha384.sigopenssl rsautl -raw -sign -inkey rsa-keys/SSK1.pem -in lpd_11.2.sha384 > psm.2.sha384.sigopenssl rsautl -raw -sign -inkey rsa-keys/SSK1.pem -in lpd_11.3.sha384 > psm.3.sha384.sigopenssl rsautl -raw -sign -inkey rsa-keys/SSK1.pem -in lpd_11.4.sha384 > psm.4.sha384.sig openssl rsautl -raw -sign -inkey rsa-keys/SSK3.pem -in fpd_8.0.sha384 > fpd_data.cdo.0.sha384.sigopenssl rsautl -raw -sign -inkey rsa-keys/SSK2.pem -in ss_13.0.sha384 > ss.0.sha384.sig

ステージ 7: パーティションの署名を認証証明に挿入パーティション 1 の署名を挿入:

command : bootgen -arch versal -image stage7a.bif -o pmc_subsys_e_ac.bin -w on -log error stage7a:{ bhsignature = bootheader.sha384.sig image_config {bh_auth_enable} image { name = pmc_subsys, id = 0x1c000001 { type = bootimage, authentication=rsa, ppkfile = rsa-keys/PSK1.pub, spkfile = rsa-keys/SSK1.pub, spksignature = SSK1.pub.sha384.sig, presign = pmc_subsys.0.sha384.sig, file = pmc_subsys_e.bin } }}

パーティション 2 の署名を挿入:

command : bootgen -arch versal -image stage7b-1.bif -o lpd_lpd_data_e_ac.bin -w on -log error stage7b-1:{ image { name = lpd, id = 0x4210002 partition





{ type = bootimage, authentication = rsa, ppkfile = rsa-keys/PSK3.pub, spkfile = rsa-keys/SSK3.pub, spksignature = SSK3.pub.sha384.sig, presign = lpd.0.sha384.sig, file = lpd_lpd_data_e.bin } } }


command : bootgen -arch versal -image stage7b-2.bif -o lpd_psm_fw_e_ac.bin -w on -log error stage7b-2:{ image { name = lpd, id = 0x4210002 partition { type = bootimage, authentication = rsa, ppkfile = rsa-keys/PSK1.pub, spkfile = rsa-keys/SSK1.pub, spksignature = SSK1.pub.sha384.sig, presign = psm.0.sha384.sig, file = lpd_psm_fw_e.bin } } }


command : bootgen -arch versal -image stage7c.bif -o fpd_e_ac.bin.bin -w on -log error stage7c:{ image { id = 0x1c000000, name = fpd { type = bootimage, authentication=rsa, ppkfile = rsa-keys/PSK3.pub, spkfile = rsa-keys/SSK3.pub, spksignature = SSK3.pub.sha384.sig, presign = fpd_data.cdo.0.sha384.sig, file = fpd_e.bin } }}






command : bootgen -arch versal -image stage7d.bif -o subsystem_e_ac.bin -w on -log error stage7d:{ image { id = 0x1c000033, name = ss { type = bootimage, authentication = rsa, ppkfile = rsa-keys/PSK2.pub, spkfile = rsa-keys/SSK2.pub, spksignature = SSK2.pub.sha384.sig, presign = ss.0.sha384.sig, file = subsystem_e.bin } }}

ステージ 8: イメージヘッダーテーブルのハッシュを生成command : bootgen -arch versal -image stage8a.bif -generate_hashes -w on -log error stage8:{ id_code = 0x04ca8093 extended_id_code = 0x01 id = 0x2 metaheader { authentication = rsa, ppkfile = rsa-keys/PSK2.pub, spkfile = rsa-keys/SSK2.pub, spksignature = SSK2.pub.sha384.sig, encryption=aes, keysrc = bbram_red_key, aeskeyfile = encr_keys/efuse_red_metaheader_key.nky, dpacm_enable, revoke_id = 0x00000002 } image { {type = bootimage, file = pmc_subsys_e_ac.bin} } image { {type = bootimage, file = lpd_lpd_data_e_ac.bin} {type = bootimage, file = lpd_psm_fw_e_ac.bin} } image { {type = bootimage, file = fpd_e_ac.bin} }





image { {type = bootimage, file = subsystem_e_ac.bin} }}

ステージ 9: イメージヘッダーテーブルのハッシュに署名生成されたハッシュに署名:

openssl rsautl -raw -sign -inkey rsa-keys/SSK2.pem -in imageheadertable.sha384 > imageheadertable.sha384.sig

ステージ 10: メタヘッダーハッシュを生成command : bootgen -arch versal -image stage8b.bif -generate_hashes -w on -log error stage8b:{ headersignature = imageheadertable.sha384.sig id_code = 0x04ca8093 extended_id_code = 0x01 id = 0x2 metaheader { authentication = rsa, ppkfile = rsa-keys/PSK2.pub, spkfile = rsa-keys/SSK2.pub, spksignature = SSK2.pub.sha384.sig, encryption=aes, keysrc = bbram_red_key, aeskeyfile = encr_keys/efuse_red_metaheader_key.nky, dpacm_enable } image { {type = bootimage, file = pmc_subsys_e_ac.bin} } image { {type = bootimage, file = lpd_lpd_data_e_ac.bin} {type = bootimage, file = lpd_psm_fw_e_ac.bin} } image { {type = bootimage, file = fpd_e_ac.bin} } image { {type = bootimage, file = subsystem_e_ac.bin} }}





ステージ 11: メタヘッダーハッシュに署名openssl rsautl -raw -sign -inkey rsa-keys/SSK2.pem -in MetaHeader.sha384 > metaheader.sha384.sig

ステージ 12: パーティションを結合し、ヘッダー署名を挿入完全な PDI をビルド:

command : bootgen -arch versal -image stage10.bif -o final.bin -w on -log error stage10:{ headersignature = imageheadertable.sha384.sig id_code = 0x04ca8093 extended_id_code = 0x01 id = 0x2 metaheader { authentication = rsa, ppkfile = rsa-keys/PSK2.pub, spkfile = rsa-keys/SSK2.pub spksignature = SSK2.pub.sha384.sig, presign = metaheader.sha384.sig encryption=aes, keysrc = bbram_red_key, aeskeyfile = encr_keys/efuse_red_metaheader_key.nky, dpacm_enable } image { {type = bootimage, file = pmc_subsys_e_ac.bin} } image { {type = bootimage, file = lpd_lpd_data_e_ac.bin} {type = bootimage, file = lpd_psm_fw_e_ac.bin} } image { {type = bootimage, file = fpd_e_ac.bin} } image { {type = bootimage, file = subsystem_e_ac.bin} }}





第 6 章

FPGA のサポート第 5 章: ブート時のセキュリティで説明したように、FPGA のみで構成されるデバイスもセキュリティを維持しながらフィールド展開する必要があります。ザイリンクスツールは、暗号化および認証を実現するためのエンベデッド IPモジュールをプログラミングロジックの一部として提供します。Bootgen は、7 シリーズ以降の FPGA ファミリデバイスに幅広く対応するセキュアイメージの作成 (暗号化および/または認証) をサポートしています。この章では、Bootgen を使用してビットストリームを暗号化して認証する方法について例を挙げて説明します。FPGA をサポートする Bootgen は、スタンドアロンの Bootgen インストールで入手できます。注記: 7 シリーズデバイス以降のビットストリームのみがサポートされています。

暗号化および認証ザイリンクス 7 シリーズ FPGA は、内蔵型で PL ベースの HMAC (Hash-based Message Authentication Code)、および Cipher Block Chaining (CBC) モードの Advanced Encryption Standard (AES) モジュールを使用します。UltraScale以降のデバイスでは、AES-256/Galois Counter Mode (GCM) が使用され、HMAC は不要です。

暗号化の例暗号化されたビットストリームを作成するには、aeskeyfile 属性を使用して BIF で AES キーファイルを指定します。encryption=aes 属性は、BIF ファイルにリストされている暗号化の必要なビットストリームに対して指定する必要があります。bootgen -arch fpga -image secure.bif -w -o securetop.bit

BIF ファイルは次のようになります。the_ROM_image:{ [aeskeyfile] encrypt.nky [encryption=aes] top.bit}

認証の例次に、FPGA ビットストリームを認証するための Bootgen コマンドを示します。bootgen -arch fpga -image all.bif -o rsa.bit -w on -log error

第 6 章: FPGA のサポート




BIF ファイルは次のとおりです。the_ROM_image:{ [sskfile] rsaPrivKeyInfo.pem [authentication=rsa] plain.bit}

ファミリキー/難読化キー注記: 難読化キー暗号化は、Versal デバイスではサポートされません。難読化キーの暗号化を使用するには、ザイリンクスサポートに登録し、ターゲットデバイスファミリのファミリキーファイルをリクエストする必要があります。このファイルが格納されている場所へのパスは、難読化キーの暗号化を実行する前に bif オプションとして渡しておく必要があります。ファミリキーを入手するには、[email protected] までお問い合わせください。image:{ [aeskeyfile] key_file.nky [familykey] familyKey.cfg [encryption=aes] top.bit}

次の図に、サンプルの aeskey ファイルを示します。図 20: AES キーのサンプル

HSM モードプロダクションの FPGA では HSM モードを使用しますが、標準モードでも選択できます。

標準モード標準モードでは、認証署名が埋め込まれたビットストリームが生成されます。このモードでは、認証されたビットストリームを生成するための秘密キーがユーザーに提供されていると想定されます。次のコマンドを使用して Bootgenを実行します。bootgen -arch fpga -image all.bif -o rsa_ref.bit -w on -log error

次に、HSM モードで認証されたビットストリームを生成する手順を示します。このモードでは、秘密キーはセキュアチームが管理し、ユーザーには提供されません。次の図に、HSM モードのフローを示します。





図 21: HSM モードのフロー

Stage-2

HSMGenerateSignature

Bitstream Hash& SSK

Stage-0

BootgenAuthenticate with

dummy keydummy.bit

Dummy Key and Bitstream

Bitstream Signature

Stage-3

BootgenUpdate

SignatureAuthenticated Bitstream

Bitstream& SPK

Stage-1

Bootgen

Generate Hashesdummy.bit Hash

X21279-081618

ステージ 0: ダミーキーで認証これは、1 つのビットストリームに 1 回だけ実行するタスクです。ステージ 0 では、Bootgen により stage0.bif ファイルが生成されます。the_ROM_image:{ [sskfile] dummykey.pem [authentication=rsa] plain.bit}

注記: 認証されたビットストリームには、ヘッダー、実際のビットストリーム、署名およびフッターが含まれます。この dummy.bit は、認証されたビットストリームのフォーマットのビットストリームを取得するために作成され、ダミー署名を含みます。ダミービットファイルが Bootgen に渡されると、署名が計算されてオフセットに挿入され、認証されたビットストリームが生成されます。ステージ 1: ハッシュを生成bootgen -arch fpga -image stage1.bif -generate_hashes -log error

Stage1.bif は次のとおりです。the_ROM_image:{ [authentication=rsa] dummy.bit}





ステージ 2: Hash HSM に署名 (例として OpenSSL を使用)

openssl rsautl -sign -inkey rsaPrivKeyInfo.pem -in dummy.sha384 > dummy.sha384.sig

ステージ 3: RSA 証明を実際の署名で更新Stage3.bif は次のとおりです。bootgen -arch fpga -image stage3.bif -w -o rsa_rel.bit -log error

the_ROM_image:{ [spkfile] rsaPubKeyInfo.pem [authentication=rsa, presign=dummy.sha384.sig]dummy.bit}

注記: eFUSE に書き込む必要のある公開キーダイジェストは、HSM モードのステージ 3 で生成されたrsaPubKeyInfo.pem.nky ファイルに含まれます。





第 7 章

ユースケースおよび例この章では、Bootgen の代表的なユースケースおよび例を示します。一部のユースケースは複雑であり、手順を明示的に示す必要があります。これらのユースケースおよび例で使用している属性の定義の詳細は、属性を参照してください。

Zynq MPSoC ユースケース異なるコアでのシンプルアプリケーションブート次の例に、異なるコアで動作するアプリケーションでブートイメージを作成する方法を示します。pmu_fw.elf はbootROM によってロードされます。fsbl_a53.elf はブートローダーであり、A53-0 コアにロードされます。app_a53.elf は A53-1 コアで、app_r5.elf は r5-0 コアで実行されます。the_ROM_image: { [pmufw_image] pmu_fw.elf [bootloader, destination_cpu=a53-0] fsbl_a53.elf [destination_cpu=a53-1] app_a53.elf [destination_cpu=r5-0] app_r5.elf}

bootROM でロードされる PMU ファームウェア次の例に、bootROM によってロードされた pmu_fw.elf でブートイメージを作成する方法を示します。the_ROM_image: { [pmufw_image] pmu_fw.elf [bootloader, destination_cpu=a53-0] fsbl_a53.elf [destination_cpu=r5-0] app_r5.elf}

次の例に、bootROM によってロードされた pmu_fw.elf でブートイメージを作成する方法を示します。[pmufw_image] 属性を使用して PMU ファームウェアが指定されている場合、PMU ファームウェアは別のパーティションとしては扱われません。FSBL に追加され、FSBL と PMU ファームウェアが 1 つのパーティションに含まれます。このため、PMU ファームウェアは Bootgen ログにも表示されません。

第 7 章: ユースケースおよび例




FSBL でロードされる PMU ファームウェア次の例に、FSBL によりロードされた pmu_fw.elf を含むブートイメージを作成する方法を示します。the_ROM_image:{ [bootloader, destination_cpu=a53-0] fsbl_a53.elf [destination_cpu=pmu] pmu_fw.elf [destination_cpu=r5-0] app_r5.elf}

注記: Bootgen は、[pmufw_image] にも [bootloader] で指定されたオプションを使用します。[pmufw_image]では追加のパラメーターは指定できません。

Linux のブート次の例に、Zynq® UltraScale+™ MPSoC デバイス (arch=zynqmp) で Linux をブートする方法を示します。• fsbl_a53.elf はブートローダーであり、a53-0 上で動作します。• pmu_fw.elf は FSBL によってロードされます。• bl31.elf は Arm® トラステッドファームウェア (ATF) であり、el-3 で動作します。• U-Boot プログラムの uboot は a53-0 上で el-2 で動作します。• Linux イメージの image.ub はオフセット 0x1E40000 に配置され、0x10000000 にロードされます。the_ROM_image: { [bootloader, destination_cpu = a53-0]fsbl_a53.elf [destination_cpu=pmu]pmu_fw.elf [destination_cpu=a53-0, exception_level=el-3, trustzone]bl31.elf [destination_cpu=a53-0, exception_level=el-2] u-boot.elf [offset=0x1E40000, load=0X10000000, destination_cpu=a53-0]image.ub }

暗号化フロー: BBRAM レッドキー次の例は、BBRAM に格納されているレッドキーを使用して FSBL およびアプリケーションに対して暗号化を有効にし、ブートイメージを作成する方法を示しています。the_ROM_image: { [keysrc_encryption] bbram_red_key [ bootloader, encryption=aes, aeskeyfile=aes0.nky, destination_cpu=a53-0 ] ZynqMP_Fsbl.elf [destination_cpu=a53-0, encryption=aes, aeskeyfile=aes1.nky]App_A53_0.elf }





暗号化フロー: eFUSE に格納されたレッドキー次の例は、eFUSE に格納されているレッドキーを使用して FSBL およびアプリケーションに対して暗号化を有効にし、ブートイメージを作成する方法を示しています。the_ROM_image: { [keysrc_encryption] efuse_red_key

[ bootloader, encryption=aes, aeskeyfile=aes0.nky, destination_cpu=a53-0 ] ZynqMP_Fsbl.elf

[ destination_cpu = a53-0, encryption=aes, aeskeyfile=aes1.nky ] App_A53_0.elf }

暗号化フロー: eFUSE に格納されたブラックキー次の例に、eFUSE に格納されている efuse_blk_key を使用して FSBL およびアプリケーションに対して暗号化を有効にし、ブートイメージを作成する方法を示します。FSBL に対しては認証も有効です。the_ROM_image: { [fsbl_config] puf4kmode, shutter=0x0100005E [auth_params] ppk_select=0; spk_id=0x5 [pskfile] primary_4096.pem [sskfile] secondary_4096.pem [keysrc_encryption] efuse_blk_key [bh_key_iv] bhkeyiv.txt [ bootloader, encryption=aes, aeskeyfile=aes0.nky, authentication=rsa ] fsbl.elf }

注記: ブラックキーの暗号化を使用する場合は、ブートイメージの認証が必須です。

暗号化フロー: ブートヘッダーに格納されたブラックキー次の例に、ブートヘッダーに格納されている bh_blk_key を使用して FSBL およびアプリケーションに対して暗号化を有効にし、ブートイメージを作成する方法を示します。FSBL に対しては、認証も有効にします。the_ROM_image: { [pskfile] PSK.pem [sskfile] SSK.pem [fsbl_config] shutter=0x0100005E [auth_params] ppk_select=0





[bh_keyfile] blackkey.txt [bh_key_iv] black_key_iv.txt [puf_file]helperdata4k.txt [keysrc_encryption] bh_blk_key [ bootloader, encryption=aes, aeskeyfile=aes0.nky, authentication=rsa, destination_cpu=a53-0 ] ZynqMP_Fsbl.elf

[ destination_cpu = a53-0, encryption=aes, aeskeyfile=aes1.nky ] App_A53_0.elf }

注記: ブラックキーの暗号化を使用する場合は、ブートイメージの認証が必要です。

暗号化フロー: eFUSE に格納されたグレーキー次の例に、eFUSE に格納されている efuse_gry_key を使用して FSBL およびアプリケーションに対して暗号化を有効にし、ブートイメージを作成する方法を示します。the_ROM_image: { [keysrc_encryption] efuse_gry_key [bh_key_iv] bh_key_iv.txt [ bootloader, encryption=aes, aeskeyfile=aes0.nky, destination_cpu=a53-0 ] ZynqMP_Fsbl.elf [ destination_cpu=a53-0, encryption=aes, aeskeyfile=aes1.nky ] App_A53_0.elf }

暗号化フロー: ブートヘッダーに格納されたグレーキー次の例に、ブートヘッダーに格納されている bh_gry_key を使用して FSBL およびアプリケーションに対して暗号化を有効にし、ブートイメージを作成する方法を示します。the_ROM_image:{ [keysrc_encryption] bh_gry_key [bh_keyfile] bhkey.txt [bh_key_iv] bh_key_iv.txt [ bootloader,





encryption=aes, aeskeyfile=aes0.nky, destination_cpu=a53-0 ] ZynqMP_Fsbl.elf [ destination_cpu=a53-0, encryption=aes, aeskeyfile=aes1.nky ] App_A53_0.elf }

操作キー次の例に、eFUSE に格納されているレッドキーを使用して FSBL およびアプリケーションに対して暗号化を有効にし、ブートイメージを作成する方法を示します。the_ROM_image:{ [fsbl_config] opt_key [keysrc_encryption] efuse_red_key

[ bootloader, encryption=aes, aeskeyfile=aes0.nky, destination_cpu=a53-0 ] ZynqMP_Fsbl.elf

[ destination_cpu=a53-0, encryption=aes, aeskeyfile=aes1.nky ] App_A53_0.elf }

開発環境での操作キーを使用したデバイスキーの保護次に、秘密レッドキーを管理するチーム A (セキュアチーム) とチーム B (非セキュアチーム) の 2 つの開発チームが共同で作業している場合に、秘密レッドキーを共有せずに暗号化されたイメージをビルドする手順を説明します。チーム A は秘密レッドキーを管理します。チーム B は、開発およびテスト用に暗号化されたイメージをビルドしますが、秘密レッドキーにはアクセスできません。チーム A はデバイスキー (Op_key (操作キー) オプションを使用) を使用してブートローダーを暗号化し、それをチーム B に渡します。チーム B は Op_key を使用してその他すべてのパーティションを暗号化します。チーム B は、Bootgen を使用して、暗号化したパーティションとチーム A から受け取った暗号化されたブートローダーを 1 つの boot.bin にまとめます。次に、イメージを作成する手順を説明します。方法 1

まず、チーム A が opt_key を使用してデバイスキーでブートローダーを暗号化し、それをチーム B に渡します。チーム B は、操作キーをデバイスキーとして使用し、すべてのパーティションと暗号化されたブートローダーをまとめて完全なイメージを作成します。





1. ブートローダーをデバイスキーで暗号化します。bootgen -arch zynqmp -image stage1.bif -o fsbl_e.bin -w on -log error

stage1.bif の例:

stage1:{ [fsbl_config] opt_key [keysrc_encryption] bbram_red_key [ bootloader, destination_cpu=a53-0, encryption=aes,aeskeyfile=aes.nky ] fsbl.elf}

stage1 の aes.nky の例:

Device xc7z020clg484;Key 0 AD00C023E238AC9039EA984D49AA8C819456A98C124AE890ACEF002100128932;IV 0 F7F8FDE08674A28DC6ED8E37;Key Opt 229C993D1310DD27B6713749B6D07FCF8D3DCA01EC9C64778CBAF457D613508F;

2. 操作キーをデバイスキーとして使用し、暗号化されたブートローダーと残りのパーティションをまとめて完全なイメージを作成します。bootgen -arch zynqmp -image stage2a.bif -o final.bin -w on -log error

stage2.bif の例:

stage2:{ [bootimage]fsbl_e.bin [ destination_cpu=a53-0, encryption=aes, aeskeyfile=aes-opt.nky ] hello.elf [ destination_cpu=a53-1, encryption=aes, aeskeyfile=aes-opt1.nky ] hello1.elf}

stage2 の aes-opt.nky の例:

Device xc7z020clg484;Key 0 229C993D1310DD27B6713749B6D07FCF8D3DCA01EC9C64778CBAF457D613508F;IV 0 F7F8FDE08674A28DC6ED8E37;

方法 2

まず、チーム A が opt_key オプションを使用してデバイスキーでブートローダーを暗号化し、それをチーム B に渡します。チーム B は、操作キーをデバイスキーとして使用し、パーティションごとに個別に暗号化されたイメージを作成します。最後に、チーム B は Bootgen を使用して、暗号化されたパーティションすべてと暗号化されたブートローダーをまとめて完全なイメージを作成します。





1. ブートローダーをデバイスキーで暗号化します。bootgen -arch zynqmp -image stage1.bif -o fsbl_e.bin -w on -log error

stage1.bif の例:

stage1:{ [fsbl_config] opt_key [keysrc_encryption] bbram_red_key [ bootloader, destination_cpu=a53-0, encryption=aes,aeskeyfile=aes.nky ] fsbl.elf}

stage1 の aes.nky の例:

Device xc7z020clg484;Key 0 AD00C023E238AC9039EA984D49AA8C819456A98C124AE890ACEF002100128932;IV 0 F7F8FDE08674A28DC6ED8E37;Key Opt 229C993D1310DD27B6713749B6D07FCF8D3DCA01EC9C64778CBAF457D613508F

2. 操作キーをデバイスキーとして使用し、残りのパーティションを暗号化します。bootgen -arch zynqmp -image stage2a.bif -o hello_e.bin -w on -log error

stage2a.bif の例:

stage2a:{ [ destination_cpu=a53-0, encryption=aes, aeskeyfile=aes-opt.nky ] hello.elf}bootgen -arch zynqmp -image stage2b.bif -o hello1_e.bin -w on -log error

stage2b.bif の例:

stage2b:{ [aeskeyfile] aes-opt.nky [ destination_cpu=a53-1, encryption=aes, aeskeyfile=aes-opt.nky ] hello1.elf}

stage2a および stage2b の aes-opt.nky の例:

Device xc7z020clg484;Key 0 229C993D1310DD27B6713749B6D07FCF8D3DCA01EC9C64778CBAF457D613508F;IV 0 F7F8FDE08674A28DC6ED8E37;

3. Bootgen を使用して上記の例をまとめて完全なイメージを作成します。Use bootgen to stitch the above, to form a complete image.





stage3.bif の例:

stage3:{ [bootimage]fsbl_e.bin [bootimage]hello_e.bin [bootimage]hello1_e.bin}

注記: aes.nky の opt_key は aes-opt.nky のキー 0 と同じで、IV 0 は両方の nky ファイルで同じである必要があります。

シングルパーティションイメージこの機能は、Bootgen の U-Boot プロンプトで作成されたシングルパーティション (ビットストリームなしの) イメージの認証および暗号化の両方またはいずれかをサポートします。注記: 複数パーティションを含むイメージはサポートしません。

セキュアイメージを読み込む U-Boot コマンドzynqmp secure <srcaddr> <len> [key_addr]

このコマンドは、アドレス $src で $len bytes\ long のセキュアイメージを検証します。暗号化にキーを使用する必要がある場合は、オプションで key_addr を指定できます。

認証のみのユースケースU-Boot で認証のみを使用する場合は、次の例に示すように bif を使用して認証イメージを作成します。1. U-Boot で認証されるシングルパーティションイメージを作成します。注記: elf ファイルを指定する場合は、複数のロード可能なセクションが含まれていないことを確認してください。elf ファイルに複数のロード可能なセクションが含まれる場合は、入力を .bin 形式に変換して、その .binを bif で入力として指定します。次に、bif の例を示します。the_ROM_image:{ [pskfile]rsa4096_private1.pem [sskfile]rsa4096_private2.pem [auth_params] ppk_select=1;spk_id=0x1 [authentication = rsa]Data.bin}

2. イメージが生成されたら、その認証イメージを DDR にダウンロードします。3. 次の例のように、U-Boot コマンドを実行してセキュアイメージを認証します。

ZynqMP> zynqmp secure 100000 2d000Verified image at 0x102800

4. 問題なく認証されると、U-Boot から実際のパーティションの開始アドレスが返されます。エラーがあった場合は、エラーコードが表示されます。RSA_EN eFUSE をプログラムする場合、イメージ認証は必須です。eFUSERSA がイネーブルの場合、ブートヘッダーの認証はサポートされません。





暗号化のみのユースケースイメージを暗号化するだけの場合、デバイスキーはサポートされません。認証がイネーブルになっていない場合は、KUP キーの暗号化のみがサポートされます。

認証フロー次の例は、FSBL およびアプリケーションに対して認証を有効にし、PPK ハッシュ値の検証をスキップしたブートヘッダー認証を有効にしてブートイメージを作成する方法を示しています。the_ROM_image: { [fsbl_config] bh_auth_enable [auth_params] ppk_select=0; spk_id=0x00000000 [pskfile] PSK.pem [sskfile] SSK.pem [ bootloader, authentication=rsa, destination_cpu=a53-0 ] ZynqMP_Fsbl.elf [destination_cpu=a53-0, encryption=aes] App_A53_0.elf }

SHA-3 eFUSE RSA 認証と PPK0 を使用する BIF ファイル次の例は、FSBL およびアプリケーションに対して認証を有効にし、PPK ハッシュ値の検証をスキップしたブートヘッダー認証を有効にしてブートイメージを作成する方法を示しています。the_ROM_image: { [auth_params] ppk_select=0; spk_id=0x00000000 [pskfile] PSK.pem [sskfile] SSK.pem [ bootloader, authentication=rsa, destination_cpu=a53-0 ] ZynqMP_Fsbl.elf [destination_cpu=a53-0, authentication=aes] App_A53_0.elf }





XIP次の例は、zynqmp (Zynq® UltraScale+™ MPSoC) に対して、XIP を実行するブートイメージの作成方法を示しています。the_ROM_image:{ [ bootloader, destination_cpu=a53-0, xip_mode ] mpsoc_qspi_xip.elf}

コマンドの詳細は、xip_mode を参照してください。

オフセット属性を使用した分割この例は、オフセット属性を使用した分割方法を示しています。the_ROM_image:{ [split]mode=slaveboot,fmt=bin [bootloader, destination_cpu = a53-0] fsbl.elf [destination_cpu = pmu, offset=0x3000000] pmufw.elf [destination_device = pl, offset=0x4000000] design_1_wrapper.bit [destination_cpu = a53-0, exception_level = el-3, trustzone, offset=0x6000000]\ hello.elf }

オフセットがパーティションに指定されると、ブートイメージ内のそのパーティションのアドレスは指定したオフセットから開始されます。Bootgen は、現在のパーティションに指定されたオフセットと前のパーティション間のギャップを埋めるため、前のパーティションに 0xFF を追加します。これにより、同じイメージで分割をしようとすると、ブートイメージはそのパーティションのアドレス (この場合は指定したオフセット) に基づいて分割されるようになります。分割されたパーティション出力に 0xFF がパディングされているのはこのためです。

Versal ACAP のユースケースVersal™ ACAP に対しては、Vivado® でプログラマブルデバイスイメージ (PDI) と呼ばれるブートイメージを生成します。この Vivado で生成される PDI には、ブートローダーソフトウェア実行ファイルの PLM (Platform Loader andManager) のほか、PL 関連のコンポーネントとサポートされるデータファイルが含まれます。Vivado はプロジェクトおよび CIPS コンフィギュレーションに基づいて BIF ファイルを作成し、Bootgen を起動して PDI を作成します。この BIF が XSA の一部として Vitis™ のようなソフトウェアツールにエクスポートされます。その後、BIF は必要なパーティションおよび属性を使用して変更できます。id_code および extended_id_code に関連する行が BIF ファイルにそのまま含まれていることを確認してください。この情報は PDI が Bootgen で生成される際に必ず必要となります。





BIF を手動で記述する場合は、Vivado で同じデバイスに対して生成された BIF を参照し、id_code およびextended_id_code に関連する行を手動で記述する BIF に追加してください。次に、Vivado で生成されたサンプル BIF を示します。new_bif:{ id_code = 0x04ca8093 extended_id_code = 0x01 id = 0x2 image { name = pmc_subsys id = 0x1c000001 partition { id = 0x01 type = bootloader file = gen_files/executable.elf } partition { id = 0x09 type = pmcdata, load = 0xf2000000 file = topology_xcvc1902.v2.cdo file = gen_files/pmc_data.cdo } } image { name = lpd id = 0x4210002 partition { id = 0x0C type = cdo file = gen_files/lpd_data.cdo } partition { id = 0x0B core = psm file = static_files/psm_fw.elf } } image { name = pl_cfi id = 0x18700000 partition { id = 0x03 type = cdo file = system.rcdo } partition { id = 0x05 type = cdo file = system.rnpi } } image {





name = fpd id = 0x420c003 partition { id = 0x08 type = cdo file = gen_files/fpd_data.cdo } }}

注記: Vivado で生成された BIF ファイルの executable.elf は、PLM を実行するファームウェアです。Vivado プロジェクトで生成される BIF ファイルは、<vivado_project>/<vivado_project>.runs/impl_1/<Vivado_project>_wrapper.pdi.bif に含まれます。

ブートローダー、PMC_CDO次の例に、ブートローダーを PMC_CDO と使用する方法を示します。all:{ id_code = 0x04ca8093 extended_id_code = 0x01

init = reginit.ini image { {type=bootloader, file=PLM.elf} {type=pmcdata, file=pmc_cdo.bin} }}

ブートローダー、PMC_CDO およびロードアドレス次の例に、ブートローダーを PMC_CDO およびロードアドレスと一緒に使用する方法を示します。all:{ id_code = 0x04ca8093 extended_id_code = 0x01

init = reginit.ini image { {type=bootloader, file=PLM.elf} {type=pmcdata, load=0xf0400000, file=pmc_cdo.bin} }}





ブートローダーのチェックサムのイネーブル次の例に、ブートローダーを使用しながらチェックサムをイネーブルにする方法を示します。

all:{ id_code = 0x04ca8093 extended_id_code = 0x01

init = reginit.ini image { {type=bootloader, checksum=sha3, file=PLM.elf} {type=pmcdata, load=0xf0400000, file=pmc_cdo.bin} }}

ブートローダー、PMC_CDO、PL CDO、NPI次の例に、ブートローダーを PMC_CDO および NPI と使用する方法を示します。new_bif:{ id_code = 0x04ca8093 extended_id_code = 0x01 id = 0x2 image { name = pmc_subsys, id = 0x1c000001 { id = 0x01, type = bootloader, file = gen_files/executable.elf } { id = 0x09, type = pmcdata, load = 0xf2000000, file = topology_xcvc1902.v2.cdo, file = gen_files/pmc_data.cdo } } image { name = lpd, id = 0x4210002 { id = 0x0C, type = cdo, file = gen_files/lpd_data.cdo } { id = 0x0B, core = psm, file = static_files/psm_fw.elf } } image { name = pl_cfi, id = 0x18700000 { id = 0x03, type = cdo, file = system.rcdo } { id = 0x05, type = cdo, file = system.rnpi } } image { name = fpd, id = 0x420c003 { id = 0x08, type = cdo, file = gen_files/fpd_data.cdo } }}





ブートローダー、PMC_CDO、PL CDO、NPI、PS CDO、および PSELF次の例に、ブートローダーを PMC_CDO、NPI、PS CDO、および PS ELF と共に使用する方法を示します。new_bif:{ id_code = 0x04ca8093 extended_id_code = 0x01 id = 0x2 image { name = pmc_subsys, id = 0x1c000001 { id = 0x01, type = bootloader, file = gen_files/executable.elf } { id = 0x09, type = pmcdata, load = 0xf2000000, file = topology_xcvc1902.v2.cdo, file = gen_files/pmc_data.cdo } } image { name = lpd, id = 0x4210002 { id = 0x0C, type = cdo, file = gen_files/lpd_data.cdo } { id = 0x0B, core = psm, file = static_files/psm_fw.elf } } image { name = pl_cfi, id = 0x18700000 { id = 0x03, type = cdo, file = system.rcdo } { id = 0x05, type = cdo, file = system.rnpi } } image { name = fpd, id = 0x420c003 { id = 0x08, type = cdo, file = gen_files/fpd_data.cdo } } image { name = apu_ss, id = 0x1c000000 { core = a72-0, file = apu.elf } { core = r5-0, file = rpu.elf } }}

AI エンジンのコンフィギュレーションおよび AI エンジンのパーティション次の例に、AI エンジンのブートイメージと AI エンジンのパーティションをコンフィギュレーションする方法を示します。all:{ image { { type=bootimage, file=base.pdi } } image { name=default_subsys, id=0x1c000000 { type=cdo





file = Work/ps/cdo/aie.cdo.reset.bin file = Work/ps/cdo/aie.cdo.clock.gating.bin file = Work/ps/cdo/aie.cdo.error.handling.bin file = Work/ps/cdo/aie.cdo.elfs.bin file = Work/ps/cdo/aie.cdo.init.bin file = Work/ps/cdo/aie.cdo.enable.bin } }}

注記: 異なる CDO が統合され、PDI に 1 つのパーティションが作成されます。

既存 PDI への新規パーティションの追加次の例に、既存の PDI に新しいパーティションを追加する方法を示します。1. Vivado で生成された PDI (base.pdi) を使用します。2. dtb、uboot、および bl31 アプリケーションを追加して新しい PDI を作成します。new_bif:{ image { { type = bootimage, file = base.pdi } } image { name = apu_ss, id = 0x1c000000 { load = 0x1000, file = system.dtb } { exception_level = el-2, file = u-boot.elf } { core = a72-0, exception_level = el-3, trustzone, file = bl31.elf } }}

RSA 認証次の例に、RSA 認証の使用方法を示します。all:{ id_code = 0x04CA8093 extended_id_code = 0x01 boot_config {bh_auth_enable} image { name = pmc_subsys, id = 0x1c000001 {type = bootloader, authentication=rsa, pskfile = ./PSK.pem, sskfile = ./SSK2.pem, revoke_id = 0x2, file = ./plm.elf} {type = pmcdata, file = ./pmc_data.cdo} } metaheader { authentication=rsa,pskfile = ./PSK.pem, sskfile = ./SSK16.pem, revoke_id = 0x10,





} image { id = 0x1c000002, name = ss_psm {type = cdo, authentication=rsa, pskfile = ./PSK1.pem, sskfile = ./SSK1.pem, revoke_id = 0x1, file = ./lpd_data.cdo} { core = psm, file = ./psm_fw.elf} } image { id = 0x1c000000, name = fpd {type = cdo, authentication=rsa, pskfile = ./PSK1.pem, sskfile = ./SSK5.pem, revoke_id = 0x5, file = ./fpd_data.cdo} } image { id = 0x1c000000, name = subsystem {type = cdo,file = ./subsystem.cdo} }}

ECDSA 認証次の例に、ECDSA 認証の使用方法を示します。

all:{ id_code = 0x04CA8093 extended_id_code = 0x01 boot_config {bh_auth_enable} image { name = pmc_subsys, id = 0x1c000001 {type = bootloader, authentication = ecdsa-p384, pskfile = ./PSK.pem, sskfile = ./SSK2.pem, revoke_id = 0x2, file = ./plm.elf} {type = pmcdata, file = ./pmc_data.cdo} } metaheader { authentication = ecdsa-p384,pskfile = ./PSK.pem, sskfile = ./SSK16.pem, revoke_id = 0x10, } image { id = 0x1c000002, name = ss_psm {type = cdo, authentication = ecdsa-p521, pskfile = ./PSK1.pem, sskfile = ./SSK1.pem, revoke_id = 0x1, file = ./lpd_data.cdo} { core = psm, file = ./psm_fw.elf} } image { id = 0x1c000000, name = fpd





{type = cdo, authentication = ecdsa-p384, pskfile = ./PSK1.pem, sskfile = ./SSK5.pem, revoke_id = 0x5, file = ./fpd_data.cdo} } image { id = 0x1c000000, name = subsystem {type = cdo,file = ./subsystem.cdo} }}

AES 暗号化次の例に、AES 暗号化の使用方法を示します。


image { {type=bootloader, encryption=aes, keysrc=bbram_red_key, aeskeyfile=key1.nky, file=plm.elf} {type=pmcdata, load=0xf0400000, file=pmc_cdo.bin} {type=cdo, file=ps_cdo.bin} {core=a72-0, encryption=aes, keysrc=bbram_red_key, aeskeyfile=key2.nky, file=a72_app.elf} }}

キーローリングを使用した AES 暗号化次の例に、キーローリングを使用した AES 暗号化方法を示します。


image { { type=bootloader, encryption=aes, keysrc=bbram_red_key, aeskeyfile=key1.nky, blocks=65536;32768;16384;8192;4096;2048;1024;512, file=plm.elf } { type=pmcdata, load=0xf0400000, file=pmc_cdo.bin } {





type=cdo, file=ps_cdo.bin } { core=a72-0, encryption=aes, keysrc=bbram_red_key, aeskeyfile=key2.nky, blocks=65536;32768;16384;8192;4096;2048;1024;512, file=a72_app.elf } }}

複数のキーソースを使用した AES 暗号化次の例に、異なるパーティションに異なるキーソースを使用する方法を示します。

all:{ bh_keyfile = ./PUF4K_KEY.txt puf_file = ./PUFHD_4K.txt bh_kek_iv = ./blk_iv.txt bbram_kek_iv = ./bbram_blkIv.txt efuse_kek_iv = ./efuse_blkIv.txt boot_config {puf4kmode , shutter=0x0100005E} id_code = 0x04CA8093 extended_id_code = 0x01 image { name = pmc_subsys, id = 0x1c000001 {type = bootloader, encryption = aes, keysrc=bbram_blk_key, dpacm_enable,revoke_id = 0x5, aeskeyfile = ./plm.nky, file = ./plm.elf} {type = pmcdata, aeskeyfile = pmcCdo.nky, file = ./pmc_data.cdo} } metaheader { encryption = aes, keysrc=bbram_blk_key,dpacm_enable, revoke_id = 0x6, aeskeyfile = metaheader.nky } image { id = 0x1c000002, name = ss_psm {type = cdo, encryption = aes, keysrc = bh_blk_key, pufhd_bh, revoke_id = 0x8, aeskeyfile = ./psmfw.nky, file = ./lpd_data.cdo} { core = psm, file = ./psm_fw.elf} } image { id = 0x1c000000, name = fpd {type = cdo, encryption = aes, keysrc = efuse_blk_key, dpacm_enable, revoke_id = 0x10,aeskeyfile = ./fpdcdo.nky,/*Here PUF helper data is also on efuse */





file = ./fpd_data.cdo} } image { id = 0x1c000000, name = subsystem {type = cdo,file = ./subsystem.cdo} }}

AES 暗号化および認証次の例に、AES 暗号化と認証の使用方法を示します。all:{ bh_kek_iv = ./blkiv.txt bh_keyfile = ./blkkey.txt efuse_kek_iv = ./efuse_blkIv.txt boot_config {bh_auth_enable, puf4kmode , shutter=0x0100005E} id_code = 0x04CA8093 extended_id_code = 0x01 image { name = pmc_subsys, id = 0x1c000001 {type = bootloader, encryption = aes, keysrc=bh_blk_key, dpacm_enable,revoke_id = 0x5, aeskeyfile = ./plm.nky, authentication = rsa, pskfile = ./PSK1.pem, sskfile = ./SSK5.pem, file = ./plm.elf} {type = pmcdata, aeskeyfile = ./pmc_data.nky, file = ./pmc_data.cdo} } metaheader { encryption = aes, keysrc=bh_blk_key, dpacm_enable, revoke_id = 0x6, aeskeyfile = metaheader.nky } image { id = 0x1c000002, name = ss_psm {type = cdo, encryption = aes, keysrc = bbram_red_key, revoke_id = 0x8, aeskeyfile = psmfw.nky, file = ./lpd_data.cdo} { core = psm, file = ./psm_fw.elf} } image { id = 0x1c000000, name = fpd {type = cdo, encryption = aes, keysrc = efuse_blk_key, dpacm_enable, revoke_id = 0x10, aeskeyfile = fpd.nky, authentication = ecdsa-p384, pskfile = ./PSK1.pem, sskfile = ./SSK5.pem, file = ./fpd_data.cdo} } image { id = 0x1c000000, name = subsystem {type = cdo,file = ./subsystem.cdo} }}





既存 PDI での PLM の置換次の例では、既存の PDI で PLM を置換する手順について説明します。1. Vivado で生成された PDI (base.pdi) を使用します。2. ベース PDI からの PLM (ブートローダー) を置換し新しい PDI を作成します。

new_bif:{ image { { type = bootimage, file = base.pdi } { type = bootloade, file = plm_v1.elf } }}

Bootgen によりブートローダー plm.elf が新しい plm_v1.elf に置き換えられます。

PDI を作成する Bootgen コマンドの例次のコマンドを使用して PDI を作成します。bootgen -arch versal -image {filename.bif} -w -o {boot.pdi}





第 8 章

BIF 属性のリファレンスaarch32_mode

構文• Zynq® UltraScale+™ MPSoC:

[aarch32_mode] <partition>

• Versal™ ACAP の場合:

{aarch32_mode, file=<partition>}

説明バイナリファイルが 32 ビットモードで実行されるように指定します。注記: Bootgen では自動的に .elf ファイルからプロセッサの実行モードが検出されます。これは、バイナリファイルにのみ使用できます。

引数指定されたパーティション。

例• Zynq UltraScale+ MPSoC:

the_ROM_image:{ [bootloader, destination_cpu=a53-0] zynqmp_fsbl.elf [destination_cpu=a53-0, aarch32_mode] hello.bin [destination_cpu=r5-0] hello_world.elf}

• Versal ACAP の場合:

new_bif:{ image { { type = bootimage, file = base.pdi } } image

第 8 章: BIF 属性のリファレンス




{ name = apu_ss, id = 0x1c000000 { core = a72-0, aarch32_mode, file = apu.bin } }}

注記: *base.pdi は Vivado で生成される PDI です。

aeskeyfile構文• Zynq デバイスおよび FPGA の場合:

[aeskeyfile] <key filename>

• Zynq UltraScale+ MPSoC の場合:

[aeskeyfile = <keyfile name>] <partition>


{ aeskeyfile = <keyfile name>, file = <filename> }

説明AES キーファイルへのパスを指定します。キーファイルには、パーティションの暗号化に使用される AES キーが含まれます。キーファイルの内容は、eFUSE または BBRAM に書き込む必要があります。指定したパスにキーファイルが存在しない場合は、Bootgen により暗号化に使用する新しいキーが生成されます。注記: Zynq UltraScale+ MPSoC のみ: BIF ファイルで複数のキーファイルを指定できます。使用するすべての NKY ファイルで Key0、IV0、および Key Opt を同じにする必要があります。1 つの ELF ファイルに対して複数のパーティションを生成する場合、各パーティションを固有のキーファイルのキーを使用して暗号化できます。次の例を参照してください。引数指定するファイルの名前。

戻り値なし





Zynq-7000 SoC 例fsbl.elf パーティションと hello.elf パーティションは test.nky のキーを使用して暗号化されます。all: { [keysrc_encryption] bbram_red_key [aeskeyfile] test.nky [bootloader, encryption=aes] fsbl.elf [encryption=aes] hello.elf }

サンプルキー (.nky) ファイルは test.nky です。Device xc7z020clg484; Key 0 8177B12032A7DEEE35D0F71A7FC399027BF....D608C58; Key StartCBC 952FD2DF1DA543C46CDDE4F811506228; Key HMAC 123177B12032A7DEEE35D0F71A7FC3990BF....127BD89;

Zynq UltraScale+ MPSoC 例例 1:

fsbl.elf パーティションは test.nky のキーを使用し、hello.elf は test1.nky のキーを使用し、app.elf はtest2.nky のキーを使用して暗号化されます。サンプル BIF は test_multipl.bif です。all: { [keysrc_encryption] bbram_red_key [bootloader,encryption=aes,aeskeyfile=test.nky] fsbl.elf [encryption=aes,aeskeyfile=test1.nky] hello.elf [encryption=aes,aeskeyfile=test2.nky] app.elf }

例 2:

Bootgen が、hello.elf の hello.elf.0、hello.elf.1、および hello.elf.2 という 3 つのパーティションを作成するとします。サンプル BIF は test_mulitple.bif です。all: { [keysrc_encryption] bbram_red_key [bootloader,encryption=aes,aeskeyfile=test.nky] fsbl.elf [encryption=aes,aeskeyfile=test1.nky] hello.elf }

その他の情報:

• fsbl.elf パーティションは、test.nky のキーで暗号化されます。すべての hello.elf パーティションは、test1.nky のキーを使用して暗号化されます。

• test1.1.nky および test1.2.nky という名前のキーファイルを test1.nky と同じパスに置くことで、hello パーティションごとに一意のキーファイルを使用できます。

• hello.elf.0 は test1.nky を使用• hello.elf.1 は test1.1.nky を使用• hello.elf.2 は test1.2.nky を使用





• キーファイル (test1.1.nky または test1.2.nky) が存在しない場合、Bootgen はそのキーファイルを生成します。

• aeskeyfile の形式:

.nky ファイルには次のフィールドを使用できます。• Device: .nky ファイルを使用するデバイスの名前。Zynq デバイスおよび Zynq UltraScale+ MPSoC の両方で有効です。

• Keyx, IVx: x は Key0、Key1、Key2 ...、IV0、IV1、IV2...といったキー/IV 番号に該当する整数。AES キーは 256ビット、キーは 12 バイト長にする必要があります。Keyx は Zynq デバイスおよび Zynq UltraScale+ MPSoCに有効ですが、IVx は Zynq UltraScale+ MPSoC にのみ有効です。

• Key Opt: ブートローダーの最初のブロックを暗号化するのに使用するオプションのキー。Zynq UltraScale+MPSoC にのみ有効です。

• StartCBC - CBC Key: CBC キーは 128 ビット長である必要があります。Zynq デバイスにのみ有効です。• HMAC - HMAC Key: HMAC キーは 128 ビット長である必要があります。Zynq デバイスにのみ有効です。• Seed: パーティションの暗号化に必要なキー/IV ペアを生成するために使用する必要のある最初のシード。

AES シードは 256 ビット長である必要があります。Zynq UltraScale+ MPSoC にのみ有効です。• FixedInputData: カウンターモード KDF への入力としてシードと共に使用されるデータ。AES 固定入力データは 60 バイト長である必要があります。Zynq UltraScale+ MPSoC にのみ有効です。

注記:• シードは FixedInputData と共に指定する必要があります。• シードには、複数のキー/IV ペアは使用されません。

Versal ACAP の例:

all: { image { name = pmc_subsys, id = 0x1c000001 { type = bootloader, encryption = aes, keysrc = bbram_red_key, aeskeyfile = key1.nky, file = plm.elf } { type = pmcdata, load = 0xf2000000, aeskeyfile = key2.nky, file = pmc_cdo.bin } { type=cdo, encryption = aes, keysrc = efuse_red_key, aeskeyfile = key3.nky, file=fpd_data.cdo } } }





a_hwrot構文boot_config { a_hwrot }

説明非対称ハードウェアの信頼のルート (A-HWRoT) ブートモード。Bootgen で A-HWRoT ブートモードのデザインルールがチェックされます。プロダクション PDI でのみ有効です。

alignment構文• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

[alignment= <value>] <partition>


{ alignment=<value>, file=<partition> }

バイトアライメントを設定します。パーティションは、この値の倍数値に揃えられるまでパディングされます。この属性はオフセットと共に使用することはできません。

引数揃えられるバイト数。

例• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

all:{ [bootloader]fsbl.elf [alignment=64] u-boot.elf}







{ name = apu_ss, id = 0x1c000000 { core = a72-0, alignment=64, file = apu.elf } }}


auth_params構文[auth_params] ppk_select=<0|1>; spk_id <32-bit spk id>;/ spk_select=<spk-efuse/user-efuse>; auth_header

説明認証パラメーターは、ブートイメージ内のパーティションの認証に使用する PPK、SPK などの追加設定を指定します。この BIF パラメーターの引数は次のとおりです。• ppk_select: 使用する PPK を選択します。オプションは 0 (デフォルト) または 1 です。• spk_id: 使用または取り消し可能な SPK を指定します。ユーザー eFUSE サポートおよび RSA キー取り消しの改善を参照してください。デフォルト値は 0x00 です。

• spk_select: SPK とユーザー eFUSE を識別。オプションは spk-efuse (デフォルト) と user_efuse です。• header_auth: パーティションが認証されていない場合のヘッダーを認証。注記:

1. ppk_select は各イメージに固有です。2. 各パーティションは固有の spk_select および spk_id を持つことができます。3. spk-efuse id はイメージ全体で一意ですが、spk-efuse id はパーティションによって異なる場合があります。4. パーティションの範囲外の spk_select/spk_id は、ヘッダーと、これらの指定をパーティション属性として持たないその他のパーティションに使用されます。

例サンプル BIF 1 - test.bif

all:{ [auth_params]ppk_select=0;spk_id=0x4 [pskfile] primary.pem [sskfile]secondary.pem [bootloader, authentication=rsa]fsbl.elf}





サンプル BIF 2 - test.bif

all: { [auth_params] ppk_select=0;spk_select=user-efuse;spk_id=0x22 [pskfile] primary.pem [sskfile] secondary.pem [bootloader, authentication = rsa] fsbl.elf }


all: { [auth_params] ppk_select=1; spk_select= user-efuse; spk_id=0x22; header_auth [pskfile] primary.pem [sskfile] secondary.pem [destination_cpu=a53-0] test.elf }


all: { [auth_params] ppk_select=1;spk_select=user-efuse;spk_id=0x22 [pskfile] primary.pem [sskfile] secondary0.pem /* FSBL - Partition-0) */ [ bootloader, destination_cpu = a53-0, authentication = rsa, spk_id = 0x3, spk_select = spk-efuse, sskfile = secondary1.pem ] fsbla53.elf /* Partition-1 */ [ destination_cpu = a53-1, authentication = rsa, spk_id = 0x24, spk_select = user-efuse, sskfile = secondary2.pem ] hello.elf }





authentication構文• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

[authenication = <options>] <partition>


{authentication=<options>, file=<partition>}

説明認証するパーティションを指定します。

引数• none: パーティションは認証されません。これがデフォルト値です。• rsa: パーティションを RSA アルゴリズムを使用して認証します。• ecdsa-p384: パーティションは ECDSA p384 曲線を使用して認証します。• ecdsa-p521: パーティションは ECDSA p521 曲線を使用して認証します。例• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

all: { [ppkfile] ppk.txt [spkfile] spk.txt [bootloader, authentication=rsa] fsbl.elf [authentication=rsa] hello.elf }


all:{ id_code = 0x04ca8093 extended_id_code = 0x01 id = 0x2 boot_config {bh_auth_enable}

metaheader { authentication = rsa, pskfile = PSK2.pem, sskfile = SSK2.pem }

image { name = pmc_subsys, id = 0x1c000001 partition





{ id = 0x01, type = bootloader, authentication = rsa, pskfile =PSK1.pem, sskfile =SSK1.pem, file = executable.elf } partition { id = 0x09, type = pmcdata, load = 0xf2000000, file = topology_xcvc1902.v1.cdo, file = pmc_data.cdo } }

image { name = lpd, id = 0x4210002 partition { id = 0x0C, type = cdo, authentication = rsa, pskfile = PSK3.pem, sskfile = SSK3.pem, file = lpd_data.cdo } partition { id = 0x0B, core = psm, authentication = rsa, pskfile = PSK1.pem, sskfile = SSK1.pem, file = psm_fw.elf } }

image { name = fpd, id = 0x420c003 partition { id = 0x08, type = cdo, authentication = rsa, pskfile = PSK3.pem, sskfile = SSK3.pem, file = fpd_data.cdo } }}

big_endian構文• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

[big_endian] <partition>






{ big_endian, file=<partition> }

説明バイナリファイルをビッグエンディアン形式に指定します。注記: Bootgen では、自動的に .elf ファイルのエンディアン形式が検出されます。これは、バイナリファイルにのみ使用できます。



the_ROM_image:{ [bootloader, destination_cpu=a53-0] zynqmp_fsbl.elf [destination_cpu=a53-0, big_endian] hello.bin [destination_cpu=r5-0] hello_world.elf}


new_bif:{ image { { type = bootimage, file = base.pdi } } image { name = apu_ss, id = 0x1c000000 { core = a72-0, big_endian, file = apu.bin } }}

Note: *base.pdi is the PDI generated by Vivado

bbram_kek_iv構文bbram_kek_iv = <iv file path>

説明bbram ブラックキーの暗号化に使用する IV を指定します。bbram_kek_iv は、keysrc=bbram_blk_key の場合にのみ有効です。





例例は、複数のキーソースを使用した AES 暗号化を参照してください。

bh_kek_iv構文bh_kek_iv = <iv file path>

説明ブートヘッダーブラックキーの暗号化に使用する IV を指定します。bh_kek_iv は、keysrc=bh_blk_key の場合にのみ有効です。


bh_keyfile構文• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

[bh_keyfile] <key file path>


bh_keyfile = <key file path>

説明ブートヘッダーに格納される 256 ビットの難読化キーまたはブラックキーです。これは、暗号化キーのソースが難読化キーまたはブラックキーの場合にのみ有効です。注記: 難読化キーは、Versal デバイスではサポートされません。引数難読化キーまたはブラックキーへのパス (選択されているソースによって異なる)。






all: { [keysrc_encryption] bh_gry_key [bh_keyfile] obfuscated_key.txt [bh_key_iv] obfuscated_iv.txt [bootloader, encryption=aes, aeskeyfile = encr.nky, destination_cpu=a53-0]fsbl.elf }


all: { bh_keyfile = bh_key1.txt bh_kek_iv = blk_iv.txt image { name = pmc_subsys, id = 0x1c000001 { type = bootloader, encryption = aes, keysrc = bbram_red_key, aeskeyfile = key1.nky, file = plm.elf } { type = pmcdata, load = 0xf2000000, aeskeyfile = key2.nky, file = pmc_cdo.bin } { type=cdo, encryption = aes, keysrc = bh_blk_key, aeskeyfile = key3.nky, file=fpd_data.cdo } } }

bh_key_iv構文[bh_key_iv] <iv file path>

説明ブラックキーを復号化する際に使用する初期化ベクター。

引数ファイルへのパス。





例Sample BIF - test.bif all:{ [keysrc_encryption] bh_blk_key [bh_keyfile] bh_black_key.txt [bh_key_iv] bh_black_iv.txt [bootloader, encryption=aes, aeskeyfile=encr.nky, destination_cpu=a53-0]fsbl.elf}

bhsignature構文[bhsignature] <signature-file>

説明ブートヘッダーの署名を認証証明にインポートします。これは、秘密キー PSK を共有しない場合に使用できます。署名を作成して Bootgen に与えることができます。

例all: { [ppkfile] ppk.txt [spkfile] spk.txt [spksignature] spk.txt.sha384.sig [bhsignature] bootheader.sha384.sig [bootloader,authentication=rsa] fsbl.elf}

blocks構文• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

[blocks = <size><num>;<size><num>;...;<size><*>] <partition>


{ blocks = <size><num>;...;<size><*>, file=<partition> }





説明暗号化におけるキーローリング機能のブロックサイズを指定します。各モジュールは独自のキーを使用して暗号化されます。最初のキーはデバイスのキーソースに格納され、後続の各モジュールのキーは直前のモジュール内で暗号化 (ラップ) されます。

引数<size>: ブロックのサイズをバイト数で指定します。X(*) と指定すると、残りのブロックのサイズがすべて X になります。

例• Zynq® UltraScale+™ MPSoC:

Sample BIF - test.bif all:{ [keysrc_encryption] bbram_red_key [bootloader,encryption=aes, aeskeyfile=encr.nky, destination_cpu=a53-0,blocks=4096(2);1024;2048(2);4096(*)] fsbl.elf}


all:{ id_code = 0x04ca8093 extended_id_code = 0x01 id = 0x2

metaheader { encryption = aes, keysrc = bbram_red_key, aeskeyfile = efuse_red_metaheader_key.nky, dpacm_enable }

image { name = pmc_subsys, id = 0x1c000001 partition { id = 0x01, type = bootloader, encryption = aes, keysrc = bbram_red_key, aeskeyfile = bbram_red_key.nky, dpacm_enable, blocks = 4096(2);1024;2048(2);4096(*), file = executable.elf } partition { id = 0x09, type = pmcdata, load = 0xf2000000, aeskeyfile = pmcdata.nky, file = topology_xcvc1902.v1.cdo, file = pmc_data.cdo } }





image { name = lpd, id = 0x4210002 partition { id = 0x0C, type = cdo, encryption = aes, keysrc = bbram_red_key, aeskeyfile = key1.nky, dpacm_enable, blocks = 8192(20);4096(*), file = lpd_data.cdo } partition { id = 0x0B, core = psm, encryption = aes, keysrc = bbram_red_key, aeskeyfile = key2.nky, dpacm_enable, blocks = 4096(2);1024;2048(2);4096(*), file = psm_fw.elf } }

image { name = fpd, id = 0x420c003 partition { id = 0x08, type = cdo, encryption = aes, keysrc = bbram_red_key, aeskeyfile = key5.nky, dpacm_enable, blocks = 8192(20);4096(*), file = fpd_data.cdo } }}

注記: 上記の例では、最初の 2 つのブロックは 4096 バイト、次のブロックは 1024 バイト、その次の 2 つのブロックは 2048 バイトになり、残りのブロックは 4096 バイトになります。

boot_device構文• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

[boot_device] <options>


boot_device { <options>, address=<address> }





説明セカンダリブートデバイスを指定します。パーティションが存在するデバイスを示します。

引数Zynq デバイスおよび Zynq UltraScale+ MPSoC のオプション:

• qspi32

• qspi24

• nand

• sd0

• sd1

• sd-ls

• mmc

• usb

• ethernet

• pcie

• sata

Versal ACAP のオプション:

• qspi32

• qspi24

• nand

• sd0

• sd1

• sd-ls (SD0 (3.0) または SD1 (3.0))

• mmc

• usb

• ethernet

• pcie

• sata

• ospi

• smap

• sbi

• sd0-raw

• sd1-raw

• sd-ls-raw

• mmc1-raw





• mmc0

• mmc0-raw


all:{ [boot_device]sd0 [bootloader,destination_cpu=a53-0]fsbl.elf}


new_bif:{ id_code = 0x04ca8093 extended_id_code = 0x01 id = 0x2 boot_device { qspi32, address=0x10000 } image { name = pmc_subsys, id = 0x1c000001 { id = 0x01, type = bootloader, file = executable.elf } { id = 0x09, type = pmcdata, load = 0xf2000000, file = topology_xcvc1902.v2.cdo, file = pmc_data.cdo } } image { name = lpd, id = 0x4210002 { id = 0x0C, type = cdo, file = lpd_data.cdo } { id = 0x0B, core = psm, file = psm_fw.elf } } image { name = pl_cfi, id = 0x18700000 { id = 0x03, type = cdo, file = system.rcdo } { id = 0x05, type = cdo, file = system.rnpi } } image { name = fpd, id = 0x420c003 { id = 0x08, type = cdo, file = fpd_data.cdo } }}

bootimage構文• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

[bootimage] <partition>






{ type=bootimage, file=<partition> }

説明入力ファイルが Bootgen で作成されたブートイメージであることを指定します。

引数指定されたファイル名。

例• FSBL の場合:

all:{ [bootimage]fsbl.bin [bootimage]system.bin}

上記の例では、fsbl.bin および system.bin は Bootgen を使用して生成されたイメージです。○ fsbl.bin を生成する場合:

image: { [pskfile] primary.pem [sskfile] secondary.pem [bootloader, authentication=rsa, aeskeyfile=encr_key.nky, encryption=aes] fsbl.elf }

次のコマンドを使用します。bootgen -image fsbl.bif -o fsbl.bin -encrypt efuse

○ system.bin を生成する場合:

image: { [pskfile] primary.pem [sskfile] secondary.pem [authentication=rsa] system.bit }

次のコマンドを使用します。bootgen -image system.bif -o system.bin







{ name = apu_ss, id = 0x1c000000 { load = 0x1000, file = system.dtb } { exception_level = el-2, file = u-boot.elf } { core = a72-0, exception_level = el-3, trustzone, file = bl31.elf } }}


bootloader構文• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

[bootloader] <partition>


{ type=bootloader, file=<partition> }

説明ELF ファイルを FSBL または PLM として認識します。• この属性は ELF ファイルのみに適用可能です。• ブートローダーに指定できるのは 1 つのファイルのみです。• この ELF ファイルのプログラムヘッダーに含めることができるのは filesz が 0 より大きい LOAD セクションを 1つのみで、このセクションは実行可能であることが必要です (x フラグを設定)。

引数指定するファイルの名前。


all:{ [bootloader] fsbl.elf hello.elf}


new_bif:{ id_code = 0x04ca8093 extended_id_code = 0x01 id = 0x2 image





{ name = pmc_subsys, id = 0x1c000001 { id = 0x01, type = bootloader, file = executable.elf } { id = 0x09, type = pmcdata, load = 0xf2000000, file = topology_xcvc1902.v2.cdo, file = pmc_data.cdo } }}

bootvectors構文[bootvectors] <values>

説明この属性は、XIP (eXecute In Place) のベクターテーブルを指定します。

例all:{ [bootvectors]0x14000000,0x14000000,0x14000000,0x14000000,0x14000000,0x14000000,0x14000000,0x14000000 [bootloader,destination_cpu=a53-0]fsbl.elf}

boot_config構文boot_config { <options> }

説明ブートイメージのコンフィギュレーションに使用するパラメーターを指定します。次のオプションがあります。• bh_auth_enable: ブートヘッダー認証イネーブル。ブートイメージの認証を実行します (PPK ハッシュおよび

SPK ID の検証を除く)。• pufhd_bh: PUF ヘルパーデータをブートヘッダーに格納します (デフォルトは efuse)。PUF ヘルパーデータファイルは、puf_file オプションを使用して Bootgen に渡されます。

• puf4kmode: PUF を 4k ビットシンドロームコンフィギュレーションでの使用に合わせて調整します (デフォルトは 12k ビット)。

• shutter = <value>: PUF でシャッターオフセット時間およびシャッターオープン時間を設定する 32 ビットのPUF_SHUT レジスタ値を指定します。





• smap_width = <value>: SMAP バス幅を定義します。指定可能な値は 8、16、32 で、デフォルトは 32 ビットです。

• dpacm_enable: DPA カウンターメジャーイネーブル例example_1:{ boot_config {bh_auth_enable, smap_width=16 } pskfile = primary0.pem sskfile = secondary0.pem image { {type=bootloader, authentication=rsa, file=plm.elf} {type=pmcdata, load=0xf2000000, file=pmc_cdo.bin} }}

checksum構文• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

[checksum = <options>] <partition>


{ checksum = <options>, file=<partition> }

説明チェックサムを実行する必要があるパーティションを指定します。認証や暗号化などのよりセキュアな機能と共に使用することはできません。

引数• none: チェックサムなし。• MD5: Zynq®-7000 SoC デバイスの MD5 チェックサム。このデバイスでは、チェックサムはブートローダーでサポートされていません。

• SHA3: Zynq® UltraScale+™ MPSoC デバイスおよび Versal ACAP のチェックサム。例• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

all: { [bootloader] fsbl.elf [checksum=md5] hello.elf }






all: { image { name = image1, id = 0x1c000001 { type=bootloader, checksum=sha3, file=plm.elf } { type=pmcdata, file=pmc_cdo.bin } } }

copy構文{ copy = <addr> }

説明イメージがメモリの指定したアドレスにコピーされます。

例test:{ image { { type = bootimage, file = base.pdi } } image { name=subsys_1, id=0x1c000000, copy = 0x30000 { core=psm, file=psm.elf } { type=cdo, file=ps_data.cdo } { core=a72-0, file=a72_app.elf } }}

core構文{ core = <options> }

説明パーティションをどのコアで実行するかを指定します。





引数• *a72-0

• a72-1

• r5-0

• r5-1

• psm

• aie

例new_bif:{ image { { type = bootimage, file = base.pdi } } image { name = apu_ss, id = 0x1c000000 { core = a72-0, file = apu.elf } }}


delay_handoff構文{ delay_handoff }

説明サブシステムへのハンドオフが遅延されます。

例test:{ image { { type = bootimage, file = base.pdi } } image { name=subsys_1, id=0x1c000000, delay_handoff





{ core=psm, file=psm.elf } { type=cdo, file=ps_data.cdo } { core=a72-0, file=a72_app.elf } }}

delay_load構文{ delay_load }

説明サブシステムの読み込みが遅延されます。

例test:{ image { { type = bootimage, file = base.pdi } } image { name=subsys_1, id=0x1c000000, delay_load { core=psm, file=psm.elf } { type=cdo, file=ps_data.cdo } { core=a72-0, file=a72_app.elf } }}

destination_cpu構文[destination_cpu <options>] <partition>

説明パーティションをどのコアで実行するかを指定します。次の例では、FSBL を A53-0 コアで実行し、アプリケーションを R5-0 コアで実行するように指定します。注記:

• FSBL は、A53-0 または R5-0 のいずれかでのみ実行できます。





• FSBL によってロードされる PMU: [destination_cpu=pmu] pmu.elf。このフローでは、最初に bootROMが FSBL をロードし、続いて FSBL が PMU ファームウェアをロードします。

• bootROM によってロードされる PMU: [pmufw_image] pmu.elf。このフローでは、bootROM が PMU をロードした後に FSBL のロードが続くため、PMU は FSBL が起動する前に電力管理タスクを実行します。

引数• a53-0 (デフォルト)

• a53-1

• a53-2

• a53-3

• r5-0

• r5-1

• r5-lockstep

• pmu

例all:{ [bootloader,destination_cpu=a53-0]fsbl.elf [destination_cpu=r5-0] app.elf}

destination_device構文[destination_device <options>] <partition>

説明パーティションのターゲットを PS または PL のいずれに指定します。

引数• ps: パーティションのターゲットは PS。これがデフォルト値です。• pl: パーティションのターゲットはビットストリームの場合 PL。





例all:{ [bootloader,destination_cpu=a53-0]fsbl.elf [destination_device=pl]system.bit [destination_cpu=r5-1]app.elf}

early_handoff構文[early_handoff] <partition>

説明このフラグは、パーティションのロード直後に重要なアプリケーションへのハンドオフが確実に実行されるようにします。このオプションを使用しない場合は、最初にすべてのパーティションが順にロードされ、続いてハンドオフが順に実行されます。注記: 次のシナリオでは、FSBL は app1 をロードしてから app2 をロードし、その後すぐに app2 に制御を渡して app1に制御を渡します。例all:{ [bootloader, destination_cpu=a53_0]fsbl.el [destination_cpu=r5-0]app1.elf [destination_cpu=r5-1,early_handoff]app2.elf}

efuse_kek_iv構文efuse_kek_iv = <iv file path>

説明eFUSE キーの暗号化に使用する IV を指定します。efuse_kek_iv は、keysrc=efuse_blk_key の場合にのみ有効です。






efuse_user_kek0_iv構文efuse_user_kek0_iv = <iv file path>

説明eFuse ユーザーブラックキー key0 の暗号化に使用する IV を指定します。efuse_user_kek0_iv は、keysrc=efuse_user_blk_key0 の場合にのみ有効です。


efuse_user_kek1_iv構文efuse_user_kek1_iv = <iv file path>

説明eFuse ユーザーブラックキー key1 の暗号化に使用する IV を指定します。efuse_user_kek1_iv は、keysrc=efuse_user_blk_key1 の場合にのみ有効です。


encryption構文• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

[encryption = <options>] <partition>


{ encryption = <options>, file = <filename> }

説明パーティションを暗号化する必要があることを指定します。暗号化アルゴリズムは次のとおりです。





引数• none: パーティションは暗号化されない。これがデフォルト値です。• aes: パーティションは AES アルゴリズムを使用して暗号化される。例• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

all: { [aeskeyfile] test.nky [bootloader, encryption=aes] fsbl.elf [encryption=aes] hello.elf }


all:{ id_code = 0x04ca8093 extended_id_code = 0x01 id = 0x2

metaheader { encryption = aes, keysrc = bbram_red_key, aeskeyfile = efuse_red_metaheader_key.nky, }

image { name = pmc_subsys, id = 0x1c000001 partition { id = 0x01, type = bootloader, encryption = aes, keysrc = bbram_red_key, aeskeyfile = bbram_red_key.nky, file = executable.elf } partition { id = 0x09, type = pmcdata, load = 0xf2000000, aeskeyfile = pmcdata.nky, file = topology_xcvc1902.v1.cdo, file = pmc_data.cdo } }

image { name = lpd, id = 0x4210002 partition { id = 0x0C, type = cdo, encryption = aes, keysrc = bbram_red_key, aeskeyfile = key1.nky, file = lpd_data.cdo





} partition { id = 0x0B, core = psm, encryption = aes, keysrc = bbram_red_key, aeskeyfile = key2.nky, file = psm_fw.elf } }

image { name = fpd, id = 0x420c003 partition { id = 0x08, type = cdo, encryption = aes, keysrc = bbram_red_key, aeskeyfile = key5.nky, file = fpd_data.cdo } }}

exception_level構文• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

[exception_level=<options>] <partition>


{ exception_level=<options>, file=<partition> }

説明コアに設定する例外レベルを指定します。

引数• el-0

• el-1

• el-2

• el-3 (デフォルト)






all:{ [bootloader, destination_cpu=a53-0]fsbl.elf [destination_cpu=a53-0, exception_level=el-3] bl31.elf [destination_cpu=a53-0, exception_level=el-2] u-boot.elf}


new_bif:{ image { { type = bootimage, file = base.pdi } } image { name = apu_ss, id = 0x1c000000 { load = 0x1000, file = system.dtb } { exception_level = el-2, file = u-boot.elf } { core = a72-0, exception_level = el-3, trustzone, file = bl31.elf } }}


familykey構文[familykey] <key file path>

説明ファミリキーを指定します。ファミリキーを入手するには、ザイリンクスの代理店 ([email protected]) までお問い合わせください。

引数ファイルへのパス。

例all:{ [aeskeyfile] encr.nky [bh_key_iv] bh_iv.txt [familykey] familykey.cfg}





file構文{ file = <path/to/file> }

説明パーティションを作成するためのファイルを指定します。



fsbl_config構文[fsbl_config <options>] <partition>

説明このオプションは、ブートイメージのコンフィギュレーションに使用するパラメーターを指定します。FSBL は、ブートヘッダー認証モードで 64 ビットモードの A53 上で実行する必要があります。

引数• bh_auth_enable: ブートヘッダー認証イネーブル: ブートイメージの RSA 認証を実行します (PPK ハッシュおよび

SPK ID の検証を除く)。• auth_only: ブートイメージの RSA 署名のみを実行します。FSBL の復号化は実行しません。• opt_key: block-0 の復号化に操作キーを使用します。操作キーはセキュアヘッダーにあります。• pufhd_bh: PUF ヘルパーデータをブートヘッダーに格納します。デフォルトは efuse です。PUF ヘルパーデータファイルは、[puf_file] オプションを使用して Bootgen に渡されます。





• puf4kmode: PUF を 4k ビットコンフィギュレーションでの使用に合わせて調整します。デフォルトは 12k ビットです。shutter = <value>: PUF でシャッターオフセット時間およびシャッターオープン時間を設定する32 ビットの PUF_SHUT レジスタ値を指定します。注記: このシャッター値は、PUF 登録中に使用されたシャッター値と一致している必要があります。

例all:{ [fsbl_config] bh_auth_enable [pskfile] primary.pem [sskfile]secondary.pem [bootloader,destination_cpu=a53-0,authentication=rsa] fsbl.elf}

headersignature構文Zynq UltraScale+ MPSoC:

[headersignature] <signature file>

Versal:

headersignature = <signature file>

説明ヘッダーの署名を認証証明にインポートします。これは、秘密キーを共有しない場合に使用できます。署名を作成して Bootgen に供給できます。

引数<signature_file>

例Zynq UltraScale+ MPSoC:

all:{ [ppkfile] ppk.txt [spkfile] spk.txt [headersignature] headers.sha256.sig [spksignature] spk.txt.sha256.sig [bootloader, authentication=rsa] fsbl.elf}





Versal ACAP の場合:

stage5:{ bhsignature = bootheader.sha384.sig image { name = pmc_subsys, id = 0x1c000001 { type = bootimage, authentication=rsa, ppkfile = rsa-keys/PSK1.pub, spkfile = rsa-keys/SSK1.pub, spksignature = SSK1.pub.sha384.sig, file = pmc_subsys_e.bin } }}

hivec構文• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

[hivec] <partition>


{ hivec, file=<partition> }

説明例外ベクターテーブルの場所を hivec として指定します。これは、A53 (32 ビット) および R5 コアにのみ適用されます。• hivec: 0xFFFF0000 の例外ベクターテーブル。• lovec: 0x00000000 の例外ベクターテーブル。これがデフォルト値です。引数なし例• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

all: { [bootloader, destination_cpu=a53_0] fsbl.elf [destination_cpu=r5-0,hivec] app1.elf }






all: { image { name = image1, id = 0x1c000001 { type=bootloader, file=plm.elf } { type=pmcdata, file=pmc_cdo.bin } { type=cdo, file=fpd_data.cdo } { core=psm, file=psm.elf } { core=r5-0, hivec, file=hello.elf } } }

id構文id = <id>

説明定義した場所に基づいて次の ID を指定します。• pdi id: 最外/PDI かっこ内• image id: イメージかっこ内• partition id: パーティションかっこ内例new_bif:{ id_code = 0x04ca8093 extended_id_code = 0x01 id = 0x2 // PDI ID image { name = pmc_subsys, id = 0x1c000001 // Image ID partition { id = 0x01, // Partition ID type = bootloader, file = executable.elf } { id = 0x09, type = pmcdata, load = 0xf2000000,





file = topology_xcvc1902.v2.cdo, file = pmc_data.cdo } }}

image構文image {

}

説明サブシステム/イメージを定義します。

例test:{ image { name = pmc_subsys, id = 0x1c000001 { type = bootloader, file = plm.elf } { type=pmcdata, load=0xf2000000, file=pmc_cdo.bin} } image { name = PL_SS, id = 0x18700000 { id = 0x3, type = cdo, file = bitstream.rcdo } { id = 0x4, file = bitstream.rnpi } } }

init構文• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

[init] <filename>


init = <filename>





説明ブートローダーの最後にあるレジスタ初期化ブロックで、.int ファイル仕様を解析することにより構築されます。最大 256 個ののアドレスと値の初期化ペアを指定できます。.int ファイルには特定のフォーマットがあります。

例BIF ファイルのサンプルを次に示します。• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

all: { [init] test.int }


all: { init = reginit.int image { name = image1, id = 0x1c000001 { type=bootloader, file=plm.elf } { type=pmcdata, file=pmc_cdo.bin } } }

keysrc構文keysrc = <options>

説明暗号化に使用するキーソースを指定します。

引数ブートローダー、メタヘッダー、およびパーティションに有効なキーソースは、次のとおりです。• efuse_red_key

• efuse_blk_key

• bbram_red_key

• bbram_blk_key

• bh_blk_key

次はパーティションにのみ有効なキーソースです。





• user_key0

• user_key1

• user_key2

• user_key3

• user_key4

• user_key5

• user_key6

• user_key7

• efuse_user_key0

• efuse_user_blk_key0

例all: { image { name = pmc_subsys, id = 0x1c000001 { type = bootloader, encryption = aes, keysrc = bbram_red_key, aeskeyfile = key1.nky, file = plm.elf } { type = pmcdata, load = 0xf2000000, aeskeyfile = key2.nky, file = pmc_cdo.bin } } }

keysrc_encryption構文[keysrc_encryption] <options> <partition>

説明暗号化に使用するキーソースを指定します。

引数• bbram_red_key: BBRAM に格納されているレッドキー。• efuse_red_key: eFUSE に格納されているレッドキー。• efuse_gry_key: eFUSE に格納されているグレー (難読化) キー。• bh_gry_key: ブートヘッダーに格納されているグレー (難読化) キー。





• bh_blk_key: ブートヘッダーに格納されているブラックキー。• efuse_blk_key: eFUSE に格納されているブラックキー。• kup_key: ユーザーキー。例all:{ [keysrc_encryption]efuse_gry_key [bootloader,encryption=aes, aeskeyfile=encr.nky, destination_cpu=a53-0]fsbl.elf}

FSBL は、暗号化用に eFUSE に格納されている encr.nky キーを使用して暗号化されます。

load構文• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

[load = <value>] <partition>


{ load = <value> , file=<partition> }

説明メモリ内のパーティションのロードアドレスを設定します。


all: { [bootloader] fsbl.elf u-boot.elf [load=0x3000000, offset=0x500000] uImage.bin [load=0x2A00000, offset=0xa00000] devicetree.dtb [load=0x2000000, offset=0xc00000] uramdisk.image.gz }


new_bif:{ image { { type = bootimage, file = base.pdi } } image {





name = apu_ss, id = 0x1c000000 { load = 0x1000, file = system.dtb } { exception_level = el-2, file = u-boot.elf } { core = a72-0, exception_level = el-3, trustzone, file = bl31.elf } }}


metaheader構文metahdr { }

説明キー、キーソースなどのようなメタヘッダーの暗号化および認証属性を定義します。

例test:{ metaheader { encryption = aes, keysrc = bbram_red_key, aeskeyfile = headerkey.nky, authentication = rsa } image { name = pmc_subsys, id = 0x1c000001 { type = bootloader, encryption = aes, keysrc = bbram_red_key, aeskeyfile = key1.nky, blocks = 8192(*), file = plm.elf } { type=pmcdata, load=0xf2000000, aeskeyfile=key2.nky, file=pmc_cdo.bin } }}





name構文name = <name>

説明イメージ/サブシステムの名前を指定します。

例new_bif:{ id_code = 0x04ca8093 extended_id_code = 0x01 id = 0x2 image { name = pmc_subsys, id = 0x1c000001 { id = 0x01, type = bootloader, file = executable.elf } { id = 0x09, type = pmcdata, load = 0xf2000000, file = topology_xcvc1902.v2.cdo, file = pmc_data.cdo } } image { name = lpd, id = 0x4210002 { id = 0x0C, type = cdo, file = lpd_data.cdo } { id = 0x0B, core = psm, file = psm_fw.elf } } image { name = pl_cfi, id = 0x18700000 { id = 0x03, type = cdo, file = system.rcdo } { id = 0x05, type = cdo, file = system.rnpi } } image { name = fpd, id = 0x420c003 { id = 0x08, type = cdo, file = fpd_data.cdo } }}

offset構文• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

[offset = <value>] <filename>






{ offset = <value>, file=<filename> }

説明ブートイメージ内のパーティションの絶対オフセットを設定します。

引数指定された値およびパーティション。


all: { [bootloader] fsbl.elf u-boot.elf [load=0x3000000, offset=0x500000] uImage.bin [load=0x2A00000, offset=0xa00000] devicetree.dtb [load=0x2000000, offset=0xc00000] uramdisk.image.gz }


new_bif:{ image { { type = bootimage, file = base.pdi } } image { name = apu_ss, id = 0x1c000000 { offset = 0x8000, file = data.bin } }}


parent_id構文parent_id = <id>

説明親 PDI の ID を指定します。親 PDI とそれに該当するブート PDI 間の関係を識別するために使用します。





例new_bif:{ id = 0x22 parent_id = 0x2

image { name = apu_ss, id = 0x1c000000 { load = 0x1000, file = system.dtb } { exception_level = el-2, file = u-boot.elf } { core = a72-0, exception_level = el-3, trustzone, file = bl31.elf } }}

partition構文partition {

}

説明パーティションを定義します。BIF を短く読みやすくするためのオプションの属性です。

例new_bif:{ id_code = 0x04ca8093 extended_id_code = 0x01 id = 0x2 image { name = pmc_subsys, id = 0x1c000001 partition { id = 0x01, type = bootloader, file = executable.elf } partition { id = 0x09, type = pmcdata, load = 0xf2000000, file = topology_xcvc1902.v2.cdo, file = pmc_data.cdo } }}





注記: partition 属性はオプションであり、設定しなくても BIF ファイルは生成できます。上記の BIF を partition 属性を使用せずに記述すると、次のようになります。new_bif:{ id_code = 0x04ca8093 extended_id_code = 0x01 id = 0x2 image { name = pmc_subsys, id = 0x1c000001 { id = 0x01, type = bootloader, file = executable.elf } { id = 0x09, type = pmcdata, load = 0xf2000000, file = topology_xcvc1902.v2.cdo, file = pmc_data.cdo } }}

partition_owner、owner構文• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

[partition_owner = <options>] <filename>


{ owner = <options>, file=<filename> }

説明パーティションをロードするパーティションオーナー。

引数• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

○ fsbl: FSBL がこのパーティションを読み込みます。○ uboot: U-Boot がこのパーティションを読み込みます。


○ plm: PLM がこのパーティションを読み込みます。○ non-plm: PLM はこのパーティションを無視します。パーティションは別の方法で読み込まれます。






all: { [bootloader] fsbl.elf uboot.elf [partition_owner=uboot] hello.elf }


all: { image { { type = bootimage, file = base.pdi } } image { name = apu_subsys, id = 0x1c000003 { id = 0x00000000, core = a72-0, owner = non-plm, file = /path/to/image.ub } } }

partition_type構文[partition_type = <options>] <partition>

説明パーティションのフォーマットタイプ。

引数• cdo: パーティションはコンフィギュレーションデータオブジェクト形式。• raw: パーティションはバイナリ形式。• cfi: パーティションは Cframe (ビットストリーム形式)。





pid構文 [pid = <id_no>] <partition>

説明パーティション ID を指定します。デフォルト値は 0 です。

例all:{ [encryption=aes, aeskeyfile=test.nky, pid=1] hello.elf}

pmufw_image構文[pmufw_image] <PMU ELF file>

説明FSBL をロードする前に bootROM によってロードされる PMU ファームウェアイメージです。pmufw_image のオプションは、ブートローダーパーティションに含まれます。Bootgen では、pmufw_image オプションと共に指定される追加の属性は考慮されません。

引数ファイル名

例the_ROM_image:{ [pmufw_image] pmu_fw.elf [bootloader, destination_cpu=a53-0] fsbl_a53.elf [destination_cpu=a53-1] app_a53.elf [destination_cpu=r5-0] app_r5.elf}





ppkfile構文• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

[ppkfile] <key filename>


ppkfile = <filename>

説明プライマリ公開キー (PPK) は、ブートイメージ内のパーティションを認証するために使用されます。認証の使用を参照してください。

引数指定するファイルの名前。注記: 秘密キーファイルには、キーの公開キーコンポーネントが含まれます。秘密キー (PSK) が指定されている場合は、公開キー (PPK) を指定する必要はありません。例• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

all:{ [ppkfile] primarykey.pub [pskfile] primarykey.pem [sskfile] secondarykey.pem [bootloader, authentication=rsa]fsbl.elf [authentication=rsa] hello.elf}


all: { boot_config {bh_auth_enable} image { name = pmc_ss, id = 0x1c000001 { type=bootloader, authentication=rsa, file=plm.elf, ppkfile=primary0.pub, pskfile=primary0.pem, sskfile=secondary0.pem } { type = pmcdata, load = 0xf2000000, file=pmc_cdo.bin } { type=cdo, authentication=rsa, file=fpd_cdo.bin, ppkfile=primary1.pub, pskfile = primary1.pem, sskfile = secondary1.pem } } }





presign構文Zynq-7000 および Zynq UltraScale+ MPSoC デバイスの場合:

[presign = <signature_file>] <partition>


presign = <signature file>

説明パーティション署名をパーティション認証証明にインポートします。これは、秘密キー (SSK) を共有しない場合に使用します。署名を作成して Bootgen に供給できます。• <signature_file>: 署名ファイルを指定します。• <partition>: 署名ファイルを適用するパーティションをリストします。

例Zynq-7000 および Zynq UltraScale+ MPSoC デバイスの場合:

all:{ [ppkfile] ppk.txt [spkfile] spk.txt [headsignature] headers.sha256.sig [spksignature] spk.txt.sha256.sig [bootloader, authentication=rsa, presign=fsbl.sig]fsbl.elf}

pskfile構文• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

[pskfile] <key filename>


pskfile = <filename>

説明このプライマリ秘密キー (PSK) は、ブートイメージ内のパーティションを認証するために使用されます。詳細は、認証の使用を参照してください。





引数指定するファイルの名前。注記: 秘密キーファイルには、キーの公開キーコンポーネントが含まれます。秘密キー (PSK) が指定されている場合は、公開キー (PPK) を指定する必要はありません。例• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

all:{ [pskfile] primarykey.pem [sskfile] secondarykey.pem [bootloader, authentication=rsa]fsbl.elf [authentication=rsa] hello.elf}


all: { boot_config {bh_auth_enable} image { name = pmc_ss, id = 0x1c000001 { type=bootloader, authentication=rsa, file=plm.elf, pskfile=primary0.pem, sskfile=secondary0.pem } { type = pmcdata, load = 0xf2000000, file=pmc_cdo.bin } { type=cdo, authentication=rsa, file=fpd_cdo.bin, pskfile = primary1.pem, sskfile = secondary1.pem } } }

puf_file構文• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

[puf_file] <puf data file>


puf_file = <puf data file>

説明PUF ヘルパーデータファイル。• PUF は、暗号化キーソースとしてブラックキーと共に使用されます。• PUF ヘルパーデータは 1544 バイトです。• 1536 バイトの PUF HD + 4 バイトの CHASH + 3 バイトの AUX + 1 バイトアライメント。





詳細は、ブラックキー/PUF キーを参照してください。


all: { [fsbl_config] pufhd_bh [puf_file] pufhelperdata.txt [bh_keyfile] black_key.txt [bh_key_iv] bhkeyiv.txt [bootloader,destination_cpu=a53-0,encryption=aes]fsbl.elf}


all: { boot_config {puf4kmode} puf_file = pufhd_file_4K.txt bh_kek_iv = bh_black_key-iv.txt image { name = pmc_subsys, id = 0x1c000001 { type = bootloader, encryption = aes, keysrc = bh_black_key, aeskeyfile = key1.nky, file = plm.elf } { type = pmcdata, load = 0xf2000000, aeskeyfile = key2.nky, file = pmc_cdo.bin } { type=cdo, encryption = aes, keysrc = efuse_red_key, aeskeyfile = key3.nky, file=fpd_data.cdo } } }

reserve構文• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

[reserve = <value>] <filename>


{ reserve = <value>, file=<filename> }





説明パーティションのメモリサイズを維持します。このサイズになるまでパーティションにパディングが追加されます。維持するメモリサイズは、バイト数で指定します。



all: { [bootloader] fsbl.elf [reserve=0x1000] test.bin }


new_bif:{ image { { type = bootimage, file = base.pdi } } image { name = apu_ss, id = 0x1c000000 { reserve = 0x1000, file = data.bin } }}


s_hwrot構文boot_config { s_hwrot }

説明非対称ハードウェアの信頼のルート (S-HWRoT) ブートモード。Bootgen で S-HWRoT ブートモードのデザインルールがチェックされます。プロダクション PDI でのみ有効です。





split構文[split] mode = <mode-options>, fmt=<format>

説明モードに基づいてイメージを分割します。スレーブブート (slaveboot) モードでは次のように分割されます。• ブートヘッダー + ブートローダー• イメージヘッダーおよびパーティションヘッダー• 残りのパーティション通常 (normal) モードでは次のように分割されます。• ブートヘッダー + イメージヘッダー + パーティションヘッダー + ブートローダー• Partition1

• パーティション 2、以下同様スレーブブートモードは Zynq UltraScale+ MPSoC でのみサポートされ、通常モードは Zynq-7000 および ZynqUltraScale+ MPSoC の両方でサポートされます。分割 (split) モードでは、出力フォーマットも bin または mcs に設定できます。

オプション引数で使用可能なオプションは次のとおりです。• slaveboot

• normal

• bin

• mcs

例all:{ [split]mode=slaveboot,fmt=bin [bootloader,destination_cpu=a53-0]fsbl.elf [destination_device=pl]system.bit [destination_cpu=r5-1]app.elf}

注記: オプションの split の normal モードは、コマンドラインオプションの split と同じです。このコマンドラインオプションは廃止予定です。注記: split slaveboot モードでは Versal ACAP ではサポートされていません。





spkfile構文• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

[spkfile] <key filename>


spkfile = <filename>

説明セカンダリ公開キー (SPK) は、ブートイメージ内のパーティションを認証するために使用されます。詳細は、認証の使用を参照してください。



all:{ [pskfile] primarykey.pem [spkfile] secondarykey.pub [sskfile] secondarykey.pem [bootloader, authentication=rsa]fsbl.elf [authentication=rsa] hello.elf}


all: { boot_config {bh_auth_enable} pskfile=primary0.pem, image { name = pmc_ss, id = 0x1c000001 { type=bootloader, authentication=rsa, file=plm.elf, spkfile=secondary0.pub, sskfile=secondary0.pem } { type = pmcdata, load = 0xf2000000, file=pmc_cdo.bin } { type=cdo, authentication=rsa, file=fpd_cdo.bin} spkfile=secondary1.pub, sskfile = secondary1.pem } } }

注記: 秘密キーファイルには、キーの公開キーコンポーネントが含まれます。秘密キー (SSK) が指定されている場合は、公開キー (SPK) を指定する必要はありません。





spksignature構文Zynq および Zynq UltraScale+ MPSoC デバイスの場合:

[spksignature] <Signature file>


spksignature = <signature file>

説明SPK 署名を認証証明にインポートします。これは、秘密キー PSK を共有しない場合に使用できます。署名を作成してBootgen に供給できます。


例Zynq および Zynq UltraScale+ MPSoC デバイスの場合:

all:{ [ppkfile] ppk.txt [spkfile] spk.txt [headersignature]headers.sha256.sig [spksignature] spk.txt.sha256.sig [bootloader, authentication=rsa] fsbl.elf}


stage7c:{ image { id = 0x1c000000, name = fpd { type = bootimage, authentication=rsa, ppkfile = PSK3.pub, spkfile = SSK3.pub, spksignature = SSK3.pub.sha384.sig, presign = fpd_data.cdo.0.sha384.sig, file = fpd_e.bin } }}





spk_select構文[spk_select = <options>]

または

[auth_params] spk_select = <options>

説明オプションは次のとおりです。• spk-efuse: パーティションに spk_id eFUSE が使用されていることを示します。これがデフォルト値です。• user-efuse: パーティションにユーザー eFUSE が使用されていることを示します。CSU ROM によってロードされるパーティションは、常に spk_efuse を使用します。注記: spk_id eFUSE は、どのキーが有効であるかを指定します。したがって、ROM は spk_id eFUSE のフィールド全体を SPK ID と照合してビットが一致することを確認します。ユーザー eFUSE は、どのキー ID が有効でない (取り消された) かを指定します。したがって、ファームウェア (ROM以外) は、SPK ID を表すそのユーザー eFUSE がプログラムされているかどうかをチェックします。spk_select =user-efuse の場合、そのパーティションにユーザー eFUSE が使用されることを意味します。例the_ROM_image:{ [auth_params]ppk_select = 0 [pskfile]psk.pem [sskfile]ssk1.pem

[ bootloader, authentication = rsa, spk_select = spk-efuse, spk_id = 0x5, sskfile = ssk2.pem ] zynqmp_fsbl.elf

[ destination_cpu =a53-0, authentication = rsa, spk_select = user-efuse, spk_id = 0xF, sskfile = ssk3.pem ] application1.elf

[ destination_cpu =a53-0, authentication = rsa,





spk_select = spk-efuse, spk_id =0x5, sskfile = ssk4.pem ] application2.elf}

sskfile構文• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

[sskfile] <key filename>


sskfile = <filename>

説明セカンダリ秘密キー (SSK) は、ブートイメージ内のパーティションを認証するために使用されます。詳細は、認証の使用を参照してください。



all:{ [pskfile] primarykey.pem [sskfile] secondarykey.pem [bootloader, authentication=rsa]fsbl.elf [authentication=rsa] hello.elf}


all: { boot_config {bh_auth_enable} image { name = pmc_ss, id = 0x1c000001 { type=bootloader, authentication=rsa, file=plm.elf, pskfile=primary0.pem, sskfile=secondary0.pem } { type = pmcdata, load = 0xf2000000, file=pmc_cdo.bin } { type=cdo, authentication=rsa, file=fpd_cdo.bin, pskfile = primary1.pem, sskfile = secondary1.pem } } }





注記: 秘密キーファイルには、キーの公開キーコンポーネントが含まれます。秘密キー (PSK) が指定されている場合は、公開キー (PPK) を指定する必要はありません。

startup構文• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

[startup = <value>] <filename>


{ startup = <value>, file = <filename> }

説明このオプションは、ロード後のパーティションのエントリアドレスを設定します。この識別子は、実行しないパーティションでは無視されます。これは、バイナリパーティションにのみ使用できます。


all: { [bootloader] fsbl.elf [startup=0x1000000] app.bin }


new_bif:{ image { { type = bootimage, file = base.pdi } } image { name = apu_ss, id = 0x1c000000 { core=a72-0, load=0x1000, startup = 0x1000, file = apu.bin } }}






TrustZone構文• Zynq デバイスおよび Zynq UltraScale+ MPSoC の場合:

[trustzone = <options> ] <filename>


{ trustzone = <options>, file = <filename> }

説明コアを TrustZone セキュアまたは非セキュアに設定します。オプションは次のとおりです。• secure

• nonsecure (デフォルト)


all: { [bootloader, destination_cpu=a53-0] fsbl.elf [exception_level=el-3, trustzone = secure] bl31.elf }


new_bif:{ image { { type = bootimage, file = base.pdi } } image { name = apu_ss, id = 0x1c000000 { load = 0x1000, file = system.dtb } { exception_level = el-2, file = u-boot.elf } { core = a72-0, exception_level = el-3, trustzone, file = bl31.elf } }}






type構文{ type = <options> }

説明パーティションのタイプを指定します。オプションは次のとおりです。• bootloader

• pmcdata

• cdo

• cfi

• cfi-gsc

• bootimage



udf_bh構文[udf_bh] <filename>

説明ブートヘッダーのユーザー定義フィールドにコピーされるデータのファイルをインポートします。入力されたユーザー定義データは、16 進数文字列フォーマットのテキストファイルで提供されます。ザイリンクス SoC におけるUDF の総バイト数は次のとおりです。• zynq: 76 バイト





• zynqmp: 40 バイト引数指定するファイルの名前。

例all:{ [udf_bh]test.txt [bootloader]fsbl.elf hello.elf}

次に、udf_bh の入力ファイルの例を示します。udf_bh - test.txt のサンプル入力ファイル 123456789abcdef85072696e636530300301440408706d616c6c6164000508 266431530102030405060708090a0b0c0d0e0f101112131415161718191a1b 1c1d1

udf_data構文[udf_data=<filename>] <partition>

説明最大 56 バイトのデータを含むファイルを認証証明のユーザー定義フィールド (UDF) にインポートします。認証証明の詳細は、認証を参照してください。


例all:{ [pskfile] primary0.pem [sskfile]secondary0.pem [bootloader, destination_cpu=a53-0, authentication=rsa,udf_data=udf.txt]fsbl.elf [destination_cpu=a53-0,authentication=rsa] hello.elf}





xip_mode構文[xip_mode] <partition>

説明FSBL が QSPI フラッシュから直接実行されるよう XIP (eXecute-In-Place) を示します。注記: この属性は、FSBL/ブートローダーパーティションにのみ適用されます。引数指定されたパーティション。

例次の例は、Zynq® UltraScale+™ MPSoC デバイスの代わりに実行するブートイメージをを作成する方法を示しています。all:{ [bootloader, xip_mode] fsbl.elf application.elf}





第 9 章

コマンドリファレンスarch

構文-arch [options]

説明ブートイメージを作成する必要のあるザイリンクスファミリアーキテクチャ。

引数• zynq: Zynq®-7000 デバイスアーキテクチャ。これがブートイメージを作成する必要のあるファミリアーキテクチャのデフォルト値です。

• zynqmp: Zynq® UltraScale+™ MPSoC デバイスアーキテクチャ。• fpga: イメージはほかの FPGA アーキテクチャをターゲットとしています。• versal: このイメージは Versal™ デバイスをターゲットにしています。戻り値なし

例bootgen -arch zynq -image test.bif -o boot.bin

authenticatedjtag構文-authenticatedjtag [options] [filename]

説明セキュアブート中に JTAG をイネーブルにします。

第 9 章: コマンドリファレンス




引数• rsa

• ecdsa

例bootgen -arch versal -image boot.bif -w -o boot.bin -authenticatedjtag rsa authJtag-rsa.bin

bif_help構文bootgen -bif_help

bootgen -bif_help aeskeyfile

説明サポートされている BIF ファイルの属性をリストします。各 BIF 属性の詳細は、コマンドラインで -bif_help の引数として属性名を指定すると説明が得られます。

dual_ospi_mode構文bootgen -arch versal -dual_ospi_mode stacked <size>

説明デュアル OSPI スタックドコンフィギュレーションに対して 2 つの出力ファイルを生成します。フラッシュのサイズを MB で指定する必要があります (64、128、または 256)。

例次の例は、OSPI デュアルパラレルコンフィギュレーションの 2 つのフラッシュを個別にプログラムするため、2 つの出力ファイルを生成します。実際のイメージの最初の 64 MB が 1 つ目のファイルに書き込まれ、残りは 2 つ目のファイルに書き込まれます。実際のイメージが 64 MB 未満の場合は、1 つのファイルのみ生成されます。これはVersal ACAP でのみサポートされます。bootgen -arch versal -image test.bif -o -boot.bin -dual_ospi_mode stacked 64





引数• stacked、<size>

dual_qspi_mode構文bootgen -dual_qspi_mode [parallel]|[stacked <size>]

説明Dual QSPI コンフィギュレーションの場合は 2 つの出力ファイルを生成します。スタックドコンフィギュレーションの場合は、フラッシュのサイズ (MB) を指定する必要があります (16、32、128、または 256)。

例次の例は、QSPI デュアルパラレルコンフィギュレーションの 2 つのフラッシュを個別にプログラムするため、2 つの出力ファイルを生成します。bootgen -image test.bif -o -boot.bin -dual_qspi_mode parallel

次の例は、QSPI デュアルパラレルコンフィギュレーションの 2 つのフラッシュを個別にプログラムするため、2 つの出力ファイルを生成します。実際のイメージの最初の 64 MB が 1 つ目のファイルに書き込まれ、残りは 2 つ目のファイルに書き込まれます。実際のイメージが 64 MB 未満の場合は、1 つのファイルのみ生成されます。bootgen -image test.bif -o -boot.bin -dual_qspi_mode stacked 64

引数• parallel

• stacked <size>

dump構文-dump [options]

説明ブートヘッダーの内容を PDI 生成中に別のバイナリファイルへダンプします。





例[bootgen -image test.bif -o -boot.bin -log trace -dump bh]

引数• empty: パーティションをバイナリファイルとしてダンプします。• bh: ブートヘッダーを別のファイルとしてダンプします。注記: ブートヘッダーは、PDI と一緒に別のバイナリファイルとしてダンプされます。生成される PDI はブートヘッダーから取り出されませんが、ブートヘッダーを含みます。

dump_dir構文dump_dir <path>

説明-dump コマンドの内容を書き込みディレクトリを指定します。

例bootgen -arch versal -dump boot.bin -dump_dir <path>

efuseppkbits構文

bootgen -image test.bif -o boot.bin -efuseppkbits efusefile.txt

引数efusefile.txt

説明このオプションは、PPK ハッシュを書き込む eFUSE ファイルの名前を指定します。また、パディングなしでダイレクトハッシュを生成します。PPK キーのハッシュを含む efusefile.txt ファイルが生成されます。• Zynq®-7000 では、ハッシュ処理に SHA2 プロトコルが使用されます。• Zynq® UltraScale+™ MPSoC および Versal ACAP では、ハッシュ処理に SHA3 が使用されます。





encrypt構文bootgen -image test.bif -o boot.bin -encrypt <efuse|bbram|>

説明このオプションは、暗号化の実行方法とキーの格納場所を指定します。NKY キーファイルは、BIF ファイルのaeskeyfile 属性で渡されます。コマンドラインで指定されるのはキーソースのみです。

引数キーソースの引数は次のとおりです。• efuse: AES キーは eFUSE に格納されます。これがデフォルト値です。• bbram: AES キーは BBRAM に格納されます。

encryption_dump構文bootgen -arch zynqmp -image test.bif -encryption_dump

説明暗号ログファイル aes_log.txt を生成します。生成される aes_log.txt には、データの各ブロックの暗号化に使用される AES キー/IV ペアの詳細が含まれます。また、パーティションとそれを暗号化するために使用した AES キーファイルもログに記録されます。注記: このオプションは、Zynq® UltraScale+™ MPSoC でのみサポートされます。例all:{ [bootloader, encryption=aes, aeskeyfile=test.nky] fsbl.elf [encryption=aes, aeskeyfile=test1.nky] hello.elf}





fill構文bootgen -arch zynq -image test.bif -fill 0xAB -o boot.bin

説明このオプションは、パディング/予約されているメモリを <hex byte> フォーマットで埋めるために使用するバイトを指定します。

出力0xAB バイトの boot.bin ファイル。

例出力イメージは boot.bin という名前で生成されます。出力イメージのフォーマットは、-o オプションで指定するファイル拡張子に基づいて決まります。この例では、-fill: でパディングするバイトを指定します。0xFF ではなく <hex byte> がヘッダーテーブルにパディングされます。bootgen -arch zynq -image test.bif -fill 0xAB -o boot.bin

generate_hashes構文bootgen -image test.bif -generate_hashes

説明このオプションは、すべてのパーティションおよびその他のコンポーネントがブートヘッダー、イメージ、およびパーティションヘッダーと同様に署名されるようハッシュファイルを生成します。また、Zynq®-7000 フォーマット用に PKCS＃1v1.5 のパディングされたハッシュを含むファイルを生成します。表 37: Zynq: SHA-2 (256 バイト)

値 SHA-2 ハッシュ* T-パディング 0x0 0xFF 0x01 0x00

バイト数 32 19 1 202 1 1

このオプションは、Zynq® UltraScale+™ MPSoC フォーマット用に PKCS＃1v1.5 のパディングされたハッシュを含むファイルを生成します。





表 38: ZynqMP: SHA-3 (384 バイト)

値 0x0 0x1 0xFF 0xFF T-パディング SHA-3 ハッシュバイト数 1 1 314 1 19 48

例test:{ [pskfile] ppk.txt [sskfile] spk.txt [bootloader, authentication=rsa] fsbl.elf [authentication=rsa] hello.elf }

Bootgen は、指定された BIF で次のハッシュファイルを生成します。• ブートヘッダーハッシュ• spk ハッシュ• ヘッダーテーブルハッシュ• fsbl.elf パーティションハッシュ• hello.elf パーティションハッシュ

generate_keys構文bootgen -image test.bif -generate_keys <rsa|pem|obfuscated>

説明このオプションは、認証用のキーと暗号化に使用される難読化キーを生成します。注記: 暗号化キーの生成の詳細は、キーの生成を参照してください。認証キー生成の例認証キー生成の例。この例では、BIF ファイルで指定したパスに認証キーを生成します。

例image:{ [ppkfile] <path/ppkgenfile.txt> [pskfile] <path/pskgenfile.txt> [spkfile] <path/spkgenfile.txt> [sskfile] <path/sskgenfile.txt>}





難読化キー生成の例この例では、familykey.txt と同じパスで難読化されたものを生成します。

コマンドbootgen -image test.bif -generata_keys rsa

BIF ファイルの例を次に示します。image:{ [aeskeyfile] aes.nky [bh_key_iv] bhkeyiv.txt [familykey] familykey.txt}

引数• rsa

• pem

• obfuscated

h、help構文bootgen -helpbootgen -help arch

説明サポートされるコマンドライン属性をリストします。各属性の詳細は、コマンドラインで -help の引数として属性名を指定すると表示されます。

image構文-image <BIF_filename>





説明このオプションは、入力する BIF ファイル名を指定します。BIF ファイルは、ブートイメージの各コンポーネントをブート順に指定し、オプションで各イメージコンポーネントに属性を指定できるようにします。各イメージコンポーネントは、通常 1 つのパーティションにマップされますが、1 つのイメージコンポーネントがメモリ内で連続する場合は、1 つのイメージコンポーネントが複数パーティションにマップされます。

引数bif_filename

例bootgen -arch zynq -image test.bif -o boot.bin

BIF ファイルの例を次に示します。the_ROM_image: { [init] init_data.int [bootloader] fsbl.elf Partition1.bit Partition2.elf }

log構文bootgen -image test.bif -o -boot.bin -log trace

説明ブートイメージの作成中にログを生成します。情報のレベルに応じてさまざまなオプションがあります。情報はコンソールに表示され、bootgen_log.txt という名前のログファイルが作業ディレクトリに生成されます。

引数• error: エラー情報のみ記録されます。• warning: 警告およびエラー情報が記録されます。これがデフォルト値です。• info: 一般的な情報および上記すべての情報が記録されます。• trace: より詳細な情報が上記の情報と共に記録されます。





nonbooting構文bootgen -arch zynq -image test.bif -o test.bin -nonbooting

説明このオプションは、中間のブートイメージを作成するために使用されます。中間の test.bin イメージは、認証イメージの生成に必要な秘密キーがなくても出力として生成されます。この中間イメージはブートできません。

例all: { [ppkfile]primary.pub [spkfile]secondary.pub [spksignature]secondary.pub.sha256.sig [bootimage,authentication=rsa,presign=fsbl_0.elf.0.sha256.sig]fsbl_e.bin }

o構文bootgen -arch zynq -image test.bif -o boot.<bin|mcs>

説明このオプションは、出力イメージファイルの名前 (拡張子) を .bin または .mcs で指定します。

出力BIN または MCS フォーマットのフルブートイメージファイル。

例bootgen -arch zynq -image test.bif -o boot.mcs

ブートイメージは MCS フォーマットで出力されます。





p構文bootgen -image test.bif -o boot.bin -p xc7z020clg48 -encrypt efuse

説明このオプションは、ザイリンクスデバイスのパーツ名を指定します。これは、暗号化キーを生成するために必要です。NKY ファイルの Device 行の *.nky ファイルにそのままコピーされます。これは、暗号化が有効な場合にのみ適用されます。BIF ファイルで指定されたパスにキーファイルが存在しない場合、同じパスに新しい暗号化キーが生成され、nky ファイルの Device フィールドの横に xc7z020clg484 がコピーされます。生成されたイメージは暗号化されたイメージです。

padimageheader構文bootgen -image test.bif -w on -o boot.bin -padimageheader <0|1>

説明このオプションは、イメージヘッダーテーブルとパーティションヘッダーテーブルを可能な限り数多くのパーティションにパディングし、続くパーティションを強制的に揃えます。この機能はデフォルトで有効になっています。0を指定すると、無効になります。実際の boot.bin にはイメージヘッダーテーブルとパーティションヘッダーテーブルがあり、余分なテーブルはパディングされていません。何も指定されていない場合、または -padimageheader=1 の場合、イメージヘッダーテーブルおよびパーティションヘッダーテーブルの合計が最大数のパーティションにパディングされます。

引数• 1: ヘッダーテーブルを最大数のパーティションにパディングする。これがデフォルト値です。• 0: ヘッダーテーブルをパディングしない。イメージヘッダーまたはパーティションヘッダーの長さ• Zynq デバイスの場合、最大パーティションは 14 です。• Zynq UltraScale+ MPSoC の場合、最大パーティションは 32 です。





process_bitstream構文-process_bitstream <bin|mcs>

説明BIF からのビットストリームのみを処理し、MCS ファイルまたは BIN ファイルとして出力します。たとえば、BIF ファイルのビットストリームに暗号化を選択した場合、出力は暗号化されたビットストリームとなります。

引数• bin: BIN フォーマットでの出力。• mcs: MCS フォーマットでの出力。戻り値生成される出力は、BIN フォーマットまたは MCS フォーマットのビットストリームで、ヘッダーが添付されていない処理済みファイルです。

read構文-read [options] <filename>

説明オプションに基づいて、ブートヘッダー、イメージヘッダー、およびパーティションヘッダーを読み出すのに使用されます。

引数• bh: bootimage からブートヘッダーを人間が読める形式で読み出します。• iht: bootimage からイメージヘッダーテーブルを読み出します。• ih: bootimage からイメージヘッダーを読み出します。• pht: bootimage からパーティションヘッダーを読み出します。• ac: bootimage から認証証明を読み出します。コード例bootgen -arch zynqmp -read BOOT.bin





spksignature構文bootgen -image test.bif -w on -o boot.bin -spksignature spksignfile.txt

説明このオプションは、SPK 署名ファイルの生成に使用します。これは、spkfile および pskfile が BIF で指定されている場合にのみ使用する必要があります。SPK 署名ファイル (spksignfile.txt) が生成されます。

オプション生成する署名ファイルの名前を指定します。

split構文bootgen -arch zynq -image test.bif -split bin

説明このオプションは、ヘッダーを含む各データパーティションを MCS または BIN フォーマットの新しいファイルとして出力します。

出力出力ファイルは次のとおりです。• ブートヘッダー + イメージヘッダー + パーティションヘッダー + Fsbl.elf

• Partition1.bit

• Partition2.elf

例the_ROM_image: { [bootloader] Fsbl.elf Partition1.bit Partition2.elf }





verify構文bootgen -arch zynqmp -verify boot.bin

説明このオプションは、ブートイメージの認証を検証するために使用します。ブートイメージ内の認証証明がすべて使用可能なパーティションに対して検証されます。検証は、次の手順で実行されます。1. ヘッダー認証証明の検証、SPK 署名の検証、およびヘッダー署名の検証。2. ヘッダーブートローダー認証証明の検証、ブートヘッダー署名の検証、SPK 署名の検証、およびブートローダー署名の検証。

3. パーティション認証証明の検証、SPK 署名の検証、およびパーティション署名の検証。これは、該当するブートイメージのすべてのパーティションで繰り返されます。

verify_kdf構文bootgen -arch zynqmp -verify_kdf testVec.txt

説明testVec.txt ファイルのフォーマットは、次のとおりです。L = 256KI = d54b6fd94f7cf98fd955517f937e9927f9536caebe148fba1818c1ba46bba3a4FixedInputDataByteLen = 60FixedInputData = 94c4a0c69526196c1377cebf0a2ae0fb4b57797c61bea8eeb0518ca08652d14a5e1bd1b116b1794ac8a476acbdbbcd4f6142d7b8515bad09ec72f7af

Bootgen は、カウンターの Mode KDF を使用して、テストベクターファイルの入力データに基づいて出力キー (KO)を生成します。この KO は、ユーザーが比較できるようにコンソールに表示されます。





w構文bootgen -image test.bif -w on -o boot.binor bootgen -image test.bif -w -o boot.bin

説明このオプションは、既存のファイルを上書きするかどうかを指定します。boot.bin ファイルが既にパスに存在する場合は上書きされます。-w on オプションと -w オプションは同じように扱われます。-w オプションが指定されていない場合、ファイルはデフォルトで上書きされません。

引数• on: 引数ありの -w on コマンドまたは引数なしの -w で指定します。これがデフォルト値です。• off: 既存ファイルを上書きしないよう指定します。

zynqmpes1構文bootgen -arch zynqmp -image test.bif -o boot.bin -zynqmpes1

説明生成されたイメージを ES1 (1.0) で使用することを指定します。このオプションは、認証イメージを生成する場合にのみ影響をおよぼします。それ以外は無視されます。デフォルトのパディング方式は、ES2 (2.0) 以降が対象です。





第 10 章

初期化ペアおよび INIT ファイルの属性初期化ペアを使用すると、MIO マルチプレクサーのプロセッサシステム (PS) レジスタとフラッシュデバイスのクロックの初期化が容易になります。これにより、FSBL イメージを OCM にコピーする前、または XIP (eXecute in place)でフラッシュから実行する前に MIO マルチプレクサーを完全にコンフィギュレーションでき、フラッシュデバイスのクロックを帯域幅が最大となるように設定できます。ブートイメージヘッダーの固定部分の最後に 256 の初期化ペアがあります。1 つのペアは 32 ビットのアドレス値と 32 ビットのデータ値で構成されるため、初期化ペアはこれに従って指定されます。初期化が実行されない場合、アドレス値はすべて 0xFFFFFFFF となり、データ値はすべて 0x00000000 となります。これらの初期化ペアは、デフォルトでファイル拡張子が .int のテキストファイルで設定されますが、拡張子は変更できます。このファイルは、ファイル名の前に [init] ファイル属性を使用することによって、BIF 内で INIT ファイルとして認識されます。データフォーマットでは、動作指示子の後に次の情報が続きます。• アドレス値• = 文字• データ値行末はセミコロン (;) で示します。次に、.set. operation directive; の例を示します。.set. 0xE0000018 = 0x00000411; // This is the 9600 uart setting.

Bootgen は、INT ファイルからブートヘッダー初期化データを最大で 256 ペアまで挿入します。bootROM が実行されると、bootROM はアドレス値を参照し、その値が 0xFFFFFFFF でない場合は、アドレス値に続く次の 32 ビット値を使用してアドレスの値を書き込みます。bootROM は、アドレス値が 0xFFFFFFFF になるまで、または 256 番目の初期化ペアに到達するまで、初期化ペアを順に設定します。Bootgen では、次に示す演算子を含む式の評価 (優先を強制するネストされたかっこを含む) を実行できます。* = multiply/ = divide% = modan address valueulo divide+ = addition- = subtraction~ = negation>> = shift right<< = shift left& = binary and = binary or^ = binary nor

値は 16 進数 (0x)、8 進数 (0o)、または 10 進数で指定できます。数表現は、128 ビットの固定小数点整数として保持されます。読みやすいように、表現演算子の前後にスペースを入れることができます。

第 10 章: 初期化ペアおよび INIT ファイルの属性




第 11 章

CDO ユーティリティCDO ユーティリティ (cdoutil) は CDO ファイルをさまざまな方法で処理可能なプログラムです。CDO ファイルは、クロック、PLL、MIO のユーザーコンフィギュレーションに基づいて Versal™ デバイス用に Vivado® Design Suite で作成されたバイナリファイルです。CDO は PDI の一部で、PLM でロード/実行されます。Zynq® デバイスおよびZynq® UltraScale+™ MPSoC の場合、コンフィギュレーションは ps7/psu_init.c/h ファイルの一部で、FSBL と共にコンパイルされます。

アクセスcdoutil は、Vivado Design Suite/Vitis™ 統合ソフトウェアプラットフォーム/Bootgen をインストールすると<INSTALL_DIR>/bin/cdoutil に含まれます。

使用法cdoutil の一般的なコマンドライン構文は、次のとおりです。cdoutil <options> <input(s)>

cdoutil は、デフォルトで入力ファイルをデコードして、CDO を表示します。

コマンドラインオプションデフォルト動作を変更するオプションは複数あります。表 39: コマンドラインオプション

オプション説明-address-filter-file <path> アドレスフィルタータイプを指定します。-annotate コマンドの詳細を含めてソース出力をアノテートします。-device <type> デバイス名を指定します。デフォルトは s80 です。-help ヘルプ情報を表示します。-output-binary-be ビッグエンディアンのバイナリ形式で CDO コマンドを出力します。-output-binary-le リトルエンディアンのバイナリ形式で CDO コマンドを出力します。-output-file <path> 出力ファイルを指定します。デフォルトは stdout です。

第 11 章: CDO ユーティリティ




表 39: コマンドラインオプション (続き)

オプション説明-output-modules 入力ファイルで使用されるモジュールのリストを出力します。-output-raw-be ビッグエンディアンの RAW 形式で CDO コマンドを出力します。-output-raw-le リトルエンディアンの RAW 形式で CDO コマンドを出力します。-output-source ソース形式 (デフォルト) 形式で CDO コマンドを出力します。-remove-comments 入力からコメントを削除します。-rewrite-block 複数の書き込みコマンドにブロック書き込みコマンドを書き直します。-rewrite-sequential 1 つのブロック書き込みコマンドに順次書き込みコマンドを書き直します。-verbose ログ情報を表示します。

注記: Vivado Design Suite はビッグエンディアンの RAW 形式で CDO コマンドを生成するので、-output-raw-beをお勧めします。-output-raw-le、-output-binary-be、-output-binary-le はお勧めしません。

アドレスフィルターファイルアドレスフィルターファイルは、-address-filter-file <path> で指定します。このファイルは、コンフィギュレーションから削除する必要のあるモジュールを指定するために使用します。アドレスフィルターファイルは、各行がダッシュ (-) で始まるテキストファイルで、すべての初期化を削除するアドレス範囲が指定されます。例:

# Remove configuration of UART0-UART0

デザインで使用されるモジュールのリストは、-output-modules オプションを使用して生成できます。これは、アドレスフィルターファイルの開始点として使用すると便利です。

例アノテーションなしのバイナリからソースへの変換cdoutil -output-file test.txt test.bin

出力例:

version 2.0write 0xfca50000 0write 0xfca50010 0write 0xfca50018 0x1write 0xfca5001c 0write 0xfca50020 0write 0xfca50024 0xffffffff





アノテーションありのバイナリからソースへの変換cdoutil -annotate -output-file test.txt test.bin

出力例:

version 2.0# PCIEA_ATTRIB_0.MISC_CTRL.slverr_enable[0]=0x0write 0xfca50000 0# PCIEA_ATTRIB_0.ISR.{dpll_lock_timeout_err[1]=0x0, addr_decode_err[0]=0x0}write 0xfca50010 0# PCIEA_ATTRIB_0.IER.{dpll_lock_timeout_err[1]=0x0, addr_decode_err[0]=0x1}write 0xfca50018 0x1# PCIEA_ATTRIB_0.IDR.{dpll_lock_timeout_err[1]=0x0, addr_decode_err[0]=0x0}write 0xfca5001c 0# PCIEA_ATTRIB_0.ECO_0.eco_0[31:0]=0x0write 0xfca50020 0# PCIEA_ATTRIB_0.ECO_1.eco_1[31:0]=0xffffffffwrite 0xfca50024 0xffffffff

バイナリ CDO ファイルの編集cdoutil -annotate -output-file test.txt test.binvim text.txtcdoutil -output-binary-be -output-file test-new.bin test.txt

.bif ファイルが test.bin ではなく test-new.bin を使用していることを確認したら、Bootgen を再実行して .pdiファイルを作成します。

ソースのバイナリへの変換cdoutil -output-binary-be -output-file test.bin test.txt





第 12 章

Bootgen ユーティリティ注意: このユーティリティは、廃止される予定です。代わりに、bootgen コマンドに -read オプションを使用してください。

bootgen_utility は、Bootgen によって生成されたブートイメージの内容をヒトが読めるログファイルにダンプするツールです。これは、ブートイメージのさまざまなヘッダーテーブルの内容をデバッグおよび理解するのに役立ちます。ユーティリティは、次のファイルを出力として生成します。• すべてのヘッダーテーブルのダンプ。• レジスタ init テーブルのダンプ。• 個々のパーティションのダンプ。注記: パーティションが暗号化されている場合、ダンプは暗号化されたパーティションとなり、復号化されたパーティションとはなりません。用途:

bootgen_utility -arch <zynq | zynqmp> -bin <binary input file name> -out <output text file>

例:

bootgen_utility -arch zynqmp -bin boot.bin -out info.txt

サンプルの出力ファイルは、次のようになります。

第 12 章: Bootgen ユーティリティ




図 22: 出力例

第 12 章: Bootgen ユーティリティ




付録 A

その他のリソースおよび法的通知

Documentation Navigator およびデザインハブザイリンクス Documentation Navigator (DocNav) では、ザイリンクスの資料、ビデオ、サポートリソースにアクセスでき、特定の情報を取得するためにフィルター機能や検索機能を利用できます。DocNav を開くには、次のいずれかを実行します。• Vivado® IDE で [Help] → [Documentation and Tutorials] をクリックします。• Windows で [スタート] → [すべてのプログラム ] → [Xilinx Design Tools] → [DocNav] をクリックします。• Linux コマンドプロンプトに「docnav」と入力します。ザイリンクスデザインハブには、資料やビデオへのリンクがデザインタスクおよびトピックごとにまとめられており、これらを参照することでキーコンセプトを学び、よくある質問 (FAQ) を参考に問題を解決できます。デザインハブにアクセスするには、次のいずれかを実行します。• DocNav で [Design Hub View] タブをクリックします。• ザイリンクスウェブサイトでデザインハブページを参照します。注記: DocNav の詳細は、ザイリンクスウェブサイトの Documentation Navigator ページを参照してください。DocNav からは、日本語版は参照できません。ウェブサイトのデザインハブページをご利用ください。

ザイリンクスリソースアンサー、資料、ダウンロード、フォーラムなどのサポートリソースは、ザイリンクスサポートサイトを参照してください。

その他のリソースBootgen の資料およびリソース次に示すドキュメントは、Bootgen プロセスをサポートするプロセスに関する補足情報を提供します。• Zynq®-7000 SoC:

○ 『Zynq-7000 SoC ソフトウェア開発者向けガイド』 (UG821: 英語版、日本語版)

付録 A: その他のリソースおよび法的通知


https://japan.xilinx.com/cgi-bin/docs/ndoc?t=design+hubs

https://japan.xilinx.com/cgi-bin/docs/rdoc?t=docnav

https://japan.xilinx.com/support

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug821-zynq-7000-swdev.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug821-zynq-7000-swdev.pdf



○ 『Zynq-7000 SoC テクニカルリファレンスマニュアル』 (UG585: 英語版、日本語版)

• Zynq® UltraScale+™ MPSoC:

○ 『Zynq UltraScale+ MPSoC: ソフトウェア開発者向けガイド』 (UG1137)

○ 『Zynq UltraScale+ デバイステクニカルリファレンスマニュアル』 (UG1085: 英語版、日本語版)

○ 『Versal ACAP テクニカルリファレンスマニュアル』 (AM011)

○ ザイリンクス Zynq UltraScale+ MPSoC ソリューションセンター: http://www.wiki.xilinx.com/Solution+ZynqMP+PL+Programming

Bootgen のその他の資料およびリソース• 『Vivado Design Suite ユーザーガイド: リリースノート、インストール、およびライセンス』 (UG973)

• 『Zynq-7000 SoC のセキュアブートスタートアップガイド』 (UG1025)

• 『Vitis 統合ソフトウェアプラットフォームの資料』 (UG1416) のエンベデッドソフトウェア開発フローのザイリンクスソフトウェアコマンドラインツール

• 『Zynq UltraScale+ MPSoC: エンベデッドデザインチュートリアル』 (UG1209: 英語版、日本語版)

• 『Zynq-7000 SoC のセキュアブート』 (XAPP1175)

• 『Zynq-7000 SoC システムメモリのランタイムインテグリティと認証チェック』 (XAPP1225)

• 『BBRAM および eFUSE のプログラミング』 (XAPP1319)

お読みください: 重要な法的通知本通知に基づいて貴殿または貴社 (本通知の被通知者が個人の場合には「貴殿」、法人その他の団体の場合には「貴社」。以下同じ) に開示される情報 (以下「本情報」といいます) は、ザイリンクスの製品を選択および使用することのためにのみ提供されます。適用される法律が許容する最大限の範囲で、(1) 本情報は「現状有姿」、およびすべて受領者の責任で (with all faults) という状態で提供され、ザイリンクスは、本通知をもって、明示、黙示、法定を問わず (商品性、非侵害、特定目的適合性の保証を含みますがこれらに限られません)、すべての保証および条件を負わない (否認する) ものとします。また、(2) ザイリンクスは、本情報 (貴殿または貴社による本情報の使用を含む) に関係し、起因し、関連する、いかなる種類・性質の損失または損害についても、責任を負わない (契約上、不法行為上 (過失の場合を含む)、その他のいかなる責任の法理によるかを問わない) ものとし、当該損失または損害には、直接、間接、特別、付随的、結果的な損失または損害 (第三者が起こした行為の結果被った、データ、利益、業務上の信用の損失、その他あらゆる種類の損失や損害を含みます) が含まれるものとし、それは、たとえ当該損害や損失が合理的に予見可能であったり、ザイリンクスがそれらの可能性について助言を受けていた場合であったとしても同様です。ザイリンクスは、本情報に含まれるいかなる誤りも訂正する義務を負わず、本情報または製品仕様のアップデートを貴殿または貴社に知らせる義務も負いません。事前の書面による同意のない限り、貴殿または貴社は本情報を再生産、変更、頒布、または公に展示してはなりません。一定の製品は、ザイリンクスの限定的保証の諸条件に従うこととなるので、https://japan.xilinx.com/legal.htm#tos で見られるザイリンクスの販売条件を参照してください。IP コアは、ザイリンクスが貴殿または貴社に付与したライセンスに含まれる保証と補助的条件に従うことになります。ザイリンクスの製品は、フェイルセーフとして、または、フェイルセーフの動作を要求するアプリケーションに使用するために、設計されたり意図されたりしていません。そのような重大なアプリケーションにザイリンクスの製品を使用する場合のリスクと責任は、貴殿または貴社が単独で負うものです。https://japan.xilinx.com/legal.htm#tos で見られるザイリンクスの販売条件を参照してください。





https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2020.2;d=ug1137-zynq-ultrascale-mpsoc-swdev.pdf




http://www.wiki.xilinx.com/Solution+ZynqMP+PL+Programming

http://www.wiki.xilinx.com/Solution+ZynqMP+PL+Programming

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2020.2;t=vivado+install+guide

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1025-zynq-secure-boot-gsg.pdf



https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug1209-embedded-design-tutorial.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug1209-embedded-design-tutorial.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=application_notes;d=xapp1175_zynq_secure_boot.pdf

https://www.xilinx.com/support/documentation/application_notes/xapp1225-rtic.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=application_notes;d=xapp1319-zynq-usp-prog-nvm.pdf

https://japan.xilinx.com/legal.htm#tos

https://japan.xilinx.com/legal.htm#tos



自動車用のアプリケーションの免責条項オートモーティブ製品 (製品番号に「XA」が含まれる) は、ISO 26262 自動車用機能安全規格に従った安全コンセプトまたは余剰性の機能 (「セーフティ設計」) がない限り、エアバッグの展開における使用または車両の制御に影響するアプリケーション (「セーフティアプリケーション」) における使用は保証されていません。顧客は、製品を組み込むすべてのシステムについて、その使用前または提供前に安全を目的として十分なテストを行うものとします。セーフティ設計なしにセーフティアプリケーションで製品を使用するリスクはすべて顧客が負い、製品の責任の制限を規定する適用法令および規則にのみ従うものとします。

商標© Copyright 2019-2020 Xilinx, Inc. Xilinx、Xilinx のロゴ、Alveo、Artix、Kintex、Spartan、Versal、Virtex、Vivado、Zynq、およびこの文書に含まれるその他の指定されたブランドは、米国およびその他各国のザイリンクス社の商標です。 OpenCL および OpenCL のロゴは Apple Inc. の商標であり、Khronos による許可を受けて使用されています。PCI、PCIe、および PCI Express は PCI-SIG の商標であり、ライセンスに基づいて使用されています。 AMBA、AMBADesigner、Arm、ARM1176JZ-S、CoreSight、Cortex、PrimeCell、Mali、および MPCore は、EU およびその他各国のArm Limited の商標です。

この資料に関するフィードバックおよびリンクなどの問題につきましては、[email protected] まで、または各ページの右下にある [フィードバック送信] ボタンをクリックすると表示されるフォームからお知らせください。フィードバックは日本語で入力可能です。いただきましたご意見を参考に早急に対応させていただきます。なお、このメールアドレスへのお問い合わせは受け付けておりません。あらかじめご了承ください。



mailto:[email protected]



Documents

Bootgen ユーザー ガイド - Xilinx

Bootgen ユーザーガイド - Xilinx