Linux บน ESP32-S3 เรื่องนี้คืออะไร?

Project Linux-on-esp32-S3 ทำให้ Linux Kernel 6.11 รันบน ESP32-S3 พร้อม Userspace ที่มีเครื่องมืออย่าง Bash, BusyBox, MicroPython, GNU Make, Network Utilities และ Writable Storage

จุดสำคัญคือ Linux ไม่ได้รันอยู่บน Computer ภายนอก แล้วใช้ ESP32-S3 เป็นเพียง Peripheral และไม่ได้ใช้ SD Card หรือ External RAM เพื่อคอยพยุงระบบ

Native Linux ต่างจาก Emulator อย่างไร?

Project รุ่นเก่าเคยใช้แนวทาง Emulate RISC-V Machine แล้วให้ Linux รันอยู่บน CPU เสมือนนั้น

แต่ Project ปัจจุบันเปลี่ยนมา Compile Linux สำหรับ Instruction Set ของ ESP32-S3 โดยตรง:

Xtensa

Hardware ที่ Project ใช้จริงคือ ESP32-S3 N16R8

สอง Core อยู่บน Chip เดียวกัน แต่ Linux ใช้เพียงหนึ่ง Core

Architecture นี้ใช้แนวคิด Asymmetric Multiprocessing: สอง Core ทำหน้าที่คนละโลก

สองฝั่งสื่อสารกันผ่าน Shared-memory IPC โดย Linux ใช้ Driver ฝั่งตัวเอง ในการเข้าถึง Network Function ที่ Core 0 จัดการ

ทำไม ESP32-S3 ต้องใช้ NOMMU Linux?

Linux บน Computer ทั่วไป ใช้ MMU ในงานอย่าง Virtual Memory, Process Address Space และ Memory Protection

แต่ ESP32-S3 ไม่มี Hardware MMU แบบที่ Linux Architecture ปกติต้องการ Project นี้จึงรัน:

NOMMU Linux

ผลที่ตามมาคือ:

• ไม่มี Hardware Process Memory Isolation
• ไม่มี Copy-on-write แบบ Linux ปกติ
• การทำ fork() ต้องใช้ Software Backend เพิ่ม
• Native Program ต้องถูก Build ให้ตรงกับ Xtensa/FDPIC
• ไม่สามารถหยิบ Desktop Linux Binary ทั่วไปมารันได้

ไม่มี MMU แล้ว fork() ทำอย่างไร?

Release นี้ใช้ Software Fork Backend ที่จัดการ Private Memory ด้วย Memory Banks / Page Sets แทน Copy-on-write แบบ Linux ทั่วไป

ข้อจำกัดหลักที่ Source ระบุ:

• Fork Backend เป็น UP-only
• Multithreaded Fork ถูก Reject
• Private Memory ต่อ Fork จำกัดไว้ที่ 512 KiB
• ไม่มี Copy-on-write

ทำไมไม่มี Copy-on-write?

Official Project อธิบายว่า Write ที่ผิด Permission บน Hardware นี้ไม่ได้ให้ Restartable Fault แบบที่ระบบ COW ต้องใช้

ใน Linux ที่มี COW ปกติ Idea จะประมาณ:

แต่ Project ระบุว่า ESP32-S3 ไม่ให้ Restartable Fault ในรูปแบบที่เอาไปใช้กับกลไกนี้ได้

Page-set Exchange ใน 0.8

Release 0.8 ใช้ Page-set Exchange เพื่อลด Memory Overhead ของ Process ที่ Fork

Concept คือ Resident Process ไม่จำเป็นต้องเก็บ Backup Page Set ซ้ำกับ Data ที่กำลังอยู่ใน Memory จริง จึงสามารถลดจำนวน Page Set จากแนวคิด N ชุด เป็น N−1 ชุด สำหรับ Process ที่ Share Region

จาก 0.7 ที่ Fault สู่ 0.8: Bug จริงอยู่ที่ Flash Cache

ใน 0.7 Board มี Early-boot Fault ที่เกิดเป็นบางครั้ง และช่วงหนึ่ง Fork Backend ถูกสงสัยว่าเป็นต้นเหตุ

แต่การไล่ปัญหาต่อพบว่า Root Cause อยู่ในอีกจุด:

ESP32-S3 ใช้ Flash Cache ร่วมระหว่างสอง Core แต่ Firmware เดิมไม่ได้ Invalidate Exact Range หลัง Write / Erase ที่ Linux ขอ

Fix ใน 0.8 จึงแก้ Firmware ให้ Invalidate Flash Cache Range หลัง Linux ทำ Write หรือ Erase

ผลการทดสอบหลัง Fix

0.8 เหลือ RAM หลัง Boot มากขึ้นแค่ไหน?

MemAvailable หลัง Boot

พูดแบบคร่าว ๆ คือ Available Memory หลัง Boot ขยับจากประมาณ 1.3 MB ไปเป็นประมาณ 3.7 MB

Peak Fork Shadow ต่อ Program

Source ระบุว่า make และ jobq ใช้ Spawn แทน Fork ใน Path ที่วัด จึงไม่มี Fork Shadow ในตาราง 0.8

36 Tests / 0 Failed หมายถึงอะไร?

Official Verification Record บันทึก Clean Build จาก Commit 8ea9011 และรายงาน:

• 36 Board Tests
• 0 Failed
• 10 Extra Tests ผ่าน 10/10
• 10 Factory Boots ใน Final-image Record ผ่าน 10/10
• Test ผ่าน Network ทั้ง Telnet, SSH, SCP และ HTTP

Linux รันได้จริง แต่ Limits ก็จริงเหมือนกัน

1. RAM 8 MB ยังเป็นข้อจำกัดใหญ่

Fork Backend ไม่ได้ใช้ Copy-on-write และ Private Memory ต่อ Fork มี Ceiling 512 KiB

หลาย Bash Sessions หรือ Pipeline ขนาดใหญ่ ยังสามารถชนข้อจำกัด RAM ได้

2. Context Switch สามารถ Hold Interrupts ได้นาน

Official Limits ระบุว่า เมื่อ Process ใช้ Private Region เต็ม Ceiling 512 KiB Context Switch สามารถ Hold Interrupts Off ประมาณ:

21.5 ms

ขณะที่ Timer Tick อยู่ที่:

10 ms

3. Linux Binary ทั่วไปไม่ได้รัน

Native Binary ต้อง Target:

Xtensa / FDPIC

ดังนั้น x86, ARM หรือ Desktop Linux Binary ไม่สามารถ Copy ลงมาแล้วรันตรง ๆ

4. Software บางตัวไม่ได้รวมมา

Official README ระบุว่า Image ไม่ได้รวม:

• CPython
• Neovim
• SQLite
• sudo
• doas

Storage: Root Read-only แต่ /etc และ /home เขียนได้

Project ใช้ Flash 16 MB แบ่งพื้นที่ให้ทั้ง Firmware, Linux Kernel, Root Filesystem และ Writable Data

Root Filesystem ถูกอ่านแบบ XIP จาก Flash เพื่อลดการใช้ RAM

ส่วนข้อมูลที่ต้อง Persist เช่น Configuration และ User Data อยู่ใน JFFS2

Flash Release 0.8 ลง ESP32-S3

Repository มี Image ของ 0.8 อยู่ใน images/ และ Quick Path ที่ Official README ให้คือ:

./flash.sh -p /dev/ttyUSB0

/dev/ttyUSB0 เป็นเพียง Example Adapter Path ต้องใช้ Port ที่ตรงกับ Board / Adapter จริง

Build Linux Image จาก Source

Official Project มี Script ที่รวม Flow ตั้งแต่ Check Environment ไปจนถึง Build, Verify, Flash และ Test

git clone https://github.com/paulneja/Linux-on-esp32-S3.git
cd Linux-on-esp32-S3
./run.sh
./run.sh --all -y

Official README ระบุว่า Script แจ้ง Estimate ประมาณ:

• Build Time ราว 40 นาที
• พื้นที่ Disk ราว 21 GB

Build จาก Clean Checkout

Official Instructions ระบุ Host:

• Linux
• Git
• Docker Access

git clone https://github.com/paulneja/Linux-on-esp32-S3.git
cd Linux-on-esp32-S3
JOBS=8 bash build/reproduce.sh

Login ผ่าน Serial แล้วต่อ Wi-Fi

Official README ใช้ Serial Console:

115200 baud

screen /dev/ttyUSB0 115200

wifi

wifi connect "YOUR SSID" "YOUR PASSWORD"

Factory Image ไม่มี Wi-Fi Configuration มาให้ ผู้ใช้จึงต้องเลือก Network เอง

Board นี้เป็น:

STA-only

หมายถึงมัน Join Existing Wi-Fi Network แต่ SoftAP ถูกถอดออกจาก Driver / Firmware และไม่ใช่ Feature ที่รองรับ

บน Linux ตัวนี้ทำอะไรได้บ้าง?

Userspace ที่ Official Project ระบุมี:

• Bash 5.2
• BusyBox
• Dash
• GNU Make
• MicroPython
• socat
• nc
• cron
• session / dtach
• nohup
• Optional HTTP Server
• Optional Dropbear SSH

MicroPython

ตัวอย่างจาก Official README:

micropython /home/root/script.py

Web Page

มี Editable Web Page ที่:

/home/www/index.html

และ Web Server สามารถเปิด / ปิด ผ่าน Command ของ Project

SSH และ SCP

Dropbear SSH ถูกปิดเป็น Default และเปิดได้ผ่าน Project Command

SCP ต้องใช้ Legacy SCP Mode:

scp -O

เพราะ Dropbear Image นี้ ไม่มี SFTP Server และ OpenSSH รุ่นใหม่ ใช้ SFTP เป็น Default

Security: Project นี้ออกแบบมาสำหรับ Workbench และ Trusted LAN

Official SECURITY.md เรียก Project นี้ว่า:

Research Project

และระบุชัดว่า ไม่ควรนำ Board ที่รัน Image นี้ ไปต่อกับ Untrusted Network หรือ Network ที่มีความสำคัญ

Project นี้เหมาะกับอะไร?

ผู้สร้างระบุเองว่าเป็น Research Project ดังนั้นคุณค่าหลักอยู่ที่การทดลอง:

• NOMMU Linux บน Microcontroller
• Native Xtensa Linux
• Software Fork Backend
• Memory Optimisation ภายใต้ RAM 8 MB
• แบ่ง Linux และ Radio Firmware คนละ Core
• Embedded Network Service แบบ Resource-constrained

Hackaday ยกตัวอย่างเชิงแนวคิดว่า อาจนึกถึง Embedded Linux Project ลักษณะคล้าย Network Appliance ที่ใช้ BusyBox

สิ่งที่ Maker เรียนรู้ได้

Project นี้แสดงให้เห็นว่า คำว่า “Linux รันได้” มีหลายระดับ

Kernel Boot ได้ เป็นเพียงจุดเริ่มต้น แต่ถ้าจะให้ระบบใช้จริง ยังต้องแก้:

• Memory Management
• Process Creation
• Filesystem
• Cache Coherency
• Networking
• Build Reproducibility
• Security
• Hardware Validation

โปรเจกต์นี้มีหลายขั้น แนะนำอ่านต้นฉบับควบคู่กัน

README และ Verification ของ Project มีรายละเอียดมากกว่าการ Build ให้ Boot ได้ โดยเฉพาะ Fork Backend, Flash-cache Corruption, Build Manifest, Board Test และ Security Trade-offs

FAQ: Linux 6.11 บน ESP32-S3

สรุป: ความน่าสนใจไม่ใช่แค่ “ESP32 รัน Linux ได้”

Linux 6.11 บน ESP32-S3 น่าสนใจเพราะมันบังคับให้เห็นว่า Operating System ต้องพึ่ง Hardware Feature มากกว่าที่คนใช้งาน Desktop มักสังเกต

บน ESP32-S3 ไม่มี MMU แบบทั่วไป RAM มีเพียง 8 MB Linux ได้ใช้เพียงหนึ่ง Core และ Wi-Fi ต้องพึ่ง Firmware ที่รันอยู่บนอีก Core

แต่ Project ยังพา Bash, MicroPython, Writable Storage, Wi-Fi, Process Creation และ Network Services ให้ทำงานร่วมกันได้

Release 0.8 ยังแสดงอีกอย่างหนึ่ง: ปัญหาที่ดูเหมือน Memory Corruption ไม่จำเป็นต้องเกิดจาก Memory Algorithm ที่สงสัยเสมอไป เพราะต้นเหตุจริงครั้งนี้ กลับเป็น Stale Flash Cache หลัง JFFS2 Write

References / แหล่งข้อมูลต้นฉบับ

• Hackaday — Running Linux 6.11 On The ESP32-S3 With A Few Tweaks
• GitHub — paulneja/Linux-on-esp32-S3
• Linux-on-esp32-S3 — Official README
• Linux-on-esp32-S3 — Architecture
• Linux-on-esp32-S3 — Changelog
• Linux-on-esp32-S3 — 0.8 Final Image Verification Record
• Linux-on-esp32-S3 — Security Notes