はじめに
「Raspberry PiでLinuxが動いた。じゃあ製品にもこのまま載せられるのでは？」――組み込みの現場に入ってきた方から、よくこういう相談を受けます。答えは「動くけれど、話はそんなに単純ではない」です。
この記事は、組み込みLinuxを学び始める前に、PC・マイコン・SBCの立ち位置を整理することを目的にした、初学者向けの解説です。
理解しやすさを優先するため、CPUやOSごとの例外は一部省略しています。
実際に製品へ採用する際は、使用するSoC・ボード・OSの公式資料で条件を確認してください。
このシリーズ「組み込みLinuxの仕組み」では、Raspberry Piから始めて、用途特化ボード、産業用モジュール、ブートの内部、そして最後はCPU搭載FPGAとYoctoまで、「Linuxが動くボード」の違いを段階的に見ていきます。
第1回の今回は、そもそも組み込みLinuxとは何者なのか、PCのLinuxやマイコン（MCU）と何が違うのかを整理します。
なお、デバッグの手法そのものは前シリーズ「組み込み実践編 A-1：どのレイヤーがおかしいかの見極め方」で扱っているので、本シリーズでは「仕組みの理解」に軸足を置きます。
連載予定（全12回＋C-10.5前後編）
| # | タイトル |
|---|---|
| C-1 | 組み込みLinuxとは何者か ― PC・マイコン・SBCの間を整理する（← 本記事） |
| C-2 | Raspberry Piはなぜ学習の入口に向くのか |
| C-3 | NanoPi・Banana Pi・Orange Pi ― 用途特化SBCの選び方 |
| C-4 | SBCから製品へ ― SoM・COM・キャリアボードという考え方 |
| C-5 | 電源ONからアプリまで ― 組み込みLinuxのブート全体像 |
| C-6 | シリアルコンソールでブートログを読む |
| C-7 | Device Treeは何をしているのか |
| C-8 | rootfsと自動起動 ― アプリを「製品として動かす」 |
| C-9 | CPU＋FPGA SoCとは何か ― プロセッサ側とロジック側の境界 |
| C-10 | Yocto Projectの地図 ― 何を作っているのか |
| C-10.5 前編 | Yoctoでユーザーアプリのバージョンをどう管理するか ― 現場で「正」を決める |
| C-10.5 後編 | Yoctoのバージョン管理を中から覗く ― PV・PR・SRCREVとマニフェスト |
| C-11 | AMD Zynq-7000のLinux開発フロー ― ハード設計からPetaLinux/Yoctoへ |
| C-12 | Altera Cyclone V SoCのLinux開発フロー ― RocketBoardsからYoctoを読む |
各回は公開が確定次第、本記事のリンクを実URLに更新します。
この記事でわかること
- ベアメタル、RTOS、組み込みLinuxの大まかな使い分け
- PCのLinuxと組み込みLinuxで、共通する部分と異なる部分
- SBC、SoM/COM、CPU搭載FPGA SoCの位置関係
先に結論
- 組み込みLinuxは、Linuxカーネルを中心とした豊富なソフトウェア資産を、特定用途の機器で利用するための実行基盤です。
- Linuxが起動することと、長期間安定して製品運用できることは別の課題です。
- ボード名だけでなく、SoC、ブート構成、OSイメージ、供給・保守条件まで見て選ぶ必要があります。
図にすると、今回整理する範囲は上のようになります。左右は優劣ではなく、装置の要件に応じた選択肢の違いです。
「OSなし／RTOS／Linux」の3つの世界
組み込み機器のソフトウェアは、大きく3つの世界に分かれます。
| 世界 | 実行環境 | 典型的なCPU | 起動時間 | 例 |
|---|---|---|---|---|
| ベアメタル（OSなし） | main()から無限ループ | Cortex-M、PIC、RL78 | ミリ秒 | センサーノード、モーター制御 |
| RTOS | FreeRTOS、ThreadX等 | Cortex-M、R系 | ミリ秒〜 | 通信モジュール、計測器の制御部 |
| 組み込みLinux | カーネル＋rootfs | Cortex-A、x86 | 数秒〜数十秒 | ルーター、複合機、HMI付き装置 |
ポイントは、一般的な組み込みLinuxを選ぶと、MMUを備えたCPU、ベアメタルや小規模RTOSより多いRAM、rootfsを置くストレージ、比較的長いブート時間が必要になることです。必要量は構成によって大きく変わりますが、それらのコストを受け入れてでも欲しい機能があるときにLinuxを選びます。
Linuxを載せる理由
私の経験上、組み込みでLinuxを選ぶ動機はだいたい次のどれかです。
- ネットワークスタックが欲しい：TCP/IP、Wi-Fi、TLS、SSH…を自前やRTOSミドルで揃えるのはしんどい
- ファイルシステムとストレージ管理が欲しい：ログ、設定、画像データの保存
- GUIが欲しい：液晶にそれなりの画面を出す（Qt、Webブラウザ系HMIなど）
- 既存のソフト資産を使いたい：OpenSSL、Python、Webサーバー、各種ドライバ
- 開発者を集めやすい：Linuxなら触れる人が多い
逆に、非常に短い起動時間、厳密な応答時間、小さなメモリや低消費電力が優先されるなら、マイコン＋ベアメタル/RTOSが有力です。ただしPREEMPT_RTを含むリアルタイムLinuxや異種コア構成もあるため、これは絶対的な境界ではなく、最初の判断軸と考えてください。この線引きは、別シリーズ（Dシリーズ：MCU開発環境の地図）で詳しく扱います。
PCのLinuxと組み込みLinuxは何が違うか
どちらもLinuxカーネルを基盤にしている点は共通しています。ただし、組み込みでは古いLTS版やベンダー独自の変更を含むカーネルが使われることもあります。主な違いは、カーネルのバージョンや構成に加えて、その外側にもあります。
| 観点 | PCのLinux | 組み込みLinux |
|---|---|---|
| CPUアーキ | x86_64が主流 | Armが主流（＋RISC-Vが台頭） |
| ファーム | UEFI/BIOSがほぼ共通 | ブートROM＋U-Boot等、ボードごとに違う |
| ハード記述 | 主にACPIや列挙可能なバスを利用 | 主にDevice Treeで基板構成を記述 |
| ストレージ | SSD/HDD | eMMC、SDカード、NAND/NOR |
| rootfs | ディストリをフルインストール | 必要最小限を構成（BusyBox〜Debian系まで幅広い） |
| 追加/交換 | ユーザーが周辺機器を挿す | 基板に実装された固定構成 |
| 電源断 | シャットダウン操作前提 | 利用環境によっては突然の電源断に耐える設計が必要 |
もちろん、組み込み機器でもACPIを使う構成や、PCでもDevice Treeを使う例はあります。ここではArm系SBCでよく見る構成として整理しています。
この表の太字2つ――「ブートがボードごとに違う」「基板構成をDevice Treeで記述する」――が、組み込みLinuxの学習で最初につまずくポイントであり、このシリーズ第2部（C-5〜C-8）の主役です。Device Treeは、OSが読み取れる形式でハードウェアを記述し、ボード固有情報をカーネルへ直接書き込むことを減らす仕組みです。
ハードウェアの全体像：SoCという考え方
組み込みLinuxボードの心臓部は SoC（System on Chip） です。CPUコアだけでなく、メモリコントローラ、UART、I2C、SPI、GPIO、Ethernet MAC、GPU…が1チップに集約されています。
Raspberry Pi 4ならBroadcom BCM2711、Orange Pi OneならAllwinner H3、といった具合に、搭載SoCはボードの性格を判断する重要な手掛かりです。CPU性能、内蔵I/O、Linuxカーネルの対応状況、ブート手順の多くがSoCに関係するからです。
ただし、同じSoCでもDRAM、電源、PHY、コネクタ、ストレージ、メーカーが提供するBSPによって使い勝手は変わります。ボードを見るときは、製品名だけでなく「SoC型番＋基板固有の構成」を確認する癖をつけると、この後の話が読みやすくなります。
「Linuxが動く＝全部Raspberry Piと同じ」ではない
同じ「Linuxが動くボード」でも、立ち位置はかなり違います。シリーズの地図を先に見せておきます。
| 分類 | 例 | 向いていること | 本シリーズ |
|---|---|---|---|
| 汎用SBC | Raspberry Pi 3/4/5 | 学習、試作、情報の多さ | C-2 |
| 用途特化SBC | Orange Pi R1（2ポートLAN）等 | ルーター、小型・低消費電力 | C-3 |
| SoM/COM＋キャリア | Compute Module 4/5、産業用SoM | 量産、長期供給、専用基板 | C-4 |
| CPU搭載FPGA SoC | Zynq-7000、Cyclone V SoC、Arria 10 SoC等 | 高速I/Oや専用ロジックが要る装置 | C-9〜C-12 |
ハマりどころ
- 「Ubuntuが動く」と「製品に使える」は別問題：SDカードの書き込み寿命、電源断耐性、起動時間、長期供給は、動作デモでは見えてきません（C-4、C-8で扱います）
- 同じボードでもOSイメージで中身が別物：Raspberry Pi OS、Ubuntu、Armbian、自前Yoctoではカーネルもrootfsも構成が違います。「ネットの記事どおりに動かない」の多くはここが原因です
- 周辺I/Oは「載っていても有効化されていない」ことがある：I2CやSPIはデフォルト無効のイメージも多く、有効化にはDevice Tree（overlay）の知識が要ります（C-7で扱います）
現場コラム：「とりあえずラズパイで」の功罪
試作の初速という意味で、Raspberry Piは本当に優秀です。私も装置のプロトタイプや治具では散々お世話になっています。一方で、「試作がラズパイで動いたので、このまま量産へ」という流れになったときに、供給性・温度範囲・電源断・EMCといった試作では問われなかった要件が一気に噴き出すのを何度か見てきました。
技術的な取り回しの良さだけでなく、稟議や調達の事情も、現場がRaspberry Piへ手を伸ばす理由になります。新規開発案件で本命は産業用SBCだとしても、量産が決まっていない段階で高価な産業用ボードを何枚も稟議に通すのは簡単ではありません。まずは安価な民生SBCでPoCを組み、技術的な実現性を示すエビデンスとして稟議に添える、という使い方は珍しくありません。
また、仮に産業用SBCの採用自体は決まっても、入手性の壁がもう一つ残ります。評価用に1〜2枚は確保できても、開発メンバー全員分をすぐ揃えられるとは限りませんし、リードタイムが長い製品では発注してから数か月手元に届かないこともあります。その「本命ボードが揃うまでの空白期間」を、入手性のいい民生SBCで埋めて開発を止めない、という運用も現場ではよくある工夫です。
大事なのは「ラズパイを卒業すること」ではなく、試作ボードと製品ボードの間に何が横たわっているかを知っておくことです。それが分かっていれば、ラズパイ試作は最短ルートですし、CM4のように「ラズパイのまま製品へ寄せる」選択肢も正しく評価できます。この間を埋めるのが、C-4までの前半戦です。
まとめと次回
- 組み込みLinuxは「ネットワーク・ファイルシステム・GUI・ソフト資産」が欲しいときの選択肢。引き換えにCPU・メモリ・ブート時間を差し出す
- PCとの違いは「ブートがボードごとに違う」「ハードはDevice Treeで教える」に集約される
- SoCはボードの性格を判断する重要な手掛かり。ただし基板構成やBSPも合わせて確認する
- 「Linuxが動くボード」には汎用SBC／用途特化SBC／SoM・COM／FPGA SoCという地図がある
次回C-2は、その地図の入口である 「Raspberry Piはなぜ学習の入口に向くのか」 です。「当たり前すぎて言語化されない強み」を、製品開発の視点から見直します。