两周前刷到 XDA 那篇稿子，标题写着 ESP32-S31 能跑 Linux、正在往单板计算机靠。我扫了一眼，手指已经在滚轮上了——这类标题一个季度能撞见三回。把我按回来的是后面两行：Sv32 二级页表，Machine / Supervisor / User 三种特权模式。
脑子里第一句是：哦，来真的了。
先把 MMU 掰扯清楚，不然"能跑 Linux"这四个字会把关键信息盖掉。乐鑫的芯片一直挂着一个叫 MMU 的模块，但那不是一回事。老那个只干块映射——把外部 flash 和 PSRAM 塞进地址空间，谁碰哪段内存全凭软件自觉，跟操作系统要的虚拟内存两码事。S31 这个是真正的地址转换：32 位 RISC-V 标准的两级页表，缺页能陷入，三种特权模式各管一摊。
差别到底多大？跑 Linux 从来不是门槛，没有 MMU 的芯片早就在跑了。代价是所有进程共享一个地址空间，一个野指针写飞，整机陪葬。只烧一个定死的应用上去，这代价可以接受；想在上面同时跑几个服务、还要让它们互相够不着，那就没得谈——fork 你都不敢用。
S31 补的就是这块。内核在 Supervisor，固件在 Machine，跟正经 RISC-V Linux 机器一个路子。这条才是它和 P4 那代真正的分界线，比千兆网重要得多。
反过来，最被拿来说事的千兆网，我认为最该打折。
官方板子的接法：MAC 在片内，PHY 外挂，走 RGMII，出来一个全尺寸 RJ45。P4 那条是百兆，S31 直接十倍。听着是爽。
但 MAC 是千兆 MAC，跟"你能跑出千兆"是两码事。有人按 320MHz 估过一笔周期账：处理一个满帧大概吃掉三千九百个周期，最短的帧两百出头。
320 MHz ÷ 3900 cycles ≈ 82.1k pps # 满帧
320 MHz ÷ 215 cycles ≈ 1.49M pps # 最小帧
千兆线速本身是多少：
1e9 bps ÷ (1518 B × 8) ≈ 81.3k pps # 满帧
1e9 bps ÷ (64 B × 8) ≈ 1.49M pps # 最小帧
两边几乎是贴着的。翻译一下：要打满千兆，得有一个核全程光搬帧、别的什么都不干，才刚刚够。那网络栈住哪？中断处理住哪？另一个核在忙什么？而且上面算的只是"处理一帧"的周期，没算把数据搬进 PSRAM 的那趟拷贝。
这算法很粗暴，我直接把协议栈开销当零了，实际情况只会更难看。但方向不会错：它给了你一个千兆的接口，没给你千兆的余量。
真正让我清醒过来、意识到它还是颗 MCU 的，是内存。
片上 512KB SRAM，没有 DRAM 控制器。封装里可选 16MB 或 32MB PSRAM，对外最多支持到 64MB。现在那两个社区移植——一个在 Supervisor 模式下跑 Linux 6.18、几乎所有硬件都有可用驱动，另一个跑 7.1 已经能推 800x480 的 LCD 控制台——内核是怎么安置的？从 flash 里直接执行，把宝贵的 PSRAM 省给用户态。
这招聪明，代价也直白。Flash 的随机读延迟跟内存不是一个量级，而 XIP 意味着每一次取指、每一次缺页，都可能扎到 flash 上去。
PSRAM 这条路也不宽：
250 MHz × 8 bit × 2 (DDR) = 4 Gbit/s = 500 MB/s
← 峰值，而且是大块顺序传输下的理想情况
串行接口的 PSRAM，随机访问延迟跟 DDR 完全没法比。Sv32 页表一旦开始频繁缺页，每一次都得走这条路——那就不是"慢一点"的问题了，是"能不能忍"的问题。
这段我没法实测，手头也没板子，上面全是推演。但看那两个移植还停在"点亮控制台"的阶段，我觉得推演偏不了太远。
还有件事让我决定先按兵不动：S31 的数据手册现在还是 0.5 版，页脚挂着 PRELIMINARY 水印。同一份文档里，PSRAM 的最高时钟写着 80MHz——跟对外公布的 250MHz 对不上。
这种自相矛盾在早期文档里很正常，不必大惊小怪。但信息量很清楚：这产品的生命周期还在很前面。乐鑫自己 8 月放出来的那套 Buildroot + U-Boot BSP，也明说了不推荐用于生产环境。
画外音：厂商说"不建议上生产"的时候，一般意味着"我们心里也没底"。
名字顺便吐槽一句。S31 第一反应会是"S3 的加强版"，其实两者关系不大。乐鑫的人在 Hackaday 评论区解释过，他们从没打算把 CPU 架构塞进产品名——现在的 S 系列指"高性能、外设丰富"，跟指令集没关系；C 系列走 RISC-V，S 系列之前一直是 Xtensa LX7。S31 这个核是从 P4 那边下来的，官方口径是速度接近 S3 的两倍。
所以拿 S3 的心智模型去套 S31，会很难受。它不是 S3 的下一版，是一颗新东西借了个旧名字。
评论区倒是挺能反映需求那一面。有人问能不能跑 Pi-hole——这问题问得很代表性，Pi-hole 根本不考验 CPU，它考验的是"我把它丢在角落里三年不管，它还活着吗"。这恰好是 MCU 的主场。
也有人更实际，希望那个 RJ45 能带上 PoE。还有人唱反调，说压根不关心这个，他要的是功耗能对标 TI、Silicon Labs 那几家的 Zigbee 芯片——巧的是 S31 确实塞了个 802.15.4 电台，Thread 和 Zigbee 都能干，底下马上有人接话：C6 做终端和路由，S31 拿去当协调器，刚合适。
还有人惦记着拿它跑老式 PC 模拟器。这个我就不评论了，当年在这类念头上缴的智商税，够买一打开发板 😅。
那篇文章结尾把话头引向"未来 ESP32 有可能成为树莓派的平价替代"，这个方向我不跟。
我的结论很简单，也不平衡：这不是一颗去抢树莓派饭碗的芯片。它的价值在于让"本来只配裸机写 C 的活，现在能用 Linux 生态来干，并且还保住 MCU 的成本和功耗"。16MB PSRAM 上跑桌面？别想了，连个现代浏览器都起不来。跑一个 5 瓦以下、常开、带完整网络栈、还能用 cgroup 把几个服务隔开的采集器/网关/协调器，才是它该待的位置——那颗独立的 40MHz 低功耗核就是为这种"主核睡大觉、它守着中断"的用法准备的。千兆网在这儿的作用也不是让你把带宽吃满，是让"我这儿只有千兆交换机能接"的部署场景别卡在百兆上。
留一条我自己会遵守的规则：数据手册上还挂着 PRELIMINARY 水印的芯片，所有参数按七折听，方案等 BSP 出 1.0 再定。S31 我会盯着，但现在还不到掏钱的时候。