how did YOU enable paging

[GLneo]

i've done nothing in months, becouse paging just won't work!!!!!!!!!!!!!!!!!!!!!!!!!!
can someone explain in detail how you set up paging???

[Colonel Kernel]

I don't have a working memory manager yet (I'm still debating how to do it ), but I have managed to enable paging. I took what I figured out and turned it into an example on the FAQ:

HigherHalfBareBones

This code won't explain much in the way of concepts, but it does work.

can someone explain in detail how you set up paging???

Why don't you explain in detail how you set up paging, then we might have an idea what the problem is.

[GLneo]

ok, first i tried setting up a liner and vutual paging table so my kernel could work at 0x1000 and 0xC0000000 but i forgot about linking [dead idea]
then i tried linking my setup code to 0x1000 and main to 0xc0000000 LD gave me unlimited truble [dead idea]
next, i tried GDT trick, cant get it to not crash instantly [dead idea]
after, i tried a second stage, i dont know enough asm to do paging/tables/directorys [dead idea]
i cant remember half of my atemps
HELP

[mystran]

My 2 cents: put your kernel at 1MB first, and figure out how to do paging. Then worry about getting your kernel to 3GB or whatever.

If you are troubleshooting both paging, and kernel relocation at the same time, you simply have too many moving parts.

[GLneo]

i've figred it out, but the broblem was only relocation

[Crazed123]

I happen to use the GDT trick, and it works fine. You link the entire kernel to its virtual destination (0xC0000000 or 0xC0100000 are the most common), have a GDT and pointer that will implement this trick set as constants in your assembler stub, set the GDT address in the assembler stub, keeping in mind that the address in the GDT pointer must be a physical address, remember to use physical addresses for anything more you have to do in assembler (like storing GRUB's boot-time information), jump into your C kernel and finally set your kernel's GDT, which continues the trick.

At last, when you have paging set up, enabled and running, change the segment registers to point to GDT entries with a zero base.

[GLneo]

thats what i did but know i'm having troble setting up paging becouse GDT trick + paging = wered result and i cant enable paging "mov cr3, ptr" and disable gdt "LGDT" in the same instruction

[Brendan]

Hi,

thats what i did but know i'm having troble setting up paging becouse GDT trick + paging = wered result and i cant enable paging "mov cr3, ptr" and disable gdt "LGDT" in the same instruction

When you setup paging, map your code at 2 different spots so that it appears at 0x1000 and 0xC0000000. Then you can change your segment registers and remove the first mapping at 0x1000.

An easier way would be to map the first 1 MB of of RAM to the first 1 MB of your address space - it's mostly the same as above but lets you access BIOS data structures too..


Cheers,

Brendan

[Freanan]

About enabling paging...
I followed the instrucions from the tutorial on osdever.net, with small changes (according to my taste).
Because i had forgotten that the adress for page dir and page tables must be 4096-byte-aligned my code crashed first. When someone told me it worked.

Another question...
What is so good about having your kernel split in two parts or having it reside at a higher memory location? What are the benefits of this?
Everyone, like linux, does it, but to me it seems like unnecessary problems. Please explain...

[AR]

The higher half kernel is mainly just a cosmetic thing, basically it's easier for the application developer to think "my program runs in 0-2GB" then for them to think "my program runs in 1-3GB". It sounds stupid when it's put like this but this is basically one of the main reason.

Of course you can achieve the same effect with segmentation (both programs and the kernel think they're at 0x0), but that isn't portable with AMD64 or any other architecture. If you don't care if it's portable or not then you can make do with segmentation.

Another reason is that if the kernel needs to get bigger than 1GB (I doubt that is likely but anyway...) then you can move the kernel's base address down without having to relink every program ever written for your OS for their new base address (Once again segmentation can avoid this as well).

[Brendan]

Hi,

Another question...
What is so good about having your kernel split in two parts or having it reside at a higher memory location? What are the benefits of this?

In addition to cosmetic reasons (already mentioned), it makes it easier to support virtual 8086 mode where the first 1 MB of the address space is used and segmentation tricks won't work.

It's also better if you've got a 32 bit application (designed for a 32 bit version of your OS) running on a 64 bit version of your OS. In this case the 64 bit kernel can let the application use from 0 to 4 GB instead of from 0 to 3 GB (or from 0 to 2 GB). If the 32 bit application assumed the kernel was at the start of the address space, then it wouldn't be able to use the entire 4 GB (without segmentation tricks, which would make it more complicated for a the 64 bit kernel to support 32 bit applications).


Cheers,

Brendan

[Freanan]

I understand..
So if i am not interrested in having applications running in virtual 8086 mode and it is no problem for me if applications have to be linked to another starting adress then 0 (which is both true, as i am doing osdev for fun and to learn, without hoping to create a kernel that is actually used by anyone at my first attempt), i do not need to care about it...

[Crazed123]

thats what i did but know i'm having troble setting up paging becouse GDT trick + paging = wered result and i cant enable paging "mov cr3, ptr" and disable gdt "LGDT" in the same instruction

I was planning just to have two 0x40000000 base segments in my GDT and otherwise it would be normal. That way, when I enable paging I can just set new segment registers (since the CPU already knows the physical address of the GDT) and keep running.

Or you can do identity paging at the start. That works really well too.