OSDev.org

Hi,

rdos wrote:

Brendan wrote:Find me a laptop made this year that has a serial port. It should be very easy to find one if serial ports aren't optional.

Laptops are not used in unattended systems. Laptops are for typical "desktop" uses.

I wasn't talking about existing unattended systems (and was talking about "all 80x86 systems in general"). In my experience, most modern desktop systems and most modern laptop systems do not have serial ports. They are optional.

rdos wrote:

Brendan wrote:So you're saying that a hardware manufacturer wouldn't need to pay for a programmer to implement support for the PIT emulation that nobody will ever want or use for UEFI?

No, because those things are already part of the BIOS they purchase. UEFI or not.

Hardware manufacturers don't pay for "a BIOS". Typically firmware is modular (e.g. you might have an initialisation/configuration module, an "UEFI module" and a "BIOS module"). Hardware manufacturers pay someone like Award to customise existing modules to suit the specific product and then probably pay "per unit sold" licence fees on top of that. For a system designed for "UEFI only" with no BIOS compatibility at all; these costs can be minimised by removing unnecessary trash (like PIT emulation).

What I'm expecting is actually a progression. At the moment we've got systems that support UEFI and BIOS. Soon (maybe in 2 years, earlier for things like tablets) we'll have systems that only support UEFI where remnants of old legacy hardware (e.g. A20, PIC, etc) still exist in the chipset. After that (maybe in 5 years, earlier for things like tablets) the chipset itself will be streamlined and things like A20, PIC, PS/2, PIT, etc will be removed from the chipset.

Things that don't actually exist now (that are only emulated - e.g. PS/2) will be the first to disappear. When the firmware is being customised to suit the hardware, it'll be a "cut" that isn't followed by a "paste". This includes PIT emulation.

rdos wrote:

Brendan wrote:In your experience there were many AHCI implementations (broken or otherwise); and this is proof that AHCI doesn't exist in hardware?

In my experience, SATA discs operated in IDE mode work far better than SATA discs operated with AHCI. Obviously, this also is the case when used with Windows 7, otherwise Compaq would not have changed from AHCI to IDE on their CQ57 laptop.

Let's create a summary. I suggested that future "UEFI only" systems won't bother with IDE/ATA and will only support AHCI; and you claim I'm wrong and suggest that some (which isn't all) existing systems (which aren't future "UEFI only" systems) still use IDE/ATA?

As I said to begin with; at the moment hardware manufacturers do still care about Windows XP compatibility. Windows XP is so old that it doesn't support AHCI out of the box (if I remember right, you have to give the OS installer an AHCI driver that isn't included, just to get Windows XP installed on AHCI).


Cheers,

Brendan

Owen wrote:

Brendan wrote:Keyboard controller - already optional. Lots of new hardware doesn't have one, and it's emulated via. SMM and USB devices. This emulation isn't needed on UEFI.

And lots of hardware doesn't have one, and uses the keyboard controller I/O ports to talk to the embedded controller (Hey, it's already built into the chipset!). If ACPI says there is no keyboard controller, there is no keyboard controller, and ignore that at your peril

Is this an issue for bootsector code setting the A20? I also have code in my MBR which uses the keybord ports to get input instead of going through the BIOS (though I can easily change that if necessary), so is that a danger to some machines or are they intelligent enough to emulate it or refuse to run code that isn't GPT?

DavidCooper wrote:Is this an issue for bootsector code setting the A20?

I tested in my macbook, setting A20 with OUT to keyboard controller and you will never get an response, no immediate harm observed.
For this reason I changed my boot code to use BIOS service, which on macbook it's implemented as rEFI's BIOS emulation.

DavidCooper wrote:

Owen wrote:

Brendan wrote:Keyboard controller - already optional. Lots of new hardware doesn't have one, and it's emulated via. SMM and USB devices. This emulation isn't needed on UEFI.

And lots of hardware doesn't have one, and uses the keyboard controller I/O ports to talk to the embedded controller (Hey, it's already built into the chipset!). If ACPI says there is no keyboard controller, there is no keyboard controller, and ignore that at your peril

Is this an issue for bootsector code setting the A20? I also have code in my MBR which uses the keybord ports to get input instead of going through the BIOS (though I can easily change that if necessary), so is that a danger to some machines or are they intelligent enough to emulate it or refuse to run code that isn't GPT?

You'll generally hang or crash them.

This is when booting an OS via the Mac's BIOS emulation layer (which will have the semi=comedic effect of causing it to call your OS "Windows")