OSDev.org

SomeGuyWithAKeyboard wrote:The bootloader sets the stack at 0x2FFFF for now. It seems like setting the stack at 0x1FFFF makes it successfully boot up a little more often when done on real hardware instead of crashing before it finishes starting up.

Neither of those are correctly aligned. (Correctly aligning your stack probably won't fix the problem, but it won't hurt.)

How much data are you dynamically allocating, anyway? That's an unusually large stack for a kernel.

SomeGuyWithAKeyboard wrote:On my 486 motherboard it freezes, on anything more advanced than that, it causes a reboot.

Are you switching between real mode and protected mode? Have you enabled the A20 line? Do you have exception handlers?

SomeGuyWithAKeyboard wrote:the cross compiler's io.h

Your cross-compiler shouldn't provide any files named io.h. Are you sure you're using the right kind of cross-compiler?

SomeGuyWithAKeyboard wrote:Here is a link to my project on github: https://github.com/Xeraster/SimpleProtectedModeOS

I'll be back later to take a better look at this.

How much data are you dynamically allocating, anyway? That's an unusually large stack for a kernel.

The memory allocator is currently set to be able to allocate up to 2kb of memory but I think with the testing stuff set up and all it only uses around 290 bytes of that by the time it lets you type in keyboard input. The stack was already at 0x6FFF or something and while the stack never goes more than FFF deep in bochs, I found through random trial and error that moving it somewhere else made it work better on real hardware for some reason.

Are you switching between real mode and protected mode? Have you enabled the A20 line? Do you have exception handlers?

I only switch from real mode to protected mode once and that happens it stays in protected mode. I'm not enabling the A20 line via the 8042 controller. I keep toggling on and off my code for enabling A20 via port 0x92 but it doesn't make a difference in reliability. My system doesn't actually use more than 1mb of memory or read or write anything to high memory (at least if it is, its not supposed to be).

I definitely don't have exception handlers or interrupts of any kind. Maybe I should.

Your cross-compiler shouldn't provide any files named io.h. Are you sure you're using the right kind of cross-compiler?

Am I sure I'm using the right kind? Short answer: no. I have a folder called "include" which has a bunch of header files. When I use "#include <sys/io.h>" with the corss compiler, it references an io.h from there. I can't actually remember but I'm pretty sure I made this one more or less by following the osdev tutorial. I did try several different methods of getting a cross compiler though and I might be misremembering things as i've been working on this on and off for quite a long time.

It turned out this project was on github the entire time with the last commit being august 2022 and I just forgot it was there.

SomeGuyWithAKeyboard wrote:When I use "#include <sys/io.h>" with the corss compiler, it references an io.h from there.

That's a Linux header. You're using a (cross?) compiler that targets Linux. You need a cross-compiler that targets bare metal.

The NASM manual says you shouldn't put square brackets around the CPU directive.

BIOS calls may re-enable interrupts. You should disable interrupts after you're done using the BIOS instead of before.

You shouldn't set the "conforming" bit (bit 2 of this byte) in your code segment descriptor. If you're not using the "accessed" bit (bit 0 of this byte), it's better to set it to 1 instead of 0. (The "accessed" bit is also 0 in your other descriptors.)

Bit 5 of this byte is reserved in protected mode and must be zero. Bit 4 is ignored by the CPU, is there any particular reason why you're setting it? (The reserved bit in this byte is also 1 in your other descriptors.)

You have a duplicate descriptor for the stack. There's no need for that, you can use the data descriptor.

The NASM manual says you shouldn't put square brackets around the bits directive either.

Your stack is not aligned correctly. You should set it to something like 0x30000 if you want it to be correctly aligned.

The general-purpose registers do not need to have segments in them. You've misunderstood the source you're referencing.

You should both make sure A20 is disabled before you try to enable it and make sure it actually did get enabled after you try to enable it. Modern PCs don't require enabling the A20 line, and very old PCs (like your 486) may not support the "fast" A20 method.

This function can return, so you need to use CALL instead of JMP here. You can declare the function with extern "C" to prevent name mangling.

The HLT instruction does not permanently stop the CPU. You must use an infinite loop with HLT inside it to stop the CPU.

Wow thanks. I went and changed everything you pointed out and then it worked! I'm so glad I finally got this working on both emulators and normals pcs now. Now I just have to fix the memory allocation bugs I caused when trying to troubleshoot things, believe it or not I had it working well enough to survive every string parse test I could throw at it but now substrings are messed up again. I'll get it fixed eventually though. I pretty much made the memory allocator without doing research beforehand. I don't know if you saw but it all runs off of a vector-like dynamic data type and that data type has special parameters so that when its being used for memory allocation, it does its own memory management and if its not being used for memory allocation (and for a string for example), it uses the already established memory management to do its stuff.

Thanks again for all the suggestions.