FR2850471A1

FR2850471A1 - Systeme et procede pour utiliser une table d'interface microprogrammee pour charger de maniere dynamique plusieurs tables ssdt acpi.

Info

Publication number: FR2850471A1
Application number: FR0309694A
Authority: FR
Inventors: Shira Qureshi; Chris Denamur
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Development Co LP
Priority date: 2002-08-07
Filing date: 2003-08-06
Publication date: 2004-07-30
Also published as: US7017034B2; US20040030875A1; JP2004070952A

Abstract

La table d'interface microprogrammée (FIT) (109) d'un jeu d'instructions IA-64 est utilisée pour peupler l'espace des noms de composants matériels en utilisant des données de table SSDT, où les données de table SSDT décrivent des composants dans le système. A l'époque du lancement, tous les composants matériels sont découverts. Le sous-système d'interface ACPI, dans le microprogramme du système, consomme la configuration des données et charge les tables SSDT à partir de la table FIT (109) pour créer l'espace des noms pour les composants actifs du système. Il existe un genre de table FIT indiquant une entrée de table SSDT, et le sous-genre est indiqué en utilisant le champ version (119) de la table FIT.

Description

ARRI RE-PLAN

L'interface ACPI (" Advanced Configuration and Power Interface ", interface avancée pour la configuration et l'alimentation) est une spécification 5 qui rend les informations d'état d'un matériel disponibles pour un système d'exploitation dans des ordinateurs, en incluant les ordinateurs portables, les ordinateurs de bureau, les serveurs etc. On peut trouver des informations plus détaillées au sujet de 10 l'interface ACPI dans les 500 pages de " Advanced Configuration and Power Interface Specification " (spécification de l'interface avancée pour la configuration et l'alimentation) révision 2.0a, du 31 mars 2002, définie de manière coopérative par des 15 sociétés Compaq Computer Corporation, Intel Corporation, Microsoft Corporation, Phoenix Technologies Ltd et Toshiba Corporation. La spécification de l'interface ACPI a été développée pour établir des interfaces industrielles communes 20 permettant une configuration robuste de dispositifs de cartes mères orientés vers un système d'exploitation (OS) ainsi qu'une gestion de l'alimentation des dispositifs et des systèmes entiers à la fois.

L'interface ACPI est l'élément clef dans la 25 configuration et la gestion de l'alimentation orientées vers un système d'exploitation (OSPM).

L'interface ACPI est utilisée dans des ordinateurs personnels (PC) exécutant une variété de systèmes d'exploitation, tels que WindowsTM, disponible auprès de 30 Microsoft Corporation, Linux, disponible comme source ouverte auprès d'une variété de vendeurs, et HP-UX, disponible auprès de Hewlett-Packard Company.

L'interface ACPI permet aussi de manipuler des ressources matérielles. Par exemple, l'interface ACPI 35 aide à gérer l'alimentation en permettant aux périphériques d'un système informatique d'être allumés et éteints pour une gestion améliorée de l'alimentation. L'interface ACPI permet aussi au système informatique d'être allumé et éteint par des 5 dispositifs extérieurs. Par exemple, le toucher d'une souris ou l'appui sur une touche peut réveiller un système informatique utilisant l'interface ACPI.

De manière traditionnelle, il a été difficile de travailler avec l'interface ACPI pour une variété de 10 raisons. En premier lieu, l'interface ACPI n'est pas écrite dans le langage assembleur natif d'une plateforme d'un système informatique quelconque. Au lieu de cela, l'interface ACPI possède son propre langage source et son propre langage machine, qui sont 15 le langage source ACPI (ASL) et le langage machine ACPI (AML), respectivement. Du fait de son utilisation hautement spécialisée, il y a relativement peu de programmeurs en langage ASL. En outre, le langage ASL a relativement peu de mises en application du fait de son 20 utilisation limitée. En outre, de manière conventionnelle, le code ACPI est monolithique dans sa conception. En conséquence, ceci rend difficile de porter le code ACPI dans d'autres plateformes ou même dans différentes configurations de la même plateforme. 25 En conséquence, un nouveau code ASL doit être écrit pour travailler avec des plateformes nouvellement développées. Le nombre limité de programmeurs en ASL rend l'écriture d'un nouveau code encore plus problématique et coteuse.

L'interface ACPI est composée à la fois de tables statiques et interprétables. A l'époque du lancement, le microprogramme du système (typiquement le BIOS, c'est-à-dire le système d'entrée/ sortie de base) construit les tables statiques, qui sont consommées par 35 le système d'exploitation. Les tables interprétables sont composées de langage AML, qui est compilé puis fusionné dans le microprogramme du système. Le système d'exploitation lit le langage AML à partir des tables interprétables et exécute les interfaces ainsi 5 architecturées, en utilisant un interpréteur ACPI. De cette manière, le système d'exploitation manipule des ressources matérielles. Parce que les tables interprétables sont fusionnées dans le microprogramme du système, ce procédé conventionnel manque de 10 souplesse et de possibilité de mise à l'échelle, et nécessite un temps de reprogrammation considérable pour accommoder des configurations de système divergentes.

Par exemple, de manière conventionnelle, les développeurs en langage ASL écrivent un code 15 d'interface ACPI pour préciser une configuration particulière d'une plateforme ou ses variantes.

Malheureusement, si même un changement matériel mineur est effectué, la conception doit être modifiée. Ceci nécessite d'écrire un nouveau code en langage AML et de 20 fusionner de nouvelles tables dans le microprogramme du système. Par conséquent, la conception conventionnelle n'est pas portable ni réutilisable.

En outre, l'interface ACPI a nécessité de manière conventionnelle qu'un microprogramme différent en ROM 25 (mémoire à lecture seule) ou un BIOS pour le système soit utilisé s'il existe une variante de la plateforme ou si elle soutient plus d'un système d'exploitation conscient de l'interface ACPI, là o les systèmes d'exploitation possèdent des contraintes d'interface 30 ACPI mutuellement exclusives. Un microprogramme différent en ROM pour le système devait aussi être utilisé si le même système devait soutenir plusieurs systèmes d'exploitation. Par exemple, une technique courante dans les ordinateurs personnels utilise le jeu 35 d'instructions IA-32. L'interface ACPI a été utilisée X 4 de manière primaire par la famille de systèmes d'exploitation de Microsoft@, en particulier dans des systèmes soutenant le jeu d'instructions IA-32.

L'interface ACPI a été acceptée comme étant 5 l'interface standard par les différents systèmes d'exploitation. Une nouvelle architecture de jeu d'instructions, IA-64, est en cours de développement, mais ses avantages ne peuvent pas être utilisés de manière complète avec le legs du code ou les procédés 10 de l'interface ACPI. Itanium , la nouvelle famille de processeurs, disponible auprès de Intel Corporation, utilise le jeu d'instructions IA-64. Le langage ASL pour chaque nouvelle plateforme ou configuration de système basée sur le processeur de cette famille 15 nécessitera d'être réécrit de manière unique si les pratiques courantes sont utilisées.

L'espace des noms de l'interface ACPI est une structure arborescente hiérarchique dans une mémoire placée sous le contrôle d'un système d'exploitation qui 20 contient les objets nommés. Ces objets peuvent être des objets de données, des objets de procédés de commande, des objets de paquets bus/ dispositifs et ainsi de suite. Le système d'exploitation change de manière dynamique le contenu de l'espace des noms à l'époque de 25 l'exécution en chargeant ou en déchargeant des blocs de définition à partir des tables de l'interface ACPI qui résident dans le BIOS de l'interface ACPI. Toute l'information dans l'espace des noms de l'interface ACPI vient de la table de description du système 30 différencié (DSDT), qui contient le bloc de définition différenciée et un ou plusieurs autres blocs de définition. Dans la technique courante, un fabricant d'équipement d'origine (OEM) doit fournir une table DSDT à un système d'exploitation compatible avec 35 l'interface ACPI, qui fournit l'information d'exécution et de configuration relative au système de base. Le système d'exploitation insère toujours l'information de table DSDT dans les espaces de nom de l'interface ACPI à l'époque du lancement du système et ne l'enlève jamais.

Une autre construction de l'interface ACPI est la table de description secondaire du système (SSDT). Les tables SSDT sont une suite de la table DSDT. Plusieurs tables SSDT peuvent être utilisés comme des parties de 10 la description d'une plateforme. Lorsque la table DSDT a été chargée dans l'espace des noms de l'interface ACPI, on charge chaque table de description secondaire avec une table d'identité (ID) OEM unique. Ceci permet à l'OEM de fournir le soutien de base dans une table, 15 tout en ajoutant de plus petites options du système dans d'autres tables. Les tables supplémentaires peuvent ajouter des données uniquement. Elles ne peuvent pas écraser des données issues de tables précédentes.

Une construction dans l'architecture ACPI définie par la couche d'abstraction du système (SAL) est une table du microprogramme d'interface (FIT). Celle-ci est une construction du jeu d'instructions IA- 64. La table FIT contient des adresses de départ et des tailles de 25 composants du microprogramme qui sont hors du bloc de lancement protégé. Une bonne vue d'ensemble de la spécification de l'entrée dans une table FIT peut être trouvée dans " ITANIUM Processor Family System Abstraction Layer Specification " (spécification de la 30 couche d'abstraction du système de la famille de processeur ITANIUMN) document N' 245359-005, (Intel juillet 2002), disponible à l'adresse http://www.intel. com/design/itanium/downloads/24535905. pdf.

Claims

RESUME DE L'INVENTION Dans un premier aspect, l'invention propose un microprogramme pour plusieurs plateformes et pour plusieurs systèmes d'exploitation pour des processeurs 5 utilisant un jeu d'instructions IA-64, comprenant: un microprogramme de système pour lancer un système informatique, le microprogramme de système ayant un premier bloc de mémoire codé avec des instructions de lancement et ayant un deuxième bloc de mémoire pour 10 stocker des données; le deuxième bloc de mémoire étant accessible pendant le lancement du système, le deuxième bloc de mémoire étant peuplé d'informations en correspondance à des composants du système informatique; une table d'interface microprogrammée 15 (FIT) résidant dans le deuxième bloc de mémoire, la table FIT comprenant des entrées ayant un champ d'adresse, un champ de taille et un champ de genre et dans lequel le champ d'adresse d'une entrée de table FIT pointe vers un emplacement de la mémoire en 20 correspondance à des données pour le genre de l'entrée; et au moins une entrée de table FIT dans la table FIT identifiant une table de description secondaire du système (SSDT) , dans lequel la table SSDT comprend des informations décrivant au moins un 25 composant du système, et dans lequel une table SSDT est identifiée par un genre unique de table FIT et un sousgenre utilisant le champ version d'une table FIT, l'entrée de table FIT étant récupérée au moment du lancement pour décrire un espace de noms pour des 30 composants actifs du système. Dans une variante de mode de réalisation de l'invention sous son premier aspect, l'invention propose ledit microprogramme dans lequel l'entrée de table FIT comprend en outre une somme de contrôle et une information de version. Dans une autre variante de mode de réalisation de l'invention sous son premier aspect, l'invention propose ledit microprogramme dans lequel l'information 5 de table SSDT est combinée aux informations issues d'une table de descripteur du système différencié (DSDT), dans lequel l'information de table DSDT réside en mémoire dans le deuxième bloc de mémoire. Dans cette variante de ce mode de réalisation de 10 l'invention sous son premier aspect, l'invention propose en outre ledit microprogramme, dans lequel l'information de table SSDT peut résider dans un troisième bloc de mémoire, le troisième bloc de mémoire résidant à l'extérieur du microprogramme. Dans une autre variante de mode de réalisation de l'invention sous son premier aspect, l'invention propose le microprogramme précédent dans lequel l'information de table SSDT est combinée aux informations issues de la table de descripteur du 20 système différencié (DSDT), l'information de table DSDT et l'information de table SSDT résidant dans un troisième bloc de mémoire, le troisième bloc de la mémoire résidant à l'extérieur du microprogramme. Dans un deuxième aspect, l'invention propose un 25 procédé pour récupérer des données de table SSDT depuis une table FIT au moment du lancement d'un système pour engendrer un espace de noms pour les composants actifs du système, ledit procédé comprenant les étapes consistant à stocker, pour chaque composant du 30 système, les informations du composant du système en correspondance dans un emplacement de la mémoire pour stocker une table de description secondaire du système (SSDT) ; déterminer une configuration de système pour des composants actifs dans un système informatique, la 35 détermination se produisant au moment du lancement du système; charger une table d'interface microprogrammée (FIT) avec des entrées de table SSDT, chaque entrée de table SSDT pointant vers un emplacement de la mémoire stockant des informations de table SSDT en 5 correspondance, les entrées chargées correspondant à des composants du système, une entrée de table FIT étant identifiée comme une entrée de table SSDT par un champ genre, et l'entrée de table SSDT ayant un sousgenre identifié dans un champ version d'une entrée de 10 table FIT; et initialiser l'espace des noms des composants du système avec la configuration du système déterminée pour les composants actifs du système. Dans une variante de mode de réalisation de l'invention sous son deuxième aspect, l'invention 15 propose que ledit procédé comprenne en outre l'étape consistant à transférer le contrôle depuis le microprogramme du système vers le système d'exploitation sélectionné, le système d'exploitation consommant l'espace des noms des composants du système 20 pour définir des interactions des composants du système. Dans une variante de mode de réalisation de l'invention sous son deuxième aspect, l'invention propose que la table d'interface microprogrammée (FIT) 25 réside dans un premier bloc de mémoire, et que la table FIT comprenne des entrées ayant une adresse, une taille et un genre, et que l'adresse d'une entrée de table FIT pointe vers un emplacement de la mémoire en correspondance à des données de genre de l'entrée. Dans une variante de ce mode de réalisation de l'invention sous son deuxième aspect, l'invention propose qu'une entrée de table FIT pointe vers un emplacement de la mémoire externe au premier bloc de mémoire. Dans une variante de mode de réalisation de l'invention sous son deuxième aspect, l'invention propose ledit procédé, lequel l'étape consistant à initialiser l'espace des noms des composants du système comprenne en outre une étape consistant à combiner des 5 informations de table SSDT à des informations issues d'une table de descripteur du système différencié (DSDT). DESCRIPTION DES DESSINS La description détaillée fera référence aux 10 dessins suivants, dans lesquels des références numériques identiques se rapportent à des éléments identiques et dans lesquels: la figure 1 montre un diagramme par blocs d'un microprogramme en ROM, donné à titre d'exemple, ayant 15 un microprogramme de table d'interface; la figure 2 montre un espace de noms, donné à titre d'exemple pour une table DSDT; la figure 3 montre un espace de noms, donné à titre d'exemple pour une table SSDT; la figure 4 montre un espace de noms combinant les composants de la table DSDT de la figure 2 et de la table SSDT de la figure 3; les figures 5A et 5B sont des diagrammes par blocs de systèmes, donnés à titre d'exemple, ayant un 25 adaptateur de bus du système et au moins un adaptateur de bus local et des fentes de connexion (" slots ") en correspondance; la figure 6A montre un exemple d'un espace de noms d'une table DSDT en correspondance à des composants 30 matériels montrés en commun pour les figures 5A et 5B; la figure 6B montre un exemple d'un espace des noms d'une table SSDT en correspondance aux composants matériels montrés à la figure 5A qui ne sont pas inclus dans l'espace des noms de la table DSDT de la figure 6A; la figure 6C montre un exemple d'un espace de noms d'une table SSDT en correspondance aux composants matériels montrés à la figure 5B qui ne sont pas inclus 5 dans l'espace des noms de la table DSDT de la figure 6A; et la figure 7 est un organigramme montrant, à titre d'exemple, un procédé pour engendrer l'espace des noms des composants du système en utilisant une table DSDT 10 et au moins une entrée de table FIT des tables SSDT. DESCRIPTION D TAILL E L'interface ACPI est un concept de jeu d'instructions IA-32 qui est encore utilisé pour le nouveau jeu d'instructions IA-64. L'interface ACPI est 15 une manière permettant d'abstraire la manipulation du matériel et des données de configuration pour définir la configuration du matériel pour une interaction du système d'exploitation (OS) et du microprogramme. L'interface ACPI est une spécification d'un standard 20 industriel. De manière courante, les trois systèmes d'exploitation commerciaux majeurs des ordinateurs personnels (PC), c'est-à-dire Linux, HP/ UX et Windows>, utilisent une interface ACPI dans un espace IA-32 et fonctionneront en utilisant une interface ACPI 25 dans le nouvel espace IA-64. Au lancement du système, le microprogramme est alimenté et détermine la configuration du système. Le système est initialisé, si besoin est, puis l'opération est passée au système d'exploitation, c'est-à-dire lance le système 30 d'exploitation. Lorsqu'un système est lancé, il doit avoir une connaissance des différentes configurations de la plateforme. L'interface ACPI est une spécification pour la configuration matérielle qui possède des objets d'interface et un espace de noms de l manière à définir des configurations divergentes de la plateforme. Il est souhaitable de rendre la création de code de l'interface ACPI pour les nouvelles plateformes plus 5 structurée et plus indépendante de la plateforme. Ceci peut être obtenu en utilisant des approches architecturées avec une conception modulaire pour le code de l'interface ACPI. Ce procédé pour concevoir l'interface ACPI n'est pas utilisé de manière courante, 10 et est en fait désapprouvé par les développeurs. Un autre problème avec les conceptions antérieures de l'interface ACPI est que les développeurs de l'interface ACPI devaient décrire de manière complète toute variante quelconque d'une plateforme donnée en 15 utilisant le langage ASL. La conception ne permettait pas la portabilité ou la réutilisation si des modifications matérielles même mineures étaient effectuées, qui comprenaient la perte d'un composant matériel pendant le lancement. En outre, la même ROM ne 20 pouvait pas être employée par une variante d'un genre de plateforme donné ou si ce même système soutenait plusieurs systèmes d'exploitation. Un espace de noms décrit la hiérarchie d'un système informatique d'une manière logique. Par 25 exemple, lorsque le système d'exploitation consomme l'espace de noms, il obtient une image de ce que à quoi le matériel ressemble en dessous. Par conséquent, si le système d'exploitation a besoin d'obtenir-une ressource pour un matériel donné ou s'il a besoin de connaître 30 comment accéder à un composant, il regarde dans l'espace des noms. Par exemple, si le système d'exploitation doit mettre la machine en veille, il existe un objet qui identifiera comment mettre un dispositif en veille. Le système d'exploitation utilise 35 les interfaces ou les objets définis dans l'espace des noms pour manipuler le matériel. C'est la fonction de l'interface ACPI. Un avantage des présents système et procédé est qu'ils permettent à différentes plateformes, et à des 5 configurations multiples de ces plateformes particulières, de fonctionner en utilisant un microprogramme programmé de manière commune ou générique. Un souhait couramment insatisfait du microprogramme actuel est qu'il est utilisable dans une 10 seule configuration d'une plateforme. Les présents système et procédé permettent d'obtenir un microprogramme d'un système qui opérera avec les trois systèmes d'exploitation majeurs en même temps. Par conséquent, le microprogramme n'aura pas besoin d'être 15 mis à jour/ modifié à chaque fois que l'on change la configuration ou le système d'exploitation. Ceci nécessite que le système d'exploitation ait une connaissance de quel système d'exploitation est en cours d'exécution sur la plateforme à l'époque du 20 lancement, entre autres choses. Le jeu d'instructions IA-64 décrit comment le microprogramme d'un système est disposé sur le composant ROM du matériel du système. Il existe différents composants formant des microprogrammes qui 25 sont fusionnés ensemble dans le système, qui comprennent des tables de langage AML de l'interface ACPI, une table statique d'interface ACPI et une couche SAL (couche d'abstraction du système) qui est purement un microprogramme. Un microprogramme de table 30 d'interface (FIT) réside dans le microprogramme pour décrire o en mémoire les tables d'interface ACPI et les autres informations nécessaires existent. La table FIT possède un certain nombre de champs et chaque champ possède un genre. Le genre du champ identifie le genre 35 du composant. Par conséquent, les genres des composants sont architecturés. Par exemple, un genre OxE (E hexadécimal) pourrait indiquer une spécificité de processeur PAL (" processor abstraction layer " couche d'abstraction de processeur). Il existe aussi une plage 5 de genres qui sont des champs de vendeur OEM (" original equipment manufacter ", fabricant d'équipement d'origine). En nous reportant maintenant aux dessins et en particulier à la figure 1, nous montrons à titre 10 d'exemple une ROM 100 de système pour un microprogramme associé au jeu d'instructions IA-64. La ROM 100 est composée de plusieurs zones, par exemple une couche SAL 101, une couche PAL 103, une zone de table SSDT 105, des tables d'interface ACPI 107 et une table FIT 109. 15 La table FIT possède un certain nombre de champs, par exemple une adresse 111, une taille 113, une somme de contrôle (checksum) 115, un genre 117, une version 119, etc. Pour cet exemple, l'adresse 111 de la table FIT pointe vers le début de la couche SAL 101. La taille 20 113 indique de quelle longueur est la zone de couche SAL de manière à pouvoir récupérer le nombre correct d'octets à la demande. Il peut y avoir une somme de contrôle 115 pour assurer l'intégrité des données dans la ROM. Les tables de l'interface ACPI 107 peuvent être statiques ou dynamiques (c'est-à-dire interprétables), en fonction de la table spécifique. Pour créer l'espace des noms du système, une table DSDT (" differentiated system descriptor table ", table des descripteurs du 30 système différencié) est stockée dans la table FIT. Le jeu d'instructions IA-64 nécessite la présence d'une table DSDT. La table DSDT définit la partie du langage AML qui peut être exécutée. La table DSDT définit les composants matériels de la racine du système. 35 L'interface ACPI permet aussi à des tables SSDT (" secondary system description tables ", tables de description secondaire du système) 115. Lorsque l'interpréteur d'interface ACPI s'exécute, il récupère la table DSDT et toutes les tables SSDT pour créer l'espace des noms du système combiné. Une entrée individuelle de table SSDT est créée pour chaque configuration pour un genre de composant présent dans le système. Par exemple, si un système peut avoir deux variantes par rapport à des adaptateurs 10 de bus local, alors deux tables SSDT seront engendrées pour définir les composants de l'adaptateur de bus local, par exemple un pour chaque variante de configuration de la plateforme. Chaque table SSDT possède son propre genre 117. Par exemple, un genre 55 15 à 80 pourrait être dédié à différents genres de table SSDT. Ce procédé fonctionne bien avec une plateforme ayant peu de variantes de configuration. Cependant, pour des systèmes qui peuvent avoir plusieurs configurations et plusieurs systèmes d'exploitation 20 possibles, la plage des genres de table SSDT peut déborder la plage permise. Il est par conséquent souhaitable d'utiliser un genre pour une table SSDT et d'utiliser un autre champ dans l'entrée de la table FIT pour indiquer le genre et la configuration spécifique 25 du composant. Le champ version 119 n'est pas utilisé pour ce genre d'entrée de table FIT de sorte qu'il est utilisé de manière avantageuse sans aucune dégradation par d'autres opérations de la table FIT. Il sera apparent à celui qui a des compétences dans la 30 technique, que d'autres champs inutilisés pourraient être utilisés, ou que des champs pourraient recartographiés pour d'autres utilisations, aussi longtemps que la spécification du microprogramme n'est pas violée et que le microprogramme peut décoder les 35 entrées de la table FIT. En nous reportant à la figure 2, nous montrons, à titre d'exemple, un nom d'espace 200 d'une table DSDT. Le bus du système racine (SB) dans une carte système est _SB 201, ayant un adaptateur pour le bus du système 5 (SBA) _SBAO 203. Le système SBA _SBAO possède un composant PCI (" peripheral component interconnect/ interface ", interconnexion/ interface de composant périphérique), PCI-1 205. Le _SBAO et le PCI-1 ont un -CRS 209 et CRS 207 associé respectivement. La table 10 DSDT peut ne pas décrire le système entier. Par exemple, elle peut décrire la partie du système informatique qui doit nécessairement être opérationnelle pour un lancement réussi. La figure 3 montre une table SSDT à titre d'exemple qui, à l'époque 15 du lancement est combinée à la table DSDT pour décrire le système entier. En nous reportant maintenant à la figure 3, la table SSDT 300 a une racine _SB._SBAO 301. Ce nom indique que les enfants suivants dans cet espace de 20 noms sont associés à l'enfant _SBAO 203 de la racine -SB 201 dans la table DSDT 200. La notation _SB._SBAO est orientée objet par nature. Un noeud enfant est d'une manière générale un composant de son parent. Le composant _SB._SBAO 301 possède un composant PCI, PCI25 5 303, et PCI-5 303 possède un état STA 305 qui lui est associé. Au lancement du système, la table DSDT et la table SSDT sont combinées pour créer l'espace des noms du système 400 comme nous le montrons à la figure 4. En nous reportant à la figure 4, nous montrons un espace de noms combiné 400 pour un bus du système _SB 401. Le bus du système possède un enfant SBA _SBAO 403 qui comprend maintenant des composants PCI PCI-1 205 et PCI5 303 qui possèdent des enfants qui leur sont 35 associés, comme cela est défini dans les espaces des noms de la table DSDT 200 et de la table SSDT 300. Un avantage à architecturer de manière dynamique l'espace des noms complet est que l'on peut accommoder différentes configurations avec la même ligne de base 5 du microprogramme. Il est possible de définir des différences de configuration dans une ou plusieurs zones de table SSDT. En nous reportant à nouveau à la figure 1, une entrée de table SSDT dans la table FIT 109 sera identifiée par son genre 117 et sa version 10 119. La table FIT 109 pointe vers une ou plusieurs tables SSDT 105 et est lue à l'époque du lancement. Il sera apparent à celui qui a des compétences ordinaires dans la technique que l'adresse de la table SSDT peut pointer vers une ROM ou toute autre zone de mémoire 15 dans le système. Un autre avantage des noms d'espace dynamiques est que certains composants peuvent ne plus fonctionner pendant un lancement. Il n'est pas nécessaire que tous les dispositifs d'un système soient présents ou 20 fonctionnels de manière à opérer un lancement avec succès. Dans des systèmes de la technique ancienne, lorsqu'un dispositif ne fonctionne plus pendant un lancement, le lancement tout entier échoue souvent. Pour WindowsTM, ceci peut résulter en ce qui est connu 25 comme " l'écran bleu de la mort " ou l'échec du système. En utilisant une table SSDT dynamique pour définir des dispositifs qui sont optionnels, le système peut déterminer si ces dispositifs optionnels particuliers sont présents et fonctionnels à l'époque 30 du lancement. Dans la négative, ils ne sont pas chargés dans l'espace des noms. Par conséquent, le système d'exploitation ne les cherchera pas à l'époque du lancement. Les figures 5A et 5B montrent des exemples de 35 configurations matérielles pour système-1 et système-2 o les deux systèmes peuvent utiliser le même microprogramme en utilisant le présent procédé. En nous reportant à la figure 5A, nous montrons un adaptateur de bus du système (SBA) 501 ayant deux adaptateurs de 5 bus local (LBA), LBA1 503 et LBA2 505. LBA1 possède quatre fentes de connexion: Si, S2, S3 et S4 (507, 509, 511 et 513). LBA2 ne possède qu'une seule fente de connexion Si, 515. En nous reportant à la figure 5B, nous montrons un SBA 521 ayant trois LBA: LBA1, LBA2 10 et LBA4 (523, 525 et 527). LBA1 possède deux fentes de connexion: Si et S2 (529 et 531) ; LBA2 possède une fente de connexion Si, 533; et LBA4 possède trois fentes de connexion: Si 535, S2 537 et S3 539. Une table DSDT simplifiée utilisée pour 15 représenter l'espace des noms de ces systèmes pourrait ressembler à la figure 6A. Une table SSDT utilisée pour décrire le reste des composants dans le système-1 pourrait ressembler à la figure 6B. Une table SSDT utilisée pour décrire le reste des composants dans le 20 système-2 pourrait ressembler à la figure 6C. Il sera apparent à celui qui a des compétences ordinaires dans la technique que les deux systèmes ont un SBA avec deux adaptateurs de bus local, le premier LBA ayant au moins deux fentes de connexion, et le deuxième LBA ayant une 25 fente de connexion. Parce que cette configuration est le système de base dans cet exemple, la table DSDT n'a besoin de définir que ces composants. Tous les autres composants sont décrits dans des tables SSDT. Par exemple, pour système-1, deux fentes de 30 connexion additionnelles de LBA1 doivent être définies par-dessus la configuration de la ligne de base. Pour système-2, un LBA supplémentaire, LBA4, doit être défini avec trois fentes de connexion: Si, S2 et S3. Par conséquent, pour le même microprogramme, seule la 35 table SSDT chargée doit changer de manière à accommoder système-i et sy'stème-2. Il sera apparent que lorsqu'un microprogramme et son langage ASL associé est développé pour être utilisé sur plusieurs plateformes avec plusieurs configurations, une pléthore de configurations des composants sont possibles. Certaines plateformes peuvent avoir quatre LBA avec chacune trois fentes de connexion, et certaines peuvent avoir cinq LBA avec chacune une à quatre fentes de connexion PCI, etc. Par 10 conséquent, le champ version est utilisé pour distinguer les configurations individuelles. Un seul genre de table SSDT est défini pour la table FIT, et sur combinaison de la table DSDT aux nombreuses tables SSDT, la version de l'entrée est utilisée pour 15 distinguer parmi les configurations. Par exemple, le champ version est long de 16 bits. Dans un mode de réalisation donné à titre d'exemple, les 16 bits sont divisés en deux octets de 8 bits chacun. Un octet (8 bits) identifie l'adaptateur et l'autre identifie le 20 nombre de fentes de connexion pour cet adaptateur particulier. La table 1 montre comment le champ version pourrait être disposé pour indiquer que la configuration courante vaut pour LBAl avec quatre fentes de connexion. La table utilise une notation 25 binaire. Par conséquent, le numéro du composant est, en binaire, 00000001 et le nombre de fentes est 00000100. Il sera apparent à celui qui a des compétences dans la technique que d'autres répartitions de bits peuvent être utilisées. Par exemple, si on souhaite disposer de 30 plus de fentes de connexion, alors on peut utiliser trois bits pour le numéro du composant et utiliser cinq bits pour définir le nombre de fentes de connexion. Numéro du composant Nombre des fentes Tableau 1. Champ version En nous reportant maintenant à la f igure 7, nous montrons un organigramme illustrant un procédé donné à 5 titre d'exemple pour engendrer l'espace des noms des composants du système en utilisant une table DSDT et au tnoins une entrée d'une table FIT d'une table SSDT. Les composants du système sont identifiés et leurs informations en correspondance, ou définitions, sont 10 stockées dans une ou plusieurs zones de table SSDT, à l'étape 701. Cette information peut être stockée en ROM ou dans toute autre mémoire qui est accessible au microprogramme du système. Pendant le lancement du système, les composants qui ont été lancés avec succès 15 sont identifiés à l'étape 703. Pour les objets de cette description, ces composants sont connus comme des composants " actifs ". Toutes les tables SSDT possibles sont chargées dans la ROM et sont décrites par la table FIT. A l'époque de l'engendrement des tables statiques 20 de l'interface ACPI par le la couche SAL, la couche SAL décide quelles tables SSDT seront chargées pour les composants actifs et place ces informations particulières dans les tables statiques de l'interface ACPI, à l'étape 705. Lorsque les informations relatives aux composants du système sont récupérées pour engendrer les noms d'espace du système, les composants inactifs ou non fonctionnels ne sont pas décrits. Ceci permet au système de se lancer en l'absence d'un ou plusieurs 30 composants non essentiels. Pendant le lancement du système également, l'interpréteur de l'interface ACPI consomme les tables statiques et dynamiques pour créer l'espace des noms valide de l'interface ACPI, à l'étape 707, en combinant les tables statiques et dynamiques (une table DSDT et des tables SSDT) . Lorsque l'espace des noms a été engendré complètement par l'interpréteur de l'interface ACPI, le contrôle est transféré au 5 système d'exploitation et le système est en marche, en cours d'exécution, à l'étape 709. Le système d'exploitation utilise alors l'espace des noms engendré pour interagir avec les composants du système. Ayant décrit des modes de réalisation 10 préférentiels d'un nouveau procédé pour utiliser une table d'interface microprogrammée pour charger des tables SSDT d'une interface ACPI, (qui sont destinés à être des illustrations et non pas des limitations), on notera que des modifications et des variations peuvent 15 être effectuées par des personnes compétentes dans la technique à la lumière des enseignements précédents. Il faut par conséquent comprendre que des modifications peuvent être faites dans les modes de réalisation particuliers de l'invention divulguée, lesquelles sont 20 dans la portée et l'esprit de l'invention telle qu'elle est définie par les revendications jointes. REVENDICATIONS

1. Microprogramme pour plusieurs plateformes et plusieurs systèmes d'exploitation pour des processeurs utilisant un jeu d'instructions IA-64, comprenant: un microprogramme de système pour lancer un 5 système informatique, le microprogramme du système ayant un premier bloc de mémoire codé avec des instructions de lancement, et ayant un deuxième bloc de mémoire pour stocker des données (100) ; le deuxième bloc de mémoire étant accessible 10 pendant le lancement du système, le deuxième bloc de mémoire étant peuplé d'informations en correspondance à des composants du système informatique (501, 503,....

515) i une table d'interface microprogrammée (FIT) (109) 15 résidant dans le deuxième bloc de mémoire, la table FIT comprenant des entrées ayant un champ d'adresse (111), un champ de taille (113) et un champ de genre (117) et dans lequel le champ d'adresse (111) d'une entrée (109) de table FIT pointe vers un emplacement de la mémoire 20 en correspondance à des données pour le genre de l'entrée; et au moins une entrée de table FIT dans la table FIT (109) identifiant une table de description secondaire du système (SSDT) (105, 300), dans lequel la table SSDT 25 comprend des informations décrivant au moins un composant du système (501, 503, ..., 515), et dans lequel une table SSDT est identifiée par un genre unique de table FIT et un sous-genre utilisant le champ version d'une table FIT (119 et tableau 1) , l'entrée de table 30 FIT étant récupérée au moment du lancement pour décrire une espace de noms (400) pour des composants actifs du système.

2. Microprogramme tel que revendiqué dans la revendication 1, dans lequel l'entrée de table FIT comprend en outre une somme de contrôle (115) et une information de version (119).

3. Microprogramme tel que revendiqué dans la revendication 1, dans lequel l'information de table SSDT (300) est combinée à des informations issues d'une 10 table de descripteur du système différencié (DSDT) (200), dans lequel l'information de table DSDT réside en mémoire dans le deuxième bloc de mémoire.

4. Microprogramme tel que revendiqué dans la 15 revendication 3, dans lequel l'information de table SSDT (300) réside dans un troisième bloc de mémoire, dans lequel le troisième bloc de mémoire réside à l'extérieur du microprogramme.

5. Microprogramme tel que revendiqué dans la revendication 1, dans lequel

l'information de table SSDT (300) est combinée aux informations issues de la table de descripteur du système différencié (DSDT) (200), l'information de table DSDT et l'information de 25 table SSDT résidant dans un troisième bloc de mémoire, le troisième bloc de la mémoire résidant à l'extérieur du microprogramme.

6. Procédé pour récupérer des données de table SSDT 30 (105, 300) depuis une table FIT (109) au moment du lancement d'un système pour engendrer un espace de noms (400) pour les composants actifs du système (501, 503, 515), comprenant les étapes consistant à : pour chaque composant du système, stocker les 35 informations du composant du système en correspondance dans un emplacement de la mémoire pour stocker une table de description secondaire du système (SSDT) (701) ; déterminer une configuration de système pour des 5 composants actifs dans un système informatique (703), la détermination se produisant au moment du lancement du système; charger une table d'interface microprogrammée (FIT) (109) avec des entrées de table SSDT (705), 10 chaque entrée de table SSDT pointant vers un emplacement de la mémoire stockant des informations de table SSDT en correspondance, les entrées chargées correspondant à des composants du système, une entrée de table FIT étant identifiée comme une entrée de table 15 SSDT par un champ genre, et l'entrée de table SSDT ayant un sous-genre identifié dans un champ version d'une entrée de table FIT; et initialiser l'espace des noms des composants du système avec la configuration du système déterminée 20 pour les composants actifs du système (707).

7. Procédé tel que revendiqué dans la revendication 6, comprenant en outre l'étape consistant à transférer le contrôle depuis le microprogramme du système vers le 25 système d'exploitation sélectionné (709), le système d'exploitation consommant l'espace des noms des composants du système pour définir des interactions des composants du système.

8. Procédé tel que revendiqué dans la revendication 6, dans lequel la table d'interface microprogrammée (FIT) réside dans un premier bloc de mémoire, et dans lequel la table FIT comprend des entrées ayant une adresse (111), une taille (113) et un genre (117), et 35 dans lequel l'adresse d'une entrée de table FIT pointe vers un emplacement de la mémoire en correspondance à des données de genre de l'entrée.

9. Procédé tel que décrit dans la revendication 8, 5 dans lequel une entrée de table FIT pointe vers un emplacement de la mémoire externe au premier bloc de mémoire.

10. Procédé tel que décrit dans la revendication 6, 10 dans lequel l'étape consistant à initialiser l'espace des noms des composants du système (400) comprend en outre une étape consistant à combiner des informations de table SSDT (300) à des informations issues d'une table de descripteur du système différencié (DSDT) 15 (200).