Garrett: Why ACPI?

Posted Nov 2, 2023 22:51 UTC (Thu) by Hunterprocrasinates (guest, #167806)
Parent article: Garrett: Why ACPI?

ive said this for years about uefi.

The more we grant UEFI control over the OS, the worse the OS becomes. UEFI has proven itself multiple times that it isn't capable of handling things. Taking more control away from the OS and giving it to UEFI results in a worse OS. Back during the BIOS era, things weren't great either as there was no standard. However, at least the OS had almost complete control over things, meaning that if something went wrong, it was the operating system's fault. Now, with UEFI, the OS has less control over the system, and hardware is managed more by UEFI than the OS. Since UEFI firmware never fully hands control to the OS or disappears like BIOS does, if the UEFI firmware encounters a problem or error, the entire OS comes to a halt, even if the OS is well past the boot-up or login page. We need to return to a time when if the OS crashed, it was purely due to the OS's inability to handle the hardware or some bug that could be fixed with a simple kernel patch.

Garrett: Why ACPI?

Posted Nov 3, 2023 0:06 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (28 responses)

UEFI disappears to just the same extent that BIOS does. Both offer runtime interfaces, and neither does anything if you don't call them.

Garrett: Why ACPI?

Posted Nov 3, 2023 0:41 UTC (Fri) by Hunterprocrasinates (guest, #167806) [Link] (27 responses)

The problem is that the runtime interfaces vary greatly from vendor. some motherboards suffer from a broken uefi implantation(the vendor didn't care enough) and are really buggy(they just barely work for windows) This can make Linux almost unusable and there's nothing the OS can do about it.

Garrett: Why ACPI?

Posted Nov 3, 2023 4:22 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (26 responses)

Yeah and that was entirely true for BIOS as well. Do you have any idea how bad APM implementations were? At runtime Linux only ever calls into UEFI if you want to modify a firmware variable, and if you're happy with BIOS levels of functionality you never need to do that.

Garrett: Why ACPI?

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

I think it's just a problem or flaw with bios and UEFI in general now that you put it like that. Its crazy how UEFI is failing from the same problems bios had.

Garrett: Why ACPI?

Posted Nov 3, 2023 14:14 UTC (Fri) by farnz (subscriber, #17727) [Link] (24 responses)

The deep fundamental is that there are details of the hardware that are unique to this system, and not part of the wider platform. If you don't have something like PC BIOS, OpenFirmware or UEFI you end up in a world where you literally have to compile your OS for the specific hardware in front of you, and you have to know exactly how the specifics of this instance of the platform are expected to behave.

This is, after all, not impossible - it's what the Commodore Amiga did, and the Acorn Archimedes range, and Old World Macs. But it means that things that we now take for granted (like the ability to replace the CPU with a newer one without replacing the OS) are no longer guaranteed to work, since the OS has to know all the details of the new hardware that didn't exist when it was written in order to be able to bring it up.

Garrett: Why ACPI?

Posted Nov 4, 2023 16:29 UTC (Sat) by raven667 (subscriber, #5198) [Link]

I still don't understand all the comments and confusion here when the most relevant example is right in the article, Android. Every SoC and every revision has a custom Linux kernel specific to just that board that can never be upgraded or changed, isn't maintained, which is hand-tweaked to be able to boot and run the hardware, so any changes if they are published are not useful for the general-purpose Linux project. It's a Linux kernel at the same level as a BIOS/UEFI/OF/ACPI for managing the low-level hardware.

The reason why this happened this way is that ARM and Android architecture did not specify any kind of standard facility to do this low-level hardware setup, they just stuffed it into Linux for expediency, where it's easy to modify, with really no consideration to the long-term maintainability of the hardware, which they'd rather sell you new hardware to get updates anyway, regardless of how wasteful of resources that actually is.

Garrett: Why ACPI?

Posted Nov 5, 2023 23:33 UTC (Sun) by Hunterprocrasinates (guest, #167806) [Link] (22 responses)

Your acting like they did a good job at doing this. In reality they didn't. Bios manufacturers like AMI and Phoenix put a "Just works on windows" philosophy. Even then there are bugs on windows because of their buggy firmware.

Garrett: Why ACPI?

Posted Nov 5, 2023 23:48 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (13 responses)

Thankfully it's generally easy to figure out what Windows is doing, ensure Linux does the same, and then get on with life. It's incredibly hard to write a specification that manages to capture every single behavioural aspect, and even if you do what do you do if someone implements it incorrectly and you end up with systems that depend on that incorrect implementation? Vendors simply aren't going to test against every OS that exists, and so you're left either raging that your laptop doesn't work or changing your OS to match the behaviour of what it *was* tested against.

Garrett: Why ACPI?

Posted Nov 5, 2023 23:57 UTC (Sun) by Hunterprocrasinates (guest, #167806) [Link] (3 responses)

fair but even then there are issues on windows due to bad UEFI implementations. Ive seen a lot of laptops and notebooks that all have some form of problem. my think pad t470 literally has a corrupted intel me firmware that displays "error sending end of post message to ME: HECI disabled , proceeding with boot" THIS IS A THINKPAD. AMI, phoenix and insyde have proven themselves that they aren't capable of handling things

Garrett: Why ACPI?

Posted Nov 6, 2023 0:30 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

ME firmware is entirely independent of ACPI and UEFI, and typically the only thing able to touch it is the ME itself. So if you've ended up with corrupt ME firmware, the overwhelming probability is that that's some form of Intel fuckup that's out of the control of anyone else.

Garrett: Why ACPI?

Posted Nov 6, 2023 0:35 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

I mean, that's true. But we don't have other hardware manufacturers. Writing BIOS/UEFI code is a complicated task, that is entirely thankless.

At least with UEFI there's a (somewhat) reference implementation that most (all?) vendors use: https://www.tianocore.org/ In particular, AMI uses it.

Garrett: Why ACPI?

Posted Nov 6, 2023 0:48 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

The only UEFI implementation I'm aware of that people might hit in the real world that *isn't* Tiano-derived is the one that u-boot provides to allow it to boot UEFI-supporting OSes on platforms that don't otherwise provide UEFI.

Garrett: Why ACPI?

Posted Nov 6, 2023 0:13 UTC (Mon) by Hunterprocrasinates (guest, #167806) [Link] (8 responses)

this should show you how little vendors care about this stuff

https://imgur.com/a/s7klWHu (ignore the nsfw warning. theres no nsfw on this page)

Garrett: Why ACPI?

Posted Nov 6, 2023 0:28 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (7 responses)

Those are fields that are supposed to be populated by system integrators - note the "System info" at the top of the first picture. "System" refers to the complete system, not just the motherboard. If a vendor integrates this board into a product they're supposed to populate it. There's a separate record for the motherboard information itself, and in the provided screenshots there's no indication that it's unpopulated.

Garrett: Why ACPI?

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

what about the hardware model in the first screenshot?

Garrett: Why ACPI?

Posted Nov 6, 2023 0:50 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (5 responses)

How does a motherboard know which system model it's integrated into without being told? The motherboard data is in a separate field that comes later in the smbios data. The app exposing that information is exposing the system information, not the motherboard information.

Garrett: Why ACPI?

Posted Nov 6, 2023 0:53 UTC (Mon) by Hunterprocrasinates (guest, #167806) [Link] (4 responses)

My old dell computer had the gpu, ram and ssd, and cpu changed, and the hardware model never changed It always remained as "Inspron 660" in the about section

Garrett: Why ACPI?

Posted Nov 6, 2023 4:31 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (3 responses)

Right, because Dell programmed the motherboard to say that. How does a bare motherboard know what system it's installed in without being told?

Garrett: Why ACPI?

Posted Nov 6, 2023 9:49 UTC (Mon) by Hunterprocrasinates (guest, #167806) [Link] (2 responses)

I'm confused at this point. What's a Bare motherboard compared to just a normal motherboard. This was the ASUS board I'm talking about/using https://www.asus.com/motherboards-components/motherboards.... This board doesn't look like its advertised as a "Bare motherboard" or generic one.

Garrett: Why ACPI?

Posted Nov 6, 2023 10:04 UTC (Mon) by zdzichu (subscriber, #17118) [Link] (1 responses)

I think by installing a motherboard in the computer you became vendor/OEM/system integrator etc. And YOU are supposed to put "Hunterprocrasinates speedy PC" in DMI fields.
Ask ASUS for API description how to do that? Internet shows this data is field-programmable (for example https://support.nextcomputing.com/hc/en-us/articles/47096...-)

Garrett: Why ACPI?

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

ok ill try that

Garrett: Why ACPI?

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

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.