Die Originaldatei war mal auf: http://dana.ucc.nau.edu/~cwl6/acpi.html Datei und Bilder sind nicht mehr online, darum stelle ich ersatzweise diese Textversion ins Netz. Hoffentlich im Sinne des Autors. Nette Intro zu "Was wo wie warum ACPI?" :-). (Eric 2/2005) (Das originale "Word, als HTML gespeichert" Layout war noch schlimmer...) RICHTIG viel Information zu ACPI: siehe auch http://www.acpi.info/ ---------------------------------------------------------------------------- Warum eigentlich ACPI? - ACPI ist eine Weiterentwicklung von APM - Entwicklung von Intel, Microsoft und Toshiba - deklariert als System Design Guide, weil das Logo von Microsoft an die Normen der Spezifikationen anknüpft - die aktuellste Spezifikation ist PC99 und erlangte ihre Gültigkeit am 01.01.1999 - hier wurde die Entfernung des ISA-Bus als für den Nutzer zugänglichen Erweiterungsbus vor und für verschiedene Systemeigenschaften der ACPI- Kompartibilität verlangt Ziel: - Implementierung verschiedenster Hard- und Software- funktionalitäten - Konfigurierung und Management von Systemfunktionen, diese voneinander unabhängigen möglich zu machen und zu vereinfachen - ACPI soll eine industrielle Schnittstellenspezifikation zwischen Hard- und Software werden ACPI Heute - ist eine für den PC und deren Komponenten ausgelegte offene industrielle Spezifikation - ACPI kann vollständig oder teilweise in ein System eingebunden werden [Image] Beschreibung Advanced Configuration and Power Interface - Schnittstelle über der Konfiguration, Systemsteuerung und Power Management - kann unabhängig von der Hardware und dem Betriebs- system arbeiten - Hardware + Motherboard angesiedelte Baugruppen werden verstanden + direkte Anbindung an PCI (Peripherical Component Interconnect) + Überwachungssensoren für Temperatur, Umdrehungszahl des Gebläses u. a. - bildet die Voraussetzung für den OSPM (OS Directed Power Managment) + Steuerung und Verantwortung für BIOS, Betriebssystem, Treiber, Anwendungssoftware - der ganz große Vorteil an diesem Zusammenarbeiten ist, das es keinerlei Beschränkungen in der Zusammenarbeiten gibt; es gibt kein Konkurrenzdenken zwischen ACPI, Vorgängern oder adequaten PM´s + BIOS Power Managment, Advanced Power Managment, PnP (Plug and Play) - PM (Power Management) wird heute nur in eine Teilmenge von PC´s integriert. Viele Hersteller nehmen aus Kostengründen Abstand von der Unterstützung, bzw. Verwendung - Algorithmen, die den Energieverbrauch steuern, sind durch die beschränkte Menge an Informationen, die dem Bios z.B. zur Verfügung stehen, nur sehr beschränkt implementierbar. Dies führt zu Ineffektivität und gelegentlichen Problemen - Das Bios ist überfrachtet, um den Anforderungen an PM zu genügen, und ist auf feste Hardwareausstattung beschränkt - Die existierende PC-Plattform überfordert die gleichzeitige und voneinander abhängige Entwicklung von Hard- und Software [Image] Zustandsmodell - Das Computer-System wird stets in einem bestimmten Zustand definiert - Der Energieverbrauch kann dadurch geändert werden, das von einem Zustand zum anderen geschaltet wird Die Zustände gliedern sich in 4 verschiedenen Kategorien: G Globale Zustände S Erläuterung s. u. C Prozessorzustände D Gerätezustände G Globale Zustände werden bestimmt durch die folgenden 6 Kriterien: - Sind Anwendungen aktiv? - Welche Zeit vergeht/darf vergehen, von einem externen Ereignis bis zur Reaktion der Anwendung (Latenz)? - Wie hoch ist der Energieverbrauch? - Ist ein Neustart des Systems erforderlich, um Betriebsbereitschaft zu erlangen? - Ist ein sicherer Ein/Aus/Umbau von Komponenten des Systems möglich? (Hier ist nicht das Hot Plugging gemeint!) - Kann der Zustand elektronisch erreicht/verlassen werden? Definition der Zustände: - G0 "in Betrieb" + Betriebssystem, Anwendungen laufen + keine Latenz + hoher (Norm-)Energieverbrauch + kein Neustart nötig + keine Manipulation an der Hardware möglich + Zustand kann elektronisch angeregt/verlassen werden - G1 "schlafend" + keine aktiven Anwendungen, flüchtige Daten bleiben erhalten + geringe Latenzzeit + Energieverbrauch niedriger als Normwert + kein Neustart nötig + keine Manipulation an Hardware möglich + Zustand kann elektronisch angeregt/verlassen werden - G2 "Soft Off" + keine aktive Software, flüchtige Daten gehen verloren + hohe Latenzzeit + Energieverbrauch gegen 0 + Neustart nötig + keine Manipulation an Hardware möglich + Zustand kann elektronisch angeregt/verlassen werden - G3 "Mechanisch Aus" + keine aktive Software, flüchtige Daten gehen verloren + hohe Latenzzeit + Energieverbrauch 0 + Neustart nötig + Hardware kann gefahrlos ein-/aus-/umgebaut werden + Zustand kann nur mechanisch angeregt/verlassen werden Gliederung von G1 in seine S-Zustände: Hier wird die Tiefe des Schlafes dargestellt. Es gibt nur einen S-Zustand der zwingend erforderlich ist. Alle anderen sind vom Systemhersteller nach eigenem Ermessen zu implementieren bzw. können weggelassen werden. Zustand S4: Hier wird ein Quickboot vorgesehen. Dabei wird der gesamte Systemkontext (flüchtige Daten, Hardware kontext, OS-Kontext usw.) in einem spezifischen Teil der Festplatte abgelegt und das System anschließend in das Soft Off geschaltet. Dazu ist noch zusagen, daß das Mechanische AUS möglich ist. Dies ermöglicht einen Systemneustart, ohne Bootvorgang. Dadurch wird Zeit eingespart, indem vom System vorhandene und gültige Daten geprüft und anschließend im Systemkontext wieder hergestellt werden. (Achtung!: hardwareseitige Veränderungen machen die Daten ungütig, daher wird vom BIOS ein Hash der Konfiguration gebildet und nach einem Umbau automatisch auf vollen Neustart statt Quickboot umgeschaltet!) [Image] C Prozessorzustände Hier wird die Leistung betrachtet, der Energieverbrauch und notwendige Kühlung beim Prozessor werden bestimmt durch 4 Zustände; - C0 + 2 Zustände (Full Speed oder Throttling) - C1 + mittels HLT-Befehl wird die CPU angehalten - C2 & C3 + sind frei implementierbar für den Systemhersteller Sie können von diesem geplant werden und müssen allerdings auch dann von ihm gewartet werden D Gerätezustände Dies sind die Zustände der im System befindlichen Geräte (Devices) [integrierte Baugruppen, Erweiterungskarten usw.] Zustandsbeschreibung: - Wieviel Energie benötigt das Gerät? - Wieviel des Gerätekontextes wird von der Hardware erhalten? - Was muß vom Gerätetreiber getan werden, um das Gerät betriebsbereit zu machen? - Wie lange dauert es, um das Gerät betriebsbereit zu machen? - D3 OFF + völlig ausgeschaltet + OS reinitialisiert die Inbetriebnahme - D0 FULLY ON + eingeschaltet vollständig betriebsbereit + Implementierung ist weitgehenst dem Hersteller überlassen Dies ist auch die Schnittstelle zu anderen Standards (PCI-Power Managment Specification), die auf ähnliche Art Zustände definiert. ACPI-Funktionsbereich Implementierung von Funktionen in Hard- und Software voneinander zu trennen, deren Funktionalitäten aufeinander abzubilden. Funktionsbereich: - System Power Management + Voraussetzung ist die geeignete HW und OSPM-unterstütztes OS + OS ist verantwortlich für Erkennung, Verarbeitung im Sinne der eingestellten PM-Politik, sowie auf aufgetretene Ereignisse zu reagieren - Geräte Power Management + Anwendung von PM-Algorithmen, Konfiguration, Steuerung und Nutzung von Geräten auf beliebige Busse, dazu sind bestimmte Standards nötig - CPU Power Management + wird nach vorgegebenen Intervallen in bestimmte Stromsparzustände geschaltet + Kontrolle hat OS - PnP (Plug and Play) - System Events + Wartung, Kontrolle und Steuerung von HW + durch System Events wurde Hot Plugging erst möglich - Batteriemanagement - Kühlungsmanagement ACPI-Hardware - es wurde versucht soviel an existierende und anerkannte Technologie & Methoden zu integrieren wie möglich - es werden besondere Spezifikationen benötigt Hardware - fixed Hardware (präzise Vorgaben werden gemacht) - generic Hardware (flexibel in ihrer Implementation) Fixed Hardware - leistungs- oder zeitkritische Funktionen - Funktionen die bei Wake-up Ereignissen benötigt werden - Crash-Recovery-Funktion (wenn der Computer abgestürzt ist, wird eine zum Ursprung zurückkehrende Funktion eingeleitet) Bsp.: CPU-Taktkontroller, PM-Timer u.a. Generic Hardware - auf die Adressen im Fixed Hardware-Bereich kann ohne weitere Unterstützung zugegriffen werden - es werden zusätzliche Treiberunterstützungen für die Ansteuerung des übrigen Bereiches benötigt - die HW (Hardware) unterliegt keinen festen Einschränkungen - Hersteller muß zusätzlich benötigten Treiber dafür selber herstellen erstellt in ASL (ACPI-System-Language) kompiliert in AML (ACPI-Machine-Language) - ACPI-Treiber werden vom AML eingebauten Interpreter in Hardware spezifische Steuermethoden umgesetzt - die Hardware bleibt unabhängig von dem OS (Betriebssystem) + die vom AML-Interpreter kompilierten Treiber werden vom OS-spezifischen ACPI-Treiber in hardwarespezifische Steuermethoden umgesetzt Funktion und Systemeigenschaften: - Power Management Timer - Power Button/Sleep Button + zur nutzerspezifischen Beeinflussung des Systems von außen - Power Button Override + zusätzliche Funktion, um den per Power Button vorgegebenen Zustand zu umgehen; schaltet den Rechner nach 4-Sekündiger Betätigung in den Soft Off Mode - RTC-Alarm + Real-Time-Clock Alarm - Legacy/ACPI-Select + definierte Umschaltmöglichkeit zwischen ACPI- und anderen Systemfunktionen - C1 Power State Softwaremodell - zuständig für das Design - Implementierung einer großen Breite von Anwendungsfällen + ermöglicht Flexibilität - es werden ACPI-Tabellen verwendet, um System-Info´s vorhandener Funktionen und Steuermethoden für diese Funktionen zu beschreiben + Listeninhalt der Tabellen für die Funktionen und Steuermethoden: - vorhandene Geräte - nicht erkannte oder nach anderen Standards zu behandelnde Geräte - sowie Fähigkeiten der jeweiligen Komponenten - Info über Schlafzustände, Energiequellen, Taktquellen, usw. - Systembeschreibungstabellen + bestehend aus mehreren Untertabellen + Grundstruktur muß im ACPI-System enthalten sein + weitere Beschreibungstabellen können vorhanden sein + Erkennung und Auswertung durch definierte Header vorgeschrieben, der eine Signatur enthält [Image] Beschreibung zu dem Fixed-ACPI-Description-Table oberste Hierarchie - Root-System-Description-Table (RSDT) durch Zeiger referenziert - RSD PTR wird vom Bios erzeugt, vom OS gesucht und ausgewertet RSDT - enthält einen oder mehrere Verweise auf andere Tabellen, die im System eine bestimmte Rolle spielen, daher immer Verweis auf Fixed-ACPI-Description-Table (FACP) vorhanden - Tabellen enthalten statische, systembedingte Informationen zu PM, sowie Zeiger Firmware-ACPI-Control-Structure (FACS) und die Diffentiated-System-Deskription-Table (DSDT) DSDT - beschreibt implementierte Systemfunktionen + PM, PnP in sogenannten Definitionsblöcken - Definitionsblöcke enthalten neben Informationen zur Ansteuerung auch AML (ACPI-Machine-Language) kodierte Steuerfunktionen Differentiated-Definition-Blocks (DDB) - bilden die Grundlage für das Funktionieren der ACPI-Funktion im System - beim Systemboot geladen und bleibt im Speicher - andere Funktionen können, müssen aber nicht geladen werden FACS - speichert vom Bios eingetragene systemspezifische Daten zu ACPI + Synchronisierung global genutzter Hardwareinterrupts FACP - hier können weiter Tabellen vorhanden sein Namensräume - Def-Blocks ist ein einheitlicher Namensraum vorgegeben + Def-Blocks werden geladen + Geräte und Methoden agieren und interagieren + sein Inhalt wird hierarchisch in die Struktur des Namensraumes eingeordnet und beim Entladen aus der Struktur entfernt + werden als logische Einheiten, Objekte betrachtet - Root des Namensraumes verzweigt zu definierten Unterräumen + logische Zuordnung zu logischen Funktionen der Objekte ist beinhaltet + Einzelobjekte können in Packages eingeordnet sein Bsp.: Datenobjekte; Methoden sind Objekten untergeordnet Methoden - werden in ASL (ACPI-System-Language) geschrieben - anschließend im AML (ACPI-Machine-Language) übersetzt - angesprochene Methoden werden direkt über das Register des OS angesprochen - Ausführung durch vorhandene ACPI-Treiber, AML-Interpreter und dem Def-Block beschriebenen Adressen abgebildet Quellen: - TU-Chemnitz http://www.tu-chemnitz.de/informatik/RA/kompendium/vortraege_98/bus/acpi.html - Firma Teleport http://www.teleport.com/~acpi/acpihtml/home.htm http://www.teleport.com/~acpi/spec.htm Autor: Carsten Landfried ii99 14. November 2000