0

EDIT: For the source code, you can check my repo on Github: https://github.com/tuhdo/os-study.

I mapped the IRQs on 2 PICs (x86) to entry 32th and onward in IDT. To test out the PIC interrupts, I put the first 31 routines to the same function. The problem is, I cannot get 15th interrupt entry to work, since it is reserved according to Interrupt Vector Table. That is, whenever I get into protected mode, after enable the mode in cr0 and jump to the first instruction in kernel space (the last line in stage2.asm, that is jmp 08h:0xFF0), it crashes (in Bochs, it jumps to address f000:fff0, which happens when things go wrong). Without adding the 15th entry, I can execute all code and terminate properly with hlt instruction.

Since the entry is reserved, what should I do to skip the 15h entry? Currently, my generic IDT entry looks like this:

;; IRQ0
  dw   0
  dw   0x30        ; gdt selector 0x30
  db   0
  db   011001110b  ; interrupt gate callable from userspace
  dw   0

The relevant code is in gdt.inc and idt.inc. My OS has some basic features:

  • Bootloader
  • 32 bit protected mode.
  • System calls (from userspace to kernel and back)
  • Initial interrupt support: So far, I can handle division by 0 or explicit interrupt call (i.e. int 1). I already activated PIC (pic.inc) and wanted to try it out since I mapped the PIC interrupts at 0x32. However, after adding 15th IDT entry, I got triple fault, while 14th and downward I did not have such problem.
Tu Do
  • 339
  • 2
  • 11
  • You should provide more code (preferably complete runnable). You do not need to skip the reserved entries in the IDT. – Jester Oct 09 '15 at 12:52
  • So you switch from real to protected mode, and then have a crash? What makes you think that this is related to the interrupt descriptor table and that particular entry of it? – Daniel Jour Oct 10 '15 at 17:18
  • @DanielJour Although it is hard to tell if a particular entry is responsible for the issue, I think the IDT is a reasonable thing to look at especially since the processor appears to have triple faulted (which would be an explanation for Bochs jumping to f000:fff0) – Michael Petch Oct 11 '15 at 20:38
  • @MichaelPetch Indeed, the IDT is a reasonable thing to look at, but so is the GDT (if it's invalid, or the size in the GDTR is wrong, or ...) and many other things that could have gone wrong. Without further background this will be no more than vague guessing. – Daniel Jour Oct 11 '15 at 20:40
  • @DanielJour No where did I say that you shouldn't look at the GDT (or anything else). But I mentioned the IDT because it was part of your discussion point (and the OP). I seem to be the only person who actually voted to close this question so far because there isn't enough information. – Michael Petch Oct 11 '15 at 20:44
  • @MichaelPetch Oh please excuse me then, I misunderstood your first comment :) I was still hoping that the OP would add relevant details, but it seems that won't happen, so I'm voting to close this, too. – Daniel Jour Oct 11 '15 at 20:52
  • If it crashes immediately after setting CR0 and entering protected mode then the contents IDT aren't the problem. The IDT is only read as necessary, and it shouldn't be necessary to read the IDT at that point. You should have disabled interrupts (CLI), and there should be no reason for a fault or an exception to occur. In particular since you've remapped PIC interrupts the only thing that could cause CPU to read the 15th entry of the IDT is an explicit `INT 0x0f` instruction. – Ross Ridge Oct 12 '15 at 05:12
  • @RossRidge The OS can get pass protected mode and execute user space code in `user_space.asm` – Tu Do Oct 12 '15 at 05:14
  • That contradicts what you've written in your question. In any case it still remains that there's no reason why the contents of the 15th entry of the IDT would cause your crash. – Ross Ridge Oct 12 '15 at 06:36
  • @RossRidge Actually, without adding the 15th entry, I can execute code in `user_space.asm`, but after adding the 15th entry in `idt.inc` and when trying to jump to the first kernel instruction (located at 0x10ff0, you can see kernel code in `kernel.asm`) in protected mode, it crashed. I'm not sure if some interrupt that requires 15th entry happened at that time. – Tu Do Oct 12 '15 at 06:52

1 Answers1

1

I know what was wrong. The reason is, I only allocated one sector for stage2.asm, but adding more entries grow the stage 2 bootloader beyond 512 bytes. For that reason, the IDT became malformed when being loaded and fault happened.

I changed this line in Makefile that only allocates 1 sector:

dd if=$(BUILD_DIR)/stage2.bin of=disk.dsk bs=512 count=1 seek=1

to allocate 3 sectors:

dd if=$(BUILD_DIR)/stage2.bin of=disk.dsk bs=512 count=3 seek=1

I know I should start writing a file system, but I will get to it later since the kernel is higher priority to me.

Tu Do
  • 339
  • 2
  • 11