0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Altera Cyclone V SoCのLinux開発フロー ― RocketBoardsからYoctoを読む【組み込みLinuxの仕組み C-12】

0
Posted at

はじめに

Cシリーズ最終回です。C-11のAMD Zynqに続き、今回は Altera Cyclone V SoC で「ハード設計の情報が、ブートローダーとYoctoへどう渡るか」を追います。

Arria 10 SoCは業務で評価した経験がありますが、個人で気軽に用意するには上位クラスです。そこで本記事の主役は、私物として所有している Cyclone V SoC搭載のDE0-Nano-SoC にします。机上のフローではなく、個人でも実機を横に置いて追える範囲から始めます。

もう1枚のCyclone 10 LP FPGA Evaluation Kitは、CPUを内蔵しないFPGAボードです。名前に同じCycloneが付いていても、こちら単体では本記事のようなHPS上のLinuxは動きません。この違いはC-9で整理した「CPU搭載FPGA SoCか、CPUを持たないFPGAか」そのものです。

個人所有のDE0-Nano-SoC(左)とCyclone 10 LP FPGA Evaluation Kit(右)

今回扱わない範囲:QuartusでのHDL設計、タイミング収束、Nios等のソフトコア、Arria 10のEarly I/O Release、Agilex世代のSDM/ATFブート。本記事はCyclone V SoCのHPS+FPGAと、GSRD/Yoctoの関係に絞ります。

先に結論

Cyclone V SoCでLinuxを理解する近道は、断片的なコマンドを集めることではありません。

  1. Quartus/Platform Designerから何が渡されるかを押さえる
  2. Boot ROM → PreloaderまたはU-Boot SPL → U-Boot → Linuxの順に追う
  3. RocketBoardsのGSRDリリースを基準に、Quartus・U-Boot・Linux・Yocto layerの版を一組で読む

特に3番目が重要です。私が業務で覚えた「ベンダーが確認した版の組を崩さない」という見方を、個人所有のCyclone V SoCへ持ち込むとき、RocketBoards周辺の資料が索引になります。単なるサンプル置き場ではなく、C-10で作ったYoctoの地図を、実在するリポジトリと成果物へ対応させる入口です。

Cyclone V SoCで見る2つの世界

Cyclone V SoCは、Arm Cortex-A9を含む HPS(Hard Processor System) とFPGAファブリックを1チップに持ちます。開発は大きく2つの世界に分かれます。

世界 主な道具 決めること
ハード側 Quartus Prime/Platform Designer HPSのDDR・クロック・pinmux、使用ペリフェラル、HPS―FPGAブリッジ、FPGA回路
ソフト側 U-Boot、Linux、Device Tree、Yocto/GSRD HPS初期化、FPGAコンフィグの時期、ドライバ、rootfs、アプリ

AMD ZynqでXSAが橋渡し役だったように、Cyclone Vでもハード設計の情報をソフト側へ渡します。ただしCyclone Vでは、単一ファイルを渡して終わりではなく、Quartusが出力する ハンドオフファイル群をブートローダー向けのソースへ変換する流れです。

Quartusからソフト側へ渡るもの

Platform Designerでは、HPSのピン、クロック、SDRAM、周辺機能、FPGA側との接続を設定します。ソフト側から見て重要な出力は、次の2系統です。

  • HPSハンドオフ情報hps_isw_handoff以下に出力される設定群。Cyclone V用BSP generatorが処理し、U-Boot SPL/PreloaderがHPSを初期化するためのソースへ反映する
  • FPGAコンフィグデータ:Quartusの.sofを用途に応じて.rbf等へ変換し、U-BootまたはLinuxからFPGAファブリックへ書き込む

ハンドオフが主に扱うのは、DDR、クロック、pinmuxなど「HPSを起動するための設定」です。一方、FPGA側IPのアドレスや割り込みをLinuxドライバへ知らせるのはDevice Treeです。回路を変更したときは、ブートローダー向けハンドオフとLinux向けDevice Treeの両方が古くなっていないかを確認します。

DE0-Nano-SoCでも原理は同じですが、Altera公式GSRDの対象ボードとDE0-Nano-SoCでは、DDR、ピン、周辺回路、Device Treeが異なります。公式開発キット向け成果物をそのまま書けば動く、とは考えず、Terasicのリファレンスデザインを個人ボード側の正常系として使います。

RocketBoardsは「対応版の索引」として読む

RocketBoardsが重要なのは、Linuxイメージをダウンロードできるからだけではありません。あるリリースで一緒に検証された部品の組み合わせが見えるからです。

現在は、手順書本体がAltera FPGA Developer Siteの版付きGSRDガイド、ビルド済み成果物がreleases.rocketboards.org、版の対応表がGSRDのリリースページ、実際のつまずきがRocketBoards Forumという形に分かれています。古いRocketBoards Wikiの記事も検索で出てくるため、ページの日付と対象Quartus版を必ず確認します。

見る場所 何が分かるか 読み方
GSRD User Guide ハード生成、ハンドオフ処理、Yocto設定、ビルド、起動確認の一周 まず全体の順序をつかむ
GSRD releases Quartus、GHRD、U-Boot、Linux、Poky、各layerのbranch/tag ここを版管理の正にする
releases.rocketboards.org SDイメージ、SPL+U-Boot、kernel、DTB、rootfs等の正常系成果物 自作物との比較材料にする
RocketBoards Forum 版固有の不具合、手順の不足、回避策 公式手順と対象版を照合して使う

C-10の登場人物をGSRDへ対応させる

Cyclone VのGSRDを開くと、C-10で説明したlayerやrecipeが具体名で現れます。

C-10の概念 Cyclone V GSRDで見るもの
参照ビルド基盤 Poky/OpenEmbedded-Core、BitBake
追加Software layer meta-openembedded内のmeta-oe、meta-networking、meta-python等
BSP layer meta-intel-fpga
GSRD固有のimage・アプリ meta-intel-fpga-refdes
machine cyclone5系の定義
ブートローダー u-boot-socfpga
カーネル linux-socfpga

Alteraへブランドが戻った後も、Cyclone V向けの既存リポジトリにはintel-fpgaという名前が残っています。これは誤記ではなく、既存資産の名称です。記事やスクリプトで勝手にalteraへ読み替えない方が安全です。

GSRDのスクリプトではbitbake_imagepackageといったラッパーを使う場合がありますが、その中にあるのはOpenEmbeddedのビルドです。実際の作業ディレクトリ、tmp/deploy/images/<machine>、recipe、layerを確認すると、C-10の地図と接続できます。

Yoctoを学ぶ順序

いきなり自分のlayerを書き始めるより、次の順序が理解しやすいです。

  1. 対象リリースを1つ決め、GSRDのビルド済みSDイメージと成果物一覧を見る
  2. u-boot-with-spl.sfp、kernel、DTB、rootfsがSDカードのどこで使われるか対応付ける
  3. 同じリリース表に載ったbranch/tagでGSRDを再ビルドする
  4. tmp/deploy/images/cyclone5と配布済み成果物を比較する
  5. 最後に自社/自分のlayerでアプリや設定を追加する

これなら、「Yoctoが難しい」の中身を、ハード依存、ブートローダー、カーネル、rootfsのどこで詰まったのかに分解できます。

Cyclone V SoCのブートシーケンス

Cyclone V SoCでHPSがLinuxを起動するまでのブートシーケンス

図はSD/QSPI等からHPSを先に起動する典型例です。Cyclone Vには複数のブート方式があり、FPGAファブリックのコンフィグもU-BootまたはLinuxから行えます。そのため、FPGAの書き込み時期を固定の1経路として描かず、構成で選ぶ処理として分けています。

各段階の役割は次のとおりです。

  1. HPS Boot ROM:ブートピンに従ってSD/MMC、QSPI、NAND、FPGA等から次段を探す
  2. Preloader/U-Boot SPL:On-Chip RAM上で動作し、ハンドオフ由来の設定を使ってクロック、pinmux、SDRAM等を初期化する
  3. U-Boot本体:kernel、DTBをロードし、構成によってFPGAの.rbfも書き込む
  4. Linuxカーネル+DTB:ドライバを初期化し、rootfsをマウントする
  5. init/systemdとアプリ:製品としてのユーザー空間を起動する

近年のGSRDでは、SPLとU-Bootをまとめたu-boot-with-spl.sfpが配布成果物に含まれます。古い資料ではPreloaderという呼び方やpreloader-mkpimage.binが出てくるため、名前だけで同じ手順だと思わず、採用リリースのGSRDガイドを優先してください。

Arria 10の経験をどう生かすか

Arria 10で得た「DDR設定はどこで決まるか」「ハード変更がブートローダーとDevice Treeのどこへ波及するか」という見方は、Cyclone Vでもそのまま使えます。ただし、成果物とブート方式まで同じではありません。

観点 Cyclone V SoC Arria 10 SoC
本記事での位置付け 個人所有機で構造を追う主役 業務経験のある上位機。比較対象
ハンドオフ XML・バイナリ・ソース等の組を処理 単一XMLからブートローダー用Device Treeへ変換する世代
FPGAコンフィグ HPS起動と別に扱える方式がある Early I/O Releaseのperiph/core分割が登場する
注意点 古いPreloader資料と新しいSPL手順を混ぜない periph/coreの順序を混ぜない

Arria 10固有のperiph/core分割をCyclone Vへ持ち込まないことが大切です。共通化するのは「見るべき場所」であって、生成物の名前や手順ではありません。

ハマりどころ

  • 公式GSRDの対象ボードと手元のDE0-Nano-SoCを混同する:SoCが同じ系列でもDDR、pinmux、周辺回路、DTBはボード固有です
  • GSRDのbranchを個別に最新版へ上げる:Poky、meta-openembedded、meta-intel-fpga、refdes、U-Boot、Linuxはリリース表の組み合わせで揃えます
  • Quartusだけ更新してハンドオフを使い回す:ハード設計とSPL/Preloaderの初期化情報がずれます
  • FPGAをいつ書くか決めない:U-Bootで書くのかLinuxで書くのか、ブリッジをいつ有効化するのかを設計として決めます
  • 古いRocketBoards Wikiのコマンドをそのまま使う:Preloader生成方法や成果物名は世代・リリースで変わっています
  • 自動生成物を直接直す:再生成で消えます。製品差分は自分のlayer、recipe、Device Tree差分として残します

現場コラム:正常系は「ログ」だけでなく「部品表」も残す

GSRDで一度起動できたら、シリアルログだけでなく、使ったGSRDリリース、Quartus版、GHRDのtag、U-BootとLinuxのcommit、Pokyと各layerのbranchを一緒に残します。さらに、SDカードへ書いたイメージのハッシュも記録します。

これがC-10.5前編で扱った製品マニフェストの、もっと下側にある基盤部品の台帳です。不具合がアプリなのか、kernelなのか、FPGA回路なのかを追うには、全レイヤーの版がつながっていなければなりません。RocketBoardsのリリース表は、その台帳を作る最初のひな型になります。

まとめとシリーズの締め

  • 個人でAltera SoC FPGAのLinuxを追うなら、Cyclone V SoCとDE0-Nano-SoCが現実的な入口になる
  • Cyclone Vでは、Quartusのハンドオフ情報をSPL/Preloaderへ反映し、Device TreeとFPGAコンフィグをLinuxの構成へつなぐ
  • RocketBoards/GSRDは、Quartus、U-Boot、Linux、Poky、BSP layerの対応版を一組で読むための重要な索引
  • Arria 10の経験は設計上の観点として生かし、periph/core分割などの世代固有手順はCyclone Vへ混ぜない

全12回にC-10.5前編後編を加えた全14記事で、Raspberry Piの入口からFPGA SoCとYoctoまで歩いてきました。最後に残したいのは、特定コマンドの暗記ではありません。ハード設計、ハンドオフ、ブートローダー、Device Tree、Yocto layer、成果物の版を一本の線で結んで追う習慣です。

シリーズ目次

  1. 組み込みLinuxとは何者か ― PC・マイコン・SBCの間を整理する
  2. Raspberry Piはなぜ学習の入口に向くのか
  3. NanoPi・Banana Pi・Orange Pi ― 用途特化SBCの選び方
  4. SBCから製品へ ― SoM・COM・キャリアボードという考え方
  5. 電源ONからアプリまで ― 組み込みLinuxのブート全体像
  6. シリアルコンソールでブートログを読む
  7. Device Treeは何をしているのか
  8. rootfsと自動起動 ― アプリを「製品として動かす」
  9. CPU+FPGA SoCとは何か ― プロセッサ側とロジック側の境界
  10. Yocto Projectの地図 ― 何を作っているのか
  11. AMD Zynq-7000のLinux開発フロー ― ハード設計からPetaLinux/Yoctoへ
  12. Altera Cyclone V SoCのLinux開発フロー ― RocketBoardsからYoctoを読む(← 本記事)

参考資料

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?