吾爱破解 - 52pojie.cn

 找回密码
 注册[Register]

QQ登录

只需一步,快速开始

查看: 306|回复: 7
上一主题 下一主题
收起左侧

[原创] Kindle 第八代救砖实录

  [复制链接]
跳转到指定楼层
楼主
futurebook 发表于 2026-8-11 20:34 回帖奖励
本帖最后由 futurebook 于 2026-8-11 20:51 编辑

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 电脑端软件配置
  1. 先装对应串口模块的驱动,我这CH340的直接搜官网驱动装上就行。
  2. 装个串口终端软件,Putty、Xshell都行。
  3. 串口号去设备管理器里看,是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          65536       987135     921600  450M  83 Linux
/dev/mmcblk0p2         987136      1118207     131072   64M  83 Linux
/dev/mmcblk0p3        1118208      1249279     131072   64M  83 Linux
/dev/mmcblk0p4        1249280      7634943    6385664  3118M  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 最有价值的几条经验

  1. 先看分区,别盲目刷机
    遇到砖机先查分区表,再找系统自带的配置确认分区用途,别上来就格式化系统分区,很容易把本来没问题的系统搞炸。
  2. 卡大树不一定是系统坏了
    无限重启大概率不是根分区挂了,持久化状态分区损坏的可能性很高。尤其是刷机搞出来的故障,很多都是状态分区写坏了。
  3. 数据不重要就大胆清状态区
    不打算保留原数据的话,重建LocalVars分区比重刷整包简单太多,风险也小。

4.3 极简操作流程(速查版)

以后再遇到同款故障,按这个流程走就行:

  1. 接TTL进底层Shell
  2. fdisk -l /dev/mmcblk0 查看分区
  3. cat /etc/default/layout 确认 LOCAL_P 对应的分区号
  4. 卸载对应分区:umount /var/localumount /mnt/local
  5. 重建分区:mkfs.ext3 -F /dev/mmcblk0pX(第八代对应p3)
  6. sync 同步数据
  7. echo b > /proc/sysrq-trigger 强制重启
  8. 等待系统自动初始化,进入桌面

总的来说,这次最大的收获不是「格式化p3能救Kindle」,而是搞懂了救砖的思路:别上来就照着教程硬刷,先读懂设备自己的分区布局和启动逻辑。很多看起来像系统崩了的问题,其实只是个小分区坏了而已。

免费评分

参与人数 1吾爱币 +1 收起 理由
khezhe + 1 我很赞同!

查看全部评分

发帖前要善用论坛搜索功能,那里可能会有你要找的答案或者已经有人发布过相同内容了,请勿重复发帖。

沙发
青春作伴 发表于 2026-8-12 11:45
其它的基本能看懂,就是TTL接线不会,进步在于折腾。
3#
Pojie5206 发表于 2026-8-12 13:12
4#
hemisphere 发表于 2026-8-12 13:34
5#
司空果果 发表于 2026-8-12 15:42
嗯。。。属于动手和动脑能力都挺强的选手
6#
AlfredQiu 发表于 2026-8-12 16:32
现在还可以入手kindle吗,几年前有一个,后面坏了就退坑了
7#
fiyta 发表于 2026-8-12 18:39
动手和动脑能力都挺强的
8#
ang123 发表于 2026-8-12 23:27
动手和理论缺一不可
您需要登录后才可以回帖 登录 | 注册[Register]

本版积分规则

返回列表

RSS订阅|小黑屋|处罚记录|联系我们|吾爱破解 - 52pojie.cn ( 京ICP备16042023号 | 京公网安备 11010502030087号 )

GMT+8, 2026-8-13 02:35

Powered by Discuz!

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表