Garrett: Why ACPI?
Garrett: Why ACPI?
Posted Nov 2, 2023 22:51 UTC (Thu) by Hunterprocrasinates (guest, #167806)In reply to: Garrett: Why ACPI? by pizza
Parent article: Garrett: Why ACPI?
you're acting like they did a good job at it. UEFI vendors like AMI still use windows ML.exe to compile everything and are riddled with bugs. They also give vendors barely any information on stuff besides code comments and like some basic windows help files(forgot what they're called) that contain like 1 page. Vendors just don't even care about firmware(I'm pretty sure some 2017 gigabyte motherboards still use AWARD BIOS!)
Posted Nov 3, 2023 15:14 UTC (Fri)
by pizza (subscriber, #46)
[Link] (3 responses)
It doesn't change the fact that there has to be _some_ way for the hardware to perform basic initialization, enumerate storage and other I/O devices, and load the operating system. On top of that, over the past 30 years we've grown accustomed to the "hardware" providing a standard mechanism to perform operations like power management, suspend, and other things that require intimate knowledge of each unique hardware design/variation.
In ARM-land, historically there has been no such standard mechanism; a unique per-design bootloader performs low-level initialization, copies the OS image from storage, and loads it. In the olden days, the OS needed to be pre-compiled for that specific design, with what was effectively a "per-design driver" that told the OS what peripherals were present and how/where they were hooked up. The major downside to this approach is that you need explicit OS support for your hardware design before it can even _boot_.
More recent ARM moved to a devicetree, where the per-design bootloader handed a generic OS image a detailed description of the hardware. The OS still had needed to have a driver for each individual component, but no longer needed a "driver" unique to each design variation. This meant you could use a generic OS image, but that OS still needed to have device drivers for every component, including the low-level platform stuff (eg PMIC or clock generators) without which the system might not be able to boot. This still tended to require a relatively modern OS image for newer hardware designs.
This is where UEFI+ACPI comes in; it standardizes the OS<->"hardware" API so that you don't need to update the OS (and/or its drivers) every time you tweak your hardware design. The OS can just invoke the generic ACPI "power down" API instead of needing to know that this design has a FooCo X4321-b PMIC, with eight different voltage regulators (controlled by a specific set of pins) that need to be shut down in a specific sequence or the board can't be powered back up again without physically disconnecting power for five minutes.
Posted Nov 3, 2023 16:02 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (2 responses)
I've done that. It's NOT NICE. And you know the old Unix error message? "Your printer is on fire"? It wasn't unknown for an innocent OS probe to let the magic smoke out of some peripheral or other - one only has to look back at X destroying VDUs by setting the wrong mode line...
Cheers,
Posted Nov 3, 2023 19:47 UTC (Fri)
by pizza (subscriber, #46)
[Link] (1 responses)
ACtually, that depends. When the hardware is designed to be safely pluggable & probable (eg USB, PCI[e], and other self-describing interconnects), probing works just fine. But trying to probe for things that weren't designed with that in mind... can lead to some nastiness.
> "Your printer is on fire"? It wasn't unknown for an innocent OS probe to let the magic smoke out of some peripheral or other
That wasn't due to probing; it was a tongue-in-cheek interpretation of (very limited) status signals that the line printer could report.
(See https://en.wikipedia.org/wiki/Lp0_on_fire )
> one only has to look back at X destroying VDUs by setting the wrong mode line...
That was due to the user supplying a display configuration that the monitor couldn't handle rather than probing, and was no different than someone manually picking a bogus resolution+refresh rate in $Other_OS. Eventually, VGA monitors gained a standard mechanism to report their capabilities (via DDC & EDID) and that remains in use today.
Posted Nov 4, 2023 17:52 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
> ACtually, that depends. When the hardware is designed to be safely pluggable & probable (eg USB, PCI[e], and other self-describing interconnects), probing works just fine. But trying to probe for things that weren't designed with that in mind... can lead to some nastiness.
I had it easy. I was just using a terminal emulator. With clueless lusers. So I had the emulator wIntegrate, some real physical Pr1me PT100s, and PT250s, Wyse, Adds3E, ...
And as I say, clueless lusers who just refused to know what was going on. Fortunately, I discovered that <ESC>E (iirc) was the standard "ask the terminal to send an answerback" code. I don't think it's universal, I was lucky that it was on all the physical terminals, and I could program the emulator to respond.
So I coded the login shell to send <ESC>E, listened for the response, and set the appropriate terminal type. Still broke regularly, but at least I wasn't repeatedly fielding calls from users who'd selected the wrong terminal type and wondered why their screens were all messed up.
(Likewise, the shell chose the user's default printer based on their department, and as much automation as I could manage to try and suppress all the grief lusers cause ... :-)
You don't want to go there, if you can avoid it ...
Cheers,
Garrett: Why ACPI?
Garrett: Why ACPI?
Wol
Garrett: Why ACPI?
Garrett: Why ACPI?
Wol