Keyboard driver resets system when key is pressed.
Keyboard driver resets system when key is pressed.
Hello!
So I'm making a basic OS, and right now I'm on the keyboard driver.
Whenever I press a key, QEMU resets (triple fault maybe?)
Here's some of the code that may help: Some of the code is from ChatGPT and some is from Claude (I'm kind of a beginner, and i can not wrap my head around some stuff )
Hope you guys can help!
So I'm making a basic OS, and right now I'm on the keyboard driver.
Whenever I press a key, QEMU resets (triple fault maybe?)
Here's some of the code that may help: Some of the code is from ChatGPT and some is from Claude (I'm kind of a beginner, and i can not wrap my head around some stuff )
Hope you guys can help!
-
- Member
- Posts: 5446
- Joined: Mon Mar 25, 2013 7:01 pm
Re: Keyboard driver resets system when key is pressed.
Probably yes, but you can use QEMU's built-in debugging functions to find out for sure. For example, if you run QEMU with "-d int" (and maybe also "-no-reboot" and "-accel tcg") you can check the log for exceptions leading up to a triple fault.
You can't use inline assembly to turn an ordinary function into an interrupt handler. If you want to write an OS, you'll need to write at least part of the interrupt handlers in pure assembly. (GCC has a function attribute you can use for simple bare-metal applications, but it won't work for an OS.)
It's also a good idea to set up exception handlers first before you worry about other interrupts.
Large language models are not a substitute for learning. Lucky for you, there's an entire forum and wiki right here, dedicated to helping people like you learn about OS development. And unlike the LLMs, we actually know what we're talking about.
Re: Keyboard driver resets system when key is pressed.
Thank you for your response
I did that, but I couldn't understand anything it printed outProbably yes, but you can use QEMU's built-in debugging functions to find out for sure. For example, if you run QEMU with "-d int" (and maybe also "-no-reboot" and "-accel tcg") you can check the log for exceptions leading up to a triple fault.
I've added a ASM wrapper (I can't upload ASM files for some reason) and replaced the function in the "keyboard_init" function (see ), but now instead of crashing, it just doesn't print out the scancode.You can't use inline assembly to turn an ordinary function into an interrupt handler. If you want to write an OS, you'll need to write at least part of the interrupt handlers in pure assembly. (GCC has a function attribute you can use for simple bare-metal applications, but it won't work for an OS.)
I understand. I might soon enough replace all code from the AIs with code I get from here or even my own code.Large language models are not a substitute for learning. Lucky for you, there's an entire forum and wiki right here, dedicated to helping people like you learn about OS development. And unlike the LLMs, we actually know what we're talking about.
-
- Member
- Posts: 5446
- Joined: Mon Mar 25, 2013 7:01 pm
Re: Keyboard driver resets system when key is pressed.
There are lots of examples of interpreting QEMU interrupt logs in various forum threads. If you want to know what your specific QEMU log means, you can post it here. Usually the interesting parts are in the last 50 or 100 lines.
Just rename it. I'm not sure why .asm isn't in the list of allowed file extensions, though.
Re: Keyboard driver resets system when key is pressed.
Here's the log from QEMU (after keypress, command is qemu-system-x86_64 -kernel ./bin/kernel.bin -d int -no-reboot -accel tcg -D qemu_log.txt): Update: I've done debugging, and it seems like when I use the straight C function, it does print out the Scancode Recevived message, but the ASM wrapper doesn't.There are lots of examples of interpreting QEMU interrupt logs in various forum threads. If you want to know what your specific QEMU log means, you can post it here. Usually the interesting parts are in the last 50 or 100 lines.
Here's the ASM wrapper:
Code: Select all
global ps2_keyboard_handler_wrapper
extern ps2_keyboard_handler
ps2_keyboard_handler_wrapper:
pusha
call ps2_keyboard_handler
popa
iret
Code: Select all
mov byte [0xB8000], ' '
-
- Member
- Posts: 5446
- Joined: Mon Mar 25, 2013 7:01 pm
Re: Keyboard driver resets system when key is pressed.
The log shows two interrupts, one using vector 0x20 (called by you) and one using vector 0x21 (called by an external interrupt request). There are no exceptions, so presumably your code is running, but is your code supposed to be calling INT 0x20?
Your ASM wrapper doesn't clear the direction flag or align the stack (although you can usually get away without aligning the stack). Based on the QEMU log, the direction flag was already clear, so you may be running into a different bug somewhere else in your code.
Are you sure a space would be visible if it did run?
Re: Keyboard driver resets system when key is pressed.
]The log shows two interrupts, one using vector 0x20 (called by you) and one using vector 0x21 (called by an external interrupt request). There are no exceptions, so presumably your code is running, but is your code supposed to be calling INT 0x20?
Yes, INT 0x20 is supposed to run. It is a testing interrupt for after the IDT init, though I should clear that after the test is done. (the test passes, so it's hopefully not with the IDT code )
Yes, or at least something in the left corner.Are you sure a space would be visible if it did run?
Re: Keyboard driver resets system when key is pressed.
it looks from keyboard.c and that function being called from asm wrapper, that both call iret?
try normal return from the C function and not the ISR like pusha/popa in there, but only in the asm wrapper the state and iret things.
try normal return from the C function and not the ISR like pusha/popa in there, but only in the asm wrapper the state and iret things.
Re: Keyboard driver resets system when key is pressed.
I did make some changes to the code (I moved the handler out for the ASM file) but I did upload them to a GitHub repo so you guys can access the changes better.
-
- Member
- Posts: 5446
- Joined: Mon Mar 25, 2013 7:01 pm
Re: Keyboard driver resets system when key is pressed.
Why aren't you using a cross-compiler?
If you really don't want to use a cross-compiler for some reason, you should at least compile with "-ffreestanding -mgeneral-regs-only". Depending on your compiler's default settings, you may need additional options to produce a suitable kernel binary.
You really should compile with "-Wall -Wextra" to enable compiler warnings. You should also consider using "-Werror" since compiler warnings usually indicate bugs that must be fixed before your code will work.
Your linker script is missing some wildcards and the COMMON section.
Multiboot doesn't provide a stack. You need to set up your own stack before you call kernel_main.
You really should #include the headers that declare things in the code that defines those things. This will help you catch bugs.
Your inline assembly clobbers AX without telling the compiler.
Your console code is not interrupt-safe. You can't print text from inside an interrupt handler if an interrupt may occur while some other part of your kernel is already printing text.
You probably want to use the address of ps2_keyboard_handler_wrapper in your IDT, not its value.
Re: Keyboard driver resets system when key is pressed.
oof.
Well I will post another reply when I'm done doing all of that stuff.
Well I will post another reply when I'm done doing all of that stuff.
Re: Keyboard driver resets system when key is pressed.
Okay, I'm doing the cross compiler using crosstool-ng, but I found this option:
EDIT: im just going to put them in the build script.
Should I add the "-Wall -Wextra -Werror" flags to that?EDIT: im just going to put them in the build script.
-
- Member
- Posts: 5446
- Joined: Mon Mar 25, 2013 7:01 pm
Re: Keyboard driver resets system when key is pressed.
I've never used crosstool-NG, but the help text says those are flags used when compiling libraries that will be provided by the toolchain, so you probably don't want to add any flags there. Your toolchain won't have any libraries other than libgcc anyway.
Re: Keyboard driver resets system when key is pressed.
I would recommend always to do -Wpendantic or -Wall etc. (enable _all_ warnings) and try to ensure your compilation has no warnings at all. Usually they are there for good reason. There are rare cases that it's needed to do stuff that yields a warning, but I've not encountered any yet with my kernel stuff (I am also not so far yet... ).
-Werror might be a bit annoying as it will translate warnings to errors and really not let stuff build if there's a warning. It's maybe hardcore mode. Usually i try to get stuff working, and then get rid of all the warnings.
As for a cross-compiler. If you have any issues still after that, I'd recommend doing to full build of binutils + GCC as per the wiki. It takes a little time to build. Using the -j<num_processors+1> option can speed it up drastically. The instructions on the wiki are relatively easy to follow, and will help also learn a bit about building large software packages (and maybe hint towards how you want to create your own build system for your OS using makefiles.)
To test the IDT, i'd recommend using a CPU exception, for example the DEBUG exception. It's also nice to make a handler for that to actually print some debug info, like register contents etc. - that way you have a nice test, but also a good way to print out debug info when you need it.
The idt_test now seems to test the first IRQ (32?). If that is used by your devices it might cause some issues.
Lastly it might also be nice to use a stub-handler for IRQ's and ISR's so you can do the sending of EOI etc. there, and call a function from within that handler appropriate for the IRQ or ISR number. That way you don't have to duplicate that general handling code to all your handlers, and will have no chance you forget such things after it's all working.
Re: Keyboard driver resets system when key is pressed.
i am now going to start from scratch.