はじめに

C-9でCPU＋FPGA SoCの構造を、C-10でYoctoの地図を作りました。C-10.5前編／後編は版管理を深掘りする発展記事です。今回は本編へ戻り、AMD（旧Xilinx）Zynq-7000で「ハード設計の情報がどうLinuxに流れ込むか」 を追います。

今回扱わない範囲：Vivadoでの回路設計そのもの、HDL、タイミング制約。ハード側は「何が出力されるか」だけ扱います。またZynq UltraScale+等の上位品も流れは同様ですが、本記事は無印Zynq（7000系）ベースで説明します。

この記事の前提

Zynq-7000のPS（CPU側）とPL（FPGA側）の違いを把握している
FSBL、U-Boot、カーネル、Device Tree、rootfsの役割を大まかに把握している
コマンド例はPetaLinuxの流れを読むためのものです。オプションはリリースで変わるため、手元のVivado／PetaLinuxと同じ版の資料を優先します

手元の実機はMicroPhase MIZAR Z7のXC7Z020版です。HDMI入出力、Ethernet、SDカード、USB、GPIOが一枚に載ったZynq-7000開発ボードで、机上の構成だけを眺めているわけではありません。ただし、この記事では未実施のログや性能を足さず、私が扱ってきた世代のPetaLinuxフローと、公式資料で確認できるZynq-7000の構成に絞ります。MIZAR Z7はAMD純正の評価ボードではないため、ボード固有の制約はMicroPhaseのリファレンスマニュアルと実機で確認します。

実機の主要部品を、この記事で触る範囲へ絞ると次のようになります。XC7Z020版は16bit幅のDDR3デバイスを2個搭載して合計1GB、EthernetはRTL8211E PHYを介した10／100／1000Mbps対応です。Wi-Fi／BLEと2個目のHDMIインターフェースはXC7Z020版の機能として整理しています。

筆者作成の概念図です。ボード仕様はMicroPhaseのMIZAR-Z7リファレンスマニュアルを参照しています。メーカー掲載図の転載やトレースではなく、LinuxとFPGAを触るうえで押さえたい関係に絞って再構成しています。

このボードを選んだ楽しさの一つが、HDMIの入力と出力を両方持っていることです。PL側で映像を生成してHDMI TXから自分で出力し、その映像を外付けのHDMIキャプチャでPCへ取り込むところまで試せます。逆にHDMI RXから映像を受け、PL側で処理して出力する構成にも発展できます。GPIOのLチカだけで終わらず、入力→FPGA処理→出力→キャプチャを目で確認できるのは、Zynqを私物で触るうえで大きな魅力です。

筆者作成の概念図です。ボード仕様はMicroPhaseのリファレンスマニュアルを参照しています。

全体フロー：2つの世界と1つの受け渡しファイル

Zynq開発は「ハードの世界（Vivado）」と「ソフトの世界（PetaLinux/Yocto）」に分かれ、その間を XSAファイル が渡ります。

左側が今回扱うZynq-7000、右側が私物でも比較できるCyclone V SoCの流れです。Vivadoから出力したXSAをPetaLinux側へ取り込むZynqと、Quartusのハンドオフファイル群をBSP generatorで起動コードへ反映するCyclone Vでは、成果物名が異なります。それでも、ハード設計、ソフトへの引き渡し、起動部品の構築、起動メディアへの配置という4段階の骨格は共通しています。

C-9で「回路とDevice Treeは同時に更新」と書きましたが、Zynqフローではこの同期をXSAの再取り込みが担います。PL回路を変えたらXSAを出し直し、ソフト側に再読み込みさせる――これがZynq開発の基本リズムです。

ハード側から出てくるもの（Vivado）

ソフト屋として押さえるべき出力は2つだけです。

XSA：PSの設定、ハードウェア構成、PLに置いたIPのアドレスや割り込みなどをソフトウェアツールへ渡すためのアーカイブ。Device Treeを生成する入力の一つになる
ビットストリーム（.bit）：PLに書き込む回路データ。VivadoからXSAをエクスポートするときに同梱できる

ソフト側から見ると、Vivadoの重要な成果物がXSAです。PLを使う案件では、ビットストリームを含めるかどうかも受け渡し条件として確認します。「XSAだけ届いたが、想定していたビットストリームが入っていない」という食い違いを防ぐためです。

ソフト側：PetaLinuxの正体

PetaLinuxはAMD公式のLinuxビルドツールですが、Yocto/OpenEmbeddedとAMD向けのBSP・メタデータを、専用コマンドで扱えるようにしたベンダーフローです。C-10の相関図で言えば、

ハード依存の構成やDevice Tree生成の入力 → XSA
BSPやrecipe → AMD向けのlayer
ユーザーの操作 → petalinux-*コマンド。その内部でBitBakeが動く

という対応です。「PetaLinux＝Yoctoそのもの」ではなく、Yocto/OpenEmbeddedを土台にしたベンダーフローと位置づけるのが正確です（PetaLinuxを介さずYocto＋meta-xilinxで組む選択肢もあります）。

2026年時点の補足：AMDはVivado 2025.1と同時期に、Yocto Projectベースの AMD Embedded Development Framework（EDF） を公開しました。AMDの案内では、PetaLinuxツールとBSPはEDFに置き換えられ、段階的にEOLへ向かっています。新規製品では、デバイスの対応状況と採用するVivado版を確認したうえで選定してください。本記事の本文は、私の経験と既存資産の読解に軸を置き、従来のPetaLinuxフローを扱います。

典型的なコマンドの流れ

次はPetaLinux 2023.2系の資料でも確認できる、概念を追うための例です。実行前に、採用版のUG1144と--helpで構文を確認してください。

$ petalinux-create -t project --template zynq -n myproj   # プロジェクト作成
$ cd myproj
$ petalinux-config --get-hw-description=../hw/design.xsa  # XSA取り込み
$ petalinux-config -c kernel      # カーネル設定（必要時）
$ petalinux-config -c rootfs      # rootfsパッケージ選択（必要時）
$ petalinux-build                 # ビルド（中でBitBakeが走る）

--get-hw-descriptionはXSAファイル、またはXSAを置いたディレクトリを指定できます。取り込まれたハードウェア記述を基にDevice Treeのハード部分（pl.dtsi等）が生成されます。

自分の追記（コンソール設定、I2Cデバイス追加など）は、典型的にはproject-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsiへ書きます。版によってレシピ構成は異なるため、生成されたプロジェクト内のREADMEも確認してください。自動生成分は直接編集せず、user側の差分として残す――C-10の原則がここでも生きています。

BOOT.BINの生成にもpetalinux-package --bootを使えますが、FSBL、ビットストリーム、U-Bootの指定方法は版と構成で変わります。ここは短いコマンドを暗記するより、生成されたBIFと採用版の資料を照合する方が安全です。

ブートの構造：BOOT.BINの中身

C-5の6段階＋C-9の「PLコンフィグ」は、ZynqではBootgenが作るブートイメージへ束ねられます。次はLinux起動でよく使う構成例です。

BOOT.BINの中身	役割（C-5の段階対応）
FSBL	Boot ROMが最初に読み出すブートローダー。以降のpartitionを処理する
ビットストリーム(.bit)	PLコンフィグ。PLを使わない構成では含めない場合もある
U-Boot	次段のブートローダー。カーネルやDTBをロードする

実際に何をどの順で入れるかはBIF（Boot Image Format）で決まります。BOOT.BINが常に上の3点セットというわけではなく、用途によってpartitionは増減します。

Boot ROMは起動モードピンの設定に従い、SD、QSPI、JTAGなどの起動経路を選びます。SD起動では、ブート用FATパーティションに置いたBOOT.BINを使う構成が一般的です。以降のカーネル・rootfsはC-5〜C-8で見た世界そのものです。

ハマりどころ

ツールバージョンの三点セット：Vivado・PetaLinux・実行環境（対応Linuxディストリ）はバージョン組合せが指定されています。バラバラの版を混ぜるのは事故のもと
ディスク容量：PetaLinuxビルドもYocto／OpenEmbeddedを利用するため、構成によって数十GB以上を消費します（C-10参照）
XSA更新の反映漏れ：PL回路を変えたのにXSAを取り込み直さないと、ソフト側が古いアドレスや割り込み定義を参照して動かなくなります。C-9のハマりどころの再現です
自動生成DTSを直接編集してしまう：再取り込みで消えます。追記は必ずsystem-user.dtsiへ
FSBLレベルの不動作はシリアルとJTAGで追う：BOOT.BINが読めていないのか、FSBLまで進んだのかをC-6の基準ログと照合します。何も出ない場合は、起動モード、電源、クロック、JTAG接続まで戻って切り分けます

現場コラム：「基準になる構成で一周してから」の価値

AMDの評価ボードやBSP付きのSoMなら、ベンダーが提供する参照BSPやハードウェア記述を基準にできます。MIZAR Z7のようなサードパーティー製ボードを使う場合も、まずメーカーのリファレンスマニュアルと付属リファレンスデザインを基準にします。出所の分からない手順を継ぎ足すところから始めると、うまく動かないとき「自分の手順」と「基板固有の事情」のどちらを疑うべきか判断しにくくなるためです。

これはC-6の「基準ログ」の話と同型です。まず正常系を1周確保してから、変数を1つずつ増やす。学習でも業務でも、この順序を守るだけでハマり時間は大きく減ります。

XSAを受け取った時点で残しておくもの

ハード担当からXSAを受け取ったら、ファイルだけを共有フォルダへ置いて終わりにせず、生成に使ったVivadoの版、Gitのcommit、ビットストリームを含めたかを一緒に記録します。ソフト側で取り込んだ日付とXSAのハッシュも残しておけば、回路変更後に「どのXSAで作ったLinuxか」を追えます。地味ですが、ハードとソフトの境目で起きる取り違えにはよく効きます。

まとめと次回

Zynqフローの核心は「Vivado→XSA→PetaLinux」の受け渡し。XSAはDevice Tree生成などの入力になる
PetaLinuxはYocto／OpenEmbeddedを土台にしたAMDの開発フロー。ユーザー差分はmeta-user側へ残す
BOOT.BINの内容と順序はBIFで定義する。FSBL、ビットストリーム、U-Bootは典型例であり、固定ではない

次回は最終回C-12、Altera Cyclone V SoCの開発フローです。手元のDE0-Nano-SoCとRocketBoards／GSRDを入口に、同じ「CPU＋FPGA＋Yocto」でも受け渡しの流儀がどう違うかを見ていきます。

参考資料