long mode

[bill_dozer]

I know i have asked alot of question and not yet answered any-but this is because im new to the subject of OS development. So please help and bare with me being on the forum.
My questions are can a bootloader put one directly into longmode without have to go through pmode?
And how will the GDT/IDT be different in longmode?
Also Should i program the IDT & GDT befor working on memory management or after?

[Kemp]

I know i have asked alot of question and not yet answered any-but this is because im new to the subject of OS development. So please help and bare with me being on the forum.

Usually being polite is all that is required

My questions are can a bootloader put one directly into longmode without have to go through pmode?

"Protected mode must be entered before activating long mode." -- AMD64 docs, volume 2.14.4

See here for a lot more info.

[bill_dozer]

That was a perfect answer an a usefull page, i dont understand though this portion-

The steps for enabling long mode are

* Disable paging
* Set the PAE enable bit in CR4
* Load CR3 with the physical address of the PML4
* Enable long mode by setting the EFER.LME flag in MSR 0xC00000080
* Enable paging

Becuae it starts off saying to " disable paging" is it safe to assume that the guide doesnt think we are going to boot our kernel instantly into longmode when the computer is turned on..or am i not getting something

[Brendan]

Hi,

That was a perfect answer an a usefull page, i dont understand though this portion-

The steps for enabling long mode are

* Disable paging
* Set the PAE enable bit in CR4
* Load CR3 with the physical address of the PML4
* Enable long mode by setting the EFER.LME flag in MSR 0xC00000080
* Enable paging

Becuae it starts off saying to " disable paging" is it safe to assume that the guide doesnt think we are going to boot our kernel instantly into longmode when the computer is turned on..or am i not getting something

The "disable paging" part just mean that you need to make sure that paging is disabled before the next steps are done, which is likely to be the case for boot code anyway.

The suggested algorithm for minimal boot code would be:

• Real mode BIOS entry
  Do real mode setup (set segment registers and temporary stack)
  Load rest of boot code
  Do anything else that must be done in real mode (get memory map, etc)
  Disable interrupts
  Load GDT and IDT
  Enable protection by setting the CR0 flag
  Initialize the protected mode environment (set segment registers and temporary stack)
  Set the PAE enable bit in CR4
  Load CR3 with the physical address of the PML4
  Set the EFER.LME flag in MSR 0xC00000080
  Enable paging by setting the CR0 flag
  Initialize the long mode environment (set segment registers and temporary stack)

I'm also not too sure how much this could be optimized. I'd like to try something like:

• Real mode BIOS entry
  Do real mode setup (set segment registers and temporary stack)
  Load rest of boot code
  Do anything else that must be done in real mode (get memory map, etc)
  Disable interrupts
  Load GDT and IDT
  Set the PAE enable bit in CR4
  Load CR3 with the physical address of the PML4
  Set the EFER.LME flag in MSR 0xC00000080
  Enable paging and protection by setting both CR0 flags
  Initialize the long mode environment (set segment registers and temporary stack)

I don't believe the AMD documentation ("Protected mode must be entered before activating long mode.") and wouldn't be surprised if AMD actually meant "you can't use long mode without protected mode enabled" instead. Unfortunately I don't have a 64 bit CPU to test it on (and wouldn't rely on emulators to be too exact, as both QEMU and Bochs have only recently added 64 bit support).

If I did have a 64 bit CPU I would test the optimized algorithm, as it'd avoid the need to setup a protected mode environment first.


Cheers,

Brendan

[Pype.Clicker]

now, as far as i can tell, AMD just require to "set up protected mode", but they don't require _fully operational_ protected mode. So if i were asked, i'd say if you keep interrupts disabled, you could wonderfully ignore the "setup IDT" step.

Moreover, it's been shown again and again on this forum that you could perfectly well enable CR0 without loading a GDT first as long as you don't attempt to switch CS: the current base/limit for the current segment will still apply, so if your 64-bits paging setup keeps the initializing code mapped 1:1 and if you manage to fit 16 bits, 32 bits and 64 bits code altogether in a couple of sectors, you can probably make the 32bits part almost only a meaningless transition.

But i don't feel like taking over the lab's AMD64 server to check out if i'm right or not

[bill_dozer]

THanks for the imformation, but im having serious rethinking about going ahead of pmode, not because of the steps involved, but because i heard there is no way to enter graphics mode in long mode without writing specific drivers for graphics card...and one of my long term goals was to set up a gui..

[Kim]

You could write a 16bit emulator for long mode and setup vesa using the bios. Iam not sure it works, its something i read on the boards.

[DruG5t0r3]

You should start reading a little about vm86 mode =)

[Kim]

Hmm? Longmode doesn't include vm86...

[Pype.Clicker]

Hmm? Longmode doesn't include vm86...

seconding that. You'd have to fallback to protected mode to use the vm86. You could alternatively have video mode set in the bootloader (grub for instance can do this), but it may make early time debugging tedious ...

[JoeKayzA]

If you like to put the video mode setting code in kernel mode, you could consider switching back to realmode (or at least to pmode and then enable v86 there...), and then use the BIOS functions to set the video mode. Even though the performance penalty is enormous, for such an operation as setting video mode this won't be such a problem. This is _no_ option of course, when you plan to put video drivers at user level....


cheers Joe

[Kemp]

I've been thinking (not a good thing usually)... Windows has a generic VGA graphics driver (that I would guess works in protected mode as I can't imagine XP dropping to vm86 every time it needs to do graphics work), so shouldn't that mean the method of doing a lot of things is pretty standard (at least up to 640x480 or so) with the ports etc that the card owns? I've also seen a generic SVGA driver in there which I would assume means that you can pull things off at higher resolutions with a standard method as well.

Or does the documentation for that sort of thing cost too much for your average home developer?

[Pype.Clicker]

I've been thinking (not a good thing usually)... Windows has a generic VGA graphics driver (that I would guess works in protected mode as I can't imagine XP dropping to vm86 every time it needs to do graphics work), so shouldn't that mean the method of doing a lot of things is pretty standard (at least up to 640x480 or so) with the ports etc that the card owns?

Very true, but the highest you could achieve is 640x480x16 colours ... and it's ugly as hell to program, so you probably prefer to stick to text mode than enabling *that* ...
If you're still interested, check the faq for HardWareVga and you should hit code (from geezer, iirc) that does it. Both 320x200x256 and 640x480x16

I've also seen a generic SVGA driver in there which I would assume means that you can pull things off at higher resolutions with a standard method as well.

Yep. that's what VBE (VESA BIOS extensions) let you do. it usually requires VM86, though. you can get it at www.vesa.org for free.

The ultimate solution might be to support SNAP drivers (from SciTech software) and hope they will somehow be compatible with long/legacy mode.

[Dex4u]

I swich to realmode from pmode and back for vesa mode swiching in my pmode OS, so in long mode you would just swich to pmode and then to realmode and swich vesa modes, but i do not see any advantage for using long mode for tesktop OS, let alone hobby OS, may be some one could point them out .

[AR]

Larger address space (not particularly useful for most apps, except games and database software), larger registers and more registers (an additional 8 general registers, and 8 more SSE registers) would be the main ones. The lack of general registers in the x86 has always been a problem for compiler optimizations.

The CPU can also obviously handle larger numbers during integer math which is again beneficial for apps like games that would benefit from the ability to process bigger numbers faster.