Virtual Box saute à l'adresse 0x5C00 au lieu de 0x7C00

Bonjour,

Mon probléme est le suivant :

J'ai fait une disquette FAT12 bootable hardcoder à la main, le bootloader lit parfaitement le FS, charge un fichier exécutable à l'adresse 0x0000:0x7C00 puis effectue un saut à cette même adresse.

Jusque là tout va bien, le problème c'est qu'une fois arrivé dans le fichier exe, on est à l'adresse 0X05C00 alors que les adresses sont codées en dur dans le code, j'ai supposé que cela venait de VirtualBox mais je ne trouve rien sur le sujet.

Quelqu'un voit-il quoi faire ou d'où vient le problème ?

Les codes

salut,

je comprends pas tout à fait, quand tu dis "jusque là tout va bien" tu veux dire que les codes que tu as mis en pièce jointe fonctionnent ? (auquel cas c'est peut-être le LOADER qu'il faudrait mettre non ?)

j'ai essayé vite fait sans trop chercher :

Code:

---

1 2	nasm -f bin nasm -f bin VBR_FAT12.asm -o floppy.img qemu-system-i386.exe -fda floppy.img

---

j'ai également essayé avec virtualbox (créer une machine other/unknown, ajouter un floppy tout en haut de la liste, en virant le controleur ide par défaut au besoin, charger l'img, lancer la vm), tout fonctionne à priori au mieux de ce qu'on peut faire avec ce que tu nous donne (qemu & vbox), c'est à dire l'affichage de :

Code:

---

1 2 3

ASTERIX BOOTDISK File not found: /LOADER The system will be restart in 3 seconds.

---

ps: ce serait plutôt restarted ;o)

Effectivement, il manque le loader. Pour l'ajouter à l'image, il faut utiliser la commande mount :

Sous Linux :

Code:

---

1 2 3 4

mount -t msdos -o loop /chemin/vers/l/image /mnt/fdd0 cp /chemin/vers/le/loader /mnt/fdd0/LOADER umount -t msdos /mnt/fdd0

---

Dans le code, il y a une macro pour tester les deux cas.

PS : mon anglais est plus que douteux, il est fort possible que tu aies raison.

j'ai regardé un peu plus en détail,

le code tourne, il se reloge convenablement en 0:600, ce qui occasionne (jmp 0x0:reloc(_load_dvr)) un jmp 0:65f, jusque là pas de souci
le problème survient dans le _jmp_loader

Code:

---

1 2 3 4 5

_start: (...) _jmp_loader: mov dl, [bpbaddr(BS_DrvNum)] ; Retore disk ID jmp 0x0000:VBR_LOADADDR ; jump in loader file

---

concrètement l'opcode est jmp 0:7c00, sauf qu'il n'y a rien en 0x7c00, donc pour moi le secteur n'est simplement pas chargé, et la vérification d'erreur peut-être pas adéquate (le jc short .readdisk c'est bien ça ?)

j'ai pas investigué plus (je me suis surtout contenté de tracer le code en vérité ici), pour debugger j'ai utilisé gdb et qemu (mais c'est possiblement faisable avec vbox également)

d'un coté (bind sur localhost) :

Code:

---

qemu-system-i386 -boot a -fda floppy.img -S -gdb tcp:0.0.0.0:1234,ipv4

---

de l'autre :

Code:

---

1 2 3 4 5 6 7 8

$ gdb -q (gdb) set architecture i8086 (gdb) set disassembly-flavor intel (gdb) target remote parsifal:1234 (gdb) break *0x7c00 (gdb) continue (gdb) x/40i 0x7c41 etc.

---

si besoin je continuerai d'investiguer dans la soirée je pense

bon, c'est bien compliqué tout ça, j'ai tracé quasiment l'intégralité du code, concrètement au moment de charger le fichier ça charge bien quelque chose qui écrase la mémoire en 0x7c00, mais ce n'est pas le fichier
je suis pas du tout expert de la FAT12 mais j'ai l'impression que l'entrée dans la FAT pour déterminer les clusters utilisés par le fichier est un peu étrange:

Code:

---

0xa00: 0xf0 0xff 0xff 0x00 0xf0 0xff 0x00 0x00

---

ce qui revient à ff0 - fff - 000 - fff, je sais pas comment l’interpréter, la première entrée est celle du volume ça ok, mais la deuxième sous-entendrait qu'il s'agit d'un cluster vide ?

tu observes la même chose ? tu as avancé de ton côté ?

est ce que vous êtes au courant que les deux premier cluster n'existent pas? parce que sinon vous chargez peut être deux cluster plus loin

edit: après un bon repas et une lecture vite faite des codes source fournit il ne me semble pas que vous ayez prit en compte le fait que les deux premier cluster (le 0 et le 1) n'existe pas dans la zone de donnée, car 0= cluster vide et 1=cluster réservé
....le premier cluster dans la zone de donnée est donc le cluster 2

un mauvais calcul de la taille occupé par le repertoire racine peut aussi créer des problème (le parametre a l'offset 17 est le nombre d'entrée du repertoire (32 octets) et pas le nombre de secteur du répertoire racine)

je vous refilerait bien le code source de mon vieux amorceur pour disquette mais après vérification il n'y as aucun commentaire (erreur de jeunesse) et il ne vous aidera pas vraiment

@bifur: J'ai bien réservé deux clusters dans la FAT donc pas de problème avec ça.

@BufferBob: il semberai que la commande mount ajoute mal les fichiers comme je suis sous Windows j'utilise WinImage

Citation:

---

Envoyé par InitSreen

@BufferBob: il semberai que la commande mount ajoute mal les fichiers comme je suis sous Windows j'utilise WinImage

---

j'ai utilisé mount sous Linux perso, apparemment elle s'y retrouve (copie dans les deux sens ok), VirtualClone Drive sous Windows en revanche fait mine de monter le volume mais ne spawn pas un nouveau lecteur comme il devrait, je ne sais pas quoi penser...

à mon avis il faudrait être sûr de la structure de la FAT avant de chercher une erreur éventuelle du côté du code, si tu as une image valide hésite pas à la mettre en pj évidemment

Citation:

---

Envoyé par bifur

est ce que vous êtes au courant que les deux premier cluster n'existent pas? parce que sinon vous chargez peut être deux cluster plus loin

edit: après un bon repas et une lecture vite faite des codes source fournit il ne me semble pas que vous ayez prit en compte le fait que les deux premier cluster (le 0 et le 1) n'existe pas dans la zone de donnée, car 0= cluster vide et 1=cluster réservé
....le premier cluster dans la zone de donnée est donc le cluster 2

---

à l'exécution le fichier semble se trouver sur le cluster n°3, multiplié par 1.5 il vérifie donc si j'ai tout bien compris la valeur à 0xa00 + 4 (cf plus haut) et tombe à priori sur 000 (cluster vide)

si votre fichier commence par le cluster n°3 et que la table montrée plus haut est bien l'image de la table fat, le cluster numéros 3 est bien marqué comme étant une fin de fichier (0FFFh) c'est le cluster numéros 2 qui est marqué comme vide

Citation:

---

Envoyé par bifur

si votre fichier commence par le cluster n°3 et que la table montrée plus haut est bien l'image de la table fat, le cluster numéros 3 est bien marqué comme étant une fin de fichier (0FFFh) c'est le cluster numéros 2 qui est marqué comme vide

---

pardon, je me suis planté en l'écrivant, l'occupation du fichier est censée être décrite à partir de la 3e entrée dans la table, donc on tombe sur 000 ou sur fff (selon qu'on commence à 0 ou 1 j'imagine) mais reste qu'à l'arrivée on ne sait pas quel(s) cluster(s) occupe le fichier, ou alors j'ai raté un morceau dans la spec

sauf erreur, une entrée valide devrait indiquer une valeur du genre f02 ou f03 par exemple, non ?

dans la table FAT on commence par l'entrée 0 (comme la plupart des fois en logique informatique) donc le cluster 3 est bien marquée comme étant la fin d'un fichier (si c'est un fichier de moins de 512 octet c'est normal)

selon la spec que j'ai uttilisé (https://fr.wikipedia.org/wiki/File_Allocation_Table qui est très bien) 0F02h et F03h renvoie a des numéros de cluster suivant du fichier, donc ça m'étonnerait que l'on les rencontre ici

ce cluster n°3 doit se trouver a l'adresse: tailleMBR+tailleFAT*NombreFAT+entréeROOT*32+octetCluster*(NumerosCluster-2)

avec:
tailleMBR = 200h (un secteur sur un disquette)
tailleFAT = valeur du word a l'adresse 22
NombreFAT = valeur de l'octet a l'adresse 16 (2 habituellement)
entréeROOT = valeur du word a l'adresse 17 (c'est le nombre de fichier dans le repertoire racine en gros)
octetCluster = 200h sur une disquette habituellement
NumérosCluster = 3 (pour cet exemple)

La commande mount décalle d'un cluster le fichier dans l'image par rapport à WinImage, pourquoi ?!? Hormis ça l'image
fonctionne visiblement.

Avec le code suivant pour le LOADER (en pièce jointe) et en l'ajoutant aux images avec WinImage, j'obtiens les deux images
selon que j'utilise la macro IMG_5C00 ou la macro IMG_7C00. Celle assemblé avec la macro IMG_5C00 fonctionne sous
VirtualBox et celle assemblé avec la macro IMG_7C00 n'affiche que les adresses sans texte ni retour à la ligne.

Alors que dans le code de l'image le saut vers le LOADER est codé en dur (VBR_LOADADDR=0x7C00) :

Code:

---

1 2 3 4

_jmp_loader: mov dl, [bpbaddr(BS_DrvNum)] ; Retore disk ID jmp 0x0000:VBR_LOADADDR ; jump in loader file

---

le LOADER s'exécute toujours à l'adresse 0x0000:0x5C00 (chez moi sous VirtualBox).

Sinon le reste doit fonctionner, sans quoi le LOADER ne s'exécuterait jamais ...

Plus précisément la question du post était:
Pourquoi VirtualBox charge et exécute le code à l'adresse 0x0000:0x5C00 alors que c'est l'adresse 0x0000:0x7C00 qui est spécifié en dur (donc pas calcullé ... ) ?

j'avoue ne pas comprendre a quoi sert ceci (n'étant pas utilisateur de nasm):

Code:

---

1 2 3 4 5 6 7 8 9

%define IMG_5C00 ;%define IMG_7C00 %define LOADADDR 0x7C00   %ifdef IMG_5C00 %define laddr(x) (0x5C00 + x) %elifdef IMG_7C00 %define laddr(x) (LOADADDR + x) %endif

---

À calculer l'adresse des données, dans le cas de la macro IMG_05C00 : l'adresse encodée au moment du linkage sera 0x5C00 + le décalage entre le début du fichier binaire et le label x et pour IMG_7C00 se sera 0x7C00 + le décalage entre le début du fichier binaire et le label x. J'aurais tout aussi bien pu utiliser org 0x7C00 ou org 0X5C00.

pourquoi n'as tu pas utillisé org 7C00h a la place? c'est quand me moin long a ecrire! :weird:

ça m'explique pas mal de truc mais je ne voie toujours pas pourquoi ça bug.....a part peut être le fait que tu fait pointer ta pile sur le début du code (il vaut mieux bien les séparer)


sinon pour economiser un peu de place dans ton code (c'est important la place dans un amorçeur) je te conseille de remplacer _put par ça:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

_put: ;affiche la chaine ASCIIZ en ds:si push ax push bx push si mov ah,0Eh mov bl,0Ah b_put: mov al,[si] cmp al,0 je fin_put int 10h inc si jmp b_put fin_put: pop si pop bx pop ax ret

---

je ne me souviens plus si ça prend en compte les carac spéciaux mais il me semble que oui

Le code se relocalise pour ne pas être écrasé par le loader qu'il charge à l'adresse 0x07C00. En utilisant org 0x00 et des macros pour calculer l'adresse des choses, cela permet d'avoir une adresse de base à laquelle on ajoute le label voulue (le décallage depuis le début du fichier: org 0x00 + <label>)

j'ai passé un peu de temps a me gratter la tête pour comprendre ce qui as pu merder et je ne voie pas.....
est ce que tu pourrait me passer les binaires de tes deux image disque (une avec 7C00 et l'autre avec 5C00) pour que je puisse tester ça sur des machines réel? peut être que virtualbox merdois mais j'y croie pas trop

en tout cas sacrée boulot! par contre je ne comprend pas pourquoi vouloir faire obligatoirement charger LOADER en 7C00? est ce que c'est pour faire du multiboot sans grub mais avec disquette?

Citation:

---

Envoyé par bifur

est ce que tu pourrait me passer les binaires de tes deux image disque (une avec 7C00 et l'autre avec 5C00) pour que je puisse tester ça sur des machines réel? peut être que virtualbox merdois mais j'y croie pas trop

---

perso avec qemu j'ai rien observé de similaire, je sais pas d'où sort cette valeur 0x5c00 honnêtement, pour moi le code se reloge en 0:0600, le seul moment où ça viande c'est au moment de charger le fichier, la zone mémoire en 0:7c00 (qui contenait initialement le loader avant qu'il soit relogé) est comme effacée (remplie de zéros donc), ce qui me laissait supposer que ce n'était pas le bon secteur de la disquette qui était copié, et j'ai pas eu l'occasion de faire d'autres tests depuis

du coup ouai, ça m'intéresse aussi ^^

Citation:

---

Envoyé par BufferBob

le seul moment où ça viande c'est au moment de charger le fichier, la zone mémoire en 0:7c00 (qui contenait initialement le loader avant qu'il soit relogé) est comme effacée (remplie de zéros donc), ce qui me laissait supposer que ce n'était pas le bon secteur de la disquette qui était copié, et j'ai pas eu l'occasion de faire d'autres tests depuis

---

il y a peu-être quelques choses de ce coté là, je vais tout bien relire voir si je ne me suis pas trompé quelques part.

Citation:

---

Envoyé par bifur

par contre je ne comprend pas pourquoi vouloir faire obligatoirement charger LOADER en 7C00? est ce que c'est pour faire du multiboot sans grub mais avec disquette?

---

non, cela aurais tout aussi bien pût être une autre adresse.

Voilà les images

bon, j'ai essayé les deux image fournis sur machine réelle (un vieux pentium2 qui me sert pour tester mon ptit projet d'OS) et a part le message "ASTERIX BOOTDISK" rien d'autre ne s'affiche
j'ai relu et rerelu le code pour voir si je voyait une souce d'erreur mais je ne voie rien, des chose estrange que je n'aurait pas fait comme ça, mais rien qui me semble être la source de l'erreur

je met ici mon logiciel d'amorçage créer il y a quelques années pour rendre amorçable une disquette, crée pour dos (executable.com) le programme ne recrée pas une image disque complète mais modifie le code d'amorçage de la disquette qui est dans le lecteur sans altérer le système de fichier. le code d'amorçage cherche le fichier SYST.BAZ dans le répertoire racine et le charge a l'adresse 5000h:0000h

si c'est une copie de secteur vide comme le pense Buffer Bob ça viens surement d'un simple décalage de secteur, je suis en train d'essayer de comprendre comment tu procède pour convertir un numéros de secteur en coordonné CHS, tu arrive probablement a trouver l'entrée de ton fichier "LOADER" dans le répertoire root car lors de la lecture tu lit plusieur secteur a la fois (et par chance tu lit le premier secteur de répertoire root) mais lors du chargement de LOADEr ça ne fonctionne pas. il faudrait voir si lors du chargement du répertoire root il n'y as pas de décalage de secteur(on lirait une partie de la deuxième table FAT avant de lire le début du repertoire)

Citation:

---

Envoyé par bifur

bon, j'ai essayé les deux image fournis sur machine réelle (un vieux pentium2 qui me sert pour tester mon ptit projet d'OS) et a part le message "ASTERIX BOOTDISK" rien d'autre ne s'affiche

---

As-tu corrigé la géométrie de la disquette dans le BPB (car il s'agit ici d'une image possédant une géométrie particulière qui n'est pas nécéssairement adapté a ta disquette) ?

Citation:

---

Envoyé par InitSreen

As-tu corrigé la géométrie de la disquette dans le BPB (car il s'agit ici d'une image possédant une géométrie particulière qui n'est pas nécéssairement adapté a ta disquette) ?

---

ah bon ? dans quelle mesure ? (c'est bien de le préciser)

par ailleurs je me suis vite fait penché sur le remote debugging avec VirtualBox (sous windows en l'occurrence), je confirme un comportement rigoureusement identique à celui observé sur qemu (LOADER copié avec mount sous Linux) (on aurait pu s'en douter mais encore fallait-il en être sûr), du coup ce qui m'interroge un peu;

• d'où provient cette valeur de 0x5c00 ? elle est observée/déduite par quel biais ?
• vous vous y prenez comment pour debugger de votre coté ? (quels outils etc.)

je n'ai pas eu le temps de tester les disquettes montées avec WinImage, je jette un oeil d'ici ce soir

Citation:

---

Envoyé par BufferBob

ah bon ? dans quelle mesure ? (c'est bien de le préciser)

---

La géométrie de la disquette varie en fonction de son fabricant, de sa taille et de son formattage, rapidemment voici la liste des géométrie reconnu pour les disquettes MS-DOS (et donc FAT). Sachant qu'une disquette doit garantir (pour être compatible) au moins les spec de cette liste. Si un support offre plus de secteur par piste ou plus de tête ou plus de cylindre, ceux-in seront simplement ignoré.

Citation:

---

Envoyé par BufferBob

d'où provient cette valeur de 0x5c00 ? elle est observée/déduite par quel biais ?

---

cette partie du dernier code du LOADER affiche CS (chez moi cela affiche 0x0)

Code:

---

1 2 3

mov ax, cs mov cx, 0x10 call _put_nb ; print current segment selector

---

puis l'appel à la fonction _addr empile la valeur de IP pour le retour de fonction

Code:

---

call _addr ; print offset of the next instruction (mov si, laddr(_lf))

---

puis

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

_addr: push bp ; sauve BP mov bp, sp ; BP pointe le sommet de la pile (old BP) add bp, 2 ; BP pointe la valeur de retour pour IP mov ax, [ss:bp] ; la valeur de retour pour IP est mis dans AX mov cx, 0x10 ; base 16 call _put_nb ; affiche l'adresse mov si, laddr(_lf) call _put ; affiche le retour à la ligne pop bp ret

---

j'obtient une adresse 0x5Cyz ou yz est l'offset de l'instruction suivant le

Code:

---

call _addr

---

Donc j'en conclue que le LOADER s'exécute à partir de l'adresse 0x0:0x5C00

Citation:

---

As-tu corrigé la géométrie de la disquette dans le BPB (car il s'agit ici d'une image possédant une géométrie particulière qui n'est pas nécéssairement adapté a ta disquette) ?

---

j'ai utillisé une disquette standard 1.44Mb qui semble correspondre aux paramêtre enregistré dans le BPB

je pense avoir trouvé pourquoi ça merdoyait, il semble qu'il y ait une erreur au niveau de conversion dans la fonction _intx13

Code:

---

1 2 3 4 5 6 7 8 9

xor dx, dx ; clean DX mov byte [ds:bp+4], cl ; save sector count (word_array[2]) mov cx, [bpbaddr(BPB_SecPerTrk)] ; CX = BPB_SecPerTrk div cx ; AX =cylinder:head ; DX = sector number push dx ; save sector number xor dx, dx mov cx, [bpbaddr(BPB_NumHeads)] ; CX = BPB_NumHeads div cx ; AX =cylinder number ; DX = head number mov byte [ds:bp+2], dl ; save head number for int 0x13 (word_array[1])

---

on ne doit pas diviser par le nombre de secteur par piste mais par le nombre de secteur par cylindre, c'est a dire le nombre de secteur par piste multiplié par le nombre de tête (dans de nombreuse doc on ne fait pas la différence entre la piste et le cylindre)

ensuite le résultat entier de cette division est la coordonnée de N° de cylindre (pas le numéros de secteur)

la division suivante doit être celle du reste de la première par le nombre de tête, ce qui nous donne le numéos de tête et le reste de cette division est le numéros du secteur

et en dernier faut pas oublier de rajouter 1 au numéros de secteur car leur numérotation commence par 1

ce qui donne (si je reprend la source de AMORC.ASM et que je rajoute quelques commentaire)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

mov cx,[bpbaddr(BPB_NumHeads)] mov ax,[bpbaddr(BPB_SecPerTrk)] mul cx ;ax=nombre de secteur par cylindre mov cx,ax mov ax,bx ;bx=numéros LBA du secteur xor dx,dx div cx mov bx,ax ;bx=numéros de cylindre/numéros de piste mov ax,dx mov cl,[bpbaddr(BPB_NumHeads)] div cl ;ah=numéros de secteur-1 al=numéros de tête inc ah ah=numéros de secteur   mov dh,al ; a partir d'ici c'est pour adapter les données aux paramètre de la fonction lecture de l'int13h mov cx,bx xchg cl,ch shl cl,6 and cl,0C0h and ah,03Fh or cl,ah

---

j'en suis sur a 95%

un vieux pense bête a moi: http://bifur.olympe.in/?art=4

si c'est ça la modification va lui couter très cher à mon avis, la fonction _intx13 étant appelée plusieurs fois et le secteur dans lequel elle se trouve ne disposant plus que de 2 octets libres, le tout sans debugger... :aie:

mais non....
si il optimise un peu son code il n'y as pas besoin de beaucoup plus de place, il peut aussi a mon avis réduire pas mal la taille de la fonction _put et en dernier recourt il peut réduire un peu la taille du texte

sauf que:

N / (BPB_NumHeads * BPB_SecPerTrk) == ( N / BPB_SecPerTrk) / BPB_NumHeads

j'ai testé la modif de la fonction eeeettt.......ça marche pas:aie:
enfin pas tout a fait comme prévu, si je ne met pas le fichier loader dans la disquette il affiche un message d'erreur et redémarre (normal donc) mais si je met le fichier LOADER dans la disquette il affiche "ASTERIX BOOTDISK" en boucle

j'ai du me planter quelque part.....

Citation:

---

N / (BPB_NumHeads * BPB_SecPerTrk) == ( N / BPB_SecPerTrk) / BPB_NumHeads

---

effectivement c'est vrai a condition qu'il n'y ait pas de reste issue de ces division (ce qui n'est pas toujour le cas)

Citation:

---

Envoyé par bifur

effectivement c'est vrai a condition qu'il n'y ait pas de reste issue de ces division (ce qui n'est pas toujour le cas)

---

dans notre cas les restes de divisions sont récupérés au fur et a mesure donc le pb ne vient pas de la.