プラットフォーム ソフトウェア コンポーネントの作成

概要

SDSoC™ プラットフォームのソフトウェア コンポーネントは、SDx™ IDE から直接生成できます。DSA を入力ハードウェア仕様として使用すると、Standalone、FreeRTOS、または Linux ターゲットに必要なソフトウェア ファイルが生成されるように SDx プラットフォーム プロジェクトを設定できます。Linux ターゲットの場合は、SDx IDE が PetaLinux ツールを起動して、Linux イメージと SDSoC プラットフォームを構築するのに必要なソフトウェア オブジェクト ファイルを生成します。SDx IDE で使用される DSA ファイルは、Vivado® Design Suitewrite_dsa コマンドを使用すると作成されます。

開発者は、Standalone および FreeRTOS アプリケーションの場合は ザイリンクス SDK でソフトウェアを作成し、PetaLinux ツールを使用して Linux イメージおよびアプリケーションを作成し、SDx プラットフォーム プロジェクト フローで SDSoC プラットフォームを構築します。HDF ファイルは、ソフトウェア作成ツールでハードウェア デザインを記述した入力ファイルとして使用します。Vivado で HDF ファイルを生成するには、[File] > [Export] > [Export Hardware] をクリックします。

重要: Vivado Design Suite および PetaLinux など、ツールによってコンフィギュレーション要件は違っているので、ツールは別のターミナル シェルで実行することをお勧めします。

ソフトウェア プラットフォーム データの作成プロセスでは、デバイス上で実行されるサポートされた各 OS に対して、ライブラリおよびヘッダー ファイル、ブート ファイルなどのソフトウェア コンポーネントをビルドし、コンポーネントの使用法および場所を指定するソフトウェア プラットフォーム メタデータ ファイル (.spfm) を生成します。ソフトウェア コンポーネントはプラットフォーム フォルダー <path_to_platform>/sw に含まれ、ソフトウェア プラットフォーム メタデータ ファイルは <path_to_platform>/sw/<platform>.spfm にあります。

また、すべてのソフトウェア プラットフォームに 1 つまたは複数のサンプル デザインとその使用方法も含まれます。

この章では、ソフトウェア プラットフォームに必須およびオプションのコンポーネントについて説明します。これらのコンポーネントは、プラットフォーム作成者が作成できると想定しています。たとえば、プラットフォームで Linux がサポートされる場合は、次を提供する必要があります。

  • ブート ファイル: FSBL (First Stage Boot Loader)、U-Boot、Linux FIT イメージ image.ub または個別の devicetree.dtb、カーネル、および ramdisk ファイル、BOOT.BIN ブート ファイルの作成に使用されるブート イメージ ファイル (BIF)。
  • 生成済みハードウェア ビットストリームや SDSoC データ ファイルなどのオプションのプリビルド ファイル (SDSoC でハードウェア アクセラレータなしでアプリケーションをビルド場合に時間を節約するために使用)。
  • オプションのヘッダー ファイルおよびライブラリ ファイル (プラットフォームでソフトウェア ライブラリが提供される場合)。
  • オプションのエミュレーション データ (プログラマブル ロジックおよびプロセッシング サブシステムの QEMU 用に Vivado シミュレータを使用したエミュレーション フローがプラットフォームでサポートされる場合)。

プラットフォームでザイリンクス Standalone OS (ベアメタル ボード サポート パッケージ (BSP)) がサポートされる場合、ソフトウェア コンポーネントは Linux のものと似ていますが、ブート ファイルに FSBL および BIF ファイルが含まれます。

ヒント: Zynq® UltraScale+™ MPSoC ブート ファイルには、PMUFW (Platform Management Unit FirmWare) および ATF (Arm® Trusted Firmware) の ELF ファイルも必要です。

ターゲット OS 用のソフトウェア コンポーネントをビルドしたら、SDSoC プラットフォーム プロジェクトの作成 に従って、SDSoC プラットフォーム プロジェクトでこれらのコンポーネントをプラットフォームに追加します。

SDx プラットフォーム プロジェクトの開始

この章では、SDx IDE で 2 つのプラットフォーム プロジェクトを作成して、Standalone および Linux のソフトウェア オブジェクトおよびファイルを生成する方法について説明します。1 つ目のプラットフォームは Standalone 用で、プラットフォームを作成するのに必要なファイルと使用するファイルを示します。2 つ目のプラットフォームは同じフローですが、ターゲット ハードウェアで Linux を実行するプラットフォームのケースを示します。通常、Linux および Standalone システム コンフィギュレーションは 1 つのプラットフォームに共存可能なので、別々のプラットフォーム プロジェクトにする必要はありません。

SDx IDE を起動したら、新規ワークスペース (この例の場合は sdx_workspace_gen) を定義します。このワークスペースには、SDx ツールがソフトウェア コンポーネントを生成するための 2 つのプラットフォーム プロジェクトが含まれます。ウェルカム画面か SDx メニュー バーの [File] > [New] > [SDx Platform Project] をクリックし、1 つ目のプラットフォームを Standalone をターゲットにして作成します。[New Platform Project] ダイアログ ボックスが開き、プロジェクト名を入力する画面が表示されます。この ZCU102 ベースの例では、プロジェクト名を platform_1_gen に指定します。

図: [New Platform Project] ダイアログ ボックス

[Next] をクリックし、次の画面へ進んで、プラットフォームのハードウェア仕様のソースを選択します。プラットフォームのハードウェア コンポーネントのソースとして、DSA を使用するか、既存プラットフォームを使用するかを選択します。この例の場合は DSA を選択します。

図: 新規プラットフォーム ソース - DSA

[Next] をクリックし、[Hardware Specification] に DSA ファイル名を指定します。プラットフォーム ハードウェア コンポーネントの作成の章の例で生成した DSA ファイルを使用します。この例の場合、/tmp/vivado/design_1.dsa にある生成済み DSA のコピーを使用します。

[Quick Link] セクションの [Generate Platform] をクリックします。プラットフォーム生成プロセスでは、Standalone ターゲット用のソフトウェア出力ファイルすべてを生成するのに約 10 分かかります。

Standalone

Standalone ターゲットを使用すると、ソフトウェア アプリケーションがプラットフォーム内のハードウェア デザインに完全にアクセスできます。これは、ソフトウェア アプリケーションとそのハードウェア間に保護層がないので、ベアメタルとも呼ばれます。

図: プラットフォーム ハードウェア仕様

図: プラットフォーム コンフィギュレーション設定 - Standalone

図: システム コンィギュレーション設定 - Standalone

図: ドメイン コンィギュレーション設定 - Standalone

Linux

Linux ターゲットには、多くの異なるハードウェア インターフェイスをサポートするために、マルチタスキング、仮想メモリ、およびさまざまなドライバーが提供されています。複数のソフトウェア アプリケーションは同時に実行できるか、Linux スケジューラを介して同時に実行できるように見えることがあります。

SDx IDE では Linux ターゲットに必要なソフトウェア ファイルも生成できます。次の図は、同じ sdx_workspace_gen ワークスペースに platform_2_gen という名前の新しい SDx プラットフォーム プロジェクトが含まれているところを示しています。SDx IDE は、PetaLinux ツールを起動して必要な Linux ソフトウェア オブジェクトおよびファイルを生成します。Linux プラットフォーム プロジェクトを作成する前に、SDx IDE で PetaLinux ツールへのパスを設定しておく必要があります。

PetaLinux のパスは、SDx メニュー バーから [Window] > [Preferences] > [Xilinx SDx] > [Platform Project] をクリックすると設定できます。[Apply and Close] をクリックして設定を保存します。

図: PetaLinux パス

図: プラットフォーム コンフィギュレーション設定 - Linux

図: Linux ドメイン設定

図: ソフトウェアの生成 - Linux

Linux ソフトウェア生成プロセスの一部として、libsds_lib.so 共有ライブラリを含むルート ファイル システムが /usr/lib ディレクトリに含まれます。これは、SDx[Project Explorer]<platform_name>/export/<platform_name>/sw/<system_name>/<domain_name>/sysroot から確認できます。Linux の platform_2_gen 例の場合、これは platform_2_gen/export/platform_2_gen/sw/sysconfig1/linux_domain/sysroot になります。プラットフォーム開発の際には、以前にスタティックにリンクされていたライブラリがダイナミックにリンクされるようになり、ボードで実行する Linux ファイル システムに含める必要があることに注意してください。

図: Linux ドメイン

図: System Configuration

[Quick Link] セクションの [Generate Platform] をクリックします。PetaLinux ツールが起動されます。生成されるソフトウェア出力のビルド時間は、この例の場合約 1 時間かかります。

これで、カスタムの ZCU102 DSA に基づいた 2 つの SDSoC プラットフォームが問題なく生成され、SDx ツールでそのプラットフォームに必要なソフトウェア コンポーネントが作成されました。Standalone ターゲット用のセット (platform_1_gen) と Linux ターゲット用の別のセット (platform_2_gen があります。

SDx アプリケーション (スタンドアロン) のビルド

SDx 環境には、アプリケーション コード テンプレート セットが含まれており、プラットフォームのテストやハードウェア アクセラレーション機能の確認などに使用できます。Standalone と Linux ターゲットのカスタム プラットフォームを生成するのに同じワークスペースを使用したので、2 つの SDx アプリケーション プロジェクトが追加されています。Array Partitioning テンプレートは、どちらのターゲットにも使用され、ZCU102 ボードでプラットフォームをテストするための SD カード イメージを作成します。

図: アプリケーション プロジェクト

図: プラットフォームの選択

図: System Configuration

図: Array Partitioning テンプレート アプリケーション

図: アプリケーション設定

図: Standalone のビルド - [Assistant] ビュー

Standalone アプリケーションを platform_1_gen を使用して作成したので、Linux の Array Partitioning アプリケーション プロジェクトも platform_2_gen 用に作成できます。Standalone ターゲットおよび Linux ターゲット両方用に SDx IDE で生成した SD カード イメージをブートして実行した結果は、次のようになります。

図: Linux のビルド - [Assistant] ビュー

図: アプリケーション実行の出力 - Standalone

SDx アプリケーションのビルド - Linux

図: アプリケーション実行の出力 - Linux

ハードウェアのプリビルド

プラットフォームには、オプションでプリビルド コンフィギュレーションを含めることができ、SDSoC アプリケーションでハードウェア関数を指定しない場合にこれを使用できます。これにより、ビットストリーム生成のためにプラットフォームのコンパイルおよびインプリメンテーションにかかる時間がかなり節約できます。プリビルド ビットストリームおよびその他の必要なファイルは、ハードウェアをコンフィギュレーションするために必要に応じて使用します。
ヒント: ハードウェア関数のない SDSoC アプリケーション プロジェクトは、プリビルド ハードウェアなしでもコンパイルできますが、時間がかかります。プリビルド ハードウェアを使用すると、このような場合にランタイムを削減できます。
SDSoC プラットフォーム プロジェクトを定義する場合、SDx IDE の用語集に示すように、プラットフォームに含めるプリビルド ハードウェア情報を含む [Prebuilt Data] フォルダーを指定できます。プリビルド ハードウェアは、SDSoC プラットフォーム プロジェクトを生成中に、プラットフォーム ソフトウェア ディレクトリのサブディレクトリにコピーされます。サブディレクトリのデータは、ソフトウェア プラットフォーム ファイルのメタデータ (.spfm) で指定されます。典型的な SDSoC プラットフォームのディレクトリ構造に示すように、SDSoC プラットフォームでのプリビルド ハードウェア データへのパスは次のとおりです。
<path_to_platform>/sw/prebuilt

ZCU102 プラットフォームの prebuilt フォルダーには、bitstream.bitzcu102.hdfpartitions.xmlapsys_0.xmlportinfo.c、および portinfo.h ファイルが含まれます。

SDx IDE プラットフォーム プロジェクトの [Platform configuration settings] で [Generate prebuilt data] をオンにすると、[Generate Platform] クイック リンクをクリックしたときに、プリビルド データが自動的に生成されるようになります。Vivado の合成およびインプリメンテーションはプリビルド データ ファイルの 1 つであるビットストリームを生成するために実行されるので、この生成プロセスの実行には追加で時間がかかります。プリビルド データを手動で作成した場合は、[Platform configuration settings] で [Use exisiting prebuilt data] をオンにして、手動で作成したデータ ファイルを含むディレクトリへのパスを指定します。

ライブラリ ヘッダー ファイル

#include でプラットフォーム特有のヘッダー ファイルを含めるためのアプリケーション コードがプラットフォームに必要な場合は、これらのファイルをその該当 OS のプラットフォーム ディレクトリのサブディレクトリにあるプラットフォーム ソフトウェア記述ファイルで定義する必要があります。SDSoC プラットフォーム プロジェクトを定義する場合は、ヘッダー ファイルを含む 1 つの、または複数のフォルダーへのパスを指定できます。

プラットフォーム ソフトウェア記述ファイルに <relative_include_path> と指定されている場合、ディレクトリは次のようになります。
platform/sw/os/os/relative_include_path
推奨: ヘッダー ファイルが標準のディレクトリに含まれない場合は、SDSoC 環境のコンパイル コマンドで –I オプションを使用して指定する必要があります。

スタティック ライブラリ

プラットフォームで提供されるスタティック ライブラリにリンクすることを必須とする場合は、これらをプラットフォーム ソフトウェア記述ファイルの該当する OS のプラットフォーム ディレクトリのサブディレクトリに含める必要があります。SDSoC プラットフォーム プロジェクトを定義する場合、スタティック ライブラリがプラットフォーム ソフトウェア データとして含まれるように指定できます。

プラットフォーム ソフトウェア記述ファイルに <relative_lib_path> と指定されている場合、ディレクトリは次のようになります。
<platform_root>/sw/<relative_lib_path>
推奨: スタティック ライブラリが標準ディレクトリには含まれない場合、sdscc リンク コマンドで –L オプションを使用してすべてのアプリケーションがそれらを指定するようにする必要があります。

Linux ブート ファイル

PetaLinux を使用すると、SDSoC プラットフォーム用の Linux ブート ファイルを生成できます。この方法については、『PetaLinux ツール資料: ワークフロー チュートリアル』 (UG1156) を参照してください。SDSoC プラットフォームの全体的なワークフローは同じです。次に基本的な手順を示します。PetaLinux ツールの使用に慣れている場合は、Zynq UltraScale+ MPSoC または Zynq-7000 SoC デザインに対して次の手順を問題なく実行できるはずです。

プラットフォーム開発の際には、以前にスタティックにリンクされていたライブラリがダイナミックにリンクされるようになり (libsds_lib.so)、ボードで実行する Linux ファイル システムに含める必要があることに注意してください。Linux ソフトウェア生成プロセスの一部として、libsds_lib.so 共有ライブラリを含むルート ファイル システムが /usr/lib ディレクトリに含まれます。PetaLinux ツールを手動で実行する場合は、このライブラリをルート ファイル システムの一部として含める必要があります。ライブラリは、<SDX_Install_Dir>/target/<architecture>-linux/lib に含まれます。PetaLinux でのライブラリの含有方法については、『PetaLinux ツール資料: リファレンス ガイド』 (UG1144) を参照してください。

重要:

Linux をサポートするカスタム プラットフォームには、SDSoC 制御の API 共有ライブラリを含める必要があります。共有ライブラリがプラットフォームに含まれない場合、カスタム プラットフォームをターゲットにするすべてのアプリケーションで明示的にスタティック リンキングを使用するが必要あります。スタティック リンキングは sds++ -static-sds オプションでサポートされていますが、複数ハードウェア サブシステムを競合なく開始するなど、共有ライブラリのサポートで可能な機能はありません。

開始する前に、次の手順を終了しておく必要があります。

  1. PATH 環境変数で PetaLinux ツールを含むシェル環境を設定します。
    重要: Vivado Design Suite および PetaLinux など、ツールによってコンフィギュレーション要件は違っているので、ツールは別のターミナル シェルで実行することをお勧めします。
  2. 作業ディレクトリを作成し、cd コマンドを使用してそのディレクトリに移動します。
  3. ターゲット ボードのタイプに対応する BSP をターゲットにした PetaLinux プロジェクトを作成します。
    petalinux-create –t project -n <project_name> \
    -s <path_to_base_BSP>
  4. Vivado プロジェクトからハードウェア プラットフォームのハードウェア ハンドオフ ファイル (.hdf) のコピーを取得します。
重要: このガイドは、Vivado Design Suite プロジェクトから生成された有効なハードウェア記述ファイル (HDF) があるものと想定して記述されています。詳細は、プラットフォーム ハードウェア コンポーネントの作成 を参照してください。

基本的な手順では、ハードウェア ハンドオフ ファイル、カーネル コンフィギュレーション、ルート ファイル システム コンフィギュレーションを読み込んで、Linux イメージ (.fsbl、.pmufw、.atf) をビルドします。この手順には、実行する作業と、実行する PetaLinux コマンドを引数と共に示します。ビルドが完了すると、デバイス ツリー、カーネル、および ramdisk を含む FIT イメージ ファイル (image.ub) が作業ディレクトリに含まれます。基本設定の手順では、SDSoC プラットフォームに含まれるすべてのベース プラットフォームにパッケージされている Linux イメージをコンフィギュレーションします。

petalinux-config コマンドを使用する際は、階層状のメニュー システムを含むテキスト ベースのユーザー インターフェイスが表示されます。手順では、コマンドの階層と使用する設定を示します。同じインデントの選択肢は、同じ階層レベルにあることを示しています。たとえば、petalinx-config –c kernel では、最上位メニューから [Device Drivers] を選択し、[Generic Driver Options] を選択して、その下のレベルで設定を適用し、上のレベルの [Staging drivers] に戻って、設定をそのサブメニュー項目に適用します。

PetaLinux イメージのビルド

PetaLinux イメージをビルドするには、次の手順に従います。

  1. 前に作っておいた関連するプラットフォームの HDF (作成方法は、概要を参照) を使用して PetaLinux を設定します。
    petalinux-config -p <petalinux_project> \
    --get-hw-description=<HDF path>
    デフォルトのコマンドの最後に quiet を含めるようにブート引数 (bootargs) を変更します (オプション)。
    • [Kernel Bootargs] → [Generate boot args automatically] (オフ)
    • Zynq MPSoC の場合: [Kernel Bootargs] → ユーザーがカーネル bootargs を設定 (earlycon clk_ignore_unused quiet)
    • Zynq-7000 の場合: [Kernel Bootargs] → ユーザーがカーネル bootargs を設定 (console=ttyPS0,115200 earlyprintk quiet)
  2. PetaLinux カーネルを設定します。
    petalinux-config -p <petalinux_project> \
    -c kernel
    CMA のサイズをより大きく設定します。SDS-alloc バッファーの場合は次のように設定します。
    • Zynq UltraScale+ MPSoC の場合: [Device Drivers] → [Generic Driver Options] → [Size in Mega Bytes(1024)]
    • Zynq-7000 SoC の場合: [Device Drivers] → [Generic Driver Options] → [Size in Mega Bytes(256)]
    ステージング ドライバーをイネーブルにします。
    • [Device Drivers] → [Staging drivers] (オン)
    APF マネージメント ドライバーをイネーブルにします。
    • [Device Drivers] → [Staging drivers] → [Xilinx APF Accelerator driver] (オン)
    APF DMA ドライバーをイネーブルにします。
    • [Device Drivers] → [Staging drivers] → [Xilinx APF Accelerator driver] → [Xilinx APF DMA engines support] (オン)
    注記:

    Zynq UltraScale+ MPSoC の場合は、CPU アイドルと周波数スケーリングをオフにする必要があります。これには、次のようにオプションを指定します。

    • [CPU Power Management] > [CPU idle] > [CPU idle PM support] (オフ)
    • [CPU Power Management] > [CPU Frequency scaling] > [CPU Frequency scaling] (オフ)
  3. PetaLinux rootfs を設定します。
    petalinux-config -p <petalinux_project> \
    -c rootfs
    stdc++ libs を追加します。
    • [Filesystem Packages] → [misc] → [gcc-runtime] → [libstdc++] (オン)
  4. APF ドライバーのデバイス ツリー部分を追加します。<>/project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi の一番下に、次を追加します。
    /{
     xlnk {
     compatible = "xlnx,xlnk-1.0";
     };
    };
  5. PetaLinux イメージをビルドします。
    • petalinux-build

SDSoC プラットフォーム ユーティリティのイメージの準備

<petalinux_project>/images/linux/ ディレクトリには、重要なファイルが多くあり、2 つのカテゴリに分類されています。
  1. BOOT.BIN にコンパイルされるファイルで、まとめてブート ファイルと呼ばれ、boot フォルダーにコピーされるファイル。ブート ファイルには、u-boot.elfzynq-fsbl.elf、または zynqmp-fsbl.elf が含まれるほか、Zynq UltraScale+ デバイスの場合は bl31.elf および pmufw.elf も含まれます。
  2. SD カードに存在している必要のあるファイルですが、BOOT.BIN にはコンパイルされず、まとめてイメージ ファイルとよばれ、image フォルダーにコピーされるファイル。PetaLinux ビルドからのイメージ ファイルは image.ub だけですが、その他のファイルも image フォルダーに追加しておくと、プラットフォームのユーザーが使用できるようになります。
<petalinux_project>/images/linux/ フォルダー内から次のコマンドを実行します。
$ mkdir ./boot
$ mkdir ./image
$ cp u-boot.elf ./boot/u-boot.elf
$ cp *fsbl.elf ./boot/fsbl.elf
$ cp bl31.elf ./boot/bl31.elf
$ cp linux/pmufw.elf ./boot/pmufw.elf
$ cp image.ub ./image/image.ub
ヒント: bl31.elf および pmufw.elf ファイルは、Zynq UltraScale+ デバイスにのみ必要です。

最後にブート イメージ フォーマット (BIF ファイル) を作成します。このファイルは boot フォルダーの内容を BOOT.BIN ファイルにコンパイルするのに使用されます。ターゲット プロセッサの BIF ファイルの作成については、『Zynq-7000 SoC ソフトウェア開発者向けガイド』 (UG821) または『Zynq UltraScale+ MPSoC ソフトウェア開発者向けガイド』 (UG1137) を参照してください。

SDSoC ブート イメージ フォーマット ファイルは標準 BIF ファイルと類似していますが、ブート ファイルへのパスが直接パスの代わりに、かっこ (< >) で指定されたトークンが使用されます。BIF ファイル トークンは、SDSoC コンパイル時に実際のファイルと生成された内容に置き換わります。これは、プログラマブル ロジック (PL) 領域のビットストリーム ファイルが手続き型で生成されるためと、一部のエレメントに BIF ファイルの生成時にわかっているファイル名がないためです。

次は、Zynq-7000 SoCboot.bif ファイルの例です。
/* linux */
 the_ROM_image:
 {
   [bootloader]<fsbl.elf>
   <bitstream> 
   <u-boot.elf>
 }
次は、Zynq UltraScale+ MPSoC の BIF の例です。
the_ROM_image:
{
  [fsbl_config] a53_x64
  [bootloader]<fsbl.elf>
  [pmufw_image]<pmufw.elf>
  [destination_device=pl] <bitstream>
  [destination_cpu=a53-0, exception_level=el-3, trustzone] <bl31.elf>
  [destination_cpu=a53-0, exception_level=el-2] <u-boot.elf>
}

boot ディレクトリ、image ディレクトリ、BIF ファイルなどがまとめられ、SDSoC プラットフォーム プロジェクトへの Linux OS の入力として必要とされるソフトウェア エレメントになります。詳細は、SDx IDE の用語集 を参照してください。

スタンドアロン ブート ファイル

OS が不要な場合は、生成された実行ファイルを実行するスタンドアロン ブート イメージ (boot.bin) と必要なブートローダーを作成できます。

ヒント: Linux OS のブート イメージを既に設定済みの場合は、スタンドアロン ブート イメージ フォーマット ファイルを作成する際に、これらと同じファイルを使用できます。

FSBL (First Stage Boot Loader)

FSBL (First Stage Boot Loader) は、ブート時にビットストリームを読み込んで Zynq および Zynq UltraScale++アーキテクチャのプロセッシング システム (PS) をコンフィギュレーションします。

Vivado Design Suite でプラットフォーム ハードウェア デザインを開き、[File] > [Export] > [Export Hardware] をクリックします。

SDx IDE またはザイリンクス ソフトウェア開発キット (SDK) で、[File] > [New] > [Application Project] をクリックし、名前を fsbl に指定して新しいアプリケーション プロジェクトを作成します。

エクスポートされたハードウェア プラットフォームを使用して、リストから Zynq FSBL アプリケーションを選択します。これで、FSBL 実行ファイルが作成されます。詳細は、SDK ヘルプを参照してください。

FSBL を生成したら、SDx 環境フローの標準ディレクトリにコピーしたり、プラットフォーム プロジェクトを構築するプロセスの一部として使用したりできます。

例:
samples/platforms/zcu102_axis_io/sw/a53_standalone/boot/fsbl.elf

ボード イメージ フォーマット (BIF) ファイル

SDx 環境でブート イメージに含まれる実行ファイル (ELF) が使用されるようにするには、BIT ファイルで指定する必要があります。次は、Zynq-7000 SoC のスタンドアロン boot.bif ファイルの例です。
/* standalone */
the_ROM_image:
 {
   [bootloader]<fsbl.elf>
   <bitstream>
   <elf>
 }

SDx 環境では、BIF ファイルの <bitstream> および <elf> トークンが SDSoC コンパイル プロセス中に生成された実際のビットストリームおよび ELF ファイル リファレンスと置き換えられます。

ヒント: Zynq UltraScale+ MPSoC デバイスの BIF ファイルは Zynq-7000 SoC の BIF ファイルとは異なり、pmufw.elf が追加で必要です。このファイルは、psu_pmu_0 プロセッサをターゲットにするサンプルとして SDK または SDx IDE で生成できます。

FreeRTOS コンフィギュレーション/バージョン変更

FreeRTOS の SDx サポートは、ザイリンクス SDK (ソフトウェア開発キット) に含まれるインプリメンテーションに基づいています。デフォルトでは、FreeRTOS v10 がサポートされています。SDK では、これは最新の freertos10_xilinx BSP ライブラリに該当します。

重要: 生成された SDx プラットフォーム ファイル (.spfm) には、プロセッサ グループに OS 名 (sdx:os/sdx:osname) を指定するメタデータが含まれます。osname が freertos として指定されると、それが最新バージョンの freertos10_xilinx にマップされます。OS 名を "freertos10_xilinx" として指定した場合、その指定したバージョンが使用されます。
FreeRTOS コンフィギュレーション設定を変更する場合、ザイリンクス SDK を使用するように SDx をプラットフォーム DSA と一緒に使用すると、サポートされる FreeRTOS BSP を作成してカスタマイズできます。
  1. プラットフォーム プロジェクトを作成するために SDx IDE を使用する場合、SDK BSP からのインクルード ファイルをプラットフォームにライブラリ インクルード ファイルとして追加します (ユーザーがライブラリ インクルード パスを定義)。
  2. SDK BSP から .mss ファイルをプラットフォームに BSP コンフィギュレーション ファイルとして追加します。リンカー スクリプトは、SDK で BSP を使用してサンプル アプリケーションを作成すると生成できます。
  3. SDx プラットフォームにリンカー スクリプトを追加する場合、SDK のデフォルト値では通常の SDx アプリケーションには小さすぎるため、スタックおよびヒープ サイズを増加する必要があります。
  4. FreeRTOS アプリケーションを作成する際は、configMINIMAL_STACK_SIZE から xTaskCreate に渡されるタスク ヒープ サイズも増加する必要があります。
    ヒント: これはアプリケーションによって異なりますが、まずは 1000 から試してみて、上下に値を調整することをお勧めします。

別の FreeRTOS バージョンを使用したり、ザイリンクス BSP インプリメンテーションとは異なる方法でカスタマイズする場合は、標準 BSP のシステム コンフィギュレーションを定義して、FreeRTOS インプリメンテーションをライブラリとして追加できます。この場合、ファイルおよびリンカー スクリプトも含めて FreeRTOS ライブラリを提供する必要があります。