ASM x86 en mode réel :Comment se déroulent les bases ?

Question

Je suis en train de lire le boot.s fichier dans les sources du tout premier noyau Linux (en supposant que la version 0.01 soit effectivement la première version publique).

Je connais C et ASM, ce dernier considérablement moins que le premier.Malgré cela, il me semble être capable de comprendre et de saisir essentiellement le code des fichiers sources.

Ce fichier me laisse cependant confus.Je réalise maintenant que c'est parce que c'est en mode réel et non en mode protégé.Inutile de dire que je n'ai jamais vu de code ASM écrit en mode réel auparavant.Le mode protégé était le mode de facto sur lequel les systèmes d'exploitation x86 fonctionnaient avant même ma naissance, il fallait donc s'y attendre.

Voici une routine que je veux mieux comprendre :

/*
 * This procedure turns off the floppy drive motor, so
 * that we enter the kernel in a known state, and
 * don't have to worry about it later.
 */
kill_motor:
    push dx
    mov dx,#0x3f2
    mov al,#0
    outb
    pop dx
    ret

Levant les yeux outb, je trouve qu'il est utilisé pour transmettre des octets aux ports de l'ordinateur.Je vais tenter de deviner, sur la base de la documentation C, que ce scénario transmet l'octet « arrêt du moteur » comme premier argument et le numéro de port du lecteur de disquette comme second.

Cette interface est-elle fournie par le BIOS ?Ou directement par le lecteur de disquette ?Je suppose que le BIOS dispose de « pilotes » économes pour un fonctionnement très basique de tous les périphériques fondamentaux.

Voici où je suis perplexe :il semble que des chiffres comme #0x3f2 sont sortis de nulle part.Ce sont clairement des numéros de port matériel ou quelque chose du genre.Ce dossier est parsemé de tels chiffres, sans aucune explication à quoi ils font référence.Où puis-je trouver une référence complète montrant tous les ports matériels et numéros de contrôle qu'ils peuvent recevoir en mode réel ?En outre, il semble que le fichier déplace le noyau en mémoire tout au long des processus de démarrage, avec des adresses mémoire codées en dur.Où puis-je trouver un guide sur les plages d'adresses mémoire disponibles pour l'écriture en mode réel ?

J'ai également lu un commentaire de Linus sur la reprogrammation des interruptions pour éviter une collision entre le BIOS et les interruptions matérielles internes.Je ne vais pas mentir, ça m'est passé par-dessus la tête.

Une aide serait formidable ;Google semble rare sur le sujet, au cas où vous vous poseriez la question.

Answer 1

Tout d’abord, bienvenue dans le monde de l’assembleur en mode réel !Vous avez probablement déjà réalisé que l'assembleur réel est à peu près le même entre le mode réel et le mode protégé - les principales différences étant la taille des opérandes et la disposition/gestion de la mémoire.

Il existe des ressources pour le mode réel sur Internet – il vous suffit de les traquer !Une ressource très importante est L'interruption de Ralf Brown Liste (connue sous le nom de RBIL) - elle fournit de nombreuses informations sur les différentes interruptions utilisées dans la programmation en mode réel.Un autre est celui de BiosCentral. Carte mémoire CMOS qui décrit les informations que le BIOS stocke (ou devrait stocker) dans différents emplacements de mémoire.

Pour répondre à certaines de vos questions sur le code Linux que vous avez posté :outb est l'instruction pour écrire l'octet dans al mettre en communication dx - 0x3f2 est le port du contrôleur de disquette. Wikipédia peut vous aider avec la liste de base des numéros de port x86, mais vous devrez fouiller pour obtenir des informations détaillées sur le format réel du al morceaux.

Quelles plages d'adresses mémoire sont disponibles pour écrire en mode réel ?

Vous devriez faire quelques recherches sur INT 15h, AX=E820h - il renvoie une carte mémoire décrivant quelles zones mémoire peuvent être utilisées et lesquelles sont réservées.Attention cependant :Lorsque vous examinez les interruptions, il est important de voir à quel point elles sont « nouvelles », car les anciens BIOS peuvent ne pas les prendre en charge.

...interruptions de reprogrammation pour éviter une collision entre le BIOS et le matériel interne interruptions

De nombreux périphériques matériels disposent d'interruptions programmables (qui sont utilisées pour entretenir le matériel lorsqu'il nécessite une intervention).Généralement, le BIOS règle une affectation initiale lors de ses routines de démarrage, mais il n'est pas rare que le système d'exploitation réorganise les interruptions matérielles à ses propres fins ou pour éviter des incompatibilités connues.

Une dernière remarque : it seems that numbers like #0x3f2 are being pulled out of thin air.La réponse est oui.Une grande partie des sources de démarrage Linux sont horribles (oui, ce n'est que mon opinion) et semblent parsemer des adresses, des numéros de port et d'autres bits apparemment aléatoires sans aucune explication significative.Tenez-vous-en à cela, recherchez d'autres ressources en mode réel et cela finira par avoir du sens.Oh, et si vous rencontrez un référence complète - dites-le à TOUT LE MONDE (car ça n'existe pas actuellement).

Answer 2

Ces adresses ont été gravées dans le marbre il y a 30 ans, lorsqu'IBM a lancé le premier IBM PC.0x3f0 est la première adresse des registres principaux du contrôleur de disquette.Une liste d'adresses est disponible ici.

Une décision inhabituelle de l'équipe de conception d'IBM a été d'assembler la machine à partir de pièces standard disponibles dans le commerce.La plupart des puces provenaient d'Intel, le contrôleur de disquette était une conception NEC.S'assurer involontairement que tout le monde pourrait construire un clone.Ces clones utilisaient les mêmes adresses pour garantir la compatibilité logicielle, transformant ainsi le choix d'IBM en un standard industriel pouvant être codé en dur.