OSDev.org

OT
is this a topic about pae and 386???????????
no i isn't.

Yes, run away from the challenge, I'm sure things will only get easier from here.
That bloody Dallas chip with the integrated battery? Yeah, that is a PITA to work around; I have seen people use a dremel very creatively to get at the battery (and then solder in a CR1820 battery holder).
Well, I had briefly considered a 32-bit OS, and then looked at PAE and non-PAE paging and noticed that supporting both would basically be twice the work, due to the details being just different enough so that an abstraction in code is either not possible or horribly slow. However, then I decided to just start on 64-bits, and that obviated the need for a decision. The jump to 5-level paging won't be nearly as far.
You know, I was on board until you gave me the finger. That's just obnoxious. Beyond that, it does happen that conversations evolve. You do not have a monopoly on on-topic answers here.

Your OS won't work with UEFI, since there's no text mode in UEFI.

Sure. Ditch Multiboot and go with a better boot protocol instead.

Developing in 16-bit real mode is already outdated and quickly gets harder and harder to do. UEFI systems that don't support compatibility booting (for example, your real machine), won't run your 16-bit code. Bootloaders are overrated and give a bad impression of operating system development

This might be true with onboard graphics, but with add on cards there is usually no problem, the only difference being that you have to load and initialize the option ROM yourself.

If you can figure out how to load and initialize an option ROM by yourself, you can figure out how to use a linear framebuffer to emulate text mode. (Plus, new display adapters often don't include a legacy ROM anyway.)

...Although, if you're really serious about running option ROMs, it's usually possible to extract the onboard device ROMs from the BIOS ROM...

All multicore x86 processors need to be able to run 16-bit real mode code. That's because UEFI will only boot your BSP processor, and so you need start the AP processors yourself, which need to go through real mode. So just forget that Intel or AMD will be able to get rid of real mode. Won't happen anytime soon.

I have boot loaders for at least four different boot modes:
* I can boot from 32-bit UEFI
* I can boot from 64-bit UEFI by switching back to compatibility mode and turn off long mode & paging
* I can boot with BIOS through real mode
* I can boot with multiboot (GRUB).

Just limiting oneself to only one mode seems a bit problematic to me.

Initializing option ROMs is pretty easy. If I remember it properly, you just call a fixed address of the ROM (in real or V86 mode). I think it is offset 3, but I'm not sure. It's in the BIOS manual that I still have somewhere...

ACPI is just software, so they might still use real mode to implement it.

I would want to see such a method in Intel's or AMDs processor manual...

Anyway, even if it would be required to start APs in long mode, I can still switch them back to compatibility mode and turn off long mode to make them run 32-bit code. 32-bit compatibility mode won't disappear anytime soon, and neither will protected mode (they are basically the same).

You also need a BIOS.


Sure, but that means the OS doesn't need to use real mode anymore, and if the OS doesn't need it then the CPU doesn't need it either.

I believe you miss the point: Once there is an interface for the OS to start the APs without caring about real mode, the hardware can be changed to cut out real mode without hurting then-extant operating systems.
For now yes. A future processor that doesn't let you turn off long mode is conceivable.
No they are not. There is no support for hardware task switching in long mode (a rarely used feature, I know, and therefore a prime candidate for removal), and I was under the impression that in long mode, you needed much of the OS to be 64-bit. I honestly never considered a 32-bit compat mode OS. Meaning that a processor that doesn't let you turn off long mode would be able to cut out quite a lot of weird stuff nobody ever needs (task gates, real mode address creation), and all of those transistors could then be reused to do something useful instead.

Certainly, but it also depends on major OSes adopting to use this or later ACPI versions. I see quite a bit of lag in this area.

Only if people install these operating systems on the target hardware, and the OS developers decide to rely on ACPI for booting AP cores.



That's possible, but I can still run my 32-bit OS under long mode using compatibility mode. Done that, and it works.



Nope, only some basics like interrupt & exception handlers needs to be 64-bit. The documentation is not so clear on this, but it is possible to call 32-bit code (using far calls) from long mode both on Intel and AMD. A feature that is unlikely to be removed as long as 32-bit compat mode is supported.

Actually, the long mode paging structure is fully compatible with PAE paging (only has more levels), and so the compat mode OS can use the page tables as if it operated under PAE paging.

I originally experimented with this as part of supporting long mode applications on my 32-bit OS. I would switch the core that currently run the long mode application to long mode, and load IDT with a prefabricated 64-bit variant. I had this running on real hardware, but then decided not to continue with it.



Most of the complexity is in descriptor handling, and that cannot be removed. Even long mode requires a GDT and a code & data selector.

Uh... Once ACPI 6.4 gets supported by firmware -- which is happening pretty quickly, I'm pretty sure EDK II/OVMF already supports a large majority of it -- you bet that I'll be using it and I'm pretty sure other OSes will switch to it too when supported. It makes AP initialization significantly easier -- no need to mess about with assembly language or any of that stuff, just point the AP at a function to run and boom. I imagine it might also speed up OS startup by small margins too -- it ultimately means that, since most of the work is already done for you, all you have to do is swap out the page tables and your good to go. If I remember right its also architecture independent, unlike previous methods, meaning you can do that same strategy on any architecture that aCPI supports. But I might be wrong on that last point.