Garrett: Why ACPI?

Posted Nov 6, 2023 11:08 UTC (Mon) by farnz (subscriber, #17727)
In reply to: Garrett: Why ACPI? by Hunterprocrasinates
Parent article: Garrett: Why ACPI?

No, I'm not - I'm saying that you need something that knows details like "you must delay 0.1 ms between enabling the DRAM voltage regulator and trying to access DRAM" that are completely specific to the hardware, and on x86-64 and SBSA ARM systems, that something is UEFI + ACPI.

The alternative is OS-specific drivers; would you prefer it if, instead of your ASUS, Dell, or Lenovo motherboard coming with a UEFI and ACPI, it came with a minimal Windows install embedded in the motherboard flash that was just functional enough to start "real" Windows and hand over hardware knowledge? That is the alternative that's been used in the past, and the result was that alternative OSes for that hardware had to somehow pick up all the details of how the hardware worked - which was different for each and every device. BIOS manufacturers are imperfect, but they're better than saying that you don't have a BIOS, you have a subset of Windows embedded in your system, and the only thing it can boot is Windows.

Garrett: Why ACPI?

Posted Nov 6, 2023 12:28 UTC (Mon) by Hunterprocrasinates (guest, #167806) [Link] (6 responses)

I agree. There are some things that would be better handled by UEFI/BIOS(why is saying UEFI so werid compared to bios lol) However there are a lot of stuff that UEFI handles that would be better handled by the OS. Even putting aside all of that there still are a lot of bugs with UEFI

Garrett: Why ACPI?

Posted Nov 6, 2023 12:31 UTC (Mon) by Hunterprocrasinates (guest, #167806) [Link]

I think alot of this comes down to the vendor to be honest rather than AMI/Phoniex. I believe they still use Microsoft ML to compile and dont give enough info besides some help files. However, I don't know, as it's been a while since I've viewed the source.

Garrett: Why ACPI?

Posted Nov 6, 2023 14:11 UTC (Mon) by farnz (subscriber, #17727) [Link] (4 responses)

What, exactly, does UEFI handle that would be better handled by the OS? Without a concrete example, it's hard to judge what you're saying; but I'd note that my system has nothing in use right now that's handled by UEFI after it loads the kernel.

Garrett: Why ACPI?

Posted Nov 10, 2023 13:55 UTC (Fri) by Hunterprocrasinates (guest, #167806) [Link] (3 responses)

Acpi is what

Garrett: Why ACPI?

Posted Nov 10, 2023 13:58 UTC (Fri) by farnz (subscriber, #17727) [Link] (2 responses)

What about ACPI would be better handled by the OS?

ACPI is a set of data tables the OS interprets to tell it how to do useful things (like enter suspend-to-RAM state, or find the PCIe Root Complex registers). If we got rid of it, the OS would have to have all of these details hard-coded for every single platform that the OS wishes to support - and you simply wouldn't be able to boot if no-one had hard-coded the right details for your motherboard + CPU combination into the OS.

Garrett: Why ACPI?

Posted Nov 11, 2023 2:55 UTC (Sat) by Hunterprocrasinates (guest, #167806) [Link] (1 responses)

I don't know why but this comment keeps magically getting deleted.

Fine you win. I don't know who to blame anymore. I'm sick of firmware bugs on other computers besides thinkpads. I Don't want to spend 7000$ on the newest linux laptop and I cant spend my money on a cheap modern computer because they are riddled with firmware bugs that affect linux.

Garrett: Why ACPI?

Posted Nov 13, 2023 12:17 UTC (Mon) by farnz (subscriber, #17727) [Link]

Underlying this is firmware bugs, not ACPI or UEFI issues; if we replace ACPI or UEFI with something else, you'll just get a different set of buggy firmwares.

This is clear when you look at some of the crap that got put out there for OpenFirmware systems, and for platforms without a standard firmware like the Acorn platforms; they often could only boot one OS reliably, because the firmware authors "knew" that they would only run that OS.