1. Présentation du sous-système du micrologiciel Linux
Le micrologiciel est un morceau de programme que le périphérique matériel lui-même exécute. Le micrologiciel est généralement stocké dans la mémoire flash de l'appareil. Pour des raisons de coût et de commodité, le programme d'exploitation du dispositif matériel est généralement intégré dans un fichier de micrologiciel dans un format spécifique, stocké dans le système terminal, et le dispositif matériel est mis à niveau via le système terminal. Au cours du processus de développement du noyau Linux, les développeurs déboguent les périphériques d'entraînement, tels que le toucher, la charge, les moteurs linéaires, le stockage, les périphériques WIFI, etc., et il existe également des cas où le micrologiciel doit être mis à jour. Dans le système Linux, le pilote de périphérique est à l'état du noyau et le fichier du micrologiciel est à l'état utilisateur. Un mécanisme sûr, stable et fiable est donc nécessaire pour garantir que le pilote de périphérique charge correctement le fichier du micrologiciel. Afin de résoudre le problème des pilotes de périphérique chargeant de manière stable les fichiers de micrologiciel en mode utilisateur à partir du mode noyau, le système Linux fournit un sous-système de micrologiciel.
2. Mécanisme de mise en œuvre du sous-système du micrologiciel Linux
1. Présentation du processus :
Le sous-système du micrologiciel Linux est implémenté sur la base des mécanismes sysfs et uevent.
Une fois que le pilote a appelé l'interface de la fonction système du micrologiciel pour demander le micrologiciel, le sous-système du micrologiciel utilise la méthode de compilation du noyau pour obtenir le micrologiciel ; si l'acquisition échoue, il utilise le cache du micrologiciel pour obtenir le micrologiciel ; si l'acquisition échoue toujours , il utilise le chemin par défaut pour rechercher directement le chemin du noyau pour obtenir le micrologiciel. Si l'acquisition échoue toujours, signalez le message uevent au processus init. Le processus init reçoit le message uevent et filtre les messages dont le type de sous-système est micrologiciel. Le processus d'initialisation recherche le micrologiciel en fonction des informations du micrologiciel pointées dans le message uevent et écrit le contenu du micrologiciel obtenu de l'état de l'utilisateur à l'état du noyau via l'interface de nœud de fichier fournie par sysfs, afin que le pilote puisse obtenir les données. du fichier du micrologiciel.
Le système de micrologiciel Linux fournit une variété de méthodes pour obtenir des fichiers de micrologiciel dans différents scénarios.
1) La méthode de compilation directe vers le noyau ;
2) Le mode de cache du firmware ;
3) Spécifiez directement le chemin selon le noyau :
4) La manière d'aider au traitement à travers le processus d'initialisation ;
2. Organigramme :
3. Interface de fonction principale :
Interface de fonction principale : les principaux types d'interfaces de micrologiciel d'application sont divisés en synchrone et asynchrone.
Habituellement, le processus de demande de micrologiciel prend du temps et le processus de traitement des mises à niveau du micrologiciel prend du temps. Il peut donc être réalisé en utilisant une interface de fonction asynchrone ou en créant une file d'attente de travail dans le pilote pour appeler une interface de fonction synchrone. . dans:
- Le noyau demande un fichier de micrologiciel en appelant la fonction request_firmware.
- Une fois que le noyau a obtenu le fichier du micrologiciel, il appelle release_firmware pour libérer la mémoire associée.
dans:
- L'interface request_firmware_direct recherche uniquement le micrologiciel dans le chemin spécifié par le noyau et n'utilise pas le mécanisme uevent pour obtenir le micrologiciel.
- L'interface request_firmware_nowait obtient le micrologiciel via une file d'attente de travail asynchrone, qui peut jouer un rôle en ne bloquant pas le temps de sonde de conduite.
4. Processus de mise en œuvre :
(1) processus de mise en œuvre de request_firmware :
La fonction request_firmware définit différents bits d'indicateur en appelant la fonction _request_firmware_prepare pour réaliser différentes fonctions de différence.
a. Fonction _request_firmware_prepare :
Sur la base de l'activation du commutateur de macro CONFIG_FW_LOADER, jugez d'abord si le fichier du micrologiciel est compilé dans le noyau en appelant la fonction fw_get_builtin_firmware.
Appelez ensuite la fonction fw_lookup_and_allocate_buf pour déterminer si la liste liée dans la structure fw_cache globale a enregistré le nom du micrologiciel de requête actuel. Si le nom du micrologiciel actuellement demandé n'existe pas, allouez dynamiquement l'espace mémoire correspondant et ajoutez le nom du micrologiciel actuellement demandé à la liste liée dans la structure globale fw_cache.
b. Fonction fw_get_filesystem_firmware :
Principalement via le chemin par défaut fourni par le noyau pour trouver le fichier du firmware, appelez la fonction kernel_read_file_from_path. Si le fichier du micrologiciel n'est pas trouvé, déterminez s'il faut activer le mode USER_HELPER via le bit d'indicateur FW_OPT_USERHELPER.
dans:
Le chemin par défaut dans le système Firmware est le suivant :
Le chemin par défaut peut ajouter un chemin via la ligne de commande du noyau et le transmettre au chemin variable via l'interface module_param_string pour personnaliser le nouveau chemin.
Informations via le train : Itinéraire d'apprentissage de la technologie du code source du noyau Linux + didacticiel vidéo sur le code source du noyau
Apprentissage par le train : code source du noyau Linux réglage de la mémoire gestion des processus du système de fichiers pilote de périphérique/pile de protocole réseau
(2) Mode USER_HELPER :
Cette fonctionnalité n'est prise en charge qu'après l'ouverture du noyau CONFIG_FW_LOADER_USER_HELPER. La fonction principale est de signaler le message uevent au processus init via le noyau, d'obtenir les informations du micrologiciel via le processus init et de les écrire sur le nœud sysfs sous-jacent.
a. Fonction fw_load_from_user_helper :
Appelez d'abord la fonction fw_create_instance pour créer le périphérique périphérique, le fichier de classe et le fichier d'attributs, puis allouez la structure firmware_priv.
Un répertoire sera alors créé sous /sys/class/firmware avec le nom de l'appareil comme nom de répertoire.
Ce répertoire contient trois propriétés :
- chargement:
Mis à 1 : Cet attribut est mis à 1 par l'espace utilisateur responsable du chargement du firmware ;
Mis à 0 : lorsque le processus de chargement est terminé ;
Réglé sur -1 : mettra fin au processus de chargement du micrologiciel.
- données:
Il est utilisé pour recevoir les données du micrologiciel. Une fois le chargement défini, le processus de l'espace utilisateur écrit le micrologiciel dans cette propriété.
- appareil:
Un lien symbolique vers l'entrée correspondante sous /sys/devices.
- temps mort:
Par défaut, le délai d'expiration maximal de l'application du micrologiciel via uevent est de 60 secondes et le délai d'expiration d'écriture de la couche supérieure est pris en charge. b. Fonction _request_firmware_load :
Tout d'abord, désactivez le rapport uevent, ajoutez un périphérique en appelant la fonction device_add et déclenchez l'appel à la fonction firmware_uevent. Parmi eux, remplissez le format d'information rapporté par uevent, y compris le nom du micrologiciel, le délai d'expiration et s'il est asynchrone.
L'étape suivante consiste à activer la fonction de rapport uevent et à appeler en même temps la fonction kobject_uevent pour signaler le type d'action d'ajout à la couche supérieure ueventd.
Appelez ensuite la fonction fw_state_wait_timeout pour attendre le traitement de la couche supérieure ueventd dans le délai d'attente prédéfini.
Si le délai d'attente est atteint ou si le réveil est reçu, la mémoire précédemment demandée sera libérée et les informations de mémoire telles que l'appareil et la classe seront libérées.
(3) flux de traitement du micrologiciel lié à ueventd
Ueventd est un module important dans le processus d'initialisation. Il gère principalement selinux, la création de périphériques de développement, l'écoute du noyau pour signaler les messages uevent, le chargement du micrologiciel, etc.
a. Flux de traitement du FirmwareHandler :
La méthode HandleUevent dans FirmwareHandler gère principalement le processus d'interaction entre le chargement du micrologiciel et les nœuds sous-jacents.
Tout d'abord, il est jugé que le type de sous-système du message uevent est le champ du micrologiciel avant traitement.Ce type n'est signalé que par le module de micrologiciel dans le noyau.
HandleUevent crée principalement différents sous-threads via un thread principal et traite les demandes de micrologiciel de différents pilotes du noyau en parallèle.
b. Fonction ProcessFirmwareEvent :
La première étape consiste à boucler pour déterminer si le fichier de micrologiciel de récupération existe dans le chemin pris en charge par ueventd ; s'il existe, écrivez le fichier d'attributs de chargement sous-jacent en tant que 1, puis copiez le fichier de micrologiciel obtenu et écrivez-le dans le fichier de données sous-jacent. Une fois terminé, il sera écrit dans le fichier de propriétés de chargement sous-jacent en tant que 0.
Jusqu'à présent, le noyau a obtenu les informations du fichier du micrologiciel écrites par l'espace utilisateur.
dans:
ueventd prend en charge le chemin de recherche du firmware par défaut :
À partir du répertoire_firmware spécifié dans le fichier ueventd.rc.
Auteur original : Kernel Craftsman
