Arria 10 SoCブート・ユーザーガイド

Transcription

1 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 に All rights reserved. ALTERA, ARRIA, CYCLONE, ENPIRION, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and logos are trademarks of 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 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, product, or service described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device specifications before relying on any published information and before placing orders for products or services. ISO 9001:2008 登録済 Innovation Drive, San Jose, CA 95134

2 2 ベアメタル ブート フロー コピーをしなくても直接 FPGA から実行可能です 第 2 ステージ ブートローダは後続のステージ ソフトウェアを検索し ロードします コントロールが第 2 ステージ ブートローダに移譲される前に セキュア ブートがイネーブルされているのであれば 暗号化 / 認証化が可能です ウォーム リセット後 ユーザはオンチップ RAM 内でイメージを検索するようブート ROM に指示を出し 直接実行することが可能です この場合 RAM 内に格納されたイメージは あらかじめ認証化されたコードとしてオンチップ RAM にインポートされている場合でも 未認証のクリアテキストとなります 次の図は 一般的なブート フローを表しています ユーザ ソフトウェア内のソフトウェア ステージの数は この図の限りではなく ソフトウェア ステージの役割も異なる場合があります 図 1: 一般的なブート フロー UG 一般的なブート フローにおける第 2 ステージ ブートローダは U-Boot となります 一般的なブート フロー OS の例は Linux です User Software Reset Boot ROM Second-Stage Boot Loader Operating System Application ベアメタル ブート フロー 次の図は ベアメタル アプリケーションを使用するブート フローを表しています 図 2: ベアメタル ブート フロー Reset Boot ROM Second-Stage Boot Loader BareMetal カスタム ブート フロー 必要に応じて カスタムのブート フローを作成することも可能です 図 3: カスタム ブートローダ フロー Reset Boot ROM Custom Boot Loader Application

3 UG ブート ステージ 3 ブート ステージ リセットリセットはブート ステージ前に実行され デバイス初期化における重要な手順となります リセットには コールド リセットとウォーム リセットの 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 を必要とする場合は コールド リ

4 4 ブート ROM フロー セットですべての 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 フロー UG コールド リセットでは HPS ブート プロセスは CPU0 がリセット ( たとえば起動時 ) からリリースされると開始し リセット例外アドレス 0x で内部ブート ROM のコードを実行します ブート ROM コードによって SoC はリセットから脱け出し 既知の状態となります ブート ROM コード完了後 コントロールは第 2 ステージ ブートローダと呼ばれるブート ソフトウェアの次のステージへと移ります 第 2 ステージ ブートローダはカスタム化が可能で 通常は HPS 外部の不揮発性フラッシュ ベースのメモリか FPGA 内のオンチップ RAM に保存されます 第 2 ステージ ブートローダは OS ベアメタル アプリケーションにロードすることが可能です またはサード パーティ製のブートローダにロードすることも可能です この項では ブート ROM コードがソフトウェア コントロールを第 2 ステージ ブートローダに渡すまでのリセットからのソフトウェア フローについて説明します コードが開始するとシステムが初期化されますが 要求されるブートの種類によってはオンチップ RAM にコードのロードを試みることも可能です ロードが成功すれば 第 2 ステージ ブートローダ コードが実行されます ブート ROM がコードの検索できない場合 あるいは 3 度連続してロードに失敗した場合 スピンしウォッチドッグ リセットを待ちます

5 UG ブート ROM フロー 5 図 4: メイン ブート ROM フロー Reset Initialize System Boot Type Flash Boot FPGA Boot RAM Boot Reserved Boot Error High-Level Boot FPGA Boot RAM Boot Reserved Boot Code Valid? No Yes Jump to Code Spin Until Watchdog Reset Boot ブート ROM は常に CPU0 で実行します CPU1 はメイン ブート ROM コードの実行中は常にリセットで保持され システム ソフトウェアによってのみリリースされます ブートの種類を判断する一環として ブート ROM は下位レベルのブート フローを実行します ブート ROM コードは第 2 ステージ ブートのソースが強制的に FPGA となるかどうかを判断するためにセキュリティ ヒューズを読み込みます 非認証の FPGA ブートあるいは非 CRC オンチップ RAM ブートが要求される場合やブートが無効の場合 ブートは下位レベルのブート フロー内で処理されます その他の種類のブートはすべて上位レベルのブート フロー内で処理されます

6 6 ブート ROM フロー 図 5: 下位レベルのブート フロー UG Low-Level Boot Read Current Security Status in Security Manager Required to boot from FPGA? No Yes Must Authenticate? No RAM Boot Allowed? No Yes Yes Enable FPGA Access RAM Boot Valid? No Yes RAM Boot Read BSEL Pins Read BSEL Pins FPGA Boot? No FPGA Boot? No Yes Yes Boot Not Valid FPGA Boot Boot Valid FPGA Boot Boot Not Valid FPGA Boot Boot Not Valid Boot 下位レベル部分のブート ROM フローの間 FPGA のみのブートが必要であるかを判断するためにブート ROM はセキュリティ ヒューズを読み込みます この場合 ブート ROM は POF の認証を示すヒューズが必要であるかも決定する必要があります 認証が必要でなければ 標準の FPGA コンフィギュレーションが実行されます FPGA のみのブートが必要とされない場合 ブート ROM はオンチップ RAM ブートが可能であるかをチェックします 可能である場合 ブート ROM はコードが有効であるかを確認します コードが有効でなければ ブート ROM は FPGA ブートを示しているかを決定するために BSEL ピンをリードします

7 UG ブート ROM フロー 7 ブート イメージに対し認証が必要であることをセキュア ヒューズが示すのであれば (C コードで実行される ) 上位レベルのブートを実行する必要があります 図 6: 上位レベルのブート フロー High-Level Boot Global Initialization Boot from FPGA & no Authenticate? No Yes Initialize Hardware RAM Boot Valid? No Yes RAM Boot Initialize DMA Load from flash Valid Image? No Yes No Error No Error No Error Error Continue Boot ブート プロセス中 ブート イメージで認証と復号を実行することが可能です 認証は復号から独立していますが 認証と復号の両方が必要とされるのであれば 必ず認証が先に実行されます 認証ブートが必要な場合 ブート ROM には認証プロセスを開始するにあたってルート キーが必要です このキーはユーザ ヒューズや FPGA ロジック エレメントに実装したり あるいは第 2 ステージ ブート イメージ ヘッダの一部として実装したりすることが可能です デバイス コンフィギュレーション ヒューズはキーのソースを決定します

8 8 第 2 ステージ : ブートローダ (U-Boot) フラッシュ メモリからのコールド ブート中 ブート 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 間のブリッジのアドレス 0xC でコードの実行を試みます FPGA が正しく初期化されず ウォッチドッグがタイムアウトに向けてイネーブルされない場合 エラー条件は生成されません 代わりに ブート ROM は FPGA が利用可能となるまで継続して待機します BSEL ビットが外部フラッシュからのブートを示すのであれば ブート ROM コードはフラッシュ デバイスからオンチップ RAM へのイメージのロード 検証と実行を試みます BSEL が無効であったり ブート ROM コードが有効なイメージをフラッシュ内に見つけられない場合は ブート ROM コードは FPGA 内にフォールバックが存在するかどうかをチェックします 存在する場合はブート ROM はそのフォールバック イメージを実行し 存在しない場合はブート ROM はオンチップ RAM へ情報の事後分析ダンプを実行し リセットを待ちます 注意 : 略語の BSEL と BOOTSEL は ブート選択ピンを定義する場合同じ意味で用いられます ブート ROM コードは破損したイメージが実行されることがないよう いくつかの方法で第 2 ステージ ブートローダを検証します 最初はイメージ ヘッダを検証しますが これはブロックを保護するイメージの CRC マジック ナンバー バージョン ブロック長を特定します いずれかが無効であれば エラーが発生します 第 2 ステージ : ブートローダ (U-Boot) 注意 : UG この項では U-Boot の機能に関する情報を提供します UEFI ブートローダの機能についての情報は アルテラ ウィキ ページのテクニカル リファレンス資料を参照してください 第 2 ステージ ブートローダの機能は ユーザによって定義されます アルテラが提供する第 2 ステージ ブートローダは 初期化 コンフィギュレーション U-Boot コードが組み合わされたもので 以下の機能が含まれます SD/MMC コントローラ ドライバ QSPI コントローラ ドライバ プロトコルをサポートするイーサネット ドライバ クロック マネージャ システム マネージャ FPGA マネージャといったシステム レベル IP 用ドライバ

9 UG 第 2 ステージ : ブートローダ (U-Boot) 9 キャッシュ メモリ ドライバ 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 ステージ ブートローダ イメージを表しています

10 10 外部ブート フロー 図 7: 第 2 ステージ ブートローダ イメージの上位レベルの図 UG 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 Boot ROM Header CRC 関連情報 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 ステージ ブート プロセスは通常 以下の図に示すフローに従います

11 UG 一般的なブート フロー ( 非セキュア ) 11 図 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 Timer & UART Initialization SDRAM Interface Initialization (Include Calibration & PLL Configuration) Success? yes no Next Stage Boot Device Initialization Configure Shared HPS I/O & Hard Memory Controller I/O Using Full or Early Release FPGA Configuration Flow no FPGA Fabric and I/O Configured Thru FPGA? yes Configure Pin Multiplexing through the System Manager Reset Deassertion through the Reset Manager System Interconnect Configuration 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 Pass Control to Next Boot Stage Software in SDRAM Error Handler 下位レベルの初期化のステップには L4 ウォッチドッグ 0 タイマのリコンフィギュレーションとディセーブル 命令キャッシュと分岐予測の無効化 最下位メモリ領域へのオンチップ RAM の再マッピング およびデータ エリアの設定が含まれます 第 2 ステージ ブートローダに進むと L4 ウォッチドッグ 0 タイマがアクティブとなります 第 2 ステージ ブートローダは このウォッチドッグ タイマをディセーブル リコンフィギュレーションすることや あるいは変更させない状態にしておくことが可能です リセット後にイネーブルされると ウォッチドッグ タイマをディセーブルすることは不可能で 停止あるいはリセットのみ選択可能です ブート ROM コードによってこれより前にイネーブルされていた命令キャッシュと分岐予測を無効化する必要があります 第 2 ステージ ブートローダがデータ キャッシュをイネーブルし使用する場合 イネーブルを行う前に全レベルのデータ キャッシュを初期化する必要があります 例外ベクタが依然ブート ROM 内で例外ハンドラに向けられているため 第 2 ステージ ブートローダは実行開始時に例外ベクタ テーブルを再マップする必要があります システム インタコネクトをビット 0 から 1 に再マップするよう設定することで オンチップ RAM はメモリ マ

12 12 一般的なブート フロー ( 非セキュア ) ップの最下位領域を反映します この再マップ実行は 例外ベクタはブートローダ イメージ内で例外ハンドラを使用します 次の図は 再マップ実行前と実行後のメモリ マップを表しています 図 9: オンチップ RAM の再マップ UG Boot ROM On-Chip RAM... On-Chip ROM... SDRAM Unused On-Chip ROM Before 0xFFFF_FFFF 0xFFE0_0000 0xFFFD_FFFF 0xFFFC_0000 0xBFFF_FFFF 0x0010_0000 0x0002_0000 0x0000_0000 Second-Stage Boot Loader On-Chip RAM... On-Chip ROM... SDRAM Unused On-Chip RAM After 0xFFFF_FFFF 0xFFE0_0000 0xFFFD_FFFF 0xFFFC_0000 0xBFFF_FFFF 0x0010_0000 0x0004_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 レジスタに有効な値 (0x ) をライトすることができます この値は オンチップ RAM 内に有効なブート イメージが存在することを表します romcode_initiswlastld レジスタは ブート デバイスからブート ROM によってロードされた最後の第 2 ステージ ブートローダ ソフトウェア イメージを保持します ウォーム リセット発生時 BSEL の値が最後のブートと等しい場合 ブート ROM は romcode_initswlastld レジスタによって示されるイメージをロードします

13 UG セキュア ブート フロー 13 関連情報 Booting and Configuration Appendix フラッシュのコンフィギュレーションについての詳細は Arria 10 Hard Processor System Technical Reference Manual の Booting and Configuration Appendix を参照してください セキュア ブート フロー セキュア ブートの重要な目的は 信頼のチェーン (chain of trust) を後続するブート ソフトウェアに渡すことにあります セキュア ブート中 第 2 ステージ ブートローダはセキュリティ マネージャのカレント ステート レジスタによっては後続するブート イメージの認証や復号が可能です 加えて 第 2 ステージ ブートローダは 後続するブート イメージがオンチップ RAM のようなセキュア メモリから実行されることを確実にする必要があります 第 2 ステージ ブートローダは以下の図のように信頼のチェーンに収まります 図 10: セキュア ブート フロー Secure World Normal World Authenticate and/or Decrypt Boot ROM (on-chip ROM) Chain of Trust Second-Stage Boot Loader (on-chip RAM) Authenticate and/or Decrypt Secure Micro-OS/ Application (on-chip RAM) Through Secure API Standard OS (SDRAM) マイクロ OS は ノーマル ワールドの OS でアプリケーションが Trusted Service を確立することを可能とするセキュア API を提供します ベリファイド ブート中 第 2 ステージ ブートローダは OS イメージおよび OS が必要とするイメージのみを認証します 以下にベリファイド ブートのフローを示します

14 14 セキュア ブート フロー 図 11: ベリファイド ( 認証 ) ブート フロー UG Boot ROM (on-chip ROM) Second-Stage Boot Loader (on-chip RAM) Authenticate Only OS Image (SDRAM) Dotted lines represent files within OS Image zimage Device Tree Blob Filesystem Other セキュア ブートとベリファイド フローの両方のフローでは 第 2 ステージ ブートローダがオンチップ RAM から実行している間にオンチップ RAM で後続するブート イメージが実行される必要があります この要件に適合するためには 選択するセキュア ブートの種類にもよりますが 認証および復号プロセスは以下の 3 つの図にあるステップに従わなければならない場合があります

15 UG セキュア ブート フロー 15 図 12: 第 2 ステージ ブートローダの認証プロセス On-chip RAM 5. セキュア マイクロ O/S アプリケーションはすべてのオンチップ RAM を消費することが可能です SDRAM 2. イメージを認証しハッシュ値を保存します Second-Stage Boot Loader (loaded by boot ROM) FIT Image which contains the secure micro OS/application 3. ブートローダはオンチップ RAM の最後に折りたたまれ コピー機能と SHA 機能のみが保持されます 4. 第 2 ステージ ブートローダはセキュア マイクロ O/S アプリケーションをオンチップ RAM へコピーし SHA とマッチングすることでそれを検証します マッチする場合 コントロールはマイクロ O/S アプリケーションへ移譲されます 1. フラッシュから SDRAM へ FIT イメージをロードします Collapsed Second-Stage Boot Loader Copy Function SHA Function FIT Image which contains the secure micro OS/application

16 16 セキュア ブート フロー 図 13: 第 2 ステージ ブートローダの復号プロセス UG On-chip RAM 5. セキュア マイクロ O/S アプリケーションはすべてのオンチップ RAM を消費することが可能です SDRAM Second-Stage Boot Loader (loaded by boot ROM) FIT Image which contains the secure micro OS/application 2. ブートローダはオンチップ RAM の最後に折りたたまれ DMA 機能のみが保持されます DMA and FPGA CSS Engine 3. 第 2 ステージ ブートローダは CSS DMA を介して復号を開始します 1. フラッシュから SDRAM へ FIT イメージをロードします Collapsed Second-Stage Boot Loader DMA Function FIT Image which contains the secure micro OS/application 4. 第 2 ステージ ブートローダは復号が完了するまでポーリング します そしてコントロールはセキュア マイクロ O/S アプリケーションに移譲されます 復号はオプションであり セキュア ブートには必須ではありません 第 2 ステージ ブートローダのエントリで CSS エンジンがイネーブルされます 第 2 ステージ ブートローダが後続のブート イメージを復号し 抜け出る際に CSS エンジンをディセーブルします

17 UG セキュア ブート フロー 17 図 14: 第 2 ステージ ブートローダの認証と復号のプロセス On-chip RAM 4. 第 2 ステージ ブートローダはセキュア マイクロ O/S アプリケーションをオンチップ RAM へコピーし SHA とマッチさせることで検証します SDRAM 2. イメージを認証しハッシュ値を保存します 7. セキュア マイクロ O/S アプリケーションはすべてのオンチップメモリを消費することが可能です Second-Stage Boot Loader (loaded by boot ROM) FIT Image which contains the secure micro OS/application DMA and FPGA CSS Engine 3. ブートローダはオンチップ RAM の最後に折りたたまれ コピー機能 SHA 機能 DMA 機能のみが保持されます 5. 第 2 ステージ ブートローダは CSS DMA を介して復号プロセスを開始します 1. フラッシュから SDRAM へ FIT イメージをロードします Collapsed Second-Stage Boot Loader DMA Function Copy Function FIT Image which contains the secure micro OS/application SHA Function 6. 第 2 ステージ ブートローダは復号が完了するまでポーリングします そしてコントロールはセキュア マイクロ O/S に移譲されます

18 18 ブート デバイス UG ブート デバイス ブート選択 ブート選択 (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 の値 0x0 BSEL[2:0] Value 予約 フラッシュ デバイス 0x1 FPGA(HPS-FPGA 間のブリッジ ) 0x2 0x3 0x4 0x5 0x6 0x7 注意 : 1.8 V NAND フラッシュ メモリ 3.0 V NAND フラッシュ メモリ 外部トランシーバを備えた 1.8 V SD/MMC フラッシュ メモリ 内部トランシーバを備えた 3.0 V SD/MMC フラッシュ メモリ 1.8 V Quad SPI フラッシュ メモリ 3.0 V Quad SPI フラッシュ メモリ BSEL の値を 0x4 あるいは 0x5 で設定する場合 SD/MMC コントローラとインターフェイスする SD カードがコントローラ インターフェイスとは異なる電圧で動作する必要があれば レベル シフトを供給するために外部トランスレーション トランシーバおよびアイソレーションが必要となることがあります 詳細は SD/MMC Controller の章を参照してください 一般的なブート フローは ブート ROM コードがフラッシュ デバイス上で第 2 ステージ ブートローダ イメージを特定し これをオンチップ RAM へロードし 実行するためのものです ウォーム リセット後 ブート ROM コードに RAM 内でイメージを検索し それを実行するよう指示することが可能です

19 UG ブートに向けたフラッシュ メモリ デバイス 19 HPS フラッシュ ソースは以下のような様々な種類のファイルを格納することが可能です 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 の倍数であるオフセットに配置されます

20 20 SD/MMC フラッシュ デバイス 図 15: Quad SPI フラッシュ イメージ レイアウト UG x0 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 ブート 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 Second-Stage Boot Loader Image 2 Second-Stage Boot Loader Image 1 Second-Stage Boot Loader Image 0... Master Boot Record (MBR) 0x0 Partition Type: A2 Partition Size: 256 KB x 4 MBR Partition Size: 512 Bytes SD/MMC コントローラは 2 つのブート モードをサポートします

21 UG SD/MMC フラッシュ デバイス 21 MBR( パーティション ) モード ブート イメージはカスタム パーティション (0xA2) からリードされます 最初のイメージはパーティションの最初であるオフセット 0x0 に配置されます 開始アドレス = パーティション開始アドレス Raw モード MBR シグネチャーが検索されない場合 SD/MMC ドライバはそれを Raw モードであると仮定します ブート イメージ データはユーザ エリアのセクタから直接リードされ SD/MMC の最初のセクタに配置されます 最初のイメージはメモリ カードの開始であるオフセット 0x0 に配置されます 開始アドレス = 0x0 MBR にはパーティション テーブルが含まれますが これは 512 バイトのメモリ サイズで常に最初のセクタ (LBA0) に配置されます MBR は実行可能コード 4 つのパーティション エントリ そして MBR シグネチャーで構成されます MBR は FDISK プログラムといった特別なツールによって作成可能です 表 2: MBR ストラクチャ オフセットサイズ ( バイト ) 説明 0x コード エリア 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 に配置されます

22 22 NAND フラッシュ デバイス 表 3: パーティション エントリ UG オフセットサイズ ( バイト ) 説明 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 ステージ ブートローダ イメージは 必ず物理ページの最初に位置すべきです ブロックは消去動作に使用される最小エリアであるため 特定のイメージに更新を行っても他のイメージに影響することはありません

23 UG FPGA からのブート 23 図 17: 256 KB メモリ ブロック向け NAND フラッシュ イメージ レイアウト 0xFFFFF 0xC0000 Second-Stage Boot Loader Image 3 Second-Stage Boot Loader Image 2 0x x40000 Second-Stage Boot Loader Image 1 ブートローダ イメージ に使用可能な各ブロック のサイズは 256KB です 0x00000 Second-Stage Boot Loader Image 0 関連情報フラッシュ メモリ デバイスフラッシュ メモリ デバイスに向けたデフォルト設定および 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 ステージ ブートローダを実行します

24 24 FPGA からのブート 図 18: FPGA からのブート フロー UG Shared I/O PCIe CSS Boot & Configuration Sources FPGA I/O FPGA Active Serial/ Active Serial x4 JTAG Passive Serial Passive Parallel FPGA Fabric Hard Memory Controller I/O MPU HPS-to-FPGA Bridge Boot ROM HPS HPS Dedicated I/O

25 UG 第 2 ステージ ブートローダのサポート パッケージ生成ツール 25 第 2 ステージ ブートローダのサポート パッケージ生成ツール SoC エンベデッド デザイン スイート (SoC EDS) には FPGA デザインに向けてブートローダの生成を可能とする第 2 ステージ ブートローダのサポート パッケージ (BSP) 生成ツールが含まれています 次の項で ブート生成フローと BSP エディタ ツールについて解説します ブートローダの生成とフローブートローダの生成には 最終的なブート可能なイメージの作成までにいくつかのステップが含まれます 各ステップは 以前のステップから独立しています 以下の独立したステップに必要な情報を生成するには 関連するアルテラコンプリート デザイン スイート (ACDS) あるいは SoC EDS ツールを使用します ステップおよび使用するツールについては以下の表を参照してください 表 4: ブートローダの生成ステージとフロー ステップ ステップ 1:FPGA デザインのコンパイル ステップ 2: ハードウェアのハード プロセッサ システム (HPS) ハンドオフ ファイルの特定 ステップ 3: ブートローダ ソースの生成とビルド 必要なツール Quartus Prime Quartus Prime SoC EDS ツール チェインおよび BSP エディタ 次の図は U-Boot を使用したブートローダの完全な生成フローを表しています 注意 : UEFI ブートローダに対しては これに類似したフローを使用することができます 詳細は 付録 B:UEFI ブートローダのビルド の項を参照してください

26 26 ステップ 1:FPGA デザインのコンパイル 図 19: Arria 10 ブートローダ生成フロー UG User Options Handoff Folder (XML Files) BSP Editor U-Boot Device Tree U-Boot Makefile make U-Boot Binary & U-Boot Device Tree Image Hardware Design Quartus II U-Boot Source SD Card SOF Quartus CPF Core RBF Peripheral RBF Legend Part of SoC EDS Part of ACDS 関連情報 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 Arria 10 Hard Processor System Technical Reference Manual の Booting and Configuration Appendix に記載された I/O Configuration の項を参照してください

27 UG ステップ 3: ブート ローダ ソースの生成 27 ステップ 3: ブート ローダ ソースの生成 ブート生成フロー内のこのステップは QSPI ブート デバイスを使用したブートローダの生成 の項で一例として説明されています 関連情報 30 ページの QSPI ブート デバイスを使用したブートローダの生成 ブートローダ生成ツール :BSP エディタ BSP エディタ ツールは ブートローダ イメージのコンフィギュレーションと生成にあたってガイド オプションを提供します BSP エディタ ツールは settings.bsp ファイルに保存されている BSP コンフィギュレーション設定を変更することで既存の生成済みブートローダの編集にも使用することができます 以下は BSP エディタのメイン インタフェースです 図 20: BSP エディタ このツールでは 以下の選択が含まれるコンフィギュレーション オプションが利用可能です

28 28 ブートローダ生成ツール :BSP エディタ 関連する HPS ハンドオフ ファイル ターゲット OS(U-Boot と UEFI ブートの両方が U-Boot OS セレクション n を使用します ) 注意 : U-Boot は本ユーザーガイドで詳しく解説していますが 第 2 ステージ ブートローダ ソースとして UEFI を使用する方法についても紹介しています 詳細は 付録 B:UEFI ブートローダのビルド を参照してください ブートローダの位置 ソースおよびコンフィギュレーションの設定 (BSP 設定 ) これらのオプションは 新しくブートローダのコンフィギュレーションを作成する場合も 既存のブートローダのコンフィギュレーションを編集する場合も選択可能です 次の図は 新規にブートローダを生成する際の設定画面を表しています 図 21: 新規にブートローダを生成する際の BSP 設定 UG 新規に 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 エディタ画面は コンフィギュレーションの一例を表しています

29 UG ブートローダ生成ツール :BSP エディタ 29 図 22: コンフィギュレーション例 以下は この画面上で選択可能なコンフィギュレーションです boot_device: 生成されたブートローダに対しターゲット ブート デバイスを選択 model: ターゲット SoC デバイス プラットフォーム peripheral_rbf_filename: ペリフェラル FPGA コンフィギュレーション ファイル core_rbf_filename: コア FPGA コンフィギュレーション ファイル disable_uboot_build: このオプションを選択すると BSP はビルドされません ( デフォルト ) 注意 : boot_device コンフィギュレーションは HPS Megawizard 内で選択し この画面の boot_device プルダウンからは変更しないでください

30 30 QSPI ブート デバイスを使用したブートローダの生成 UG 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 バージョン 以降のバージョン あるいは 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 テキスト ボックスでブートローダ コンフィギュレーションおよび設定ファイルを指定します

31 UG QSPI を使用したブートローダの生成例 31 図 23: 新規の BSP エディタ画面の選択

32 32 QSPI を使用したブートローダの生成例 図 24: 新規の BSP 設定のコンフィギュレーション UG 各項目の設定完了後 OK をクリックし main メニュー タブでソース boot_device(qspi) を指定します 注意 :.rbf ファイルは SD/MMC からブートする場合にのみ適用されます QSPI コンフィギュレーションでは これらのテキスト ボックスに変更を加える必要はありませんが その代わりに変換スクリプトを介してシングル.rbf ファイルを作成する必要があります

33 UG QSPI を使用したブートローダの生成例 33 図 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 ファイル uboot_w_dtb-mkpimage.bin 説明 デバイス ツリー バイナリを持つ U-boot 実行可能ファイル mkpimage ヘッダを持つ U-boot 実行可能ファイル 注意 : 第 2 ステージ ブートローダ ソースとして UEFI の使用を選択する場合は この段階で 付録 B:UEFI ブートローダのビルド を参照してください

34 34 QSPI を使用したブートローダの生成例 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 0x ~/a10_soc_devkit_ghrd/output_files/ ghrd_10as066n2.rbf.bin このコマンドの満了には 45 分ほど要します アルテラは 現段階では HPS Flash Programmer を使用したプログラミングを推奨していますが 今後のアップデートでは これらのステップを高速化を図るには U-Boot コンソールの使用を推奨します 11. ボードに電力を供給します QSPI からブートし U-Boot コンソールで停止します 関連情報 19 ページの Quad SPI フラッシュ メモリ Quad SPI Flash に関する詳細情報はこの項を参照してください 41 ページの付録 B:UEFI ブートローダのビルド UG

35 UG ブートおよび FPGA のコンフィギュレーション 35 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 を参照してください ブートのデバッグ この項では ブート プロセスのデバッグの一助となるテクニックをいくつか紹介しており ブート ROM とブートローダに対しての配慮がなされています 残りのブート フローは汎用であり 一般的なテクニックでデバッグが可能です コールド ブート デバッグ コールド ブートはボードへの電源の再投入あるいは適用可能な場合にはコールド リセットの発行により開始されます 機能時のブートに関連する問題には以下の共通する兆候があります ハードウェアにアクティビティが見られない ( 例 :LED が点滅していない ) ディスプレイ コンソールにアクティビティが見られない ( 例 :UART 出力や HPS ソフトウェアが実行されない ) ブート ソフトウェアの実行が割り込みされ フリーズしている ブート ROM はパワーアップあるいはコールド ブート中に実行される最初のブート ステージですが ブートを確実に成功させるにはこの他にも検証を要するハードウェア依存が存在します 加えて ロジック アナライザやオシロスコープといった測定装置もブート プロセス中に信号の状態とレベルのチェックやアクティビティのモニタに使用可能です ハードウェア プラットフォームが安定しており ブート ソフトウェアの依存が仕様範囲内であることを検証することで ブート ROM とブートローダが確実にロードおよび実行されます 以下は 確実にブートを成功させるために確認すべき依存性のサンプルです ボードの電源をチェックします 仕様の範囲内であり 過度のノイズが存在しないことを確認します 電源シーケンスが正しい順序であり すべてのレベルが各ステージで仕様の範囲内であることを確認します 入力クロックは その振幅 周波数 ノイズ およびジッタを検証しておく必要があります すべてのリセット信号がデザインの仕様およびレベルにシーケンスされていることを検証します

36 36 ウォーム ブート デバッグ ウォーム ブート デバッグ ウォーム デバッグの問題には以下の原因が考えられます アプリケーション ソフトウェアがウォーム ブートを正しくない方法でイネーブルした アプリケーション ソフトウェアが使用シナリオとは一致しない方法でウォーム リセット オプションを修正した 使用されたブート ソースがウォーム リセット中にリセットされていない ブート ROM およびブートローダ デバッグ レジスタの使用方法 HPS がブートローダ ステートを実行する場合 ブート ROM とブートローダによって維持されるレジスタはブート プロせずを介して更新されています このようなレジスタは 有益なステータスと情報を提供し これらを詳しく調べることでブート障害の原因を検証することができます レジスタは システム マネージャの sysmgr.romcodegrp 内で利用可能です 以下はレジスタとその説明です initswstate 次の有効なブート ステージにジャンプする前にブートローダが magic value である 0x をレジスタにライトします この値がない場合 ブートローダが後続のブート ステージの実行に成功しなかったことを示します initswlastld ブート ソース デバイスからロードされた最後のブートローダ ソフトウェア イメージのインデックスを含みます 最大 4 個のブートローダ イメージがロード可能です bootromswstate ブート ROM ステートの情報を含みます Bit[0]: このビットが設定されている場合 すべてのブート イメージのロードに成功しなかったことを示します Bit[1]: このビットが設定されている場合 ブートローダが開始 あるいは実行していたこと ( 後に成功しなかった可能性もあります ) を示します Bits[11:8]: この領域はブート フラッシュ デバイスを示します 0x0= NAND 0x1= SD/MMC 0x2= QSPI ブート フラッシュ デバイスの問題 UG HPS がソフトウェアを実行していても ブート ROM がブートローダ イメージのロードに成功しない場合 考えられる原因はに以下があります ブートローダ イメージがブート デバイス フラッシュ内で破損している ブートローダ イメージは有効であるが ブート フラッシュ デバイスの通信にエラーがある ブートローダ イメージのロードは成功したが ソフトウェアのバグによりランタイム実行が成功しない フラッシュ デバイスの通信に関する問題を軽減するには CSEL=0x0 で設定します この設定により ブート ROM が PLL を再度プログラミングすることが防止され デバイスで最低の通信スピードを強制的に使用させます 以下の目的のため フラッシュ メモリ信号は可能であれば適切な測定機器 ( ロジック アナライザやオシロスコープ ) を使用しモニタしてください

37 UG HPS ブートローダのデバッグ 37 通信の持続時間が仕様内であるかを判断する ブート ROM 通信が時期尚早にアボートされるかを観察する 電圧レベルおよび立ち上がり時間 立ち下がり時間といったシグナル インテグリティを検証する HPS およびフラッシュ デバイスの通信を ( ロジック アナライザで ) キャプチャする 問題が解消していない状態で デバッガ接続が可能である場合はオンチップ RAM の上部 4KB の内容をアルテラが解析するようデバッガからダンプすることが可能です 関連情報 Altera Support Center サポート センターのページへのログインおよび mysupport サービス リクエスト システムへのアクセスに関する情報です HPS ブートローダのデバッグ デバッガ接続が利用できない状態で かつ HPS がフラッシュからブートしている場合はフラッシュ デバイス信号をモニタする必要があります ブート フラッシュ デバイスの問題 の項を参照してください デバッガはソース コードにアクセス可能であるため ブートローダ実行のデバッグにデバッガを使用することは最も効果的な方法です 以下の汎用的なデバッグ テクニックが使用可能です JTAG 接続を持つシステムでは ブートローダの実行をステップ スルーにはデバッガを使用します あるいは ブートローダ コードは LED や UART といったハードウェア リソースを経由 あるいは未使用のメモリ ロケーションに書き込むことでより有益なデバッグ情報を提供するよう編集することも可能です 関連情報 36 ページのブート フラッシュ デバイスの問題 ARM Infocenter ARM DS-5 を使用したブートローダのデバッグについての詳細情報です

38 38 付録 A:SD/MMC ブート デバイスを使用したブートローダの生成 UG 付録 A:SD/MMC ブート デバイスを使用したブートローダの生成 ブートローダの例 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 テキスト ボックスでブートローダ コンフィギュレーションおよび設定ファイルを指定します 図 26: 新規の BSP エディタ画面の選択

39 UG ブートローダの例 39 図 27: 新規の BSP 設定のコンフィギュレーション 4. 各項目の設定完了後 OK をクリックし main メニュー タブでソース boot_device(sd/ MMC) を指定します

40 40 ブートローダの例 図 28: BSP エディタ画面で SD/MMC デバイスからブートを選択する UG 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/ フォルダ内に生成されます 表 6: ブートローダ実行可能イメージ u-boot_w_dtb.bin ファイル uboot_w_dtb-mkpimage.bin 説明 デバイス ツリー バイナリを持つ U-boot 実行可能ファイル mkpimage ヘッダを持つ U-boot 実行可能ファイル

41 UG 付録 B:UEFI ブートローダのビルド 41 注意 : 第 2 ステージ ブートローダ ソースとして UEFI の使用を選択する場合は この段階で 付録 B:UEFI ブートローダのビルド を参照してください 7. ブート デバイス上でブートローダ イメージ U-Boot デバイス ツリー FPGA デザインを準備します 詳細は アルテラ SoC Embedded Design Suite User Guide あるいは Rocketboards サイトを参照してください 関連情報 20 ページの SD/MMC フラッシュ デバイス詳細については SD/MMC フラッシュ デバイス の項を参照してください 41 ページの付録 B:UEFI ブートローダのビルド 付録 B:UEFI ブートローダのビルド UEFI(Unified Extensible Firmware Interface) ブートローダをビルドするには UEFI ソース コードを入手し サポートされているツールチェインで UEFI ソースをコンパイルする必要があります 前提条件 UEFI ブートローダをビルドするには インストール パッケージが必要となります 使用する Linux ディストリビューションによってパッケージのインストールに使用するコマンドは異なります Ubuntu ディストリビューションを使用している場合は 以下を入力します $ sudo apt-get install uuid-dev build-essential Fedora ディストリビューションを使用している場合は 以下を入力します $ sudo yum install uuid-devel libuuid-devel 注意 : UEFI のビルドには Python パッケージが必要です Python がホストにインストールされていない場合は 以下のコマンドを入力することで SoC EDS インストレーション パスから入手することができます $ export PATH=$SocEDS_DEST_ROOT/host_tools/python/bin:$PATH hashlib.py によってエラーがレポートされる場合は 以下を入力して libssl.so をインストールします $ export LD_LIBRARY_PATH=$SOCEDS_DEST_ROOT/host_tools/python/lib/:$LD_LIBRARY_PATH/ sbin/ldconfig サポートされているコンパイラ ツールチェイン サポートされている UEFI コンパイラ ツールチェインには以下が含まれます

42 42 UEFI ソース コードの入手 Linaro: このツールチェインは SoC EDS インストレーション パッケージより利用可能です arm-linux-gnueabihf-gcc (crosstool-ng linaro Linaro GCC ) (prerelease) ARM (armcc, armlink): このツールチェインは SoC EDS DS-5 インストレーション パッケージより利用可能です UEFI ソース コードの入手 UEFI ソース コードは GitHub 内に位置しています UEFI ソース コードを入手するには以下の手順に従ってください 1. ターミナルを開きます 2. GitHub から UEFI ソース コードをチェックアウトする目的でディレクトリ パスを新しく作成します $ mkdir /data/<username>/pggit 3. この UEFI 作業ディレクトリに変更し git ツリーから UEFI ソースをクローンします $ cd /data/<username>/pggit $ git clone 4. 完了後 uefi-socfpga フォルダに変更し git チェックアウトを実行します $ cd uefi-socfpga $ git checkout t b socfpga-linaro-edk a3 origin/socfpga-linaroedk a3 $ git reset tags/rel_socfpga_arria10_beta UG Linaro ツールチェインを使用した UEFI ソース コードのコンパイル この項では Linaro ツールチェインを使用した UEFI ソース コードのコンパイル方法を解説します 1. ターミナル ウィンドウを開き 以下のコマンドを入力します $ cd /data/<username>/pggit/uefi-socfpga $ make clean 注意 : make clean は /data/<username>/pggit/uefi-socfpga/build/ フォルダをすべて消去し また BaseTools も削除します 2. 以下のコマンドを使用し Arria 10 デバイスに向けて UEFI ブートローダをコンパイルします このビルド プロセスは 3 分以内に完了します $ make 注意 : make の入力は make DEVICE=a10 COMPILER=gcc に相当します ビルド完了後 Build Done メッセージが表示されます

43 UG ARM ツールチェインを使用した UEFI ソース コードのコンパイル 43 ARM ツールチェインを使用した UEFI ソース コードのコンパイル この項では ARM ツールチェインを使用した UEFI ソース コードのコンパイル方法を解説します 1. ターミナル ウィンドウを開き 以下のコマンドを入力します $ cd /data/<username>/pggit/uefi-socfpga $ make clean 注意 : make clean は /data/<username>/pggit/uefi-socfpga/build/ フォルダをすべて消去し また BaseTools も削除します 2. UEFI ブートローダをコンパイルします $ make DEVICE=a10 COMPILER=gcc HANDOFF_DTB=a10_soc_devkit_ghrd_qspi/software/ bootloader/devicetree.dtb UEFI が生成するファイル UEFI ソース コードをコンパイルすると /data/<username>/pggit/uefi-socfpga/build/ フォルダ内に以下のファイルが作成されます 表 7: UEFI が生成するファイル ファイル 説明 ~ /uefi-socfpga/build/pei.256 (256KB) このファイルは ~/uefisocfpga/ Build/ Arria10SoCPkg/RELEASE_GCC48/FV/ ALTERA_HPS_OCRAM_EFI_ PART1.fd に位置するオリジナル ファイルにヘッダを追加することで mkpimage ツールから生成されます このファイルのサイズは 256 KB と小さいため DS-5 を使用してオンチップ RAM に直接ロードします このファイルは PEI.ROM ファイルを生成します ~ /uefi-socfpga/build/pei.rom (1MB = 256KB X 4) このファイルはフラッシュ ドーターカードにプログラムされます このファイルは ブート ROM は最大 4 個のバックアップ イメージをサポート可能なため 4 倍のサイズとなります たとえば 最初のイメージ (256KB) が破損している場合 ブート ROM は 2 番目のイメージをロードします

44 44 UEFI が生成するファイル UG ファイル ~ /uefi-socfpga/build/load_uefi_fw.ds これは DS-5 スクリプトのテンプレートです DS-5 ツールにインポートされ デバッグおよび開発用に UEFI ファームウェアをロードします このユーザはユーザのためにデバッグ シンボルをロードします 現行では GCC コンパイラのみがサポートされており ARMCC はサポートされていません ~ /uefi-socfpga/build/dxe.rom このファイルは現行では使用されておらず 将来用の予備となっています 説明

45 UG の改訂履歴 45 の改訂履歴 日付バージョン変更内容 2015 年 10 月 付録 B:UEFI ブートローダのビルド の項とサブセクション を追加 高度なブート トピック の項を削除 2015 年 6 月 別の OS ブート フロー の項を削除 一般的なブート フロー( 非セキュア ) の項に記載された 一般的な第 2 ステージ ローダのフロー ( 非セキュア ) を更新 QSPI を使用したブートローダ生成の例 の項に記載された 新しい BSP エディタ ウィンドウの選択 の図を更新 付録 A:SD/MMC ブート デバイスを使用したブートローダの生成 の項に記載された 新しい BSP エディタ ウィンドウの選択 の図を更新 ブートのデバッグ の項に以下のサブセクションを追加 2015 年 4 月 初版 コールド ブート デバッグ ウォーム ブート デバッグ ブート ROM およびブートローダ デバッグ レジスタの使用 ブート フラッシュ デバイスの問題 HPS ブートローダのデバッグ 付録 B: ブートローダ (U-Boot) デバイス ツリー リファレンス を削除