「在 MCU 上跑 Linux」這句話，我過去十年聽到的反應大概都是同一種：好玩，但沒用。RAM 只有幾百 KB、沒有 MMU、每個 process 共用同一塊位址空間，就算硬塞進去，你得到的也只是一個開機要半分鐘、隨時會被一個野指標拖垮的玩具。
ESP32-S31 讓我開始重新想這個問題。
Espressif 在 3 月發表、7 月量產的 ESP32-S31 ，是一顆雙核 RISC-V、320 MHz、帶 MMU 的 Wi-Fi 6 MCU。8 月，官方釋出了 Linux 6.18 的 BSP 開發者預覽版（CNX Software 的報導 ）；現在社群已經在上面跑起 Alpine Linux，用 apk add 裝套件。同一時間，Espressif 又在 10 月推出 esp-pqc ，把後量子密碼帶進 ESP32 的 TLS 和 Secure Boot。
這篇我想從韌體工程師的角度回答兩個問題：S31 到底離「能用的嵌入式 Linux」還有多遠？後量子密碼塞進 MCU 之後，開機和連線要付出多少代價？
閱讀前提
- 適合讀者：嵌入式／韌體工程師、正在評估 MCU vs MPU 方案的硬體團隊
- 前置知識：知道 MMU、bootloader、Secure Boot、TLS 握手的基本概念
- 版本基準：ESP32-S31 Linux BSP developer preview（Linux 6.18、Buildroot 2025.02）、esp-pqc（需 ESP-IDF v6.0 以上）
- 狀態提醒：S31 的 Linux BSP 官方明說不建議用於量產，本文所有 Linux 內容都是預覽階段
S31 是一顆什麼樣的晶片
先把規格攤開。根據 Espressif 的 發表新聞 和 量產公告 ，S31 的定位是「高效能 AIoT SoC」，主打智慧家電、智慧音箱、語音控制和工業自動化：
| 項目 | ESP32-S31 |
|---|---|
| CPU | 雙核 32-bit RISC-V，320 MHz，支援 MMU |
| 向量運算 | 其中一核有 128-bit 資料路徑與 SIMD 指令 |
| 記憶體 | 512 KB SRAM，外接 8-bit DDR PSRAM（250 MHz），flash 與 PSRAM 可同時存取 |
| 無線 | Wi-Fi 6（2.4 GHz）、藍牙 5.4（含 LE Audio 與 Classic）、IEEE 802.15.4（Thread／Zigbee） |
| 有線 | Gigabit Ethernet MAC、High-speed USB OTG |
| 多媒體 | 8–24-bit 平行 LCD、8–16-bit DVP 相機、JPEG codec、2D 圖形加速 |
| 安全 | PUF 金鑰管理、Secure Boot、flash／PSRAM 加密、TEE、抗旁路與電壓突波攻擊 |
| 其他 | 60 GPIO、CAN 2.0（TWAI）、雙 I2S |
如果拿它跟熟悉的兩顆比較，S31 的特別之處就很清楚了（S3 與 P4 規格參考 Espressif 的 ESP32-S3 與 ESP32-P4 產品頁）：
| ESP32-S3 | ESP32-P4 | ESP32-S31 | |
|---|---|---|---|
| CPU | 雙核 Xtensa LX7，240 MHz | 雙核 RISC-V，400 MHz | 雙核 RISC-V，320 MHz |
| 無線 | Wi-Fi 4、BLE 5 | 無 | Wi-Fi 6、BT 5.4、802.15.4 |
| 有線網路 | 無 | Ethernet MAC | Gigabit Ethernet MAC |
| Linux 需要的分頁式 MMU | 無 | 無 | 有 |
S3 有無線但效能有限，P4 效能強但沒有無線，S31 剛好卡在中間，而且是 Espressif 這幾顆裡第一個讓「標準 Linux」變成合理選項的。
為什麼 MMU 才是關鍵
很多人以為 MCU 跑不動 Linux 是因為時脈太低、RAM 太小。其實更根本的障礙是 MMU。
沒有 MMU 的 Linux（nommu，也叫 uClinux 路線）不是不能跑，在沒有分頁式 MMU 的 MCU 上硬跑 Linux，走的就是這條路。但代價很大：沒有虛擬記憶體，就沒有真正的 fork()，只能用 vfork()；所有 process 共用同一個實體位址空間，一個程式寫爆記憶體，整台機器跟著陪葬；大部分現成的 Linux 使用者空間軟體都得重新編譯或改寫，套件管理器基本上別想了。
有了 MMU，每個 process 都有自己的虛擬位址空間，核心可以做記憶體保護、按需分頁、標準的 ELF 載入。這就是為什麼 S31 上可以直接跑 Alpine 的 apk：那些套件不用為 nommu 特別改過。
不過「有 MMU」不等於「是 MPU」。S31 的 Linux 設定是 RV32、ILP32 ABI、soft-float，也就是沒有硬體浮點可用，所有浮點運算都靠軟體模擬。主記憶體則是外接的 PSRAM，社群整理的現況報告 提到的實驗配置是 16 MiB。跟動輒 4–8 GB DDR 的 MPU 比，這是完全不同的量級。
開機鏈：從 ROM 到 BusyBox
Espressif 的 BSP 採用標準 RISC-V Linux 的開機流程，各元件都有專屬的整合分支：
Mask ROM -> U-Boot SPL -> OpenSBI 1.6（M-mode 韌體） -> U-Boot 2024.07
-> Linux 6.18（從 NOR flash XIP 執行） -> CramFS 唯讀根目錄 -> BusyBox shell
這條鏈裡有兩個設計，我覺得特別能看出「在 MCU 上跑 Linux」的取捨。
Linux 核心是 XIP（eXecute In Place），直接從 NOR flash 執行，不用先複製到 RAM。這在 RAM 只有十幾 MB 的系統上非常重要，核心的程式碼段不佔寶貴的 PSRAM。根目錄用唯讀的 CramFS，也是同樣的考量。
OpenSBI 是 RISC-V 世界的標準 M-mode 韌體，負責 Linux（S-mode）與硬體之間的 SBI 呼叫。S31 走這條標準路線，代表未來往上游 kernel 合併的機會比較高，不會變成一個只有 Espressif 維護的孤兒分支。
實際動手：編譯一份 S31 的 Linux
先說清楚：我手上還沒有 S31 的實機，下面的步驟整理自官方 esp-buildroot-external 的 README，加上社群的回報。你需要 Buildroot 2025.02.11 以上，以及支援 S31 的 esptool。依 daily.dev 整理的 CNX 報導 ，esptool 需要 5.3.0 以上，4.7.0 這類舊版不行：
# 1. 取得對應的 Buildroot
git clone --branch 2025.02.x --depth 1 \
https://gitlab.com/buildroot.org/buildroot.git ~/buildroot
git clone https://github.com/espressif/esp-buildroot-external ~/esp-buildroot-external
# 2. 套用 S31 開發板的 defconfig
make -C ~/buildroot \
BR2_EXTERNAL=~/esp-buildroot-external \
O=~/s31-out \
espressif_esp32s31_function_core_board_nor_defconfig
# 3. 編譯（社群回報第一次要超過一小時）
ESP_ESPTOOL=$(which esptool) \
make -C ~/buildroot O=~/s31-out -j"$(nproc)"
# 4. 板子進入下載模式後燒錄整顆 flash
esptool --chip esp32s31 --port /dev/ttyUSB0 --baud 1152000 \
write-flash 0x0 ~/s31-out/images/s31_full_flash.bin
燒完用 115200 baud 開序列埠，順利的話會一路跑到 root shell。如果你的編譯主機不是 x86_64 或 AArch64 Linux，官方說要在 defconfig 加上 BR2_TOOLCHAIN_BUILDROOT_MUSL=y。燒錄不穩的話，把 baud 降到 460800。
社群走得更遠。esp32s31-alpine 這個專案在 ESP32-S31 Function-CoreBoard-1 上，用 Espressif 的核心開機、從 USB 隨身碟的 ext4 分割區載入 Alpine 的根目錄，登入時大約還有 9.6 MiB 可用 RAM。Ethernet 開機就透過 DHCP 拿到 IP，apk add nano 可以從網路安裝並驗證簽章。
9.6 MiB 是什麼概念？以我的經驗推估，跑一個輕量的 MQTT client、一個小型 web 管理介面、幾個 shell script 應該沒問題；想跑 Python 或 Node.js 就會很吃緊。這部分目前還沒看到實測數據。
Linux 編譯的坑
esptool 版本太舊。 用系統套件管理器裝的 esptool 常常是 4.x，不認得 S31。用 pip install -U esptool 裝新版，並確認 ESP_ESPTOOL 指到正確的執行檔。
非 Linux 主機編不過。 官方只保證 x86_64 和 AArch64 Linux 主機，其他平台要在 defconfig 加 musl 工具鏈設定。在 macOS 上，我會直接開 Docker 或 Linux VM 來編，省掉很多麻煩。
現在能拿來做產品嗎？
老實說，還不行。
esp-buildroot-external 的 README 明講這是 developer preview，「not yet recommended for production use」，更新不定期、可能有破壞性變更、bug 修正採 best effort。社群整理的 現況報告 也列了幾個具體問題。要注意前兩個是 ESP-IDF 層的問題，不是 Linux BSP，但它們說明了 S31 的周邊驅動整體還不成熟：
UART3 的訊號定義是 -1。 ESP-IDF 的 uart_periph.c 裡，UART3 的 TX/RX 被定義成 -1（IDFGH-18333），可能造成 GPIO Matrix 繞線錯誤，甚至越界存取暫存器。做 RS-485、Modbus RTU 的人要特別小心，先避開 UART3。
藍牙 A2DP 相容性不穩。 跟某些喇叭能連，跟某些會在 LMP／角色協商時失敗。
Linux 下的 Wi-Fi 查無公開資料。 我找到的成功案例都是走 Ethernet，沒有看到 Wi-Fi 在 Linux BSP 裡運作的公開紀錄。這不代表它不能用，但在有人實測之前，別把產品規劃押在上面。
所以我會這樣選：
| 需求 | 建議方案 |
|---|---|
| 量產的 Wi-Fi／Matter 裝置 | S31 + ESP-IDF（FreeRTOS），穩定成熟 |
| 需要 Linux 生態、有 Ethernet、RAM 需求 < 10 MB | S31 + Linux，先當 PoC |
| 要跑 Python、容器、AI 推論 | 直接上 MPU，例如我之前測過的 RK3588 |
S31 Linux 最有吸引力的場景，是那種「本來要用一顆 MPU 加一顆 Wi-Fi 模組，現在想縮成單晶片」的閘道器。但前提是你能接受預覽版的風險，而且你的應用真的塞得進 10 MB。
esp-pqc：把後量子密碼塞進 MCU
為什麼一篇講 S31 Linux 的文章要談後量子密碼？因為 S31 這類晶片越來越像「一台小電腦」，它要撐的產品壽命也越來越長，而 S31 本身就把 Secure Boot、flash 加密、TEE 當成賣點。一台 2026 年出貨的智慧家電，十年後可能還在用；如果那時量子電腦真的能破解 RSA 和 ECC，現在的韌體簽章和 TLS 金鑰交換就全都不安全了。更麻煩的是「先收集、後解密」：攻擊者今天錄下你的加密流量，等量子電腦成熟再解開。
NIST 在 2024 年 8 月正式公布了兩個後量子標準：用來交換金鑰的 ML-KEM（FIPS 203）和用來簽章的 ML-DSA（FIPS 204）。Espressif 10 月發布的 esp-pqc ，就是把這兩個演算法帶進 ESP-IDF。它基於 liboqs，包含 Espressif 自己的 liboqs fork 和一個 mbedTLS override，支援所有 Espressif SoC，但需要 ESP-IDF v6.0 以上。
要注意的是，官方的 benchmark 是在 ESP32-C5 上跑的，不是 S31。不過演算法本身是純軟體，數字可以當作同級 RISC-V 晶片的參考。
混合 TLS 1.3：握手要多久
esp-pqc 示範的是 X25519MLKEM768 混合金鑰交換：傳統的 X25519 加上後量子的 ML-KEM-768，兩個都要被破解才算破。這是目前業界過渡期的主流做法，萬一新演算法哪天被發現有弱點，至少還有傳統演算法撐著。
| 項目 | 數值 |
|---|---|
| 握手時間（ESP32-C5，含區網往返） | 約 300 ms |
| X25519MLKEM768 key share | 1,216 bytes |
| ML-DSA-65 公鑰 | 1,952 bytes |
| ML-DSA-65 簽章 | 3,309 bytes |
300 ms 對 IoT 裝置來說完全可以接受，真正的成本在尺寸。ML-DSA-65 的簽章是 3.3 KB，比 ECDSA P-256 的 64 bytes 大了五十倍。TLS 的 I/O buffer 得跟著加大，憑證鏈一長，SRAM 和封包數都會明顯上升。在 512 KB SRAM 的 MCU 上，這是要認真算的帳。
混合 Secure Boot：兩把鑰匙一起驗
對韌體工程師來說，Secure Boot 這部分比 TLS 更切身。esp-pqc 示範的混合 Secure Boot V2，會在原本的 RSA 或 ECDSA 簽章之外，再加一個 ML-DSA-65 簽章，兩個都通過才開機。官方在 ESP32-C5 以 80 MHz 實測：
| 步驟 | 時間 | CPU cycles | 加速方式 |
|---|---|---|---|
| SHA-256（映像檔 + 傳統簽章區） | 約 30 ms | 2,465,694 | 硬體 |
| ML-DSA-65 驗證 | 約 44 ms | 3,533,980 | 軟體 |
| RSA-PSS-3072 驗證 | 約 13 ms | 1,095,604 | 硬體 |
| 官方標示總計 | 約 91 ms | 7,328,597 |
細心的讀者會發現，三步驟的時間加起來是 87 ms、cycles 加起來是 7,095,278，跟官方標示的總計對不上，官方文章沒有說明差異來源。文章的結論則寫道，PQC 驗證「only ~78 ms」，也就是只讓開機時間增加約 78 ms，flash 多用 8 KB（簽章區總共 12 KB，4 KB 傳統加上 8 KB PQC）。這三個數字（78、87、91 ms）的換算方式官方都沒交代，我建議把它們看成「大約多 0.1 秒」的量級就好。
這裡有個我覺得比數字更重要的細節：Mask ROM 只支援傳統的 Secure Boot V2，所以 PQC 驗證只能放在第二階段 bootloader 執行。
換句話說，信任鏈的根仍然是傳統密碼學。ROM 用 RSA／ECDSA 驗證第二階段 bootloader，bootloader 再用混合簽章驗證 app。如果有一天 RSA 真的被量子電腦打穿，攻擊者只要偽造一個 bootloader 簽章，後面的 ML-DSA 就形同虛設。這跟我前一篇寫 GPU Unlock 時講的道理一樣：信任鏈的強度取決於最弱的那一環，而那一環通常在最底層、最難更新的地方。
Espressif 自己也很清楚，官方說未來的 SoC 會加入專用的後量子硬體加速，並把 PQC Secure Boot 內建進去。在那之前，esp-pqc 的定位是評估與 benchmark 用，不是量產方案。
導入 PQC 前要想清楚的事
以下兩點都來自 esp-pqc 官方文章列出的限制：
ML-DSA 私鑰管理。 混合 Secure Boot 多了一把 ML-DSA 私鑰要保管。弄丟或外洩，就沒辦法再推送可信任的韌體更新；要更換 bootloader 信任的金鑰，得重新燒錄 bootloader。在 CI 裡導入之前，請先把 HSM 或金鑰保管流程想清楚。
TLS buffer 要加大。 後量子憑證比傳統憑證大得多，官方範例的 CA 憑證就有 7,571 bytes，TLS 的 I/O buffer 得跟著加大。沿用預設大小的話，我預期握手會在收憑證時出問題，導入前務必先算好 SRAM 預算。
S31 現在買得到嗎？
可以。Espressif 在 2026 年 7 月 27 日宣布量產，可以從 Espressif 官方 AliExpress 商店購買，或洽詢業務。開發板價格各通路說法不一，建議以實際通路為準。
esp-pqc 能用在 ESP32-S3 這類舊晶片嗎？
元件本身支援所有 Espressif SoC，但需要 ESP-IDF v6.0 以上。bootloader 的 PQC 驗證目前只列出 ESP32-C3、C5、C6。舊晶片沒有後量子硬體加速，一切靠軟體算，速度會比 C5 的數字更慢。
我的產品現在就該上 PQC 嗎？
如果產品壽命超過十年、處理敏感資料，現在就該開始評估，至少先確認 flash 和 SRAM 預算夠不夠放下更大的簽章和憑證。如果是一般消費性產品，可以先追蹤，等未來有硬體加速和 ROM 層級支援的 SoC 再上。
結語：我會怎麼用 S31
S31 不會取代 MPU，9.6 MiB 的可用 RAM 和軟體浮點就決定了它的天花板。但如果我現在要做一個需要 Ethernet、需要標準 TCP/IP 工具、需要用 shell 除錯的閘道器，S31 會是我第一個拿來做 PoC 的晶片，而不是直接放一顆 MPU 加 Wi-Fi 模組。量產則還是乖乖用 ESP-IDF，等 Linux BSP 脫離預覽再說。
esp-pqc 我會先拿來量自己產品的 flash 和 SRAM 預算夠不夠放下 PQC 簽章，而不是急著上線。真正要導入，我會等 ROM 層級就支援 PQC 的下一代晶片。
你手上如果已經有 S31，照著官方步驟編過 Linux 的話，很想知道你量到的開機時間和可用記憶體，歡迎跟我分享。
參考資料
| 來源 | 標題 |
|---|---|
| Espressif | Espressif Unveils ESP32-S31 |
| Espressif | ESP32-S31 Now in Mass Production and Available for Purchase |
| Espressif Developer Blog | Post-Quantum Cryptography on ESP32 |
| GitHub | espressif/esp-buildroot-external |
| GitHub | Alpine Linux on the ESP32-S31 |
| note.com | Summary of Key ESP32-S31 Updates (as of September 24, 2026) |
| CNX Software（X） | ESP32-S31 is getting official Linux support |
| daily.dev | Espressif releases a Linux BSP developer preview for ESP32-S31 |
| Espressif | ESP32-S3 產品頁 |
| Espressif | ESP32-P4 產品頁 |
沒有留言:
張貼留言