D'abord, le circuit de veille à faible consommation permet d'alimenter le reste du système, il y a une brève pause pendant que les régulateurs locaux démarrent et que les condensateurs se chargent, et qu'un microcontrôleur vérifie que toutes les différentes tensions qu'il attend sont dans la gamme, puis la ligne de réinitialisation est libérée sur le système.
Le processeur commence à exécuter le micrologiciel à partir de la flash système - communément appelé BIOS ou micrologiciel UEFI sur les systèmes d'architecture x86. Sur les systèmes ARM, il s'agit de la rom de masque sur le SoC lui-même.
Le micrologiciel effectue quelques autotests et une certaine initialisation matérielle(POST).
À partir de là, sur les plateformes basées sur le BIOS x86, le BIOS lit le master boot record à partir du dispositif d'amorçage défini dans le CMOS, puis charge le bootloader de stade 1 à partir du MBR, qui charge le code du bootloader de stade 2 (dépend du type de bootloader). Le chargeur d'amorçage charge ensuite le noyau du système d'exploitation dans la ram à partir du disque, et commence à l'exécuter.
Pour les plateformes x86 basées sur l'UEFI, l'UEFI lit le contenu de la partition système à partir du périphérique d'amorçage défini dans la NVRAM, puis charge l'image d'amorçage trouvée. Sur les systèmes UEFI, il peut s'agir soit du noyau de votre OS lui-même, soit d'un chargeur d'amorçage intermédiaire de stade 2, selon l'OS en question. Le chargeur d'amorçage charge ensuite le noyau de l'OS dans la ram depuis le disque, et commence à l'exécuter.
Sur les plateformes ARM, typiquement, il exécute le chargeur d'amorçage (communément U-Boot) depuis une position bien définie sur la flash (l'emplacement varie selon le fabricant et est contrôlé par la rom du SoC), qui charge et exécute l'image du noyau, qui est plus ou moins toujours stockée brute sur le périphérique flash.
Une fois que le noyau a commencé à s'exécuter, il initialise tous les périphériques, charge le micrologiciel dans ceux-ci (de nombreux pilotes contiennent le micrologiciel des périphériques pour lesquels ils sont destinés - ce qui facilite les mises à jour du micrologiciel des périphériques), démarre les services système, monte les systèmes de fichiers, etc - les choses divergent considérablement à partir de là.
Venez-en maintenant au cœur du problème - pourquoi n'est-ce pas instantané ?
Pour les plateformes ARM, la plupart du temps est passé à démarrer le noyau, et non dans le chargeur d'amorçage. U-Boot s'exécutera extrêmement rapidement, c'est pourquoi certains premiers chromebooks x86 utilisent U-Boot (en conjonction avec Coreboot, qui est un remplacement très rapide du BIOS basé sur le noyau Linux), pour des temps de démarrage considérablement réduits.
Pour les plateformes x86, tout d'abord le code lui-même est moins compact en raison de son architecture CISC (Complex Instruction Set Computer) au lieu d'une architecture RISC (Reduced Instruction Set Computer), ensuite le firmware du système peut faire plusieurs mégaoctets, par rapport à la poignée d'octets pour ARM.
Un OS moderne rapide avec une séquence de démarrage optimisée sur un support de démarrage haute performance peut passer la plupart de son temps dans le BIOS (plusieurs secondes), c'est pourquoi UEFI a été développé pour moderniser le processus de démarrage.
UEFI est assez rapide dans la plupart des cas, mais s'il doit charger un tas de firmware pour les périphériques ou initialiser un tas de matériel compliqué ou de la mémoire peut prendre un LONG temps. Les serveurs modernes, par exemple, peuvent prendre des dizaines de minutes pour arriver au point où le firmware lit les blocs de démarrage et exécute le chargeur de démarrage sur un système quadruple socket avec 512 Go de mémoire ECC et un tas de cartes d'extension, chacune avec son propre firmware à charger dans la RAM.
De son côté, le BIOS a toujours été lent, plein de code hérité, et sur les systèmes modernes, il peut faire plusieurs mégaoctets, même un ordinateur de bureau avec relativement peu de périphériques peut prendre près d'une minute pour arriver au bootloader.
Par contraste, un Atmel ATMEGA 328 - la puce de la carte Arduino Uno, démarre en une fraction de seconde sur le code que vous avez écrit, en s'exécutant à partir des 32kb de flash embarqués. Il n'y a que 2 Ko de mémoire vive, la largeur de données n'est que de 8 bits, la fréquence n'est que de 8 MHz et vous devez initialiser vous-même chaque fonction de la puce que vous souhaitez utiliser. La chose la plus proche de ce que vous écrivez sur un système moderne est le BIOS lui-même.
TL;DR : Les ordinateurs et les téléphones sont des machines complexes, le logiciel qui fonctionne sur eux consiste en des centaines sur des milliers de MILLIONS de lignes de code source, converties en binaires contenant des centaines de trillions d'instructions que les processeurs doivent exécuter, généralement en plusieurs étapes.