[go: up one dir, main page]

DE10196703B4 - Verfahren zum Booten der Betriebsumgebung eines autonomen Untersystems in einem computergestützten System ohne Einbeziehung des Hauptbetriebssystems - Google Patents

Verfahren zum Booten der Betriebsumgebung eines autonomen Untersystems in einem computergestützten System ohne Einbeziehung des Hauptbetriebssystems Download PDF

Info

Publication number
DE10196703B4
DE10196703B4 DE10196703T DE10196703T DE10196703B4 DE 10196703 B4 DE10196703 B4 DE 10196703B4 DE 10196703 T DE10196703 T DE 10196703T DE 10196703 T DE10196703 T DE 10196703T DE 10196703 B4 DE10196703 B4 DE 10196703B4
Authority
DE
Germany
Prior art keywords
subsystem
memory
boot
booting
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE10196703T
Other languages
English (en)
Other versions
DE10196703T1 (de
Inventor
Kelan Portland Silvester
Edwin Hillsboro Pole II
Frank Hart
Paul Hillsboro Zurcher
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE10196703T1 publication Critical patent/DE10196703T1/de
Application granted granted Critical
Publication of DE10196703B4 publication Critical patent/DE10196703B4/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/22Microcontrol or microprogram arrangements
    • G06F9/24Loading of the microprogram
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/4401Bootstrapping
    • G06F9/4406Loading of operating system

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)
  • Hardware Redundancy (AREA)
  • Power Sources (AREA)

Abstract

Verfahren zum schnellen und energiesparenden Booten einer Betriebsumgebung eines Untersystems (618, 602, 622; 714, 708, 716) eines ein Hauptsystem (610, 614; 702–706, 710) und das Untersystem enthaltenden Computers (6; 7), wobei auf dem Hauptsystem ein Hauptbetriebssystem abgearbeitet werden kann, wobei:
a) ein Untersystem-Boot-Indikator (in 624 bzw. 720) von dem Untersystem gewonnen wird (302; 502), wobei der Untersystem-Boot-Indikator anzeigt, ob das Untersystem gebootet werden soll;
b) wenn der gewonnene Untersystem-Boot-Indikator anzeigt, daß das Untersystem gebootet werden soll, für das Booten der Betriebsumgebung des Untersystems notwendige, Bootcode umfassende Boot-Informationen aus einem ersten Speicher (614; 710) zu einem zweiten Speicher (622; 724) übertragen werden (306; 506; 510), wobei der erste Speicher ein Speicher des Hauptsystems ist, auf welchen das Untersystem während des Bootens der Betriebsumgebung des Untersystems nicht zugreifen kann, wobei der zweite Speicher ein Speicher des Untersystems ist, auf den während des Bootens der Betriebsumgebung des Untersystems zugegriffen werden kann;...

Description

  • Die vorliegende Erfindung bezieht sich auf ein Verfahren zum schnellen und energiesparenden Booten einer Betriebsumgebung eines Untersystems eines Computers.
  • 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 bringen.
  • 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 Anlage 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 Direktzugriffsspeicher (RAM) zum Plattenspeicher usw. beinhalten.
  • Bei Ansteuerung solcher Niedrigenergiezustände kann das computergestützte System das Betriebssystem wiederaufnehmen oder booten. Nach dem Booten oder Wiederaufnehmen des Betriebssystems kann eine Anwendung ausgeführt werden, um Operationen durchzuführen. Die zum Booten des Betriebssystems benötigte Zeit kann für ein Untersystem (Subsystem), das eine rasche Antwort benötigt, ein Problem darstellen. Darüber hinaus kann die während des Bootprozesses verbrauchte Energie für batteriebetriebene Einrichtungen ein Problem darstellen.
  • Aufgabe der Erfindung ist es daher, ein schnelles und energiesparendes Booten eines Untersystems eines Computers zu ermöglichen.
  • Aus EP 0 592 079 A2 ist ein Verfahren zum Booten eines Computers über ein Netzwerk bekannt. Aus EP 0 805 386 A1 sind Verfahren zum Energiesparen bei einem Computersystem bekannt.
  • Die oben genannte Aufgabe der Erfindung wird durch ein Verfahren mit den Merkmalen des Anspruchs 1 gelöst. Vorteilhafte und/oder bevorzugte Weiterbildungen der Erfindung sind in den Unteransprüchen gekennzeichnet.
  • 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:
  • 1 eine vernetzte Computerumgebung darstellt;
  • 2 ein Blockschaltbild eines Computersystems ist;
  • 3, 4 und 5 Ablaufdiagramme sind, die verschiedene Ausführungsbeispiele der Erfindung darstellen;
  • 6 und 7 Blockdiagramme sind, welche verschiedene Ausführungsbeispiele der Erfindung darstellen.
  • Beschrieben werden ein Verfahren und eine Einrichtung zum Booten der Betriebsumgebung eines autonomen Untersystems in einem computergestützten System ohne Einbeziehung des Hauptbetriebssystems. Es ist klar, 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 bezeichnet wird. Booten kann von einem System ausgehen, das bereits teilweise hochgefahren 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änd lich, daß die Bootfolge die Aufnahme zusätzlicher Befehle und/oder Daten als Ergebnis eines Stimulus, eines Betriebsschalters, 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 klar, daß das der Ausdruck Abschalten (Shutdown) 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 Taktmechanismen usw. umfassen.
  • Ein maschinenlesbares Medium wird so verstanden, daß es 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-Speichermedien; optische Speichermedien; Flashspeichergeräte; elektrische, optische, akustische oder andere Formen von übertragenen Signalen (z.B. Trägerwellen, Infrarotsignale, Digitalsignale usw.); usw.
  • 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-I bzw. 104-M und N Benutzer bzw. Clienten 108-I 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.
  • 2 zeigt einen konventionellen Personalcomputer in Blockdiagrammform, der für einen beliebigen Clienten oder Server gemäß 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(I-O)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 (SCSI), 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 pro grammierbar sein kann, wie maskenprogrammierbar, Flash usw. RAM 208 kann bspw. statisch, dynamisch, synchron, asynchron oder irgendeine Kombination sein, Speicher 210 kann Compact Disc (CD), Digital Versatile Disk (DVD), Festplatten, optische Platten, Band, Flash, Speichersticks, Videorecorder usw. sein. Anzeige 220 kann bspw. ein Kathodenstrahlröhrenbildschirm (CRT), eine Flüssigkristallanzeige (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 Reihe von Schaltern usw. ausgebildet sein. Der Zeiger 226 kann bspw. eine Maus, ein Touchpad, eine Trackball, ein Joystick 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, Virtual-Reality-Zubehö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). Das Kommunikationsgerät 230 kann bspw. ein Ethernet-Adapter für lokale 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. 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 230 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äß 2 möglich.
  • Es wird wieder auf 1 Bezug genommen; die Clients 108-1 bis 108-N sind 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 Clients 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 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 Ethernet 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 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. Das Kommunikationsgerät 230 kann bspw. ein Untersystem haben, das bei Empfang einer Nachricht unabhängig von dem Hauptsystem gebootet werden muß.
  • 3 ist ein vereinfachtes Blockdiagramm eines Ausführungsbeispiels der vorliegenden Erfindung. Ein Untersystem-Boot-Indikator 302 wird gewonnen (retrieved). Auf der Grundlage des gewonnenen Untersystem-Boot-Indikators wird bestimmt, ob das Untersystem gebootet werden soll. Wenn der gewonnene Untersystem-Boot-Indikator kein Booten des Untersystems anzeigt, dann sind weitere Optionen verfügbar (308). Wenn ein Booten des Subsystems angezeigt wird, dann werden Informationen an das Untersystem übertragen (306).
  • 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ß-Pins an einem Bauelement 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. Es ist ferner klar, 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 Client oder Server.
  • Wenn der abgerufene Untersystem-Boot-Indikator 302 keine Anforderung auf ein Booten des Untersystems 304 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.
  • 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 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.
  • 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.
  • 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 618 ü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 6 gezeigten Architektur ist wie folgt. Anfänglich sind Hauptsystem 610 und Hauptsystemspeicher 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 610 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, Befehle 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äß 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.
  • 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) 710 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 Direktzugriffsspeicher (SDRAM) gekoppelt. Das autonome Untersystem 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 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 ausreichenden 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 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 Einzelsystem 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.

Claims (7)

  1. Verfahren zum schnellen und energiesparenden Booten einer Betriebsumgebung eines Untersystems (618, 602, 622; 714, 708, 716) eines ein Hauptsystem (610, 614; 702706, 710) und das Untersystem enthaltenden Computers (6; 7), wobei auf dem Hauptsystem ein Hauptbetriebssystem abgearbeitet werden kann, wobei: a) ein Untersystem-Boot-Indikator (in 624 bzw. 720) von dem Untersystem gewonnen wird (302; 502), wobei der Untersystem-Boot-Indikator anzeigt, ob das Untersystem gebootet werden soll; b) wenn der gewonnene Untersystem-Boot-Indikator anzeigt, daß das Untersystem gebootet werden soll, für das Booten der Betriebsumgebung des Untersystems notwendige, Bootcode umfassende Boot-Informationen aus einem ersten Speicher (614; 710) zu einem zweiten Speicher (622; 724) übertragen werden (306; 506; 510), wobei der erste Speicher ein Speicher des Hauptsystems ist, auf welchen das Untersystem während des Bootens der Betriebsumgebung des Untersystems nicht zugreifen kann, wobei der zweite Speicher ein Speicher des Untersystems ist, auf den während des Bootens der Betriebsumgebung des Untersystems zugegriffen werden kann; und c) die Betriebsumgebung des Untersystems auf der Basis der übertragenen Boot-Informationen gebootet wird (512), wobei das Hauptsystem nach dem Übertragen der Boot-Informationen heruntergeschaltet (powered down) wird und beim Booten der Betriebsumgebung des Untersystems heruntergeschaltet bleibt, wobei die Schritte a)–c) ausgeführt werden, ohne das Hauptbetriebssystem zu booten.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der Untersystem-Boot-Indikator aus einem dritten Speicher (624; 716) gewonnen wird.
  3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß der Untersystem-Boot-Indikator in Erwiderung einer das Booten des Untersystems anfordernden Kommunikation gewonnen wird.
  4. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Boot-Informationen mit Hilfe eines Hauptprozessors (702) des Hauptsystems übertragen werden, wobei der Hauptprozessor (702) auf den ersten Speicher (710) zugreift und die Boot-Informationen überträgt, ohne das Hauptbetriebssystem zu laden.
  5. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Boot-Informationen unter der Steuerung des Subsystems aus dem ersten Speicher (710) zu dem zweiten Speicher (724) übertragen werden, wobei der erste Speicher (710) nach der Übertragung der Boot-Informationen heruntergeschaltet (powered down) wird, wobei das Untersystem (714) eingeschaltet bleibt.
  6. Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß der dritte Speicher (624; 716) ein nicht-flüchtiger Speicher ist.
  7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, daß der nicht-flüchtige Speicher Teil des Untersystems ist.
DE10196703T 2000-09-29 2001-09-26 Verfahren zum Booten der Betriebsumgebung eines autonomen Untersystems in einem computergestützten System ohne Einbeziehung des Hauptbetriebssystems Expired - Fee Related DE10196703B4 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US09/675,977 US7149888B1 (en) 2000-09-29 2000-09-29 Method and apparatus for booting the operating environment of an autonomous subsystem in a computer based system without involvement of the main operating system
US09/675,977 2000-09-29
PCT/US2001/030349 WO2002027471A2 (en) 2000-09-29 2001-09-26 Method and apparatus for booting the operating environment of an autonomous subsystem

Publications (2)

Publication Number Publication Date
DE10196703T1 DE10196703T1 (de) 2003-08-28
DE10196703B4 true DE10196703B4 (de) 2006-12-07

Family

ID=24712704

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10196703T Expired - Fee Related DE10196703B4 (de) 2000-09-29 2001-09-26 Verfahren zum Booten der Betriebsumgebung eines autonomen Untersystems in einem computergestützten System ohne Einbeziehung des Hauptbetriebssystems

Country Status (9)

Country Link
US (1) US7149888B1 (de)
KR (1) KR100527885B1 (de)
CN (1) CN1306397C (de)
AU (1) AU2001293155A1 (de)
DE (1) DE10196703B4 (de)
GB (1) GB2386453B (de)
HK (1) HK1058253A1 (de)
TW (1) TW554289B (de)
WO (1) WO2002027471A2 (de)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7149888B1 (en) 2000-09-29 2006-12-12 Intel Corporation Method and apparatus for booting the operating environment of an autonomous subsystem in a computer based system without involvement of the main operating system
DE10355584B4 (de) * 2003-11-28 2007-11-08 Advanced Micro Devices, Inc., Sunnyvale Datenverarbeitungssystem, computerlesbares Speichermedium und Verfahren zum Steuern einer Datenübertragung zu und/oder von einem WLAN-Gerät
US7086583B2 (en) * 2004-01-20 2006-08-08 Standard Microsystems Corporation Systems and methods for power reduction in systems having removable media devices
US20050257041A1 (en) * 2004-05-14 2005-11-17 Cory Wallenstein Method and apparatus for remote computer reboot
US7827558B2 (en) * 2004-06-30 2010-11-02 Devicevm, Inc. Mechanism for enabling a program to be executed while the execution of an operating system is suspended
US7433990B2 (en) * 2006-01-24 2008-10-07 Standard Microsystems Corporation Transferring system information via universal serial bus (USB)
JP4976817B2 (ja) * 2006-11-06 2012-07-18 オンセミコンダクター・トレーディング・リミテッド プログラム処理装置及びプログラム処理方法
CN101232397B (zh) * 2008-02-22 2010-10-27 成都市华为赛门铁克科技有限公司 多控制器系统修复的方法和装置
US8185759B1 (en) 2008-11-06 2012-05-22 Smsc Holdings S.A.R.L. Methods and systems for interfacing bus powered devices with host devices providing limited power levels
US7882297B2 (en) * 2009-02-20 2011-02-01 Standard Microsystems Corporation Serial bus hub with low power devices
JP5578811B2 (ja) * 2009-06-30 2014-08-27 キヤノン株式会社 情報処理装置、情報処理装置の制御方法及びプログラム
US8938796B2 (en) * 2012-09-20 2015-01-20 Paul Case, SR. Case secure computer architecture
JP6570227B2 (ja) * 2014-08-28 2019-09-04 キヤノン株式会社 メインシステムおよびサブシステムを備える情報処理装置

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0592079A2 (de) * 1992-09-20 1994-04-13 Sun Microsystems, Inc. Automatisierte Softwareinstallierung und Betriebsumgebungskonfigurierung in einem Rechnersystem

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4747041A (en) 1983-06-27 1988-05-24 Unisys Corporation Automatic power control system which automatically activates and deactivates power to selected peripheral devices based upon system requirement
US5367688A (en) * 1987-09-04 1994-11-22 Digital Equipment Corporation Boot system for distributed digital data processing system
US5146568A (en) * 1988-09-06 1992-09-08 Digital Equipment Corporation Remote bootstrapping a node over communication link by initially requesting remote storage access program which emulates local disk to load other programs
US5261114A (en) 1990-11-09 1993-11-09 Ast Research, Inc. Method and apparatus for providing down-loaded instructions for execution by a peripheral controller
IL123186A0 (en) 1998-02-04 1998-09-24 Haviv Uri Network computer
US6088785A (en) 1998-04-15 2000-07-11 Diamond Multimedia Systems, Inc. Method of configuring a functionally redefinable signal processing system
US6101601A (en) * 1998-04-20 2000-08-08 International Business Machines Corporation Method and apparatus for hibernation within a distributed data processing system
US6430687B1 (en) * 1999-04-15 2002-08-06 International Business Machines Corporation Boot sequence for a network computer including prioritized scheduling of boot code retrieval
US6421777B1 (en) * 1999-04-26 2002-07-16 International Business Machines Corporation Method and apparatus for managing boot images in a distributed data processing system
US6473857B1 (en) * 1999-12-06 2002-10-29 Dell Products, L.P. Centralized boot
US7149888B1 (en) 2000-09-29 2006-12-12 Intel Corporation Method and apparatus for booting the operating environment of an autonomous subsystem in a computer based system without involvement of the main operating system

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0592079A2 (de) * 1992-09-20 1994-04-13 Sun Microsystems, Inc. Automatisierte Softwareinstallierung und Betriebsumgebungskonfigurierung in einem Rechnersystem

Also Published As

Publication number Publication date
AU2001293155A1 (en) 2002-04-08
KR20030036857A (ko) 2003-05-09
CN1531682A (zh) 2004-09-22
DE10196703T1 (de) 2003-08-28
CN1306397C (zh) 2007-03-21
GB2386453B (en) 2005-02-23
GB0309104D0 (en) 2003-05-28
TW554289B (en) 2003-09-21
WO2002027471A2 (en) 2002-04-04
HK1058253A1 (en) 2004-05-07
KR100527885B1 (ko) 2005-11-15
WO2002027471A3 (en) 2003-09-04
GB2386453A (en) 2003-09-17
US7149888B1 (en) 2006-12-12

Similar Documents

Publication Publication Date Title
DE10196703B4 (de) Verfahren zum Booten der Betriebsumgebung eines autonomen Untersystems in einem computergestützten System ohne Einbeziehung des Hauptbetriebssystems
DE60128396T2 (de) Computer-peripheriegerät, das betreibbar bleibt, wenn die operationen des zentralprozessors suspendiert werden
DE69229976T2 (de) Gerät und Verfahren zum Unterbrechen und Wiederaufnehmen von Softwareanwendungen auf einem Rechner
DE102004038649B4 (de) Dauerspeichervorrichtung für Sicherungsprozess-Prüfpunktzustände
DE112005001801B4 (de) Verfahren und Vorrichtung zum dynamischen DLL-Herunterfahren und Speicher-Selbstauffrischen
DE69015084T2 (de) Rechnersystem mit Steuereinheit zur Steuerung der Energieversorgung einer Speichereinheit.
DE69605127T2 (de) Kernteil mit asynchroner teilweisen rücksetzung
DE60116650T2 (de) Strommodus-übergang für einen prozessor
DE69622253T2 (de) System und verfahren für on-line- und echzeit-datenmigration
DE112006001168B4 (de) Nahtloser Übergang von Betriebsumgebungen in mobilen Systemen zur Leistungsoptimierung
DE102012212441B4 (de) Verfahren zum Eintreten in und Verlassen eines Schlafmodus in einer Graphikverarbeitungseinheit
DE60130262T2 (de) Stromsparendes dekodierungs-/abspielsystem für digitale audiosignale für datenverarbeitungsgeräte
DE69319383T2 (de) Verfahren und Gerät zum Urladen eines Rechners zu einer programmierten Zeit
DE69804099T2 (de) Initialisierung von unterteilten datenobjekten
DE69627604T2 (de) Verfahren und vorrichtung zum verarbeiten von e/a-anforderungen
DE112012004893B4 (de) Implementieren eines Software-Abbildes auf mehreren Zielen unter Verwendung einer Datenstromtechnik
DE112007003113B4 (de) Reduzieren von Leerlauf-Verlustleistung in einem integrierten Schaltkreis
DE112017004663T5 (de) Mehrfachverbinder-unterstützung für usb-c
DE102010001985A1 (de) Vorrichtung zum Schalten des Betriebs einer virtuellen Maschine zwischen mehreren Computern, die der gleichen Computerplattform zugeordnet sind, und entsprechende Schaltverfahren
DE10393969T5 (de) Mechanismus zur Verteilung von Unterbrechungen niedrigster Priorität unter Berücksichtigung des Prozessorleistungszustands
DE112010004784T5 (de) Effizientes Laden von Daten in den Speicher eines Rechnersystems
DE202008018394U1 (de) Wenigstens teilweise auf einem Leistungszustand eines integrierten Schaltkreises basierende Versorgungsspannungssteuerung
DE102009030544A1 (de) Koordiniertes Link-Power-Management
DE112011105700T5 (de) Schneller Ruhezustand- und schnelle Wiederinbetriebnahme für eine Plattform von Computersystem
DE112019000662T5 (de) System, Vorrichtung und Verfahren für ein Handschlag-Protokoll für Niedrigleistungszustandsübergänge

Legal Events

Date Code Title Description
8110 Request for examination paragraph 44
8364 No opposition during term of opposition
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee