nand.bin还原系统什么是刷机中的FASTBOOT，如何烧录img，bin，mbn，elf等镜像文件

发布时间 : 2024-10-07

作者 : 小编

访问数量 : 23

扫码分享至微信

什么是刷机中的FASTBOOT，如何烧录img、bin、mbn、elf等镜像文件

1. 什么是手机上的FASTBOOT模式？

顾名思义，FASTBOOT这个名词可以理解为“快速启动”的中文意思。但在安卓手机中，则代指一种比Recovery更底层的刷机救援模式，亦被称作“引导模式”、“线刷模式”或“Bootloader模式”。与主要采用手机屏幕及实体按键交互的Recovery模式不同，在FASTBOOT模式下，需要将设备通过数据线连接至PC端，并通过CUI命令行或GUI图形界面的方式，向设备传输各种指令来实现操作（本质上还是CUI交互）。

配合各种不同的指令，FASTBOOT模式具有强大而丰富的功能特性，刷机和解锁也只是其中最常用到的操作而已。

2. 如何进入与退出FASTBOOT模式？

目前所有的小米手机都可以通过如下方式进入和退出FASTBOOT模式：

2.1 进入方式

同时长按电源键+音量下键进入（实测在电源键坏了的情况下，长按音量下键也可以）

关机及关机充电状态下：按上述组合键约3-6秒后进入。

重启状态下：一点重启就按上述组合键约10-15秒

当在手机屏幕看到如下图所示的“米兔修机器人”画面时，则说明已经成功进入FASTBOOT模式。

3. 如何在PC端安装FASTBOOT驱动？

与其他多数外设硬件一样，必须通过对应的驱动程序，才能在手机与PC端建立有线通信。所以在插入手机之前，需要先在PC上妥善安装FASTBOOT模式的相关驱动。

在PC端（Windows XP及更高版本）下载MiFlash刷机工具并解压，然后运行其中的XiaoMiFlash.exe并点击窗口顶部的Driver，接着在弹出的窗口中点击安装按钮，安装FASTBOOT相关驱动程序。

4. 怎么开启FASTBOOT命令提示符？

所谓FASTBOOT模式的本质。其实就是通过向设备发送对应的命令，并实现相应的操作和功能。而MiFlash（线刷工具）、解锁工具、小米助手，以及各种第三方刷机工具等基于GUI图形化界面的程序，也是将各种命令配合条件判断语句等组成脚本，来实现“一键傻瓜式解锁刷机”的功能。

其实我们也可以使用CUI命令行的方式，直接向手机端发送对应的命令，并获取想要的信息或完成各种操作。虽然没有软件界面的便捷美观，但可实现的功能却远比图形化工具更加强大，且整个执行过程都非常直观透明，即使失败也能获取到最为完整的报错信息。

将手机进入FASTBOOT模式，并通过数据线连接至PC，进入MiFlash刷机工具文件夹下的\Source\ThirdParty\Google\Android”目录下，然后在地址栏中输入“cmd”并按键盘上的回车（Enter）键，打开命令提示符窗口。此时可以输入“fastboot --version”命令后回车，并查看当前FASTBOOT软件的版本号。而在下文中所列出的相关命令，也需要在该窗口中输入并执行。

5. 目前FASTBOOT命令有哪些类型？

可以通过在FASTBOOT命令提示符窗口中执行“fastboot -h”命令，来获取可能用到的命令参考及语法格式帮助，英文不好的同学也可以借助翻译软件阅读。但由于不同机型和处理器的差异，本帮助文档并未涵盖所有可以用到的命令，具体情况还取决于插入的设备本身。

目前几乎所有的FASTBOOT命令，都可以大致分为以下几类：

输出信息类：仅向PC端输出该设备的对应信息，例如当前机型内部代号、BL锁开启状态、防回滚机制状态等，通常不会改写手机中的数据。

执行动作类：仅执行对应的常规动作，例如重启进入系统、Recovery或高通9008救援模式、拔掉数据线后关机等，通常不会改写手机中的数据。

擦写数据类：会擦写手机中的数据或修改相关设置，且大多需要解锁Bootloader后才能被成功执行。例如擦除分区、焼写镜像、开启及关闭BL锁等，在执行此类命令前请务必谨慎，并尽量对重要数据进行妥善备份。不当的操作可能会造成设备无法开机，甚至不可逆的严重损坏。

6. 常用的FASTBOOT命令都有哪些？

6.1 fastboot devices 查看已连接设备

命令类型：输出信息类

命令作用：列出当前已进入FASTBOOT模式，且与PC连接正常的所有设备。

支持机型：所有机型

适用场景：将设备连接PC后，可先通过该命令检测连接状态，在执行后续的操作。

使用方法：直接输入并回车执行，会列出当前所有已连接设备及对应序列号。如果输出结果为空，说明未插入设备，设备未进入FASTBOOT状态，或驱动程序未就绪。

解除BL锁：不需要

注意事项：如果使用CUI命令交互，建议只连接一台设备。如果同时连入多个设备，通常仅对该列表中排在首位的设备有效。

6.2 fastboot getvar product 查看设备内部代号

命令类型：输出信息类

命令作用：输出该机型内部代号名称（线刷包文件名前缀）

支持机型：所有机型

适用场景：当不知道具体机型，且该设备又无法开机和查看串号时，可以通过查询内部英文代号来确定。通常该机型的内部代号，与其线刷包文件名前缀是相对应的。

使用方法：直接输入并回车执行，即可看到该机型的内部代号名称。

解除BL锁：不需要

注意事项：如果在官网下载的线刷包文件名前缀，与该机型内部代号不匹配请勿刷入，否则可能会造成设备无法开机。此外小米3 电信/联通版与小米4内部代号均为“cancro”，但线刷包却是不通用的，请勿混淆刷入。

6.3 fastboot getvar anti 查看防回滚机制版本号

命令类型：输出信息类

命令作用：输出防回滚机制（ANTI）版本号

支持机型：具有防回滚机制的机型（目前在售的机型均支持）

适用场景：如果想线刷旧版本降级，建议先使用此命令查看当前防回滚机制状态。

使用方法：直接输入并回车执行，如果所显示的ANTI版本输出值大于1，在一个时间点之前的旧版本线刷包可能无法刷入；如果ANTI版本不超过1，未显示数值或输出“getvar:anti FAILED (remote: GetVar Variable Not found)”的报错信息，则说明该设备尚不会对低版本ROM进行限制。

解除BL锁：不需要

注意事项：如果设备已限制回滚低版本系统，强制刷入旧版本包很可能无法开机。

6.4 fastboot getvar all 查看所有设备信息

命令类型：输出信息类

命令作用：输出该设备的所有信息

支持机型：大部分机型

适用场景：查看当前BL锁状态、获取分区名

使用方法：直接输入并回车执行，会输出该设备的所有信息，其中不仅有上述提到的设备代号名称，和防回滚机制版本号，还包括CPU编号、电池电压（mV）、设备序列号，以及各分区所在的内存地址等内容。

解除BL锁：不需要

注意事项：输出的设备信息仅供参考

6.5 fastboot -w 清空所有数据

命令类型：擦写数据类

命令作用：清除手机中所有数据，等同于系统中的“恢复出厂设置”，或Recovery模式的“清空所有数据”操作。

支持机型：大部分机型

适用场景：当无法进入系统和Recovery模式时，可以使用该命令清除所有数据。

使用方法：输入该命令并回车单独执行，亦可为其他命令附加“-w”选项一起执行，如执行“fastboot -w reboot”命令后，将在清空所有数据后重启进入系统。

解除BL锁：需要

注意事项：如果手机可以开机且能正常使用，在执行该命令前，需提前对重要数据进行妥善备份。

6.6 fastboot flash <分区名> <镜像文件名或路径> 烧录镜像到分区

命令类型：擦写数据类

命令作用：烧录img、bin、mbn、elf等镜像文件内容到指定分区，支持刷入的分区名可通过上述“fastboot getvar all”命令查询。

支持机型：所有机型

适用场景：单独刷入boot、Recovery、cust等分区镜像，或当手机始终卡在小米logo界面无法开机，且线刷和清空数据都无法解决时，可以使用该命令依次烧录对应线刷包“images”目录下，所有能刷入的镜像文件。

使用方法：

– ① 将需要烧录的镜像文件放置在“fastboot.exe”所在的同一个目录下，然后执行对应的烧录命令。如烧录“recovery.img”镜像文件到Recovery分区，则执行“fastboot flash recovery recovery.img”命令；

– ② 先输入“fastboot flash <分区名>”，敲一下空格键后，在将需要烧录的镜像文件直接拖拽进命令提示符窗口中，并获取该文件的绝对路径，如烧录“recovery.img”镜像文件到Recovery分区，且文件位于“C:/REC”目录下，则拖拽文件后应执行“fastboot flash recovery C:/REC/recovery.img”命令。

解除BL锁：需要

注意事项：烧录前请确定镜像文件与机型和分区匹配，并尽量提前备份重要数据，在操作执行结束前，切勿拔掉数据线或关闭命令提示符窗口。

PolarDB-X 20 全局 Binlog 和备份恢复能力解读

作者： 燧木

背景

我们作为开发者都了解或熟悉后台系统，后台系统可以抽象为两个组成部分：一个是业务系统，该部分负责处理系统的业务逻辑，在现代化的架构中，该部分通常设计成可水平扩展的无状态节点；另一个是数据库系统，该部分负责存储系统的状态，这其中便包括最核心的业务数据。

站在数据库的视角，数据的流入包括两个部分，一个是业务系统的实时写入，这是核心数据来源的主要部分；另一个是从上游数据系统一次性或周期性导入的数据。因为这些核心数据在这里首次产生，所以这个数据库也被称为 SSOT（Single Source of Truth）。

SSOT 是后台系统中最重要的数据资产，那么随之便产生两个问题需要妥善处理。第一个问题是，作为最重要的资产，通常我们需要将这些数据实时同步到其他系统进行 BI 分析等进一步的处理，如果没有这样的实时同步机制，那么这份数据将成为数据孤岛。第二个问题是，这份数据可能因为各种原因遭到破坏，比如硬件故障或软件 Bug 导致的数据损坏、不当操作引起的数据损坏、错误 SQL 引起的数据错乱等，提供多种机制保障这份数据的安全显得非常必要。

全局 Binlog

PolarDB-X 是一款高度兼容 MySQL 生态的分布式数据库产品，所以我们首先来看下 MySQL 是如果解决数据孤岛问题的。

从 DB-Engines 排行榜可以看出，MySQL 的流行度比其他开源数据库的总和还要高，这意味着 MySQL 的生态非常繁荣，比如 MySQL 的下游系统有 Kafka、MySQL 备节点、Canal 多种数据同步工具、Pulsar 等等。MySQL 通过 Binlog 机制实现了与下游系统的实时增量数据同步。Binlog 可以看做是一个消息队列，队列中按顺序保存了 MySQL 中详细的增量变更信息，通过消费这个队列，下游系统或工具实现了与 MySQL 的实时数据同步，这样的机制也称为 CDC（Change Data Capture），即增量数据捕捉。

分布式数据库提供 CDC 能力相对于单机有更高的复杂度。一个分布式数据库通常包含多个节点，这些节点会产生多个增量日志队列，那么下游如果要消费多个队列会涉及几个问题。

因为是多个队列，那么下游消费时多个队列内变更事件的顺序如何确定？分布式事务的变更可能涉及多个队列，如果要保证消费时事务的完整性，那么如何发现并合并同一个事务的变更事件？系统发生了扩缩容（也就是队列的增减）下游如何正确处理？DDL 会涉及多个队列，下游如何精确识别出每个队列 Schema 变化前后的位置并协调好消费进度？

面对这些问题，分布式数据库的 CDC 能力需要在实现难度、支持特性、易用性等方面做 trade-off。通常来说，给下游提供多个队列、不保障事务完整性仅提供最终一致性、提供自定义格式的增量日志是一种较易实现的方案，但该方案会对下游消费提出更高的要求，比如要开发相应的消费代码或工具、需要考虑多个队列的协同问题等。一种体验更友好的方式是，通过提供与 MySQL Binlog 完全一致体验的 CDC 能力，让下游可以像消费 MySQL Binlog 一样透明的消费分布式数据库的增量变更，从而极大降低数据同步链路的搭建成本，这也是 PolarDB-X 2.0 采用的方案，我们称为全局 Binlog。

PolarDB-X 2.0 采用的是可水平扩展的 Share-Nothing 架构，系统基本组成单位是节点（即 Node），每个节点又可分为计算节点（即CN）和数据节点（即DN）两个部分。如上图所示，为提供全局 Binlog 能力，PolarDB-X 2.0 在此基础上增加了 CDC 组件，CDC 是一个具备弹性能力的集群。

全局 Binlog 的生成过程可分为三个阶段：

CDC 组件从每个 DN 拉取其增量日志，也就是物理 Binlog，之后进行单队列排序、内部事件过滤、DDL 相关的整形等操作，以便为下一阶段提供一个“干净”的增量事件队列，同时若系统发生了扩缩容，CDC 组件会在该阶段自动感知并做相关处理；CDC 组件将所有“干净”的增量事件队列进行合并，期间会对属于同一分布式事务的事件进行合并，并会根据事务时间戳进行全局排序，这样便得到一个全局有序的保障事务完整性的事件队列，同时该阶段还会处理好 DDL 在队列中的位置。之后 CDC 组件会将该队列生成兼容 MySQL Binlog 格式的文件，即全局 Binlog 文件；CN 组件在收到下游订阅全局 Binlog 请求后，会按照 MySQL DUMP 协议将全局 Binlog 发送给下游消费。

经过上面三个阶段，PolarDB-X 2.0 实现了完全兼容 MySQL Binlog 的全局 Binlog 能力。如果对详细的实现原理感兴趣，欢迎关注PolarDB-X的知乎专栏：PolarDB-X - 知乎

备份恢复

对于数据损坏问题，PolarDB-X 2.0 提供不同粒度的数据恢复能力，包括实例级的一致性备份恢复能力、表级的表回收站能力、SQL 级的 SQL 闪回能力、行级的 Flashback Query 能力等。下面分别介绍这四项能力的特点和使用场景。

一致性备份恢复

首先来看下一致性备份恢复，该能力的特点是可以提供实例级任意时间点的历史数据恢复能力，这个时间点可以精确到秒级。

单机数据库中，可以认为全量数据和增量日志都存储在一台机器上，实现一致性备份和恢复的话，只需要将全量数据和增量日志备份就好。分布式数据库中若要做到一致性备份恢复，因为全量数据和增量日志都存储在多台机器上的缘故，实现上会有额外的复杂度。

PolarDB-X 2.0 中通过将所有 DN 做全量备份+全局 Binlog 的方式实现了一致性备份恢复能力。

以上图为例，比如我们有一个 PolarDB-X 2.0 实例每周一、周二和周五的零点进行备份，某天产生一个需求，需要将数据恢复到周日的 14:25:26，那么我们的系统会选择离恢复点最近的一个全量备份集---- 也就是周五零点点这份，并从周五零点开始重放全局 Binlog，直到周日 14:25:26 结束，这样我们便得到了想要的快照。

PolarDB-X 2.0 的一致性备份恢复能力备份期间不会锁库，该能力依赖全局 Binlog，也就是可恢复的区间是全局 Binlog 的保存区间。该能力目前有几个限制，比如备份期间不能进行扩缩容、仅支持同构恢复等。

表回收站

PolarDB-X 2.0 提供的第二项数据恢复能力叫做表回收站。顾名思义，我们会将 DROP 的表临时放入一个回收站，若两小时内发现需要恢复该表，那么可以在回收站中找回。

表回收站提供了完整的管理功能，比如查看回收站中所有的表、彻底删除某张表、恢复某张表等。回收站目前仅缓存两小时内删除的表，并且不支持找回通过 TRUNCATE TABLE 删除的表。

SQL 闪回（即将上线）

PolarDB-X 2.0 提供的第三项数据恢复能力叫做 SQL 闪回。该能力可精确恢复一条误操作 SQL 影响的数据。PolarDB-X 1.0 中同样提供了该能力，上线以来，该能力帮助众多误删数据的用户找回了数据，是一项被广泛认可的数据恢复能力。下面我们以一个例子来介绍这项能力的具体使用过程。

如上图所示，在 T1 时我们想把职位是 "Developer" 名字是 "Ralph" 的记录删掉，但 WHERE 条件中忘了加 "name='Ralph'" ，导致名字为 "Mary" 的记录被一同删掉了。这两个删除事件以及对应 SQL 的 ID 会被记录在全局 Binlog 中。

T2 时，我们发现了误删问题，并通过 PolarDB-X 的审计功能找到了对应的 SQL 和 ID。

T3 时，我们通过 SQL ID 和 SQL 闪回能力生成了恢复 SQL。SQL 闪回的原理是，在拿到 SQL ID 后，通过在全局 Binlog 中进行搜索，找到该 SQL 对应的所有变更事件（此处为两个删除事件），并逐个生成逆向恢复 SQL。

T4 时，我们将恢复 SQL 执行后得到了被误删的两条数据。

SQL 闪回针对 SQL 误操作场景可提供精确的数据恢复能力，可以看出，能够恢复的时间区间依赖于全局 Binlog 的保存区间。

Flashback Query（即将上线）

PolarDB-X 2.0 提供的第四项数据恢复能力叫做 Flashback Query。该能力可提供一定时间范围内行级的数据精确恢复能力。下面我们仍以 SQL 误操作场景为例。

如上图所示，T1 时我们想把职位是 "Developer" 名字是 "Ralph" 的记录职位更新为 "CTO"，但 WHERE 条件中忘了加 "name='Ralph'"，导致所有职位是 "Developer" 的记录都被更新成了 "CTO"。这些变更都会记录在版本为 Vn+1 的 undo log 中（undo log 是数据库中的一个基础数据结构，里面详细的记录了每行数据的变更内容，可简单类比成 GIT commit log）。

T2 时，我们马上发现了误改问题并确定了误操作时间和影响的数据范围。

T3 时，我们通过 Flashback Query 能力直接查到了被影响的两行记录在 T1 时刻正确的值。

T4 时，我们根据 Flashback Query 返回的正确值对数据进行了订正。

可以看出，Flashback Query 能力依赖 undo log 的保存时长。与 SQL 闪回相比，该能力可提供更快速、精确到行级的恢复能力，但 undo log 通常不如全局 Binlog 保存的时间长，所以可恢复区间上弱于 SQL 闪回。

总结

PolarDB-X 2.0 针对数据孤岛问题提供了全局 Binlog 能力，该能力为下游生态提供了与 MySQL Binlog 完全一致的增量日志消费体验。针对数据损坏问题提供了实例级、表级、SQL 级和行级等不同粒度的数据恢复能力，包括一致性备份恢复、表回收站、SQL 闪回、Flashback Query 等。PolarDB-X 2.0 还在持续打造更多产品能力，敬请期待~

【相关阅读】

PolarDB-X：使用一个透明的分布式数据库是一种什么体验

#阿里云# #数据库#

什么是刷机中的FASTBOOT，如何烧录img、bin、mbn、elf等镜像文件

PolarDB-X 20 全局 Binlog 和备份恢复能力解读

背景

全局 Binlog

备份恢复

总结

关于我们

产品中心

服务与支持