qu'est-ce que le firmware Linux

Sous Linux, le firmware fait référence au « firmware », qui est un programme exécuté par le périphérique matériel lui-même et qui est généralement stocké dans la mémoire flash de l'appareil. Dans un système Linux, le pilote de périphérique est dans l'état du noyau, tandis que le fichier du micrologiciel est dans l'état utilisateur. Par conséquent, un mécanisme sûr, stable et fiable est nécessaire pour garantir que le pilote de périphérique charge correctement le fichier du micrologiciel.

L'environnement d'exploitation de ce tutoriel : système linux7.3, ordinateur Dell G3.

Qu'est-ce que le firmware Linux

Le firmware est un programme exécuté par le périphérique matériel lui-même. 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 en cours d'exécution du périphérique matériel est généralement regroupé dans un fichier de micrologiciel dans un format spécifique, stocké dans le système terminal, et le périphérique matériel est mis à niveau via le système terminal.

Pendant le processus de développement du noyau Linux, les développeurs déboguent les périphériques pilotes, tels que le toucher, la charge, les moteurs linéaires, le stockage, les périphériques WIFI, etc. Il existe également des situations dans lesquelles le micrologiciel doit être mis à jour. Dans un système Linux, le pilote de périphérique est dans l'état du noyau, tandis que le fichier du micrologiciel est dans l'état utilisateur. Par conséquent, un mécanisme sûr, stable et fiable est 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ériques chargeant de manière stable les fichiers du micrologiciel en mode utilisateur à partir du mode noyau, le système Linux fournit un sous-système de micrologiciel.

Présentation du processus du sous-système du micrologiciel Linux

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 fonction du système du micrologiciel pour demander le micrologiciel, le sous-système du micrologiciel utilise le noyau de compilation du micrologiciel pour obtenir le micrologiciel si l'acquisition échoue, le cache du micrologiciel est utilisé pour obtenir le micrologiciel si l'acquisition échoue toujours ; le chemin par défaut du noyau est utilisé. Recherchez directement le firmware. 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 le micrologiciel. Le processus init recherche le micrologiciel sur la base des informations du micrologiciel pointées dans le message uevent et écrit le contenu du micrologiciel obtenu de l'état 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 firmware.

Le système de micrologiciel Linux propose diverses méthodes pour obtenir des fichiers de micrologiciel dans différents scénarios.

1) Méthode de compilation directe dans le noyau ;

2) Méthode de mise en cache du firmware ;

3) Méthode de spécification du chemin directement en fonction du noyau :

4) Méthode d'assistance au traitement via le processus d'initialisation ;

Organigramme du sous-système du micrologiciel Linux

Interface de fonction principale du sous-système du micrologiciel Linux

Interface de fonction principale :

Les principaux types d'interfaces de micrologiciel d'application sont divisés en synchrones et asynchrones.

Habituellement, le processus de demande de micrologiciel prend du temps, et le processus de mise à niveau du micrologiciel prend du temps. Par conséquent, il peut être implémenté à l'aide d'une interface de fonction asynchrone, ou d'abord créer une file d'attente de travail dans le pilote et appeler le synchrone. interface de fonction pour l’implémenter.

Parmi eux :

• Le noyau demande les fichiers du firmware en appelant la fonction request_firmware.

• Une fois que le noyau a obtenu le fichier du firmware, il appelle release_firmware pour libérer la mémoire associée.

Parmi eux :

• L'interface request_firmware_direct recherche uniquement le firmware dans le chemin spécifié par le noyau et n'utilise pas le mécanisme uevent pour obtenir le firmware.

• L'interface request_firmware_nowait obtient le firmware via une file d'attente de travail asynchrone, qui ne peut pas bloquer le temps de sonde du pilote. La fonction request_firmware définit différents bits d'indicateur pour obtenir différentes fonctions différentielles en appelant la fonction _request_firmware_prepare.

Fonction_request_firmware_prepare :

En fonction de l'activation du commutateur macro CONFIG_FW_LOADER, déterminez d'abord si le fichier du firmware 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 chaînée dans la structure globale fw_cache a enregistré le nom du firmware actuellement demandé. Si le nom du micrologiciel actuellement demandé n'existe pas, l'espace mémoire correspondant est alloué dynamiquement et le nom du micrologiciel actuellement demandé est ajouté à la liste chaînée dans la structure globale fw_cache.

La fonction

• fw_get_filesystem_firmware

recherche principalement les fichiers du firmware via le chemin par défaut fourni par le noyau et appelle la fonction kernel_read_file_from_path. Si le fichier du micrologiciel n'est pas trouvé, le bit indicateur FW_OPT_USERHELPER est utilisé pour déterminer si le mode USER_HELPER est activé.

Parmi eux :

Le chemin par défaut dans le système du micrologiciel est le suivant :

Le chemin par défaut peut être ajouté via la ligne de commande du noyau et transmis au chemin de la variable via l'interface module_param_string pour personnaliser le nouveau chemin .

Mode USER_HELPER

Cette fonctionnalité n'est prise en charge qu'une fois que le noyau a activé CONFIG_FW_LOADER_USER_HELPER. La fonction principale est de signaler les messages d'événement au processus d'initialisation via le noyau, d'obtenir des informations sur le micrologiciel via le processus d'initialisation et de les écrire sur le nœud sysfs sous-jacent.

Fonction fw_load_from_user_helper :

Appelez d'abord la fonction fw_create_instance pour créer le périphérique, le fichier de classe et le fichier d'attribut, et allouer la structure firmware_priv.

Ensuite, un répertoire sera créé sous /sys/class/firmware, qui utilise le nom de l'appareil comme nom de répertoire.

Ce répertoire contient trois attributs :

• loading :

  est défini sur 1 : cet attribut est défini par l'espace utilisateur responsable du chargement du firmware commençant par 1

  est défini sur 0 : lorsque le processus de chargement est terminé ; ;

  est réglé sur - 1 : le processus de chargement du micrologiciel sera terminé.

• data :

  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 cet attribut.

• device : Lien symbolique vers l'entrée correspondante sous

  /sys/devices.

• timeout :

  Le délai d'expiration maximum par défaut pour l'application du micrologiciel via uevent est de 60 S, et le délai d'expiration d'écriture de la couche supérieure est pris en charge.

Fonction_request_firmware_load :

Désactivez d'abord le rapport uevent, ajoutez l'appareil en appelant la fonction device_add et déclenchez l'appel de la fonction firmware_uevent. Parmi eux, remplissez le format d'informations signalé par uevent, y compris le nom du firmware, le délai d'attente et s'il est asynchrone.

L'étape suivante consiste à activer la fonction de rapport uevent, à appeler la fonction kobject_uevent en même temps et à signaler le type d'action d'ajout à la couche supérieure ueventd.

Appelez ensuite la fonction fw_state_wait_timeout et attendez le traitement de la couche supérieure ueventd dans le délai d'expiration prédéfini.

Si le délai d'attente atteint ou se réveille après avoir reçu le montant d'achèvement, la mémoire précédemment appliquée sera libérée et les informations sur la mémoire telles que l'appareil et la classe seront libérées.

Processus 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, la surveillance des rapports du noyau sur les messages uevent, le chargement du micrologiciel, etc.

Flux de traitement 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, déterminez si le type de sous-système du message uevent est le champ du firmware avant le traitement. Ce type ne peut être signalé que par le module du firmware dans le noyau.

HandleUevent crée principalement différents sous-threads via un thread principal et traite en parallèle les demandes de firmware de différents pilotes du noyau.

Fonction ProcessFirmwareEvent

Tout d'abord, elle boucle pour déterminer si le fichier du firmware récupéré dans le chemin pris en charge par ueventd existe s'il existe, écrivez le fichier d'attribut de chargement sous-jacent sur 1, copiez le fichier du firmware obtenu et écrivez-le ; au fichier de données sous-jacent. Une fois terminé, 0 est écrit dans le fichier d'attributs de chargement sous-jacent.

À ce stade, le noyau a obtenu les informations du fichier du firmware écrites par l'espace utilisateur.

Parmi eux :

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.

Recommandations associées : "Tutoriel vidéo Linux"

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!