Proche du duplicata : Est-il possible de démarrer un téléphone Android à partir d'une clé USB ?
Votre question comporte deux parties :
1. Comment démarrer à partir d'une clé USB sur un appareil Android ?
Sur la plupart des appareils Android récents, il n'est pas possible de démarrer Android à partir d'une clé USB, mais plutôt Ubuntu ou un autre système d'exploitation.
PC :
Le monde des PC est normalisé. BIOS / UEFI, ACPI y bus découvrables rendre chaque PC presque identique au système d'exploitation, de sorte que nous puissions démarrer n'importe quel système d'exploitation. BIOS vous permet de sélectionner le périphérique de démarrage, de charger bootsecotor / MBR et bootloader qui charge le noyau du système d'exploitation. UEFI Gestionnaire de démarrage est encore plus sophistiqué, il peut lire les systèmes de fichiers et charger un ou plusieurs BL ou même des Noyau Linux directement des partitions du système EFI (ESP).
![]()
Compatible avec le multiboot Les BL peuvent charger plusieurs systèmes d'exploitation. BOOTMGR Windows et Linux GRUB peuvent également se charger en chaîne les uns les autres. Ce dernier peut agir comme 1ère étape BL (MBR/VBR) ainsi que 2ème étape (gestionnaire de démarrage à interface graphique qui lit la configuration à partir du système de fichiers). Voir aussi Processus de démarrage : Android vs. Linux
Téléphones :
Le monde du téléphone est très fragmenté. Ils sont basés sur SoC de sorte que chaque fournisseur met en œuvre son propre micrologiciel à code source fermé. Non compatible avec le dénombrement Les bus dépendent de Arborescence des appareils qui est stocké sur la mémoire flash sous la forme d'un blob (DTB), et chargé par le BL final (comme le U-Boot , Petit noyau / Aboot ) et le noyau Linux. Le microprogramme du SoC doit donc amorcer le dispositif jusqu'à l'étape BL afin de pouvoir identifier le matériel.
![]()
Source de l'image : Exploitation des programmeurs EDL de Qualcomm
Le microprogramme du SoC ne peut pas démarrer à partir d'un MBR/VBR générique ou d'un système de fichiers. chemins codés en dur aux partitions contenant des BL. De même, la règle stricte de l Chaîne de confiance dans le processus de démarrage ne charge que des fichiers binaires signés, les fichiers BL non verrouillés peuvent briser cette chaîne. Voir Rooting Android phone without unlocking BL , VB y AVB .
Cependant, le BL final permet une certaine interaction avec l'utilisateur pour démarrer. démarrage rapide ou le noyau Linux à partir de botte o récupération partition. Les deux partitions n'ont pas de système de fichiers, mais un format brut standard conforme aux spécifications d'Android.
Conclusion :
Ainsi, en raison de petite taille la non-standardisation, source fermée / La nature signée du micrologiciel et les fonctionnalités minimales, Firmware du SoC + DT + Aboot n'est en aucun cas comparable à BIOS / UEFI + ACPI + GRUB de l'installation. Des fonctionnalités telles que la communication USB et les menus de sélection graphiques rendraient le noyau BL plus important que ce qui est acceptable au niveau de la conception. limite de taille . Il convient de noter que "Sur les plates-formes ARM embarquées, le noyau de LK est généralement de 15 à 20 Ko.
Cependant Les SoC peuvent démarrer à partir d'une clé USB , en particulier ceux qui sont utilisés avec les conseils de développement ou des PC à carte unique. Voir aussi Différence entre BootRom et BootLoader .
EFIDroid est un BL de deuxième niveau basé sur l'UEFI ( EDK-II ). Actuellement, il remplace le noyau dans boot (à l'instar d'autres hacks multi-boot), et non la BL d'origine.
Mais nous pourrions voir (le firmware du SoC et/ou) certains (ou tous) BLs remplacés par UEFI et Device Tree par ACPI (en particulier sur ARM car il s'agit d'une technologie de pointe). pas très improbable ). Cela rendra plus probable le démarrage à partir de périphériques USB sur les téléphones mobiles. Par exemple, le Sanpdaragon 835 de Qualcomm a déjà son SBL remplacé par XBL basé sur l'UEFI (qui prend également en charge l'ACPI sous Windows) et Aboot avec ABL . Voir UEFI sur un système Linux embarqué basé sur ARM-V8 .
2. Comment démarrer Ubuntu sur un appareil Android ?
Sur les appareils Android, il n'est pas possible de démarrer Ubuntu même à partir d'une carte SD ou d'une mémoire flash interne, mais plutôt à partir d'un port USB.
Découverte du matériel :
Les systèmes d'exploitation génériques comme Ubuntu ne sont pas modifiés pour un environnement matériel spécifique. Sur un Compatible avec l'ACPI après la mise sous tension, le système d'exploitation peut immédiatement commencer à interroger les bus : "Quel est le matériel qui vous est attaché ?" ce qui n'est pas le cas des appareils basés sur la technologie DT. Voir aussi Le cas de l'UEFI pour Windows sur ARM .
De même sur les PC Gestion de l'énergie est pris en charge par l'ACPI, tandis que sur les téléphones, le PMIC fait généralement partie du SoC - là encore, il est spécifique au matériel.
Noyau :
L'espace utilisateur d'Ubuntu n'est pas compatible avec le noyau d'Android car ce dernier est largement modifié e.g. Paranoid Networking, qtaguid gadgets USB, etc. Il est théoriquement possible de démarrer le noyau Ubuntu à partir de boot.img par exemple en utilisant fastboot ou le charger par le noyau d'Android en utilisant kexec . Cependant, le problème le plus important est l'implémentation incomplète par les vendeurs de la norme pilotes de matériel dans le noyau, qui ne font pas partie des sources du noyau en amont (celui utilisé par Ubuntu). Exécution connexion à la console et traditionnels Serveur X etc. pourrait ne pas être facile à réaliser, voir Android vs. Linux .
Blobs binaires :
Android n'est pas strictement basé sur le système UNIX. "Tout est un fichier théorie. Principalement en raison de problèmes de licence, une grande partie du travail sur le matériel est gérée par des fournisseurs (une fois de plus) à source fermée spécifiques. HALs qui servent de pont entre le cadre natif/Java d'Android et le noyau, par exemple le son, les graphiques, le RIL, les empreintes digitales, l'appareil photo, les capteurs, etc. Depuis Android 8, HIDL (sur la base de Liant IPC ) sépare spécifiquement les blobs binaires de l'AOSP ainsi que du noyau Linux.
Abstraction matérielle :
Outre les blobs binaires, les démons de l'espace utilisateur de l'AOSP tels que surfaceflinger , audioserver y gatekeeperd Il s'agit également d'interfacer la pile Java (qui exécute les applications) d'un côté, et le noyau ou les HAL de l'autre (qui interfèrent avec le matériel). Ainsi, chaque composant matériel n'est pas simplement un fichier dans le répertoire /dev avec interface du noyau bien documentée Au lieu de cela, il y a des couches de IPC et les API entre les applications et le matériel.
Ce modèle permet au cadre Java AOSP d'être agnostique quant aux implémentations de pilotes de niveau inférieur, et limite l'accès direct des applications aux ressources matérielles. Les applications doivent autorisations du manifeste traverser API protégées afin d'accéder à une ressource du système, y compris le stockage, le réseau, la caméra, le micro, le son, etc.
Les partitions :
L'AOSP dépend de quelques partitions telles que /system y /data mais les HAL ont besoin de plus. Sur les appareils Qualcomm, des démons de fournisseurs comme sensors.qti , qseecomd , rmt_storage y wcnss_service lire et écrire sur des périphériques de blocs bruts (par ex. ssd , rpmb , fsg ) et les systèmes de fichiers (par exemple modem , persister y dsp ). Ainsi, la caméra, les capteurs, le TEE, le Wi-Fi, le Bluetooth, les empreintes digitales, l'aDSP, etc. ne fonctionneront pas sans partitions supplémentaires. Le SoC, les processeurs, le modem, le TZ, le RPM et les BL utilisent également d'autres partitions pour le processus de démarrage, les OTA, la récupération, le démarrage sécurisé, le cryptage, le logo de démarrage/chargement, etc. Pour en savoir plus Partitions et systèmes de fichiers Android .
Il n'est donc pas possible de démarrer un système d'exploitation entièrement à partir d'une seule partition. Les PC peuvent être démarrés s'il n'y a pas de périphérique de stockage, mais les appareils Android ne s'allumeront pas si eMMC / UFS est endommagé . Partitions spécifiques au matériel sont nécessaires aux stades pré-noyaux et post-noyaux. C'est pourquoi les appareils Android sont plus vulnérable à un blocage permanent .
Conclusion :
Sur les téléphones Android, il n'y a pas de système d'exploitation générique. ROMs qui sont étroitement liés à un matériel spécifique. Ainsi, le démarrage d'Ubuntu sur un appareil Android nécessite l'intégration de tout le code fournisseur lié au matériel dans le noyau et/ou l'espace utilisateur d'Ubuntu.
LIENS :
