¿Puede un dispositivo Android con /dev/mmcblk0 totalmente sobrescrito (sin particiones /dev/mmcblk0p*) aún ser flasheado usando fastboot? ¿Es cierto que sobrescribir /dev/mmcblk0 no elimina las particiones /dev/mmcblk0boot*?
/dev/mmcblk0 es todo el chip de almacenamiento MMC que incluye la tabla de particiones GUID (GPT) y todas las particiones. En dispositivos Android, algunas de estas particiones de eMMC contienen bootloaders (como sbl, aboot en dispositivos Qualcomm) que tienen rutas codificadas en firmware SoC. Sobrescribir completamente (borrar) tales particiones significa que el SoC no podrá arrancar el dispositivo. Dado que fastboot y otros modos de servicio como odin están alojados por los bootloaders, no estarán disponibles y el dispositivo se considerará duro-brickeado.
Las excepciones son si el dispositivo tiene soporte BIOS/OpenBIOS/UEFI/ACPI y es capaz de descubrir el hardware sin DTB y arrancar inicialmente sin depender de los bootloaders.
O si hay una forma de recrear particiones y reescribir bootloaders (ver ejemplo de MTK en la sección de edición más abajo). Algo a un nivel aún más bajo que pueda comunicarse directamente con el SoC por ejemplo el protocolo JTAG, posiblemente se pueda utilizar para revivir el dispositivo. Sin embargo, esto requiere hardware y software especiales y a veces el desoldado/resoldado o incluso retirar el chip flash. Aún después de recuperar el dispositivo de esa manera, tendrás que restaurar particiones específicas del dispositivo, por ejemplo la que contiene el IMEI.
La convención de nomenclatura /dev/mmcblk0boot* usualmente se utiliza para representar particiones de área de arranque desde el eMMC interno en Linux mientras que /dev/mmcblk0p* representa particiones de área de usuario o particiones en la tarjeta SD externa. Android enumera las particiones de eMMC como /dev/block/mmcblk0p* y las particiones de la tarjeta SD externa como /dev/block/mmcblk1p* (por lo que he visto). Pero la nomenclatura puede diferir para diferentes fabricantes. Sea cual sea el caso, sobrescribir un dispositivo de memoria flash de bloque crudo entero borraría todas las particiones en él.
EDICIÓN:
Acabo de darme cuenta de que estás hablando de eMMCs usadas con placas de desarrollo, no en teléfonos Android. Este último es algo diferente, puede tener más de 50 particiones en dispositivos recientes. Muchas de estas son blobs binarios cerrados específicos del vendedor. Pero las eMMCs usadas con Linux tienen algunas particiones (no más de 8 por dispositivo de bloque de forma predeterminada).
Si ese es el caso, /dev/mmcblk0boot* probablemente sean dispositivos de bloque separados según el estándar eMMC v4.41. Por lo que es posible que no se hayan borrado junto con las particiones de área de usuario. Las particiones de arranque también están protegidas contra escritura de forma predeterminada (1, 2), mientras que los dispositivos Android principalmente usan el área de usuario para el arranque (aunque los fabricantes pueden hacerlo de otra forma) lo cual se puede borrar fácilmente. La eMMC v4.41 también define la partición RPMB que también es un dispositivo de bloque separado (de hecho no es un dispositivo de bloque y no es una partición) y no debería ser eliminable.
En un dispositivo Android con SoC Qualcomm (MSM8953) y eMMC Samsung (RX1BMB) y sin particiones de área de arranque:
~# 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]: 0x20Otro dispositivo con SoC MediaTek (MT8127) y eMMC Hynix (H8G1e) sí tiene dos particiones de área de arranque y un RPMB. Informa "Boot Partition 1 enabled", entonces mmcblk0boot0 contiene el bootloader de primera etapa (preloader o SPL) mientras que el UBOOT real está en el área de usuario (mmcblk0p4). mmcblk0boot1 contiene información específica del dispositivo disponible a través de idme print como dirección MAC, número de serie, código de desbloqueo, etc. Sin embargo, otro SoC (MSM8610) con el mismo eMMC reporta "User area is enabled for boot". Entonces parece ser algo específico del fabricante.
Nuevamente, dado que fastboot está implementado en U-Boot, no estará disponible después de borrar mmcblk0. Sin embargo, en dispositivos MTK, el Modo de Descarga del Preloader (Herramienta SP Flash) o incluso el modo EDL aún más temprano ("ROM de arranque en chip para programación de flash de fábrica") debería funcionar (si está implementado). El modo EDL en algunos MTK (Modo Meta) y dispositivos Qcom (modo QDL/9008; implementado en PBL/BootROM) requiere acortar los puntos de prueba en la placa base (3, 4).
De lo contrario, la única forma de flashear particiones es comunicándose directamente con el SoC. Los SoCs i.MX, por ejemplo, proporcionan el protocolo SDP sobre USB o UART que se puede utilizar para cargar U-Boot y usar fastboot.
NOTA: No confundir el fastboot de Android con el Fast Boot de eMMC.
RELACIONADO:
La convención de denominación suele ser la misma en todos los dispositivos basados en Linux con eMMC. El "mmcblk" interno (eMMC) es el primer mmcblk (mmcblk0) y la tarjeta externa es el segundo mmcblk (mmcblk1).
PreguntAndroid es una comunidad de usuarios de Android en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.
