DE112006001308T5

DE112006001308T5 - Neukonfigurierung von Hardware-Ressourcen innerhalb eines Systems

Info

Publication number: DE112006001308T5
Application number: DE112006001308T
Authority: DE
Inventors: Shahrokh Beaverton Shahidzadeh; William Portland Kirby; Jonathan Portland Douglas
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2005-05-23
Filing date: 2006-05-23
Publication date: 2008-04-17
Also published as: GB2439889B; CN101180608A; US20100058323A1; GB0721237D0; WO2006127949A1; KR20080005567A; GB2439889A; US20070006213A1; TWI328189B; US8375380B2; TW200713028A; JP2008542882A; CN101180608B; KR100962747B1; US7640541B2; JP5070206B2

Abstract

Verfahren, das aufweist:
Feststellen, ob ein System mit einer Aufrüstung einer Hardwareressource des Systems kompatibel ist;
Empfangen von Befehlen von einem entfernten System, um die Hardwareressource aufzurüsten, wenn das System kompatibel ist; und
Programmieren der Hardwareressource basierend auf den Befehlen.

Description

Hintergrund
Ausführungsformen der Erfindung betreffen Hardwarekomponenten, die in Computersystemen und dergleichen verwendet werden, und genauer die Aufrüstbarkeit solcher Komponenten.
Viele auf Prozessor basierende Systeme, die unter vielen anderen Personal Computer (PCs), Server, persönliche digitale Assistenten (PDAs) und Mobiltelefone umfassen, enthalten eine Mischung aus Hardware- und Softwarekomponenten. Typischerweise umfaßt ein System ei nen Mikroprozessor, der allgemein als eine zentrale Verarbeitungseinheit (CPU) bezeichnet wird, die einen Hauptanteil der Verarbeitungsoperationen handhabt, zusammen mit dazu in Bezug stehenden Komponenten, die zum Beispiel Speicher und andere Speichermedien, Chipsätze und andere Verarbeitungsvorrichtungen, Eingabe/Ausgabe (I/O – Input/Output)-Vorrichtungen und dergleichen umfassen.
Endverbraucher nutzen derartige Systeme typischerweise für vielfältige Verarbeitungsprozesse, zur Unterhaltung, zur Kommunikation und für andere Aktivitäten. Oftmals wird ein Benutzer Softwarekomponenten eines Systems, einschließlich eines Betriebssystems (OS – Operating System), Anwendungsprogramme, so wie Antivirenprogramme und dergleichen aufrüsten. Weiter können Benutzer die Hardware eines Systems aufrüsten, indem neue Software (z. B. Treiber oder Software-Korrekturprogrammstücke) heruntergeladen oder auf andere Weise installiert wird, um die Hardware zu steuern, indem neue Komponenten hinzugefügt werden, so wie zusätzlicher Speicher, indem neue Bauteile eingebaut werden, so wie erweiterte Grafikkarten und dergleichen, oder ältere Komponenten, so wie ein Mikroprozessor oder ein Festplattenlaufwerk, durch eine neue Komponente ersetzt werden. Jedoch gibt es keine Aufrüstmöglichkeiten nach dem Verkauf, die für Hardwarekomponenten innerhalb eines zuvor konfigurierten Systems erhältlich sind.
Oftmals sind Hardwaremerkmale oder Hardwarekomponenten, so wie ein Mikroprozessor, Chipsätze und dergleichen, der Übernahme dieser Merkmale durch eine Mehrzahl der Benutzer Jahre voraus. Zum Beispiel sind Hardwaremerkmale in Hardwarekomponenten lange vor der Übernahme dieser Merkmale durch Software und/oder ausgereifte Software, die solche Merkmale implementiert, verfügbar und vorliegend. Mit anderen Worten wird neue Hardwaretechnologie in vielen Fällen schneller eingeführt, als Software die Technologie übernehmen kann. Ohne Softwareunterstützung und Benutzernachfrage nach solchen Hardwaremerkmalen rechtfertigen Hardwarekomponenten, die diese neuen Hardwaremerkmale enthalten, wegen der unverwerteten Technologien auf der Karte oftmals keinen Aufpreis.
Demgemäß gibt es ein Bedürfnis, die Aufrüstbarkeit von Hardwaremerkmalen innerhalb von Systemen zu verbessern.
Kurzbeschreibung der Zeichnungen
1 ist ein Blockschaubild eines Systems zum Durchführen von Hardwareaufrüstungen gemäß einer Ausführungsform der vorliegenden Erfindung.
2 ist ein Ablaufdiagramm eines Verfahrens gemäß einer Ausführungsform der vorliegenden Erfindung.
3 ist ein Blockschaubild eines ersten Teiles einer dynamischen Programmierschaltung für Sicherungen gemäß einer Ausführungsform der vorliegenden Erfindung.
4 ist ein Blockschaubild eines zweiten Teiles der dynamischen Programmierschaltung für Sicherungen der 3.
5 ist ein Blockschaubild eines Systems gemäß einer Ausführungsform der vorliegenden Erfindung.
Genaue Beschreibung
Mit Bezug nun auf 1 ist ein Blockschaubild eines Systems zum Aufrüsten eines oder mehrerer Hardwaremerkmale eines Systems gezeigt. Wie in 1 gezeigt, umfaßt das System einen entfernt stehenden Server 10, der mit einem Zielsystem 100 kommuniziert. Als ein Beispiel kann der entfernte Server 10 ein Webserver eines Originalherstellers (OEM – Original Equipment Manufacturer), so wie einem Hersteller oder Wiederverkäufer von PCs, oder eines anderen Anbieters sein. Als Alternative kann der entfernte Server 10 mit einem unabhängigen Anbieter von Hardwarekomponenten verknüpft sein. Bei noch anderen Ausführungsformen kann der entfernte Server 10 mit einem unabhängigen Serviceprovider, so wie einem autorisierten Wiederverkäufer bestimmter Hardwarekomponenten verknüpft sein. Obwohl er hierin als ein entfernt stehender Server beschrieben ist, soll verstanden werden, daß in anderen Ausführungsformen ein unterschiedlicher Typ eines Systems benutzt werden kann, um Aufrüsten gemäß einer Ausführungsform der vorliegenden Erfindung zu ermöglichen.
Der entfernte Server 10 kann mit dem Zielsystem 100 durch verschiedene Mittel kommunizieren, einschließlich zum Beispiel über das Internet oder andere auf einem Netzwerk basierende Verbindungen. Bei manchen Ausführungsformen kann der entfernte Server 10 eine sichere Schnittstelle 20 umfassen, um mit dem Zielsystem 100 zu kommunizieren. Die sichere Schnittstelle 20 kann Verschlüsselungstechnologie einsetzen, so wie die, die für sichere, auf dem Web basierende finanzielle oder andere Transaktionen verwendet wird, um sicher mit dem Zielsystem 100 zu kommunizieren.
Bei verschiedenen Ausführungsformen kann das Zielsystem 100 ein PC, ein Servercomputer, ein PDA, ein Mobiltelefon oder dergleichen sein. Das Zielsystem 100 kann verschiedene Hardware- und Softwarekomponenten umfassen. Bei verschiedenen Ausführungsformen kann das Zielsystem 100 eine Tabelle 110 unterstützter Konfigurationen umfassen, die eine Vielzahl von Maschinenstatusregistern (MSRs) enthält, um den Status unterschiedlicher Hardwaremerkmale anzugeben. Bei einer Ausführungsform kann die Tabelle 110 unterstützter Konfigurationen innerhalb des Computers des Zielsystems 100 sein und kann verwendet werden, um unterschiedliche Hardwaremerkmale des Mikroprozessors selbst anzugeben. Bei manchen Ausführungsformen kann wenigstens ein Teil der Information innerhalb der Tabelle 110 unterstützter Konfigurationen in anderen Teilen des Prozessors enthalten sein. Zum Beispiel können andere Statusregister Information umfassen, die bestimmte Fähigkeiten eines Prozessors identifizieren, so daß geeignete Software, ein Mikrocode und dergleichen einen Nutzen aus den Fähigkeiten ziehen kann. Jedoch ist die Information in solchen Statusregistern für einen entfernten Server nicht sichtbar.
Bei anderen Ausführungsformen kann sich die Tabelle 110 unterstützter Konfigurationen in anderen Teilen eines Zielsystems befinden, zum Beispiel einer Chipsatzkomponente, eines dauerhaften Speichers oder an einem anderen Ort. Das Zielsystem 100 kann weiter einen Neukonfigurierungs-Logikblock 120 umfassen, um Aufrüstungsaktivitäten gemäß einer Ausführungsform der vorliegenden Erfindung zu handhaben.
Während des Betriebes kann der entfernte Server 10 eine Anfrage nach einer Neukonfiguration einer Hardwarekomponente innerhalb des Systems einleiten. Zum Beispiel kann ein entfernter Server 10 eine Anfrage an das Zielsystem 100 senden, um festzustellen, ob ein Benutzer des Systems 100 es wünscht, ein Hardwaremerkmal eines Mikroprozessors aufzurüsten. Der entfernte Server 10 kann mit dem Zielsystem 100 vielfältig kommunizieren. Zum Beispiel kann bei manchen Ausführungsformen der entfernte Server 10 eine Sammelrufsendung in eine Anzahl von Systemen senden, so wie eine Sammelrufsendung an alle bekannten Zielsysteme eines gegebenen Modells und/oder einer gegebenen Konfiguration. Zum Beispiel kann allen Modellen X eines OEM, die einen bestimmten Prozessor und/oder ein bestimmtes Softwareabbild enthalten, ein Sammelrufpaket geschickt werden.
Bei manchen Ausführungsformen können diese Sammelrufpakete transparent an das Zielsystem 100 geschickt werden, so daß ein Benutzer des Systems den Empfang des Paketes nicht erkennt. Bei diesen Ausführungsformen kann das Sammelrufpaket Information enthalten, um den Sender des Paketes zu identifizieren, zusätzlich zu Information, um auf die Tabelle 110 unterstützter Konfigurationen zuzugreifen. Genauer kann das Sammelrufpaket Befehle für die Ausführung durch einen Prozessor des Zielsystems 100 umfassen, um auf die Tabelle 110 unterstützter Konfigurationen zuzugreifen, um einen Aufrüstungsstatus für ein gegebenes Hardwaremerkmal zu bestimmen. Zum Beispiel kann ein Sammelrufpaket eine Anfrage von dem entfernten Server 10 nach Information im Hinblick auf ein Hardwaremerkmal B enthalten. Demgemäß kann das Zielsystem 100 auf die Tabelle 110 unterstützter Konfigurationen zugreifen, um festzustellen, ob eine Aufrüstung zum Freigeben des Merkmals B mit dem Zielsystem 100 verträglich ist. Wenn dies der Fall ist, kann das Zielsystem 100 derartige Information an den entfernten Server 10 kommunizieren. Bei manchen Ausführungsformen kann diese Kommunikation für einen Benutzer des Zielsystems 100 ebenfalls transparent sein.
Wenn der entfernte Server 10 somit bestätigt, daß ein Zielsystem 100 im Hinblick auf ein Merkmal B aufgerüstet werden kann, kann der entfernte Server 10 dann eine Kommunikation an das Zielsystem 100 schicken, um festzustellen, ob der Benutzer (oder ein verantwortlicher Informationstechnologie (IT)-Verwalter) des Zielsystems 100 es wünscht, sein System in bezug auf das Merkmal B aufzurüsten. Bei manchen Ausführungsformen kann die Nachricht eine Pop-up- oder eine andere dynamische Nachricht sein. Bei diesen Ausführungsformen kann, um eine solche dynamische Nachricht zu empfangen, das Zielsystem 100 für dynamische Aufrüstungen freigegeben sein. Obwohl die Form der Nachricht, die die Verfügbarkeit einer Aufrüstung zeigt, viele Formen annehmen kann, kann bei manchen Ausführungsformen eine Pop-up-Anzeige, so wie die für eine herkömmliche Software/OS-Aufrüstung angezeigt werden. Als ein Beispiel kann eine Nachricht die Verfügbarkeit eines Merkmals B wie folgt berichten: "Sind Sie daran interessiert, das Merkmal B für Ihr Intel^®Pentium^®4-System zu aktivieren?" "Hier für eine Demonstration der Möglichkeiten dieses Merkmals klicken, was eine Anordnung von Einsatzmodellen aktiviert, die bereits auf Ihrem System verfügbar sind." Dann kann eine Demonstration präsentiert werden, die die Nutzen des Merkmals zusammen mit den Kosten beschreibt. Dann kann eine Nachricht, so wie "Es dauert weniger als X Minuten, Ihren PC für einen Betrag von $Y aufzurüsten" angezeigt werden. Basierend auf der Antwort des Benutzers wird eine Kommunikation zurück zu dem entfernten Server 10 vorgenommen. Auf eine solche Weise können Dienstleister den Wert für diesen Zeitpunkt nach dem Verkauf belasten und somit eine Gelegenheit zum Verkauf realisieren.
Das Hardwaremerkmal kann irgendeine gewünschte Hardwareschaltung sein, um eine gegebene Funktion durchzuführen. Als Beispiel und ohne Beschränkung können Hardwaremerkmale, die aufgerüstet werden sollen, die Geschwindigkeit des Prozessors, Sicherheitsmerkmale und dergleichen umfassen. Weitere Hardwaremerkmale, die aufgerüstet werden sollen, können das Hyperthreading oder andere Multi-Threading-Technologien, Virtualisierungstechnologien, Rechnen mit 64-Bit-Befehlen, erweiterte Technologien und dergleichen umfassen.
Bei manchen Ausführungsformen kann der entfernte Server 10 die Anfrage an das Zielsystem 100 senden, indem eine sichere Schnittstelle 20 verwendet wird. Das Zielsystem 100 kann wiederum prüfen, um festzustellen, ob das System aufrüstbar ist und welche Merkmale für das Aufrüsten verfügbar sind. Wie oben beschrieben können bei manchen Ausführungsformen unterschiedliche Register der Tabelle 110 unterstützter Konfigurationen untersucht werden, um den Aufrüstungsstatus des Systems festzustellen.
Wie in 1 gezeigt, kann die Tabelle 110 unterstützter Konfigurationen eine Vielzahl von Maschinenstatusregistern (MSRs) umfassen. Bei manchen Ausführungsformen kann jedes der MSRs mehrere Bits umfassen, wobei jedes Bit mit einem unterschiedlichen Merkmal verknüpft ist, obwohl andere Steuerschemata möglich sind.
Ein erstes MSR 112 kann als ein Produktmerkmal-Statusregister bezeichnet werden. Das Produktmerkmal-MSR 112 kann von dem Hersteller der Hardwarekomponente (z. B. dem Hersteller eines Prozessors) gesetzt werden, um anzugeben, ob die gegebene Hardwarekomponente Schaltung umfaßt, die einem gegebenen Merkmal entspricht. Bei der Ausführungsform, die in 1 gezeigt ist, umfaßt das Produktmerkmal-MSR 112 eine Vielzahl von Bits. Die Bits A, B und C sind als gesetzt gezeigt, was angibt, daß der Prozessor, wie er hergestellt ist, Schaltung für Hardwaremerkmale A, B und C enthält. Natürlich sind bei anderen Ausführungsformen unterschiedliche Konfigurationen möglich, und mehr als die veranschaulichte Anzahl von Merkmalen kann vorliegen.
Weiter mit Bezug auf 1 umfaßt die Tabelle 110 unterstützter Konfigurationen ein zweites MSR 114, das als ein Systemmerkmal-MSR bezeichnet werden kann. Das Systemmerkmal-MSR 114 kann darüber berichten, welche Systemunterstützung ein OEM oder ein anderer Anbieter für das System, wie es konfiguriert ist, verfügbar gemacht hat. Das heißt, einige Merkmale können Unterstützung auf Systemebene erfordern, so wie zusätzliche Hardware oder Software (z. B. OS-Merkmale, Treiber, zusätzliche Hardware, so wie ein Modul für eine zuverlässige Plattform (TPM – Trusted Platform Module) oder eine bandversetzte (OOB – Out-Of-Band)-Verwaltungsmaschine). Demgemäß kann das Systemmerkmal-MSR 114 In formation darüber liefern, ob das Zielsystem 100, wie es konfiguriert ist, zu einer nahtlosen Aufrüstung in der Lage ist. Bei verschiedenen Ausführungsformen kann das Systemmerkmal-MSR 114 somit von einem OEM oder einem anderen Systemanbieter zum Beispiel während der Herstellung des Systems beschrieben werden, um die Aufrüstbarkeit des Zielsystems für unterschiedliche Hardwaremerkmale anzugeben. Demgemäß kann das zweite MSR 114 benutzt werden, um eine Zertifizierung/Validierung eines Systems für gegebene Hardwaremerkmale zu liefern. Wenn ein gegebenes Merkmal in dem zweiten MSR 114 gesetzt ist, kann das Zielsystem 100 zuverlässig mit einer Aufrüstung auf das gegebene Merkmal kompatibel sein, um es im Hinblick auf die verschiedene Hardware und Software des gegebenen Systems zu unterstützen.
Somit können bei verschiedenen Ausführungsformen Systeme am Verkaufsort durch einen OEM, einen Originalgerätehersteller (ODM – Original Device Manufacturer) und/oder einen Integrator als für bestimmte Klassen von Merkmalen aufrüstbar zertifiziert werden. Eine solche Aufrüstbarkeit kann basierend auf der Annahme zur Verfügung gestellt werden, daß an einem Verkaufsort ein Kernmodell, das einem System entspricht, in vielen Schattierungen verfügbar ist, z. B. verschiedene Hardware- und Softwarekomponenten und Ebenen solcher Komponenten umfassend. Manche Benutzer mögen es wünschen, das System mit allen aktivierten Merkmalen zu kaufen, d. h. ein Topsystem. Jedoch mögen andere Benutzer wünschen, ein System mit einer Untermenge aller Merkmale, die in Hardware verfügbar sind, zu kaufen, wobei Ökosystem- und Einsatzmodelle reifen und für Durchschnittsbenutzer heranwachsen. Demgemäß, basierend auf einer bestimmten Konfiguration des Systems kann der Anbieter das Systemmerkmal-MSR 114 entsprechend an dem Verkaufsort setzen.
Wiederum kann ein Aufrüstung-MSR 116 die Merkmale der Zielkomponente angeben, die innerhalb des Systems aktiviert werden können. Bei manchen Ausführungsformen kann das MSR 116 ein MSR für Aufrüsten nach dem Verkauf sein. Das heißt, das Aufrüstung-MSR 116 kann eine logische UND-Operation zwischen den MSRs 112 und 114 anzeigen. Demgemäß, wie in 1 gezeigt, ist das Merkmal B im Aufrüstung-MSR 116 gesetzt, was eine Aufrüstung nach dem Verkauf bezüglich des Merkmals B angibt.
Wenn somit das Zielsystem 100 in der Lage ist, aufgerüstet zu werden, und ein Benutzer die Aufrüstung wünscht, können das Zielsystem 100 und der entfernte Server 10 bewirken, daß das Zielsystem aufgerüstet wird. Bei manchen Ausführungsformen, wenn ein Benutzer ein vom OEM zur Verfügung gestelltes Abbild geändert hat, bevor irgendwelche Hardwareaufrüstungen erlaubt sind, kann das ursprüngliche Abbild neu installiert werden, um zu bestätigen, daß die Hardwaremerkmale nahtlos aktiviert werden können. Mit anderen Worten, bevor der entfernte Server 10 in der Lage ist, ein Zielsystem 100 aufzurüsten, muß zunächst das Zielsystem 100 sein ursprüngliches Abbild erneut installiert haben.
Um die Aufrüstung der Hardware zu bewirken, kann das Zielsystem 100 einen Chiffrierschlüssel an den entfernten Server 10 senden, zusammen mit der Angabe, daß für das Hardwaremerkmal B gewünscht wird, daß es aktiviert und/oder aufgerüstet wird. Bei verschiedenen Ausführungsformen kann die Systemkomponente, die aufgerüstet werden soll (z. B. eine CPU oder eine Chipsatzkomponente), einen eindeutigen Chiffrierschlüssel zur Verfügung stellen, der für das Zielsystem 100 spezifisch ist. Bei manchen Ausführungsformen kann der eindeutige Chiffrierschlüssel eine Produktseriennummer oder ein anderer eindeutiger Identifizierer sein, der zur Verfügung gestellt wird, um jede hergestellte Komponente eindeutig zu identifizieren. Indem ein eindeutiger Identifizierer zur Verfügung gestellt wird, kann die Verträglichkeit mit Maßnahmen gegen Piraterie und anderen Sicherheitsmechanismen durchgesetzt werden.
Basierend auf der Information, die von dem Zielsystem 100 erhalten wird, kann der entfernte Server 10 Mikrocodebefehle verschlüsseln, um (zum Beispiel) das Merkmal B zu aktivieren, das in dem Zielsystem 100 aufgerüstet werden soll. Bei der Ausführungsform der 1 kann ein Codeverschlüsselungslogikblock 30 innerhalb des entfernten Servers 10 verwendet werden, um den Mikrocode zu erhalten, über den das Aufrüsten bewirkt wird, und um den Mikrocode entsprechend dem Chiffrierschlüssel, der von dem Zielsystem 100 erhalten worden ist, zu verschlüsseln. Dann kann der entfernte Server 10 die verschlüsselten Befehle über einen Code- und Verifikationskommunikationslogikblock 40 senden. Bei verschiedenen Aus führungsformen kann die verschickte Information verschlüsselte Mikrocodebefehle umfassen, um das/die Hardwaremerkmale) zu aktivieren, zusammen mit zusätzlichen Befehlen zum Prüfen der Zielkomponente, um ein erfolgreiches Aufrüsten zu bestätigen.
Noch mit Bezug auf 1 können die verschlüsselten Befehle von einem Neukonfigurierungs-Logikblock 120 des Zielsystems 100 verwendet werden. Der Neukonfigurierungs-Logikblock 120 kann verschiedene Komponenten umfassen, um Merkmalaufrüstungen zu bewirken. Insbesondere, wie in 1 gezeigt, kann der Neukonfigurierungs-Logikblock 120 eine Codedechiffrierlogik 122 umfassen, um den Mikrocode zu entschlüsseln, der von dem entfernten Server 10 geschickt worden ist. Bei verschiedenen Ausführungsformen kann die Codeentschlüsselungslogik 122 einen Dechiffrierschlüssel verwenden, der dem Chiffrierschlüssel entspricht, welcher von dem Zielsystem 100 gesendet worden ist. Nach dem Entschlüsseln des Mikrocodes kann eine Aktivierlogik 124 innerhalb des Systems das Merkmal B aktivieren. Bei verschiedenen Ausführungsformen kann eine Programmierlogik für Sicherungen verwendet werden, um das Merkmal zu aktivieren, wie es weiter hiernach diskutiert wird.
Nach dem Beenden des Aktivierens des Merkmals kann eine Validierlogik 126 innerhalb des Systems bestätigen, daß das Hardwaremerkmal tatsächlich erfolgreich aktiviert worden ist. Wenn dies der Fall ist, kann die Validierlogik 126 innerhalb des Systems ein entsprechendes Merkmalsbit in einem Merkmal-Aktiviert-MSR 118 innerhalb der Tabelle 110 unterstützter Konfigurationen setzen, um den aktivierten Zustand anzugeben. Zum Beispiel zeigt 1, daß das Merkmal-Aktiviert-MSR 118 eine logische "Null" in einem Bit hat, das dem Merkmal B entspricht. Bei einer erfolgreichen Aufrüstung, um das Merkmal B bereitzustellen, kann das Bit, das dem Merkmal B entspricht, in den Zustand einer logischen "Eins" gebracht werden. Nach dem Setzen des Merkmal-Aktiviert-MSR 118 kann das Zielsystem 100 eine Bestätigungsnachricht an einen Bestätigungs- und Rechnungsstellungslogikblock (Bestätigungsblock) 50 des entfernten Servers 10 senden. Bei verschiedenen Ausführungsformen kann die Bestätigungsnachricht weiter bestätigen, daß das Hardwaremerkmal auf dem Zielsystem 100 arbeitet. Demgemäß kann eine Validierungsnachricht zurück an den Server 10 eine Signatur umfassen, welche die erfolgreiche Implementierung des Hardwaremerkmals in dem Zielsystem 100 bestätigt. Demgemäß kann ein Benutzer nicht später behaupten, daß das Hardwaremerkmal nicht erfolgreich aufgerüstet wurde, in dem Bestreben, die Bezahlung für die Aufrüstung zu vermeiden.
Nach dem Empfang der Bestätigungsnachricht kann der entfernte Server 10 ein Konto, das mit dem Zielsystem 100 verknüpft ist, für die erfolgreiche Aufrüstung belasten. Weiter kann der Bestätigungsblock 50 eine Statusnachricht an eine zentrale Datenbank 60 senden, um die Aufrüstung für das Zielsystem 100 anzugeben. Bei manchen Ausführungsformen kann die zentrale Datenbank 60 eine Datenbank sein, die mit einem Komponentenhersteller verknüpft ist, zum Beispiel einem Hersteller für Mikroprozessoren. Auf diese Weise kann der Hersteller die tatsächliche Konfiguration bestimmter Prozessoren für Gewährleistungs- und andere Zwecke verfolgen. Wenn zum Beispiel ein Benutzer ein gegebenes Hardwaremerkmal aktiviert hat, kann ein Hersteller für Prozessoren das System für weitere Aufrüstungen, Software oder andere Komponenten ins Ziel fassen, um für Zubehör zu sorgen, das für die Verwendung mit der gegebenen Aufrüstung des Hardwaremerkmals geeignet ist. Noch weiter kann der Hersteller für Prozessoren Information im Hinblick auf Aufrüstungen verwenden, die von bestimmten Benutzern bewirkt wurden, oder die Auswahl von Aufrüstungen insgesamt, um Marketinginformation zur Verwendung beim Entwickeln zukünftiger Produkte und Aufrüstungen herauszuziehen.
Obwohl es in 1 als mit einem entfernten Server 10 implementiert gezeigt ist, können bei anderen Ausführungsformen Aufrüstungen für das Zielsystem 100 auf andere Weise geschehen. Zum Beispiel kann ein Benutzer eine Disk oder ein anderes Speichermedium kaufen, das Befehle enthält, Aufrüstungen gemäß einer Ausführungsform der vorliegenden Erfindung zu implementieren.
Mit Bezug nun auf 2 ist ein Ablaufdiagramm eines Verfahrens gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Wie in 2 gezeigt, kann das Verfahren 200 verwendet werden, um ein Hardwaremerkmal eines Zielsystems aufzurüsten. Das Verfah ren 200 kann damit beginnen, daß es mit einem Zielsystem kommuniziert (Block 205). Zum Beispiel kann ein entfernt stehender Server eines OEM, eines Wiederverkäufers oder dergleichen mit dem Zielsystem kommunizieren. Bei verschiedenen Ausführungsformen kann die Kommunikation für einen Benutzer des Systems transparent sein. Insbesondere kann der entfernte Server nach Information im Hinblick auf eine Konfiguration des Zielsystems anfragen, so daß eine Feststellung getroffen werden kann, ob das System aufgerüstet werden kann.
Demgemäß kann festgestellt werden, ob das Zielsystem für ein Aufrüstung zertifiziert ist (Diamant 210). Bei verschiedenen Ausführungsformen kann Information in einer Tabelle unterstützter Konfigurationen zurück zu dem entfernten Server auf eine Anfrage von dem entfernten Server kommuniziert werden. Wieder kann diese Kommunikation zwischen dem entfernten Server und dem Zielsystem für einen Endbenutzer transparent sein. Basierend auf der Information, die von dem Zielsystem empfangen worden ist, kann der entfernte Server feststellen, daß das Zielsystem für ein Aufrüsten nicht zertifiziert ist. Wenn es nicht zertifiziert ist, kann das Verfahren 200 beendet werden.
Wenn festgestellt wird, daß das Zielsystem für ein Aufrüsten zertifiziert ist, kann als nächstes bestimmt werden, ob der Benutzer wünscht, das System aufzurüsten (Diamant 215). Obwohl verschiedene Arten des Feststellens, ob für ein System gewünscht ist, daß es aufgerüstet wird, vorliegen können, kann bei vielen Ausführungsformen eine Nachricht von dem entfernten Server an das Zielsystem geschickt werden. Es kann bewirkt werden, daß die Nachricht auf dem Zielsystem angezeigt wird, zum Beispiel über einen Pop-up- oder einen anderen Nachrichtenblock, um die Verfügbarkeit des Aufrüstens anzuzeigen. Wenn der Benutzer das Aufrüsten nicht wünscht, kann das Verfahren 200 beendet werden.
Wenn statt dessen ein Benutzer das Aufrüsten wünscht, kann das Zielsystem einen Chiffrierschlüssel an den entfernten Server senden (Block 220). Bei verschiedenen Ausführungsformen kann der Chiffrierschlüssel ein eindeutiger Code sein, der das Zielsystem und/oder eine bestimmte Hardwarekomponente des Systems, z. B. einen Prozessor oder einen Chipsatz, identifiziert.
Unter Verwendung des Chiffrierschlüssels kann der entfernte Server verschlüsselte Befehle erzeugen, um das Aufrüsten zu ermöglichen. Genauer kann der entfernte Server Mikrocodebefehle erzeugen und kann weiter die Befehle verschlüsseln, um nicht autorisierten Zugriff auf die Befehle zu verhindern. Die Mikrocodebefehle können von dem Zielsystem verwendet werden, um in geeigneter Weise eine oder mehrere Hardwarekomponenten zu programmieren, um das/die Merkmal(e) für den Betrieb zu aktivieren. Das entfernte System kann auch Validierungsbefehle zum Senden an das Zielsystem erzeugen, um zu bestätigen, daß das Aufrüsten erfolgreich war und daß das Zielsystem den Code ausführen kann, der das gewünschte Merkmal implementiert. Demgemäß kann der entfernte Server verschlüsselte Aufrüstbefehle an das Zielsystem übertragen (Block 225).
Indem ein Dechiffrierschlüssel verwendet wird, der den verschlüsselten Befehlen entspricht, kann das Zielsystem die Aufrüstbefehle entschlüsseln und das Zielsystem entsprechend programmieren (Block 230). Genauer können die entschlüsselten Mikrocodebefehle verwendet werden, um sicheres Aufrüsten zu ermöglichen, die mit weniger Bedenken für Sicherheitslücken geschehen. Das heißt, Mikrocodebefehle können entschlüsselt und direkt an einen Prozessorkern geschickt werden, wo die Mikrocodebefehle intern ausgeführt werden können, um das Programmieren einzuleiten. Da bei dieser Ausführungsform die gesendeten Befehle im Mikrocode sein können, kann die Möglichkeit für einen Benutzer, die Befehle herauszuziehen oder die Befehle an nicht autorisierte Parteien zur Verfügung zu stellen, beträchtlich reduziert werden.
Bei manchen Ausführungsformen können die Mikrocodebefehle von dem Prozessor ausgeführt werden, um das Programmieren des/der Merkmal(e) einzuleiten, das/die aufgerüstet werden sollen. Zum Beispiel können bei manchen Ausführungsformen die Mikrocodebefehle eine dynamische Programmierlogik für Sicherungen innerhalb eines Prozessors oder einer anderen Hardwarekomponente einleiten, eine oder mehrere Sicherungen durchzubrennen, um einen Weg zur Schaltung freizugeben, der zuvor nicht verfügbar war. Bei diesen Ausführungsformen kann die dynamische Programmierlogik für Sicherungen bewirken, daß eine Quellspannung an eine Sicherungsbank oder dergleichen angelegt wird, um zu bewirken, daß die ausgewählten Sicherungen durchgebrannt (d. h. aktiviert) werden. Nach dem erfolgreichen Brennen kann dann ein Weg zu der Schaltung gebildet werden, die das Merkmal ausführt.
Nach dem Programmieren der Komponente, um das Merkmal zu aktivieren, kann als nächstes festgestellt werden, ob das Aufrüsten erfolgreich war (Diamant 235). Bei verschiedenen Ausführungsformen kann der Code, der von dem entfernten Server gesendet worden ist, verwendet werden, um die Operation des aktivierten Merkmales zu verifizieren. Zum Beispiel kann bei manchen Ausführungsformen ein Validiercode zusammen mit dem Mikrocodebefehlen gesendet werden. Nach dem Beenden des Programmierens kann das Zielsystem den Validierungscode ausführen. Der Validierungscode kann die neu aktivierte Schaltung prüfen, um zu verifizieren, daß sie für ihren beabsichtigten Zweck arbeitet, und genauer um zu verifizieren, daß es in der bestimmten Konfiguration des Zielsystems arbeitet.
Wenn festgestellt wird, daß das Aufrüsten nicht erfolgreich war (Diamant 235), kann die Steuerung zum Block 240 gehen, an dem eine Fehlerbehandlungsprozedur durchgeführt werden kann. Bei verschiedenen Ausführungsformen kann ein Fehlerbehandlungscode auf dem Zielsystem implementiert werden, um den Fehler zu behandeln. Bei manchen Ausführungsformen kann die Fehlerbehandlungsprozedur von der entfernten Quelle heruntergeladen werden. Nachdem der Fehlerbehandlungscode ausgeführt ist, kann dann festgestellt werden, ob der Aufrüstprozeß erneut versucht werden soll (Diamant 245). Wenn zum Beispiel die Fehlerbehandlungsroutine den Fehler korrigiert hat, kann der Aufrüstprozeß erneut versucht werden. Als Alternative kann bestimmt werden, die Aufrüstung jetzt nicht zu bewirken, wobei an diesem Punkt das Verfahren 200 beendet werden kann. Wenn das Aufrüsten erneut versucht werden soll, kehrt die Steuerung zum Block 230 zurück.
Wenn statt dessen am Diamanten 235 festgestellt wird, daß das Aufrüsten erfolgreich war, kann das Aufrüsten an den entfernten Server berichtet werden (Block 250). Genauer kann Information von der Tabelle unterstützte Konfiguration an den entfernten Server geschickt werden, um den erfolgreichen Abschluß des Aufrüstens anzuzeigen. Zusätzlich zu der Infor mation von der Tabelle für unterstützte Konfiguration kann Information, die das Zielsystem identifiziert, enthalten sein, so daß der entfernte Server geeignete Maßnahmen treffen kann.
Genauer kann der entfernte Server ein Konto, das mit dem Zielsystem verknüpft ist, für das Aufrüsten belasten (Block 260). Zum Beispiel kann eine IT-Abteilung eines Unternehmens ein Konto bei dem OEM halten, welches den entfernten Server implementiert. Bei weiteren Ausführungsformen können unterschiedliche Maßnahmen zum Zahlen für Aufrüstungen möglich sein. Zum Beispiel kann bei manchen Ausführungsformen ein einzelner Endbenutzer Kreditkarteninformation zur Verfügung stellen, um Rechnungsbelastungen für eine Aufrüstung zu autorisieren, die von dem Endbenutzer gewünscht wird.
Zusätzlich zum Berechnen des Aufrüstens kann der entfernte Server Information, die das Aufrüsten betrifft, speichern, die zum Beispiel Information umfaßt, welche die Identifizierung des Zielsystems, die bewirkten Aufrüstungen und zusätzliche Information über das Zielsystem betrifft, so wie Plattform, Aufbau, Abbild und dergleichen. Weiter, wie in 2 gezeigt, kann der entfernte Server die Information über das Aufrüsten an eine zentrale Datenbank kommunizieren (Block 270).
Mit Bezug nun auf 3 ist ein Blockschaubild eines Teiles einer dynamischen Programmierlogik für Sicherungen gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Wie in 3 gezeigt kann eine Schaltung 300a verschiedene Register, logische Gatter und Controller umfassen, um das Durchbrennen von Sicherungen für das Aktivieren unterschiedlicher Hardwaremerkmale zu steuern. Wie in 3 gezeigt, ist die Schaltung 300a so gekoppelt, daß sie Daten empfängt, um Sicherungen durchzubrennen. Die Daten können an die Schaltung 300a unter der Steuerung von Mikrocodebefehlen gesendet werden, die von einem entfernten Server empfangen worden sind. Wie in 3 gezeigt, können die einlaufenden Daten an einer Vielzahl von Sperren 310a, b, c empfangen werden. Bei verschiedenen Ausführungsformen kann eine Ein-Bit-Sperre verwendet werden, um Daten für jedes Merkmal zu empfangen, das aufgerüstet werden kann. Obwohl für die Einfachheit der Veranschaulichung in 3 so gezeigt ist, daß drei solcher Sperren umfaßt sind, soll verstanden werden, daß der Umfang der vorliegenden Erfindung nicht derart beschränkt ist. Die Sperren 310 sind so gekoppelt, daß sie von einem ankommenden Taktsignal getaktet werden, zum Beispiel einem Prozessortaktsignal (CPU-Takt). Das ankommende Taktsignal kann auch verwendet werden, um eine Steuersperre 314 zu takten, die so gekoppelt ist, daß sie ein Steuersignal empfängt. Genauer kann das Steuersignal (d. h. ZumAufrüstenBereit) aus ausgeführten Mikrobefehlen erhalten werden.
Um das Durchbrennen ausgewählter Sicherungen zu steuern, kann ein Sicherungsbrenncontroller 325 vorliegen. Bei verschiedenen Ausführungsformen kann der Controller 325 eine programmierbare Logik sein, um eine Sicherungsbrennsequenz einzuleiten. Bei der Ausführungsform der 3 ist der Controller 325 so gekoppelt, daß er ein Rücksetzsignal (d. h. CPU Reset) und ein Steuersignal (d. h. BrennsequenzStarten) von der Sperre 314 empfängt, um eine erste Brennsequenz einzuleiten. Weiterhin ist der Controller 325 so gekoppelt, daß er das ankommende Taktsignal empfangt. Schließlich, wie in 3 gezeigt, ist der Controller 325 so gekoppelt, daß er ein Spannungsstatussignal (VCCIstGut) empfängt. Das Spannungsstatussignal kann von einem Comparator 320 ausgegeben werden, der eine Versorgungsspannung für den Prozessor (CPU VCC) zum Beispiel mit einer Referenzspannung vergleicht. Bei der Ausführungsform, die in 3 gezeigt ist, kann die Referenzspannung (d. h. Stabile VEREF) ungefähr gleich zwei Drittel der Versorgungsspannung sein.
Nach dem Aktivieren des Steuersignals (d. h. BrennsequenzStarten) und unter der Annahme, daß das Rücksetzsignal empfangen worden ist und das Spannungsstatussignal aktiv ist, kann der Controller 325 das Durchbrennen der ausgewählten Sicherungen bewirken. Genauer kann der Controller 325 zunächst ein Signal zum Aktivieren Ladungssteuerung setzen (d. h. LadungspumpeStarten). Dann, bei darauf folgenden Taktzyklen (z. B. Zyklen von einer Mikrosekunde (μs) des CPU-Taktes), kann der Controller 325 ein Signal für jede aus einer Vielzahl redundanter Sicherungen für das ausgewählte Merkmal setzen. Wie in 3 gezeigt, können die geschickten Signale auf einer Vielzahl von Leitungen ausgegeben werden (d. h. SicherungDurchbrennen [3:0]). Wenn die Brennsequenz abgeschlossen ist, kann ein Steuersi gnal für den Abschluß der Brennsequenz (d. h. BrennsequenzFertig) erzeugt werden. Dann kann der Controller 325 alle seine Ausgänge auf Null setzen.
Die Aufmerksamkeit nun auf 4 richtend ist ein zweiter Teil der dynamischen Programmierlogik für Sicherungen gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Wie in 4 gezeigt, kann eine Schaltung 300b Teil derselben Logik sein wie die Schaltung 300a.
Wie in 4 gezeigt, umfaßt die Schaltung 300b eine Ladungspumpe 330, die eine Sicherungsbrennspannung erzeugt, wenn sie aktiviert wird. Die Ladungspumpe 330 ist so gekoppelt, daß sie eine Versorgungsspannung (CPU VCC) und ein Freigabesignal (SpannungPumpen) empfängt, das von einem UND-Gatter 328 ausgegeben wird. Wie in 4 gezeigt, ist das UND-Gatter 328 so gekoppelt, daß es das Ladungssteuersignal und ein invertiertes Steuersignal für den Abschluß der Brennsequenz, d. h. über einen Invertierer 327, empfangt. Wenn somit der Ausgang des UND-Gatters 328 eine logische "Eins" ist und die Versorgungsspannung vorliegt, kann die Ladungspumpe 330 ein Ladungspumpen-Spannungssignal (LadungspumpeAus) erzeugen, um eine Sicherungsbrennspannung an eine erste Sicherungsbank 340 und eine zweite Sicherungsbank 345 zu liefern. Obwohl es in der Ausführungsform der 4 so gezeigt ist, daß eine Quellenspannung von der Versorgungsspannung des Prozessors (d. h. CPU VCC) erhalten wird, kann bei anderen Ausführungsformen eine Hilfsspannungsversorgung verwendet werden. Weiterhin kann anstelle des Verwendens einer über die Ladungspumpe 330 hochgepumpten Spannung eine besondere Quellenspannung der Plattform verwendet werden. Als Alternative kann bei anderen Ausführungsformen eine nominale Versorgungsspannung (z. B. CPU VCC) verwendet werden.
Obwohl es in der Ausführungsform der 4 so gezeigt ist, daß nur zwei Sicherungsbänke enthalten sind, soll verstanden werden, daß der Umfang der vorliegenden Erfindung nicht derart beschränkt ist und bei einer gegebenen Ausführungsform jedwede gewünschte Anzahl von Sicherungsbänken vorliegen kann. Bei verschiedenen Ausführungsformen kann jede Sicherungsbank eine Bank mit redundanten Sicherungen (z. B. vier redundanten Sicherungen) mit getrennter Brennsteuerung für jede Sicherung sein. Weiterhin kann bei verschiedenen Ausführungsformen für jedes potentielle Merkmal, das aktiviert oder aufgerüstet werden soll, eine Sicherungsbank vorliegen. Jedoch soll verstanden werden, daß andere Konfigurationen möglich sind.
Um die ausgewählten Sicherungen in einer gegebenen Sicherungsbank durchzubrennen, kann ein einlaufendes Signal auf einer Leitung, das einer ausgewählten Sicherung innerhalb der Bank entspricht, auf einem logisch hohen Pegel sein. Insbesondere, wie in 4 gezeigt, sind die logischen Gatter 335 und 337 (d. h. UND-Gatter) mit einem Dateneingang der Sicherungsbanken 340 bzw. 345 gekoppelt. Die UND-Gatter 335 und 337 sind so gekoppelt, daß sie ein Merkmal Brennauswahlsignal (MerkmalBrennenRegister [X]) von den Sperren 310 und ein Sicherungsbrennsignal vom Controller 325 empfangen. Wenn von einem der UND-Gatter 335 und 337 ein logisch hoher Pegel ausgegeben wird und das Ladungspumpenspannungssignal vorliegt, wird die geeignete Sicherung durchgebrannt werden. Auf diese Weise kann eine Vielzahl redundanter Sicherungen, die einem gegebenen Hardwaremerkmal entsprechen, unter Steuerung von Befehlen (z. B. Mikrocodebefehlen) eingestellt werden.
Noch weiter mit Bezug auf die 3 und 4 kann die Schaltung 300a und 300b auch verwendet werden, um zu verifizieren, daß eine Sicherungsbrennsequenz richtig durchgeführt worden ist. Demgemäß kann ein Sicherungsverifizier-Controller 360 vorliegen (in der Schaltung 300a). Wie in 3 gezeigt, kann der Controller 360 so gekoppelt werden, daß er verschiedene Eingaben empfängt, einschließlich dem einlaufenden Taktsignal, dem Spannungsstatussignal und dem Rücksetzsignal. Weiterhin kann der Controller 360 so gekoppelt werden, daß er das Brennsequenz-Abschlußsignal vom Controller 325 empfängt. Bei verschiedenen Ausführungsformen kann der Controller 360 leer laufen, wobei alle seine Ausgänge auf Null gesetzt sind, bis er ein Brennsequenz-Abschlußsignal, das aktiv hoch ist, empfängt, welches den Abschluß einer Brennsequenz angibt.
Zu dieser Zeit kann der Controller 360 bei einer Ausführungsform die folgenden Funktionen durchführen: Als erstes kann der Controller 360 ein Sicherung-Abfühlen-Signal (Siche rungAbfühlen) auf ein logisches Hoch setzen. Dann kann er ein Sicherung-Laden-Signal (SicherungLaden) auf einen aktiven hohen Wert setzen. Wenn das Sicherung-Abfühlen-Signal aktiv ist, werden die Sicherungsbänke 340 und 345 Ausgaben erzeugen, um den Brennzustand jeder der einzelnen Sicherungen innerhalb jeder Bank anzuzeigen. Diese Ausgangssignale werden dann wiederum logisch über ODER-Gatter 348 und 349 mit ODER verknüpft, deren Ausgänge an jeweilige Sperren 350 und 352 gekoppelt sind. Wenn diese Sperren durch das Sicherung-Laden-Signal freigegeben werden, werden die Sperren ein Sicherung-Ausgabe-Signal (SicherungAus [x]) ausgeben.
Wie in 4 gezeigt, wird über einen Invertierer 354 das Sicherung-Ausgabe-Signal invertiert, um somit ein Alle-Sicherungen-Signal (AlleSicherunge = Null) und ein nicht inverrtiertes Irgendeine-Sicherung-Signal (IrgendeineSicherung = Eins) zu bilden. Mit Bezug auf 3 ist ein UND-Gatter 356 (d. h. ein UND-Gatter) gekoppelt, um das Irgendeine-Sicherung-Signal zu empfangen, zusammen mit einem Sequenzabschluß-Verifizieren-Signal (VerifiziereSequenzFertig), das von dem Sicherungscontroller 360 erzeugt wird. Wenn beide diese Signale auf ein logisches Hoch gesetzt sind, erzeugt das UND-Gatter 356 eine hohe Ausgabe, die an eine jeweilige der Sperren 374a, b, c geliefert wird, die jede einem entsprechenden Hardwaremerkmal entspricht. Wenn eine der Sperren 374 ein Merkmal-Gültig-Bit (MerkmalGültigBits) erzeugt, gibt dies an, daß das entsprechende Hardwaremerkmal seine Sicherungen erfolgreich programmiert hat.
Wenn im Gegensatz dazu das Alle-Sicherungen-Signal auf einem logisch hohen Pegel ist und das Sequenzabschluß-Verifieren-Signal vom Controller 360 auch auf einem logischen Hoch ist, kann ein UND-Gatter 368 ein auszugebendes Hoch-Signal erzeugen, um einen Wert an eine entsprechende der Sperren 370a, b, c zu liefern, von denen jede ebenfaslls einem gegebenen Merkmal entspricht. Wenn eine dieser Sperren 370 ein logisch hohes Signal ausgibt, zeigt es an, daß ein Sicherungsbrennfehler beim Versuch, das gegebene Hardwaremerkmal zu programmieren, aufgetreten ist. Schließlich kann ein ODER-Gatter 364 gekoppelt werden, um ein Energieversorgung-Ausfall-Signal zu empfangen. Genauer können zwei solcher Energieversorgung-Ausfall-Signale, nämlich ein VCC-Ausfall-vor-Brennen-Signal vom Sicherungs brenncontroller 352 und ein VCC-Ausfall-bevor-fertig-Signal vom Sicherungsverifiziercontroller 260 an die Eingänge eines ODER-Gatters 364 gegeben werden. Wenn eines dieser Signale auf Hoch gesetzt wird, was einen Ausfall der Versorgungsspannung anzeigt, wird das ODER-Gatter 364 ein logisch hohes Signal ausgeben. Dies setzt wiederum eine Sperre 372, um einen Energieausfallfehler anzuzeigen.
Das Merkmal-gültig-Bit (z. B. über eine der Sperren 374a, b, c) kann verwendet werden, um das Merkmal-Aktiviert-MSR 118 der Tabelle 110 unterstützter Konfigurationen in verschiedenen Ausführungsformen zu setzen. Wenn zum Beispiel eine Sicherungsbank für ein Merkmal B erfolgreich programmiert worden ist, kann ein entsprechendes Bit für das Merkmal B innerhalb des Merkmal-Aktiviert-MSR 118 gesetzt werden. Das Zielsystem 100 kann wiederum eine Nachricht an den entfernten Server senden, die das erfolgreiche Programmieren des ausgewählten Merkmals angibt.
Somit können bei verschiedenen Ausführungsformen Hardwaremerkmale in Hardwarekomponenten zum Zeitpunkt der Herstellung implementiert werden, und Benutzer können nach dem Verkauf wählen, ob sie Nutzen aus einem der mehreren Hardwaremerkmalen ziehen wollen. Gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung kann eine sichere/geschützte Art des Freigebens von Merkmalen und das Validieren ihrer Funktionalität in Zielsystemen zur Verfügung gestellt werden. Solches Aufrüsten kann einen Wert für OEMs, IT-Kunden und Endbenutzer hinzufügen. Weiterhin können Hardwarehersteller, OEMs und andere zusätzliche Einkünfte erzeugen, indem für ein späteres Aufrüsten von Merkmalen gesorgt wird, die bereits in Hardware implementiert sind, am Verkaufsort jedoch nicht freigegeben sind. Auch können Endbenutzer beim Aufrüsten von Hardwaremerkmalen schneller ihre Aufrüstungspläne auf sogar noch höhere Endplattformen beschleunigen, was somit den Ersatzzyklus eines PC verringert.
Auch kann es ein Benutzer vermeiden, einen Höchstpreis für ein System am Verkaufsort zu bezahlen, hat jedoch weiter die Flexibilität und Möglichkeit, später vorgesehene Hardwaremerkmale aufzurüsten. Wenn zum Beispiel bestimmte Anwendungen/Einsatzmodelle reifer werden, kann ein Benutzer wählen, dann eine oder mehrere Hardwarekomponenten aufzurüsten, um für weitere Hardwaremerkmale zu sorgen.
Ausführungsformen können in einem Computerprogramm implementiert werden. Somit können diese Ausführungsformen auf einem Speichermedium gespeichert werden, auf dem Befehle gespeichert sind, die verwendet werden können, um ein System so zu programmieren, daß es die Ausführungsformen ausführt. Das Speichermedium kann umfassen, ist jedoch nicht beschränkt auf irgendeinen Typ einer Disk, einschließlich Floppy Disks, optischer Disks, Compaktdisks als Nur-Lese-Speicher (CD-ROMS – Compact Disk Read-Only Memories), wiederbeschreibbare Compaktdisk (CD-RWs – Compact Disk Re Writables) und Magnetoopitische Disks, Halbleitereinheiten, so wie Nur-Lese-Speicher (ROMs – Read-Only Memories), Speicher mit wahlfreiem Zugriff (RAMs – Random Access Memories), so wie dynamische RAMs (DRAMs), löschbare programmierbare Nur-Lese-Speicher (EPROMs – Erasable programmable Read-Only Memories), elektrisch löschbare programmierbare Nur-Lese-Speicher (EEPROMs – Electrically Erasable Programmable Read-Only Memories), Flash-Speicher, magnetische oder optische Karten oder irgendeinen Typ eines Mediums, das zum Speichern elektronischer Befehle geeignet ist. In ähnlicher Weise können Ausführungsformen als Softwaremodule implementiert werden, die von einer programmierbaren Steuervorrichtung ausgeführt werden, so wie einem Computerprozessor oder einer speziell gestalteten Zustandsmaschine.
Ausführungsformen können in unterschiedlichen Systemen implementiert werden. Zum Beispiel können manche Ausführungsformen in einem Multiprozessorsystem implementiert werden (z. B. einem Punkt-zu-Punkt-Bussystem, so wie einem System mit gemeinsamer Systemschnittstelle (CSI – Common System Interface)). Mit Bezug nun auf 5 ist ein Blockschaubild eines Multiprozessorsystems gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Wie in 5 gezeigt, ist das Multiprozessorsystem 400 ein Punkt-zu-Punkt-Bussystem und umfaßt einen ersten Prozessor 470 und einen zweiten Prozessor 480, die über eine Punkt-zu-Punkt-Verbindung 450 gekoppelt sind. Wie in 5 gezeigt, kann jeder der Prozessoren 470 und 480 ein Mehrkernprozessor sein, der einen ersten und einen zweiten Prozessorkern umfaßt (d. h. die Prozessorkerne 474a und b und die Prozessorkerne 484a und b). Der erste Prozessor 470 umfaßt weiter einen Speichercontrollerhub (MCH – Memory Controller Hub) 474 und Punkt-zu-Punkt (P-P)-Schnittstellen 476 und 478. In ähnlicher Weise umfaßt der zweite Prozessor 480 einen MCH 482 und P-P-Schnittstellen 486 und 488. Wie in 5 gezeigt koppeln die MCHs 472 und 482 die Prozessoren an jeweilige Speicher, nämlich einen Speicher 432 und einen Speicher 434, die Teile eines Hauptspeichers sein können, der lokal an die jeweiligen Prozessoren angebunden ist.
Wie in 5 gezeigt, kann der Prozessor 470 eine Tabelle 473 entsprechend einer Ausführungsform der vorliegenden Erfindung umfassen. Genauer kann die Tabelle 473 eine Tabelle unterstützter Konfigurationen sein, die eine Vielzahl von MSRs umfaßt, um Hardwaremerkmale und ihren Aufrüstungszustand zu identifizieren. Weiter kann der Prozessor 470 Neukonfigurierungs-Logik 475 gemäß einer Ausführungsform der vorliegenden Erfindung umfassen. Die Neukonfigurierungs-Logik 475 kann verwendet werden, um Befehle von einem entfernten Server zu empfangen und um innerhalb des Systems gemäß den Befehlen ein oder mehrerer Hardwaremerkmale zu aktivieren. Wie weiter in 5 gezeigt, kann der Prozessor 480 in ähnlicher Weise eine Tabelle 483 und Neukonfigurierungs-Logik 485 gemäß einer Ausführungsform der vorliegenden Erfindung umfassen.
Der erste Prozessor 470 und der zweite Prozessor 480 können über P-P-Schnittstellen 452 bzw. 454 an einen Chipsatz 490 gekoppelt sein. Wie in 5 gezeigt umfaßt der Chipsatz 490 die P-P-Schnittstellen 494 und 498. Weiterhin umfaßt der Chipsatz 490 eine Schnittstelle 492, um den Chipsatz 490 an eine Grafikmaschine 438 mit hoher Leistung zu koppeln. Bei einer Ausführungsform kann ein erwieterter Grafikport (AGP – Advanced Graphics Port)-Bus 439 verwendet werden, um die Grafikmaschine 438 mit dem Chipsatz 490 zu koppeln. Der AGP-Bus 439 kann der Accelerated Graphics Port Interface Specification, Auflage 2.0, veröffentlicht am 4. Mai 1998 von der Intel Corporation, Santa Clara, Kalifornien, entsprechen. Als Alternative kann eine Punkt-zu-Punkt-Verbindung 439 diese Komponenten koppeln.
Weiterhin kann der Chipsatz 490 über eine Schnittstelle 496 an einen ersten Bus 416 gekoppelt werden. Bei einer Ausführungsform kann der erste Bus 416 ein Bus für den Anschluß von Peripheriekomponenten (PCI – Peripheral Component Interconnect) sein, wie er in der PCI Local Bus Specification, Production Version, Auflage 2.1, Juni 1995, definiert ist, oder ein Bus, so wie der PCI Express Bus oder ein anderer I/O-Anschlußbus dritter Generation sein, obwohl der Umfang der vorliegenden Erfindung nicht derart beschränkt ist.
Wie in 5 gezeigt, können verschiedene Eingabe/Ausgabe (I/O – Input/Output)-Vorrichtungen 414 an den ersten Bus 416 gekoppelt werden, zusammen mit einer Busbrücke 418, die den ersten Bus 416 mit einem zweiten Bus 420 koppelt. Bei einer Ausführungsform kann der zweite Bus 420 ein Bus mit niedriger Stiftzahl (LPC – Low Pin Count) sein. Verschiedene Vorrichtungen können an den zweiten Bus 420 gekoppelt werden, zum Beispiel eine Tastatur/Maus 422, Kommunikationsvorrichtungen 426 und eine Datenspeichereinheit 428, die bei einer Ausführungsform einen Code 430 umfassen kann. Die Kommunikationsvorrichtungen 426 können eine Netzwerk-Schnittstellenkarte, eine drahtlose Schnittstelle und dergleichen umfassen, um es dem System 400 zu ermöglichen, mit einem entfernten System zu kommunizieren, um Aufrüstungsbefehle zu empfangen. Weiter kann ein Audio-I/O 424 an den zweiten Bus 420 gekoppelt werden.
Obwohl die vorliegende Erfindung mit bezug auf eine beschränkte Anzahl von Ausführungsformen beschrieben worden ist, werden die Fachleute zahlreiche Modifikationen und Variationen daraus erkennen. Es ist beabsichtigt, daß die angehängten Ansprüche alle solchen Modifikationen und Variationen abdecken, wie sie in den wahren Geist und Umfang dieser vorliegenden Erfindung fallen.
ZUSAMMENFASSUNG:
Bei einer Ausführungsform umfaßt die vorliegende Erfindung ein Verfahren zum Feststellen, ob ein System mit einer Aufrüstung einer Hardwareressource des Systems kompatibel ist, zum Empfangen von Befehlen von einem entfernten Server, um die Hardwareressource aufzurüsten, wenn das System kompatibel ist, und zum Programmieren der Hardwareressource basierend auf den Befehlen. Bei einer solchen Ausführungsform kann die Hardwareressource über programmierbare Sicherungen programmiert werden, um die Schaltung der Hardwareressource freizugeben. Weitere Ausführungsformen sind beschrieben und beansprucht.

Claims

Verfahren, das aufweist: Feststellen, ob ein System mit einer Aufrüstung einer Hardwareressource des Systems kompatibel ist; Empfangen von Befehlen von einem entfernten System, um die Hardwareressource aufzurüsten, wenn das System kompatibel ist; und Programmieren der Hardwareressource basierend auf den Befehlen.
Verfahren nach Anspruch 1, das weiter aufweist: Senden eines Chiffrierschlüssels für das System an das entfernte System, nachdem festgestellt wurde, daß das System kompatibel ist; und Empfangen verschlüsselter Befehle von dem entfernten System, wobei die Befehle Mikrocode aufweisen.
Verfahren nach Anspruch 2, bei dem das Programmieren der Hardwareressource das dauerhafte Programmieren der Hardwareressource über dynamisches Sicherungsbrennen, das entsprechend den Mikorcode-Befehlen durchgeführt wird, aufweist.
Verfahren nach Anspruch 3, bei dem das dynamische Sicherungsbrennen das Freigeben eines Weges zur Schaltung der Hardwareressource, die dem Aufrüsten entspricht, aufweist.
Verfahren nach Anspruch 1, bei dem das Bestimmen, ob das System kompatibel ist, das Analysieren einer Konfigurationstabelle des Systems auf einem Freigabestatus eines Merkmals der Hardwareressource hin, das dem Aufrüsten entspricht, aufweist.
Verfahren nach Anspruch 5, bei dem die Konfigurationstabelle in einem Verkaufsort eingerichtet wird, um das System als aufrüstbar in bezug auf das Merkmal zu zertifizieren, wobei die Zertifikation dazu dient, zu verifizieren, daß das System ein Abbild umfaßt, das mit dem Merkmal kompatibel ist.
Vorrichtung, die aufweist, eine integrierte Schaltung mit einer Merkmalstabelle, um Information im Hinblick auf einen Status eines oder mehrerer Hardwaremerkmale zu speichern, die nach einem Zeitpunkt des Verkaufs eines Systems, das die integrierte Schaltung umfaßt, freigegeben werden sollen.
Vorrichtung nach Anspruch 7, bei der die Merkmalstabelle ein erstes Statusregister aufweist, um Information im Hinblick auf einen Systemunterstützungsstatus für die Hardwaremerkmale zu speichern, wobei das erste Statusregister von einem Verkäufer des Systems gesetzt wird, um zu zertifizieren, ob das System, wie es von dem Verkäufer konfiguriert worden ist, in der Lage ist, die Hardwaremerkmale zu unterstützen.
Vorrichtung nach Anspruch 8, bei der die Merkmalstabelle ein zweites Statusregister aufweist, um Information im Hinblick auf ein Merkmalfreigabestatus für die Hardwaremerkmale zu speichern, wobei das zweite Statusregister von einem Hersteller der integrierten Schaltung eingestellt wird, um das Vorliegen der Schaltung in der integrierten Schaltung, die den Hardwaremerkmalen entspricht, anzugeben.
Vorrichtung nach Anspruch 9, bei der die Merkmalstabelle ein drittes Statusregister aufweist, um Information im Hinblick auf einen aufgerüsteten Status für die Hardwaremerkmale zu speichern, wobei wenigstens ein Teil des dritten Statusregisters nach dem erfolgreichen Aktivieren eines der Hardwaremerkmale gesetzt wird.
Vorrichtung nach Anspruch 7, weiter mit einer dynamischen Programmierlogik für Sicherungen, um die integrierte Schaltung zu programmieren, um wenigstens eines der Hardwaremerkmale entsprechend Mikrocode, der von einer entfernten Quelle empfangen worden ist, zu aktivieren.
Vorrichtung nach Anspruch 1, bei der die dynamische Programmierlogik für Sicherungen einen ersten Sicherungsbrenncontroller, um wenigstens eine Sicherung zu brennen, um das wenigstens eine der Hardwaremerkmale basierend auf dem Mikroco de zu aktivieren, und einen Sicherungsverifiziercontroller, um das Brennen zu verifizieren, aufweist.
Vorrichtung nach Anspruch 12, bei der die integrierte Schaltung einen Prozessor aufweist und weiter mit einem Block des Prozessors, um das wenigstens eine der Hardwaremerkmale auszuführen, wobei der Block an einen Prozessorkern über die wenigstens eine Sicherung gekoppelt ist.
Vorrichtung nach Anspruch 11, bei der die integrierte Schaltung die Hardwaremerkmale umfaßt, wobei die Hardwaremerkmale deaktiviert sind, wenn sie nicht von der dynamischen Programmierlogik für Sicherungen programmiert sind.
Vorrichtung nach Anspruch 7, bei dem die Merkmalstabelle einen zentralen Speicher für Statusinformation, die in Registern der integrierten Schaltung verfügbar ist, aufweist, wobei die Merkmalstabelle für ein externes System sichtbar ist.
Gegenstand, der ein maschinenlesbares Speichermedium aufweist, welches Befehle enthält, die, wenn sie von einer Maschine ausgeführt werden, es der Maschine ermöglichen, ein Verfahren durchzuführen, das aufweist: Feststellen, ob ein Zielsystem qualifiziert ist, eine Hardwarekomponente des Zielsystems aufzurüsten, durch Analyse einer Merkmalstabelle des Zielsystems; und Vorbereiten und Senden von Aufrüstungsbefehlen an das Zielsystem, wobei die Aufrüstungsbefehle bewirken, daß das Zielsystem die Hardwarekomponenten programmiert, um das Aufrüsten zu aktivieren.
Gegenstand nach Anspruch 16, bei dem das Verfahren weiter das Bereitstellen von Validierungsbefehlen an das Zielsystem aufweist, wobei die Validierungsbefehle bestätigen, daß das Aufrüsten des Zielsystems erfolgreich war.
Gegenstand nach Anspruch 16, bei dem das Verfahren weiter aufweist: Belasten eines Kontos, das mit dem Zielsystem verknüpft ist, für das Aufrüsten nach der Bestätigung, daß das Aufrüsten erfolgreich war; und Aufzeichnen von Information im Hinblick auf das Zielsystem und das Aufrüsten in einer zentralen Datenbank, auf die von einem Hersteller der Hardwarekomponente zugegriffen werden kann.
Gegenstand nach Anspruch 16, bei dem das Verfahren weiter das Vorbereiten und Übersenden der Aufrüstungsbefehle in einer verschlüsselten Weise gemäß einem Chiffrierschlüssel, der von dem Zielsystem empfangen worden ist, aufweist.
System, das aufweist: einen Prozessor, der ein Hardwaremerkmal umfaßt, das an einem Verkaufspunkt des Systems nicht aktiviert ist; einen Programmierer, der mit dem Hardwaremerkmal gekoppelt ist, um das Hardwaremerkmal nach dem Verkauf zu aktivieren; und eine Schnittstelle, um das System mit einem entfernten System zu verbinden.
System nach Anspruch 20, bei dem der Prozessor eine Merkmalstabelle aufweist, um Information im Hinblick auf einen Status des Hardwaremerkmals zu speichern.
System nach Anspruch 21, bei dem die Merkmalstabelle ein erstes Statusregister aufweist, um Information im Hinblick auf einen Systemstatus für das Hardwaremerkmal zu speichern, wobei das erste Statusregister von einem Verkäufer des Systems gesetzt wird, um zu zertifizieren, ob das System, wie es von dem Verkäufer konfiguriert worden ist, in der Lage ist, das Hardwaremerkmal zu unterstützen.
System nach Anspruch 20, bei dem der Programmierer eine Programmierlogik für dynamisches Sicherungsbrennen aufweist, um das Hardwaremerkmal entsprechend Befehlen, die von dem entfernten System empfangen worden sind, zu aktivieren.
System nach Anspruch 23, bei dem die dynamische Programmierlogik für Sicherungen einen Controller aufweist, um wenigstens eine Sicherung durchzubrennen, um das Hardwaremerkmal an einen Prozessorkern zu koppeln.
System nach Anspruch 20, bei dem das Hardwaremerkmal ein Sicherheitsmerkmal aufweist.