OSDev.org

Posted: **Tue Sep 10, 2024 1:29 pm**

Okay, so it builds now, but when I start it in QEMU, it resets...

Posted: **Tue Sep 10, 2024 1:38 pm**

I did some debugging, and line 19 in boot.asm:

jmp 0x08:.reload_CS ; 0x08 is code segment

crashes the system. The lgdt instruction doesn't crash it, why does line 19 crash it?

Posted: **Tue Sep 10, 2024 3:53 pm**

The CPU only accesses the GDT when it loads a segment descriptor. That JMP instruction is the first instruction that loads a segment descriptor after you've loaded GDTR. It crashes because GDTR does not point to your GDT.

You should take the time to understand how the tutorial code works before you copy it.

Posted: **Tue Sep 10, 2024 4:39 pm**

You copy and pasted tutorial code that doesn't apply to the way you did things. In boot.asm `_start` is your entry point. There are no parameters on the stack so referencing ESP+4 and ESP+8 just loads gibberish into your `gdtr`. Your call to `gdt_c` sets up your GDTR. NO reason to do anything more with it. Change:

Code: Select all

	cli ; Disable interupts, just in case.
	call gdt_c ; Call the C function (C is very good)

	; Code from wiki.osdev.org/GDT_Tutorial
	mov ax, [esp + 4]
	mov [gdtr], ax
	mov eax, [esp + 8]
	mov [gdtr + 2], eax
	lgdt [gdtr]
	
	jmp 0x08:.reload_CS ; 0x08 is code segment

to:

Code: Select all

	cli ; Disable interupts, just in case.
	call gdt_c ; Call the C function (C is very good)
	lgdt [gdtr]
	
	jmp 0x08:.reload_CS ; 0x08 is code segment

Note: you don't need CLI since interrupts will be off when a multiboot loader calls your code. You should also consider setting ESP to `stack` prior to calling your first function (in this case before `call gdt_c`).

As well you have a bug in gdt.c. You have:

Code: Select all

encodeGdtEntry((uint8_t*)((&gdt) + (i*8)), entries[i]);

I think you really want

Code: Select all

encodeGdtEntry((uint8_t*)&gdt[i*8], entries[i]);

. As well

Code: Select all

gdtr.limit = GDT_ENTRIES * 8 + 1;

should be

Code: Select all

gdtr.limit = GDT_ENTRIES * 8 - 1;

Posted: **Wed Sep 11, 2024 2:25 pm**

The GDT is fixed! Now I'm working on console again.

Posted: **Wed Sep 11, 2024 3:29 pm**

: yay; good.png (668 Bytes) Viewed 1808 times

Posted: **Wed Sep 11, 2024 5:17 pm**

So I'm done with console (and added a "main menu" for now). Time for IDT!

Posted: **Thu Sep 12, 2024 5:40 pm**

So I am making the IDT, but after a very short time, the exception handler gets called. I added some handler code that will print out the error before halting, and its a General Protection Fault.

I even tried making the PIC (I didn't add that yet to the repo), but that just made it a Double Fault.

Posted: **Thu Sep 12, 2024 6:29 pm**

Run QEMU with the `-d int -no-shutdown -no-reboot` the interrupt dumps including exceptions should give you information about the exceptions you are getting and where they occurred. I tried to build your code and the file with `isr_stub_table` seems to be missing.

Posted: **Thu Sep 12, 2024 6:40 pm**

MichaelPetch wrote: ↑Thu Sep 12, 2024 6:29 pm I tried to build your code and the file with `isr_stub_table` seems to be missing.

Huh. The "idt_asm.asm" file (which contains that) is in the GitHub repo, so I don't know why it would be missing.

MichaelPetch wrote: ↑Thu Sep 12, 2024 6:29 pm Run QEMU with the `-d int -no-shutdown -no-reboot`

I did that, but I couldn't really understand it, but heres the last "debug" message from QEMU:

Code: Select all

0: v=08 e=0000 i=0 cpl=0 IP=0008:00100796 pc=00100796 SP=0010:0007ff00 env->regs[R_EAX]=00000000
EAX=00000000 EBX=0010b320 ECX=000b8000 EDX=000003d5
ESI=00000000 EDI=00000000 EBP=00000000 ESP=0007ff00
EIP=00100796 EFL=00000202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT=     00109720 000007ff
IDT=     00109f40 000007ff
CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000000 CCD=0007fe70 CCO=EFLAGS
EFER=0000000000000000

Posted: **Thu Sep 12, 2024 7:01 pm**

You need to add your PIC code that remaps the PICs. You aren't actually getting a double fault. You are getting a timer interrupt (IRQ0) which happens to be coming in as interrupt 0x08 (same as double fault). You need to remap the PICs so they don't overlap the exceptions. Most people will map the master PIC to 0x20 (thru 0x27) and the slave PIC to 0x28 (thru 0x2f).

Once you get past that eventually you will learn that your interrupt stubs don't save (and later restore) the registers that are clobbered by calls to the C function exception_handler. As well in the case of exceptions with an error code, the error code isn't being removed from the stack prior to the IRET.

Posted: **Fri Sep 13, 2024 3:49 pm**

So I added the PIC, now I get a General Protection Fault....

Posted: **Fri Sep 13, 2024 5:02 pm**

If you'd like us to help you, we need to know more about that general protection fault.

Posted: **Fri Sep 13, 2024 5:36 pm**

You should not enable interrupts with STI until the PICs and the IDT are initialized. Do pic_init before idt_init. As for why you get a GPF it seems to be that you haven't created entries in the IDT from 0x20 (32) to 0x2f(47). You only created entries for the first 32 (the exceptions). You get a timer interrupt (IRQ0) and you haven't created a proper entry in the IDT for the IRQ so it GPFs.

Posted: **Fri Sep 13, 2024 6:52 pm**

I added this code to the idt_asm.asm file:

Code: Select all

stub:
	iret

And:

Code: Select all

%assign i 0 
%rep    256-32 
    dd stub
%assign i i+1 
%endrep

But it still GPFs.

OSDev.org

Keyboard driver resets system when key is pressed.

Re: Keyboard driver resets system when key is pressed.

Re: Keyboard driver resets system when key is pressed.

Re: Keyboard driver resets system when key is pressed.

Re: Keyboard driver resets system when key is pressed.

Re: Keyboard driver resets system when key is pressed.

Re: Keyboard driver resets system when key is pressed.

Re: Keyboard driver resets system when key is pressed.

Re: Keyboard driver resets system when key is pressed.

Re: Keyboard driver resets system when key is pressed.

Re: Keyboard driver resets system when key is pressed.

Re: Keyboard driver resets system when key is pressed.

Re: Keyboard driver resets system when key is pressed.

Re: Keyboard driver resets system when key is pressed.

Re: Keyboard driver resets system when key is pressed.

Re: Keyboard driver resets system when key is pressed.