Kindle 第八代救砖实录
原创 吾爱pojie 2026-10-08 17:47 北京
从闲鱼30块收了台开不了机的第八代Kindle，初步判断是闲置太久电池饿死了。用5V1A充电充了2小时成功激活，本来到这事儿就结束了，结果手痒想折腾刷机，才有了后面这堆事儿。
作者论坛账号：futurebook
Kindle 第八代救砖实录
一、前情提要
1.1 设备初始状态
从闲鱼30块收了台开不了机的第八代Kindle，初步判断是闲置太久电池饿死了。用5V1A充电充了2小时成功激活，本来到这事儿就结束了，结果手痒想折腾刷机，才有了后面这堆事儿。
1.2 变砖始末
找了网上适配这款机型的 LanguageBreak 越狱教程，顺利进了演示机界面，文件也都拖进去了。第一次刷机没成功，试第二次也不行，想着前两次都没出问题就接着试，结果第三次直接卡在屏保界面开始重启，之后就一直卡在大树启动界面无限循环，彻底变砖。
二、无效方案踩坑实录
砖了之后先后试了网上好几种方案，全是坑，反正我这台是行不通。
方案1：USB瞬连写入 DO_FACTORY_RESTORE
网上说重启的瞬间有极短时间能连上USB，往里面扔一个叫 DO_FACTORY_RESTORE 的空文件，机器识别到就会自动恢复出厂。
结论：死活抓不到那个瞬间，直接放弃。
方案2：彻底放完电再上电恢复
还有说法是把电彻底耗空，等出现低电量界面再插电脑，就能识别USB放恢复文件。
实测：放着让它重启了一整晚，电终于耗空了，早上起来就看见这个低电量界面：
插电充了没一会儿，有电了就自动开机，又开始卡大树无限重启，插USB完全没反应。后来又等电放完，插USB充电的时候，开机瞬间电脑会叮咚一声出现虚盘，等卡大树重启就又消失了，根本来不及操作。
到这儿可以确定：不拆机纯靠USB放文件的方法彻底没戏。
方案3：传统TTL刷固件救砖
B站上不少TTL救砖教程，虽然机型不一样但原理差不多，就照着试了。
结果照着教程输 bootm 命令进恢复界面失败，改启动参数进shell也没反应。后来好不容易进了menu菜单，导出FAT分区放了官方固件 update_kindle_8th_5.15.1.1.bin 升级，还是解决不了卡大树重启的问题。甚至初始化分区表重新格式化再刷固件，照样失败。
网上能搜到的教程全不适配，最后只能自己慢慢摸索。
三、TTL救砖全流程：从定位到修复
好在uboot还能用，还有折腾的空间。踩了一堆坑之后终于找到了问题所在，成功救回。
3.1 准备工作：硬件与软件
3.1.1 所需硬件
USB转TTL串口模块（我用的是CH340系列）
杜邦线若干
绝缘胶带/夹子（用来固定接线）
⚠️
重要注意
：TTL接线时
绝对不能拔掉电池
，不然会直接出电池报错，无法正常启动。
3.1.2 主板接线点位
我的主板型号是SY69JL，和Kindle X 咪咕版应该是一样的，主板整体样貌如下：
串口主要接TX、RX、GND三根线，点位标注如下：
接线对应关系：
TTL模块的 TXD → 主板的 RXD
TTL模块的 RXD → 主板的 TXD
TTL模块的 GND → 主板地（我直接接屏蔽罩上了，随便找个地就行）
我嫌焊接太麻烦，主打一个怎么简单怎么来，直接用杜邦线对准点位，用绝缘胶带和夹子固定住，一样能用。就是要压紧，不然容易出现数据波动。
⚠️ 注意：TTL模块接3.3V电平，别用5V，容易烧坏主板。
3.1.3 电脑端软件配置
先装对应串口模块的驱动，我这CH340的直接搜官网驱动装上就行。
装个串口终端软件，Putty、Xshell都行。
串口号去设备管理器里看，是COM几就选几，串口参数设置如下：
波特率：115200
数据位：8
停止位：1
奇偶校验：无
流控：无
都设置好之后打开串口连接，然后给Kindle上电重启，就能看到启动日志滚动输出，一直按回车就能进到uboot菜单。
3.2 进入底层Shell，确认分区布局
一开始照着教程输命令各种失败，后来等启动日志加载过半的时候按回车，成功进到了menu菜单，想办法进了底层Shell。
进去第一件事，先别瞎刷机，先搞清楚分区都是干嘛的，执行：
复制代码 隐藏代码fdisk -l /dev/mmcblk0
得到分区表：
复制代码 隐藏代码Disk /dev/mmcblk0: 3728 MB, 3909091328 bytes
Device StartLBA EndLBA Sectors Size Id
/dev/mmcblk0p1 65536987135921600450M 83 Linux
/dev/mmcblk0p2 987136111820713107264M 83 Linux
/dev/mmcblk0p3 1118208124927913107264M 83 Linux
/dev/mmcblk0p4 1249280763494363856643118M b Win95 FAT32初步推测分区用途：
分区 | 大小 | 推测用途 |
|---|---|---|
p1 | 450 MB | 系统根分区 RootFS |
p2 | 64 MB | 诊断分区 Diagnostics |
p3 | 64 MB | 本地变量分区 LocalVars |
p4 | 3.1 GB | 用户存储分区 UserStore |
但这只是猜测，不能凭感觉瞎格式化，得找系统自己的配置确认。
3.3 关键突破：确认分区真实用途
查看系统自带的分区布局配置文件：
复制代码 隐藏代码cat /etc/default/layout
里面写得明明白白：
复制代码 隐藏代码case"$(f_platform)"in
luigi) ROOT_P=p1 ; LOCAL_P=p2 ; DIAG_P=p3 ; USER_P=p4 ;;
zelda) ROOT_P=p5 ; LOCAL_P=p6 ; DIAG_P=p5 ; USER_P=p7 ; KEYS_P=p3 ;;
rex) ROOT_P=p8 ; LOCAL_P=p9 ; DIAG_P=p8 ; USER_P=p10 ; KEYS_P=p3 ;;
bellatrix) ROOT_P=p8 ; LOCAL_P=p9 ; DIAG_P=p8 ; USER_P=p10 ; KEYS_P=p3 ;;
*) ROOT_P=p1 ; LOCAL_P=p3 ; DIAG_P=p2 ; USER_P=p4 ;;
esac我这台属于默认布局，直接对应最后一行：
ROOT_P = p1→ 系统根分区
LOCAL_P = p3→ 本地持久化变量分区
DIAG_P = p2→ 诊断分区
USER_P = p4→ 用户存储分区
也就是说，/dev/mmcblk0p3 对应的就是 /var/local。
为了进一步确认，又看了挂载启动脚本：
复制代码 隐藏代码cat /etc/upstart/filesystems_var_local.conf
开头直接写了：# /var/local is the persistent read-write store，也就是系统持久化读写存储区。而且脚本里明确写了，如果这个分区挂载失败，系统会自动执行 mkfs.ext3 重建它。
这一下就给了我明确的思路：问题很可能出在p3分区上。
3.4 确认故障：p3分区异常
先卸载相关分区：
复制代码 隐藏代码umount /mnt/local 2>/dev/null
umount /mnt/userstore 2>/dev/null检查p3分区，虽然能识别出是ext3文件系统、卷标是LocalVars，但状态有异常。
既然原数据本来就不重要，那直接重建这个分区就完事了。
3.5 核心操作：重建 LocalVars 分区
执行格式化命令，重建p3的文件系统：
复制代码 隐藏代码mkfs.ext3 -F /dev/mmcblk0p3
执行完成后，手动挂载验证一下：
复制代码 隐藏代码mkdir -p /mnt/local
mount -t ext3 /dev/mmcblk0p3 /mnt/local
ls -lah /mnt/local输出只有 lost+found 目录，就是全新的ext3分区正常的状态。
这里不用手动往里面塞任何系统文件，系统本身自带初始化资源，启动的时候会自动把必要的目录和配置创建好，直接让它自己初始化就行。
3.6 强制重启系统
格式化完成后先同步数据、卸载分区：
复制代码 隐藏代码sync
umount /mnt/local这时候直接输 reboot 是没用的——因为我们现在是救援Shell环境，init=/bin/sh，不是正常的系统运行环境，reboot命令不会真的重启硬件。
直接用SysRq强制重启：
复制代码 隐藏代码sync
echo b > /proc/sysrq-trigger设备会立刻重启。
3.7 成功恢复
重启之后，之前一直循环的「大树→黑屏→重启」终于变了。这次大树界面过后出现了进度条，顺利走完启动流程，成功进入Home界面。
之后又正常重启了一次，同样顺利进入系统，确认完全恢复正常。
✅ 救砖成功！
四、经验总结
4.1 到底修好了什么？
这次既没重刷整个系统，也没动根分区、bootloader和用户数据，全程只做了一件核心的事：
复制代码 隐藏代码mkfs.ext3 -F /dev/mmcblk0p3
也就是重建了 /var/local 对应的 LocalVars 持久化状态分区。
Kindle的启动流程不只是加载系统那么简单：挂载完根分区之后，还要读取 /var/local 里的系统状态、数据库、配置文件，才能继续启动框架和图形界面。如果这个分区损坏或者状态异常，哪怕根分区完全完好，系统也会启动失败，触发看门狗重启，表现就是卡大树无限循环。
4.2 最有价值的几条经验
- 先看分区，别盲目刷机
遇到砖机先查分区表，再找系统自带的配置确认分区用途，别上来就格式化系统分区，很容易把本来没问题的系统搞炸。
- 卡大树不一定是系统坏了
无限重启大概率不是根分区挂了，持久化状态分区损坏的可能性很高。尤其是刷机搞出来的故障，很多都是状态分区写坏了。
- 数据不重要就大胆清状态区
不打算保留原数据的话，重建LocalVars分区比重刷整包简单太多，风险也小。
4.3 极简操作流程（速查版）
以后再遇到同款故障，按这个流程走就行：
接TTL进底层Shell
fdisk -l /dev/mmcblk0查看分区
cat /etc/default/layout确认
LOCAL_P对应的分区号卸载对应分区：
umount /var/local或umount /mnt/local重建分区：
mkfs.ext3 -F /dev/mmcblk0pX（第八代对应p3）sync同步数据
echo b > /proc/sysrq-trigger强制重启
等待系统自动初始化，进入桌面
总的来说，这次最大的收获不是「格式化p3能救Kindle」，而是搞懂了救砖的思路：别上来就照着教程硬刷，先读懂设备自己的分区布局和启动逻辑。很多看起来像系统崩了的问题，其实只是个小分区坏了而已。
-官方论坛
www.52pojie.cn
👆👆👆
公众号设置“星标”，您不会错过新的消息通知
如开放注册、精华文章和周边活动等公告
本文转载自微信公众号「吾爱破解论坛」，查看原文。版权归原作者所有，如有侵权请联系删除。