Traitement en cours

Veuillez attendre...

Paramétrages

Paramétrages

Aller à Demande

1. DE000010196703 - Verfahren zum Booten der Betriebsumgebung eines autonomen Untersystems in einem computergestützten System ohne Einbeziehung des Hauptbetriebssystems

Note: Texte fondé sur des processus automatiques de reconnaissance optique de caractères. Seule la version PDF a une valeur juridique

[ DE ]

Beschreibung

PATENTANWÄLTE ZENZ, HELBER, HOSBACH & PARTNER · HUYSSENALLEE 58-64 · D-45128 ESSEN
PCT/US01/30349 1835
Verfahren und Einrichtung zum Booten der Betriebsumgebung
eines autonomen Untersystems in einem computergestützten
System ohne Einbeziehung des Hauptbetriebssystems
Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich auf das Gebiet der Computer. Insbesondere bezieht sich die Erfindung auf das Booten der Betriebsumgebung eines Untersystems ohne Einbeziehung des Hauptbetriebssystems.
Hintergrund der Erfindung
Computergestützte Systeme werden zunehmend mobil. Diese Mobilität legt häufig den Schwerpunkt auf Brauchbarkeit. Brauchbarkeit wird häufig erweitert auf die Fähigkeit, die Anlage über längere Zeitspannen zu betreiben. Diese Zeitspanne steht häufig in Beziehung zum Energieverbrauch der Anlage, insbesondere bei batteriebetriebenen Anlagen. Daher kann hoher Energieverbrauch Probleme stellen.
Zahlreiche Lösungsansätze wurden zum Reduzieren des Energieverbrauchs versucht. Eine Möglichkeit besteht im Abschalten der Anlage, wenn sie nicht in aktiver Benutzung steht. Andere Lösungsansätze umfassen das Versetzen der An^ lage in verschiedene niedrigere Leistungszustände, z. B. Leerlaufmodus, Schlafmodus, Hibernationsmodus usw. Derartige Lösungsansätze können das Ausschalten von Teilschaltungen oder Komponenten, das Herunterfahren von Untersystemen und/oder des Hauptsystems, das Senken von Versorgungsspannungen, das Ändern von Taktmechanismen, das Übertragen von Daten bspw. vom Direktzusatzspeicher (RAM) zum Plattenspeieher usw. beinhalten.
Bei Ansteuerung solcher Niedrigenergiezustande kann das computergestützte System das Betriebssystem Wiederaufnehmen oder Booten. Nach dem Booten oder Wiederaufnehmen des Betriebssystems kann eine Anwendung ausgeführt werden, um Ope-
rationen durchzuführen. Die zum Booten des Betriebssystems
benötigte Zeit kann für ein Untersystem ein Problem darstellen, da es eine rasche Antwort benötigt. Die während des
Bootprozesses verbrauchte Energie kann auch für batteriebetriebene
Einrichtungen ein Problem darstellen.
Kurzbeschreibung der Zeichnungen
Die Erfindung wird anhand von Beispielen und ohne Beschränkung
hierauf anhand der Figuren der begleitenden
Zeichnungen dargestellt, in denen gleiche Bezugszeichen ähnliche Elemente bezeichnen und in denen:
Figur 1 eine vernetzte Computerumgebung darstellt;
Figur 2 ein Blockschaltbild eines Computersystems ist;
Figuren 3, 4 und 5 Blockdiagramme sind, die verschiedene Ausführungsbeispiele der Erfindung darstellen;
Figuren 6 und 7 Blockdiagramme sind, welche verschiedene Ausführungsbeispiele der Erfindung darstellen.
Detailbeschreibung
Beschrieben werden ein Verfahren und eine Einrichtung
zum Booten der Betriebsumgebung eines autonomen. Untersystems in einem computergestützten System ohne Einbeziehung des
Hauptbetriebssystems. Zum Zweck der Erörterung der Erfindung ist es verständlich, daß zahlreiche Ausdrücke von Fachleuten verwendet werden, um die Aufeinanderfolge zu beschreiben,
mit der ein System sich selbst starten kann. Ein solcher
Start wird häufig als ein Boot-Prozeß bezeichnet. Booten
kann bspw. ein anfängliches Anlegen von Spannung an das Gerät
sein, was häufig als Einschalten oder Kaltstart bezeich-0 net wird. Booten kann von einem System ausgehen, das bereits teilweise angefahren ist. Booten kann von einem völlig unter Strom stehenden System stattfinden, was häufig als ein Warmstart oder Reset bezeichnet wird. Es ist außerdem verständlich,
daß die Bootfolge die Aufnahme zusätzlicher Befehle
und/oder Daten als Ergebnis eines Stimulus, eines Betriebs-
schalters, einer Reset-Taste, eines Empfangssignals usw. umfaßt. Der Erhalt zusätzlicher Befehle und/oder Daten kann bspw. von einer Festplatte, einer Floppy Disk, einem Netzwerk, einem Flash Memory usw. erfolgen. Das Ergebnis des Boot-Prozesses besteht darin, das computergestützte Gerät in einen Betriebsmodus zu versetzen, in dem es in der Lage ist, zusätzliche Informationen und Ausführungsprogramme zu empfangen. Ein Beispiel wäre die Einschalt-Folge eines Personal Computers unter Verwendung eines Windows* Betriebssystems oder des Linux Betriebssystems.
Es ist einzusehen, das der Ausdruck Abschalten, jedoch ohne Beschränkung hierauf, das Steuern eines Geräts, Systems oder Untersystems durch vollständiges Abschalten der Energiezufuhr, teilweises Energieabschalten, Betrieb bei einer anderen Spannung, Betrieb bei einer anderen Frequenz usw. bedeuten kann. Ein Gerät, System, Untersystem oder eine Anlage, die heruntergefahren oder abgeschaltet ist, soll u. a. Verringern des Energieverbrauchs dienen. Es gibt zahlreiche Lösungsansätze zum Reduzieren des Energieverbrauchs. Das Energieabschalten, wenn die Einrichtung nicht in aktiver Benutzung ist, stellt einen Lösungsansatz dar. Andere Lösungsansätze umfassen das Versetzen der Anlage in verschiedene niedrigere Energiezustände, wie Leerlaufmodus, Schlafmodus, Hibernationsmodus usw. Derartige Lösungsansätze können das Abschalten von Teilen von Schaltungen oder Komponenten, das Herunterfahren von Untersystemen und/oder des Hauptsystems, das Senken von Versorgungsspannungen, Änderung von Taktme-.chanismen usw. umfassen.
Ein maschinenlesbares Medium wird so verstanden, daß es 0 einen beliebigen Mechanismus zum Speichern oder Übertragen von Informationen in einer maschinenlesbaren Form (z.B. durch einen Computer) enthält. Der Begriff "maschinenlesbares Medium" umfaßt bspw. einen Nur-Lese-Speicher (ROM); einen Direktzugriffsspeicher (RAM); Magnetplatten-Speichernde dien; optische Speichermedien; Flashspeichergeräte; elektri-
sehe, optische, akustische oder andere Formen von übertragenen Signalen (z.B. Trägerwellen, Infrarotsignale, Digitalsignale usw.); usw.
Figur 1 zeigt eine Netzwerkumgebung, in der die beschriebenen Techniken angewendet werden können. Wie gezeigt, sind einige Computersysteme in der Form von M Servern 104-1 bzw. 104-M und N Benutzer bzw. dienten 108-1 bis 108-N über ein Netzwerk miteinander verbunden, welches bspw. durch das Internet gebildet sein kann. Zu beachten ist, daß in alternativer Ausführung das Netzwerk 102 einen oder mehrere der folgenden Netzwerke sein oder enthalten kann: ein lokales Netzwerk (LAN), Fernnetz (WAN), eine Satellitenverbindung, ein Fasernetzwerk, ein Kabelnetzwerk oder eine Kombination solcher Netzwerke und/oder anderer. Das hier beschriebene Verfahren und die Einrichtung können auf einen beliebigen Typen von Übertragungsmitteln oder Anlagen, ob lokal oder fern, wie ein LAN, ein WAN, einen Systembus, ein Plattenlaufwerk, Speicher usw. Anwendung finden.
Figur 2 zeigt einen konventionellen Personal Computer in Blockdiagrammform, der für einen beliebigen dienten oder Server gemäß Figur 1 stehen kann. Das Blockdiagramm ist eine grob-konzeptionelle Darstellung und kann auf verschiedene Arten und mit unterschiedlichen Arten und Architekturen realisiert werden. Bussystem 202 verbindet eine zentrale Verarbeitungseinheit (CPU) 204, einen Nur-Lese-Speicher (ROM) 206, einen Direktenzugriffsspeicher (RAM) 208, einen Speicher 210, eine Anzeige 220, ein Audiogerät 222, eine Tastatur 224, einen Zeiger 226, sonstige Eingabe/Ausgabe(ΙΟ) Geräte 228 und Kommunikationen 230. Das Bussystem 202 kann bspw. aus einem oder mehreren solcher Busse, wie einem Systembus, einer Peripheriekomponentenverbindung (PCI) , einem erweiterten Grafikport (AGP), Kleincomputersystem-Interface (CSI), Institute of Electrical and Electronics Engineers (IEEE) Standardnummer 1394 (FireWire) usw. bestehen. Die CPU 204 kann ein Einzel-, Mehrfach- oder sogar ein verteiltes
Rechenhilfsmittel (Ressource) sein. Der ROM 206 kann eine beliebige Art von nichtflüchtigem Speicher sein, der programmierbar sein kann, wie maskenprogrammierbar, Flash usw. RAM 208 kann bspw. statisch, dynamisch, synchron, asynchron 5 oder irgendeine Kombination sein, Speicher 210 kann Compact Disc (CD), Digital Versatile Disk (DVD), Festplatten, optische Platten, Band, Flash, Speichersticks, Videorekorder usw. sein. Anzeige 220 kann bspw. ein Kathodenstrahlröhrenbildschirm (CRT), eine Flüssigkristalanzeige (LCD), ein Projektionssystem, Fernsehen (TV) usw. sein. Audio 222 kann eine monophone, stereophone, dreidimensionale Sound-Karte usw. sein. Die Tastatur 224 kann als Tastatur, Musiktastatur, ein Tastenfeld, eine Tastenfolge usw. ausgebildet sein. Der Zeiger 226 kann bspw. eine Maus, ein Tastenfeld, eine Rollkugel, ein Steuerknüppel usw. sein. I/O Geräte 228 können durch einen Sprachbefehl-Eingabegeräte, ein Daumenabdruck-Eingabegerät, einen Smart Card-Einschub, eine Personal Computer Card (PC Card)-Schnittstelle, virtuellen Realitätszubehör usw. gebildet sein und eine optionale Verbindung über einen Eingangs/Ausgangs-Port 229 zu anderen Geräten oder Systemen bilden. Ein Beispiel für ein alternatives I/O Gerät 228 ist eine Musikinstrument-Digital Schnittstellen (MIDI)-Karte mit dem I/O-Port 229 zum Anschluß an Musikinstrument (e) . Kommunikationsgerät 230 kann bspw. ein Ethernet Adapter für örtliche Netzwerk (LAN)-Verbindungen, eine Satellitenverbindung, ein Set-Top-Box-Adapter, ein digitaler Teilnehmerleitungs-(xDSL) Adapter, ein Funkmodem, ein konventionelles Telefonmodem, eine direkte Telefonverbindung, eine Hybrid-Faser-Coax(HFC)-Verbindung, ein Kabelmodem usw.
0 sein. Der externe Verbindungsport 232 kann eine beliebige benötigte Verbindung zwischen einem beabstandeten Gerät und dem Bussystem 202 über das Kommunikationsgerät 230 herstellen. Bspw. kann das Kommunikationsgerät 23 0 ein Ethernet Adapter sein, der über den Verbindungsport 232 bspw. mit einem externen DSL-Modem verbunden ist. Zu beachten ist, daß
in Abhängigkeit von der aktuellen Implementierung eines Computersystems das Computersystem einige, alle, mehrere oder ein Neuordnung von Komponenten im Blockdiagramm enthalten kann. Bspw. kann ein dünner Client aus einem Hand-Funkgerät bestehen, dem bspw. eine traditionelle Tastatur fehlt. Daher sind zahlreiche Abwandlungen des Systems gemäß Figur 2 möglich.
Erneut bezugnehmend auf Figur 1 sind Clienten 108-1 bis 108-N mit Webseiten, Anwendungsserviceprovidern, Suchmaschinen und/oder Datenbankressourcen, gebildet durch Server, wie Server 104-1 bis 104-M, über das Netzwerk 102 effektiv verbunden. Der Webbrowser und/oder andere Anwendungen laufen generell an den Clienten 108-1 bis 108-N ab, während Informationen generell bei den Servern 104-1 bis 104-M liegen.
Zur Vereinfachung der Erläuterung wird ein einziger Client oder Anwender 108-1 als repräsentativ für ein Ausführungsbeispiel der vorliegenden Techniken betrachtet. Es ist klar, daß solche Techniken leicht auf mehrere Clienten übertragen werden können.
In Figur 1 kann der Client 108-1 seine Bootfolge ablaufen lassen, da er die Fähigkeit hat, auf das Netzwerk zuzugreifen. Diese Fähigkeit ermöglicht das Booten oder andere Aktualisierungen aus einem Server über das Internet und/oder ein anderes Netzwerk. Eine Beschreibung des Verfahrens zum Aktualisieren oder Installieren eines revidierten Bootcodes und/oder Daten ist für das Verständnis der vorliegenden Erfindung nicht erforderlich.
Die zum Booten eines Gerätes, bspw. eines Untersystems bei der Erfindung erforderliche Information kann sich bei der Erfindung bspw. in der CPU 204, dem ROM 206, dem Speicher 210 usw. befinden. Diese. Bootinformation kann - ohne Beschränkung hierauf - aus Untersystem-Boot-Indikatoren, einem aktuellen Bootcode und/oder Daten zum Booten eines Untersystems usw. bestehen. Zusätzlich ermöglichen Zugriffe bspw. über das Kommunikationsgerät 230, das bspw. als Ether-
DE ΪΟ1"96 7'03"Τ1
net Adapter ausgebildet sein kann, den Zugriff auf ein Netzwerk, wobei die Informationen, wie ein Untersystem-Boot-Indikator und/oder eine Boot-Codeinformation abgerufen werden können.
Ein Untersystem kann - ohne Beschränkung hierauf - aus einem oder mehreren der in Figur 2 dargestellten Elemente bestehen. So kann bspw. Speicher 210 ein Untersystem haben, das die Art der Speicherung und Wiedergewinnung von Daten steuert. Audio 222 kann ein Untersystem aufweisen, das bestimmt, wann bspw. Lautsprecher abgeschaltet werden. Kommunikationsgerät 230 kann bspw. ein Untersystem haben, das bei Empfang einer Nachricht unabhängig von dem Hauptsystem gebootet werden muß.
Figur 3 ist ein vereinfachtes Blockdiagramm eines Ausführungsbeispiels. Ein Untersystem-Boot-Indikator kann ohne Beschränkung hierauf - ein Bit oder mehrere Bits an einem Speicherplatz sein,- entfernt von dem Untersystem, bspw. in einem Hauptsystem oder sogar noch weiter entfernt, wie irgendwo auf einer Internet-Webseite gespeicherte Information; ein nicht flüchtiger Speicher, wie Festplatte, DVD, Flash usw.; oder etwas besonders einfaches, wie ein Jumper über Anschlußverfahren an einem Gerät sein. Zu beachten ist, daß der Untersystem-Boot-Indikator in jeglicher Form und in jeder örtlichen Zuordnung eine Anzeige für den Bootstatus und/oder eine angeforderte Bootoperation des Untersystems darstellt. Einzusehen ist ferner, daß einzelne sowie mehrere Ressourcen den Status des Indikators oder der Indikatoren abfragen können. D. h. ein Leistungscontroller kann in einem System den Zustand eines Untersystem-Bootindikators ebenso abfragen wie ein HauptSystemprozessor oder sogar ein entfernter Anwender oder Server.. ..
Wenn der abgerufene Untersystem-Boot-Indikator 302 keine Anforderung auf ein Booten des Untersystems 3 04 anzeigt, so stehen andere Optionen 308 zur Verfügung. Bspw. kann der Untersystem-Boot-Indikator Informationen enthalten, die anzei-
• ·
gen, daß ein vorausgegangener Bootversuch erfolglos war und daß eine Korrekturmaßnahme erforderlich sein kann.
Figur 4 ist ein anderes Ausführungsbeispiel der Erfindung. Ein Bootvorgang wird bei 402 gestartet, während ein Boot-Indikator 404 abgerufen wird. Auf der Basis des gewonnenen Boot-Indikators 404 werden dann Informationen an das Untersystem 406 übertragen, worauf das System abgeschaltet wird, 408.
Das Abschalten 408 kann - jedoch ohne Beschränkung hierauf - ein Abschalten eines gesamten Systems, eines Hauptsystems, eines Untersystems usw. sein. Bspw. kann nach Übertragen der Informationen an das Untersystem 406 das Abschalten 408 ein Abschalten des Hauptsystems und Aktivhalten eines Untersystems beinhalten. Daher kann ein Untersystem bspw. Informationen verarbeiten und betrieben werden, während die in Figur 4 dargestellte Folge abgearbeitet wird.
Ein Beispiel eines solchen Ausführungsbeispiels kann jedoch ohne Beschränkung hierauf - ein HauptSystemprozessor, bspw. ein Pentium -Prozessor, sein der zum Booten gestartet, danach eine Boot-Indikator bspw. von einem Flashspeicherplatz in einem Firmware-Netzknoten abruft, danach auf dieser Basis Informationen an einen Untersystemspeicher überträgt und so das Hauptsystem herunterfährt. Die Übertragung von Informationen in solch einem System vom Hauptsystemprozessor kann deshalb notwendig werden, weil ein Untersystembetriebsmittel nicht in der Lage ist, anfänglich auf die Informationen zuzugreifen. D. h. der Hauptsystemprozessor kann nur in der Lage sein, auf die Informationen so lange zuzugreifen, wie er auf das Untersystem überträgt, worauf ein Untersystem-Betriebsmittel Zugriff haben kann. Alternativ kann eine andere Systemressource (Betriebsmittel) oder sogar das Untersystem selbst das Übertragen von Informationen durchführen, so daß das Untersystem auf die Informationen während seines Bootens Zugriff hat.
Das Abschalten des Systems kann Energie sparen. So kann bspw. der HauptSystemprozessor während eines Bootens Informationen zu einem Untersystem übertragen und sich danach selbst abschalten. Das Untersystem, das danach mit Energie versorgt ist, kann danach die vom Hauptprozessor übertragene Information zum Booten verwenden. Auf diese Weise kann der Energieverbrauch reduziert werden.
Zu beachten ist, daß bei den obigen Beispielen der Hauptprozessor die Informationen überträgt, ohne daß der Hauptprozessor ein Betriebssystem, bspw. Windows oder Linux zu laden hat.
Figur 5 ist ein detaillierteres Ablaufdiagramm nach einem Ausführungsbeispiel der Erfindung. Ein Untersystem-Boot-Indikator wird bei 502 abgerufen. Auf der Basis des abgerufenen Untersystem-Boot-Indikators 502 wird bestimmt, ob das Untersystem 504 bootet. Wenn der abgerufene Untersystem-Boot -Indikator 502 nicht anzeigt, daß das Untersystem bootet, so stehen andere Optionen 508 zur Verfügung. Wenn ein Booten des Untersystems angezeigt wird, so werden Informationen aus einem Hauptspeichersystem 506 abgerufen und danach übertragen und gespeichert an dem Untersystem 510. Das Untersystem bootet danach unter Verwendung der übertragenen Informationen 512.
Der Hauptsystemspeicher kann - jedoch ohne Beschränkung hierauf - ein Festplattenspeicher, DVD, CD, ROM, Flash usw. sein. In ähnlicher Weise kann die Speicherung der übertragenen Informationen - ebenfalls ohne Beschränkung hierauf - in einer anderen Festplatte, einem beschreibbaren Gerät, RAM, Flash usw. erfolgen,
0 Figur 6 zeigt eine Systemarchitektur für ein Ausführungsbeispiel der Erfindung. Controller 602 ist gekoppelt mit: Hauptsystem 610 über Verbindung 604; Untersystem 618 über Verbindung 608; und Untersystem-Boot-Indikator 624 über Verbindung 606. Hauptsystem 610 ist zusätzlich mit Hauptsystemspeicher 614 über Verbindung 612 und mit Untersystem
über Verbindung 616 gekoppelt. Untersystem 618 ist zusätzlich mit Untersystemspeicher 622 über Verbindung 620 gekoppelt.
Ein Beispiel für eine mögliche Betriebsweise der in Figur 6 gezeigten Architektur ist wie folgt. Anfänglich sind Hauptsystem 610 und Hauptsystemspeieher 614 abgeschaltet. Controller 602 erhält eine Nachricht über Verbindung 608 vom Untersystem 608, die verlangt, daß Untersystem 618 gebootet wird. Controller 602 prüft dann den Untersystem-Boot-Indikator 624 über Verbindung 606, um den Bootzustand festzustellen. Angenommen, daß ein Booten des Untersystem 618 durchgeführt werden soll, so kann der Controller 602 dann das Hauptsystem 610 und den Hauptsystemspeicher 614 einschalten. Controller 602 kann über Verbindung 604 den Untersystem-Boot-Indikator 624-Status an das Hauptsystem 610 während dessen Bootprozeß mitteilen. Auf der Basis des Untersystem-Boot -Indikators 624 kann dann das Hauptsystem 610 auf den Hauptsystemspeicher 614 über Verbindung 612 zugreifen, Informationen abfragen und sie über Verbindung 616 zum Untersystem 618 und Verbindung 620 zum Untersystemspeicher 622 übertragen und auch speichern. Nach Beendigung der Informationsübertragung kann der Controller 602 das Hauptsystem und den Hauptsystemspeicher 614 abschalten. Das Untersystem 618 kann dann unter Verwendung der übertragenen Information, die jetzt im Untersystemspeicher 622 gespeichert ist, mit dem Booten fortfahren.
Nachdem das Hauptsystem 610 feststellt, daß es Informationen zum Untersystemspeicher 622 übertragen soll, kann es für einen Prozessor im Hauptsystem 610 notwendig werden, Be-0 fehle bezüglich der Durchführung dieser Operation einzuholen. Diese Befehle können von verschiedenen Quellen, z.B. dem Hauptsystemspeicher 614, dem Untersystemspeicher 622, dem Controller 602, einem entfernten Server usw. mitgeteilt werden,
Ein anderes Beispiel einer möglichen Betriebsweise der Architektur gemäß Figur 6 wäre es, dem Untersystem 618 den Zugriff über Verbindung 618 und Verbindung 612 direkt auf den Hauptsystemspeicher 614 zu gestatten. Bei diesem Szenario kann das Untersystem 618 die Informationsübertragung aus dem Hauptsystemspeicher 614 zum Untersystemspeicher 622 anstelle des die Übertragung der oben beschriebenen Weise bewirkenden Hauptsystems 610 bewirken. Ein Fachmann erkennt, daß viele andere Architekturen und Abwandlungen möglich sind.
Figur 7 zeigt eine andere Systemarchitektur für ein Ausführungsbeispiel der vorliegenden Erfindung. Eine Host-Zentralverarbeitungseinheit (CPU) 702 ist über Verbindung 703 mit einem Speichercontroller-Netzknoten (MCH) 704 gekoppelt.
Der MCH 704 ist über Verbindung 705 mit einem Eingangs/Ausgangs-Controller-Netzknoten (ICH) 706 gekoppelt. Die ICH 706 ist über eine integrierte Treiberelektronik (IDE) 709-Verbindung mit einem Festplattenlaufwerk (HDD) gekoppelt. Die IDE 709 koppelt auch das autonome Untersystem 714 mit dem HDD 710. Die ICH 706 ist auch mit dem autonomen Untersystem 714 über eine universelle Serienbus (USB) 713-Verbindung gekoppelt. Zusätzlich ist der ICH 706 über eine Low-Pin-Count (LPC) 707-Verbindung mit einem eingebetteten Controller (EC) 708, einem Firmware-Netzknoten (FWH) 712 und einem autonomen Untersystem 714 gekoppelt. Das autonome Untersystem 714 ist mit dem EC 708 über einen System-Managementbus (SMB) 721 gekoppelt. Das autonome Untersystem 714 ist über Verbindung 723 mit einem synchronen dynamischen Direktzugriff sspeicher (SDRAM) gekoppelt. Das autonome Unter-0 system 714 ist über eine Verbindung 715 mit einem elektrisch programmierbaren Flash-Nur-Lese-Speicher (FEPROM) 716 gekoppelt. Zu beachten ist, daß der FEPROM 716 einige Speicherplätze hat, die zur Host-Bootunterstützung 718 und zum Speichern von Daten in einem Datenbereich 720 verwendet werden.
Eine mögliche Ausführungsform der Erfindung ist unter Bezugnahme auf Figur 7 wie folgt. Der EC 708 gibt Energie für das autonome Untersystem 714 frei, welches daraufhin den Datenbereich 720 innerhalb des FEPROM 716 prüft, um festzustellen, ob ein Booten erforderlich ist. Ist ein Booten erforderlich, so informiert das autonome Untersystem 714 über den SMB 721 den EC 708 davon, daß ein Booten erforderlich ist. An diesem Punkt kann der EC 708 entweder die Host-CPU 702 zum Bewirken einer Informationsübertragung (bezeichnet als Slave-Modus) oder das autonome Untersystem 714 zum Bewirken der Informationsübertragung (bezeichnet als Master-Modus) verwenden.
Wenn die Host-CPU 702 zum Übertragen der Information verwendet wird, d. h. Slave-Modus, dann kann der EC 708 einschalten; die Host-CPU 702; den MCH 704; den ICH 706; das autonome Untersystem 714; den FEPROM 716 einschließlich der Host-Boot-Unterstützung 718; den LPC 707; den USB 713; die IDE 709; und die Verbindungen 703, 705 und 715. Die Host-CPU 702 kann dann auf die Host-Boot-Unterstützung 718 zeigergesteuert (d. h. gerichtet) werden, um Befehle und/oder Daten über diejenige Art zu holen, mit der die Informationsübertragung bewirkt wird. Die Quelle oder das Ziel der Information kann - jedoch ohne Beschränkung hierauf - bspw. das HDD 710, der FEPROM 716, der FWH 712, der SDRAM 724, ein entfernter Client oder Server usw. sein. Daher kann die Host-CPU 702 einen Informationstransfer bewirken, bspw. von dem HDD 710 zum SDRAM 724. Es ist einzusehen, daß irgendeine Quelle und/oder ein Ziel und ihre entsprechenden Verbindungen genügend weit hochgefahren sein müssen, um einen ausrei-0 chenden Betrieb zu gewährleisten. Nach der vollständigen Übertragung kann der EC 708 die.Host-CPU 702, den MCH 704, den ICH 706, die Verbindungen 703 und 705, den LPC 707, den USB 713 und die IDE 709 abschalten. Der EC 708 kann dann mit dem autonomen Untersystem 714 bspw. über den SMB 721 kommu-
• ·· i »
• « r ·
nizieren, um unter Verwendung der an den SDRAM 724 übertragenen Informationen zu booten.
Wenn die Ressourcen des autonomen Untersystems 714 in ähnlicher Weise benutzt werden, um die Informationen zu übertragen, d. h. Master-Modus, so kann der EC 708 das HDD 710, die IDE 709, das autonome Untersystem 714; den FEPROM 716, den SDRAM 724 und die Verbindungen 715 und 723 einschalten. Das autonome Untersystem 714 kann dann vom EC 708 über SMB 721 angewiesen werden, Befehle und/oder Daten aus dem FEPROM 716 über die Art der Informationsübertragung zu holen. Die Quelle oder das Ziel der Information kann bspw. jedoch ohne Beschränkung hierauf - das HDD 710, der FEPROM 716, der FWH 712, der SDRAM 724, ein entfernter Client oder Server usw. sein. Daher können die Ressourcen des autonomen Untersystems 714 einen Informationstransfer bspw. vom HDD 710 zum SDRAM 724 bewirken. Nach Beendigung der Übertragung kann der EC 708 das HDD 710, die IDE 709 abschalten und danach mit dem autonomen Untersystem 714 bspw. über den SMB 721 kommunizieren, um unter Verwendung der zum SDRAM 724 übertragenen Informationen zu booten.
Die dargestellten Ausführungsbeispiele der vorliegenden Erfindung können, wie einzusehen ist, auf eine Vielzahl von Untersystemen innerhalb eines einzelnen und/oder verteilten Systems oder Systeme angewendet werden. Bei einem Einzelsystern kann es bspw. eine das Untersystem bedienende Benutzereingabe bspw. von einer Tastatur geben, während gleichzeitig ein anderes Untersystem bspw. die Übertragung und den Empfang von Daten über eine drahtlose Verbindung bedient. Bei dem Ziel des Energieerhalts können diese verschiedenen Untersysteme eingeschaltet und gebootet und danach asynchron abgeschaltet werden. Bspw. kann.ein Tastaturuntersystem nur dann aktiviert werden, wenn eine Taste betätigt wird, und es kann zwischen den Tastenbetätigungen abgeschaltet bzw. deaktiviert werden. In ähnlicher Weise kann ein Kommunikations-
untersystem nur eingeschaltet sein, während eine Übertragung oder ein Empfang notwendig ist.
Daher wurde ein Verfahren oder eine Einrichtung zum Booten der Betriebsumgebung eines Untersystems ohne Einbeziehung des Hauptbetriebssystems beschrieben. Obwohl die vorliegende Erfindung unter Bezugnahme auf spezielle Ausführungsbeispiele beschrieben worden ist, ist es klar, daß zahlreiche Modifikationen und Änderungen an diesen Ausführungsbeispielen ohne Abweichen vom Wesen und Umfang der Erfindung vorgenommen werden können, wie sie in den Ansprüchen angegeben sind. Daher sind die Beschreibung und die Zeichnungen in illustrativer Weise und nicht in beschränkendem Sinne zu verstehen.