x86_64: Booting kernel

[ThymeCypher]

I successfully made a x86 kernel using the provided information on the wiki, and booted it in Virtual Box as such. Worked fine. I decided however, x86 is fairly outdated, and if I'm going to spend time developing a new kernel, I might as well use the latest technology, so I decided to switch to x86_64. Making the cross compiler went smoothly, and making the kernel, just as smooth. Now, I need a way to boot... And the documentation on this is poor. GRUB2 is terrible and finds some way to complain when trying to compile (Most of the errors are bull, such as needing applications. Low-level tools shouldn't need so many dependencies. Simple as that.) And there's no information on legacy GRUB (There's constant references to a x86 bootstrap using patched GRUB legacy... speaking of, there's the patch, and the files, but NO instructions on how to go about this process. Terrible documentation here too). Can someone just point me in the right direction on getting this kernel booted? And not to sound mean or anything, but these persistent "You need to do this" information is worthless and annoyimh; Examples and elaboration are needed, otherwise you're either just telling people things they already know, or running them into dead ends (such as how there's various statements of "you need to load a GDT", and an example of what a GDT looks like, but not the actual process of loading and using one).

[Combuster]

Last time I checked, Grub2 was still broken, don't use it.

Grub legacy works pretty well. You shouldn't need any specific patches. The only thing you have to do is bootstrapping long mode from the protected mode grub leaves you in. (and you can just as well not bother with compiling as there are tons of precompiled versions available.)

[ThymeCypher]

I've tried every way possible. I've even compiled the same 32-bit code using the 64-bit compilers with the .code32, hoping that if the loader was compiled 32-bit, things would be ok. GRUB Legacy still refuses to find/load the file: Invalid or Unsupported Executable Format.

[ThymeCypher]

Doing a bit of research, I have found objdump cannot see the headers for my kernel, but the 64-bit objdump can. This tells me that GRUB probably can't see them either, and that's the problem.

[Combuster]

How about specifying an aout kludge in the multiboot header and using a flat binary output file?

[xenos]

You don't even need flat binary, 64bit ELF is pretty fine if you use an aout kludge. Just make sure it's within the first 8k of your kernel image.

[ThymeCypher]

Anyone mind pointing me in the direction on how to do that?
I'm a newb and didn't even know ASM before I started this project; but I'm a very fast learner with computers, so I figured I could jump in... I haven't found a problem without a solution yet, but I'm having a hard time finding said solutions

[JohnnyTheDon]

The call instruction pushes the return address to the stack, which is causing the triple fault and reseting your computer. You need to find someplace to put your stack. I recommend (at this stage) just putting it right after your kernel. Set RSP to the end of your kernel plus the stack size and you should be okay.

[steveklabnik]

For lots of information on how all of this works, you can see the code from our XOmB Bare Bones.

All of the documentation is here.

We end up with D, but you don't have to. The first 95% of this information will be useful to you.

[ThymeCypher]

Okay, I got it. Booting 64-bit code through GRUB using a aout kludge! One problem (This may or may not be expected), is using this code for example:

unsigned char *videoram = (unsigned char *) 0xb8000;
videoram[0] = 's';
videoram[1] = 0x07;

Despite the letter placed, it returns a dot, hex: 0xF9

Does 64-bit not handle the text buffer the same?

[ThymeCypher]

Doh! Just thought about it... 32-bit VS 64-bit... so if I'm not mistaken, instead of 1 char being 2 bytes, it's 4 now. Is there any tutorials on text output in 64-bit?

[ThymeCypher]

Nevermind, I figured it out:

videoram[0] = 'A'; // character 'A'
videoram[1] = 0x07; // White on Black

becomes:

videoram[0] = 0x0; // Padding
videoram[1] = 'A'; // character 'A'
videoram[2] = 0x07; // White on Black
videoram[3] = 0x0; // Padding

[Colonel Kernel]

Doh! Just thought about it... 32-bit VS 64-bit... so if I'm not mistaken, instead of 1 char being 2 bytes, it's 4 now. Is there any tutorials on text output in 64-bit?

You're doing this in C/C++, right? char is 1 byte, regardless of whether you're targeting 32- or 64-bit. I don't know why padding would somehow fix your problem...

[ThymeCypher]

Hm, I take that back, it's not... This is odd.

[01000101]

hmm, so what does this produce?

Code: Select all

*(char*)0xb8000 = 'A';
*(char*)0xb8001 = 0x0A;

it should be a green A on a black background. Also, are you in 80x25 text mode? maybe that 'dot' was a pixel being drawn in color mode?