flat assembler
Message board for the users of flat assembler.
Index
> OS Construction > IRQ not fired on real hardware Goto page 1, 2 Next |
Author |
|
poupougne 08 Feb 2011, 11:56
Hello,
I've been working for a long time on my own OS, an it works fine within emulator such as Bochs & Qemu. But it fails on real hardware : i have tested with 3 real PC, it works until it reaches "STI" and so, no IRQ is fired and OS loops in "idle" task. I've been searching for days an days (forums, doc) but found nothing significant. Do you have any idea ? Here is the booting part of my os (os.asm), and if you want to play a little, a floppy image (os.img) Thanks to all by advance
|
|||||||||||
08 Feb 2011, 11:56 |
|
poupougne 08 Feb 2011, 14:40
Thanks edfed, i will try it
At the moment, the whole source code fills in only one text file, more than 22,300 lines... personal convenience : i prefer handling only one file, and do pageup/pagedown... i force myself writing lots of comment but i know it's hard to read ! au fait, salut à toi marseillais |
|||
08 Feb 2011, 14:40 |
|
poupougne 09 Feb 2011, 08:40
I put EOI at the end of the ISR : it doesn't work
Here are some pieces of code from the whole, easier to read : A20 gate : Code: ; activation ligne A20 ; masquer les irg mov al,0xFF out 0xA1,al out 0x21,al ; si ko, essayer de desactiver le kbd avant (out 0x64,0xAD) et de le ; reactiver apres (cmd out 0x64,0xAE), ou de lire le Ouput Port avant d'y ; ecrire la meme valeur OR 2 (bit du A20 : bit 1 - a mettre a 1 pour activer A20) ; ;mov al,0xAD ;out clavier_port_command,al ; ecriture Output Port du 8042 ; attente_8042_1: jmp $+2 in al,clavier_port_command test al,2 jnz attente_8042_1 ; attend que le buffer soit dispo (bit 1 à 0) ; mov al,0xD1 out clavier_port_command,al ; ecriture Output Port du 8042 ; attente_8042_2: jmp $+2 in al,clavier_port_command test al,2 jnz attente_8042_2 ; on attend que le buffer soit dispo (bit 1 a 0) ; mov al,0xDF ; A20 + activation IRQ souris et clavier (0xCF a l'origine, 0xDF menuet32+bochs) out clavier_port_data,al ; autoriser la ligne A20 (envoi controleur 8042) ; attente_8042_3: jmp $+2 in al,clavier_port_command test al,2 jnz attente_8042_3 ; on attend que le buffer soit dispo (bit 1 a 0) ; ;mov al,0xAE ;out clavier_port_command,al ; ecriture Output Port du 8042 ; attente_8042_4: ;jmp $+2 ;in al,clavier_port_command ;test al,2 ;jnz attente_8042_4 ; on attend que le buffer soit dispo (bit 1 a 0) remap of 8259 : Code: ; mise en place des IRQ, programmation 8259 ; sauvegarde des masques ;in al,0x21 ;mov bh,al ;in al,0xA1 ;mov bl,al ; iowait a mettre apres chaque out, pour laisser le temps au PIC de travailler ;mov al,0xFF ; Masquage de toutes les interruptions avant travaux ;out 0xA1,al ;call pic_iowait ;out 0x21,al ;call pic_iowait ; mov al,0x11 ; Initialisation out 0x20,al out 0xA0,al ;call pic_iowait mov al,0x20 ; Initialisation - Master - 1ere IRQ = 0x20 out 0x21,al mov al,0x28 ; Initialisation - Slave - 1ere IRQ = 0x28 out 0xA1,al ;call pic_iowait mov al,0x04 ; Initialisation - Master - lien master/slave out 0x21,al mov al,0x02 ; Initialisation - Slave - lien master/slave out 0xA1,al ;call pic_iowait mov al,0x01 ; Initialisation - Master - divers (8086) out 0x21,al mov al,0x01 ; Initialisation - Slave - divers (8086) out 0xA1,al ;call pic_iowait ; ; attente plus longue avant de remettre les masques mov ecx,0xFFFF pic_att: nop loop pic_att ; remise des masques sauvegardes ;mov al,bh mov al,0 out 0x21,al out 0xA1,al call pic_iowait ;mov al,bl ; envoi EOI aux 2 pics mov al,0x20 out 0x20,al out 0xA0,al jmp pic_fin pic_iowait: nop ret pic_fin: |
|||
09 Feb 2011, 08:40 |
|
poupougne 17 Feb 2011, 15:23
While testing some issues, something strange happens.
After booting the os and "working" for a while (with qemu and bochs), i did a reset using emulator console, and at reboot, the same bug occurs : system halt and no irq fired ! No timer pulse neither keyboard response. Can it help ? |
|||
17 Feb 2011, 15:23 |
|
poupougne 22 Feb 2011, 08:00
I got it about the reset bug !
There was a bug in the CREATE PROCESS function that zero'ed the first kb of memory, instead of process header ; that's why the os halted at reset (very strange behaviour indeed). But it's still ko on real hardware... i continue debugging |
|||
22 Feb 2011, 08:00 |
|
Dex4u 22 Feb 2011, 16:53
Where do you STI ?, to enable interrupts .
|
|||
22 Feb 2011, 16:53 |
|
poupougne 23 Feb 2011, 08:52
Hello Dex,
STI is done at the end of all hardware initializations, as you can see in the os.asm file i posted. After lots of debuging, it seems that the os halt while calling "i015_debut" or "i049_debut" : the first function write a text on the screen (in text mode, with cursor moves using in/out on VGA registers), and the second is the CREATE PROCESS function. I'm not using paging nor TSS, and all irq are trapped using interrupt gate. All the processes are running in CPL0. I know that all comments are in French, and so it can be hard to understand. Tell me if you want more informations. |
|||
23 Feb 2011, 08:52 |
|
Dex4u 23 Feb 2011, 16:50
My search function in the editor must of mist it .
Anyway the best way to find the problem is this Code: mov byte [fs:0xB809E], "1" ; some code mov byte [fs:0xB809E], "2" ; some code mov byte [fs:0xB809E], "3" ; some code mov byte [fs:0xB809E], "4" ; some code mov byte [fs:0xB809E], "5" ; some code mov byte [fs:0xB809E], "6" ; some code mov byte [fs:0xB809E], "7" ; some code mov byte [fs:0xB809E], "8" ; some code And so on, then see what number it stops at. |
|||
23 Feb 2011, 16:50 |
|
poupougne 24 Feb 2011, 08:05
Thanks for the tip Dex.
I've done it and i found something interesting : it's not an IRQ firing bug I misunderstood the problem, because on real hardware, the os boot from USB pendrive (i've no more floppy...). And the boot loader fail when it reaches sector # 64 : it's translated in CHS to sector 1 and head 1. But the loaded sector is not the one expected. I copy the os with the "dd" utility, and my USB pendrive is set to 63 sectors and 255 heads. Is there something special to do when there are "255" heads ? Here is the part of code that loads sectors : Code: secteur_suivant: push cx mov cx,[boot_piste_sect] ; current sector - begins at 2 mov dh,[boot_tete] ; current head - begins at 0 mov dl,[boot_device] ; push es xor bx,bx mov ah,2 ; lecture secteur mov al,1 ; nb de secteurs à lire int 0x13 jc load_kernel_error ; erreur lecture kernel mov ax,0x0E2E ; affiche un point (pour la progression) int 0x10 pop es mov ax,es add ax,0x20 ; ajoute 512 au segment (0x20 = 32 * 16 = 512) mov es,ax ; calcul secteur suivant CHS (secteur++ puis head++ puis cylindre++) mov cx,[boot_piste_sect] mov dh,[boot_tete] inc cl ; sect + 1 cmp cl,[disk_nbsect] jbe secteur_fincalc mov cl,1 inc dh ; head + 1 cmp dh,[mask_tete] ; max head reaches jbe secteur_fincalc ; on revient a la tete 0 : piste + 1 ! inc ch secteur_fincalc: and dh,[mask_tete] mov [boot_piste_sect],cx mov [boot_tete],dh pop cx xor si,si loop secteur_suivant |
|||
24 Feb 2011, 08:05 |
|
edfed 24 Feb 2011, 10:18
about the loading error at sector 63, check the USB boot secret topic from mike gonta, it explains the extended INT13h that you need.
|
|||
24 Feb 2011, 10:18 |
|
Dex4u 24 Feb 2011, 18:47
Have you tryed to set [disk_nbsect] to one less, to see if that makes a difference.
|
|||
24 Feb 2011, 18:47 |
|
poupougne 28 Feb 2011, 09:36
It's running with extended int 13h !
On laptop, USB pen is recognized as HDD emulation and boot fine. On MSI motherboard based computer, it's recognized as FDD emulation and extended int 13h returns error... If i manage to make it boot the two ways, i will share the resulting code. Thanks to all. |
|||
28 Feb 2011, 09:36 |
|
Mike Gonta 02 Mar 2011, 10:00
poupougne wrote: It's running with extended int 13h ! Hi poupougne, Some BIOS/version use the size of the UFD to determine the emulation, this varies but 1 GB and up should result in HDD emulation unless the the BIOS/version is very old. Can you run the code here and report the results with the BIOS maker and date? Last edited by Mike Gonta on 02 Mar 2011, 11:45; edited 1 time in total |
|||
02 Mar 2011, 10:00 |
|
Mike Gonta 02 Mar 2011, 11:45
poupougne wrote: I misunderstood the problem, because on real hardware, the os boot from USB pendrive (i've no more floppy...). And the boot loader fail when it reaches sector # 64 : it's translated in CHS to sector 1 and head 1. But the loaded sector is not the one expected. The emulated geometry of the UFD can not be predicted or assumed. Int 13 function ah=8 Get Drive Parameters must be used to obtain the emulated geometry. The LBA can then be converted accordingly. |
|||
02 Mar 2011, 11:45 |
|
Dex4u 02 Mar 2011, 15:37
Wow!, Mike Gonta, i have just tried your latest æBIOS you have done a great job.
|
|||
02 Mar 2011, 15:37 |
|
poupougne 03 Mar 2011, 08:00
Hi Mike,
I did it and the result is : DELL Laptop C: C: 03/02/05 MSI motherboard BIOS cannot boot Add a BPB C: C: 12/07/07 I did a small bootloader that displays sectors on USB pen (size 32 MB) : DELL : HDD emulation with 32 sectors and 2 heads MSI : FDD emulation with 32 sectors and 64 heads The bootloader (sorry for french comments ) : Code: use16 org 0 jmp boot nop ; 3 octets avant le BPB db '12345678' ; nom du prog de generation du BPB (8 octets) dw 512 ; nb octets pas secteur db 1 ; nb secteurs par cluster dw 1 ; nb secteurs reserves (en comptant secteur de boot, avant la FAT) db 2 ; nb FAT dw 512 ; taille repertoire racine dw 63776 ; nb total de secteurs (si < 65536, sinon 0) 0xF920 63776 db 0xF8 ; type disque : floppy F0, dur F8 dw 248 ; taille FAT en secteurs disk_nbsect: dw 63 ; nb secteurs par piste (soit 1012 pistes) 63 disk_nbtete: dw 255 ; nb tetes 255 disk_cache: dd 0 ; nb secteurs caches (avant/apres secteur de boot ?) 32 dd 0 ; nb total de secteurs (si > 65535, sinon 0) ********** ;***** Extended BPB FAT16 (26 octets) boot_device: db 0 ; boot device (a partir de 0 pour floppy/amovible et 80 pour les fixes) db 0 ; reserve db 0x29 ; signature dd 0xFCE96061 ; numero de serie du disque db '12345678123' ; nom du disque (11 octets) db '12345678' ; type de FS 8 octets boot: jmp 0x07C0:boot2 boot2: mov ax,cs ; segment de données = segment de code mov ds,ax mov es,ax push es mov [boot_device],dl ; no lecteur de boot a memoriser mov ah,8 ; get drive parameters int 0x13 pop es jc secteur_suivant and cx,0x3F mov [disk_nbsect],cx inc dh mov [disk_nbtete],dh secteur_suivant: mov cx,[boot_piste_sect] mov dh,[boot_tete] mov dl,[boot_device] mov bx,buffer mov ah,2 ; lecture secteur mov al,1 ; nb de secteurs à lire int 0x13 jc load_error ; erreur lecture kernel ; affichage donnees secteur call aff ; calcul secteur suivant CHS mov cx,[boot_piste_sect] mov dh,[boot_tete] inc cl cmp cl,[disk_nbsect] jbe boot_finsuiv mov cl,1 inc dh cmp dh,[disk_nbtete] jb boot_finsuiv mov dh,0 inc ch boot_finsuiv: mov [boot_piste_sect],cx mov [boot_tete],dh ; inc word [boot_lba] test word [boot_lba],7 jnz secteur_suivant ; attente touche tous les 8 secteurs mov ah,0 int 0x16 jmp secteur_suivant ;-------------------------------------------------------------------------------- boot_piste_sect dw 1 ; piste (H) secteur (L) en cours boot_tete db 0 ; tete en cours boot_lba dw 0 ; no secteur absolu (LBA) en cours ;-------------------------------------------------------------------------------- aff_chaine: ; boucler sur la chaine pointee par DI et stop si zero mov ah,0x0E xor bx,bx mov al,[di] inc di or al,al jz fin_aff int 0x10 ; affichage du caractere jmp aff_chaine fin_aff: ret load_error: jmp load_error aff: ; affichage des 24 premiers octets du buffer ; LBA et no secteur/piste/tete mov ax,[boot_piste_sect] xor ah,ah mov di,secteur_aff2 call decimal mov ax,[boot_piste_sect] xchg al,ah xor ah,ah mov di,secteur_aff4 call decimal mov al,[boot_tete] xor ah,ah mov di,secteur_aff3 call decimal mov ax,[boot_lba] mov di,secteur_aff1 call decimal ; 24 cars mov cx,24 mov di,secteur_aff5 ; car mov si,secteur_aff6 ; hexa mov bx,buffer carsuiv: mov al,[bx] mov dl,al inc bx ; hexa mov ah,al shr ah,4 and al,0x0F add ax,0x3030 cmp ah,0x39 jbe hex1 add ah,7 hex1: cmp al,0x39 jbe hex2 add al,7 hex2: mov [si],ah mov [si+1],al ; car cmp dl,0x20 jb aff_point cmp dl,0x7E jbe aff_car aff_point: mov dl,'.' aff_car: mov [di],dl inc di add si,3 loop carsuiv mov di,secteur_aff call aff_chaine ret decimal: ; convertit ax en decimal et le met dans secteur_aff1 xor dx,dx mov bx,10 div bx add dl,0x30 mov [di+4],dl xor dx,dx div bx add dl,0x30 mov [di+3],dl xor dx,dx div bx add dl,0x30 mov [di+2],dl div bl add ax,0x3030 mov [di+1],ah mov [di],al ret ;-------------------------------------------------------------------------------- secteur_aff: db 'LBA ' secteur_aff1: db '00000 Sec ' secteur_aff2: db '00000 Tet ' secteur_aff3: db '00000 Cyl ' secteur_aff4: db '00000 Car ' secteur_aff5: db '012345678901234567890123',13,10 secteur_aff6: db '00 11 22 33 44 55 66 77 88 99 00 11 22 33 44 55 66 77 88 99 00 11 22 33',13,10 db 13,10,0 ;************************************************************************ times 510-$ db 0 dw 0xAA55 ; marque le secteur comme bootable buffer: ; FIN BOOT SECTOR times 512 db 0 times 512*16 db 'A' ; 18/19 ici times 512 db 'B' times 512*44 db 'C' ; 63/64 ici times 512 db 'D' times 512*5 db 'E' The bootloader has been copyed to the USB pen with "dd". The bootloader displays the right letters while sectors are read, according to translation LBA/CHS It seems to work with it, but with the os boot loader, it fails ! Still debugging... |
|||
03 Mar 2011, 08:00 |
|
Mike Gonta 03 Mar 2011, 11:22
Hi poupougne,
Thanks for testing. poupougne wrote: I did a small bootloader that displays sectors on USB pen (size 32 MB) a larger capacity (1 GB min to be on the safe side) as HDD. poupougne wrote:
It's possible to have a maximum head number of 255 (even with real hard drives). This is a classic software problem which contributed to the 4.2 GB Barrier. Adding one to the maximum head number (which starts at 0) will give the maximum number of heads and should be saved as 16 bit. |
|||
03 Mar 2011, 11:22 |
|
poupougne 09 Mar 2011, 12:22
Hi,
On MSI motherboard, with Sempron 64 CPU, extended int 13h returns error (HDD emulation). So, i get drive geometry and then load kernel using CHS int 13h. It seems to work, but after STI, the computer is stuck ! There's a Code: mov byte [0xB8058],'.' at the beginning of the IRQ0 handler, but nothing displays in text mode. Does 64 bits CPU running in PM legacy 32 bits mode make a difference with a 32 "native" bits CPU running in PM mode ? It's running correctly on DELL laptop, Pentium M, firing IRQ 0/1/12 normally (32 Mo fob treated as FDD emulation), and on Qemu and Bochs 2.4.5 Thanks |
|||
09 Mar 2011, 12:22 |
|
Coty 09 Mar 2011, 14:53
poupougne wrote: Does 64 bits CPU running in PM legacy 32 bits mode make a difference with a 32 "native" bits CPU running in PM mode ? It shouldn't, My PC AMD Athlon 64 x2 was built by my dad in 2006. It has never ran a 64bit OS other than Baremetal and some 64bit helloworld OS. In all the time its ran... never saw the need, only 2GB of ram... Hmm, you only move one byte into buffer... Perhaps the screen attribute is black on black? Did you try to move a word into buffer? Code: mov edi, 0x000B8000 mov ah, 0x07 ; Colour atribute mov al, '!' ; This is an exclamation point! stosw ; Put to buffer nao! |
|||
09 Mar 2011, 14:53 |
|
Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.