Pourquoi mon transfert DMA ne se fait pas ? [Programmation d'un OS] - C++ - Programmation
Marsh Posté le 13-12-2002 à 21:16:09
up please...
Marsh Posté le 13-12-2002 à 21:29:00
donc y'a personne qui sait ici !?
Marsh Posté le 14-12-2002 à 01:18:22
J'ai souvenir d'une très vielle limitation du DMA ( à l'époque ou je me suis codé mes drivers de carte SoundBlaster sur un 486 sous DOS ). En gros, la bande mémoire sur lequel le DMA agit devait se trouver sur une seule page mémoire. Je n'ai aucune idée si ce genre de limitation agit encore.
Sinon, quand on touche à des choses si bas niveau, c'est normal qu'il y ait des difficultées. Regarde le code source d'un noyau Linux ou BSD si tu en as le courage. Ca doit pouvoir t'aider quand même.
Marsh Posté le 14-12-2002 à 02:49:02
Ben, heuh... je suis comme largué sur ce coup-là.
Tu essayes de remonter le niveau du forum après la vague des 'exercice, comprends po' ?
Peut-être que tout ce code gagnerait à utiliser des énumérations et un peu d'objet.
Just un truc qui me chiffone:
Code :
|
C'est symbolique ?
Parce que ça ne peut pas avoir d'effet...
Marsh Posté le 14-12-2002 à 07:20:47
Kristoph a écrit : J'ai souvenir d'une très vielle limitation du DMA ( à l'époque ou je me suis codé mes drivers de carte SoundBlaster sur un 486 sous DOS ). En gros, la bande mémoire sur lequel le DMA agit devait se trouver sur une seule page mémoire. Je n'ai aucune idée si ce genre de limitation agit encore. |
Effectivement, les transferts DMA doivent se faire dans le 1er Mo de la RAM, et c'est toujours d'actualité !!!! Mais ça n'est pas un problème vu que je l'ai mis en 0x8000... Ou alors, je me suis planté qq part. En fait, une vois que tout s'est bien passé, le lecteur de disquettes doit m'envoyer l'IRQ6. Apparemment, à partir d'un débogage avec bochs, la commande de lecture est bien envoyée au floppy, mais le dma ne semble pas avoir reçu de données, ce qui me laisse supposer que si le transfert des données n'a pas pu se faire, le floppy ne renvoie pas l'IRQ. Tu as encore tes drivers pour ton 486 sur toi ? Sinon, je mate les srcs de minix, linux 0.9, et divers OS, et je ne vois rien ki chie... Si qqn veut les srcs complètes de l'OS pour voir d'un peu plus prêt, je suis prêt à lui envoyer...
Merci
Marsh Posté le 14-12-2002 à 07:26:03
Musaran a écrit : Ben, heuh... je suis comme largué sur ce coup-là.
|
bah il faut bien remonter le niveau... Je voyais ke le forum courait à sa perte
Sinon cette fonction a un effet : j'indique au controleur DMA ce qu'il doit faire, et ça se fait par une succession d'écritures sur les ports du contrôleur. Je lui indique si il doit lire ou écrire, sur quel canal il doit travailler, quel endroit en mémoire il doit utiliser, ... Ce code me semble correct, car je l'ai trouvé sur des cours : http://www.nondot.org/sabre/os/articles
bon je v en cours... Ad'taleur
Marsh Posté le 14-12-2002 à 11:18:12
Code :
|
C'est cette boucle qui bloque ? Tu devrais absolument definir done comme etant un volatile. J'ai eu exactement le meme probleme à l'époque, sauf que pour moi ça ne marchais pas en mode optimise. En mode normal, le compilo ne mettait pas done dans un registre et donc il devait lire sa valeur à chaque fois de la mémoire => bon comportement.
Il est possible qu'avec un compilateur moderne, meme sans optimisations particulieres le compilateur decide de mettre done dans un registre
Marsh Posté le 14-12-2002 à 14:05:58
Merci, je vais tester ça de ce pas.
Sinon, euh... En fait apparemment, je ne reçois pas l'irq6. J'ai créé un irq handler, et j'ai mis un print dedans pour que ça m'affiche un texte quand il reçoit l'IRQ, puis il met done à 1. Et justement, le problème c'est qu'il ne m'affiche pas le texte de l'IRQ 6 !!!
Marsh Posté le 14-12-2002 à 14:18:57
D'abord, est tu sur que printf peut etre utilise à partir d'une interrupt ?
Sinon, je ne vois pas le code qui indique au DMA que c'est l'IRQ 6 qu'il doit prevenir à la fin du transfert.
Marsh Posté le 14-12-2002 à 16:13:02
Kristoph a écrit : D'abord, est tu sur que printf peut etre utilise à partir d'une interrupt ? |
c le DMA ki renvoie l'IRQ 6 !? je pensais ke ct le floppy, quand il avait fini de tout faire.....
Marsh Posté le 14-12-2002 à 18:52:50
En fait, je n'en ai aucune idée. D'apres ton document c'est le floppy qui le fait, mais dans le cas de copie mémoire à mémoire ca doit etre le DMA.
Enfin, si c'est vraiment le floppy qui lance l'interruption, il faut que regarde de ce cote du code et pas de celui du DMA
Marsh Posté le 15-12-2002 à 01:41:06
tout à fait d'accord pour le volatile.
je me souviens avec le watcom c ou je mixais de l'asm et du C, avec une varible globale dans le C, modifié dans l'ASM, le compilateur me tégais des boucles car il supposais que la variable restait dans son état initialisé...
Marsh Posté le 15-12-2002 à 04:17:45
robotniktareum a écrit : bah il faut bien remonter le niveau... Je voyais ke le forum courait à sa perte |
Y'a pas photo, ca change des 'le prog quitte trop vite' et autres 'tableau variable'.
En fait, c'est ça exactement qui me chiffone:
Code :
|
keskecé ?
(je connais le principe de CLear/SeT Interrupt)
Si c'est des noms de type ou d'objets, ça ne fait strictement rien.
Ça pourrait être des macros, mais on les mets en majuscules d'habitude.
Et si c'est une extension de langage, c'est maladroit.
Juste par curiosité, ça m'étonnerait beaucoup que ce soit l'origine du problème !
Peut-être que les newsgroup sauraient mieux te répondre...
Marsh Posté le 15-12-2002 à 11:09:23
robotniktareum a écrit : bah il faut bien remonter le niveau... Je voyais ke le forum courait à sa perte |
beurk t as cours le samedi now !!!
bon sinon bonne continuation !!!
Marsh Posté le 15-12-2002 à 11:30:01
Musaran a écrit : Y'a pas photo, ca change des 'le prog quitte trop vite' et autres 'tableau variable'.
|
c des instructions asm pour masquer ou pas les interruptions coté cpu.
Marsh Posté le 15-12-2002 à 12:26:19
bjone a écrit : |
Les bouquins intel me disent :
CLI - Clear Interrupt Flag
OPCode : 0xFA
Interrupts disabled when interrupt flag cleared.
STI - Set Interrupt Flag
OPCode : 0xFB
external, maskable interrupts enabled at the end of the next instruction
The IF flag and IF Flag and the STI and CLI instructions have no affect an the generation of the execptions and NMI interrupts.
EDIT : bien entendu, j'ai déclaré ceci :
#ifndef cli
#define cli asm("cli":: )
#endif
#ifndef sti
#define sti asm("sti":: )
#endif
EDIT2 : 'font chier ces smileys
Marsh Posté le 15-12-2002 à 12:33:16
asphro a écrit : |
putain m'en parle pas... En plus pour des cours d'adélia de merde qu'on pige même pas ce kon veut nous faire faire et arrivés en TP on nous dit : "bon bah faîtes pas ça marche pas" ou bien encore "n'ouvrez pas tous l'as/400 en même temps, sinon ça va planter ace ke il est vieux", merci... Enfin, encore 2 fois à supporter ça, après, c'est C++
Marsh Posté le 15-12-2002 à 13:44:57
robotniktareum a écrit : putain m'en parle pas... En plus pour des cours d'adélia de merde qu'on pige même pas ce kon veut nous faire faire et arrivés en TP on nous dit : "bon bah faîtes pas ça marche pas" ou bien encore "n'ouvrez pas tous l'as/400 en même temps, sinon ça va planter ace ke il est vieux", merci... Enfin, encore 2 fois à supporter ça, après, c'est C++ |
mouahahha ayez l as400 devient poussif !!
c la fin
Marsh Posté le 15-12-2002 à 16:30:40
J'ai une très bonne nouvelle : j'arrive à le faire marcher.
Pour ceux que ça intéresse, j'ai mis les srcs à disposition :
http://dszczyt.free.fr/dossier/BoOSt.tar.gz
Merci @ tous...
Marsh Posté le 15-12-2002 à 19:42:43
Super question à 2 balles (même pas)
Ça sert à quoi tout ça ?
Merci
(oui, c'était court comme intervention)
Marsh Posté le 15-12-2002 à 19:44:27
ça sert à transfert des données de/vers le lecteur de disquette.
Marsh Posté le 13-12-2002 à 15:34:15
Salut...
Je réalise un système d'exploitation en mode protégé, et j'ai jarté toutes les fonctions du BIOS. Je dois donc reprogrammer les fonctions de lecture sur le lecteur de disquette. J'ai les commandes à envoyer au lecteur de disquettes, et je le fais avec le DMA. J'ai tout programmé, et ça ne marche pas, je ne sais pas pk...
Je vous montre les sources, si vous pouviez m'éclaircir sur le sujet...
Merci
Message édité par robotniktareum le 13-12-2002 à 21:15:45
---------------
si t déçu d'être dessous, tu iras dessus kom ça tu seras plus déçu ni dessous... Si tu piges pas c ke t saoul, c sûr...