OSDev.org

For me the code seems ok, but it causes reboots.

Roman, I really don't want to sound rude or discouraging, and I appreciate you're new to all of this stuff, but you really need to start applying some basic debugging techniques, if nothing more than to narrow down your question when you post on here, to less than your entire source.

An honest tip I can give you, and one that has saved me several times, especially before I've bootstrapped properly into a reasonable environment, is to put the lines where you think the fault is happening. If the fault no longer happens, the problem is after this point. If it does, the problem is before. Repeat until you find the exact instruction that is faulting, and from there determine possible causes. Check register values, page status, etc.

To reiterate, this is difficult stuff, and I appreciate you're new to it, but many people here don't tolerate newbie questions for very long, and there are some who lose their tempers very quickly, driving people from the community (and I've seen it happen, on more than one occasion). I'd hate to see that happen again.

I've got to agree with CWood. You desparately need to learn how to debug. I can see some obvious errors just glancing at your code (for example you don't appear to disable interrupts but you don't set up a viable IDT), but it wouldn't really help you to have them pointed out one-by-one. OS development gets a lot harder than this, so take the opportunity now to learn how to track down errors.

As well as the simple debugging techniques already mentioned, consider using a full debugger to step through the code one instruction at a time. If you are using Linux one particularly good tool for doing this is SimNow from AMD. But you could also use gdb in conjunction with qemu or, I believe, Bochs has good debugging facilities. If you are not using Linux, consider doing so. I believe it provides better tools for this purpose than other environments.

To add a little something: posting 274 lines of code and asking what's wrong with it isn't much appreciated either.

What is it? Could not find it on google.

Oh really? Have you tried looking it up in the intel manuals instead? I'm sure that'll give you an even more correct answer.

Have you also considered what those three truncated lines do as a whole?

> For me the code seems ok, but it causes reboots.

Could be that long mode was not entered properly.
The problem in that case is that 64 bit addresses get truncated to 32 bit and execution ends up where you do not expect it after the long jump.

Check that EFER is 0x0000000000000500.

You can do this by printing the reigsters, If you are using Qemu press ALT+CTRL+2.
Then type "print registers".

What is it? [/b]
It's bitwise setting 0x80000001 in ebx, but also keeping what ever bits already set in the ebx register.
or meens "this or that" or "keep this and that" in ebx.

Im guessing you are refering to the tutorial lines: 1. First line copys cr0 to ebx in Intel syntax, in AT&T syntax it would move ebx register content to cr0.
2. Then make shore 0x80000001 bits are set in ebx.
3. Activate the settings by storing ebx in cr0.

cr0 is a CPU control register. 0x80000001 sets enable protected mode (bit 0 to 1) and enable paging (bit 31 to 1).
This adds up to 0x80000001 if you enter it into a hex calculator.

But please do refer to the intel manual and CR0, to understand what these and the other bits do.

Okay, you've narrowed it down to when you set CR0. That's a good start. Now, you already know that both of these bits set, respectively, paging and protected mode, and it is fairly clear that this code should be correct. So, backtrack a little, and think about what each of these, on their own, rely on. Check each of these bits of code, individually, to check the right values end up in the right place at the right time.