組込みLinux（Yocto）のOSポーティングとは ― 手順・注意点と、外部委託を検討する際のポイント
組込みLinuxのOSポーティングは、「ブートローダ・カーネル・rootfs」をボードに合わせて作り込み、再現性のある形で継続更新できる状態まで整える作業です。
一方で、実際に取り組むと、Yocto・Poky・OpenEmbeddedの関係が分からず何から手を付ければよいか迷う、BSPの制約やデバイスツリー・ファームウェアの落とし穴、カーネル移行の互換性問題など、経験がないと見えないつまずきポイントが数多くあります。
本記事では、Yoctoで何を作るのかという全体像と進め方を整理した上で、つまずきやすい注意点と、自社対応と外部委託をどう切り分けるかの判断ポイントまでを解説します。「新しいボードでLinuxを立ち上げたい」「Yocto・Poky・OpenEmbeddedの関係を整理したい」「社内にYocto経験者が少なく不安がある」という組込みエンジニアの方に向けた内容です。
医療機器開発支援のお問い合わせはこちら
要求レベルの高い医療機器の開発を、ソフトウェアとハードウェアの両面からワンストップで支援
目次
Yocto・Poky・OpenEmbeddedの関係を先に整理する
Yoctoに触れ始めるときに最初につまずきやすいのが、関連する用語が多く、どれが何を指すのか分かりにくい点です。全体像を先に押さえておきます。
用語位置づけYocto Project組込み向けLinuxディストリビューションを再現可能に生成するための、プロジェクト全体の総称PokyYocto Projectの参照実装。BitBakeや基本レイヤー群を含む、ビルド環境の出発点OpenEmbeddedレシピとメタデータの基盤。パッケージのビルドルールと依存関係を提供する母体プロジェクトBitBakeレシピを解釈してビルドを実行するタスクエンジンレイヤー機能やベンダー差分を重ね合わせる管理単位（BSPレイヤー、自社レイヤーなど）
つまり「Yocto Projectという活動体が、Pokyという出発点を提供し、OpenEmbeddedのレシピ資産をBitBakeで実行し、レイヤーという単位で差分を積み重ねる」という関係です。この全体像さえつかめれば、以降の解説がつながりやすくなります。
OSポーティングの全体像（Yoctoで何を作るか）
YoctoでのOSポーティングの成果物は、主にブートローダ、Linuxカーネル、デバイスツリー、rootfs（必要に応じて初期RAMディスクや更新用イメージ）です。ボード固有の差分は、ブート媒体やDRAM設定のような超初期の領域から、周辺I/Oのドライバ、有線無線のファームウェア、ユーザー空間の設定まで連続しています。まず「どこまでをYoctoの成果物として管理するか」を決めることで、作業境界がぶれなくなります。
工程は、要件を固めてLTSや運用年数を決める、ベンダーBSPレイヤーを導入して最小イメージをビルドする、シリアル出力を確保してブートチェーンを段階的に起動させる、周辺機能を追加して製品要件まで積み上げる、という流れが王道です。Yoctoは運用フェーズで真価を発揮するため、「起動すること」だけでなく「更新と再現性」までを最初から意識して進める必要があります。
組込みLinuxとYocto Projectの基礎
Yoctoはディストリビューションそのものではなく、組込み向けLinuxディストリビューションを再現可能に生成するための枠組みです。
PCであればUbuntuやDebianといったできあがったLinuxをインストールすれば動きますが、組込み機器はCPU・メモリ・搭載機能が製品ごとに異なり、リソースも限られています。そのため「その機器に必要な部品だけを組み込んだ専用のLinuxを、ソースとメタデータから生成する」というアプローチが必要になり、その生成を担うのがYoctoです。同じ入力（リポジトリと設定）から何度でも同じOSを作れることが、長期運用時のセキュリティ更新や複数機種展開での差分管理の基盤になります。
レイヤーは、機能やベンダー差分を重ね合わせる単位です。ベンダーBSPレイヤーがSoC向けのカーネルやブートローダを提供し、自社レイヤーで製品固有のアプリケーションや設定を載せます。重要なのは、上流レイヤーを直接改変せず、自社レイヤーで上書き・追記を行うことです。これにより、YoctoやBSPの更新が入っても差分を追跡できます。逆に言えば、レイヤー設計を誤ると更新のたびに構成が破綻する、というのがYoctoの難しさでもあります。
Yoctoを使うメリットと他の選択肢との違い
Yoctoの最大のメリットは、製品に最適化したOSを作りつつ、その「作り方」をレイヤーと設定として残せることです。ボードが増えても共通部分は再利用でき、機種差分はMACHINEや専用レイヤーに閉じ込められます。クロス開発用SDKの生成も標準機能です。
OSの選択肢としては、大きく3つに整理できます。UbuntuやDebianのような汎用ディストリビューションは導入が速い一方、組込みに合わせた最小化やボード固有のブートチェーン統合に工夫が必要です。Buildrootは短期間で小さなrootfsを作るのに適しますが、パッケージ管理・更新・複数機種展開をプロジェクト側で補う場面が増えます。そして、Wind River LinuxやTimesysなど、ベンダーが商用サポート付きで提供する商用ディストリビューションという選択肢もあります。商用ディストリビューションは、サポート窓口やセキュリティパッチの提供が受けられる安心感がある一方、ライセンス費用が発生し、カスタマイズの自由度はYocto自前構築より制限される傾向があります。
要件が小さく短期立ち上げを優先するならBuildroot、サポート体制を重視し費用をかけられるなら商用ディストリビューション、長期運用と拡張性を含めた製品基盤を自社の資産として持ちたいならYocto、という整理が実務的な判断軸になります。
当社の医療機器開発支援の詳細はこちら
要求レベルの高い医療機器の企画・要件定義から製品化、市場参入までワンストップで支援
ポーティング前に決める要件（SoC・ボード・機能・ライフサイクル）
ポーティングの難易度と後戻りコストは、初期要件の決め方でほぼ決まります。
まず、ボードの起動方式、ブート媒体、ストレージ・メモリ容量、搭載周辺（Ethernet、Wi-Fi、USB、カメラ、表示など）を洗い出し、「起動に必要な最小機能」と「製品として必須の周辺」を分けてスコープを切ります。全機能の同時立ち上げは失敗のもとです。
次に、運用年数と更新方法を決めます。フィールドアップデートの有無、OTAを行う場合のA/B更新・ロールバック・署名検証の要否によって、イメージ形式やパーティション設計まで変わります。
最後に、ベンダーBSPの対応範囲と制約を確認します。BSPは特定のカーネル系列に固定されていることが多く、後からカーネルを上げると周辺ドライバやGPUスタックが追従できない場合があります。要件は理想論ではなく、BSPが現実的に支えるラインに合わせ、自社で維持する範囲を明確にすることが重要です。
長期サポートカーネル（LTS）選定の考え方
製品の運用年数とセキュリティ更新の提供期間を決め、その期間に合うLTS系列を候補にします。重要なのはカーネル自体のEOLだけでなく、ベンダーBSPがどの系列に追従しているかです。BSPが追従しない系列を選ぶと、GPU・無線・カメラなどの周辺で自社保守が増え、コストが跳ね上がります。
運用方針は「LTS固定でバックポートする」か「定期的に系列を上げて追従する」かの二択が基本です。前者は動作安定に有利ですがCVE対応の品質が問われ、後者は上流の修正を取り込みやすい反面、互換性確認の工数を製品スケジュールに組み込む必要があります。
リアルタイム要件とPREEMPT_RTの適用判断
リアルタイム要件は、許容レイテンシとジッタを数値で定義することが出発点です。これが曖昧なままPREEMPT_RTを導入すると、改善したかどうかの判断すらできず、検証が長期化します。
PREEMPT_RTはカーネル内のプリエンプションを強化し遅延を抑えるのに有効ですが、ベンダー独自ドライバやGPUスタックとの互換性問題、スループット低下などの副作用が出ることがあります。まずユーザー空間の優先度設定やIRQのピニング、I/Oパスの見直しで要件を満たせるかを確認し、それでも足りない場合にPREEMPT_RTを検討するのが堅実です。
ポーティングの進め方（BSP導入 → 最小起動 → 機能拡張）
実際の作業は、ブートローダからカーネル、rootfsへと段階的に成功条件を積み上げていきます。ここでは流れの要点だけを整理します。
BSP導入とボード立ち上げの要点
最初にシリアルコンソールを必ず確保し、ブートローダのログが見える状態を作ります。観測点がないと、起動しない原因がDRAM設定なのか、カーネル起動引数なのか、rootfsマウントなのかが切り分けられず、試行錯誤が指数的に増えます。
ベンダーBSPのサンプル構成をできるだけそのまま使い、core-image-minimalなどの最小イメージで起動確認するのが最短ルートです。ここで自社の理想構成に寄せると、BSPが保証している前提を崩してしまいます。起動が確認できてから、自社ボードへの派生・機能追加へ進みます。自社ボード対応では、既存MACHINEを直接編集せず、自社レイヤーにMACHINE派生を作って差分だけを追加する形が安全です。
イメージ作成とレシピカスタマイズ
BitBakeでイメージをビルドし、ボードに合った方式（ネットワークブート、SD/eMMC書き込みなど）で配置します。立ち上げ初期は書き換えが速い方式で原因を絞り、安定してから量産想定の配置へ移行すると無駄が減ります。
自社アプリケーションや設定の追加は、自社レイヤー内のレシピに落とし込み、手作業の変更を残さないことが原則です。既存パッケージの変更はbbappendで追記します。製品仕様がlocal.confに散らばると再現性が壊れるため、local.confはビルド高速化やデバッグ用に限定するルール化が有効です。
起動確認とデバッグ
デバッグはブート段階ごとに分けます。ブートローダ段階で止まる場合は電源・クロック・DDR設定などハードウェア寄りの原因が多く、カーネル段階のpanicはroot=指定の間違い、DTB不一致、ストレージドライバ未有効化が典型です。ユーザー空間ではinit/systemdの失敗や権限問題が中心になります。
重要なのは、実機で手作業で直した変更を必ずレシピや設定へ戻すことです。これを怠ると「直ったように見えて次のビルドで再発する」状態に陥ります。
当社の医療機器開発支援の詳細はこちら
要求レベルの高い医療機器の企画・要件定義から製品化、市場参入までワンストップで支援
OSポーティングでつまずきやすい注意点
ここまでの手順は、書籍やベンダードキュメントにも記載があります。しかし実際のプロジェクトで工数が膨らむのは、以下のような「経験しないと見えない」ポイントです。
デバイスツリー・ドライバ・ファームウェアの落とし穴
「ビルドは通ったのにボードで動かない」というケースの多くは、ハードウェア依存の設定不足です。デバイスツリーの記述ミス、クロック・リセット・電源レギュレータの設定不足、ピン設定、割り込み番号の不一致が典型で、切り分けにはハードウェアの理解が不可欠です。
特に見落としやすいのがファームウェアです。Wi-Fi/BT、GPU、VPU、カメラなどはファームウェアがないと初期化できません。プロプライエタリなファームウェアの場合、取得手段や再配布可否がライセンス・調達の問題に直結するため、技術以外の観点でも早期の整理が必要です。
カーネルバージョン移行で起きる互換性問題
既存製品のカーネルを新しい系列へ移行する作業は、新規立ち上げとは別種の難しさがあります。カーネル内部APIの変更にベンダードライバや自社ドライバが追従できない、デバイスツリーのバインディング仕様が変わっている、ユーザー空間とのインターフェースが非互換になっている、といった問題が同時多発的に起きるためです。
BSPが新系列に対応していない場合、この追従作業をすべて自社で担うことになります。移行の影響範囲を事前に見積もれるかどうかが、プロジェクトの成否を分けます。
長期保守・セキュリティ更新の運用負荷
ポーティングは「起動して終わり」ではありません。再現性のためにYoctoのブランチ・各レイヤのリビジョン・ソース取得先を固定し、誰がビルドしても同じ成果物が出る状態を維持する必要があります。
SBOM（ソフトウェア部品表）の整備と脆弱性対応も、近年は事実上の必須要件です。カーネル、BusyBox、OpenSSLなどの基盤部品はCVEの頻度が高く、監視、影響判定、取り込み、検証、リリースまでの運用フローを製品ライフサイクル全体にわたって回し続けることになります。立ち上げ時の工数だけを見て体制を組むと、この運用フェーズで破綻しがちです。
なお、カメラ映像のリアルタイム処理を伴う機器では、Yoctoで構築した装置OSの上でFPGAによる画像処理やエッジAI推論と連携させるケースもあり、OS基盤の設計がその後の機能拡張の自由度を左右します。
OSポーティングを外部委託すべきか判断するポイント
ここまで見てきたとおり、Yoctoのビルド手順そのものよりも、ハードウェア起因の切り分け、カーネル移行の互換性対応、長期保守の運用設計に経験と工数が求められます。自社対応と外部委託の切り分けは、次の観点で判断するのが現実的です。
自社対応が向いているケースは、対象ボードのBSPが充実しており、社内にLinuxカーネルとボード立ち上げの経験者がいて、製品のライフサイクルを通じて保守体制を維持できる場合です。
外部委託を検討すべきケースは、次のいずれかに当てはまる場合です。
- 新規ボードの立ち上げで、ハードウェアレベルの切り分け（シリアル出力すら出ない段階からのデバッグ）に対応できる人材が社内にいない
- 古いカーネルからの移行が必要だが、影響範囲の見積もりができない
- アプリケーション開発には注力したいが、OS・BSPレイヤーの維持に人を割けない
- 一時的な立ち上げ工数のピークだけを外部で吸収したい
商用ディストリビューションの導入だけでは、自社ボード特有のBSP統合やカーネル移行までは面倒を見てもらえないことも多く、その場合はポーティング作業そのものを委託できる開発パートナーが選択肢になります。委託先を選定する際は、Yoctoのビルドができるだけでなく、ハードウェア仕様の確認から、ビルド環境の整備、移植作業、基板レベルでの動作確認までを一貫して対応できるか、そしてカーネルバージョン移行の実績があるかを確認することをおすすめします。OSポーティングはソフトウェアとハードウェアの境界領域の作業であり、ハードウェアを理解した上での組込みソフトウェア開発経験が品質を左右するためです。
まとめ
YoctoでのOSポーティングは、ブートローダ、カーネル、デバイスツリー、rootfsという成果物をボードに合わせて作り込み、継続更新できる形で管理する取り組みです。Yocto・Poky・OpenEmbeddedの関係を理解し、要件を運用年数と一体で定義し、ベンダーBSPが支える範囲を現実的に見極め、最小イメージで早期に起動確認してから機能を積み上げる、という進め方が王道です。
一方で、デバイスツリーやファームウェアの落とし穴、カーネル移行の互換性問題、SBOM・セキュリティ更新を含む長期運用など、経験がないと工数を見積もれない領域が多いのも事実です。自社で立ち上げる場合も、商用ディストリビューションを使う場合も、外部パートナーへ委託する場合も、それぞれの利点と制約を理解した上で選ぶことが、後戻りのない開発につながります。
社内リソースだけでの対応に不安がある場合や、ハードウェア立ち上げの切り分けから任せられるパートナーをお探しの場合は、実績のある開発パートナーへの相談も選択肢の一つです。ゼネテックは、組込みLinux（Yocto）を用いた装置ソフトウェアの開発、新しいハードウェアへのOSポーティング、カーネルバージョンの移行に対応しています。ハードウェア仕様の確認からビルド環境の整備、移植作業、基板レベルでの動作確認まで、装置の土台となるソフトウェア開発を一貫してご支援します。医療機器をはじめとする要求レベルの高い分野でのご相談は、お気軽にお問い合わせください。
医療機器開発支援のお問い合わせはこちら
要求レベルの高い医療機器の開発を、ソフトウェアとハードウェアの両面からワンストップで支援