Le fonctionnement de boot.s de Linux Kernel v0.01

bonsoir
j'ai lus cet article http://en.wikibooks.org/wiki/X86_Assembly/Bootloaders sur le bootloader
ils ont mentionné un code de boot.s de Linux Kernel v0.01
selon le commentaire, le programme est chargé initialement dans 0x7c00, en suit le programme se déplacera à 0x90000
si j'ai compris le code , le deplacement a été effectuer à la fin de cet portion de code, à l'aide de l'instruction

Code:

jmpi go,INITSEG
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 BOOTSEG = 0x07c0 INITSEG = 0x9000 SYSSEG = 0x1000 | system loaded at 0x10000 (65536). ENDSEG = SYSSEG + SYSSIZE entry start start: mov ax,#BOOTSEG mov ds,ax mov ax,#INITSEG mov es,ax mov cx,#256 sub si,si sub di,di rep movw jmpi go,INITSEG go: mov ax,cs
la question que je veux poser, c'est comment il a pu déplacer son code, je voir un branchement, il n'a pas copie les instructions d'un addresse vers une autre,
pouvez vous m'expliqué et merci

Bonjour,

Je ne crois pas qu'il se déplace, mais plutôt qu'il saute dans une autre portion du code, pour atteindre celui qu'il a besoin d'exécuter.

Hello à tous,

Citation:

Envoyé par LittleWhite

Bonjour,

Je ne crois pas qu'il se déplace, mais plutôt qu'il saute dans une autre portion du code, pour atteindre celui qu'il a besoin d'exécuter.

En fait, dans ce cas précis, il y a bien déplacement du code.

Citation:

Envoyé par linux user

si j'ai compris le code , le deplacement a été effectuer à la fin de cet portion de code, à l'aide de l'instruction

Code:

jmpi go,INITSEG

Pas tout-à-fait : le code a été déplacé, ou plus précisément copié de 0000:7c00 à 9000:0000 par le début du code, c'est-à-dire depuis la première jusqu'à l'instruction que tu cites.

Officiellement, les 512 octets du bootloader, issus du secteur du MBR, sont chargés par le BIOS d'un PC en 0000:7c00 et ce sont ces valeurs précises que l'on retrouve dans les registres : CS=0000 et IP=7c00. Mais le programme considère qu'il est implanté en fait en 07C0:0000, ce qui correspond rigoureusement au même endroit, mais permet de dire à l'assembleur qu'on démarre en 0000, ce qui est utile pour calculer l'adresse des étiquettes.

Une fois, le code déplacé en 9000:0000, c'est-à-dire à une adresse débutant réellement en 0000, l'instruction effectue un far call vers le segment INITSEG, soit 0x9000 et l'offset de l'instruction suivante, reperée par « go: », et qui demeure le même à l'emplacement de destination.

L'exécution se poursuit alors normalement, mais depuis ce nouvel endroit.

Voici l'extrait de code concerné avec des commentaires :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 BOOTSEG = 0x07c0 INITSEG = 0x9000 SYSSEG = 0x1000 | system loaded at 0x10000 (65536). ENDSEG = SYSSEG + SYSSIZE entry start start: mov ax,#BOOTSEG ; AX=07C0 (Segment de départ) mov ds,ax ; DS=AX (On ne peut pas le charger directement) mov ax,#INITSEG ; AX=9000 (Segment d'arrivée) mov es,ax ; ES=AX (Même problème) mov cx,#256 ; CX = 256 (car 256 mots de 16 bits donc 512 octets) sub si,si ; SI=0 sub di,di ; DI=0 rep ; Répète CX fois l instruction qui suit movw ; Charge [DS:SI] dans AX et copie-le dans [ES:DI], puis fais avancer les deux pointeurs de seize bits chacun jmpi go,INITSEG ; Saute vers l instruction suivante mais dans la zone de destination go: mov ax,cs ;

Citation:

Envoyé par Obsidian

Une fois, le code déplacé en 9000:0000, c'est-à-dire à une adresse débutant réellement en 0000, l'instruction effectue un far call vers le segment INITSEG, soit 0x9000 et l'offset de l'instruction suivante, reperée par « go: », et qui demeure le même à l'emplacement de destination.

Pour quoi, il cherche une adresse qui debute avec 0000 ? la première aussi l'est aussi

Code:

1 2 3 4 5 ; nothing to do times 510-($-$$) db 0 ; pad remainder of boot ; sector with 0 s dw 0xAA55 ; std PC boot signature
je crois que c'est pour éviter de forcer la reconnaissance de la signature "boot" pour passer du boot secteur au load kernel ou un truc du genre... mais bon.. là je suis pas sur de mon coup parce que là j'ai juste gardé cette petite note telle que.... :? sans la commenter...
bref pour une sort d'alignement des adresses quoi

Citation:

Envoyé par Obsidian

Code:

movw ; Charge [DS:SI] dans AX et copie-le dans [ES:DI], puis fais avancer les deux pointeurs de seize bits chacun

j'ai essayé cette instruction sur mon ordinateur (GAS), et ça n'a pas marché

Code:

a.s:12: Error: number of operands mismatch for `mov'

Pour quoi ?

Bonjour,

movw est un opcode binaire (il prend 2 opérandes : movw seg-reg, seg-reg ), l'assembleur utilisé par la personne ayant posté le boot secteur, devais permettre de définir implicitement le selecteur de segment et l'offset par défaut, ce qui n'est point le cas sous gas.

Citation:

Envoyé par linux user

Pour quoi, il cherche une adresse qui debute avec 0000 ? la première aussi l'est aussi

Non, l'adresse initiale est 0000:7c00, mais peu importe. Ce qui est fait ici, c'est déplacer le code plus loin en mémoire car la suite va probablement avoir besoin de travailler en mémoire conventionnelle.
Citation:
Envoyé par frp31
Code:

1 2 3 4 5 ; nothing to do times 510-($-$$) db 0 ; pad remainder of boot ; sector with 0 s dw 0xAA55 ; std PC boot signature
je crois que c'est pour éviter de forcer la reconnaissance de la signature "boot" pour passer du boot secteur au load kernel ou un truc du genre... mais bon.. là je suis pas sur de mon coup parce que là j'ai juste gardé cette petite note telle que.... :? sans la commenter...
bref pour une sort d'alignement des adresses quoi
Non, en l'occurence, c'est justement pour mettre en place la signature du boot. Le code ici présent va être compilé pour former le contenu du MBR. Bon, sur un disque dur, il faudra aussi intégrer à la main la table des partitions, mais il faut se souvenir que cette amorce peut se retrouver sur tous types de supports, notamment les disquettes.

Jusqu'à une époque récente, d'ailleurs, le noyau était auto-amorçable. Il suffisait donc de faire cat bzImage > /dev/fd0 pour obtenir une disquette bootable. Attention, pas un système utilisable, mais quelque chose qui permette de démarrer le noyau qui, lui, lançait le reste. C'était pratique notamment quand on utilisait des périphériques de stockage qui n'étaient pas reconnus par le BIOS. Ce n'est plus possible aujourd'hui.

Citation:

Envoyé par Ethan 0x21

Bonjour,

movw est un opcode binaire (il prend 2 opérandes : movw seg-reg, seg-reg ), l'assembleur utilisé par la personne ayant posté le boot secteur, devais permettre de définir implicitement le selecteur de segment et l'offset par défaut, ce qui n'est point le cas sous gas.

En fait, ce n'est pas ça. Il n'existe pas de telle instruction à ma connaissance.

Citation:

Envoyé par linux user

j'ai essayé cette instruction sur mon ordinateur (GAS), et ça n'a pas marché

Code:

a.s:12: Error: number of operands mismatch for `mov'

Pour quoi ?

Il s'agit en réalité… d'une faute de frappe ! :-) L'instruction implicite adéquate dans le contexte présent est MOVSW. L'extrait que tu cites est tiré du « kernel v0.01 », c'est-à-dire la toute première ébauche de système écrite par Linus en 1991, il y a maintenant 22 ans.

Les archives du noyau nous montrent que la toute première version officielle de Linux, donc Linux 1.0 en 1993, corrige déjà ce détail.

vous avez raison, je l'ai trouve
http://faydoc.tripod.com/cpu/movsw.htm

pour movw, elle est utilisée comme mov, mais pour les operations sur 16bits

Après la rédaction de code, doit-t-il être compilé en BIN?

Citation:

Envoyé par linux user

vous avez raison, je l'ai trouve
http://faydoc.tripod.com/cpu/movsw.htm

pour movw, elle est utilisée comme mov, mais pour les operations sur 16bits

Plus précisément, l'instruction exacte est MOV, donc « Move » en anglais, suivi du suffixe « B », « W », « D » pour, respectivement « Byte » (8 bits), « Word » (16 bits) ou « Double word » (32 bits). Ces suffixes sont facultatifs et tous les assembleurs n'utilisent pas forcément la même syntaxe.

En général, la largeur du déplacement est implicite mais quand elle a besoin d'être précisée, les assembleurs dérivant de MASM, par exemple, la spécifient explicitent à l'opérande, avec « byte ptr », par exemple.

MOVS, quant à elle, signifie « Move String » et est une instruction à part entière, mais qui peut être soumise aux mêmes suffixes.

Citation:

Après la rédaction de code, doit-t-il être compilé en BIN?

Oui.

sous NASM , il faut utiliser

Code:

nasm -f bin <nom de fichier>

comment faire cela sous GAS ? il parait qu'il n'utilise que ELF

Citation:

Envoyé par linux user

sous NASM , il faut utiliser

Code:

nasm -f bin <nom de fichier>

comment faire cela sous GAS ? il parait qu'il n'utilise que ELF

GAS va te produire un fichier objet .o destiné à être traité par le linker ld. C'est à lui qu'il faut demander d'utiliser le bon format de sortie pour le fichier final… s'il a été compilé pour le prendre en charge !

En l'occurrence, c'est ld --oformat=binary.