Programmation d'un OS - erreur pdt le test sous bochs - Divers - Programmation
Marsh Posté le 30-10-2002 à 19:06:11
T'as testé en vrai sur ton ordi ?
PS : pourquoi il faut mettre volatile devant asm ?
Marsh Posté le 30-10-2002 à 21:00:08
Euh
Question à 2 balles.
Comment tu fais pour compiler un truc qui doit pouvoir faire booter la machine?
J'ai un vague souvenir qu'il faut mettre l'adresse dans le MBR du début du code à exécuter, c'est ca ou je me plante?
Marsh Posté le 30-10-2002 à 21:15:08
HelloWorld a écrit a écrit : T'as testé en vrai sur ton ordi ? PS : pourquoi il faut mettre volatile devant asm ? |
en vrai sur mon ordi, ça reboote
Pour le volatile, je c pas, il faut le mettre, c tout ce ke je c... Si on peut m'éclairer sur ce sujet d'ailleurs...
Marsh Posté le 30-10-2002 à 21:17:26
zion a écrit a écrit : Euh Question à 2 balles. Comment tu fais pour compiler un truc qui doit pouvoir faire booter la machine? J'ai un vague souvenir qu'il faut mettre l'adresse dans le MBR du début du code à exécuter, c'est ca ou je me plante? |
pour ça, tu vas voir mon site, consacré à l'étude et à la réalisation d'un système d'exploitation :
http://boost.ht.st/indexo.php et tu vas dans la rubrique téléchargement, tu télécharges le fichier boost-0.2.0-20020831-linux.tar.gz, tu mates les sources et le makefile qui compile tout ça... En gros, tu ne dois utiliser aucune fonction de la libc, tu dois donc tout reprogrammer toi-même, et tu dois créer un secteur de boot, à moins que lilo ou grub ne s'en charge...
Marsh Posté le 30-10-2002 à 23:40:52
up ace ke je le vaux bien...
Je tiens à préciser que je suis en mode protégé, là... J'ai déjà réinitialisé la GDT en mode réel, et tout s'est bien passé... Je suppose donc ke le problème vient du mode du processeur
Marsh Posté le 31-10-2002 à 07:56:29
Ben si ca reboot oui c'est ton code.
Au passage, petit conseil pour que ce soit + rapide et + lisible (pour une fois que les 2 sont comptibles) :
change :
(base / 0x10000) & 0xFF;
en
(base >> 16) & 0xFF;
Ensuite, vite fait comme ca avec les souvenirs qu'il me reste, lgdt doit immédiatement être suivie par un jump.
Toi, le lgdt est dans une fonction et est suivi par un ret.
Donc j'inclurais tout le code assembleur dans ta fonction _lgdt, y compris les init sur les registres, tant qu'à faire.
Marsh Posté le 31-10-2002 à 11:13:02
HelloWorld a écrit a écrit : Ben si ca reboot oui c'est ton code. Au passage, petit conseil pour que ce soit + rapide et + lisible (pour une fois que les 2 sont comptibles) : change : (base / 0x10000) & 0xFF; en (base >> 16) & 0xFF; Ensuite, vite fait comme ca avec les souvenirs qu'il me reste, lgdt doit immédiatement être suivie par un jump. Toi, le lgdt est dans une fonction et est suivi par un ret. Donc j'inclurais tout le code assembleur dans ta fonction _lgdt, y compris les init sur les registres, tant qu'à faire. |
J'ai donc suivi tes indications... Voici mon code à présent :
Code :
|
Et là... Toujours la même erreur Je vois pas du tout où est mon pb
Marsh Posté le 31-10-2002 à 16:43:23
Bon je me suis gourré ... c'est après avoir commuté en mp qu'il faut faire le jump,pas apres le changement de gdt.
L'erreur peut aussi venir de donnée incorrectes dans ta gdt.
voici un lien qui m'avais bcp servi
note l'attribut packed pour les structures qui dit au compilo de ne pas ajouter des bytes en plus pour aligner en mémoire. Mais dans ton cas ca m'etonnerais que ca change.
http://inferno.cs.univ-paris8.fr/~ [...] ial06.html
Marsh Posté le 31-10-2002 à 18:08:02
HelloWorld a écrit a écrit : Bon je me suis gourré ... c'est après avoir commuté en mp qu'il faut faire le jump,pas apres le changement de gdt. L'erreur peut aussi venir de donnée incorrectes dans ta gdt. voici un lien qui m'avais bcp servi note l'attribut packed pour les structures qui dit au compilo de ne pas ajouter des bytes en plus pour aligner en mémoire. Mais dans ton cas ca m'etonnerais que ca change. http://inferno.cs.univ-paris8.fr/~ [...] ial06.html |
Mais justement, là je pige pas... J'ai initialisé EXACTEMENT la même GDT avant... Tiens, mate ça, c la même chose, en assembleur, c exécuté avant cette fontion, c'est en nasm.
Code :
|
Tu vois une différence entre les 2 GDT ? La 1è marche nickel, c une certitude, et elle vient de la même source que toi. La 2è, elle marche pas... D'ailleurs, j'ai rajouté les attributs packed, et ça fait pareil...
Marsh Posté le 31-10-2002 à 18:52:07
Citation : cli |
Ou est l'equivalent dans ton code C ?
2 erreurs possibles : tu as mal traduit l'init de ta gdt de asm -> C
Y'a une couille au niveau du code asm dans ton C qui load et switch en pmode
Citation : GDT[num].type = type + (present * 0x8 + DPL * 2 + S)*0x10; |
C'est assez risqué. Test ce que ça donne si je passe autre chose que 1 ou 0 aufx flags ....
Code :
|
et défini des constantes pour que ce siot + lisible :
Code :
|
(valeurs données au pif)
Sinon désolé mais c'est trop loin je peux pas grand chose pour toi.
Mais si ton code asm marche, c'est un problème de transcription asm -> C
Lis avec attention le lien que je t'ai filé.
Marsh Posté le 31-10-2002 à 20:29:14
Vraiment, merci beaucoup pour tes réponses.
Concernant ceci :
Code :
|
il s'agit du passage en mode protégé. Le bit PE du registre cr0 doit être mis à 1 pour le mode protégé. Sinon, on est en mode réel. La seule différence entre le code asm et le code C, c que l'asm est en mode réel, et celui en C est en mode protégé. Est-ce qu'il y a une subtilité en mode protégé que je ne respecte pas quand on veut charger une nouvelle GDT ? Sinon je tiens à savoir où se situe mon erreur...
Merci.
Damien
Marsh Posté le 31-10-2002 à 20:43:13
Citation : La seule différence entre le code asm et le code C, c que l'asm est en mode réel, et celui en C est en mode protégé |
Ah okay je suis à la masse. Je croyais que t'écrivais un loader en C
Mais pourquoi tu réserve pas la taille depuis l'assembleur et tu files l'adresse de la gdt à ton main (ou alors tu décides qu'elle est à une adresse fixe donnée) ?
Depuis ton C tu modifie directement les entrées voulues, sans avoir à recharger la gdt.
P'tête que je dis des conneries ... c'est trop loin là.
Marsh Posté le 31-10-2002 à 21:27:40
oui mé bon... Admettons que j'aie besoin de 8192 segments (taille maximale admise pour les processeurs intel), en assembleur, j'aurais 8192*8 à mettre à 0 !? soit 65536 octets de plus pour le loader... Ca fé pas un peu bcp tout ça !? ça ressemblerait étrangement aux lignes xxxxxxxxxxxxxxxxxxxxx dans le msdos.sys de chez Microsoft... Si t'as un autre moyen, donne-le moi...
Marsh Posté le 31-10-2002 à 23:09:45
Mais non !
A partir du moment où t'as décidé où était la GDT en adresse physique, tu écris directement dedans (tu choisis un endroit ou y'a pas ton loader, ton kernell, le bios, etc ...)
Un petite boucle qui efface tout, tu initialise les premiers descriptor pour lancer le kernell, tu switch en pmode, et voilou.
Marsh Posté le 31-10-2002 à 23:17:14
HelloWorld a écrit a écrit : Mais non ! A partir du moment où t'as décidé où était la GDT en adresse physique, tu écris directement dedans (tu choisis un endroit ou y'a pas ton loader, ton kernell, le bios, etc ...) Un petite boucle qui efface tout, tu initialise les premiers descriptor pour lancer le kernell, tu switch en pmode, et voilou. |
arf... il va falloir copier les octets de gdt: à gdtend: en assembleur !? ouh là... euh... moui... Et tu c pas par hasard où je peux la mettre et comment ?
Marsh Posté le 01-11-2002 à 11:08:25
Bon, j'ai réussi à charger une nouvelle GDT, une fois en mode protégé, et en C... J'ai remplacé tout le fichier par celui-ci :
Code :
|
Voilà, pour ceux que ça intéresse
ciao
Marsh Posté le 30-10-2002 à 17:34:39
Je suis en train de réaliser un système d'exploitation en mode protégé. Quand je le teste à partir de bochs, il me dit :
========================================================================
Event type: PANIC
Device: [CPU0 ]
Message: [CPU0 ] exception(): 3rd exception with no resolution
A PANIC has occurred. Do you want to:
cont - continue execution
alwayscont - continue execution, and don't ask again.
This affects only PANIC events from device [CPU0 ]
die - stop execution now
abort - dump core
debug - continue and return to bochs debugger
Choose one of the actions above: [die]
========================================================================
Bochs is exiting with the following message:
[CPU0 ] exception(): 3rd exception with no resolution
========================================================================
damien@Le-Zigoto:~/boost/BoOSt-0.2.0$
En gros, on dirait un plantage de windows, mais encore pire Dommage Voici le code qui fait planter :
Et en fait, ça plante quand je mets la ligne init_gdt() dans le programme principal du kernel. Qqn pourrait-il m'éclairer sur l'affaire ? Merci...
---------------
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...