Linux Boot sur la plate-forme ARM
Description
La plate-forme ARM est la carte basée sur l'architecture ARM. Il existe de nombreuses fabricants sur le marché qui conçoivent les plateformes basées sur cette architecture. Généralement, une plate-forme de bras a les éléments constitutifs suivants:
- CPU / SOC: Il s'agit de la principale unité de traitement de la plate-forme. Les composants ont les composants internes aussi bien comme le cache, SCU, etc.
- S-Ram interne: C'est le RAM qui est présent dans le SOC. La taille de cette mémoire est limitée et sera peu KBS.
- DDR externe: Ceci est la RAM externe, qui est de taille significative par rapport à la RAM interne. Cette mémoire agit comme la mémoire d'exécution pour le processeur. Généralement, cela est de quelques GB, basés sur la conception du système.
- Périphérique de démarrage: Il s'agit du périphérique de stockage permanent externe utilisé pour stocker les images logicielles nécessaires au système pour démarrer. Peu d'exemples des composants sont les chargeurs de démarrage, l'image Linux, le système de fichiers racine. Ces 3 composants sont des composants de base nécessaires à n'importe quel système pour démarrer Linux. L'exemple de périphériques de démarrage est EMMC, NV Flash Memory Devices, carte SD, bâton de mémoire USB, etc. Ces appareils ne peuvent être utilisés pour démarrer que si le système prend en charge le démarrage avec ce support. Peu de systèmes ont plusieurs options de démarrage, qui peuvent être contrôlées par des sangles ou des interrupteurs de DIP. Tout type de démarrage requis peut être sélectionné et les images peuvent programmer dans le support de démarrage. La programmation des images de démarrage peut être effectuée à l'aide d'un programmeur externe comme un outil DeDiProg.
Images pour le système pour démarrer
Le premier et le plus important élément nécessaire pour démarrer Linux sur la plate-forme ARM est que nous avons besoin des images de construction de chargeurs de démarrage, de systèmes de fichiers du noyau Linux et racine. Ces images peuvent être compilées si la carte est conçue interne à l'organisation, mais si l'appareil est acheté via un vendeur, il devrait fournir les instructions sur la génération d'images. Même dans certains cas, s'ils ne fournissent pas le code source à compiler ou à construire, ils fournissent les images prédéfinies.
Programmation des images sur le périphérique de démarrage
Après avoir des images prêtes à démarrer sur la plate-forme, nous devons brûler / programmer les images sur le périphérique de démarrage. Il devrait y avoir des instructions disponibles auprès du fournisseur ou tout programme HW peut être utilisé pour programmer les images sur le périphérique de démarrage. L'exemple de ce programmeur est DedIprog.
DeDiProg est l'outil qui peut être utilisé pour programmer l'image Flash au NV Flash. C'est le cas du mode de démarrage flash. Des cavaliers ou une configuration sont nécessaires pour activer le démarrage flash si plusieurs périphériques de démarrage sont présents.
Instantané de DedIprog:
Après tout, les images sont programmées dans le support de démarrage et toute la configuration de démarrage est effectuée pour activer le type de démarrage où nous avons conservé les images pour démarrer.
Le démarrage du Linux peut être pris en compte en plusieurs étapes:
- Phase de la ROM de démarrage
- Démarrage du premier chargeur de démarrage
- Démarrage du chargeur de démarrage en deuxième étape, c'est U-Boot en général.
- Démarrage de Linux
- Montage de rootfs et exécution des scripts Linux init jusqu'à la console de connexion.
Discutons de toutes ces étapes de démarrage en détail maintenant.
Phase de la ROM de démarrage
À ce stade, il n'y a pas d'accès au DDR externe, toute l'exécution doit être effectuée dans le S-Ram interne. Dès que le système est allumé, le code ROM de démarrage initialise l'interface de démarrage, puis récupère le chargeur de démarrage en première étape. Une fois que le chargeur de démarrage est disponible en RAM interne et prêt à s'exécuter, le contrôle est transféré au chargeur de démarrage en première étape.
Démarrage du premier chargeur de démarrage
Immédiatement après la mise sous tension de la carte, il n'y a pas d'accès à la RAM externe disponible pour le processeur. L'exécution commence à partir du vecteur de réinitialisation. Réinitialiser le vecteur est l'emplacement d'où CPU commence à exécuter les premières instructions de programmation. À ce stade, seul RAM interne est disponible. Plus tard, le DDR externe est initialisé, puis le chargeur de démarrage en deuxième étage est récupéré à partir du support de démarrage et chargé au DDR et le contrôleur externes initialisés est transmis au chargeur de démarrage de deuxième étape I.e., U-Boot.
Démarrage du chargeur de démarrage en deuxième étage ou de l'u-boot
Il s'agit d'un logiciel minimal nécessaire à la configuration de l'environnement nécessaire à Linux Kernel avant de démarrer. Divers conducteurs et interfaces HW sont activés dans un environnement U-Boot. Ce chargeur de démarrage fournit la ligne de commande et donc nous pouvons modifier les plusieurs configurations à l'exécution. Le but principal de cette étape est de préparer la configuration / la carte pour le noyau Linux. À ce stade, l'image Linux peut être récupérée à partir de plusieurs options disponibles. L'image Linux peut être chargée sur n'importe quelle interface à partir des différentes interfaces. Cette étape récupère l'image du noyau Linux et passe le contrôle d'exécution au chargeur de démarrage.
Bootage Linux
Après la deuxième étape, le chargeur de démarrage a copié l'image Linux vers le DDR externe. Il passera le contrôle d'exécution à l'image Linux. Une fois que l'image Linux commencera à démarrer, elle démarre l'initialisation de tous les périphériques / périphériques de la carte. Il initialise tout le sous-système, y compris tous les contrôleurs et appareils. Une fois que tous les pilotes et appareils sont initialisés à ce stade et le noyau Linux fonctionne à une capacité maximale possible.
Une fois le démarrage ou l'initialisation des pilotes terminés, il y a une recherche du périphérique ROOTFS. L'emplacement du périphérique rootfs peut également être configuré ou modifié à partir des paramètres de ligne de commande de Linux. Les paramètres de ligne de commande pour Linux sont les variables d'environnement dans l'environnement U-Boot, donc pour mettre à jour l'emplacement de l'appareil RootsFS n'est qu'une modification de la variable d'environnement dans U-Boot. Il existe d'autres informations et disponibles dans un environnement U-Boot.
Peu d'exemples sont l'emplacement du processus init, la taille de la mémoire, l'activation du DevMem, l'augmentation du noyau Loglevels, etc. Peu d'autres options de variables d'environnement U-Boot sont disponibles pour faciliter d'autres cas d'utilisation dans U-Boot. Par exemple, l'affectation d'adresse IP dans le U-Boot se fait avec l'aide de la variable d'environnement.
Montage de rootfs et exécution des scripts init linux:
Le périphérique rootfs est recherché et monté, puis le processus d'initiation est recherché dans le périphérique rootfs. Une fois l'image init est située, le contrôle est transmis à l'init après avoir invoqué le processus d'initial. Ceci est le premier processus d'utilisateur qui démarre l'exécution. Une fois qu'Init a obtenu le contrôle, il initialise les services d'espace utilisateur en exécutant les scripts init.
Tous les démons sont démarrés et les services au niveau du système sont démarrés soit exécuter les services d'initiation présents dans / etc / ou si le système est un système basé sur SystemCTL, tous les services sont démarrés conformément aux directives mentionnées pour SystemCTL System. Une fois tous les services démarrés, le programme Shell est invoqué, ce qui crée une invite de session de connexion pour l'utilisateur.
L'utilisateur peut utiliser cette console de commande pour demander divers services à partir du noyau Linux.
Maintenant, voyons les journaux de démarrage du système Linux qui démontreront la phase de démarrage dont nous avons discuté jusqu'à présent. Remarque Ce ne sont pas des journaux complets. J'ai supprimé quelques lignes entre les deux car ce sont d'énormes journaux. Pas pertinent pour le sujet, donc je viens de fournir les journaux pertinents pour notre discussion.
Remarque: la phase de démarrage de la ROM ne peut pas être observée dans les journaux, car UART n'est pas disponible à ce stade.
Démarrage du premier chargeur de démarrage:
U-boot SPL 2019.04 (17 août 2021 - 18:33:14 +0000)
Essayer de démarrer à partir de RAM
Démarrage du chargeur de démarrage en deuxième étage ou U-Boot:
U-Boot 2019.04 (17 août 2021 - 18:33:14 +0000)
SOC: AST2600-A1
RST: puissance sur
Mode LPC: SIO: Activer: Supero-2E
ETH: MAC0: RMII / NCSI, MAC1: RMII / NCSI, MAC2: RMII / NCSI, MAC3: RMII / NCSI
Modèle: vendeur BMC
DRAM: déjà initialisé, 1008 MIB (capacité: 1024 MIB, VGA: 16 MIB), ECC OFF
PCIe-0: lien vers le bas
MMC: EMMC_SLOT0 @ 100: 0
Environnement de chargement de SPI Flash… SF: détecté N25Q256A avec taille de page 256 octets, effacer la taille 4 kib, total 32 MIB
*** AVERTISSEMENT - Bad CRC, en utilisant un environnement par défaut
Dans: Serial @ 1E784000
OUT: SERIAL @ 1E784000
Err: serial @ 1e784000
Modèle: vendeur BMC
eeprom eth2addr: ea = aa: bb: cc: dd: de: e0
BMC ETH2ADDR = AA: BB: CC: DD: DE: E3
Net: FTGMAC100_PROBE - NCSI détecté
ETH2: FTGMAC @ 1E670000FTGMAC100_PROBE - NCSI détecté
AVERTISSEMENT: FTGMAC @ 1E690000 (ETH3) Utilisation d'adresse MAC aléatoire - FA: 12: FB: CA: BC: FF
, ETH3: FTGMAC @ 1E690000
Appuyez sur n'importe quelle clé pour arrêter Autoboot: 2 1 0
## Chargement du noyau de l'image de l'ajustement à 20100000…
Utilisation de la configuration «conf-1»
Essayer le sous-image du noyau «noyau-1»
Description: noyau Linux
Type: Image du noyau
.
.
.
.
Compression: non compressé
Démarrage des données: 0x2067e1c4
Taille des données: 54387 octets = 53.1 kib
Architecture: bras
Vérification de l'intégrité du hachage… ok
Démarrage à l'aide du blob FDT à 0x2067e1c4
Chargement de l'image du noyau… ok
Chargement de Ramdisk à 8FBE0000, fin 8ffffbf0… ok
Arbre de chargement de chargement à 8fbcf000, fin 8fbdf472… ok
Bootage Linux:
Démarrage du noyau…
[0.000000] Démarrage de Linux sur CPU physique 0xf00
[0.000000] Version Linux 5.1.3.SDK-V00.05.07 (Cienauser @ Haxv-Srathore-2) (GCC version 8.3.0 (Buildroot 2019.05-RC2)) # 3 SMP Sun 29 août 14:19:01 UTC 2021
[0.000000] CPU: Processeur ARMV7 [410FC075] Révision 5 (ARMV7), CR = 10C5387D
[0.000000] CPU: Instructions DIV Disponible: Code de division de correction
[0.000000] CPU: cache de données non aliasing PIPT / VIPT, cache d'instructions d'aliasing VIPT
[0.000000] de: FDT: Machine Modèle: AST2600 A1 EVB
[0.000000] Politique de mémoire: Data Cache WriteAlloc
[0.000000] Mémoire réservée: Pool de mémoire CMA créé à 0xbb000000, taille 64 MIB
[0.000000] de: MEM réservé: Vidéo de nœud initialisé, ID compatible partage-DMA-POOL
[0.000000] Mémoire réservée: Pool de mémoire CMA créé à 0xb7000000, taille 64 MIB
[0.000000] de: MEM réservé: RVAS de nœud initialisé, id compatible partage-pool DMA
[0.000000] Mémoire réservée: Pool de mémoire DMA créé à 0xb6e00000, taille 2 MIB
[0.000000] de: MEM réservé: nœud initialisé SSP_MEMORY, ID compatible Pold-DMA-Pool
[0.000000] Mémoire réservée: Pool de mémoire DMA créé à 0xb6d00000, taille 1 MIB
.
.
.
.
[ 1.184367] 0x000000000000-0x0000000f0000: "U-Boot"
[ 1.191246] 0x0000000f0000-0x000000100000: "U-Boot-ENV"
[ 1.198363] 0x000000100000-0x000002060000: "Fit"
[ 1.203661] MTD: La partition "Fit" s'étend au-delà de la fin du dispositif "BMC" - Taille tronquée à 0x1f00000
[ 1.215347] vendeur-SMC 1E620000.SPI: BUS_WIDTH 2, en utilisant une fréquence SPI 50 MHz
[ 1.223375] vendeur-SMC 1E620000.SPI: N25Q256A (32768 kytes)
[ 1.229723] vendeur-SMC 1E620000.SPI: fenêtre CE1 [0x22000000 - 0x24000000] 32 Mo
[ 1.237996] vendeur-SMC 1E620000.SPI: fenêtre CE2 [0x24000000 - 0x30000000] 192MB
[ 1.246357] vendeur-SMC 1E620000.SPI: Read Control Register: [203C0441]
[ 1.316884] Vendeur-SMC 1E630000.SPI: BUS_WIDTH 2, en utilisant une fréquence SPI 50 MHz
[ 1.324821] Vendeur-SMC 1E630000.SPI: octets ID JEDEC non reconnus: 00 00 00 00 00 00
[ 1.333384] Vendeur-SMC 1E630000.SPI: Chip 0 n'existe pas.
.
.
.
[ 1.631342] UHCI_HCD: Pilote d'interface du contrôleur hôte universel USB
[ 1.638622] Plateforme-Uhci 1E6B0000.USB: détecté 2 ports à partir de l'appareil de périphérique
[ 1.646217] Plateforme-Uhci 1E6B0000.USB: Activé de solution de contradiation des fournisseurs
[ 1.664722] Plateforme-Uhci 1E6B0000.USB: contrôleur hôte générique UHCI
[ 1.671844] Plateforme-Uhci 1E6B0000.USB: Nouveau bus USB enregistré, bus affecté numéro 2
[ 1.680671] Plateforme-Uhci 1E6B0000.USB: IRQ 42, IO MEM 0X1E6B0000
[ 1.687977] USB USB2: nouveau dispositif USB trouvé, idVendor = 1d6b, idProduct = 0001, bcddevice = 5.01
[ 1.697237] USB USB2: Nouvelles chaînes de périphérique USB: MFR = 3, produit = 2, serialNumber = 1
[ 1.705311] USB USB2: Produit: Contrôleur hôte générique UHCI
[ 1.711542] USB USB2: Fabricant: Linux 5.1.3.SDK-V00.05.07 UHCI_HCD
[ 1.718824] USB USB2: SerialNumber: 1e6b0000.USB
[ 1.724589] Hub 2-0: 1.0: HUB USB Trouvé
[ 1.728830] Hub 2-0: 1.0: 2 ports détectés
[ 1.734689] USBCORE: NOUVEAUX INTERFACE DU NOUVEAUX INTERFACE-STORAGE USB
[ 1.753347] Vendor_Vhub 1E6A0000.USB-VHUB: Hub virtuel initialisé en mode USB2
[ 1.762327] Pilote I2C / Dev Entrées
[ 1.767491] I2C_NEW_VENDOR 1E78A080.i2c-bus: new-i2c: i2c-bus [0]: mode adaptateur [100 kHz] [2]
.
.
.
[2.960181] Libérer la mémoire du noyau inutilisé: 1024k
[2.970760] MMCBLK0: MMC0: 0001 R1J57L 27.5 gib
[2.976119] MMCBLK0BOOT0: MMC0: 0001 R1J57L Partition 1 16.0 MIB
[2.983067] MMCBLK0BOOT1: MMC0: 0001 R1J57L Partition 2 16.0 MIB
[2.989980] MMCBLK0RPMB: MMC0: 0001 R1J57L Partition 3 128 Kib, Chardev (246: 0)
[2.999275] MMCBLK0: P1
[3.012035] Vérification des mappages W + x: passé, pas de pages W + x trouvées
Montage de rootfs et exécution des scripts Linux init
[3.018367] Exécuter / sbin / init comme processus init
Conclusion
Nous avons vu le processus complet de démarrage Linux en détail avec des exemples de journaux. Nous avons également discuté des différents éléments constitutifs du démarrage Linux. Peu d'autres pré-requis nécessaires au démarrage ont également été discutés. Il existe différentes étapes impliquées dans le démarrage Linux sur n'importe quelle carte processeur ARM, toutes les étapes ont été discutées en détail et sont cartographiées avec les exemples de journaux de démarrage. Cette discussion est suffisante pour fournir la compréhension de base du démarrage Linux sur les systèmes ARM.