はじめに

2026年8月22日、CNX Software が「Espressif が ESP32-S31 向けの Linux BSP 開発者プレビューを公開した」と報じました。GitHub の Espressif アカウントを開くと、確かに Linux カーネル・OpenSBI・U-Boot・Buildroot のフォークが並んでいます。ブランチ名にはすべて esp32s31 が入っています。

ESP32 と聞いて多くの人が思い浮かべるのは、FreeRTOS の上で ESP-IDF のタスクを回す、あのマイコンでしょう。そこに Linux カーネルのフォークが公式アカウントから出てくるというのは、ちょっとした事件です。

そして今回いちばん面白いのは、「なぜ今までは動かせなかったのか」のほうが技術的にはっきりしているという点です。答えは1つの部品に集約されます。MMU です。

この記事では、次の順で整理します。

  • MMU とは何か。なぜ Linux はそれを要求し、ESP32-S3 では足りないのか
  • BSP とは何か。今回「公開された」ものの実体は何なのか
  • 公式リポジトリのデバイスツリーとカーネル設定を読んで、開発者プレビューで何が動いて何が動かないのかを確定させる
  • ESP-IDF（FreeRTOS）と Linux の使い分け

なお、筆者は ESP32-S31 の実機を持っていません。この記事は公開されているソースコードと公式ドキュメントを読んだ範囲の内容で、実機で焼いて起動させたものではありません。 実機での確認が必要な箇所はその都度明記します。

1. 🧠 MMU とは何か — Linux が動く / 動かないの分かれ目

仮想アドレスと物理アドレスを、ページ単位で結び直す装置

MMU（Memory Management Unit）は、CPU が出したアドレス（仮想アドレス）を、実際のメモリのアドレス（物理アドレス）へ翻訳するハードウェアです。翻訳のルールはメモリ上のページテーブルという表に書かれていて、MMU はそれを引きながらアクセスのたびに変換します。

💡 ワード解説：ページとページテーブル

メモリを固定サイズの区画に区切ったものがページです（ESP32-S31 が使う RISC-V Sv32 方式では 4KB）。「仮想アドレスのこのページは、物理アドレスのあのページ」という対応表がページテーブルで、OS がプロセスごとに作ります。表に載っていないアドレスへ触るとページフォルトという例外が起き、CPU の制御が OS に戻ります。

この仕組みがあると、OS は次のことができるようになります。

できること 中身
プロセスごとの独立したアドレス空間 プロセス A の「アドレス 0x1000」と B の「0x1000」を別の物理メモリに割り当てられる
メモリ保護 他人のメモリやカーネルのメモリに触ろうとした瞬間に例外を起こして止められる
ユーザ空間とカーネル空間の分離 アプリが暴走してもカーネルは巻き込まれない
デマンドページング 実際に触られたときに初めて物理メモリを割り当てる

一般的な Linux は、この4つを前提として書かれています。fork(2) も mmap(2) も、共有ライブラリの仕組みも、セグメンテーション違反で1つのプロセスだけが落ちる挙動も、すべて MMU があることが出発点です。MMU を持たない環境向けの NOMMU 構成も Linux には存在しますが、プロセスごとのアドレス空間分離という前提そのものが変わるため、通常のディストリビューションのユーザ空間がそのまま動くわけではありません。

ESP32-S3 にも「MMU」はある。でも別物

ここが紛らわしいところです。ESP-IDF のドキュメントには、ESP32-S3 の項目にもはっきり「MMU」という章があります。ではなぜ ESP32-S3 で Linux が動かないのか。

ESP-IDF 公式ドキュメントは、ESP32-S3 の MMU を 相対的に単純（relatively simple）なもので、物理アドレスと仮想アドレスの変換を行う と説明しています。そしてフラッシュのマッピングは 64KB ページ単位で、読み出し操作にしか働きません。

つまり ESP32-S3 の MMU は、外付けの SPI フラッシュや PSRAM を CPU のアドレス空間の窓に見せて、キャッシュ経由で読めるようにするためのアドレス変換器です。役割としては「大きな外部メモリを、限られたアドレス空間から覗く」ための仕掛けであって、プロセスごとのページテーブルも、書き込み保護も、ページフォルトによる OS への制御移譲もありません。Linux が要求している MMU とは、同じ3文字でも守備範囲が違います。

さらに RISC-V 系の ESP32-C3 / C6 なども事情は同じで、Linux が動くには S モード（スーパーバイザモード） とページング機構が要ります。この2つが揃って初めて、カーネルとユーザ空間を特権レベルで分けるという Linux の大前提が成立します。

ESP32-S31 のデバイスツリーには何と書いてあるか

今回公開されたカーネルツリーの arch/riscv/boot/dts/espressif/esp32s31.dts には、CPU の記述としてこう書かれています。

riscv,isa = "rv32imac_zicsr_zifencei";
riscv,isa-base = "rv32i";
mmu-type = "riscv,sv32";
clock-frequency = <320000000>;

mmu-type = "riscv,sv32" の一行が、この記事のすべてです。Sv32 は RISC-V の 32bit 向けページング方式で、4KB ページの2段ページテーブルを持ちます。これがハードウェアにあるから、Linux のメモリ管理がそのまま乗ります。

ついでに読める情報も並べておきます。

  • rv32imac — 整数・乗除算・アトミック・圧縮命令。浮動小数点拡張（F / D）が無いので、浮動小数点演算はソフトウェアで処理されます
  • clock-frequency = <320000000> — 320MHz。Espressif 公式製品ページの「最大 320MHz」と一致します
💡 ワード解説：エミュレーションで動かす手もある（ただし別の話）

「MMU が無いと Linux は動かない」には抜け道があります。MMU を持つ CPU をソフトウェアでまるごと再現してしまう方法です。実際、2022年に Dror Gluska 氏が TinyEMU を初代 ESP32 に移植し、エミュレートした RISC-V の上で Linux カーネルを起動させています。同氏はその記事で、起動に 1分35秒かかったと報告しています（それ以前の試みでは約6時間かかっていたとも書かれています）。

今回の ESP32-S31 は、これとはまったく違います。エミュレータを挟まず、チップのハードウェア MMU の上で Linux が直接走ります。 同じ「マイコンで Linux」でも性質がまるで別物だという点は、押さえておく価値があります。

2. 📦 BSP とは何か

BSP は Board Support Package の略です。ある OS を、ある特定のボード / SoC の上で起動させるために必要な一式を指します。具体的には次のようなものが含まれます。

構成要素 役割
ブートローダ 電源投入直後にメモリやクロックを初期化し、カーネルを起動する
カーネルの移植コード その SoC 固有の割り込みコントローラ・タイマ・キャッシュなどを扱うコード
デバイスドライバ UART やフラッシュなど、周辺回路を OS から使えるようにする
デバイスツリー 「このアドレスにこの周辺回路がある」というハードウェアの地図
ビルドレシピ 上記とルートファイルシステムをまとめてイメージにする手順

「BSP の開発者プレビューが出た」というのは、そのボードで Linux が起動するところまでの最小の一式が、公式アカウントから公開されたという意味になります。逆に言えば BSP は「全部入りの完成品」を意味しません。何がその一式に含まれていて、何が含まれていないかを読むのが本題です。

3. 🔍 公開されたものの中身

5つのリポジトリで構成されている

Espressif が公開したのは単一のリポジトリではなく、5つのフォーク / ツリーの組です。Buildroot の defconfig が、それぞれのブランチを指しています。

リポジトリ ブランチ ベース 役割
espressif/opensbi integration/v1.6-esp32s31 OpenSBI 1.6 M モードに常駐するファームウェア
espressif/u-boot integration/v2024.07-esp32s31 U-Boot 2024.07 SPL による PSRAM / フラッシュ初期化とブート
espressif/linux integration/v6.18-esp32s31 Linux 6.18 カーネル本体
espressif/esp-buildroot-external buildroot/v2025.02-esp32s31 Buildroot 2025.02 ビルド定義とルートファイルシステム
espressif/esp-linux-bsp integration/v1.0-esp32s31 ― イメージレイアウトとパッケージング（Apache-2.0）
💡 ワード解説：OpenSBI と SBI

RISC-V では、OS より下の階層に SBI（Supervisor Binary Interface） という規格があります。M モード（最高特権）で動くファームウェアが、S モードで動く OS に対してタイマ設定・コア間割り込み・システムリセットといったサービスを提供する取り決めです。OpenSBI はその参照実装で、RISC-V の Linux ではほぼ標準的に挟まります。x86 でいう BIOS/UEFI と役割は似ていますが、SBI は起動後も常駐して OS からの呼び出しに応え続ける点が違います。

ブートチェーン

Buildroot の README は、起動が成功すると SPL・OpenSBI・U-Boot・Linux・ルートファイルシステムの順に進んでルートシェルに到達する、と書いています。図にするとこうなります。

flowchart TD A["U-Boot SPL
PSRAM と XIP 窓を初期化"] --> B["OpenSBI 1.6 fork
M モードに常駐"] B --> C["U-Boot 2024.07 fork"] C --> D["Linux 6.18 fork
S モード / XIP 実行"] D --> E["cramfs ルート
読み取り専用 4MiB"] E --> F["BusyBox シェル
ttyS0 115200"]

SPL は Espressif のイメージ形式でラップされてフラッシュの先頭（オフセット 0x0）に置かれ、そこから上の順に進みます。デバイスツリーの冒頭コメントには、U-Boot が Linux 起動前に PSRAM を初期化し NOR フラッシュの XIP ウィンドウをマップすること、OpenSBI が M モードの CLIC バンクを所有し、ベンダ SBI 呼び出しでキャッシュ管理を提供することが明記されています。

カーネルへの変更は8コミット

espressif/linux の該当ブランチは、Linux 6.18 のリリースタグの上に Espressif のコミットが8個乗っているだけの構成です（いずれも 2026年8月17日付）。GitHub の差分表示で数えると、追加行数の合計はおよそ1,250行です。この規模感自体が、開発者プレビューという位置づけをよく表しています。

# コミット 中身
1 riscv: add Espressif platform plumbing SoC 選択とデバイスツリーのビルド配線を追加
2 riscv: add ESP32-S31 CLIC interrupt support PLIC を使わず、CLIC とインタラプトマトリクス経由で周辺割り込みを配る
3 serial: support ESP32-S31 UART 既存の esp32_uart.c に S31 対応を追加
4 cache: add ESP32-S31 SBI cache maintenance 非コヒーレント DMA と命令キャッシュ同期をベンダ SBI 呼び出しで行う
5 riscv: add ESP32-S31 XIP kernel support カーネル本体を NOR フラッシュ上で直接実行し、初期化済みデータだけ PSRAM へ複製
6 clocksource: add ESP32-S31 system timer CPU がアイドルでも走り続けるクロックソース / クロックイベント
7 riscv: add minimal ESP32-S31 NOR boot target デバイスツリーと最小 defconfig を追加
8 esp: add ESP32-S31 branch maintenance strategy ブランチ運用方針のドキュメント化

注目したいのは2番の CLIC です。RISC-V の Linux で一般的な割り込みコントローラは PLIC ですが、ESP32-S31 は CLIC（Core-Local Interrupt Controller）と Espressif 独自のインタラプトマトリクスという組み合わせを使っています。そのため専用のドライバが2本（irq-esp-clic.c と irq-esp-intmtx.c）、合わせて465行分、新規に書かれています。既存の RISC-V ボードと同じ構成にはならなかったことが、コミットの形からそのまま読み取れます。

XIP — カーネルを RAM に展開しない

5番の XIP（eXecute In Place） も、この構成を理解する鍵です。通常の Linux はカーネルイメージを RAM に展開してから実行しますが、ここではカーネルのコードを NOR フラッシュ上のアドレスから直接実行し、書き換えが必要な初期化済みデータだけを PSRAM にコピーします。

最小 defconfig を読むと、その配置がそのまま書かれています。

CONFIG_XIP_KERNEL=y
CONFIG_XIP_PHYS_ADDR=0x40400000
CONFIG_PHYS_RAM_BASE=0x50000000

デバイスツリー側では、メモリとルートファイルシステムがこう定義されています。

領域 アドレス サイズ 中身
カーネル（XIP） 0x40400000 約 7MiB フラッシュ上で直接実行
ルートファイルシステム 0x40b00000 4MiB cramfs・読み取り専用
メモリ 0x50000000 16MiB PSRAM

RAM に相当するのは 16MiB の PSRAM だけです。カーネルを RAM に置かない設計は、この容量では実質的に必須の選択と言えます。

4. 🚦 開発者プレビューで何ができて、何ができないのか

ここが一次情報を読む価値のいちばん大きいところです。最小 defconfig（esp32s31_minimal_defconfig）とデバイスツリーに書かれているものが、そのまま動く範囲そのものになります。

動くもの

項目 根拠
シリアルコンソール（115200 baud） DT に uart0、bootargs に console=ttyS0
読み取り専用のルートファイルシステム CONFIG_CRAMFS=y、bootargs に rootfstype=cramfs ro
/tmp と /run への書き込み CONFIG_TMPFS=y、rootfs オーバーレイの fstab で tmpfs をマウント
/dev の自動生成 CONFIG_DEVTMPFS_MOUNT=y
BusyBox のシェル inittab が getty -n -l /bin/sh でログインプロンプト無しにシェルを起動
再起動 inittab に ::ctrlaltdel:/sbin/reboot

Buildroot が用意する /etc/inittab のコメントには、ルートはフラッシュの XIP ウィンドウから読む読み取り専用 cramfs であり remount,rw は行わない、とはっきり書かれています。

この最小構成では動かないもの

項目 根拠
Wi-Fi 6 / Bluetooth 5.4 / Ethernet 最小 defconfig にネットワーク関連の設定が1行も無い。DT にも無線・Ethernet のノードが無い
ブロックデバイス・SD カード・ext4 # CONFIG_BLOCK is not set。ブロックレイヤ自体が無効
GPIO / I2C / SPI などの周辺回路 DT に記述されているのは CLIC・インタラプトマトリクス・UART0・システムタイマ・フラッシュのみ
デュアルコア（SMP） DT の CPU ノードは cpu@0 の1個だけ
seccomp / スタックプロテクタ / kallsyms いずれも無効。CONFIG_BUG も無効で、サイズ最適化が徹底されている

つまり現時点のこのプレビューは、Sv32 の MMU の上で Linux カーネルが起動し、シリアルコンソールにシェルが出るところまでを示す最小構成です。ESP32-S31 の売りである Wi-Fi 6 や Gigabit Ethernet MAC を Linux から使う話は、まだここには含まれていません。

⚠️ 報道と一次情報で食い違う点

CNX Software の記事には「Wi-Fi・Bluetooth・デュアルコアは Experimental、Poweroff は未実装」という状態表が引かれています。これは Espressif 公式 BSP のものではなく、コミュニティ移植（GrieferPig 氏の esp32-s31-linux）の README にある表です。 実際に同リポジトリを開くと、その表がそのまま載っています。

一方、Espressif の公式リポジトリ側に機能ステータス表は存在せず、上に書いたとおり最小 defconfig にネットワーク設定がありません。公式 BSP で Wi-Fi が Experimental ながら動く、という読み方は、少なくとも公開されているコードからは裏が取れません。 両者は別のプロジェクトとして分けて読む必要があります（コミュニティ側の話は §6 に整理しました）。

公式が明言している位置づけ

5つのリポジトリすべてに、同じ文言のブランチ運用方針が置かれています。要点はこうです。

  • 開発者プレビューであり、本番利用はまだ推奨しない（not yet recommended for production use）
  • 対応チップは ESP32-S31 のみ
  • 更新は不定期。予告なく破壊的変更が入りうる
  • 開発者プレビュー期間中は新機能の要望が受け入れられない場合がある
  • バグ修正はベストエフォート。API / ABI の互換性保証は無い
  • 想定用途は、早期評価・ハードウェア検証・プロトタイピングとフィードバック

試すための手順

公式 README に載っている手順は次のとおりです（ボードは defconfig 名から ESP32-S31-Function-CoreBoard-1 向け）。

# 1. 対応する Buildroot 本体を取得
git clone --branch 2025.02 --depth 1 \
  https://gitlab.com/buildroot.org/buildroot.git <path-to-buildroot>

# 2. Espressif の external tree を取得
git clone --branch buildroot/v2025.02-esp32s31 \
  https://github.com/espressif/esp-buildroot-external.git <path-to-external>

# 3. defconfig を適用
make -C <path-to-buildroot> \
  BR2_EXTERNAL=<path-to-external> \
  O=<path-to-output> \
  espressif_esp32s31_function_core_board_nor_defconfig

# 4. ビルド（RV32 の musl ツールチェーンから作られる）
ESP_ESPTOOL=<path-to-esptool> \
make -C <path-to-buildroot> O=<path-to-output> -j"$(nproc)"

できあがるのは <path-to-output>/images/s31_full_flash.bin の1ファイルで、書き込みはオフセット 0x0 へ丸ごと流し込みます。

esptool --chip esp32s31 --port <serial-port> --baud 1152000 \
  write-flash 0x0 <path-to-output>/images/s31_full_flash.bin

シリアル接続が不安定なときは 460800 へ落とすように README が案内しています。書き込み後、コンソールは 115200 baud で開きます。

なお esptool は「ESP32-S31 に対応したもの」とだけ書かれており、README に具体的なバージョン指定はありません。CNX Software は 5.3.0 以上が必要で 5.3.1 で検証したと報じていますが、この数字は公式 README では確認できませんでした。

5. 🧭 ESP-IDF / FreeRTOS / NuttX / Linux の使い分け

「Linux が動く」と聞くと ESP-IDF が置き換わるように見えますが、実態は選択肢が1つ増えたという話です。それぞれ前提が違います。

ESP-IDF（FreeRTOS） NuttX Linux（今回の BSP）
MMU の要否 不要 不要 必須
アドレス空間 全タスクで単一 単一（構成による） プロセスごとに分離
無線スタック Wi-Fi / BT / Thread / Matter を公式提供 ― 最小構成には含まれない
省電力機構 ディープスリープ等を公式提供 ― 今回のプレビューでは未整備
ソフト資産 ESP-IDF コンポーネント POSIX 風 API POSIX とその上の膨大な既存ソフト
Espressif の位置づけ フルサポート ― 開発者プレビュー

ESP32-S31 の量産開始を伝えた 2026年7月27日の公式ニュースでも、ソフトウェア面で挙げられているのは ESP-IDF のフルサポートと、ESP-Matter / ESP-GMF / ESP-BLE-MESH といったエコシステムです。Linux への言及はありません。 つまり Espressif にとっての本線はいまも ESP-IDF であり、Linux BSP はその隣に置かれた実験的な選択肢、と読むのが自然です。

NuttX については、ESP32 シリーズをアップストリームで公式サポートしている RTOS で、MMU を必要としません。ESP32-S31 向けの統合は Espressif の開発者プラットフォームにコミュニティ投稿として掲載されています（2026年8月18日付）。アップストリームへの取り込み状況までは確認できませんでした。

判断の軸を1つに絞るならこうなります。周辺回路をリアルタイムに叩き、マイクロアンペア単位で寝かせたいなら ESP-IDF。既存の POSIX ソフトウェア資産とプロセス分離が欲しいなら Linux。 そして今回のプレビューは、後者の入口が開いたことを示すものであって、後者が完成したという話ではありません。

6. 🌱 コミュニティ側はもっと先へ行っている

面白いのは、公式より先にコミュニティが動いていたことです。Espressif の ESP32-S31 開発者プラットフォームには、コミュニティプロジェクトとして複数の Linux 移植が掲載されています。

GrieferPig 氏の移植（Linux 6.12）

ESP32-S31-WROOM-3 E1H16R16V モジュールで検証したとされる移植です。README のステータス表によれば、Buildroot の rootfs と再起動は Stable、Poweroff は未実装、Wi-Fi・Bluetooth デュアルモード・デュアルコア SMP は Experimental という状態です。周辺ドライバも幅広く、AXI/AHB GDMA・TRNG・eFuse・ウォッチドッグ・GPIO・GMAC Ethernet・SDMMC などが Experimental として並び、I2C や I2S は未実装とされています。公式の最小構成よりはるかに広い範囲に手を伸ばしていることがわかります。

annoyedmilk 氏の移植（Linux 7.1）

こちらは ESP32-S31-Korvo-1 で、16MiB の octal PSRAM を Linux のメモリとして使う構成です。README に書かれた設計がとくに興味深く、2つのハートを役割で分けています。ハート0 は M モードのまま ESP-IDF のローダを常駐させて WLAN モデムを所有し続け、ハート1 を OpenSBI 経由で Linux に明け渡す、という構成だとしています。

つまり「Wi-Fi は ESP-IDF に任せたまま、隣のコアで Linux を走らせる」わけです。Espressif の無線スタックを捨てずに Linux を載せる現実的な折衷案で、発想として素直に面白いと感じました。同 README にはキャッシュ構成（命令 32KiB / データ 64KiB、いずれも2ウェイ・64バイトライン）や、Zicbom が無いため DMA がキャッシュコントローラの同期エンジンに依存する、といった移植者ならではの記述も並んでいます。

これらは移植者自身による記述であり、筆者が実機で確認したものではありません。ただ、公式の最小 BSP とコミュニティの探索が同時に走っているという状況そのものが、このチップの現在地をよく表しています。

📌 筆者の見方

筆者は先日、ESP32-S3 で自宅の環境センサー基板を一式組み終えたところです。センサーを I2C で読んで MQTT で飛ばし、受け側の Ubuntu サーバーが Docker で受け止めて時系列 DB に貯める、という構成でした。作りながら、線は自然に引かれていました。端末は FreeRTOS、母屋は Linux。 その配分に疑問を持ったことは一度もありません。

そのうえで正直に振り返ると、端末側で「Linux だったらな」と思った瞬間が1つだけありました。ネットワークが切れている間のデータをどう溜めるかです。Linux ならファイルに追記して終わりの話が、ESP-IDF ではフラッシュ上のリングバッファを自分で設計することになります。壊れたときの復旧も自分で書く。ここは既存のソフトウェア資産の厚みがそのまま効く領域だと感じました。

だから今回のプレビューを見て最初に確かめたのは、まさにそこでした。そして、ルートは読み取り専用の cramfs、ブロックレイヤは無効、ネットワークは設定に一行も無い。筆者が欲しかった用途には、まだ届いていません。それでも落胆はしていなくて、むしろ順番として正しいと受け止めています。MMU の上でカーネルが起動してシェルが出る ——ここが通っていなければ、その先の話は全部机上のままだからです。

これは意見ですが、この一件でいちばん効いてくるのは機能表ではなく、線の引き直しが設計者の手に戻ることだと思います。これまで端末側が RTOS だったのは、多くの場合それが好ましいからではなく、チップに MMU が無かったからでした。理由がハードウェアの制約から用途の判断に変わるなら、次に基板を起こすときの選択肢は確実に一段増えます。16MiB の PSRAM と読み取り専用ルートという制約の中で、どこまで実用に近づくのか。ESP32-S31 の実機はまだ手元にありませんが、これは追いかける価値のある方向だと感じています。

まとめ

一次情報で確認できたこと

  • Espressif が ESP32-S31 向けに Linux 6.18 ベースの BSP 開発者プレビューを公開した。構成は OpenSBI 1.6 / U-Boot 2024.07 / Linux 6.18 / Buildroot 2025.02 / パッケージングツールの5リポジトリ
  • カーネル側の変更は 8コミット・約1,250行。CLIC 割り込み・UART・SBI キャッシュ管理・XIP・システムタイマ・最小デバイスツリーという内訳
  • デバイスツリーに mmu-type = "riscv,sv32" が明記されており、ハードウェア MMU の上で Linux が直接動く
  • 動くのはシリアルコンソールと読み取り専用 cramfs ルートまで。Wi-Fi・Bluetooth・Ethernet・ブロックデバイス・GPIO・SMP は最小構成に含まれない
  • 公式の位置づけは「本番利用はまだ推奨しない」「破壊的変更が予告なく入りうる」
  • ESP32-S31 自体は 2026年7月27日に量産開始が公式発表されている。ただしその発表でソフトウェアとして挙がっているのは ESP-IDF であり、Linux への言及は無い

確認できなかったこと

  • esptool の必要バージョン（CNX Software は 5.3.0 以上と報じているが、公式 README に記載無し）
  • これらのパッチをアップストリームの Linux へ提出する計画の有無
  • Wi-Fi / Ethernet を Linux から使えるようにする今後のロードマップ

ここから先は筆者の判断

  • このプレビューは「Linux が使える ESP32」ではなく、Linux が起動する ESP32 の証明として読むのが正確
  • ESP-IDF の置き換えではない。端末を RTOS にする理由が、チップの制約から設計の選択に変わることのほうが効いてくる

よくある質問（FAQ）

Q1. ESP32-S31 で Linux を動かせば、Wi-Fi 6 もそのまま使えますか。

今回公開された最小構成では使えません。カーネルの esp32s31_minimal_defconfig にはネットワーク関連の設定が1行も含まれておらず、デバイスツリーにも無線や Ethernet のノードがありません。Wi-Fi や Bluetooth を使いたい場合、現時点では ESP-IDF 側が公式の道です。

Q2. ESP32-S3 や ESP32-C6 でも同じことはできますか。

同じやり方ではできません。§1 のとおり、これらのチップにある「MMU」はフラッシュや PSRAM をアドレス空間に見せるための読み出し専用のアドレス変換器で、Linux が要求するページテーブルとページフォルトの仕組みではないからです。ただし MMU 付き CPU をソフトウェアでエミュレートする方法はあり、初代 ESP32 上で TinyEMU を使って Linux を起動させた例（起動 1分35秒）が公開されています。

Q3. どのボードが必要ですか。

Buildroot の defconfig 名は espressif_esp32s31_function_core_board_nor_defconfig で、ESP32-S31-Function-CoreBoard-1 向けです。デバイスツリーのメモリ記述は 16MiB で、PSRAM がその容量で載っていることが前提になります。

Q4. 開発者プレビューを製品に使えますか。

公式が明確に「まだ本番利用は推奨しない」と書いています。加えて、予告なしの破壊的変更・不定期な更新・API/ABI 互換性の無保証・ベストエフォートのバグ修正が明記されています。評価やプロトタイピング向けと考えるのが妥当です。

Q5. ESP-IDF から乗り換えるべきですか。

乗り換えを検討する段階ではありません。Espressif が ESP32-S31 の量産発表で挙げているソフトウェアサポートは ESP-IDF とそのエコシステムで、無線スタックも省電力機構もそちらにあります。Linux BSP は用途が重なる場面が限られており、いまは「別の選択肢が生まれた」段階です。

Q6. Raspberry Pi のような使い方ができますか。

想定している資源の規模がまったく違います。今回の構成で Linux が使えるメモリは 16MiB の PSRAM、ルートファイルシステムは 4MiB の読み取り専用 cramfs、カーネルは RAM に展開せずフラッシュ上で直接実行（XIP）されます。汎用の Linux ボードというより、組み込み機器のファームウェアを Linux で書くための足場と捉えるほうが実態に近いはずです。

Q7. このパッチはアップストリームの Linux に入りますか。

現時点では espressif/linux のフォークのブランチとして公開されている段階です。アップストリームへの提出計画について、公式リポジトリのドキュメントには記載を確認できませんでした。

関連記事

参考