OSDev.org

requimrar wrote:I think I just did… I don't know what defines '64-bit code', but I can execute code in a 64-bit elf by jumping directly to it. Probably a bad idea though.

When you're in long mode with a 64-bit code segment, you can execute code compiled with a 64 bit compiler or assembled with some 64 bit assembler, maybe using the .code64 directive if you had some .code32 stub before.

Yes, I'm using QEMU. Is that some kind of anomaly?

Actually I never encountered such a delay in QEMU, so I don't think it's a general thing about QEMU. But it's hard to tell where this may come from.

XenOS wrote:

requimrar wrote:I think I just did… I don't know what defines '64-bit code', but I can execute code in a 64-bit elf by jumping directly to it. Probably a bad idea though.

When you're in long mode with a 64-bit code segment, you can execute code compiled with a 64 bit compiler or assembled with some 64 bit assembler, maybe using the .code64 directive if you had some .code32 stub before.

Yes, I'm using QEMU. Is that some kind of anomaly?

Actually I never encountered such a delay in QEMU, so I don't think it's a general thing about QEMU. But it's hard to tell where this may come from.

I see, thanks for clarifying. Anyway, now that I've gotten a call-able function pointer to my kernel, I'm just going to work on my PMM for now.

Just a question: Say the kernel wants to be loaded at 0x002F0000. However, that space is either
a. Reserved (Type 2) or
b. Non-existant.

Should I
a. Screw what it wants, and just shove it in whatever nook and cranny I have for free memory, or
b. Figure out relocations and stuff?

I'm thinking A… but of course it doesn't seem right.
One last question: GRUB says my kernel is about 2MB+. That doesn't seem right, given that

a. My ASM file is just 1 BITS directive, one extern and one global directive, a section marker, a label, a cli, a hlt and a call instruction, and

b. My C file is a void main(), setting an int pointer to 0xB8000, writing A to 0xB8000 and 0x0F to 0xB8001…

Why?

Force the page size to 4 kb

requimrar wrote:Just a question: Say the kernel wants to be loaded at 0x002F0000. However, that space is either
a. Reserved (Type 2) or
b. Non-existant.

Should I
a. Screw what it wants, and just shove it in whatever nook and cranny I have for free memory, or
b. Figure out relocations and stuff?

For me it is simple, refuse to boot; and nobody complaint so far (well, I have zero user base, and chances for any user with such machine is so remote that it's not justified to support it).

requimrar wrote:Just a question: Say the kernel wants to be loaded at 0x002F0000. However, that space is either
a. Reserved (Type 2) or
b. Non-existant.

Should I
a. Screw what it wants, and just shove it in whatever nook and cranny I have for free memory, or
b. Figure out relocations and stuff?

Link it at 0x00100000 instead, so you can have more machines on which it works. Although being unable to fit your kernel within the first 4MB of RAM indicates other problems and "no" is also an answer.

One last question: GRUB says my kernel is about 2MB+. That doesn't seem right

Well, with your post count, I would expect you'd be able to give a better description than that? If the end result is not what you expect, break the process up into the individual steps. Know your tools. Check your actual filesizes on disk and use objdump to find out what's actually stored as metadata within the files.

Combuster wrote:

requimrar wrote:Just a question: Say the kernel wants to be loaded at 0x002F0000. However, that space is either
a. Reserved (Type 2) or
b. Non-existant.

Should I
a. Screw what it wants, and just shove it in whatever nook and cranny I have for free memory, or
b. Figure out relocations and stuff?

Link it at 0x00100000 instead, so you can have more machines on which it works. Although being unable to fit your kernel within the first 4MB of RAM indicates other problems and "no" is also an answer.

One last question: GRUB says my kernel is about 2MB+. That doesn't seem right

Well, with your post count, I would expect you'd be able to give a better description than that? If the end result is not what you expect, break the process up into the individual steps. Know your tools. Check your actual filesizes on disk and use objdump to find out what's actually stored as metadata within the files.

I *am* linking at 0x00100000, So no problems there. It's a theoretical question, but I get your point.

My post count… I never looked at that I'm taking a break from that currently, but I'll get to work soon enough.