Can Android device with fully overwritten /dev/mmcblk0 (without /dev/mmcblk0p* partitions) be still flashed using fastboot? Is it true that overwriting /dev/mmcblk0 does not remove /dev/mmcblk0boot* partitions?


1 Answer 1


/dev/mmcblk0 is whole MMC storage chip which includes GUID partition table (GPT) and all partitions. On Android devices some of these eMMC partitions hold bootloaders (like sbl, aboot on Qualcomm devices) which have hard-coded paths in SoC firmware. Fully overwriting (erasing) such partitions means the SoC won't be able to boot device. Since fastboot and other service modes like odin are hosted by bootloaders, so those won't be available and the device is considered hard-bricked.

Exceptions are if the device does have BIOS/OpenBIOS/UEFI/ACPI support and is able to discover hardware without DTB and boot initially without depending on bootloaders.
Or if there is a way to re-create partitions and re-write bootloaders (see MTK example in edit section below). Something at even lower level which can communicate directly to SoC e.g. JTAG protocol can be possibly used to bring device back to life. However that requires special hardware and software and sometimes desoldering/resoldering or even chipping off flash chip. Still after recovering the device that way, you will have to restore device-specific partitions e.g. the one which contains IMEI.

/dev/mmcblk0boot* naming convention is usually used to represent boot area partitions from internal MMC on Linux while /dev/mmcblk0p* represents user area partitions or partitions on external SD card. Android init enumerates eMMC partitions as /dev/block/mmcblk0p* and external SD card partitions as /dev/block/mmcblk1p* (as far as I have seen). But the nomenclature may differ for different vendors. Whatever the case is, overwriting a whole flash memory raw block device would erase all partitions on that.


I just realized you are talking about eMMCs used with development boards, not on Android phones. Latter is somewhat different, it can have 50+ partitions on recent devices. Many of those are vendor-specific closed source signed binary blobs. But the eMMCs used with Linux have a few partitions (not more than 8 per block device by default).

If that's the case, /dev/mmcblk0boot* are most probably separate block devices as per eMMC v4.41 standard. So those might have not been erased with user area partitions. Boot partitions are also write-protected by default (1, 2), while Android devices mostly use user area for booting (though vendors can go other way) which is easily erasable. eMMC v4.41 also defines RPMB partition which is also a separate block device (in fact not a block device and not a partition) and shouldn't be deletable.

On an Android device with Qualcomm SoC (MSM8953) and Samsung eMMC (RX1BMB) and without boot area partitions:

~# mmc extcsd read /dev/block/mmcblk0
  Extended CSD rev 1.8 (MMC 5.1)
Boot configuration bytes [PARTITION_CONFIG: 0x38]
 User Area Enabled for boot
 No access to boot partition

Another device with MediaTek SoC (MT8127) and Hynix eMMC (H8G1e) does have two boot area partitions and an RPMB. It reports "Boot Partition 1 enabled", so mmcblk0boot0 contains first stage bootloader (preloader or SPL) while actual UBOOT is on user area (mmcblk0p4). mmcblk0boot1 contains device specific information available through idme print like MAC address, serial number, unlock code etc. However another SoC (MSM8610) with same eMMC reports "User area is enabled for boot". So this seems to be a vendor-specific thing.

Again, since fastboot is implemented in U-Boot, it won't be available after erasing mmcblk0. On MTK devices, though, Preloader Download Mode (SP Flash Tool) or the even earlier EDL mode ("On-chip boot ROM for factory flash programming") should still work (if implemented). EDL mode on some MTK (Meta Mode) and Qcom (QDL/9008 mode; implemented in PBL/BootROM) devices requires shortening test points on motherboard (3, 4).

Otherwise the only way to flash partitions is by directly communicating with SoC. i.MX SoCs, for instance, provide SDP protocol over USB or UART which can be used to load U-Boot and use fastboot.

NOTE: Don't confuse Android's fastboot with eMMC Fast Boot.


  • The naming convention is usually same on all Linux-based devices with eMMC. Internal “mmcblk” (eMMC) is the first mmcblk (mmcblk0) and external card is second mmcblk (mmcblk1).
    – jiwopene
    Commented Nov 8, 2019 at 17:48
  • @jiwopene I was talking about ...boot* vs ...p*. Commented Nov 8, 2019 at 17:50
  • So no mmcblk0boot* partitions are present on android devices?
    – jiwopene
    Commented Nov 8, 2019 at 17:51
  • 1
    EDL mode also works on some qualcomm phones (although you may need to disasemble it, and short some test points). Then you might be able to restore the system. See for example 34C3 - eMMC hacking, or: how I fixed long-dead Galaxy S3 phones for an interesting talk about reviving phones without eMMC access. Commented Nov 11, 2019 at 14:13
  • 1
    @JonasCz-ReinstateMonica that's what I wrote: "EDL mode on some MTK (Meta Mode) and Qcom (QDL/9008 mode; implemented in PBL/BootROM) devices requires shortening test points on motherboard". Probably you missed that :) Also on some devices it works without shortening e.g. Xiaomi Redmi Note 4 Commented Nov 11, 2019 at 14:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .