I almost implemented minimal keyboard support into my OS. However, for some reason, my emulator (QEMU) likes to restart when it receives a IRQ1. This atleast means i'm processing a IRQ1 correctly (it also doesn't issue it 5624 times), it just seems to be crashing.
Yes, i still get 7's when i move my mouse. That happens in emulators when your mouse is PS/2. I still have to disable the mouse I/O port.
If you're hungry for my Github code (just updated), go:
https://github.com/NunoLava1998/DixiumOS
It compiles without errors, warnings on -Wall -Wextra.
How would i fix this problem?
PROGRESS:
implementing keyboard_handler (not the actual handler)
learning to receive IRQ1's
trying to call keyboard_handler only when a IRQ1 is issued.
Why does my OS crash when a IRQ1 gets issued?
-
- Member
- Posts: 273
- Joined: Sun Oct 09, 2016 4:38 am
- Libera.chat IRC: NunoLava1998
Why does my OS crash when a IRQ1 gets issued?
Last edited by NunoLava1998 on Tue Dec 20, 2016 1:58 am, edited 1 time in total.
Developing TRIODIUM OS. Or call it Dixium if you want. It doesn't matter.
https://github.com/NunoLava1998/DixiumOS
https://github.com/NunoLava1998/DixiumOS
Re: Why does my OS crash when a IRQ1 gets issued?
I can't see any IDT in your code, which would explain why it triple faults as soon as an interrupt is received.
-
- Member
- Posts: 273
- Joined: Sun Oct 09, 2016 4:38 am
- Libera.chat IRC: NunoLava1998
Re: Why does my OS crash when a IRQ1 gets issued?
Is this the correct way of initializing the IDT?iansjack wrote:I can't see any IDT in your code, which would explain why it triple faults as soon as an interrupt is received.
Code: Select all
struct IDTDescr{
uint16_t offset_1; // offset bits 0..15
uint16_t selector; // a code segment selector in GDT or LDT
uint8_t zero; // unused, set to 0
uint8_t type_attr; // type and attributes, see below
uint16_t offset_2; // offset bits 16..31
};
static inline void lidt(void* base, uint16_t size)
{ // This function works in 32 and 64bit mode
struct {
uint16_t length;
void* base;
} __attribute__((packed)) IDTR = { size, base };
asm ( "lidt %0" : : "m"(IDTR) ); // let the compiler choose an addressing mode
}
void load_lidt(void){
lidt(32, 64);
}
Is this correct?
EDIT: it isn't
Developing TRIODIUM OS. Or call it Dixium if you want. It doesn't matter.
https://github.com/NunoLava1998/DixiumOS
https://github.com/NunoLava1998/DixiumOS
Re: Why does my OS crash when a IRQ1 gets issued?
I would strongly recommend that you write assembler routines in pure assembler rather than trying to use in-line assembly, which can be rather complicated and i full of potential pitfalls. For example, in the line:
what is the purpose of your coment "let the compiler choose an addressing mode"? Surely you want to specify the addressing mode for this instruction rather than leaving it up to the vagaries of the compiler.
Code: Select all
asm ( "lidt %0" : : "m"(IDTR) ); // let the compiler choose an addressing mode
-
- Member
- Posts: 273
- Joined: Sun Oct 09, 2016 4:38 am
- Libera.chat IRC: NunoLava1998
Re: Why does my OS crash when a IRQ1 gets issued?
I'm not that good at stuff in interrupts. Also, i don't seem to find any "addressing modes" related to IDT.iansjack wrote:I would strongly recommend that you write assembler routines in pure assembler rather than trying to use in-line assembly, which can be rather complicated and i full of potential pitfalls. For example, in the line:what is the purpose of your coment "let the compiler choose an addressing mode"? Surely you want to specify the addressing mode for this instruction rather than leaving it up to the vagaries of the compiler.Code: Select all
asm ( "lidt %0" : : "m"(IDTR) ); // let the compiler choose an addressing mode
Developing TRIODIUM OS. Or call it Dixium if you want. It doesn't matter.
https://github.com/NunoLava1998/DixiumOS
https://github.com/NunoLava1998/DixiumOS
Re: Why does my OS crash when a IRQ1 gets issued?
I believe that you are still just cutting and pasting code without any understanding of what it does and how it works. This is never going to work.
For example, it doesn't look as if you understand what a hardware interrupt is and how the processor responds to one. I think you need to do quite a bit more reading before you are ready for OS development. Hone your C, assembler, and debugging skills on user programs first and then you will be better equipped to deal with more advanced stuff. But until you have a firm grounding in C programming and debugging you are not going to progress.
For example, it doesn't look as if you understand what a hardware interrupt is and how the processor responds to one. I think you need to do quite a bit more reading before you are ready for OS development. Hone your C, assembler, and debugging skills on user programs first and then you will be better equipped to deal with more advanced stuff. But until you have a firm grounding in C programming and debugging you are not going to progress.