Discussion :

[dway]

pour l'openbios : ca a rien avoir avec le bios (merci qd meme dway)

j'ai du confondre avec freebios, essaie ca :

http://belnet.dl.sourceforge.net/sourceforge/freebios/freebios-20010708.tar.gz

[SKZ81]

Toute int. BIOS est interdite en mode P, le BIOS étant concu en 16bits pour le mode réel.

Golem

...en fait windows (et linux aussi j'en suis presque sur) repasse en mode reel lors du changement de mode video pour appeller l'int 10h et ensuite ils repassent en mode pro pour reprendre le cours du prog....

dway.

Ce qui est donc normal. Néanmoins il me parraît TRES vraissemblable que Windows fasse ainsi, autant que Linux se passe totalement du BIOS (je rappelle que Linux marche sur des machines, autres que des PC, où l'INT 0x10 n'existe absolument pas etc...) ce qui ne l'interdit pas de faire appel à l'INT 0x10... Mais les concepteurs de Linux sont autant des bidouilleurs qui aime avoir un controle logiciel total et comprendre comment marchent leur bécanes, l'idée de se passer du BIOS rentre à fond dans la "philosophie" linux (indépendance par rapport au matériel)

[golem]

moi je prefere programmer pour decouvrir un max de chose sur le PC

c'est tout a ton honneur.

Néanmoins il me parraît TRES vraissemblable que Windows fasse ainsi,

pq ?

...en fait windows (et linux aussi j'en suis presque sur) repasse en mode reel lors du changement de mode video pour appeller l'int 10h et ensuite ils repassent en mode pro pour reprendre le cours du prog....

Urgh! Vrai ?

Repasser en mode réel n'est pas sans conséquence !!! C'est vraiment tricky de faire de genre de manip, mais pourquoi pas ?

Je ne vois pas de contre indication à coder les out/in qui vont bien pour les modes basiques VGA reconnus par toute carte compatible VGA. Après tout le CRTC n'est pas un circuit complètement opaque et il existe une foule de docs dessus. Après pour les modes plus évolués (SVGA...) il existe des drivers carte-graphique-dépendants.

J'ai bien vu un appel à l'int 10h dans les sources du boot procces linux juste avant de passer en mode protégé et de manière à pouvoir afficher des messages en mode texte mais jamais après !

Enfin je m'avance surement, faut que je vérifie ...


golem
+++

[dway]

à SKZ81 et colem (et ç tous ceux que cela intéresse bien sur) :

j'suis pas sur d'avoir tout pigé la ... en gros vous me dites que win utilise l'int 10h (en repassant en mode reel,etc...) mais pas linux , c'est ca ?
ban écoutez si vous arrivez à trouver un bout de code qui active un mode video (même un mode vga tout bete style 13h ou 03h) sans l'int 10h je vous tire mon chapeau...que cela vienne de linux ou pas d'ailleurs...

sinon oui repasser en mode reel c'est carrément la m**** !!!


c'est vrai que j'avais trouver les src d'un vieux bios ...qui initialisez le mode 03h je crois .... faut que je cherches ca...

sinon si qq'un connait bien linux et peut dire comment les modes video sont gérés se serait cool...

je cherche aussi comment gérér l'APM (mise en veille etc...) sans int si qq'un à des infos...

[SKZ81]

Ca ne m'etonnerais pas plus que ça...
Il existe très probablement un bout de code du noyau (p'têt codé en ASM, mais en 32 bits surement) qui réimplémente le fonctionnement de l'INT 10... A moins qu'il n'existe des opérations qui ne sont possible qu'en mode réel et qui servent à l'init graphique ?
Ce qui est sûr c'est que Linux n'aime pas le modse réel et fait tout pour s'en passer !

[dway]

Ca ne m'etonnerais pas plus que ça...
Il existe très probablement un bout de code du noyau (p'têt codé en ASM, mais en 32 bits surement) qui réimplémente le fonctionnement de l'INT 10... A moins qu'il n'existe des opérations qui ne sont possible qu'en mode réel et qui servent à l'init graphique ?
Ce qui est sûr c'est que Linux n'aime pas le modse réel et fait tout pour s'en passer !

on est à peu prés d'accord, linux est censé tout reprogrammé mais j'étais quasiment sur qu'il utilisé au moins l'int 10h du bios, je me trompe peut être...si qq'un peut confirmer car je ne domine pas assez le src ded linux pour le dire...mais je vais cherchez ...si qq'un a une url pour les src de linux ...

sinon qqs liens :
ftp://ftp.arnes.si/software/simtelnet/msdos/asmutl/modes.zip
http://www.programmersheaven.com/d/click.aspx?ID=F15869

[dway]

...
- CS:IP==F000:FFF0 soit adresse physique FFFF0h.
...

t'es sur de ca ?! c'est pas plutot F000:0000 ?

[golem]

...
- CS:IP==F000:FFF0 soit adresse physique FFFF0h.
...

t'es sur de ca ?! c'est pas plutot F000:0000 ?

F000:FFF0.

Il y a d'ailleurs un détail qui a été passé sous silence. Il se trouve qu'à l'init, le bus d'adresses vaut en fait FFFFFFF0h, c'est à dire que les 12 bits supérieurs sont fixés à 1 par le processeur afin d'acceder à une éventuelle ROM de boot de 64ko mappée à la partie la plus supérieure de l'espace d'adressage. Le premier jump inter segment (far) fait retomber ces 12 bits à 0 pour donner l'adresse physique FFFF0h.

Ce qui suit est ma libre interprétation.

Dans l'architecture PC, cette feature n'est pas utilisée et le processeur démarre directement a FFFF0h, la logique de décodage ignorant les 12 bits supérieurs. Cela présente sans doute un intéret dans des systèmes embarqués où l'on ne souhaite pas que cette rom soit visible:

- L'idée de placer cette ROM de boot en haut de l'espace d'adressage le rend invisible en mode réel puisque que l'on ne dispose que de 20 bits d'adresse.

- En mode protégé, c'est l'os qui décide si cette ROM peut être vue ou pas s'il décide de mapper les pages physiques dans la zone d'adressage des process.

j'suis pas sur d'avoir tout pigé la ... en gros vous me dites que win utilise l'int 10h (en repassant en mode reel,etc...) mais pas linux , c'est ca ?

je suis partisan pour dire qu'aucun des deux n'utilise l'int 10h pour passer en mode graphique (en tout cas après le boot... puisque j'ai effectivement vu un appel à l'int 10h dans les toutes premières étapes du linux boot process);
Repasser en mode réel n'est franchement pas la chose à faire car on perd tout le bénéfice du mode protégé (pendant un temps court mais c'est déjà trop). De plus c'est vraiment un sacré bordel à gérer si la pagination est activée.

C'est mon intuition, rien ne dit que ceci est la vérité.
golem
+++

[dway]

...
je suis partisan pour dire qu'aucun des deux n'utilise l'int 10h pour passer en mode graphique (en tout cas après le boot... puisque j'ai effectivement vu un appel à l'int 10h dans les toutes premières étapes du linux boot process);
Repasser en mode réel n'est franchement pas la chose à faire car on perd tout le bénéfice du mode protégé (pendant un temps court mais c'est déjà trop). De plus c'est vraiment un sacré bordel à gérer si la pagination est activée.

C'est mon intuition, rien ne dit que ceci est la vérité.
golem
+++

et moi je suis quasiment sur du contraire !!! mais prouvez le moi en montrant du code !!!

[Blustuff]

Passé le chargement du driver de la carte vidéo et de la carte mère, l'os n'a certainement plus besoin des interruptiopns du bios. Pour quoi faire sinon ?

[Invité]

Attendez c'est quoi ce délire sur Linux qui n'a pas besoin du Bios ???

Le bios c'est le niveau le plus bas avant le matériel lui même (disque, ports,etc). Il conditionne ce que le système d'exploiattion pourra faire avec les périphériques présents.
Le meilleur exemple, c'est les vieux bios incapable de permettre la prise en charge par un OS de disques de capacités supérieurs à 8Go (ou 4 ou 2 je ne me souviens plus).
C'est notre ami le bios qui orchestre la vie de tous ces composants qui ensemble s'appellent un micro-ordinateur.

Pour la vidéo, l'accès direct en mode vga standard permet l'affichage en mode caractère au démarrage, après les pilotes de l'os permettent l'usage de toutes les fonctions propres à la carte.

J'ai pris le temps de lire tout le sujet avant

[dway]

ou la la , y'a du melange dans l'air la !!!

a mon avis, linux, comme 95% des OS (à part le DOS ) redeveloppent eux-mêmes la majorité des int du bios , sinon il faudrait repasser en mode reel pour accéder aux disques via l'int 13h par ex !! par contre pour l'int 10h (et aussi certaines fonctions de l'int 15h) je suis quasiement sur qu'ils utilisent toujours le bios, encore une fois je le répéte, si qq'un connait bien les src de linux il faudrait jeter un oeil....

et quand vous parlez de charger un driver vga au démarrage, il faut bien le developper non ? il suffit pas de passer en mode vidéo via l'int 10h au démarrage puis de passer en mode pro pour le kernel, sinon comment ferais windows pour changer de mode video aprés le boot (en mode pro) ?

[Invité]

Un système comme windows NT utilise une "Hardware Abstraction Layer".
On ne peut pas redévelopper des interruptions matérielles, seulement les exploiter
Pour le mode vidéo, en écrivant des valeurs adéquates dans les registres de la carte, on obtient l'effet souhaité. Pour le vga c'est la même chose pour tout le monde, pour le reste, chaque fabricant a sa propre sauce...

[dway]

...
- à F000:FFF0 se trouve la première instruction du BIOS qui est un jump (vous pouvez d'ailleurs facilement vérifier avec debug et un unassemble). Pourquoi un jump ? Parce qu'il n'y a que 16 octets entre cette adresse d'init. et la barrière des 1megs. Vous n'imaginez pas un bios de 16 octets tout de meme ? Ce saut nous envoie donc à l'adresse "réelle" du début du BIOS, chez moi c'est F000:E05B mais peut changer suivant le contructeur, la révision ... c'est ici que commence le boot process: test des mémoires, init. basique des controleurs disques, détection d'une carte graphique, init. du keyboard, ports com et patin coufin. Il doit y avoir un peu de travail aussi sur le chipset puisque les périph sus cités font de nos jours partie d'un seul circuit qui est le chipset...
...

j'ai jeté un oeil avec debug , moi aussi il jmp à F000:E05B , par contre est ce que tu peux stp me montrer qqs lignes de codes que tu obtiens en dessassemblant à cette adresse ? ca ma parait bizarre ce que je trouve...

[dway]

Un système comme windows NT utilise une "Hardware Abstraction Layer".
On ne peut pas redévelopper des interruptions matérielles, seulement les exploiter
Pour le mode vidéo, en écrivant des valeurs adéquates dans les registres de la carte, on obtient l'effet souhaité. Pour le vga c'est la même chose pour tout le monde, pour le reste, chaque fabricant a sa propre sauce...

euh la à mon avis tu te trompe...pourquoi on ne pourrait pas redevelopper un int ? je l'ai fait des dizaines de fois ...

et si tu sais activer un mode video en écrivant directement dans ls ports de la carte VGA (san l'int 10h), balances du code je demande à voir !!, moi tout ce que j'ai trouvé c'est les src d'un vieux bios xt qui initialise le mode 03h txt et ca fait 12 pages !!!

[Blustuff]

Il ne suffit pas de lire tout le post Florian, il faut un minimum chercher a comprendre ce que l'on a pu y dire. Il n'a jamais été question de remplacer le bios. Ce qu'il fait au démarrage était la question posée et nous navons pas parlé des os qui se passent de cette étape, seulement des os qui se passent des interruptions du bios. (J'ai l'impression en te lisant que tu ne maitrise pas tellement ce sujet, en particulier quand je t'endend dire "redevelopper les interruptions materielle" qui ne veut pas dire grand chose... Bien evidement, les os détournent les interruptions)

Quand au dirvers, dway, leur développement n'est pas un problème, ce sont les constructerus qui les fournissent, donc ils ont la doc pour developper.

Florian Windows utilises le GDI pour l'affichage, donc pas de HAL.

(J'ai cherché comment dans son garage on pourrait essayer e changer de mode vidéo. C'est d'une part très complexe, vu le nombre de registres vga, mais il me manque quelque chose, quelque chose qui doit dire si un octet dans un plan représente un caractère, ou un index de registre dac, ou deux index de palette, et ca j'ai pas trouvé)

[dway]

...
Quand au dirvers, dway, leur développement n'est pas un problème, ce sont les constructerus qui les fournissent, donc ils ont la doc pour developper.
...

je ne pense pas que les mecs qui ont dev linux ont eu systématiquement les docs des fabricants de cartes ...surtout au début...

et pis moi je parlais surtout des modes vga ex : 03h et 13h, deja si qq'un arrive à me monter du code qui init ca ...

[CyberLudo2013]

Des exemples de code qui initialises les modes vidéo sans passer par le bios, ca doit exister. Mais a quoi bon puisque toutes les cartes video sont standard VGA et tout les bios implémente des intérruptions pour ce faire. Maintenant on a même des interruptions pour le VESA, directement dans la carte graphique, alors c'est même pas la peine de se poser de questions....

[SKZ81]

Generalement les develloppeurs de drivers Linux s'arrange avec les boîtes de matos pour avoir les docs, au moins le minimum pour developper les modules... Certaines noites sont rétissantes d'où les pressions de la Free Software Foundation via les utilisateurs de GNU/*** par des appels au boycott.
Certaines firmes fournissent des drivers sous forme binaire (developpé par la firme, mais pas OpenSource) pour Linux, mais celà ne résoud pas le problème des utilisateurs de FreeBSD par exemple.
Le problème est que sans la doc, le temps de developpement du driver atteint voire dépasse le temps d'obsolessance de la carte! Quel intérêt de gaspiller son temps... Autant utiliser du materiel "ouvert" !

L'intérêt CyberLudo? Eviter de repasser en mode réél. Bien faible sous Windows (n'importe quel vieux programme DOS écrit en mode réél peut le faire ) mais très important sous GNU pour des raisons de sécurité.
A mon avis même un prog setUID "root" (programme qui bénéficie des droits du super-utilisateur) ne peut pas faire ce genre de chose, les bidouilles assembleur nécessite (me semble) le niveau de sécurité "kernel" donc il faut developper le code dans un tout autre espace (kernel), i.e. developper un module, i.e. un driver....

[golem]

j'ai jeté un oeil avec debug , moi aussi il jmp à F000:E05B , par contre est ce que tu peux stp me montrer qqs lignes de codes que tu obtiens en dessassemblant à cette adresse ? ca ma parait bizarre ce que je trouve...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
-u F000:FFF0
F000:FFF0 EA5BE000F0    JMP     F000:E05B
F000:FFF5 3032          XOR     [BP+SI],DH
F000:FFF7 2F            DAS
F000:FFF8 3235          XOR     DH,[DI]
F000:FFFA 2F            DAS
F000:FFFB 3033          XOR     [BP+DI],DH
F000:FFFD 00FC          ADD     AH,BH
F000:FFFF 96            XCHG    SI,AX

la première instruction executée par le processeur se trouve en ROM BIOS et est un jump.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
-u F000:E05B
F000:E05B E91214        JMP     F470
F000:E05E 20431B        AND     [BP+DI+1B],AL
F000:E061 50            PUSH    AX
...

Cela nous mène vers un autre jump. Celui ci permet de sauter la zone de données qui se trouve en f000:e05e qui est du texte (version ...):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
-d F000:E05E
F000:E050                                            20 43                  C
F000:E060  1B 50 68 6F 65 6E 69 78-2D 41 77 61 72 64 20 42   .Phoenix-Award B
F000:E070  49 4F 53 20 76 36 2E 30-30 50 47 00 CB 32 EC 33   IOS v6.00PG..2.3
F000:E080  EC 35 EC 38 EC 3C EC 41-EC 47 EC 4E EC 77 61 72   .5.8.<.A.G.N.war
F000:E090  2E 43 6F 70 79 72 69 67-68 74 20 28 43 29 20 32   .Copyright (C) 2
F000:E0A0  30 30 32 2C 20 50 68 6F-65 6E 69 78 20 54 65 63   002, Phoenix Tec
F000:E0B0  68 6E 6F 6C 6F 67 69 65-73 2C 20 4C 54 44 00 61   hnologies, LTD.a
F000:E0C0  3C 41 53 55 53 20 41 37-4E 38 58 20 41 43 50 49   <ASUS A7N8X ACPI
F000:E0D0  20 42 49 4F 53 20 52 65-76 20 31 30 30 32          BIOS Rev 1002

Le deuxième jump nous mène ici:

-u F000:F470
F000:F470 8EEA MOV CS,DX
F000:F472 FA CLI
F000:F473 FC CLD
F000:F474 E464 IN AL,64
F000:F476 A804 TEST AL,04
F000:F478 7512 JNZ F48C
F000:F47A 8CC8 MOV AX,CS
F000:F47C 8ED0 MOV SS,AX
F000:F47E BC84F4 MOV SP,F484
F000:F481 E9AD02 JMP F731
F000:F484 86F4 XCHG DH,AH
F000:F486 7504 JNZ F48C
F000:F488 E9B54F JMP 4440
F000:F48B 90 NOP
F000:F48C 0F DB 0F
F000:F48D 01E0 ADD AX,SP
F000:F48F A801 TEST AL,01

On y voit entre autres init du registre cs, désactivation des interruptions, init. du flag de direction, du travail sur le controleur clavier (port 64h), init. des registres de pile ...




A titre de comparaison, voici ce que donne le bios rom de bochs:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
(0) [0x000fe05b] f000:e05b (unk. ctxt): xor AX, AX                ; 31c0
<bochs:3> disassemble 0xfe05b 0xfe15b
000fe05b: xor AX, AX                ; 31c0
000fe05d: out 0d, AL                ; e60d
000fe05f: out da, AL                ; e6da
000fe061: mov AL, c0                ; b0c0
000fe063: out d6, AL                ; e6d6
000fe065: mov AL, 00                ; b000
000fe067: out d4, AL                ; e6d4
000fe069: mov AL, 0f                ; b00f
000fe06b: out 70, AL                ; e670
000fe06d: in AL, 71                 ; e471
000fe06f: mov BL, AL                ; 88c3
000fe071: mov AL, 0f                ; b00f
000fe073: out 70, AL                ; e670
000fe075: mov AL, 00                ; b000
000fe077: out 71, AL                ; e671
000fe079: mov AL, BL                ; 88d8
000fe07b: cmp AL, 00                ; 3c00
...

On y trouve ici init. des controleurs DMA ...

L'intérêt CyberLudo? Eviter de repasser en mode réél. Bien faible sous Windows (n'importe quel vieux programme DOS écrit en mode réél peut le faire ) mais très important sous GNU pour des raisons de sécurité.

Je suis pas sur d'avoir compris ta remarque mais:
Un programme DOS executé sous windows ne fonctionne pas en mode réel mais en mode vm86 qui est un mode "réel emulé" cependant l'os tourne toujours en mode protégé.


golem
+++