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?
Answer
/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.
EDIT:
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
...
RPMB Size [RPMB_SIZE_MULT]: 0x20
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.
RELATED:
No comments:
Post a Comment