OSDev.org

I remember I saw it somewhere in the main page, but can't find it anymore

Can anyone please advice (or link maybe?) what are the things need to be done before getting into PMode? Maybe things like information that can be obtain in Real Mode easily, but need trivial implementation in PMode, settings, etc...

Very mush appreciated.

Now, as to HOW to get into protected mode, you need to set the lowest bit of the cr0 register to a 1. You also need to setup a new GDT and load the segment registers with the new offset in respect to the GDT. Then you can far jump into your protected mode code. As to stuff you should get prior to protected mode, memory detection is a BIG one, as the only alternatives are GRUB (then why are you in real mode then?) or direct probing (which is about as safe doing as dealing with nitroglycerin). You might also want to set video modes if you are planning to do a graphical UI.

Here is a link if you need more information on how to get to protected mode:

http://wiki.osdev.org/Journey_To_The_Protected_Land

Hi,

tongko wrote:Can anyone please advice (or link maybe?) what are the things need to be done before getting into PMode? Maybe things like information that can be obtain in Real Mode easily, but need trivial implementation in PMode, settings, etc...

Things that you might want to do before discarding the pre-boot environment may include:

• Get a map of the physical address space (not just which areas are usable RAM)
• Get a list of video modes that are available during boot
• Get the monitor's EDID
• Set a video mode
• Get a list of disk drives present and (for BIOS) their "virtual cylinders, heads, and sectors" information (so you can correctly create the old CHS values in partition tables after boot without guesswork, and know which devices are which "BIOS device number")
• If you booted from disk, try to determine which disk drive you booted from (e.g. so the OS can update itself reliably, even when there's 2 or more versions of the same OS installed)
• If you booted from network, get networking information for the network card you booted from (the card's MAC address and IP address, plus the DNS server's IP address, TFTP server's IP address, etc) so that you can avoid doing (relatively slow) DHCP negotiations a second time if/when possible
• For BIOS; determine which PCI access mechanism the motherboard uses (it's best to ask the BIOS to avoid manual probing)
• For BIOS; enable A20 (best to ask BIOS to do it and fall back to less reliable methods if the BIOS won't)
• For BIOS; if you might be planning to use long mode (even if you don't know that you definitely will use long mode); call the "int 0x15, eax = 0xEC00" BIOS function to tell the BIOS your intentions. Note: Most people forget this, and nobody knows why it exists, but it's something you are supposed to do (according to at least some of AMD's "BIOS and Kernel Developer's Guides").
• For UEFI; get the addresses of significant tables (ACPI, SMBIOS) because UEFI tells you where they are and (unlike BIOS) you don't have to search for them
• Load the kernel and/or whatever (boot image, "initrd")

Note: If you gather all the information and present it to the kernel in the same way for both BIOS and UEFI, and start the kernel in the same way for both BIOS and UEFI; then the kernel (and remainder of the OS) can be "firmware independent" (e.g. exact same kernel binary, etc. used for both BIOS and UEFI systems).


Cheers,

Brendan

Brendan wrote: [*]For BIOS; if you might be planning to use long mode (even if you don't know that you definitely will use long mode); call the "int 0x15, eax = 0xEC00" BIOS function to tell the BIOS your intentions. Note: Most people forget this, and nobody knows why it exists, but it's something you are supposed to do (according to at least some of AMD's "BIOS and Kernel Developer's Guides").

Is this in the wiki? I've never even heard of this.

If you get a chance, maybe you should add it to the Long Mode page.

Brendan, that list looks really helpful. I didn't see any wiki pages covering this question, so I've started writing up your post as a wiki page here. It's still a work in progress, but hopefully it can become a useful page and be moved to a proper wiki page.

SpyderTL wrote:

Brendan wrote: [*]For BIOS; if you might be planning to use long mode (even if you don't know that you definitely will use long mode); call the "int 0x15, eax = 0xEC00" BIOS function to tell the BIOS your intentions. Note: Most people forget this, and nobody knows why it exists, but it's something you are supposed to do (according to at least some of AMD's "BIOS and Kernel Developer's Guides").

Is this in the wiki? I've never even heard of this.

If you get a chance, maybe you should add it to the Long Mode page.

It's for telling the firmware which processor mode the OS will run in. It's only for performance; nothing will break if you won't call it. As far as I know, it's only AMD requires this. Here are the values you can pass to BL:

• 01h: Legacy mode (real, protected); default assumption
• 02h: Long mode
• 03h: Mixed mode (long mode and legacy)

And here are the return values:

• AH = 00h: EC00h supported, AH = 86h: EC00h not supported
• CF = 0: BL value supported, CF = 1: EC00h not supported or BL value reserved, in which case defaults to legacy mode

Go ahead an put it on the wiki, if you want.

Hi,

Love4Boobies wrote:It's for telling the firmware which processor mode the OS will run in. It's only for performance; nothing will break if you won't call it.

I honestly don't know what the point of the function is (e.g. why the firmware needs to care which CPU mode the OS will be using). However; I wouldn't necessarily assume that everything will be fine if software that uses long mode doesn't use this function. For a simple example, maybe the firmware's SMM code assumes that it's OK to clear the highest 32-bits of 64-bit registers (unless the OS says it may be using long mode).

Note that AMD's documentation uses the word "must". Specifically:

• "The default operating mode assumed by the BIOS is Legacy Mode Target Only. If this is not the target operating mode, system software must execute this callback to change it before transitioning to long mode for the first time. If the target operating mode is Legacy Mode Target Only, the callback does not need to be executed."

Also be warned that calling this function at the wrong time may also cause problems. A while ago (maybe a few years ago) someone on IRC disassembled their BIOS to try to figure out what it actually does do (for their system) and found that it messes with various parts of the chipset, resetting various things and re-configuring parts of the memory controller. What this means is that if your boot code detects and configures various things, then calls the function and enters long mode afterwards; the information you detected may no longer be valid and the things you configured may be "de-configured"; and there's no real way to know what those "various things" may be.

Finally; in some cases it can be impossible for code capable of calling the BIOS function to know which mode/s the OS might use. For an example of this, my boot code typically has a "firmware independent, OS independent" stage (where it decides which kernel to use after the code stops using the firmware); and some OSs have a "fast reboot" feature (e.g. kexec) where a 32-bit OS may start a 64-bit OS (or a 64-bit OS may start a 32-bit OS) directly without any firmware involvement. For these cases the only possible option is to tell the firmware "Mixed mode (long mode and legacy)" and hope the BIOS doesn't return an "unsupported target" error.


Cheers,

Brendan

AMD seems to have only documented this "Target Operating Mode Callback" in the original AMD NPT (K8/Hammer) BKDG, but it has been excluded from all succeeding guides, I've personally checked the Family 10h, 14, 15h, and 16h BKDG's.

While not an officially deprecated function, it certainly isn't mandatory. I know at least OpenBSD does not call it.. and a superficial glance suggests FreeBSD doesn't either.

Hi,

Brynet-Inc wrote:AMD seems to have only documented this "Target Operating Mode Callback" in the original AMD NPT (K8/Hammer) BKDG, but it has been excluded from all succeeding guides, I've personally checked the Family 10h, 14, 15h, and 16h BKDG's.

While not an officially deprecated function, it certainly isn't mandatory. I know at least OpenBSD does not call it.. and a superficial glance suggests FreeBSD doesn't either.

Even if it was deprecated on new hardware, it would still be mandatory on old hardware (e.g. on AMD Family 0Fh).

Linux does calls it. I have no idea why OpenBSD and FreeBSD are more buggy than Linux.


Cheers,

Brendan

Brendan wrote:I have no idea why OpenBSD and FreeBSD are more buggy than Linux.

I'd consider firmware unable to cope with mode changes broken. There's many people still running OpenBSD/amd64 on the early Athlon64 boards without problems, AMD even loaned processors to developers before it was generally available.

In the real world, I imagine there are significantly more systems that misbehave executing this interrupt than it was ever really intended to help.

Your claims that BSD is more "buggy" seems a well-earned title, OpenBSD enables by default several features that expose bugs in the operating system and the larger software ecosystem. A lot of those get fixed because of it, which I suppose makes Linux "less" buggy, today.

Hi,

Brynet-Inc wrote:

Brendan wrote:I have no idea why OpenBSD and FreeBSD are more buggy than Linux.

I'd consider firmware unable to cope with mode changes broken.

I'd consider firmware that's unable to cope with mode changes broken too; but almost all firmware is broken in one or more ways. From my perspective it's about minimising risk - there's virtually zero risk involved in using the BIOS function when it's not necessary, and much higher risk involved in failing to use the BIOS function if/when it is necessary.

Brynet-Inc wrote:There's many people still running OpenBSD/amd64 on the early Athlon64 boards without problems, AMD even loaned processors to developers before it was generally available.

There's also plenty of people that eat peanuts regularly; but does "plenty of people" imply that it's always safe for everyone?

Brynet-Inc wrote:In the real world, I imagine there are significantly more systems that misbehave executing this interrupt than it was ever really intended to help.

Sadly, in the real world what really matters is whether or not Windows calls the BIOS function, and this is something I've been unable to determine. What you or I imagine doesn't help much.


Cheers,

Brendan