STM32MP1: U-Boot, Buildroot, Arch Linux et un peu de Debian

Bonjour, Habr!

Il y a quelque temps, STMicroelectronics a lancé d'intéressants processeurs de la série STM32MP1. Lorsque j'ai enfin mis la main sur la carte de débogage basée sur ce processeur, j'ai été surpris de constater qu'il ne manque aucune version basée sur des distributions populaires (Debian, Arch Linux, etc.). Il ne restait plus qu'à essayer d'adapter vous-même un kit de distribution pour cette carte. Sur la base des résultats de cela, cet article est apparu.



Quelles en sont les caractéristiques?


Cet article ne serait pas complet sans au moins un bref aperçu des caractéristiques des processeurs de la série STM32MP1. Il existe trois familles de processeurs dans la série STM32MP1: STM32MP151, STM32MP153 et STM32MP157. Leurs principales caractéristiques sont données dans le tableau.



Comme vous pouvez le voir dans le tableau, la différence entre les familles est que STM32MP151 a un cœur Cortex-A7, tandis que STM32MP153 et STM32MP157 ont deux cœurs de ce type, et STM32MP157 a également un support GPU 3D. Mais en général, les caractéristiques de ces processeurs en 2020 ne font aucune impression, elles sont plutôt modestes. Pourquoi ai-je encore fait attention à eux?

Pourquoi STM32MP1?


En effet, une question tout à fait logique peut se poser: y a-t-il un Raspberry Pi, il y a un Banana Pi, il y a un Orange Pi, et enfin - pourquoi avons-nous besoin d'un autre STM32MP1? De plus, toutes ces cartes ont généralement des performances significativement plus élevées que l'objet de notre étude. La réponse est simple - pendant que vous faites de l'artisanat pour un usage domestique, c'est que vous devez prendre la framboise et ce sera juste. Mais si nous parlons de produits fabriqués en série pour des applications industrielles - ici, d'autres choses commencent à jouer un rôle décisif, grâce auquel le STM32MP1 est le gagnant:

  • Plage de température de fonctionnement. Pour STM32MP1, il commence à moins 40 degrés, tandis que pour de nombreux processeurs d'autres ordinateurs à carte unique, il est bon s'il est de moins 20.
  • . STMicroelectronics , .
  • . DigiKey Mouser STM32MP1, .

Bien entendu, le ST32MP1 n'est pas le seul processeur du marché pour les applications industrielles. Il existe à la fois NXP et TI. Quant à TI, j'avais un projet de module plutôt complexe basé sur celui-ci, et il y avait un sédiment provenant d'un nombre notable de fonctionnalités matérielles qui n'étaient pas couvertes dans la documentation, mais s'il n'était pas respecté, le processeur pourrait complètement échouer, et pas immédiatement, mais avec le temps et au moment le plus inopportun. De plus, il s'agissait d'un processeur monocœur, et avec l'augmentation du nombre de tâches qui lui étaient assignées, des problèmes de performances se posaient de plus en plus souvent. En même temps, je faisais affaire avec des microcontrôleurs STMicroelectronics, et ils se sont avérés assez bons, alors j'ai décidé d'essayer de choisir ce nouveau petit.

Carte de débogage


Pour les expériences, j'ai acheté une carte de débogage STM32MP157A-DK1. Cette carte est plutôt modeste en termes d'équipement: elle n'a pas d'écran LCD comme le STM32MP157C-DK2 ou un périphérique aussi riche que le STM32MP157A-EV1. Cependant, il y a un emplacement pour carte microSD, une console USB-UART, plusieurs ports USB et Ethernet. Pour le premier départ, plus que suffisant. Et pour diluer l'histoire sèche avec une photo, je joins une photo de ce tableau de débogage.



Qu'est-ce qu'un logiciel prêt à l'emploi?


Chez STMicroelectronics, tout est généralement assez bon en termes de matériel, mais terrible en termes de logiciels. Toutes ces modifications d'Atollic True Studio, CubeMX, CubeIDE, qui sont de plus en plus boguées à chaque nouvelle version, évoquent une certaine angoisse. La situation est légèrement meilleure avec le support STM32MP1. STMicroelectronics ne propose qu'un certain assemblage d'OpenSTLinux. Cet assemblage est une distribution construite à l'aide du projet Yocto. Bien sûr, tout cela peut exister sous cette forme, mais pour moi le principal inconvénient était le manque d'accès aux référentiels de distributions bien connues. Cela signifie que vous ne pourrez pas mettre sur votre carte un utilitaire à partir des référentiels des distributions populaires simplement en exécutant une commande comme apt-get install. Souvent, cela n'est pas requis pour les solutions intégrées, mais des situations sont possibles,quand une telle opportunité ne sera certainement pas superflue.

Qu'est-ce qu'on fait?


Donc, la tâche est claire - nous devons exécuter une distribution populaire sur notre tableau de débogage. Mon choix s'est porté sur Arch Linux. Ce n'est pas la distribution la plus simple, mais elle est bien adaptée pour les appareils ARM: il y a des assemblages prêts à l'emploi et un site officiel dédié à cela.

La première chose que j'ai essayé de résoudre le problème en un clin d'œil - je viens de glisser le noyau prêt pour le chargeur de démarrage de la distribution d'Arch Linux, assemblé sous armv7. Cela fonctionnait parfois sur d'autres cartes, mais un fiasco m'attendait: malgré le fait que le noyau ait été assemblé pour la bonne architecture, il n'a pas démarré. Eh bien, alors vous devez assembler votre noyau et en même temps votre chargeur. Mon plan d'action était le suivant:

  1. Construisez le chargeur de démarrage U-Boot.
  2. Construisez le noyau Linux.
  3. Nous marquons la carte microSD.
  4. Nous écrivons le chargeur de démarrage, le noyau et le système de fichiers racine sur la carte microSD.
  5. Profit

Préparation de l'assemblage


Pour mettre en œuvre ce plan, nous avons besoin d'un ordinateur avec Linux et d'un lecteur de carte pour l'enregistrement sur une carte microSD. J'ai utilisé un ordinateur portable avec Debian 10, mais en général ce n'est pas important, les noms des utilitaires peuvent différer légèrement. Nous mettons donc les utilitaires requis. Je constate tout de suite que de temps en temps toutes les commandes doivent être exécutées en tant que root ou via sudo.

apt-get install git
apt-get install make
apt-get install gcc
apt-get install gcc-arm-linux-gnueabihf
apt-get install bison
apt-get install flex
apt-get install g++
apt-get install rsync
apt-get install libncurses-dev

En préparation de l'assemblage, nous créons trois répertoires dans le répertoire de travail: u-boot (pour le chargeur de démarrage), buildroot (pour la construction du système) et archlinux (pour la distribution):

mkdir u-boot
mkdir buildroot
mkdir archlinux

Nous aurons besoin de ces répertoires plus loin. Je ferai référence à ces noms plus loin dans le texte de l'article.

Assemblage U-boot


De nombreux articles ont déjà été écrits sur U-Boot, et dans le cadre de cela, je n'entrerai pas dans les détails de ce que c'est, à quoi il sert et comment cela fonctionne. Je peux seulement dire qu'il s'agit d'un chargeur de démarrage qui fournit le démarrage Linux sur les appareils ARM. Le code source du chargeur de démarrage U-Boot est disponible sur GitHub.

Afin de construire U-Boot, nous clonons tout d'abord le référentiel U-Boot dans le répertoire u-boot que nous avons créé précédemment:

git clone https://github.com/u-boot/u-boot

Pour créer avec succès U-Boot, nous avons besoin d'un fichier d'arborescence de périphériques et d'un fichier de configuration U-Boot.

Le fichier d'arborescence des périphériques est un fichier dépendant du périphérique. Ce fichier décrit la configuration du processeur pour une carte spécifique. Si vous fabriquez votre matériel sur la base d'un processeur ARM et prévoyez d'exécuter Linux sur celui-ci, vous devrez développer votre fichier d'arborescence de périphériques pour celui-ci (ou en adapter un prêt à l'emploi). Cependant, de nombreuses cartes de débogage ont déjà des fichiers prêts à l'emploi: les développeurs U-Boot attentionnés les incluent dans leur référentiel. Alors, regardez le répertoire u-boot / arch / arm / dts. Il doit contenir le fichier stm32mp157a-dk1.dtb - il s'agit du fichier d'arborescence de périphériques pour notre carte de débogage.

Dans le fichier de configuration U-Boot, les paramètres de base du chargeur de démarrage sont écrits.

Configurer U-Boot à partir de zéro est un processus assez long et laborieux, car il existe de nombreux paramètres. À ces fins, il existe des configurateurs de console et graphiques. Cependant, nous avons eu de la chance: dans le répertoire u-boot / configs, il y a un fichier stm32mp15_basic_defconfig . Il s'agit du fichier de configuration de base U-Boot pour les cartes de débogage STM32MP15. Nous ouvrons ce fichier et voyons que pour que nous démarrions rapidement, il suffit de changer une seule ligne: à la place

CONFIG_DEFAULT_DEVICE_TREE=”stm32mp157c-ev1”

écrire

CONFIG_DEFAULT_DEVICE_TREE=”stm32mp157a-dk1”

Avec cette ligne, nous indiquons au chargeur de démarrage que nous devons utiliser le fichier d'arborescence des périphériques pour notre carte.

Vous êtes maintenant prêt à créer U-Boot. Nous utilisons notre config:

make CROSS_COMPILE=arm-linux-gnueabihf- stm32mp15_basic_defconfig

Et exécutez l'assemblage:

make CROSS_COMPILE=arm-linux-gnueabihf-

Si tout s'est bien passé, alors dans le répertoire u-boot, nous devrions avoir un tas de fichiers. Parmi ceux-ci, deux nous intéressent: u-boot-spl.stm32 et u-boot.img .

Le premier fichier est le soi-disant First Stage Boot Loader (FSBL). Il est situé devant l'U-Boot, démarre en premier et initialise la mémoire DDR3, qui est nécessaire pour démarrer U-Boot. Dans d'autres cartes, FSBL est souvent combiné avec U-Boot en une seule image, mais ici, vous devez écrire chaque image sur une clé USB séparément.

C'est tout avec U-Boot pour l'instant, enregistrez les fichiers désignés et passez directement à l'assemblage du noyau Linux.

Assemblage du noyau Linux


J'utiliserai Buildroot pour construire le noyau Linux. Bien sûr, à ces fins, vous pouvez utiliser le Yocto tout aussi populaire, ou même essayer de construire le noyau à partir des sources de kernel.org. Cependant, j'avais une certaine expérience de travail avec Buildroot, alors j'ai décidé. De plus, Buildroot construit également le système de fichiers racine (rootfs) et même le chargeur U-Boot.

Maintenant, par tous les moyens disponibles, téléchargez l'archive de Buildroot depuis le site officiel , décompressez-la dans le répertoire buildroot et accédez-y.

Comme dans le cas de U-Boot, la première chose dont vous devez vous occuper est le fichier de configuration de notre matériel.

Nous allons dans le répertoire buildroot / configs et voyons que les développeurs ont déjà ajouté un fichier de configuration pour notre carte: il y a un fichierstm32mp157a_dk1_defconfig (vrai pour la version Buildroot-2020.05, dans les versions antérieures de ce fichier il n'y en avait pas encore).

J'ai essayé de construire le noyau 5.4.26 en utilisant ce fichier de configuration, et il a généralement démarré avec succès sur ma carte. Cependant, pour une raison quelconque, le fichier d'arborescence des périphériques Linux dans cet assemblage s'est avéré être tronqué: par défaut, les ports USB n'étaient même pas pris en charge. Espérons qu'avec le temps ce bug sera corrigé, mais que faire maintenant?

Je suis allé sur Google ce problème et suis tombé sur les référentiels STMicroelectronics, où j'ai trouvé des sources Linux 4.19 avec des correctifs pour leurs produits. Y compris, les bons fichiers DTB étaient également là. Il ne reste plus qu'à dire à Buildroot d'utiliser ce dépôt lors de la construction du noyau. Pour ce faire, copiez le fichier stm32mp157a_dk1_defconfig et renommez-le en stm32mp157a_dk1_new_defconfig . Ouvrez - le et effectuez les modifications suivantes:

Au lieu

BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_5_4=y

Nous écrivons

BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_19=y

Au lieu

BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="5.4.26"

Nous écrivons

BR2_LINUX_KERNEL_CUSTOM_TARBALL=y
BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION="$(call github,STMicroelectronics,linux,v4.19-stm32mp-r1.2)/linux-v4.19-stm32mp-r1.2.tar.gz"

Enregistrez et fermez le fichier. Le fichier de configuration est prêt, appliquons-le (vous devez l'exécuter depuis le répertoire buildroot):

make CROSS_COMPILE=arm-linux-gnueabihf- stm32mp157a_dk1_new_defconfig

Cette commande transférera les informations de notre fichier de configuration stm32mp157a_dk1_defconfig vers le fichier .config, qui se trouve dans le répertoire buildroot. À l'avenir, l'assemblage sera construit sur la base du fichier .config.

Donc, maintenant tout est presque prêt pour démarrer le processus de construction, mais avant cela, vous devez configurer notre noyau.

Ici, il convient de dire que par défaut, une fonctionnalité minimale sera incluse dans le noyau. Si nous voulons l'étendre, le noyau devra être configuré pour nous-mêmes. Au minimum, vous devrez ajouter la prise en charge du groupe de contrôle au noyau: sans cela, notre Arch Linux ne démarrera pas. De plus, à titre d'exemple, je vais vous montrer comment ajouter la prise en charge des lecteurs flash USB au noyau: en conséquence, notre carte de débogage pourra fonctionner avec les lecteurs flash.
Pour démarrer le configurateur de noyau à partir du répertoire buildroot, exécutez la commande

make linux-menuconfig

et aller boire du thé. Ce processus n'est pas rapide et en fonction de la puissance de votre ordinateur peut prendre de quinze minutes à plusieurs heures. Important: pendant le travail de buildroot, vous avez besoin d'une connexion stable à Internet, de nombreux packages différents seront téléchargés.
Si dans le processus une erreur apparaît

configure: error: you should not run configure as root (set FORCE_UNSAFE_CONFIGURE=1 in environment to bypass this check)
See `config.log' for more details

devra exécuter la commande

export FORCE_UNSAFE_CONFIGURE=1

et redémarrez le configurateur de noyau.

Par conséquent, la fenêtre du configurateur devrait apparaître:



Ajouter le support du groupe de contrôle: Configuration générale -> Support du groupe de contrôle et définir l'astérisque avec un espace:



Et comment ajouter le support de lecteur flash?
SCSI . 80- , , , USB FLASH . Device Drivers -> SCSI support :



USB FLASH . Device Drivers -> USB support USB Mass Storage support:



, FLASH : File systems -> Native language support -> Codepage 437 File systems -> Native language support -> NLS ISO 8859-1:





, USB FLASH .

Une fois tous les paramètres du configurateur du noyau définis, enregistrez-les avec le bouton Enregistrer et quittez le configurateur avec le bouton Quitter .

Maintenant, il ne reste plus qu'à démarrer le processus de construction avec la commande:

make CROSS_COMPILE=arm-linux-gnueabihf-

et vous pouvez aller boire du thé une deuxième fois, ce processus prend également beaucoup de temps.

Si tout s'est bien passé, l'ensemble de fichiers suivant devrait apparaître dans le répertoire buildroot / output / images:

  • rootfs.ext2 est un système de fichiers racine compilé avec ext2. Cela ne nous intéresse pas;
  • rootfs.ext4 est un système de fichiers racine compilé avec ext4. Il nous sera utile un peu plus tard;
  • sdcard.img - Une image d'une carte microSD, y compris FSBL + U-Boot + zImage + rootfs. Un fichier pour les paresseux, il vous permet de ne pas prendre la peine de baliser une carte microSD et d'y télécharger immédiatement l'ensemble du système. Bien sûr, ce n'est pas notre chemin :).
  • stm32mp157a-dk1.dtb - fichier d'arborescence de périphériques. Assurez-vous d'être utile pour démarrer le système;
  • u-boot.img et u-boot-spl.stm32 - fichier FSBL et U-Boot. Comme nous les avons collectés à la dernière étape, nous n'en avons pas besoin;
    Pourquoi les avons-nous collectés séparément?
    , Buildroot U-Boot. , . U-Boot, – Linux.
  • zImage - le cœur de tout le système - un fichier de noyau Linux compressé.

Ainsi, le processus d'assemblage est terminé, maintenant nous procédons au marquage de la carte mémoire microSD et à la création de partitions sur celle-ci.

Partitionnement et sections d'une carte microSD


Marquer une carte microSD et créer des partitions est une étape très importante, fortement liée à une plateforme matérielle spécifique. Malheureusement, les informations sur ce problème sur un processeur spécifique ne sont pas toujours faciles à trouver, et même si vous collectez U-Boot entièrement fonctionnel et le noyau Linux, rien de tout cela ne fonctionnera avec la moindre erreur dans la disposition de la carte microSD.

Immédiatement, je note que la carte microSD avec laquelle le système est lancé sur le STM32MP1 doit avoir un balisage GPT. L'utilitaire gdisk nous aidera avec cela , mais plus à ce sujet plus tard.

Les sections de la carte microSD devraient ressembler à ceci:



Comme vous pouvez le voir sur la figure, la carte doit contenir au moins 5 partitions: fsbl1, fsbl2, ssbl, kernel, rootfs. De plus, vous pouvez également créer une ou plusieurs sections de données pour stocker des informations à leur sujet.

Les sections fsbl1 et fsbl2 sont complètement identiques et le chargeur de démarrage principal y est écrit (comme vous vous en souvenez, il s'agit du fichier u-boot-spl.stm32 que nous avons reçu pendant le processus d'assemblage U-Boot). Malgré le fait que tout devrait fonctionner et avec une seule section de ce type, la documentation sur STM2MP1 recommande d'en faire deux. D'autres exigences s'appliquent à ces sections:

  • Chaque partition doit avoir une taille de 256 Ko.
  • , fsbl (fsbl1 fsbl2). : , .

La section ssbl est destinée à l'écriture du chargeur de démarrage U-Boot (le fichier u-boot.img que nous avons reçu pendant le processus d'assemblage U-Boot). La taille de partition ssbl recommandée est de 2 Mo.
La section du noyau est destinée à y écrire le noyau Linux (fichier zImage ), l'arborescence des périphériques ( fichier stm32mp157a-dk1.dtb ), ainsi que le script pour U-Boot, avec lequel le système sera lancé. La taille de partition du noyau recommandée est de 64 Mo.

La section rootfs sert à écrire le système de fichiers racine. Nous allons essayer d'y écrire le système de fichiers racine compilé par Buildroot, ainsi que le système de fichiers racine d'Arch Linux. La taille de partition rootfs recommandée est de 1 Go ou plus.
La section des données est destinée au stockage des données utilisateur. Vous pouvez créer une ou plusieurs de ces sections. Et vous pouvez vous en passer du tout. Dans cet article, je ne créerai pas cette section.

Donc, nous commençons à baliser. Nous insérons la carte microSD dans le lecteur de carte de notre ordinateur avec Linux à bord et en utilisant tous les moyens disponibles (par exemple, en utilisant dmesg) déterminer le nom de l'appareil qui apparaît. Dans mon cas, c'est / dev / sdb. Dans votre cas, il peut s'agir d'un nom différent.

Exécutez l'utilitaire gdisk et supprimez complètement le balisage sur la carte microSD:

root@debian:/home/myuser# gdisk /dev/sdb
GPT fdisk (gdisk) version 1.0.3
Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help): x
Expert command (? for help): z
About to wipe out GPT on /dev/sdb. Proceed? (Y/N): y
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.
Blank out MBR? (Y/N): y

Au cas où, nous martelons le début de la carte microSD avec des zéros.

dd if=/dev/zero of=/dev/sdb bs=1M count=64

Maintenant, exécutez à nouveau gdisk, ajoutez le balisage et créez 5 partitions sur la carte microSD conformément au tableau que j'ai donné ci-dessus:

root@debian:/home/myuser# gdisk /dev/sdb
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries.

Command (? for help): o
This option deletes all partitions and creates a new protective MBR.
Proceed? (Y/N): y

Command (? for help): n
Partition number (1-128, default 1): 1
First sector (34-30873566, default = 2048) or {+-}size{KMGTP}: 
Last sector (2048-30873566, default = 30873566) or {+-}size{KMGTP}: +256K
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): 
Changed type of partition to 'Linux filesystem'

Command (? for help): n
Partition number (2-128, default 2): 2
First sector (34-30873566, default = 4096) or {+-}size{KMGTP}: 
Last sector (4096-30873566, default = 30873566) or {+-}size{KMGTP}: +256K
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): 
Changed type of partition to 'Linux filesystem'

Command (? for help): n
Partition number (3-128, default 3): 3
First sector (34-30873566, default = 6144) or {+-}size{KMGTP}: 
Last sector (6144-30873566, default = 30873566) or {+-}size{KMGTP}: +2M
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): 
Changed type of partition to 'Linux filesystem'

Command (? for help): n
Partition number (4-128, default 4): 4
First sector (34-30873566, default = 10240) or {+-}size{KMGTP}: 
Last sector (10240-30873566, default = 30873566) or {+-}size{KMGTP}: +64M
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): 
Changed type of partition to 'Linux filesystem'

Command (? for help): n
Partition number (5-128, default 5): 5
First sector (34-30873566, default = 141312) or {+-}size{KMGTP}: 
Last sector (141312-30873566, default = 30873566) or {+-}size{KMGTP}: 
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): 
Changed type of partition to 'Linux filesystem'

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/sdb.
The operation has completed successfully.

Ensuite, ajoutez les noms aux sections sur la carte microSD. Comme vous vous en souvenez, ceci est particulièrement critique pour les premières sections où FSBL sera écrit: si vous ne leur attribuez pas les noms requis, le système ne démarrera pas:

root@debian:/home/myuser# gdisk /dev/sdb
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): c
Partition number (1-5): 1
Enter name: fsbl1

Command (? for help): c
Partition number (1-5): 2
Enter name: fsbl2

Command (? for help): c
Partition number (1-5): 3
Enter name: ssbl

Command (? for help): c
Partition number (1-5): 4
Enter name: kernel

Command (? for help): c
Partition number (1-5): 5
Enter name: roootfs

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/sdb.
The operation has completed successfully.

À la fin du travail avec la carte microSD, nous devons ajouter l' attribut de démarrage BIOS hérité à la section sur laquelle nous allons écrire le noyau Linux. Sans cet attribut, le noyau a refusé de démarrer:

root@debian:/home/myuser# gdisk /dev/sdb
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): x

Expert command (? for help): a
Partition number (1-5): 4
Known attributes are:
0: system partition
1: hide from EFI
2: legacy BIOS bootable
60: read-only
62: hidden
63: do not automount

Attribute value is 0000000000000000. Set fields are:
  No fields set

Toggle which attribute field (0-63, 64 or <Enter> to exit): 2
Have enabled the 'legacy BIOS bootable' attribute.
Attribute value is 0000000000000004. Set fields are:
2 (legacy BIOS bootable)

Toggle which attribute field (0-63, 64 or <Enter> to exit): 

Expert command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/sdb.
The operation has completed successfully.

C'est tout, la disposition de la carte mémoire est prête. Au cas où, vérifiez que tout est enregistré comme il se doit. Pour ce faire, réexécutez gdisk et exécutez la commande p . Le résultat devrait conseiller l'image:



Maintenant, créez le système de fichiers ext4 sur / dev / sdb4 et / dev / sdb5:

mkfs.ext4 /dev/sdb4
mkfs.ext4 /dev/sdb5

Et nous prescrivons des étiquettes de volume pour que plus tard il soit plus facile d'y accéder:

e2label /dev/sdb4 kernel
e2label /dev/sdb5 rootfs

Ceci termine la création de sections de la carte mémoire, vous pouvez y écrire des fichiers.

Enregistrement sur carte MicroSD


Ainsi, au stade actuel, tout est prêt pour l'enregistrement sur une carte microSD. Nous l'insérons dans le lecteur de cartes de l'ordinateur Linux et écrivons le chargeur de démarrage principal (FSBL) dans les première et deuxième sections de la carte mocroSD:

dd if=u-boot/u-boot-spl.stm32 of=/dev/sdb1
dd if=u-boot/u-boot-spl.stm32 of=/dev/sdb2

Maintenant, écrivez U-Boot dans la troisième section de la carte microSD:

dd if=u-boot/u-boot.img of=/dev/sdb3

Ensuite, vous devez copier le noyau, le fichier d'arborescence des périphériques et le script de démarrage dans la quatrième section de la carte microSD.

Avant de commencer à copier des fichiers, vous avez besoin d'une petite explication sur le script de téléchargement. Dans ce script, en fait, diverses informations pour U-Boot sont indiquées, à l'aide desquelles il peut démarrer le système et transférer le contrôle au noyau. Il existe différentes façons d'écrire ces scripts, mais la plus simple (à mon avis) est décrite dans la documentation de STM32MP1: vous devez créer le répertoire / extlinux à la racine de la section du noyau et créer un fichier texte avec le nom extlinux.conf avec le contenu suivant:

LABEL stm32mp157a-dk1
KERNEL /zImage
FDT /stm32mp157a-dk1.dtb
APPEND root=/dev/mmcblk0p5 rootwait rw console=ttySTM0,115200

Tout est assez simple ici: nous disons au chargeur où trouver le noyau, l'arborescence des périphériques, le système de fichiers racine et disons que nous aurons le port ttySTM0 comme console de travail.

Copiez maintenant le noyau:

cp -a buildroot/output/images/zImage /media/myuser/kernel/

Remarque: dans le répertoire / media / myuser /, je monte une carte microSD lorsqu'elle est installée dans le lecteur de carte. Dans votre cas, il peut s'agir d'un répertoire différent.

Copiez le fichier d'arborescence des périphériques:

cp -a buildroot/output/images/stm32mp157a-dk1.dtb /media/myuser/kernel/

Créez un répertoire:

mkdir /media/myuser/kernel/extlinux

Créez un fichier:

nano /media/myuser/kernel/extlinux/extlinux.conf

et remplissez-le avec le contenu:

LABEL stm32mp157a-dk1
KERNEL /zImage
FDT /stm32mp157a-dk1.dtb
APPEND root=/dev/mmcblk0p5 rootwait rw console=ttySTM0,115200

Enregistrez le fichier et fermez l'éditeur.

Sur ce point, la quatrième section de la carte microSD est prête: le noyau linux et tous les fichiers auxiliaires sont déjà écrits. Déjà à ce stade, si vous insérez une carte microSD dans la carte de débogage, le noyau Linux devrait être chargé, cependant, à la fin, il tombera en panne de noyau en raison du fait que le système de fichiers racine ne peut pas être monté. Ce n'est pas surprenant, car nous l'avons enregistré jusqu'à présent.

Il y a la dernière étape, à laquelle nous allons écrire le système de fichiers racine sur la carte microSD. Et ici, différentes options sont possibles:

  1. Écrire le système de fichiers racine généré par Buildroot
  2. Réécrire le système de fichiers racine Arch Linux

Tout d'abord, notez le système de fichiers racine que Buildroot a généré pour nous et essayez de commencer avec. Ce n'était pas le but de cet article, mais il me semblait qu'en général il pourrait être utile pour toutes les applications, d'autant plus que cette action ne prend pas beaucoup de temps. Le système de fichiers racine est écrit dans la cinquième section de notre carte microSD avec une seule commande:

dd if=buildroot/output/images/rootfs.ext4 of=/dev/sdb5

Insérez maintenant la carte mémoire dans la carte de débogage et démarrez le système. Nous observerons la sortie des informations de débogage via la console USB-UART: l'accès est fourni via un port microUSB sur la carte STM32MP157A-DK1. L'affichage des informations affichées est possible dans n'importe quel programme de terminal, par exemple Putty ou Minicom. Pour les besoins de cet article, j'ai utilisé ce dernier en ouvrant une autre fenêtre de terminal dans Debian.

Maintenant, nous insérons la carte microSD dans la carte de débogage, alimentons la carte et regardons le terminal. Si tout a été fait correctement, alors les journaux du noyau FSBL, U-Boot, devraient être versés là-bas et finalement - une invitation à entrer la connexion apparaîtra. Nous entrons en root et - voila - nous arrivons à la console du système que nous venons de collecter:



Oui, il n'a même pas de gestionnaire de paquets, et en général, la fonctionnalité est très médiocre, mais avec l'aide de Buildroot, vous pouvez le créer très cool et créer un système complexe vraiment fonctionnel. En attendant, sa taille n'est que de 7 mégaoctets!



Après vous être assuré que le système de fichiers racine maison démarre correctement, il est temps de démarrer Arch Linux. Insérez à nouveau la carte microSD dans le lecteur de carte de notre ordinateur et formatez à nouveau la cinquième section de la carte mémoire:

mkfs.ext4 /dev/sdb5

Téléchargez l'archive avec Arch Linux, assemblé sous armv7, depuis le site officiel. Décompressez l'archive dans le répertoire archlinux et utilisez la commande:

cp -a archlinux/* /media/myuser/rootfs 

Copiez-le dans la section rootfs de la carte microSD.

Nous nettoyons le répertoire / media / myuser / rootfs / boot: nous n'avons pas besoin du contenu, car le noyau et l'arborescence des périphériques sont dans une section distincte de la carte microSD:

rm –rf /media/myuser/rootfs/boot/*

Plus tard, vous pouvez monter la partition / dev / sdb4 dans le répertoire de démarrage, où nous avons l'image du noyau.

Après cela, insérez la carte microSD dans la carte de débogage, dynamisez et profitez du travail ArchLinux:



Après le démarrage réussi d'Arch Linux, j'ai décidé d'essayer également d'exécuter Debian sur la carte de débogage. En utilisant des manipulations absolument similaires avec le système de fichiers racine, cela a fonctionné avec succès:



Conclusion


Dans cet article, nous avons suffisamment joué avec la carte de débogage STM32MP157A-DK1: placez U-Boot, le noyau Linux, notre propre système de fichiers racine, et avons également lancé Arch Linux et Debian. J'espère que ce matériel sera utile à quelqu'un à la fois lorsque vous travaillez avec des processeurs de la famille STM32MP1 ou avec toute autre carte unique sur ARM.


All Articles