Which things are legacy today and not needed any more?

[gusc]

One more thing that's still bothering me - the more I read through manuals, specifications, this forum and wiki, the more I find that there are more than one way to do things and once you have this "freedom of choice" it slows everything down a bit.

For example, the APIC - you can read the IA32_APIC_BASE MSR and work memory mapped registers (if I'm not mistaken it is the same with xAPIC), x2APIC on the other hand has it's own MSRs (i.e. it's registers are MSRs). But you can also read MADT table from ACPI and work with that.

Same goes for the PCI/PCI Express. You have 2 methods:
#1 - you have 2 IO registers (CONFIG_ADDRESS at IO port 0xCF8, CONFIG_DATA at IO port 0xCFC)
#2 - memory mapped IO (which was introduced with PCI Express, but everybody says it's deprecated or something)
And (if I'm not mistaken) you can enumerate and work with PCI/PCI Express buses using DSDT table from ACPI.

So the big question here is - which of these roads will be future proof? I like to build solutions around single specification (or API), so that my code does not become a mess, thus it seems that ACPI is really the way to go. Plus if I'll get to UEFI implementation, then ACPI table is already presented to my efi_main function through EFI_SYSTEM_TABLE argument and I don't have to do the silly memory scan.

[Brendan]

Hi,

I strongly recommend you go the x86-64 route as this will make life much easier. Don't waste time trying to enable the A20 three different ways; you know you're x64, call BIOS and move on.

That is exactly the route I'm going now. For now my minimum requirements are Sandy Bridge, but maybe once I've built a fully functional OS, I might push it even further to Haswell. I'm not even targeting a general PC market, I'm targeting a specific configuration: Ivy Bridge i5/i7 with integrated Intel HD Graphics 4000 and a motherboard with the Intel Z77 chip and Intel gigabit Ethernet chip. Why all-Intel? Because of freely available tech specs and software developers manuals. It's pain to get access to specs and developer manuals of Nvidia or Realtek (Realtek, for example, requires to sign the NDA).

For CPUs, I think you should look at the differences between them. For example:

• unless you're intending to use AVX2 in your kernel, there's no point requiring Haswell and not supporting Ivy Bridge
• except for some performance improvements, Ivy Bridge doesn't support anything that Sandy Bridge didn't support, so there's no reason to support Ivy Bridge without also supporting Sandy Bridge
• unless you're intending to use AVX in your kernel, I don't think there's any point requiring Sandy Bridge and not supporting Nehalem
• except for some performance improvements, Nehalem doesn't support anything that Penryn didn't support, so there's no reason to support Nehalem without also supporting Penryn

For things like ethernet and video, your OS should support dynamically loaded device drivers. For example; you might only provide a driver for Intel's gigabit Ethernet, but that doesn't mean that you (or someone else) couldn't write a device driver for any other ethernet cards at any time.

For motherboards, ACPI means that you shouldn't need to care what the motherboard is.

Basically, if you want to make sure that your OS can only be used for one specific CPU on one specific motherboard, then it'd make a lot more sense to use the OS's licence as a way to prevent people using it on hardware you don't like for political (rather than technical) reasons.

There's just one little problem though - UEFI support, as it's still not clearly stated which mobo really supports UEFI and which doesn't. Plus the emulators. I've read that Qemu does support UEFI, but I haven't been able to set it up, and Bochs does not support UEFI, that's for sure. So, for now I'm still playing around with BIOS (just for the first few thousand instructions until I jump to Protected mode and then to Long mode) and parse everything the old way - scanning through ACPI tables in memory, etc. But I've already chosen to build it around GPT, so I wrote my custom MBR, that reads BIOS Boot Partition (the one that's supposed to hold raw boot code), which then prepares everything to gain access to other partitions. But I'd love to just skip all these initializations and start right-up in the long mode and prepare only the necessary things.

UEFI is supported by all "Sandy Bridge and later" systems. VirtualBox supports UEFI. For Qemu I didn't do anything special (just downloaded the replacement firmware, put it where Qemu expects to find its firmware and renamed it so it has the name Qemu expects).

Of course there aren't any emulators that emulate "Ivy Bridge i5/i7 with integrated Intel HD Graphics 4000 and a motherboard with the Intel Z77 chip and Intel gigabit Ethernet chip" so you'll have to do all your testing and debugging on real hardware.

One more thing that's still bothering me - the more I read through manuals, specifications, this forum and wiki, the more I find that there are more than one way to do things and once you have this "freedom of choice" it slows everything down a bit.

For example, the APIC - you can read the IA32_APIC_BASE MSR and work memory mapped registers (if I'm not mistaken it is the same with xAPIC), x2APIC on the other hand has it's own MSRs (i.e. it's registers are MSRs). But you can also read MADT table from ACPI and work with that.

For xAPIC, using ACPI to determine the local APIC's base address is more future-proof. For x2APIC there's nothing to detect (just use the MSRs documented by Intel).

Same goes for the PCI/PCI Express. You have 2 methods:
#1 - you have 2 IO registers (CONFIG_ADDRESS at IO port 0xCF8, CONFIG_DATA at IO port 0xCFC)
#2 - memory mapped IO (which was introduced with PCI Express, but everybody says it's deprecated or something)
And (if I'm not mistaken) you can enumerate and work with PCI/PCI Express buses using DSDT table from ACPI.

There's 3 ways to access PCI configuration space:

• Mechanism #1 - supported by virtually everything
• Mechanism #2 - deprecated and extremely rare before it was deprecated (I've never seen any computer that supports it)
• Memory mapped - introduced with PCI Express, and faster and better. It also increased the size of PCI configuration space (from 512 bytes of space per device to 4096 bytes of space per device).

Systems that support memory mapped PCI configuration space also support Mechanism #1 for backward compatibility; but if you use Mechanism #1 instead then you'll only be able to access the first 512 bytes of each device's 4096-byte space.

So the big question here is - which of these roads will be future proof? I like to build solutions around single specification (or API), so that my code does not become a mess, thus it seems that ACPI is really the way to go. Plus if I'll get to UEFI implementation, then ACPI table is already presented to my efi_main function through EFI_SYSTEM_TABLE argument and I don't have to do the silly memory scan.

The most future proof way is to use abstractions. For example, your kernel could provide a "read_PCI_config_space()" function that device drivers use without caring if the system supports memory mapped PCI or Mechanism #1 (or Mechanism #2); and if hardware developers feel like increasing the size of PCI configuration space to 8 KiB per device then you could support that easily without breaking all your drivers.

I'd also suggest keeping track of which CPU features you actually require. For example, if your kernel does require a CPU that supports AVX, then tell end users "this kernel requires AVX" (and check that all CPUs support AVX during boot). Don't select one specific CPU from one specific CPU manufacturer and fail to support CPUs that have everything you need for no reason at all.


Cheers,

Brendan

[gusc]

OK, it seems that I'll play around with ACPI a little bit more, so that I won't go crazy, trying to read through more than 2 different manuals that are around 3k pages long.

xAPIC from MADT
PCI Express from MCFG
shutdown/suspend and some more info about the hardware from DSDT

Also, I found out here, that I don't have to write a fully fledged AML parser or use ACPICA (I'm scared of large chunks of unknown code or reference implementations) to read from DSDT bytecode.

Thanks again, Brendan! That was really helpful.