OSDev.org

I want to hear your opinion on the things that you might consider legacy and skip the implementation, if for example you'd start writing a brand new OS for your brand new hardware (think something between the lines of x86_64, Sandy/Ivy Bridge, PCIe, SATA 2/3, USB 2/3).

What do you think about: ISA, PCI, PIC, PIT, IDE, USB 1.0 (UHCI, OHCI)?
What about BIOS vs UEFI?
What about ACPI - is it a total mess or you can live with it? I'm having shivers when I hear AML (I really don't like overabstraction).
What about APIC, xAPIC, x2APIC?

Arguments, like, I have a good old PCI FM radio adapter so I wouldn't drop PCI support, or I have an old PC with Pentium 3 so BIOS is cool, are not what I'm looking for.

Yo:

What about sunrise
What about rain
What about all the things
That you said we were to gain?
What about killing fields
Is there a time
What about all the things
That you said was yours and mine~~

Whether or not something is "not needed anymore" really depends on what your target level of support for hardware is. If you aren't interested in having your kernel run on a rich, wide number of diverse hardware cases, then a few of those are irrelevant.

As for ACPI, I don't view it as an overabstraction at all, and for a production level IBM-PC kernel, no you can't live without it. Actually, depending on how new your hardware is, you probably can't live without it at all, given that a lot of newer hardware will only report PCI bus-pin mappings and a good bit of other important information via ACPI.

--Peace out,
gravaera

gravaera wrote: Whether or not something is "not needed anymore" really depends on what your target level of support for hardware is. If you aren't interested in having your kernel run on a rich, wide number of diverse hardware cases, then a few of those are irrelevant.

Well if I'd say that the target level is no less than hardware released in 2012/2013, then it seems that a lot these things are irrelevant (PIC, PIT, PCI, BIOS, for example), aren't they? And that means that I should probably go UEFI and ACPI way.

gusc wrote:

gravaera wrote: Whether or not something is "not needed anymore" really depends on what your target level of support for hardware is. If you aren't interested in having your kernel run on a rich, wide number of diverse hardware cases, then a few of those are irrelevant.

Well if I'd say that the target level is no less than hardware released in 2012/2013, then it seems that a lot these things are irrelevant (PIC, PIT, PCI, BIOS, for example), aren't they? And that means that I should probably go UEFI and ACPI way.

Whereas, if you look at hardware people actually have and would be willing to install it on, I'd use BIOS, PIT, ATAPI, and USB (Plus "features")

Hi,

gusc wrote:What do you think about: ISA, PCI, PIC, PIT, IDE, USB 1.0 (UHCI, OHCI)?

ISA started being replaced by PCI in about 1995, and was almost gone entirely by 2000 (excluding very hard to find motherboards designed to satisfy a niche market of people with expensive/custom designed ISA cards that couldn't be replaced easily). For an OS (where you're simply not going to have drivers for the custom designed ISA cards anyway) supporting ISA cards doesn't make much sense unless you support hardware from 1997 ("Pentium II or older").

PCI was superceded by PCI Express (starting in about 2004). However, from software's perspective there's only minor/superficial differences (most differences are in the electronics not software), and it's hard to think of a reason not to support PCI if you support PCI Express anyway.

PIC chips got replaced by IO APIC; and supporting them doesn't make much sense unless you support hardware from about 2001 (e.g. "Pentium III or older").

The PIT got replaced by HPET and could be considered "ignorable" unless you support hardware from about 1999 (e.g. "Pentium II or older"). However, it's very easy to use the PIT chip and it makes a nice fall-back (e.g. in case there's something wrong with HPET) so I'd still include support for it anyway.

For IDE there's a progression (IDE, ATA 1, ATA 2, ..., ATA/ATAPI 8 ) where differences between "version n" and "version n+1" are minor. This makes it hard to really determine where you'd stop; unless you only support SATA/AHCI. SATA started in about about 2003 but took a while to catch on; so you'd want to support some sort of IDE/ATA/ATAPI if you support hardware from about 2007 or older.

The hardware for USB 2 relies on USB 1, so it's silly to support USB 2 without also supporting USB 1. USB 3 is still "too new". Basically, you should still include support for USB 1 even for "2013 or later" hardware.

gusc wrote:What about BIOS vs UEFI?

UEFI became mainstream (for "white box 80x86", not including Apple 80x86) with the introduction of Sandy Bridge. That was only a few years ago (2011). This means you need to support BIOS for hardware that's 2011 or older. More interesting is when support for legacy BIOS will stop. People don't seem to realise, but this has already started happening for 80x86 based tablets, so if you care about tablets you need to support UEFI now. For laptop/desktop/server it's going to take longer (my estimate is that it'll happen when consumers stop caring about support for Windows XP, which will probably be about 5 years).

gusc wrote:What about ACPI - is it a total mess or you can live with it? I'm having shivers when I hear AML (I really don't like overabstraction).

I have a "strong dislike" for ACPI. You can run a modern motherboard without using ACPI if you want, it's just that you lose a lot of things like power management, decent PCI IRQ support, etc. In theory you can write native motherboard drivers to do all of this instead (but that's a huge amount of work). Sadly, you probably want to support ACPI for hardware made after about 2000.

gusc wrote:What about APIC, xAPIC, x2APIC?

The "external local APIC chip" (82489DX) was used in some early Pentium systems, and 80486 systems. Back then multi-CPU was rare and most of those machines are dead now, so it doesn't make any sense bothering with 82489DX even if you do support 80486 systems. For x2APIC, there's backward compatibility and you can just use xAPIC instead; so you only really need to worry about x2APIC if you want to be able to support systems with 250 CPUs or more. Apart from that it just depends on which CPU/s you support, but it's not hard to support APIC and xAPIC anyway (the differences are too minor to worry about).


Cheers,

Brendan

Wow, thanks Brendan, that was quite informative!

I'm currently working on a toy project which is like a hardware+software solution, thus it's targeting single hardware configuration and an off-the-shelf one. For now it looks like Ivy Bridge, but we'll see what Intel is preparing for us this year with it's Haswell micro-architecture.

So it seems that I'll probably have to read through ACPI specs carefully then, as it seems there's no way of avoiding it.

Brendan wrote:For x2APIC, there's backward compatibility and you can just use xAPIC instead; so you only really need to worry about x2APIC if you want to be able to support systems with 250 CPUs or more.

Just an offtopic I wanted to point out. There is a Kickstarter project (Parallella) currently in development with 64 ARM cores. Well it's ARM, but as a trend, it seems that this overkill core count might be inevitable in the near future.

64 is overkill? Try your local GPU

Brendan wrote:so you only really need to worry about x2APIC if you want to be able to support systems with 250 CPUs or more

Although I can't say that MSRs are really better than MMIO, such opportunity seems to be nice.
One more interesting (although very rare) case when x2APIC is really useful: exitless interrupts and EOI handling for VMs.

Combuster wrote:Try your local GPU

No-no-no, please, don't mess massive parallel things (such as GPUs and programmable logic devices) with {multi,many}core CPUs.
Threads in GPU are totally synced (they have common clock source), so behavior of such system is very predictable and compiler can do some good work to use this power. But complete cores in most cases are almost async from each other, so it's much more difficult to use their power fully.

BIOS and 32-bit protected mode are for sure useless now.

Nessphoro wrote:BIOS and 32-bit protected mode are for sure useless now.

To you maybe? I am pretty sure you can still go out and buy a 32-bit atom processor based tablet or netbook now, and they are likely to remain this way for another 2 years at least: http://www.tomshardware.com/news/atom-b ... 19244.html

Although, personally i wish 32-bit would just go the way of the Dodo.

General market CPU's (Not Atom) are all 64 bit for a couple of years now.
EFI is much easier to work with than the BIOS, and I think for us hobby OS devers it is even better.

Hi,

gusc wrote:

Brendan wrote:For x2APIC, there's backward compatibility and you can just use xAPIC instead; so you only really need to worry about x2APIC if you want to be able to support systems with 250 CPUs or more.

Just an offtopic I wanted to point out. There is a Kickstarter project (Parallella) currently in development with 64 ARM cores. Well it's ARM, but as a trend, it seems that this overkill core count might be inevitable in the near future.

That looks interesting (especially the price!); but for real world workloads I can see a massive "RAM bandwidth" bottleneck that will probably kill performance completely. Basically, 64 CPUs all trying to share the same 1.4 GB/s link to the same DDR3 RAM chip, where all those CPUs spend most of their time stalled. 2 MiB of RAM (32 KiB per core) on the Epiphany itself is nowhere near enough to hide the bandwidth problem; and for a lot of cases I wouldn't be too surprised if it'd be faster to just use NEON on the dual core ARM A9 (which has about 10 times the RAM bandwidth) and ignore those other 64 cores.


Cheers,

Brendan

My system is targeted for x86-64 so I check for this very early (basically first thing in the bootloader). Doing so saves a bunch of headaches down the road because this also works as an implicit PC check, as we can assume now we're 2003+. I then can make the following assumptions:

1) We have ACPI (and thus E820 memory map support)
2) We have decent BIOS support (enable A20 call, Extended Disk Read calls)

That's pretty much all that's needed. Everything else can be derived from the ACPI tables. When people think of ACPI they tend to think about power management. ACPI is more like a blueprint of the PC, describing the platform architecture. "I have a RTC that's wired to I/O ports 0x70 and 0x71...using IRQ 8." Gone are the days of writing for an IBM based PCs. We write for ACPI based PCs now.

As for APIC, if you decide to go the x86-64 route then that implies you have at least an xAPIC.

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.

Opcode wrote: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).

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.