Casi duplicado: ¿Es posible arrancar un teléfono Android desde una unidad USB?
Su pregunta tiene dos partes:
1. ¿Cómo arrancar desde un USB en un dispositivo Android?
En la mayoría de los dispositivos Android recientes no se puede arrancar ni siquiera Android desde el USB, sino Ubuntu o algún otro SO.
PCs:
El mundo del PC tiene una estandarización. BIOS / UEFI, ACPI y autobuses descubribles hacer que cada PC sea casi idéntico al SO, para poder arrancar cualquier SO. BIOS le permite seleccionar el dispositivo de arranque, carga bota de motor / MBR y bootloader que carga el kernel del SO. UEFI Gestor de arranque es aún más sofisticado, puede leer los sistemas de archivos y cargar uno de los múltiples BLs o incluso El núcleo de Linux directamente de las particiones del sistema EFI (ESP).
![]()
Compatible con Multiboot Los BL pueden cargar varios sistemas operativos. BOOTMGR de Windows y Linux GRUB también pueden cargarse en cadena unos a otros. Este último puede actuar como 1ª etapa BL (MBR/VBR) así como 2ª etapa (gestor de arranque con interfaz gráfica que lee la configuración del sistema de archivos). Ver Proceso de arranque: Android vs. Linux
Teléfonos:
El mundo del teléfono está muy fragmentado. Se basan en SoC diseño, por lo que cada proveedor implementa su propio firmware de código cerrado. Sin capacidad de enumeración los autobuses dependen de Árbol de dispositivos que se almacena en el almacenamiento flash como blob (DTB), y se carga por BL final (como U-Boot , LittleKernel / Sobre ) y el núcleo de Linux. Así que el firmware del SoC tiene que arrancar el dispositivo a la etapa BL para que sea capaz de identificar el hardware.
![]()
Fuente de la imagen: Explotación de los programadores EDL de Qualcomm
El firmware del SoC no puede arrancar desde un MBR/VBR genérico o un sistema de archivos, sino que tiene rutas codificadas a las particiones que contienen BLs. También el estricto Cadena de confianza en el proceso de arranque sólo carga binarios firmados, los BL desbloqueados pueden romper esta cadena. Ver Rootear el teléfono Android sin desbloquear el BL , VB y AVB .
Sin embargo el BL final permite algo de interacción con el usuario para arrancar fastboot o el núcleo de Linux de arranque o recuperación partición. Ambas particiones no tienen sistemas de archivos, sino un formato estándar en bruto según las especificaciones de Android.
Conclusión:
Así que debido a tamaño pequeño , la no estandarización, código cerrado / naturaleza firmada del firmware y la funcionalidad mínima, Firmware del SoC + DT + Aboot no es comparable con BIOS / UEFI + ACPI + GRUB configuración. Funcionalidades como la comunicación USB y los menús de selección gráfica harían que el núcleo BL fuera más grande de lo aceptable por diseño límite de tamaño . Tenga en cuenta que "En las plataformas ARM embebidas el núcleo de LK suele ser de 15-20 KB".
Sin embargo, Los SoC pueden arrancar desde el USB En particular, los que se utilizan con tableros de desarrollo o PC de placa única. Ver Diferencia entre BootRom y BootLoader .
EFIDroid es una segunda etapa BL basada en UEFI ( EDK-II ). Actualmente sustituye a kernel en boot partición (como otros hacks de arranque múltiple), no el BL original.
Pero es posible que veamos (el firmware del SoC y/o) algunos (o todos) los BLs siendo reemplazados por UEFI y el Device Tree por ACPI (particularmente en ARM ya que es no es muy improbable ). Hará más probable el arranque desde dispositivos USB en los teléfonos móviles. Por ejemplo el Sanpdaragon 835 de Qualcomm ya tiene su SBL sustituido por XBL basado en UEFI (que también soporta ACPI en Windows) y Aboot con ABL . Ver UEFI en un sistema embebido Linux basado en ARM-V8 .
2. ¿Cómo arrancar Ubuntu en un dispositivo Android?
En los dispositivos Android no es posible arrancar Ubuntu ni siquiera desde la tarjeta SD o la memoria flash interna, sino desde el USB.
Descubrimiento del hardware:
Los SO genéricos como Ubuntu no se modifican para un entorno de hardware específico. En un Compatible con ACPI sistema, después de encenderlo, el SO puede empezar inmediatamente a consultar los buses: "¿Qué hardware está unido a ti?" , lo que no ocurre con los dispositivos basados en el DT. Véase El caso de UEFI para Windows en ARM .
Del mismo modo, en los PC Gestión de la energía se encarga de ACPI mientras que en los teléfonos el PMIC suele formar parte del SoC - de nuevo específico del hardware.
El núcleo:
El espacio de usuario de Ubuntu no es compatible con el kernel de Android ya que este último es ampliamente modificada Por ejemplo, Paranoid Networking, qtaguid , gadgets USB, etc. Es teóricamente posible arrancar el kernel de Ubuntu desde boot.img por ejemplo, utilizando fastboot o cargarlo mediante el kernel de Android utilizando kexec . Sin embargo, un problema aún mayor es la implementación incompleta de los proveedores de controladores de hardware en el kernel, que no forman parte del código fuente del kernel upstream (el utilizado por Ubuntu). Ejecutando acceso a la consola y tradicional Servidor X etc. puede no ser fácil de conseguir, véase Android vs. Linux .
Binary Blobs:
Android no se basa estrictamente en el sistema UNIX "Todo es un archivo" teoría. Principalmente debido a los problemas de licencia, una gran cantidad de trabajo de hardware es gestionado por (de nuevo) proveedor de código cerrado específico HALs que actúan como puente entre el framework nativo/Java de Android y el kernel, por ejemplo, sonido, gráficos, RIL, huella digital, cámara, sensores, etc. Desde Android 8, HIDL (basado en Encuadernación CIP ) separa específicamente los productos específicos del proveedor manchas binarias de AOSP así como del kernel de Linux.
Abstracción del hardware:
Además de los blobs binarios, los demonios del espacio de usuario de AOSP, como surfaceflinger , audioserver y gatekeeperd también la interfaz de la pila Java (que ejecuta las aplicaciones) en un extremo, y el núcleo o HAL en el otro (que interconecta el hardware). Así que cada componente de hardware no es simplemente un archivo en /dev con interfaz del kernel bien documentada En lugar de ello, hay capas de Android específicas CIPs y API entre las aplicaciones y el hardware.
Este modelo permite que el marco de trabajo de AOSP Java sea agnóstico con respecto a las implementaciones de controladores de nivel inferior, y restringe el acceso directo de las aplicaciones a los recursos de hardware. Las aplicaciones necesitan permisos manifiestos para pasar a través de APIs protegidas para acceder a un recurso del sistema, incluido el almacenamiento, la red, la cámara, el micrófono, el sonido, etc.
Particiones:
AOSP depende de algunas particiones como /system y /data pero los HAL necesitan más. En los dispositivos Qualcomm, los demonios de los proveedores como sensors.qti , qseecomd , rmt_storage y wcnss_service leer y escribir en dispositivos de bloque en bruto (por ejemplo ssd , rpmb , fsg ) y los sistemas de archivos (por ejemplo módem , persistir y dsp ). Así que la cámara, los sensores, el TEE, el Wi-Fi, el bluetooth, la huella dactilar, el aDSP, etc. no funcionarán sin particiones adicionales. El SoC, los procesadores, el módem, el TZ, el RPM y los BL también utilizan otras particiones para el proceso de arranque, las OTAs, la recuperación, el arranque seguro, el cifrado, el logotipo de arranque/carga, etc. Leer más sobre Particiones y sistemas de archivos de Android .
Así que no es posible arrancar un sistema operativo completamente desde una sola partición. Los PC pueden arrancarse si no hay un dispositivo de almacenamiento, pero los dispositivos Android no se encienden si la eMMC / UFS está dañada . Particiones específicas del hardware son necesarios tanto en las fases previas como en las posteriores a la obtención del núcleo. Por eso los dispositivos Android son más vulnerables a quedar permanentemente brickeados .
Conclusión:
En los teléfonos Android no hay un sistema operativo Android genérico, sino que tenemos ROMs que están estrechamente vinculados a un hardware específico. Así que arrancar Ubuntu en un dispositivo Android requiere integrar todo el código del proveedor relacionado con el hardware en el kernel de Ubuntu y/o en el espacio de usuario.
ENLACES:
