Arria 10 SoC
ブート・ユーザーガイド
2015.10.30 UG-1171 更新情報 フィードバック 本資料では、ブート・フロー、ブート・ソース・デバイスの総合的な情報および Arria® 10 SoC 二向けたブートローダの生成とデバッグ方法を紹介します。 この SoC ブート・ユーザガイドには以下の詳細情報が含まれます。 • Arria 10 SoC システムでサポートされる一般的なブート・フロー • 使用可能なブート・ソース・デバイスおよびそのコンフィギュレーション方法• 第 1 および第 2 ブート・ステージ（U-Boot あるいは Unified Extensible Firmware Interface （UEFI）） 注意: 本ユーザガイドでは、U-Boot を代表例として紹介していますが、第 2 ステージの非汎 用パブリック・ライセンス（非 GPL）ブートローダ・ソースとして UEFI の使用も紹介 されています。詳細は、「付録 B：UEFI ブートローダのビルド」を参照してください。 • ブートローダの生成方法およびブート・ソース・デバイスに向けたコンフィギュレーション 方法 • ブートローダのビルド方法 • ブートローダのデバッグ • ブート・メモリおよび SoC 開発プラットフォームに向けた技術的参照付録 関連情報 41 ページの付録 B：UEFI ブートローダのビルド
ブート・プロセス
一般的なブート・フロー
HPS のブートは、複数のステージ・プロセスを経て実行されます。各ステージは、次のステー ジのロードに影響します。 第 1 ステージは、ブート ROM の実行です。HPS 内に位置するブート ROM コードは、プロセッ サをリセットから立ち上げ、既知の状態および安定した状態にします。次に第 2 ステージ・ブー トローダを検索し、次のステージへコントロールを移譲します。ブート ROM コードは、第 2 ス テージ・ブートローダのみを把握しており、後続の潜在的なソフトウェア・ステージは把握して いません。この期間、ブート ROM はエラー条件もシームレスに処理します。 次のステージは、コントロールが第 2 ステージ・ブートローダに移譲される際に開始されます。 第 2 ステージ・ブートローダは、外部フラッシュ・メモリ、あるいは FPGA 内のどちらかの HPS 外部に位置します。FPGA を使用する場合、第 2 ステージ・ブートローダはオンチップ RAM に © 2016 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, ENPIRION, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and logos aretrademarks of Altera Corporation and registered in the U.S. Patent and Trademark Office and in other countries. All other words and logos identified as trademarks or service marks are the property of their respective holders as described at www.altera.com/common/legal.html. Altera warrants performance of its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to any products and services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any information,
ISO 9001:2008
コピーをしなくても直接 FPGA から実行可能です。第 2 ステージ・ブートローダは後続のステー ジ・ソフトウェアを検索し、ロードします。 コントロールが第 2 ステージ・ブートローダに移譲される前に、セキュア・ブートがイネーブル されているのであれば、暗号化/認証化が可能です。 ウォーム・リセット後、ユーザはオンチップ RAM 内でイメージを検索するようブート ROM に 指示を出し、直接実行することが可能です。この場合、RAM 内に格納されたイメージは、あら かじめ認証化されたコードとしてオンチップ RAM にインポートされている場合でも、未認証の クリアテキストとなります。 次の図は、一般的なブート・フローを表しています。ユーザ・ソフトウェア内のソフトウェア・ ステージの数は、この図の限りではなく、ソフトウェア・ステージの役割も異なる場合がありま す。 図 1: 一般的なブート・フロー 一般的なブート・フローにおける第 2 ステージ・ブートローダは、U-Boot となります。一般的 なブート・フロー OS の例は、Linux です。
Reset
Boot ROM
Second-Stage
Boot Loader
Operating
System
Application
User Software
ベアメタル・ブート・フロー
次の図は、ベアメタル・アプリケーションを使用するブート・フローを表しています。 図 2: ベアメタル・ブート・フロー
Reset
Boot ROM
Second-Stage
Boot Loader
BareMetal
カスタム・ブート・フロー
必要に応じて、カスタムのブート・フローを作成することも可能です。 図 3: カスタム・ブートローダ・フロー
Reset
Boot ROM
Custom Boot
Loader
Application
ブート・ステージ
リセット
リセットはブート・ステージ前に実行され、デバイス初期化における重要な手順となります。リ セットには、コールド・リセットとウォーム・リセットの 2 種類のリセット方法があります。 SoC の FPGA 部分は、コンフィギュレーション完了時にウォーム・リセットあるいはコールド・ リセットをトリガすることが可能です。ブート・プロセスは、MPU 内の CPU0 がリセット状態を終了すると開始します。CPU0 がリセ ットを終了する際、ブート ROM が配置されているリセット例外アドレスでコードの実行を開始 します。CPU1 はこの間リセット状態を維持し、後にユーザ・ソフトウェアによってリセットか ら脱け出します。 ウォーム・リセットでは、一部のソフトウェア・レジスタは保存され、ソフトウェアの設定によ ってはブート・プロセスはいくつかの手順を飛ばして進みます。これに加え、ウォーム・リセッ トでは第 2 ステージ・ブートローダはオンチップ RAM からの実行が可能です。 関連情報 • Reset Manager
ソフトウェア・リセットの詳細については、Arria 10 Hard Processor System Technical Reference
Manual の「Reset Manager」の章を参照してください。
• Arria 10 Core Fabric and General Purpose I/Os Handbook
FPGA のコンフィギュレーションおよびリセットについての詳細情報です。
第 1 ステージ：ブート ROM
ブート ROM コードのサイズは 64 kB で、アドレス 0xFFFD0000 から 0xFFFDFFFF のオンチップ ROM に位置しています。ブート ROM コードの役割は、ブート・ソースの決定、リセット後の HPS の初期化、プリローダへのジャンプです。第 2 ステージ・ブートローダ・イメージが既にフ ラッシュ・メモリからオンチップ RAM へロードされている場合、ブート ROM はオンチップ RAM ロケーションへジャンプします。ブート ROM は HPS を初期化する際、以下の動作を実行 します。 • CPU0 の NEON ベクタ・ユニット、命令キャッシュ、分岐予測、浮動小数点をイネーブルし ます。 • level 4（L4）watchdog 0 タイマを設定します。 • Boot Select（BSEL）設置をもとに専用ピンをコンフィギュレーションします。 • フラッシュ・コントローラをデフォルト設定に初期化します。 フラッシュ・メモリからボンディングを行う際、ブート ROM コードはオンチップ RAM の上部 32 B をデータ・ワークスペースとして使用します。このエリアはリセット後、ブート ROM コー ドが第 2 ステージ・ブートローダにソフトウェア・コントロールを移譲するまで、ブート ROM コード用に予約されます。第 2 ステージ・ブートローダの最大サイズは、認証化を行う場合であ れば 208 KB で、認証化を行わない場合 224 KB となります。RAM からのウォーム・ブートある いは FPGA からのブートの場合、ブート ROM コードはオンチップ RAM の上部 32 KB を保存し ません。また、ユーザはブート ROM によって上書きされることなく、このエリアにユーザ・デ ータを配置することができます。 注意: ブート ROM は、使用するオンチップ RAM の 32 KB 内の部分のみを初期化します。オン チップ RAM 内で第 2 ステージ・ブートローダが ECC を必要とする場合は、コールド・リ UG-1171 2015.10.30 ブート・ステージ 3セットですべての RAM をクリアするセキュリティ・ヒューズをイネーブルします。セキ ュリティ・ヒューズの詳細については、Arria 10 Hard Processor System Technical Reference
Manual の SoC Security の章を参照してください。
ブート・プロセスは、CPU0 がリセット状態を終了すると開始します。ブート ROM コードは CPU0 でのみ実行されます。CPU1 はユーザ・ソフトウェアによってリリースされるまでリセッ ト状態を維持します。CPU0 がリセットを完了すると、リセット例外アドレスでコードの実行を 開始します。 ブート ROM 実行中、クロック・コントロール・ヒューズの情報はクロック・マネージャに、そ してメモリ・コントロール・ヒューズの情報はリセット・マネージャにそれぞれ自動で送信さ れ、その他のヒューズ機能（認証、暗号化、プライベートおよびパブリック・キー・ソース、ハ ッシュ関数） は、ブート・コードがリードできるようにメモリ・マップされた箇所に格納され ます。通常の動作では、ブート ROM はリセット例外アドレスにマップされるため、コードはブ ート ROM 内で実行を開始します。
CPU0 がブート ROM コードを完了し、ユーザ・ソフトウェアの実行を開始する際、ブート ROM アクセスはディセーブルされます。CPU0 で実行するユーザ・ソフトウェアは、ユーザ・ソフト ウェア例外ベクタを 0x0（これは以前ブート ROM 例外ベクタにマップされたものです）にマッ ピングする必要があり、また必要であれば CPU1 をリセットからリリースします。CPU1 がリセ ットからリリースされる際、CPU1 はブート ROM ではなくユーザ・ソフトウェア例外を実行し ます。 関連情報 SoC Security
セキュリティ・ヒューズについての詳細は、Arria 10 Hard Processor System Technical Reference
Manual の SoC Security の章を参照してください。
ブート ROM フロー
コールド・リセットでは、HPS ブート・プロセスは CPU0 がリセット（たとえば起動時）からリ リースされると開始し、リセット例外アドレス 0x00000000 で内部ブート ROM のコードを実行 します。 ブート ROM コードによって SoC はリセットから脱け出し、既知の状態となります。 ブート ROM コード完了後、コントロールは第 2 ステージ・ブートローダと呼ばれるブート・ソ フトウェアの次のステージへと移ります。第 2 ステージ・ブートローダはカスタム化が可能で、 通常は HPS 外部の不揮発性フラッシュ・ベースのメモリか FPGA 内のオンチップ RAM に保存さ れます。第 2 ステージ・ブートローダは、OS、ベアメタル・アプリケーションにロードするこ とが可能です。またはサード・パーティ製のブートローダにロードすることも可能です。 この項では、ブート ROM コードがソフトウェア・コントロールを第 2 ステージ・ブートローダ に渡すまでのリセットからのソフトウェア・フローについて説明します。 コードが開始するとシステムが初期化されますが、要求されるブートの種類によってはオンチッ プ RAM にコードのロードを試みることも可能です。ロードが成功すれば、第 2 ステージ・ブー トローダ・コードが実行されます。ブート ROM がコードの検索できない場合、あるいは 3 度連 続してロードに失敗した場合、スピンしウォッチドッグ・リセットを待ちます。 4 ブート ROM フロー 2015.10.30UG-1171図 4: メイン・ブート ROM フロー
Initialize System
Reset
Boot Type
Jump to Code
FPGA Boot RAM Boot Error
Boot Code Valid?
Reserved Boot Flash Boot
High-Level
Boot FPGA Boot RAM Boot Reserved Boot
Spin Until Watchdog Reset Yes
No
ブート ROM は常に CPU0 で実行します。CPU1 はメイン・ブート ROM コードの実行中は常に リセットで保持され、システム・ソフトウェアによってのみリリースされます。 ブートの種類を判断する一環として、ブート ROM は下位レベルのブート・フローを実行しま す。ブート ROM コードは第 2 ステージ・ブートのソースが強制的に FPGA となるかどうかを判 断するためにセキュリティ・ヒューズを読み込みます。非認証の FPGA ブートあるいは非 CRC オンチップ RAM ブートが要求される場合やブートが無効の場合、ブートは下位レベルのブー ト・フロー内で処理されます。その他の種類のブートはすべて上位レベルのブート・フロー内で 処理されます。 UG-1171 2015.10.30 ブート ROM フロー 5
図 5: 下位レベルのブート・フロー
Read Current Security Status in Security Manager
Boot Not Valid
FPGA Boot? RAM Boot Valid?
Boot Required to boot
from FPGA?
Must Authenticate?
RAM Boot Allowed?
Enable FPGA Access
FPGA Boot
Read BSEL Pins
Boot Valid FPGA Boot Boot Not Valid FPGA Boot Boot Not Valid FPGA Boot?
RAM Boot Low-Level Boot
Read BSEL Pins
No No No No No No Yes Yes Yes Yes Yes Yes 下位レベル部分のブート ROM フローの間、FPGA のみのブートが必要であるかを判断するため にブート ROM はセキュリティ・ヒューズを読み込みます。この場合、ブート ROM は POF の認 証を示すヒューズが必要であるかも決定する必要があります。認証が必要でなければ、標準の FPGA コンフィギュレーションが実行されます。
FPGA のみのブートが必要とされない場合、ブート ROM はオンチップ RAM ブートが可能であ るかをチェックします。可能である場合、ブート ROM はコードが有効であるかを確認します。 コードが有効でなければ、ブート ROM は FPGA ブートを示しているかを決定するために BSEL ピンをリードします。
ブート・イメージに対し認証が必要であることをセキュア・ヒューズが示すのであれば、（C コ ードで実行される）上位レベルのブートを実行する必要があります。 図 6: 上位レベルのブート・フロー Global Initialization No Error
RAM Boot Valid?
Continue Boot Boot from FPGA & no Authenticate?
No Error
Initialize DMA
No Error ErrorError Valid Image? RAM Boot High-Level Boot Initialize Hardware No No No Yes Yes Yes
Load from flash
ブート・プロセス中、ブート・イメージで認証と復号を実行することが可能です。認証は復号か ら独立していますが、認証と復号の両方が必要とされるのであれば、必ず認証が先に実行されま す。認証ブートが必要な場合、ブート ROM には認証プロセスを開始するにあたってルート・キ ーが必要です。このキーはユーザ・ヒューズや FPGA ロジック・エレメントに実装したり、ある いは第 2 ステージ・ブート・イメージ・ヘッダの一部として実装したりすることが可能です。デ バイス・コンフィギュレーション・ヒューズはキーのソースを決定します。 UG-1171 2015.10.30 ブート ROM フロー 7
フラッシュ・メモリからのコールド・ブート中、ブート ROM コードはフラッシュ・メモリから オンチップ RAM への最初の第 2 ステージ・ブートローダ・イメージのロードを試み、コントロ ールを第 2 ステージ・ブートローダに渡します。この初期イメージが有効でない場合、ブート ROM コードはromcode_initswlastldレジスタにインデックスを付与し、次に格納されたイメー ジのロードを試みます。ブート ROM は最初のロードの後、3 回連続してロードを試みます。こ れらのロード後においても有効なイメージが検索されない場合、ブート ROM コードはフォール バック・イメージのためにデバイスの FPGA 部分をチェックします。 注意: ブート・プロセス中、ブート ROM はすべてのキャッシュ（L1 データおよび命令キャッシ ュと L2 キャッシュ）をイネーブルします。第 2 ステージ・ブートローダがブート・フラ ッシュ・デバイス（SD/MMC、QSPI、NAND）プロパティからロードされない場合、キャ ッシュはブート ROM がフォールバック・イメージのためにデバイスの FPGA 部分をチェ ックをする際、オンのままとなります。この状態は、コードをロードする際にコヒーレン シに関する問題の原因となるため、キャッシュはフォールバック・イメージ内でフラッシ ュされディセーブルされなければいけません。 ウォーム RAM ブートが成功しない、あるいはコールド・リセットが発生する場合は、ブート ROM はシステム・マネージャのbootinfoレジスタ内の BSEL 値を読み込みます。FPGA がブー
ト・ソースとして選択されているのであれば、ブート ROM コードは HPS-FPGA 間のブリッジの アドレス 0xC0000000 でコードの実行を試みます。FPGA が正しく初期化されず、ウォッチドッ グがタイムアウトに向けてイネーブルされない場合、エラー条件は生成されません。代わりに、 ブート ROM は FPGA が利用可能となるまで継続して待機します。 BSEL ビットが外部フラッシュからのブートを示すのであれば、ブート ROM コードはフラッシ ュ・デバイスからオンチップ RAM へのイメージのロード、検証と実行を試みます。BSEL が無 効であったり、ブート ROM コードが有効なイメージをフラッシュ内に見つけられない場合は、 ブート ROM コードは FPGA 内にフォールバックが存在するかどうかをチェックします。存在 する場合はブート ROM はそのフォールバック・イメージを実行し、存在しない場合はブート ROM はオンチップ RAM へ情報の事後分析ダンプを実行し、リセットを待ちます。 注意: 略語の BSEL と BOOTSEL は、ブート選択ピンを定義する場合同じ意味で用いられます。 ブート ROM コードは破損したイメージが実行されることがないよう、いくつかの方法で第 2 ス テージ・ブートローダを検証します。最初はイメージ・ヘッダを検証しますが、これはブロック を保護するイメージの CRC、マジック・ナンバー、バージョン、ブロック長を特定します。い ずれかが無効であれば、エラーが発生します。
第 2 ステージ：ブートローダ（U-Boot）
注意: この項では、U-Boot の機能に関する情報を提供します。UEFI ブートローダの機能につい ての情報は、 アルテラ® ウィキ・ページのテクニカル・リファレンス資料を参照してくだ さい。 第 2 ステージ・ブートローダの機能は、ユーザによって定義されます。アルテラが提供する第 2 ステージ・ブートローダは、初期化、コンフィギュレーション、U-Boot コードが組み合わされ たもので、以下の機能が含まれます。 • SD/MMC コントローラ・ドライバ • QSPI コントローラ・ドライバ • プロトコルをサポートするイーサネット・ドライバ 8 第 2 ステージ：ブートローダ（U-Boot） 2015.10.30UG-1171• キャッシュ・メモリ・ドライバ
• UART、タイマ、およびウォッチドッグ・ドライバ • FAT ファイル・システム・サポート
• Flat Image Tree（FIT）イメージ処理
• 基本的かつ不可欠なデバッグ・コマンドを含む U-Boot コンソール・サポート • 暗号ライブラリ • U-Boot デバイス・ツリー処理ライブラリ • システムおよびメモリ・ファイアウォール・コンフィギュレーション • ソフトウェアの次のステージをロードするインタフェースに向けた初期化コード セキュア・ブートが必要な場合、セキュリティのレベルを上げ、必要であれば次のブート・イメ ージの認証と復号を開始するには第 2 ステージ・ブートローダを使用することができます。 SDRAM ファイアウォールをコンフィギュレーションすると、第 2 ステージ・ブートローダがブ ート・ソフトウェアの次のステージを SDRAM へロードすることが可能となります。オンチップ RAM に収まる第 2 ステージ・ブートローダの最大レングスは、認証がある場合は 208 KB、認証 がない場合は 224 KB です。一般的な次のソフトウェア・ステージは、アプリケーション OS ソ フトウェアのロードです。第 2 ステージ・ブートローダは、使用可能などのデバイスからも HPS へ次のステージ・ブート・ソフトウェアをロードすることが可能です。一般的なソースには、第 2 ステージ・ブートローダ、別のフラッシュ・デバイス、あるいは EMAC などの通信インタフェ ースを含む同じフラッシュ・デバイスが含まれます。 第 2 ステージ・ブートローダを認証化する必要が有る場合、第 2 ステージ・ブートローダはパブ リック・キーを格納する必要があります。以下の図は、セキュア、認証ブート中にブート ROM に尿時される第 2 ステージ・ブートローダ・イメージを表しています。 UG-1171 2015.10.30 第 2 ステージ：ブートローダ（U-Boot） 9
図 7: 第 2 ステージ・ブートローダ・イメージの上位レベルの図
Boot ROM Header CRC
Boot ROM Authentication Header
Boot ROM Standard Header
Second-Stage Boot Loader Binary
Keys to Authenticate/Decrypt Next Stage
Clock Configuration
Pin Configuration
Memory Configuration
Second-Stage Boot Loader DTB
関連情報
Altera Wiki Site
UEFI に関する説明およテクニカル・リファレンスについてはこのサイトを参照してください。
外部ブート・フロー
The second stage boot loader has the capability of supporting the following types of boot: • Non-secure clear text boot
• Secure boot with:
• Authentication only (also called verified boot) • Decryption only
• Authentication and decryption 一般的なブート・フロー（非セキュア）
非セキュアの第 2 ステージ・ブート・プロセスは通常、以下の図に示すフローに従います。
図 8: 一般的な第 2 ステージ・ブートローダのフロー（非セキュア）
Second-Stage Boot Loader Entry Low-Level Initialization Assert Reset to Affected Peripherals/ Components during PLL Reconfiguration
Clock Reconfiguration Configure Dedicated HPS I/O
Configure Pin Multiplexing through the System Manager Reset Deassertion through the
Reset Manager System Interconnect Configuration
Timer & UART Initialization SDRAM Interface Initialization (Include
Calibration & PLL Configuration)
Success? yes
no
Next Stage Boot Device Initialization Checking Boot Image’s Checksum
(Optional) Checksum Passed?
yes no
Copy the Next Stage Boot Image from the Next Stage Boot Device to the SDRAM
Write Magic Value to the Initial Software State Register
Error Handler Pass Control to Next Boot
Stage Software in SDRAM Configure Shared HPS I/O & Hard Memory
Controller I/O Using Full or Early Release FPGA Configuration Flow
FPGA Fabric and I/O Configured Thru FPGA? no yes 下位レベルの初期化のステップには、L4 ウォッチドッグ 0 タイマのリコンフィギュレーション とディセーブル、命令キャッシュと分岐予測の無効化、最下位メモリ領域へのオンチップ RAM の再マッピング、およびデータ・エリアの設定が含まれます。 第 2 ステージ・ブートローダに進むと、L4 ウォッチドッグ 0 タイマがアクティブとなります。 第 2 ステージ・ブートローダは、このウォッチドッグ・タイマをディセーブル、リコンフィギュ レーションすることや、あるいは変更させない状態にしておくことが可能です。リセット後にイ ネーブルされると、ウォッチドッグ・タイマをディセーブルすることは不可能で、停止あるいは リセットのみ選択可能です。 ブート ROM コードによってこれより前にイネーブルされていた命令キャッシュと分岐予測を 無効化する必要があります。第 2 ステージ・ブートローダがデータ・キャッシュをイネーブルし 使用する場合、イネーブルを行う前に全レベルのデータ・キャッシュを初期化する必要がありま す。 例外ベクタが依然ブート ROM 内で例外ハンドラに向けられているため、第 2 ステージ・ブート ローダは実行開始時に例外ベクタ・テーブルを再マップする必要があります。システム・インタ コネクトをビット 0 から 1 に再マップするよう設定することで、オンチップ RAM はメモリ・マ UG-1171 2015.10.30 一般的なブート・フロー（非セキュア） 11
ップの最下位領域を反映します。この再マップ実行は、例外ベクタはブートローダ・イメージ内 で例外ハンドラを使用します。 次の図は、再マップ実行前と実行後のメモリ・マップを表しています。 図 9: オンチップ RAM の再マップ
On-Chip RAM
...
On-Chip ROM
...
SDRAM
Unused
On-Chip ROM
0xFFFF_FFFF
0xFFE0_0000
0xFFFD_FFFF
0xFFFC_0000
0xBFFF_FFFF
0x0010_0000
0x0002_0000
Boot ROM
Before
On-Chip RAM
...
On-Chip ROM
...
SDRAM
Unused
On-Chip RAM
0xFFFF_FFFF
0xFFE0_0000
0xFFFD_FFFF
0xFFFC_0000
0xBFFF_FFFF
0x0010_0000
0x0004_0000
Second-Stage
Boot Loader
After
0x0000_0000
0x0000_0000
第 2 ステージ・ブートローダは、すべての HPS クロックをリコンフィギュレーションすること が可能です。クロックのリコンフィギュレーション中、ブートローダはクロックの変更に影響を 受ける HPS のペリフェラルにリセットを挿入します。 HPS の I/O アサインメントは、第 2 ステージ・ブートローダで IOCSR コンフィギュレーション の一部としてコンフィギュレーションされます。I/O アサインメントを含むビットストリーム は効率的に第 2 ステージ・ブートローダ内で初期化コードの一部としてデバイスへ送信されま す。FPGA を介して FPGA ファブリックと I/O がコンフィギュレーションされていない場合、 HPS は SDRAM にアクセスする必要があり、共有およびハード・メモリ・コントローラ I/O をコ ンフィギュレーションするために、フルあるいは早期 I/O リリース・コンフィギュレーション手 法を使用するよう HPS をプログラムすべきです。フルあるいは早期 I/O リリース・コンフィギ ュレーションについての詳細は、Arria 10 Hard Processor System Technical Reference Manual の付録 「Booting and Configuration」の項「FPGA Configuration」を参照してください。第 2 ステージ・ブートローダは、ミラー・イメージ内のブート・イメージ検証データとチェック サムを検査することで次のステージのブート・デバイス内で有効な次のステージのブート・イメ ージを検索します。検証後、第 2 ステージ・ブートローダは次のステージのブート・デバイスか ら SDRAM へ次のステージのブート・イメージ（OS あるいはアプリケーション・イメージ）を コピーします。 ソフトウェアがコントロールを次のステージのブート・ソフトウェアに渡す前、第 2 ステージ・ ブートローダはシステム・マネージャのromcode_initswstateレジスタに有効な値 （0x49535756）をライトすることができます。この値は、オンチップ RAM 内に有効なブート・イ メージが存在することを表します。romcode_initiswlastldレジスタは、ブート・デバイスから ブート ROM によってロードされた最後の第 2 ステージ・ブートローダ・ソフトウェア・イメー ジを保持します。ウォーム・リセット発生時、BSEL の値が最後のブートと等しい場合、ブート ROM はromcode_initswlastldレジスタによって示されるイメージをロードします。 12 一般的なブート・フロー（非セキュア） 2015.10.30UG-1171
関連情報
Booting and Configuration Appendix
フラッシュのコンフィギュレーションについての詳細は、Arria 10 Hard Processor System Technical
Reference Manual の Booting and Configuration Appendix を参照してください。
セキュア・ブート・フロー セキュア・ブートの重要な目的は、信頼のチェーン（chain of trust）を後続するブート・ソフト ウェアに渡すことにあります。セキュア・ブート中、第 2 ステージ・ブートローダはセキュリテ ィ・マネージャのカレント・ステート・レジスタによっては後続するブート・イメージの認証や 復号が可能です。加えて、第 2 ステージ・ブートローダは、後続するブート・イメージがオンチ ップ RAM のようなセキュア・メモリから実行されることを確実にする必要があります。第 2 ス テージ・ブートローダは以下の図のように信頼のチェーンに収まります。 図 10: セキュア・ブート・フロー
Boot ROM (on-chip ROM)
Second-Stage Boot Loader (on-chip RAM)
Secure Micro-OS/ Application (on-chip RAM)
Standard OS (SDRAM) Through Secure API
Secure World
Normal World
Chain of Trust
Authenticate and/or Decrypt
Authenticate and/or Decrypt
マイクロ OS は、ノーマル・ワールドの OS でアプリケーションが Trusted Service を確立するこ とを可能とするセキュア API を提供します。 ベリファイド・ブート中、第 2 ステージ・ブートローダは OS イメージおよび OS が必要とする イメージのみを認証します。以下にベリファイド・ブートのフローを示します。 UG-1171 2015.10.30 セキュア・ブート・フロー 13
図 11: ベリファイド（認証）ブート・フロー
Boot ROM (on-chip ROM)
Second-Stage Boot Loader (on-chip RAM)
OS Image (SDRAM)
zImage
Authenticate Only
Device Tree Blob Filesystem Other
Dotted lines represent files within OS Image
セキュア・ブートとベリファイド・フローの両方のフローでは、第 2 ステージ・ブートローダが オンチップ RAM から実行している間にオンチップ RAM で後続するブート・イメージが実行さ れる必要があります。この要件に適合するためには、選択するセキュア・ブートの種類にもより ますが、認証および復号プロセスは以下の 3 つの図にあるステップに従わなければならない場合 があります。 14 セキュア・ブート・フロー 2015.10.30UG-1171
図 12: 第 2 ステージ・ブートローダの認証プロセス
On-chip RAM SDRAM
Second-Stage Boot Loader
(loaded by boot ROM) FIT Image which contains the securemicro OS/application
FIT Image which contains the secure micro OS/application 1. フラッシュからSDRAMへ FITイメージをロードします 3. ブートローダはオンチップRAMの 最後に折りたたまれ、コピー機能と SHA機能のみが保持されます
Collapsed Second-Stage Boot Loader
2. イメージを認証し ハッシュ値を保存します 4. 第2ステージ・ブートローダはセキュア・マイクロ O/SアプリケーションをオンチップRAMへコピーし、 SHAとマッチングすることでそれを検証します。 マッチする場合、コントロールは マイクロO/Sアプリケーションへ移譲されます。
Copy Function SHA Function
5. セキュア・マイクロO/Sアプリ ケーションはすべてのオンチップ RAMを消費することが可能です。 UG-1171
図 13: 第 2 ステージ・ブートローダの復号プロセス
On-chip RAM SDRAM
Second-Stage Boot Loader
(loaded by boot ROM) FIT Image which contains the securemicro OS/application
FIT Image which contains the secure micro OS/application 1. フラッシュからSDRAMへ FITイメージをロードします 2. ブートローダはオンチップRAMの 最後に折りたたまれ、 DMA機能のみが保持されます
Collapsed Second-Stage Boot Loader
4. 第2ステージ・ブートローダは 復号が完了するまでポーリング します。そしてコントロールは セキュア・マイクロO/S アプリケーションに移譲されます DMA Function 5. セキュア・マイクロO/Sアプリ ケーションはすべてのオンチップ RAMを消費することが可能です。 3. 第2ステージ・ブートローダは、 CSS DMAを介して復号を開始します
DMA and FPGA CSS Engine
復号はオプションであり、セキュア・ブートには必須ではありません。第 2 ステージ・ブートロ ーダのエントリで、CSS エンジンがイネーブルされます。第 2 ステージ・ブートローダが後続の ブート・イメージを復号し、抜け出る際に CSS エンジンをディセーブルします。
図 14: 第 2 ステージ・ブートローダの認証と復号のプロセス
On-chip RAM SDRAM
Second-Stage Boot Loader
(loaded by boot ROM) FIT Image which contains the securemicro OS/application
FIT Image which contains the secure micro OS/application 1. フラッシュからSDRAMへ FITイメージをロードします 3. ブートローダはオンチップRAMの 最後に折りたたまれ、コピー機能、 SHA機能、DMA機能のみが保持されます
Collapsed Second-Stage Boot Loader
6. 第2ステージ・ブートローダは 復号が完了するまでポーリング します。 そしてコントロールは セキュア・マイクロO/Sに移譲 されます DMA Function 4. 第2ステージ・ブートローダは セキュア・マイクロO/S アプリケーションをオンチップRAMへ コピーし、SHAとマッチさせることで 検証します 5. 第2ステージ・ブートローダは、 CSS DMAを介して復号プロセスを 開始します
DMA and FPGA CSS Engine
2. イメージを認証し ハッシュ値を保存します Copy Function SHA Function 7. セキュア・マイクロO/Sアプリ ケーションはすべてのオンチップ メモリを消費することが可能です。 UG-1171 2015.10.30 セキュア・ブート・フロー 17
ブート・デバイス
ブート選択
ブート選択（BSEL）ピンは、第 2 ステージ・ブート・イメージを取得するにあたって複数の方 法を提供します。コールド・リセットでは、ブート・ソースはセキュア・ブートヒューズと BSEL ピントの組み合わせによって決定されます。このようなヒューズの値と BSEL ピンの値は、コー ルド・リセットが開始されると HPS のセキュリティ・マネージャ・モジュールへ送信されます。 HPS がリセットからリリースされる際、ブート ROM はシステム・マネージャのbootinfoレジ スタをリードし、ブートのソースを決定します。 注意: 注意: FPGA からのブート（BSEL[2:0]=0x1）が必要な場合は、FPGA のプログラムが完全に終了 するまで HPS がリセットからリリースされないことを確認する必要があります。これを 怠ると、ブート・ソースを決定するためのbootinfoレジスタが、ブート ROM によって 不正確にリードされる恐れがあります。FPGA の準備が整っているかどうかは、FPGA か ら HPS へのハンドシェイク信号であるf2h_boot_from_fpga_readyと f2h_boot_from_fpga_on_failureによって示されます。f2h_boot_from_fpga_ready信号は 準備が整っていることを示すためにプルアップされる必要があります。 注意: 略語の BSEL と BOOTSEL は、ブート選択ピンを定義する場合同じ意味で用いられます。 表 1: ブート・ソース選択に向けた BSEL の値 BSEL[2:0] Value フラッシュ・デバイス 0x0 予約 0x1 FPGA（HPS-FPGA 間のブリッジ） 0x2 1.8 V NAND フラッシュ・メモリ 0x3 3.0 V NAND フラッシュ・メモリ 0x4 外部トランシーバを備えた 1.8 V SD/MMC フラッシュ・メ モリ 0x5 内部トランシーバを備えた 3.0 V SD/MMC フラッシュ・メ モリ 0x6 1.8 V Quad SPI フラッシュ・メモリ 0x7 3.0 V Quad SPI フラッシュ・メモリ 注意: BSEL の値を 0x4 あるいは 0x5 で設定する場合、SD/MMC コントローラとインターフェイ スする SD カードがコントローラ・インターフェイスとは異なる電圧で動作する必要があ れば、レベル・シフトを供給するために外部トランスレーション・トランシーバおよびア イソレーションが必要となることがあります。詳細は SD/MMC Controller の章を参照し てください。 一般的なブート・フローは、ブート ROM コードがフラッシュ・デバイス上で第 2 ステージ・ブ ートローダ・イメージを特定し、これをオンチップ RAM へロードし、実行するためのもので す。ウォーム・リセット後、ブート ROM コードに RAM 内でイメージを検索し、それを実行す 18 ブート・デバイス 2015.10.30UG-1171HPS フラッシュ・ソースは以下のような様々な種類のファイルを格納することが可能です。 • FPGA プログラミング・ファイル • 第 2 ステージ・ブートローダ・バイナリ・ファイル（最大 4 コピー） • オペレーティング・システム・バイナリ・ファイル • アプリケーション・ファイル・システム フラッシュ内の第 2 ステージ・ブートローダ・イメージは、HPS による認証と解読が可能です。 HPS オンチップ RAM から直接ブートすると、常に未認証でクリアテキストとなります。ただし 必要であればオプションで CRC を持つことができます。 BSEL の値が 0x1 の場合、FPGA はそのブートへのブート・ソースとして選択されます。この選 択は、fpga_boot_f ヒューズがイネーブルされる場合など永続的なのもではありません。両方の ケースにおいて CSEL ヒューズも無視され、HPS は FPGA が起動するまでリセット状態で保持さ れ、ブート ROM がブート・ソースを誤って解釈しないようプログラムする必要があります。 HPS フラッシュ・インタフェースがブート・イメージをロードするよう選択されている場合、 ブート ROM はオンチップ RAM へブート・イメージをロードする前にそのインタエースのイネ ーブルとコンフィギュレーションを実行し、検証を行い、第 2 ステージ・ブートローダへソフト ウェア・コントロールを渡します。
FPGA ファブリックがブート・ソースである場合、ブート ROM コードはデバイスの FPGA 部分 がユーザ・モードとなるまで待機し、コードの実行を準備し、FPGA RAM 内でソフトウェア・ コントロールを第 2 ステージ・ブートローダへ渡します。
ブートに向けたフラッシュ・メモリ・デバイス
ブートローダ・イメージを含むメモリ・コントローラおよびデバイスには、フラッシュから正し くブートを実行するためのコンフィギュレーション要件があります。 すべてのフラッシュ・デバイスには、最大 4 個の第 2 ステージ・ブートローダ・イメージを含む ブート・エリアと呼ばれるメモリ領域が存在します。QSPI および SD/MMC デバイスの場合、ブ ート・エリアのサイズは 1 MB です。NAND デバイスの場合、ブート・エリアのサイズは 4 デバ イス・ブロックですが、NAND 消去ブリックが 256 Kb よりも大きければ 1 MB より大きくなり ます。SD/MMC、Quad SPI、および NAND フラッシュ・デバイスはすべて、Raw モードと MBR（パー ティション）モードをサポートします。Raw モードでは、ブート・イメージはフラッシュ・メモ リ・デバイスの開始のオフセット 0x0 に配置されます。MBR モードでは、以下となります。 • ブート・イメージはカスタム・パーティション（0xA2）からリードされます • 最初のイメージはパーティションの最初であるオフセット 0x0 に配置されます • 開始アドレス = パーティション開始アドレス
Quad SPI
フラッシュ・メモリ
次の図は、Quad SPI フラッシュ・イメージ・レイアウトを表しています。第 2 ステージ・ブー トローダ・イメージは常に 256 KB の倍数であるオフセットに配置されます。 UG-1171 2015.10.30 ブートに向けたフラッシュ・メモリ・デバイス 19図 15: Quad SPI フラッシュ・イメージ・レイアウト
Second-Stage Boot Loader Image 3
Second-Stage Boot Loader Image 2
Second-Stage Boot Loader Image 1
Second-Stage Boot Loader Image 0
Multiple of 256 KB
0x0
ブート ROM コードは、サポートされる SPI あるいは Quad SPI フラッシュ・メモリに向けて Quad SPI コントローラをデフォルト設定にコンフィギュレーションします。
関連情報
フラッシュ・メモリ・デバイス
フラッシュ・メモリ・デバイスに向けたデフォルト設定および CSEL ピンの設定についての詳細 は、Arria 10 Hard Processor System Technical Reference Manual の Booting and Configuration Appendix を参照してください。
SD/MMC
フラッシュ・デバイス
次の図は、ブートに向けた SD/MMC フラッシュ・イメージ・レイアウトの例です。マスタ・ブ ート・レコード（MBR）はメモリの最初の 512 バイトに位置しています。MBR には、パーティ ションについての情報（パーティションのアドレスとサイズ）が含まれます。第 2 ステージ・ブ ートローダ・イメージはパーティション A2 に格納されます。パーティション A2 は、ファイル・ システムを持たないカスタム Raw パーティションです。 図 16: SD/MMC フラッシュ・イメージ・レイアウト...
Second-Stage Boot Loader Image 3
Partition Type: A2
Partition Size: 256 KB x 4
Master Boot Record (MBR)
0x0
MBR Partition Size: 512 Bytes
Second-Stage Boot Loader Image 2
Second-Stage Boot Loader Image 1
Second-Stage Boot Loader Image 0
SD/MMC コントローラは 2 つのブート・モードをサポートします。
• MBR（パーティション）モード • ブート・イメージはカスタム・パーティション（0xA2）からリードされます • 最初のイメージはパーティションの最初であるオフセット 0x0 に配置されます • 開始アドレス = パーティション開始アドレス • Raw モード • MBR シグネチャーが検索されない場合、SD/MMC ドライバはそれを Raw モードであると 仮定します • ブート・イメージ・データはユーザ・エリアのセクタから直接リードされ、SD/MMC の最 初のセクタに配置されます • 最初のイメージはメモリ・カードの開始であるオフセット 0x0 に配置されます • 開始アドレス = 0x0 MBR にはパーティション・テーブルが含まれますが、これは 512 バイトのメモリ・サイズで常 に最初のセクタ（LBA0）に配置されます。MBR は実行可能コード、4 つのパーティション・エ ントリ、そして MBR シグネチャーで構成されます。MBR は FDISK プログラムといった特別な ツールによって作成可能です。 表 2: MBR ストラクチャ オフセット サイズ（バイト） 説明 0x000 446 コード・エリア 0x1BE 16 パーティション 1 へのパーテ ィション・エントリ 0x1CE 16 パーティション 2 へのパーテ ィション・エントリ 0x1DE 16 パーティション 3 へのパーテ ィション・エントリ 0x1EE 16 パーティション 4 へのパーテ ィション・エントリ 0x1FE 2 MBR シグネチャー：0xAA55 標準的な MBR には、16 バイトのエントリを 4 個備えたパーティションが 1 個含まれます。この ため、この標準的なテーブルを使用するメモリカードは 4 個を超えるプライマリ・パーティショ ンあるいは 3 個のパーティションと 1 個の拡張パーティションを含めることはできません。 各パーティション・タイプはパーティション・エントリによって定義されます。ブート・イメー ジはカスタム・パーティション・タイプ（0xA2）を持つプライマリ・パーティション内に格納 されます。SD/MMC フラッシュ・ドライバはファイル・システムをサポートしていないため、 ブート・イメージは固定位置のパーティション A2 に配置されます。 UG-1171 2015.10.30 SD/MMCフラッシュ・デバイス 21
表 3: パーティション・エントリ オフセット サイズ（バイト） 説明 0x0 1 ブート・インディケータ。 0x80 はブート可能であること を表します。 0x1 3 CHS 値の開始 0x4 1 パーティション・タイプ 0x5 3 CHS 値の終了 0x8 4 パーティション内の最初のセ クションの LBA 0xB 4 パーティション内のセクタ数 ブート ROM コードは、サポートされる SD/MMC フラッシュ・メモリに向けて SD/MMC コント ローラをデフォルト設定にコンフィギュレーションします。 関連情報 フラッシュ・メモリ・デバイス フラッシュ・メモリ・デバイスに向けたデフォルト設定および CSEL ピンの設定についての詳細 は、Arria 10 Hard Processor System Technical Reference Manual の Booting and Configuration Appendix を参照してください。
NAND
フラッシュ・デバイス
NAND サブシステムは、NAND デバイスで少なくとも最初の 1 MB を予約します。NAND フラ ッシュ・デバイスに 256 KB を超えるブロックが存在する場合、NAND サブシステムはデバイス の最初のブロック 4 個を予約します。256 KB より小さいサイズのブロックを持つ NAND デバ イスでは、第 2 ステージ・ブートローダ・イメージは複数のブロックに配置する必要がありま す。NAND サブシステムは、NAND デバイスで最大 4 個の第 2 ステージ・ブートローダを検索 することが予想されます。必要であれば 4 個より少ないイメージを持たせることも可能です。 第 2 ステージ・ブートローダ・イメージは、必ず物理ページの最初に位置すべきです。ブロック は消去動作に使用される最小エリアであるため、特定のイメージに更新を行っても他のイメージ に影響することはありません。 22 NANDフラッシュ・デバイス 2015.10.30UG-1171
図 17: 256 KB メモリ・ブロック向け NAND フラッシュ・イメージ・レイアウト
Second-Stage Boot Loader Image 3
Second-Stage Boot Loader Image 2
Second-Stage Boot Loader Image 1
Second-Stage Boot Loader Image 0 0x00000 0x40000 0x80000 0xC0000 0xFFFFF ブートローダ・イメージ に使用可能な各ブロック のサイズは256KBです 関連情報 フラッシュ・メモリ・デバイス フラッシュ・メモリ・デバイスに向けたデフォルト設定および CSEL ピンの設定についての詳細 は、Arria 10 Hard Processor System Technical Reference Manual の Booting and Configuration Appendix を参照してください。
FPGA
からのブート
次の図では、FPGA は非 HPS コンフィギュレーション・ソースのいずれかを介し最初にコンフ ィギュレーションされます。CSS ブロックは FPGA ファブリック、FPGA I/O、共有 I/O、および ハード・メモリ・コントローラ I/O をコンフィギュレーションします。HPS は第 2 ステージ・ブ ートローダを FPGA から実行します。この場合、FPGA の電源がオンになりプログラムされるま で、HSP をリセットからリリースしないでください。FPGA がユーザ・モードとなり、リセット からリリースされた後、ブート ROM コードは実行を開始します。HPS ブート ROM コードは、 HPS-FPGA 間ブリッジを介し FPGA ファブリックから第 2 ステージ・ブートローダを実行しま す。 UG-1171 2015.10.30 FPGAからのブート 23
図 18: FPGA からのブート・フロー HPS D edic at ed I/O
FPGA
FPGA
Fabric
FPGA I/O Shared I/OHard Memory Controller I/O CSS
Boot
ROM
HPS-to-FPGA
Bridge
MPU
HPS
Boot &
Configuration
Sources
PCIe
Passive
Serial
Passive
Parallel
Active Serial/
Active Serial x4
JTAG
24 FPGAからのブート 2015.10.30UG-1171第 2 ステージ・ブートローダのサポート・パッケージ生成ツール
SoC エンベデッド・デザイン・スイート（SoC EDS）には、FPGA デザインに向けてブートロー ダの生成を可能とする第 2 ステージ・ブートローダのサポート・パッケージ（BSP）生成ツール が含まれています。次の項で、ブート生成フローと BSP エディタ・ツールについて解説します。
ブートローダの生成とフロー
ブートローダの生成には、最終的なブート可能なイメージの作成までにいくつかのステップが含 まれます。 各ステップは、以前のステップから独立しています。以下の独立したステップに必要な情報を生 成するには、関連する アルテラ コンプリート・デザイン・スイート（ACDS）あるいは SoC EDS ツールを使用します。ステップおよび使用するツールについては以下の表を参照してください。 表 4: ブートローダの生成ステージとフロー ステップ 必要なツール ステップ 1：FPGA デザインのコンパ イル Quartus ® Prime ステップ 2：ハードウェアのハード・ プロセッサ・システム（HPS）ハンド オフ・ファイルの特定 Quartus Prime ステップ 3：ブートローダ・ソースの 生成とビルド SoC EDS ツール・チェインおよび BSP エディタ 次の図は、U-Boot を使用したブートローダの完全な生成フローを表しています。 注意: UEFI ブートローダに対しては、これに類似したフローを使用することができます。詳細 は「付録 B：UEFI ブートローダのビルド」の項を参照してください。 UG-1171 2015.10.30 第 2 ステージ・ブートローダのサポート・パッケージ生成ツール 25図 19: Arria 10 ブートローダ生成フロー
SD Card U-Boot Binary & U-Boot Device Tree
Image
U-Boot Device Tree make
U-Boot Source U-Boot Makefile BSP Editor User Options Handoff Folder (XML Files) Quartus II SOF Quartus CPF Core RBF Peripheral RBF Hardware Design
Part of SoC EDS Part of ACDS Legend
関連情報
• 41 ページの付録 B：UEFI ブートローダのビルド
• Altera SoC Embedded Design Suite User Guide
BSP ツールについての詳細は、Altera SoC Embedded Design Suite User Guide を参照してくださ い。
ステップ 1：FPGA デザインのコンパイル
ステップ 1 の詳細：FPGA デザインのコンパイルについては、GSRD User Manual を参照してくだ さい。 関連情報 GSRD User Manual
ステップ 2：ハードウェア・ハンドオフ・ファイル
ブートローダを生成する前に、HPS ハンドオフ・ファイルが必要です。ハンドオフ・ファイル は、「ステップ 1：FPGA デザインのコンパイル」で作成され、hps_isw_handoffフォルダ内に保 存されます。 HPS ハンドオフ・ファイルには、（XML として） FPGA ハードウェア・デザイン情が含まれ、正 しい FPGA ハードウェアの初期化とランタイム・アクセスに向けて必要なブートローダ・デバイ ス・ツリーの生成に使用されます。 関連情報 • Clock Select詳細については、Arria 10 Hard Processor System Technical Reference Manual の Booting and Configuration Appendix に記載された「Clock Selects」の項を参照してください。 • I/O Configuration
ステップ 3：ブート・ローダ・ソースの生成
ブート生成フロー内のこのステップは、「QSPI ブート・デバイスを使用したブートローダの生 成」の項で一例として説明されています。 関連情報 30 ページのQSPI ブート・デバイスを使用したブートローダの生成ブートローダ生成ツール：BSP エディタ
BSP エディタ・ツールは、ブートローダ・イメージのコンフィギュレーションと生成にあたって ガイド・オプションを提供します。BSP エディタ・ツールは、settings.bspファイルに保存され ている BSP コンフィギュレーション設定を変更することで既存の生成済みブートローダの編集 にも使用することができます。以下は、BSP エディタのメイン・インタフェースです。 図 20: BSP エディタ このツールでは、以下の選択が含まれるコンフィギュレーション・オプションが利用可能です。 UG-1171 2015.10.30 ステップ 3：ブート・ローダ・ソースの生成 27• 関連する HPS ハンドオフ・ファイル
• ターゲット OS（U-Boot と UEFI ブートの両方が U-Boot OS セレクションｎを使用します） 注意: U-Boot は本ユーザーガイドで詳しく解説していますが、第 2 ステージ・ブートローダ・ ソースとして UEFI を使用する方法についても紹介しています。詳細は、「付録 B：UEFI ブートローダのビルド」を参照してください。 • ブートローダの位置 • ソースおよびコンフィギュレーションの設定（BSP 設定） これらのオプションは、新しくブートローダのコンフィギュレーションを作成する場合も、既存 のブートローダのコンフィギュレーションを編集する場合も選択可能です。次の図は、新規にブ ートローダを生成する際の設定画面を表しています。 図 21: 新規にブートローダを生成する際の BSP 設定 新規に BSP を作成する場合や既存の BSP を編集する場合、BSP エディタでは以下の選択が可能 です。
• Preloader settings directory:HW HPS ハンドオフ・ファイルの位置
• Operating system:ターゲット・プラットフォーム・ブートローダ（U-Boot または UEFI） • Version:ターゲット・プラットフォーム・ブートローダのバージョン（デフォルトまたは推奨
を使用）
• BSP target directory:生成された BSP の位置 • BSP Settings File name:BSP 設定ファイルの位置
• Enable Additional Tcl Script:追加のカスタム設定への Tcl スクリプトを含める • Additional Tcl script:追加の Tcl スクリプトの位置
最初のコンフィギュレーション設定を入力した後、ブートローダ・ソース・デバイスの選択、プ ラットフォール・モデルの選択、FPGA コンフィギュレーション・ファイルに編集を加え、生成 後に自動でブートローダをビルドするかどうかを選択することができます。次の BSP エディタ
図 22: コンフィギュレーション例 以下は、この画面上で選択可能なコンフィギュレーションです。 • boot_device:生成されたブートローダに対しターゲット・ブート・デバイスを選択 • model:ターゲット SoC デバイス・プラットフォーム • peripheral_rbf_filename:ペリフェラル FPGA コンフィギュレーション・ファイル • core_rbf_filename:コア FPGA コンフィギュレーション・ファイル • disable_uboot_build:このオプションを選択すると、BSP はビルドされません（デフォルト） 注意: boot_device コンフィギュレーションは HPS Megawizard 内で選択し、この画面の boot_device プルダウンからは変更しないでください。 UG-1171 2015.10.30 ブートローダ生成ツール：BSP エディタ 29
QSPI
ブート・デバイスを使用したブートローダの生成
この項では、ブート可能なイメージの生成の手順を詳しく解説します。前提条件
QSPI ブート・フラッシュを使用したブートローダの生成には、以下のツールが必要です。 • Arria 10 SoC 開発キット • QSPI ブート・フラッシュ・ドーターカード• Arria 10 SoC と互換性を持つ U-boot および Linux ソース・コード
• QSPI からの Arria 10 SoC ブートをサポートする Quartus Prime バージョン
• QSPI ブートに向けて適切なピン・コンフィギュレーションを持つ FPGA デザイン
• ARM® DS-5 Development Studio バージョン 5.20.2 以降のバージョン、あるいは GNU デバッ グ・パッケージ
QSPI
を使用したブートローダの生成例
1. SoC EDS エンベデッド・コマンドシェルを起動します $ ~/altera/15.0/embedded/embedded_command_shell.sh 2. SoC EDS エンベデッド・コマンドシェルから BSP エディタ・ツールを起動します $ bsp-editor 3. File > New HPS BPS を選択し、画面上で新規に HPS BSP を作成した後、以下をコンフィギュ レーションします a. Preloader settings ディレクトリでハードウェア HPS ハンドオフ・フォルダを指定します b. Specify the boot loader sources folder in the BSP target directory テキスト・ボックスでブートローダ・ソース・フォルダを指定します
c. BSP Settings File name テキスト・ボックスでブートローダ・コンフィギュレーションおよ び設定ファイルを指定します
図 23: 新規の BSP エディタ画面の選択
UG-1171
図 24: 新規の BSP 設定のコンフィギュレーション
4. 各項目の設定完了後、OK をクリックし、main メニュー・タブでソース boot_device（QSPI） を指定します 注意: .rbfファイルは、SD/MMC からブートする場合にのみ適用されます。QSPI コンフィギ ュレーションでは、これらのテキスト・ボックスに変更を加える必要はありませんが、 その代わりに変換スクリプトを介してシングル.rbfファイルを作成する必要がありま す。 32 QSPIを使用したブートローダの生成例 2015.10.30UG-1171
図 25: BSP エディタ画面で QSPI デバイスからブートを選択する 5. Generate を選択すると、BSP ターゲット・ディレクトリとして指定したフォルダ内にブート ローダおよび U-Boot ソース・ファイルが作成されます 6. U-Boot ブートローダ・ソース・フォルダを移動し、イメージをビルドします $ cd ~/a10_soc_devkit_ghrd/software/arria10_uboot_bsp $ make 以下のアイテムが~/a10_soc_devkit_ghrd/software/arria10_uboot_bsp/フォルダ内に生成されま す。 表 5: ブートローダ実行可能イメージ ファイル 説明 u-boot_w_dtb.bin デバイス・ツリー・バイナリを持つ U-boot 実行可能ファ イル
uboot_w_dtb-mkpimage.bin mkpimage ヘッダを持つ U-boot 実行可能ファイル
注意: 第 2 ステージ・ブートローダ・ソースとして UEFI の使用を選択する場合は、この段階 で「付録 B：UEFI ブートローダのビルド」を参照してください。
UG-1171
7. QSPI からブートする場合、FPGA コア・ファブリック・コンフィギュレーションと I/O リン グ設定の両方を含むシングル.rbfファイルが必要です。これは、別の.rbfファイルが必要な SD/MMC ブートとは異なる要件です。エンベデッド・コマンドシェルで以下を入力すること で変換を実行することができます。 $ ~/altera/15.0/embedded/embedded_command_shell.sh $ cd ~/a10_soc_devkit_ghrd/
$ quartus_cpf -c -o bitstream_compression=on output_files/ghrd_10as066n2.sof output_files/ghrd_10as066n2.rbf このコマンドにより、FPGA ファブリックと I/O リング・コンフィギュレーションが組み合わ されたファイルがghrd_10as066n2.rbfという名称で~/a10_soc_devkit_ghrd/output_files/フォル ダに作成されます。 8. U-Boot ソフトウェアが FPGA イメージ・ファイルのロードが可能となる前に、長さや CRC と いったイメージの情報が必要です。このような情報は、エンベデッド・コマンドシェルより mkimage ツールを実行することで U-boot ツールへ渡されます。 $ ~/altera/15.0/embedded/embedded_command_shell.sh $ cd ~/a10_soc_devkit_ghrd/
$ mkimage -A arm -T firmware -C none -O u-boot -a 0 -e 0 -n "A10 GHRD RBF" -d output_files/ghrd_10as066n2.rbf output_files/ghrd_10as066n2.rbf.bin
このコマンドにより、U-Boot ヘッダにラップされた FPGA ファブリックと I/O リング・コン フィギュレーションが組み合わされたファイルが作成されます。生成されるファイルの名称 はghrd_10as066n2.rbf.binファイルで、~/a10_soc_devkit_ghrd/output_files/ghrd_
10as066n2.rbf.binフォルダ内に位置します。
9. HPS Flash Programmer は、U-Boot とデバイス・ツリーのイメージ、および.rbfファイルを QSPI ブート・カードへ書き込むために使用します。HPS Flash Programmer への入力ファイルには 常に.bin拡張子が必要です。ファイルにこの拡張子がない場合、ファイル名を変更する必要 があります。U-Boot とデバイス・ツリーのイメージを QSPI へ書き込むには、以下のコマン ドを入力します。 $ ~/altera/15.0/embedded/embedded_command_shell.sh $ quartus_hps -c 1 -o PV ~/a10_soc_devkit_ghrd/software/arria10_uboot_bsp/ uboot_w_dtb-mkpimage.bin このコマンドの完了には 2 分ほど要します。 10.QSPI へ.rbfファイルを書き込むには、以下のコマンドを入力します。 $ ~/altera/15.0/embedded/embedded_command_shell.sh $ quartus_hps -c 1 -o PV -a 0x720000 ~/a10_soc_devkit_ghrd/output_files/ ghrd_10as066n2.rbf.bin このコマンドの満了には 45 分ほど要します。アルテラは、現段階では HPS Flash Programmer を使用したプログラミングを推奨していますが、今後のアップデートでは、これらのステッ プを高速化を図るには U-Boot コンソールの使用を推奨します。 11.ボードに電力を供給します。QSPI からブートし、U-Boot コンソールで停止します。 関連情報 • 19 ページのQuad SPI フラッシュ・メモリ 34 QSPIを使用したブートローダの生成例 2015.10.30UG-1171
• Altera SoC Embedded Design Suite User Guide 必要なソフトウェア開発タスクについての詳細情報です。 • RocketBoards Website
ブートおよび FPGA のコンフィギュレーション
ブート・プロセス中、第 2 ステージ・ブートローダを使用した FPGA のコンフィギュレーション が可能です。また、外部フラッシュ・デバイスといった非 HPS ソース、あるいは Quartus Prime ツールを使用して FPGA をコンフィギュレーションすることが可能です。 関連情報Booting and Configuration Appendix
フラッシュのコンフィギュレーションについての詳細は、Arria 10 Hard Processor System Technical
Reference Manual の Booting and Configuration Appendix を参照してください。
