Keyboard driver resets system when key is pressed.

[Tomrs123]

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:

keyboard.c

(1.4 KiB) Downloaded 100 times

idt.c

(2.24 KiB) Downloaded 131 times

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!

[Octocontrabass]

QEMU resets (triple fault maybe?)

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.

Here's some of the code that may help:

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.

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 )

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.

[Tomrs123]

Thank you for your response

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.

I did that, but I couldn't understand anything it printed out

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've added a ASM wrapper (I can't upload ASM files for some reason) and replaced the function in the "keyboard_init" function (see

keyboard.c

(465 Bytes) Downloaded 94 times

), but now instead of crashing, it just doesn't print out the scancode.

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.

I understand. I might soon enough replace all code from the AIs with code I get from here or even my own code.

[Octocontrabass]

I did that, but I couldn't understand anything it printed out

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.

I can't upload ASM files for some reason

Just rename it. I'm not sure why .asm isn't in the list of allowed file extensions, though.

[Tomrs123]

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 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):

qemu_log.txt

(19.86 KiB) Downloaded 69 times

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.
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

Also, it doesn't even seem like the ASM wrapper runs. I added the following code to test:

Code: Select all

mov byte [0xB8000], ' '

But I dont see a space in the top left corner.

[Octocontrabass]

Here's the log from QEMU

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?

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.

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.

Also, it doesn't even seem like the ASM wrapper runs.

Are you sure a space would be visible if it did run?

[Tomrs123]

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 )

Are you sure a space would be visible if it did run?

Yes, or at least something in the left corner.

[sh42]

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.

[Tomrs123]

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.

[Octocontrabass]

GitHub repo

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.

[Tomrs123]

oof.

Well I will post another reply when I'm done doing all of that stuff.

[Tomrs123]

Okay, I'm doing the cross compiler using crosstool-ng, but I found this option:

cflags_crosstool_ng.png (1.7 KiB) Viewed 6717 times

Should I add the "-Wall -Wextra -Werror" flags to that?

EDIT: im just going to put them in the build script.

[Octocontrabass]

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.

[sh42]

Okay, I'm doing the cross compiler using crosstool-ng, but I found this option:
cflags_crosstool_ng.png

Should I add the "-Wall -Wextra -Werror" flags to that?

EDIT: im just going to put them in the build script.

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.

[Tomrs123]

i am now going to start from scratch.