Discussion :

[tiloup367]

Bonjour j'aimerais la réponse à certaines questions que je me poses. Je sais que mes questions pourraient en irrités quelqu'uns, en ce sens, svp soyez courtois face a mon manque de cultures! ;p Bref, voici mes questions :
Pour un intel 64bit
1. Quel est le moyen de connaitre les informations sur les peripheriques et "features" de mon motherboard? CPUID? Dautres methodes?
2. Y a t il moyen de communiquer avec les peripheriques disponibles? (Mode reel, protegee?)
3. Dans le cas de la conception d'un micronoyau en C, quel serait la méthode appropriée pour acceder aux peripheriques disponibles?
Merci de votre aide dédié a ma comprehesion de ces connaissances :p

[Obsidian]

Bonjour,

Même si les processeurs Intel x86, spécialement en 64 bits, sont utilisés à 99 % dans les PC, il n'en reste pas moins qu'un micro-processeur est en soi un produit distinct et en principe indépendant de l'environnement dans lequel il tourne.

Ceci veut dire qu'en assembleur, tu vas avoir à ta disposition d'instructions dédiées pour obtenir des informations sur le micro-processeur lui-même (par exemple CPUID, ainsi que les flags, les registres CR0, CR1, etc.) et pour le manipuler, mais pas pour interroger directement ce qui l'entoure sur un point précis.

À dire vrai, l'exploitation entière de ton ordinateur va se faire en lisant certaines adresses en mémoire et en écrivant à d'autres. Y compris la gestion des périphériques. Les micro-processeurs Intel font toutefois un distingo entre l'adressage normal de la mémoire et l'exploitation des périphériques, lequels s'adressent de manière indirecte avec « IN » et « OUT » mais au final, électroniquement, les accès se font à travers le même bus modulo une ligne spéciale indiquant quel genre de transfert on souhaite effectuer.

Concrètement, tu peux communiquer avec tous tes périphériques en assembleur, à commencer par les périphériques « historiques », principalement émulés aujourd'hui par le chipset, et qui ont un emplacement fixe dans le plan d'adressage. Cela concerne notamment le clavier, le port parallèle, les ports série, la gestion du port PS/2 également, mais aussi le timer, qui servait entre autre à générer des tonalités vers le buzzer du PC avant qu'il commence à être doté d'une carte son.

Pour le reste, il y a d'un côté des technologies comme http://en.wikipedia.org/wiki/Desktop...ment_Interface ou SMBus, basées qui permettent justement de recenser les différents composants sur une même carte.

Pour les autres périphériques connectés au bus PCI, soit branchés sur les slots, soit directement intégrés à la carte-mère mais utilisant PCI quand même, ceux-ci n'ont plus d'adresse fixe assignée par défaut comme du temps du bus ISA. Il faut procéder à une énumération des périphériques du bus PCI (comme avec l'USB) puis mapper celui-ci qui nous intéresse en mémoire ou sur les ports I/O et, de là, l'exploiter à notre convenance. Cette énumération comme le reste de la gestion du bus PCI se fait à travers des ports I/O fixes s'étendant de 0xCF8 à 0xCFF.

Enfin, dans tous les cas, si tu pars de zéro, soit tu utilises les interruptions BIOS déjà à disposition pour gérer ces périphériques, soit tu les pilotes directement (spécialement si tu es en mode protégé et que tu ne peux utiliser le BIOS). Mais dans ce cas, tu pourras utiliser indifféremment les anciens périphériques standard sur toutes les machines (notamment la carte graphique jusqu'aux modes VGA, mais pas plus haut).

Par contre, pour les autres, il te faudra écrire un programme spécial pour chaque type de périphérique. C'est le cas notamment si tu veux utiliser ta carte réseau, par exemple. En fait, il n'y a pas de secret : si tu écris un mini-OS, il faudra que tu écrives les pilotes qui l'accompagnent, ce qui n'est pas une mince affaire.

J'ai passé le mois dernier à faire exactement la même chose : un nano-OS qui démarre en DHCP/PXE via le réseau sur une machine sans disque et qui, de là, met tout en place jusqu'à proposer une mini-console, soit capable de télécharger le reste du système via ma carte réseau, puis accède au bus USB via le bus PCI et qui, en dernier lieu, essaie d'atteindre mon système audio USB (5.1 indépendant avec un caisson de basse). Je n'ai pas encore fait la partie réseau, ni l'USB, ni l'audio. Le reste fonctionne.

Je te conseille de visiter http://wiki.osdev.org/ . C'est un wiki consacré à cette activité en particulier et qui, donc, réunit sur un même portail les ressources dont tu as besoin.

[tiloup367]

Mon dieu merci beaucoup obsidian, ça cest de linformation riche en detail! Tu mas aider a confirmer ce que je pensais, car jai deja telecharger et presque lu au complet le manuel pour developpeur Intel, mais comme le document est en anglais, certains termes et expressions sont plus dures a comprendre. Si je recapitule :
CPUID et flags : infos processeur et feature
mini-nano-micro-OS: soit interruption bios mais comme sa jcrois que tu (developpeur) reste limité a utiliser un mode precis du processeur (max 2Mo adressage). Soit par ecriture de pilote et mappage en memoire ou sur les I/O. Tres bien, mais toute ces informations comme ecriture lecture initialisation dun peripherique (ex carte reseau) a quel endroit ce trouve telle afin de mapper et decrire des methodes avec les bonnes commandes?

[Obsidian]

Si je recapitule :CPUID et flags : infos processeur et feature

C'est un poil plus subtil. Le 8086 est apparu en 1978, il y a trente-quatre ans, donc. Et toute la gamme x86 jusqu'aux Core actuels est une évolution progressive à partir de ce modèle, sachant qu'Intel en a également produit d'autres et qu'il est loin d'être le seul fabricant de micro-processeurs.

Le registre « flags » est à la base quelque chose qui existe sur tous les micro-processeurs. On l'appelait « CC » (Code Condition) sur les 68xx de Motorola, par exemple. C'est lui qui est chargé de refléter l'état du résultat de la dernière opération arithmétique et logique et il est nécessaire, entre autres, pour effectuer des sauts conditionnels.

Intel, en faisant évoluer ses processeurs tout en conservant une compatibilité ascendante jusqu'au premier jour et en profitant d'une technologie progressante et qui permettait à terme de faire facilement ce qui aurait jadis posé des problèmes technologiques, a fini par ajouter des informations dans ces fameux flags (ce qui n'était pas très propre) puis par ajouter des registres dédiés.

« CPUID », en revanche, n'est apparu qu'avec le Pentium et les derniers 486, soit quinze ans après la naissance du premier modèle. C'est une instruction qui est propre aux Intel, même si d'autres fabricants peuvent proposer quelque chose de similaire, c'est loin d'être une généralité. Ça veut dire aussi que tu peux l'utiliser dès que tu sais qu'elle est disponible, mais que cela plantera si tu l'appelles sur un processeur plus ancien. C'est pourquoi Intel consacre un bit des flags à l'indication de disponibilité de cette instruction.

C'est aussi pour cela que ce n'est pas une très bonne idée de courir tous les lièvres à la fois : les processeurs pour PC de dernière génération sont trop sophistiqués. C'est sympa à l'usage, mais c'est compliqué pour rien et cela donne une vision biaisée de l'assembleur si on commence directement par les plus gros et qu'on ne voit que cela.

Ensuite, par définition, quand tu écris un nano-OS, c'est toi qui doit faire tout le travail. Ça demande donc une certaine expertise. C'est pas forcément difficile avec la doc, mais ce n'est pas non plus une tâche de débutant. Et surtout : c'est long !

mini-nano-micro-OS: soit interruption bios mais comme sa jcrois que tu (developpeur) reste limité a utiliser un mode precis du processeur (max 2Mo adressage). Soit par ecriture de pilote et mappage en memoire ou sur les I/O. Tres bien, mais toute ces informations comme ecriture lecture initialisation dun peripherique (ex carte reseau) a quel endroit ce trouve telle afin de mapper et decrire des methodes avec les bonnes commandes?

C'est le problème ! Et c'est ce que je t'explique plus haut. Il y a d'un côté des choses qui sont « historiques » à l'IBM PC et qui, donc, sont documentées et mappées toujours au même endroit, il y a quelques nouveautés qui sont établies par différents consortiums mais il est très difficile de trouver aujourd'hui une source unique et officielle de documentations. Il y a des technologies qui émergent, qui prennent ou pas, et certains grands groupes décident de parier sur une technologie et de l'imposer à leur partenaires s'ils veulent obtenir leur « certification ». Ce fut le cas par exemple avec SMBios, que Microsoft a décidé d'exiger. Les fabricants de carte-mère et les développeurs de BIOS qui voulaient pouvoir apposer le logo Windows sur leur boîte devaient donc intégrer cette technologie, parmi d'autres.

Dans les années 1990, Michael Tischer avait sorti la « Bible PC », un ouvrage gros comme un dictionnaire et qui a été réédité six ou sept fois, jusqu'à Windows 95. Après, je n'ai rien vu de tel. Connaître les technologies populaires tient donc de la veille technologique. Mais surtout, ce qui fait qu'un PC reste un PC est que chacune d'elles est accessible via la précédente. Par exemple, les périphériques capables de s'annoncer via DMI le font à travers une interface, laquelle est elle-même et en principe mappée sur le bus PCI. Tous les autres périphériques « normaux », qu'ils soient intégrées à ta carte-mère ou sur un slot, communiquent aujourd'hui à travers le bus PCI (les bus ISA, et temporairement VLB, ont complètement disparu). Le bus PCI lui-même a beaucoup évolué : tout le monde travaille aujourd'hui avec du PCI-Express, mais c'est le même principe et surtout, c'est compatible.

C'est qui nous amène à ta question : pour utiliser correctement un périphérique une fois dûment mappé via le bus PCI. Il faut le « piloter » et donc écrire son pilote. Pour cela, il te faut les « spécifications » du périphérique concerné et cela, seul son constructeur peut te les fournir (initialement). S'il est conciliant, tu les trouveras sur son site, mais ça veut quand même dire qu'il faut écrire un pilote particulier par périphérique ou, au moins, par famille de périphérique. C'est pour cela que tu installes toujours les « drivers » d'un nouvel équipement sous Windows. Tout gérer représente donc une quantité considérable de travail.

Or, et c'est bien là le problème, sous Windows, ce n'est pas Microsoft qui écrit la totalité des pilotes mais les constructeurs eux-mêmes, qui le fournissent s'ils veulent vendre leur produit.

Sous Linux, par exemple, à quelques exceptions près (les pilotes nVidia par exemple) on n'installe pratiquement jamais les pilotes car c'est la communauté qui les développe, et gratuitement en plus ! Intégrés au noyau, ils sont automatiquement détectés et chargés. Et ça semble fonctionner tout seul. Mais c'est aussi pour cela que les produits trop récents ne sont pas immédiatement fonctionnels, sauf quand ils respectent à la base une norme déjà existante.

D'autre part, beaucoup de constructeurs, Canon par exemple, se font fortement prier pour ouvrir leurs spécifications. Gagner gratuitement des parts de marché en laissant la communauté travailler pour eux ne semble pas les séduire et on a eu beaucoup de déboire avec des produits parfois aussi simples qu'une imprimante à jet d'encre. Dans ce cas, il faut faire du reverse engineering dans les pays où c'est autorisé pour pouvoir simplement utiliser l'appareil qu'on a légalement acheté. En France, cette pratique est autorisée sous certaines conditions.

Aujourd'hui, les bus PCI et USB intègrent un système d'identifiants fabricant/produit (vendor:device) qui te permet d'identifier à coup sûr un produit particulier et même sa sous-version. Il est donc très facile de le détecter et de charger le bon pilote en conséquence. Par contre, à l'époque du bus ISA, chaque constructeur s'allouait plus ou moins arbitrairement un bout de la plage adressable. Par exemple, les cartes Sound Blaster étaient typiquement en 0x220 et suivants, si on ne l'avait pas déplacée ailleurs à l'aide de cavaliers jumpers. Du coup, pour sonder sa présence, il fallait faire du polling prudemment à cette adresse et vérifier si les résultats étaient cohérents.

Tu trouveras sur OSDev la plupart des spécifications des périphériques historiques que l'on trouve dans un PC. Pour le reste, la prochaine étape consistera à initialiser correctement le bus PCI.

[tiloup367]

Merci encore et toujours obsidian! jespere tu as deja penser etre consultant :p Ça semble donc etre une tache ardue a cause du temps consacrer a lapprentissage des specifications, du temps et lagorithmie! Je sais maintenant vers quel voie aller

[Obsidian]

Ça semble donc etre une tache ardue a cause du temps consacrer a lapprentissage des specifications, du temps et lagorithmie! Je sais maintenant vers quel voie aller

Attention : il ne s'agissait pas de te dissuader mais, au contraire, de t'avertir que c'est très long pour que tu ne te retrouves pas découragé à la première ligne de code. :-)

Avec quel système d'exploitation travailles-tu ?

Si tu n'as pas encore essayé Linux, je te suggère d'aller récupérer et graver l'ISO d'une distribution en Live CD telle que Knoppix. Ceci te permettra de démarrer sur le CD et d'obtenir un système utilisable sans avoir à installer quoi que ce soit sur ta machine cible, ce qui est assez remarquable ! Si tu as une clé USB inutilisée, tu peux également la consacrer à cela.

Une fois que tu as démarré, essaie les commandes « dmidecode », « lspci » et « lsusb » qui, à elles trois, te donneront une liste déjà très exhaustive de ce que tu trouves dans ta machine.

De là, tu pourras mettre tranquillement le pied à l'étrier si l'activité t'intéresse.