DE112020006305T5

DE112020006305T5 - Ein-Chip-System, das mehrere CPUs verschiedener Arten betreibt, und Betriebsverfahren desselben

Info

Publication number: DE112020006305T5
Application number: DE112020006305.4T
Authority: DE
Inventors: Yongseok OH; Hoyeonjiki Kim; Taehun Jeong; Moon-Soo Kim
Original assignee: Telechips Inc
Current assignee: TELECHIPS INC., SEONGNAM-SI, KR
Priority date: 2019-12-24
Filing date: 2020-11-25
Publication date: 2022-12-01
Also published as: JP7444994B2; KR102285084B9; US20230020191A1; WO2021132904A1; KR20210081909A; JP2023510131A; KR102285084B1

Abstract

Ein Ein-Chip-System (SoC; system-on-chip) zum Betreiben einer Mehrzahl verschiedener zentraler Verarbeitungseinheiten und ein Verfahren zum Betreiben desselben werden bereitgestellt. Das SoC umfasst eine Mehrzahl zentraler Verarbeitungseinheiten (CPUs), die entsprechende Software-Programme unabhängig voneinander ausführen, einen Bus-Verbinder zum Verbinden der Mehrzahl CPUs, und mindestens ein Zugriffssteuergerät, das mit dem Bus-Verbinder verbunden ist und jeden Zugriff auf eine physikalische Ressource über den Bus-Verbinder für jede CPU steuert, die von der Mehrzahl CPUs geteilt wird.

Description

Querverweis zu verwandten Anmeldungen
Diese Anmeldung beansprucht die Priorität und den Vorteil der koreanischen Patentanmeldung Nr. 10-2019-0174323 , die am 24. Dezember 2019 beim Koreanischen Patentamt eingereicht wurde, deren gesamter Inhalt hierin unter Bezugnahme aufgenommen ist.
Hintergrund
(a) Gebiet
Die vorliegende Erfindung bezieht sich auf ein Ein-Chip-System zum Betreiben heterogener Multi-CPUs und ein Betriebsverfahren desselben.
(b) Beschreibung des verwandten Stands der Technik
Fälle, bei denen eine Mehrzahl zentraler Verarbeitungseinheiten (im Folgenden insgesamt als „CPU“; central processing unit bezeichnet) auf einem einzigen Ein-Chip-System oder System-on-Chip (SoC; system-on-chip) getragen werden, nehmen zu. Derartige Systeme werden klassifiziert in symmetrische Multiprozessorsysteme (SMP; symmetrical multi-processing), bei denen eine Mehrzahl identischer CPUs vorhanden ist, und asymmetrische Multiprozessorsysteme (AMP; asymmetric multi-processing), die aus einer Mehrzahl heterogener CPUs bestehen.
Bei einem SMP besetzt im Wesentlichen ein Betriebssystem (OS; operating system) alle CPUs auf einem SoC und führt Aufgaben durch, indem es die Aufgaben an jede CPU verteilt, was die gesamte Verarbeitungsleistung allgemeiner Aufgaben verbessert.
Währenddessen ist bei einem AMP jede CPU dafür bestimmt, verschiedene bestimmte Aufgaben durchzuführen. Beispielsweise kann eine Last einer CPU, die für allgemeine Zwecke verwendet wird, reduziert werden, indem eine bestimmte CPU exklusiv mit Aufgaben beauftragt wird, wie Grafikverarbeitung und digitale Signalverarbeitung.
Damit mehrere heterogene CPUs auf einem einzigen SoC für bestimmte Aufgaben, die sich voneinander unterscheiden, vorgesehen sind, sollte jede CPU in der Lage sein, unabhängig ein OS zu betreiben. Somit arbeitet jedes OS unabhängig zu unterschiedlichen Zwecken, wenn mehrere heterogene CPUs auf einem einzigen SoC unabhängig OSs entsprechend betreiben. Demgemäß kann eine Wettlaufsituation hinsichtlich des Zugriffs auf eine geteilte physikalische Ressource auftreten.
Herkömmlicherweise wurde Virtualisierungstechnologie in einer Situation verwendet, bei der mehrere OSs, die sich physikalische Ressourcen teilen, betrieben werden.
Die Virtualisierungstechnologie ist eine Technologie zum Abstrahieren einer physikalischen Ressource in eine Mehrzahl virtueller logischer Ressourcen, und die Software, die solch eine Virtualisierung durchführt, wird als ein Hypervisor bezeichnet. Basierend auf einer höheren Zugriffsberechtigung auf eine physikalische Ressource als das OS steuert der Hypervisor einen Zugriff durch ein OS auf eine physikalische Ressource, und verwaltet die physikalische Ressource nach deren Abstraktion. Es erlaubt mehreren OSs, ohne eine Wettlaufsituation auf eine einzige physikalische Ressource zuzugreifen und sie zu verwenden.
Der Hypervisor benötigt jedoch Zeit, um den Zugriff auf die physikalische Ressource durch ein OS zu steuern und die virtuelle logische Ressource zu steuern, was auch dazu führen kann, dass eine zusätzliche Zuweisung eines Speicherbereichs für das Bereiben des Hypervisors benötigt wird.
Ein derartiger zusätzlicher Zeitverbrauch kann zu einer Latenzzeit für eine Aufgabe, die durch mehrere OS verarbeitet werden, die auf dem SoC betrieben werden. Insbesondere kann eine derartige Latenzzeit für eine Aufgabe, die Echtzeit erfordert, eine große Einschränkung darstellen.
Zusammenfassung
Die vorliegende Erfindung stellt ein Ein-Chip-System oder System-on-Chip (SoC; system on chip) zum Betreiben heterogener Multi-OSs bereit, die wechselweise unabhängige Softwareprogramme ausführen, und ein Verfahren zum Betreiben derselben. Die heterogenen Multi-OSs werden betrieben, um ohne eine Wettlaufsituation physikalische Ressourcen zu teilen und den Zugriff durch andere CPUs auf eine physikalische Ressource zu blockieren, die Schutz benötigt.
Gemäß einer Ausführungsform der vorliegenden Erfindung wird ein Ein-Chip-System (SoC) bereitgestellt. Das SoC umfasst eine Mehrzahl zentraler Verarbeitungseinheiten (CPUs; central processing units), die entsprechende Softwareprogramme unabhängig voneinander ausführen, einen Bus-Verbinder, um die Mehrzahl CPUs zu verbinden, und mindestens ein Zugriffssteuergerät, das mit dem Bus-Verbinder verbunden ist und jeden Zugriff auf eine physikalische Ressource für jede CPU steuert, die von der Mehrzahl der CPUs über den Bus-Verbinder geteilt wird.
Das mindestens eine Zugriffssteuergerät kann eine Zugriffssteuerung durchführen, die mindestens eine der folgenden Anfragen einschließt: eine Anfrage zum Teilen einer physikalischen Ressource, eine Anfrage zum Zugriff auf eine physikalische Ressource, und eine Kommunikation zwischen CPUs einschließlich Übermittelung von Zustandsinformationen einer CPU.
Die Mehrzahl CPUs kann mindestens zwei CPUs umfassen, die physikalische Ressourcen teilen, einschließlich eines Speichers über eine erste Bus-Schnittstelle, und kann des Weiteren ein Gerät zum Steuern der Ressourcenteilung umfassen, das einen Zugriff auf eine physikalische Ressource steuert, die exklusiv zwischen den mindestens zwei CPUs unter den geteilten physikalischen Ressourcen verwendet wird.
Die mindestens zwei CPUs können eine erste CPU umfassen, die eine erstes Softwareprogramm ausführt, und eine zweite CPU, die ein zweites Softwareprogramm ausführt, das sich von dem ersten Softwareprogramm unterscheidet. Das Ressourcenteilungsteuergerät kann einen Speicherbereich, auf den das erste Softwareprogramm geladen ist, physikalisch zwischen physikalischen Ressourcen trennen, die exklusiv zwischen den mindestens zwei CPUs verwendet werden, und einen Zugriff durch die zweite CPU auf den getrennten Speicherbereich blockieren.
Das Ressourcenteilungsteuergerät kann eine Firmware betreiben, die ein höheres Berechtigungslevel hat als das erste Softwareprogramm und das zweite Softwareprogramm, und kann einen Zugriff auf die exklusiv verwendete physikalische Ressource durch die Firmware steuern.
Die Mehrzahl an CPUs kann eine dritte CPU umfassen, die mit einem statischen Direktzugriffsspeicher (RAM; random access memory) und einer Mehrzahl von Geräten über eine zweite Bus-Schnittstelle verbunden ist, und ein drittes Softwareprogramm ausführt. Des Weiteren kann mindestens ein Zugriffssteuergerät ein erstes Zugriffssteuergerät umfassen, das zwischen der zweiten Bus-Schnittstelle und dem Bus-Verbinder platziert ist, und Zugriffe der anderen CPUs auf den statischen RAM und die Mehrzahl von Geräten steuert.
Die Mehrzahl CPUs kann eine vierte CPU umfassen und über eine dritte Bus-Schnittstelle verbunden ist mit einem Code-RAM, auf den Programmcodes einschließlich eines Bootcodes geladen sind, und einem Daten-RAM, auf den Nutzerdaten geladen werden, und ein viertes Softwareprogramm ausführt. Und das mindestens eine Zugriffssteuergerät kann des Weiteren ein zweites Zugriffssteuergerät umfassen, das zwischen der dritten Bus-Schnittstelle und dem Bus-Verbinder platziert ist, und Zugriffe von anderen CPUs auf den Code-RAM und den Daten-RAM steuert.
Die erste CPU kann einen Quadcore/Vierfachkern umfassen, und die zweite CPU, die dritte CPU und die vierte CPU können einen Singlecore/Einzelkern umfassen.
Die Mehrzahl CPUs kann unabhängig entsprechende Softwareprogramme ausführen, nachdem die dritte CPU, die erste CPU, die vierte CPU und die zweite CPU nacheinander gebootet wurden.
Gemäß einer anderen Ausführungsform der vorliegenden Erfindung wird ein Verfahren zum Betreiben einer Mehrzahl zentraler Verarbeitungseinheiten (CPUs; central processing units) bereitgestellt, die auf einem einzigen Ein-Chip-System (SoC; system-on-chip) installiert sind. Das Verfahren umfasst Ausführen eines Bootcodes des SoC in einer ersten CPU, und Ausführen eines primären Bootladers bzw. Startladers, der von dem Bootcode in der ersten CPU aufgerufen wird. Der erste Bootlader kann ein erstes Softwareprogramm der ersten CPU ausführen und einen sekundären Bootlader, der in einer zweiten CPU ausgeführt ist, aufrufen. Der sekundäre Bootlader kann einen tertiären Bootlader aufrufen, der ein zweites Softwareprogramm der zweiten CPU ausführt, und ein drittes Softwareprogramm einer dritten CPU ausführen. Und der tertiäre Bootlader kann ein viertes Softwareprogramm einer vierten CPU ausführen.
Das erste Software-Programm kann ein Betriebssystem (OS; operating system) umfassen, das zweite Softwareprogramm kann einen Linuxkernel umfassen, das dritte Softwareprogramm kann ein Echtzeit-Betriebssystem (RTOS; real-time operating system) umfassen, und das vierte Softwareprogramm kann eine Firmware umfassen.
Das dritte Softwareprogramm kann von dem zweiten Bootlader ausgeführt werden, wenn ein erstes Zugriffssteuergerät, das mit einem Bus-Verbinder verbunden ist, der die zweite CPU und die dritte CPU verbindet, es der zweiten CPU gestattet, auf die dritte CPU zuzugreifen.
Das vierte Softwareprogramm kann von dem dritten Bootlader ausgeführt werden, wenn ein zweites Zugriffssteuergerät, das mit einem Bus-Verbinder verbunden ist, der die zweite CPU und die vierte CPU verbindet, es der zweiten CPU gestattet, auf die vierte CPU zuzugreifen.
Gemäß einer Ausführungsform der vorliegenden Erfindung kann in einem Ein-Chip-System (SoC; system-on-chip), das heterogene Multi-CPUs betreibt, eine physikalische Ressource ohne eine Wettlaufbedingung zwischen jeder der CPUs geteilt werden, ohne Virtualisierungstechnologie zu verwenden, wie es im Stand der Technik der Fall ist, und ein Zugriff einer CPU auf einige geteilte Ressourcen kann gesteuert werden. Demgemäß wird eine zusätzliche Latenzzeit aufgrund der Verwendung der Virtualisierungstechnologie nicht verursacht. Des Weiteren kann eine Leistungsminderung aufgrund eines Mehraufwands gelöst werden.
Zusätzlich ist es für Anwendungen, die eine Aufgabenverarbeitung in Echtzeit erfordern, möglich, eine Umgebung bereitzustellen, in der Echtzeit garantiert ist.
Figurenliste

1 ist ein Konfigurationsdiagramm eines Ein-Chip-Systems (SoC; system-on-chip) gemäß einer Ausführungsform der vorliegenden Erfindung.
2 ist ein Diagramm, das zwei Arten von Steuerdomänen auf dem Ein-Chip-System (SoC), das in 1 gezeigt ist, darstellt.
3 ist ein Diagramm, das eine Boot-Reihenfolge aus Sicht eines Speichers gemäß einer Ausführungsform der vorliegenden Erfindung zeigt.
4 ist ein Diagramm, das einen Boot-Betrieb eines SoC gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.

Detaillierte Beschreibung der Ausführungsformen
In der folgenden detaillierten Beschreibung werden lediglich bestimmte Ausführungsformen der vorliegenden Erfindung gezeigt und beschrieben, einfach mittels Darstellung. Wie der Fachmann erkennen würde, können die beschriebenen Ausführungsformen auf verschiedene unterschiedliche Weisen modifiziert werden, ohne von der Idee oder dem Umfang der vorliegenden Erfindung abzuweichen. Demgemäß sind die Figuren und die Beschreibung von darstellender Natur und nicht einschränkend zu verstehen. In der gesamten Beschreibung benennen die gleichen Bezugszeichen die gleichen Elemente.
Wenn auf ein Teil als einen bestimmten Bestandteil „aufweisend“ oder „umfassend“ Bezug genommen wird, bedeutet dies in der gesamten Beschreibung, dass es des Weiteren einen anderen Bestandteil aufweisen kann, anstatt andere Teile auszuschließen, es sei denn, dies wäre anderweitig angegeben.
In der Beschreibung beziehen sich die Begriffe wie „... Einheit“, „...... er/or“, „... modul“ und dergleichen auf Einheiten, die mindestens eine Funktion oder einen Vorgang durchführen, die mit einer Hardware, einer Software oder einer Kombination daraus umgesetzt werden können.
In der Beschreibung kann „Übermittlung“ oder „Bereitstellung“ direkte Übermittlung oder Bereitstellung sowie indirekte Übermittlung oder Bereitstellung durch andere Vorrichtungen oder mittels einer Umgehung umfassen.
In der Beschreibung können Ausdrücke, die in dieser Beschreibung im Singular verwendet werden, als Singular oder Plural verstanden werden, außer es wird ein expliziter Ausdruck wie „ein“ oder „einzig“ verwendet.
In dieser Beschreibung beziehen sich die gleichen Bezugszeichen auf die gleichen Bestandteile durch alle Zeichnungen hindurch, und „und/oder“ umfasst jeden der Bestandteile und alle Kombinationen davon.
Die Aufzählungszahlen wie „erste/s/r“ und „zweite/s/r“ werden zur Beschreibung verschiedener Bestandteile verwendet, schränken die Bestandteile jedoch nicht ein. Des Weiteren werden die Aufzählungszahlen lediglich zur Unterscheidung eines Bestandteils von einem anderen Bestandteil verwendet. Beispielsweise kann, ohne vom Umfang der vorliegenden Offenbarung abzuweichen, auf einen ersten Bestandteil als ein zweiter Bestandteil Bezug genommen werden, und gleichermaßen kann auf einen zweiten Bestandteil auch als ein erster Bestandteil Bezug genommen werden.
In dieser Beschreibung bezieht sich „Bootlader/Startlader“ auf ein Programm, das ein Softwareprogramm aus einem bestimmten Speichermedium (z.B. einem externen Speichergerät) liest und das Programm auf einer Hauptspeichereinheit (z.B. RAM) installiert, sodass ein Nutzer ein elektronisches Gerät verwenden kann, wenn das elektronische Gerät gebootet oder gestartet wird.
1 ist ein Konfigurationsdiagramm eines Ein-Chip-Systems (SoC; system-on-chip) gemäß einer Ausführungsform der vorliegenden Erfindung, und 2 ist ein Diagramm, das Steuerdomänen zweier Arten auf dem Ein-Chip-System (SoC) darstellt, das in 1 gezeigt ist.
Unter Bezugnahme auf 1 umfasst ein SoC 100 vier zentrale Verarbeitungseinheiten (im Folgenden insgesamt als „CPU“ bezeichnet) 101, 103, 105 und 107.
Das SoC 100 umfasst eine CPU_1 101, eine CPU_2 103, eine CPU_3 105 und eine CPU_4 107. Zu diesem Zeitpunkt sind die CPU_1 101, die CPU_2 103, die CPU_3 105 und die CPU_4 107 CPUs verschiedener Art und führen entsprechende Softwareprogramme aus, die unabhängige Aufgaben durchführen.
Hier kann die CPU_1 101 ein Systembetriebssystem (OS) ausführen. Das System-OS führt Mehrzweck-Aufgaben aus, einschließlich Interaktion mit einem Nutzer, und kann beispielsweise ein Android-OS sein.
Die CPU_2 103 kann ein Softwareprogramm ausführen, das eine besondere Aufgabe verarbeitet, die schnelle Verarbeitung ohne Nutzerinteraktion verlangt. Beispielsweise kann die CPU_2 103 einen Linux-Kernel ausführen.
Die CPU_3 105 kann ein Softwareprogramm ausführen, das eine Aufgabe verarbeitet, die Echtzeit-Verarbeitung verlangt. Beispielsweise kann die CPU_3 105 ein Echtzeit-Betriebssystem (RTOS; real time operating system) ausführen.
Die CPU_4 107 kann einen im Vergleich zu anderen CPUs 101, 103 und 105 preisgünstigen und technisch relativ einfachen Prozessor umfassen. Die CPU_4 107 kann eine Sicherheitsfirmware ausführen, die Verschlüsselungs-/Entschlüsselungsoperationen durchführt, wie eine Integritätüberprüfung.
Die CPU_1 101 kann einen Quad-Core-Prozessor umfassen. Die CPU_2 103, die CPU 3 105 und die CPU_4 107 können einen Single-Core-Prozessor umfassen.
Somit führen die CPU_1 101, die CPU_2 103, die CPU_3 105 und die CPU_4 107 unabhängig voneinander Software-Programme aus. Daher kann zum Beispiel das Software-Programm der CPU_1 101 alle vier Kernprozessoren verwenden. Insbesondere kann die CPU_1 101 alle vier Kernprozessoren belegen, wenn das Software-Programm der CPU_1 101 das System-OS ist, wodurch eine Leistung des gesamten SoC 100 verbessert wird.
Die CPU_1 101 und die CPU_2 103 sind mit einem synchronen dynamischen Direktzugriffsspeicher (SDRAM; synchronous dynamic random access memory) 111, einem zugeordneten Gerät 113, und einer Mehrzahl geteilter Geräte 115 über einen Bus 109 verbunden. Hierbei kann das zugeordnete Gerät 113 und die Mehrzahl geteilter Geräte 115 einen universellen asynchronen Empfänger/Sender (UART; universal asynchronous receiver/transmitter), einen interintegrierten Schaltkreis (I2C), ein GPSB, eine eingebettete Multimedia-Karte (eMMC; embedded multi-media card) und dergleichen umfassen.
Zu diesem Zeitpunkt wird ein Ressourcenteilungsteuergerät 117 zwischen die CPUs (die CPU_1 101 und die CPU_2 103) und den Bus 109 gesetzt.
Das Ressourcenteilungsteuergerät 117 steuert einen Zugriff auf eine exklusiv verwendete physikalische Ressource unter physikalischen Ressourcen, die von der CPU_1 101 und der CPU_2 103 geteilt werden.
Die CPU_3 105 ist mit einem statischen Direktzugriffsspeicher (SRAM; static random-access memory) 121, einem zugeordneten Gerät 123 und einer Mehrzahl geteilter Geräte 125 über einen Bus 119 verbunden. Hier können das zugeordnete Gerät 123 und die Mehrzahl geteilter Geräte 125 einen UART, einen Eingangserfassungszeitzähler (ICTC; input capture timer counter), einen seriellen Flash-Speicher, ein GPSB und dergleichen umfassen.
Zu diesem Zeitpunkt können UART, GPSB und dergleichen CPU-alleinige Ressourcen, die nicht geteilt werden.
Die CPU_4 ist mit einem Code-RAM 129 und einem Daten-RAM 131 über einen Bus 127 verbunden. Der Code-RAM 129 und der Daten-RAM 131 laden ein Software-Programm (z.B. Sicherheitsfirmware) der CPU_4 107. In diesem Fall kann der Daten-RAM 131 eine zugeordnete physikalische Ressource sein, die nicht geteilt wird und ausschließlich von der CPU_4 107 belegt wird. Dementsprechend kann ein Zugriff auf den Daten-RAM 131 durch ein Zugriffssteuergerät _2 137 blockiert werden.
Die Busse 109, 119 und 127 sind mit physikalischen Ressourcen 111, 115, 121, 125, 129 und 131 verbunden, die mit jedem der Busse 109, 119, 127 durch Verbindungen über einen Bus-Verbinder 133 verbunden sind. Dementsprechend können die CPU_1 101, die CPU_2 103, die CPU_3 105 und die CPU_4 107 die physikalische Ressourcen 111, 115, 121, 125, 129 und 131 teilen. Beispielsweise kann die CPU_1 101 auf die physikalische Ressourcen 121 und 125 zugreifen, die mit dem Bus 119 der CPU_3 105 verbunden sind. Hier kann der Daten-RAM 131 gezielt von dem Zugriffssteuergerät_2 137 geteilt werden.
In diesem Fall teilen sich die CPU_1 101 und die CPU_2 103 alle physikalischen Ressourcen 111, 113 und 115, die kein Prozessor sind.
Wenn jedoch alle physikalischen Ressourcen 111, 115, 121, 125, 129 und 131 von allen CPUs 101, 103, 105 und 107 wie oben beschrieben geteilt werden, kann eine Wettlauf-Situation beim Zugriff auf die physikalischen Ressourcen 111, 115, 121, 125, 129 und 131 entstehen. Damit sich jede der CPUs 101, 103, 105 und 107 die physikalischen Ressourcen 111, 115, 121, 125, 129 und 131 ohne eine solche Wettlauf-Situation teilen, definiert die Ausführungsform der vorliegenden Erfindung zwei Arten von Steuerdomänen P1 und P3.
Unter Bezugnahme auf 2 wird eine Vertrauenszonen-Steuerdomäne P1 durch ein Ressourcenteilungssteuergerät 117 gesteuert.
Zusätzlich dazu, dass sie einen Speicher anstelle eines Bus-Verbinders 133 umfassen, teilen sich eine CPU_1 (101) und eine CPU_2 (103) alle physikalischen Ressourcen 111, 113 und 115. Zu diesem Zeitpunkt blockiert das Ressourcenteilungssteuerungsgerät 117 durch eine physikalische Teilung einen Zugriff auf eine physikalische Ressource, die exklusiv unter den geteilten physikalischen Ressourcen verwendet werden sollte.
Das Ressourcenteilungssteuergerät 117 verwendet ARM Trustzone-Technologie (ARM Trustzone Technology), um die Verwendung physikalischer Ressourcen zu trennen. Insbesondere kann das Ressourcenteilungssteuergerät 117 durch Verwendung der ARM Trustzone-Technologie eine Firmware betreiben, die eine höhere Berechtigung als ein OS hat.
Das Ressourcenteilungssteuergerät 117 kann ein exklusives Zugriffsrecht für die alleinige CPU_1 101 auf manche physikalische Ressourcen unter den durch die CPU_1 101 und die CPU_2 103 geteilten physikalische Ressourcen festlegen. Das Ressourcenteilungssteuergerät 117 blockiert den Zugriff durch die CPU_2 103 auf die physikalische Ressource, für die ein exklusives Zugriffsrecht durch lediglich die CPU_1 101 festgelegt ist.
Die Zugriffssteuerdomäne P3 wird durch das Zugriffssteuergerät_1 135 und das Zugriffssteuergerät_2 137 gesteuert, die mit dem Bus-Verbinder 133 verbunden sind.
Das Zugriffssteuergerät_1 135 ist zwischen dem Bus 119 und dem Bus-Verbinder 133 verbunden.
Das Zugriffssteuergerät_1 135 legt eine separate Zugriffsberechtigung auf die physikalischen Ressourcen 121, 123 und 125 fest, die über den Bus 119 verbunden sind. Diese Zugriffsberechtigung kann eine Zugriffsblockiereinstellung anderer CPUs 101, 103 und 107 auf die CPU_3 105 oder die physikalische Ressourcen 121, 123 und 125 umfassen. Das Zugriffssteuergerät_1 135 kann Verkehr blockieren, der über den Bus-Verbinder 133 auf den Bus 119 gerichtet ist.
Das Zugriffssteuergerät_2 137 ist zwischen dem Bus 127 und dem Bus-Verbinder 133 verbunden.
Das Zugriffssteuergerät_2 137 legt eine separate Zugriffsberechtigung auf die physikalischen Ressourcen 129 und 131 fest, die über den Bus 127 verbunden sind. Diese Zugriffsberechtigung kann eine Zugriffsblockiereinstellung anderer CPUs 101, 103 und 105 auf die CPU_4 107 oder die physikalische Ressourcen 129 und 131 umfassen.
Das Zugriffssteuergerät_2 137 kann Verkehr blockieren, der über den Bus-Verbinder 133 auf den Bus 127 gerichtet ist.
Hier kann der Verkehr, der durch das Zugriffssteuergerät_1 135 und das Zugriffssteuergerät_2 137 blockiert ist, eine Anfrage zum Teilen einer physikalischen Ressource, eine Anfrage zum Zugreifen auf eine physikalische Ressource, eine Anfrage zum Kommunizieren zwischen CPUs und dergleichen umfassen.
Die Anfrage zum Kommunizieren zwischen CPUs kann eine Anfrage zum Übertragen einer Information zu einem abnormalen Status jeder der CPUs 101, 103, 105 und 107 umfassen. Hier kann die Information zu einem abnormalen Status mindestens eine der Folgenden umfassen: Reset/Zurücksetzen, Neustart, Reboot und Absturz.
Eine mit der CPU_3 105 oder CPU_4 107 verbundene physikalische Ressource kann als solche durch Verwendung der Zugriffssteuergeräte 135 und 137 geteilt oder geschützt werden.
Wie oben unter Bezugnahme auf 1 und 2 beschrieben, kann gemäß einer Ausführungsform der vorliegenden Erfindung jede der CPUs 101, 103, 105 und 107 unabhängig ein Softwareprogramm ausführen und eine physikalische Ressource ohne eine Wettlauf-Situation teilen.
Nun wird ein Boot/Start-Verfahren zum Umschalten jeder der CPUs 101, 103, 105 und 107 in einen Betriebszustand beschrieben. Eine Boot/Start-Reihenfolge umfasst einen Vorgang des Betreibens einer Betriebsumgebung zwischen jeder der CPUs 101, 103, 105 und 107 und eines Software-Programms.
Vier heterogene CPUs 101, 103, 105 und 107 auf einem SoC 100 betreiben unabhängige Software-Programme bzw. führen Aufgaben verschiedener Zwecke durch. Wie oben beschrieben verfügt jede der CPUs 101, 103, 105 und 107 über ihre eigene physikalische Ressource, und teilt und verwendet die Ressource mit anderen CPUs 101, 103, 105 und 107. Dementsprechend werden durch Vereinheitlichung eines Boot-Schrittes, in dem eine Initialisierung physikalischer Ressourcen durchgeführt wird, die Ressourcen ohne Eintreten einer Wettlauf-Situation initialisiert.
3 ist ein Diagramm, das eine Boot-Reihenfolge aus der Sicht eines Speichers gemäß einer Ausführungsform der vorliegenden Erfindung zeigt.
Unter Bezugnahme auf 3 wird eine Boot-Reihenfolge für eine Ressourceninitialisierung ohne Eintreten einer Wettlauf-Situation hinsichtlich einer Speicherverwendung gezeigt.
Wenn Strom an einem SoC 100 eingeschaltet wird, lädt eine CPU_3 (105 in 1) einen Chip-Bootcode (Chipboot ROM Code), der in einem ROM gespeichert ist, auf einen SRAM (121 in 1 und 2) und führt dann den Chip-Bootcode aus. Der Chip-Bootcode ruft einen primären Bootlader auf. Dann lädt die CPU_3 105 den aufgerufenen primären Bootlader auf den SRAM (121 in 1 und 2) und führt den primären Bootlader aus.
Der primäre Bootlader ruft einen sekundären Bootlader einer CPU_1 (101 in 1 und 2) auf. Die CPU_1 101 lädt den aufgerufenen sekundären Bootlader auf den SRAM 121 und führt den sekundären Bootlader aus. Der sekundäre Bootlader ruft einen tertiären Bootlader auf.
Die CPU_1 101 lädt den aufgerufenen tertiären Bootlader auf einen SDRAM (111 in 1 und 2) und führt dann den tertiären Bootlader aus.
Der primäre Bootlader ruft ein RTO der CPU_3 105 auf, und das aufgerufene RTOS kann ausgeführt werden, indem eine Ausführung vor Ort (XIP; eXecution In Place) auf einen seriellen NOR Flash Speicher (SNOR; serial NOR flash memory) der CPU_3 (105) angewendet wird. Hierbei ist der SNOR aufgrund der physikalischen Merkmale ein nichtflüchtiger Speicher im Gegensatz zu dem SRAM 121 und dem SDRAM 111. Nachdem der SNOR im Gegensatz zu anderen flüchtigen Speichern einen Byte-Zugriff unterstützt, kann ein RTOS direkt auf dem SNOR ausgeführt werden, ohne dass es auf einen Speicher wie den SDRAM 111 geladen wird.
Der sekundäre Bootlader ruft eine Firmware einer CPU_4 (107 in 1 und 2) auf und die aufgerufene Firmware wird auf einen Code-RAM (129 in 1 und 2) der CPU_4 (107) geladen.
Der tertiäre Bootlader ruft das Android-OS der CPU_1 101 und den Linux-Kernel der CPU 2 (103 von 1 und 2) auf, und das aufgerufene Android-OS und der Linux-Kernel werden auf den SDRAM 111 geladen.
Somit laufen die vier heterogenen CPUs 101, 103, 105 und 107 parallel zum Zeitpunkt des Stromeinschaltens. Die heterogenen CPUs 101, 103, 105 und 107 werden nacheinander in einer Reihenfolge CPU 3 105 → CPU_1 101 → CPU 2 103 → CPU_4 107 betrieben, und führen dann unabhängig entsprechende Software-Programme aus.
4 ist ein Diagramm, das einen Boot-Betrieb eines SoC gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
Unter Bezugnahme auf 4 läuft, wenn heterogene CPUs 101, 103, 105 und 107 auf einem SoC 100 eingeschaltet werden, eine CPU_3 (105 in 1 und 2) zuerst.
Nach Initialisierung (oder Reset/Zurücksetzen) (S103), führt die CPU_3 105 eine Grundaufgabe zum Booten durch, indem ein Chip Bootcode (Chipboot ROM Code) ausgeführt wird, der zuvor auf einen ROM geladen wurde.
Die CPU_3 105 führt einen primären Bootlader aus, der von einem Speichergerät 115, 123 oder 125 durch den Chip Bootcode aufgerufen wird (S107). Die CPU_3 105 führt eine Grundaufgabe zum Betreiben eines Software-Programms der CPU 3 105 durch, indem der primäre Bootlader ausgeführt wird, und fährt mit einer Vorbereitung zum Betreiben der CPU_1 (101 in 1 und 2) fort. Die Vorbereitung umfasst ein Aufrufen eines sekundären Bootlader und eine Aufgabe zum Antreiben der CPU_1 101.
Die CPU 3 (105) überträgt das Aufrufen des sekundären Bootlader auf die CPU_1 (101) (S109).
Die CPU 3 105 führt einen ROTS aus, der ein unabhängiges OS (S111) ist.
Die CPU_1 101 führt den sekundären Bootlader aus, der von der CPU_3 105 aufgerufen wurde (S113). Hier kann der sekundäre Bootlader eine auf ARM vertrauende Firmware (ARM Trusted Firmware) sein.
Der sekundäre Bootlader bereitet sich für das Betreiben der CPU_4 (107 in 1 und 2) vor und ruft einen tertiären Bootlader auf. Das heißt die CPU 1 101 fordert, dass eine Firmware der CPU_4 107 ausgeführt wird, indem der sekundäre Bootlader ausgeführt wird (S115).
Die CPU_1 101 führt den tertiären Bootlader aus, der durch den sekundären Bootlader (S117) aufgerufen wird.
Wie oben beschrieben, dient der sekundäre Bootlader nicht nur als ein Bootlader sondern auch als eine sichere Firmware, sodass eine Mehrzahl unabhängiger Software-Programme physikalische Ressourcen sicher teilen können. Dafür behält der sekundäre Bootlader auf dem SDRAM (111 in 1 und 2) manche auszuführende Codes als die sichere Firmware selbst nach dem Boot-Schritt bei.
Der sekundäre Bootlader als die sichere Firmware gestattet es der CPU_1 101 und CPU 2 (103 in 1 und 2), wechselweise exklusiv eine geteilte physikalische Ressource zu verwenden. Im Speziellen wird der sekundäre Bootlader in einem Ausführungsmodus mit einer höchsten Berechtigung in der CPU_1 101 betrieben. Der sekundäre Bootlader schränkt einen Zugriff auf physikalische Ressourcen durch Software-Programme ein, die in jeder der CPU_1 101 und der CPU_2 103 ausgeführt werden, wodurch eine Wettlauf-Situation beseitigt wird, die zwischen der CPU_1 101 und der CPU_2 103 auftreten kann.
Die CPU_1 (101) wird von einer Abhängigkeitsbeziehung mit der CPU_3 (105) durch Ausführen des sekundären Bootlader unabhängig. Im Ergebnis verliert die CPU 3 105 eine Berechtigung zum Starten und Beenden der CPUs 101, 103 und 107, abgesehen von sich selbst.
Der tertiäre Bootlader der CPU_1 101 treibt die CPU_2 103 an, indem der Linux-Kernel der CPU 2 (103 in 1 und 2) aufgerufen wird (S119). Als Nächstes führt der tertiäre Bootlader der CPU_1 101 ein Android OS aus (S121).
Sobald alle Boot-Prozesse beendet sind, können die vier heterogenen CPUs 101, 103, 105 und 107 schließlich unabhängige Software-Programme betreiben, die Aufgaben verschiedener Zwecke durchführen. Daher belegt im Gegensatz zur herkömmlichen Verwendungsart von Virtualisierungstechnologie kein einziges Software-Programm die gesamte CPU. Daher ist es selbst dann, wenn eine Abnormalität in einem Software-Programm oder einer CPU auftritt, möglich, eine Gestaltung vorzunehmen, sodass nur einige Software-Programme oder die CPU neu angetrieben wird, bei denen/der die Abnormalität auftritt, ohne das gesamte System 100 anzutreiben, im Gegensatz zu dann, wenn Virtualisierungstechnologie verwendet wird.
Zusätzlich dazu steuert in Sachen Geräteteilung dann, wenn Virtualisierungstechnologie verwendet wird, ein zentrales Steuerprogramm den Gerätezugriff. Zu diesem Zeitpunkt entsteht ein Mehraufwand, da alle CPUs das Steuerprogramm durchlaufen sollten. Daher kann im Falle einer Echtzeit-Aufgabe (zeitkritisch) eine Virtualisierungstechnologie nicht verwendet werden. Gemäß einer Ausführungsform der vorliegenden Erfindung besteht jedoch nicht ein zusätzliches Problem des Mehraufwands, da die CPU_3 105, die eine Echtzeit-Aufgabe wie ein RTOS durchführt, ein zugeordnetes Gerät 123 eigens nutzt.
Die oben beschriebene Ausführungsform der vorliegenden Erfindung wird nicht durch den Apparat und das Verfahren umgesetzt, sondern kann durch ein Programm zur Realisierung einer Funktion umgesetzt werden, entsprechend der Konfiguration der Ausführungsform der vorliegenden Erfindung oder durch ein Aufzeichnungsmedium, in dem das Programm aufgezeichnet wird.
Während diese Erfindung in Zusammenhang damit, was derzeit als praktische Ausführungsformen verstanden wird, beschrieben wurde, versteht es sich, dass sich die Erfindung nicht auf die offenbarten Ausführungsformen beschränkt. Es ist im Gegenteil beabsichtigt, verschiedene Modifikationen und äquivalente Anordnungen abzudecken, die in der Idee und dem Umfang der anhängenden Ansprüche enthalten sind.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

KR 1020190174323 [0001]

Claims

Ein Ein-Chip-System (SoC; system-on-chip) umfassend: eine Mehrzahl zentraler Verarbeitungseinheiten (CPUs; central processing units), die entsprechende Software-Programme unabhängig voneinander ausführen; einen Bus-Verbinder zum Verbinden der Mehrzahl CPUs; und mindestens ein Zugriffssteuergerät, das mit dem Bus-Verbinder verbunden ist und jeden Zugriff auf eine physikalische Ressource für jede CPU steuert, die von der Mehrzahl CPUs über den Bus-Verbinder geteilt wird.
Das SoC gemäß Anspruch 1, wobei das mindestens eine Zugriffssteuergerät eine Zugriffssteuerung durchführt, umfassend mindestens eine der folgenden Anfragen: eine Anfrage zum Teilen einer physikalischen Ressource, eine Anfrage zum Zugreifen auf eine physikalische Ressource, und eine Kommunikation zwischen CPUs einschließlich Übermittelung von Zustandsinformationen einer CPU.
Das SoC gemäß Anspruch 1, wobei die Mehrzahl CPUs mindestens zwei CPUs umfasst, die sich über eine erste Bus-Schnittstelle physikalische Ressourcen einschließlich eines Speichers teilen, und umfasst des Weiteren ein Ressourcenteilungs-Steuergerät, das einen Zugriff auf eine physikalische Ressource teilt, die exklusiv zwischen den mindestens zwei CPUs unter den geteilten physikalischen Ressourcen verwendet wird.
Das SoC gemäß Anspruch 3, wobei die mindestens zwei CPUs eine erste CPU umfassen, die ein erstes Software-Programm ausführt und eine zweite CPU, die ein zweites Software-Programm ausführt, das sich von dem ersten Software-Programm unterscheidet, und wobei das Ressourcenteilungsteuergerät einen Speicherbereich, auf den das erste Softwareprogramm geladen ist, physikalisch zwischen physikalischen Ressourcen trennt, die exklusiv zwischen den mindestens zwei CPUs verwendet werden, und einen Zugriff durch die zweite CPU auf den getrennten Speicherbereich blockiert.
Das SoC gemäß Anspruch 4, wobei das Ressourcenteilungssteuergerät eine Firmware betreibt, die ein höheres Berechtigungslevel aufweist als das erste Software-Programm und das zweite Software-Programm, und einen Zugriff auf die exklusiv verwendete physikalische Ressource durch die Firmware steuert.
Das SoC gemäß Anspruch 4, wobei die Mehrzahl CPUs eine dritte CPU aufweist, die mit einem statischen Direktzugriffsspeicher (RAM; random access memory) und einer Mehrzahl von Geräten über eine zweite Bus-Schnittstelle verbunden ist, und ein drittes Softwareprogramm ausführt, und wobei das mindestens eine Zugriffssteuergerät ein erstes Zugriffssteuergerät umfasst, das zwischen der zweiten Bus-Schnittstelle und dem Bus-Verbinder platziert ist, und Zugriffe durch andere CPUs auf den statischen RAM und die Mehrzahl von Geräten steuert.
Das SoC gemäß Anspruch 6, wobei die Mehrzahl CPUs eine vierte CPU aufweist, die über eine dritte Bus-Schnittstelle mit einem Code-RAM, auf den Programmcodes einschließlich eines Bootcodes geladen sind und einen Daten-RAM, auf den Nutzerdaten geladen sind, verbunden ist, und führt ein viertes Software-Programm ausführt, und wobei das mindestens eine Zugriffssteuergerät des Weiteren ein zweites Zugriffssteuergerät aufweist, das zwischen der dritten Bus-Schnittstelle und dem Bus-Verbinder platziert ist, und den Zugriff anderer CPUs auf den Code-RAM und den Daten-RAM steuert.
Das SoC gemäß Anspruch 7, wobei die erste CPU einen Vierfachkern aufweist, und wobei die zweite CPU, die dritte CPU und die vierte CPU einen Einzelkern aufweisen.
Das SoC gemäß Anspruch 7, wobei die Mehrzahl CPUs unabhängig entsprechende Software-Programme ausführt, nachdem die dritte CPU, die erste CPU, die vierte CPU und die zweite CPU nacheinander gebootet wurden.
Ein Verfahren zum Betreiben einer Mehrzahl zentraler Verarbeitungseinheiten (CPUs; central processing units), die auf einem einzigen Ein-Chip-System (SoC; system-on-chip) angebracht sind, wobei das Verfahren umfasst: Ausführen eines Bootcodes des SoC in einer ersten CPU; und Ausführen eines primären Bootlader, der durch den Bootcode in der ersten CPU aufgerufen wird, wobei der erste Bootlader ein erstes Softwareprogramm der ersten CPU ausführt, und einen sekundären Bootlader aufruft, der in einer zweiten CPU ausgeführt wird, wobei der sekundäre Bootlader einen tertiären Bootlader aufruft, der ein zweites Software-Programm der zweiten CPU ausführt, und ein drittes Software-Programm einer dritten CPU ausführt, und wobei der tertiäre Bootlader ein viertes Software-Programm einer vierten CPU ausführt.
Das Verfahren gemäß Anspruch 10, wobei das erste Software-Programm ein Betriebssystem (OS) umfasst, wobei das zweite Software-Programm einen Linux-Kernel aufweist, wobei das dritte Software-Programm ein Echtzeit-Betriebssystem (RTOS; real time operating system) aufweist, und wobei das vierte Software-Programm eine Firmware aufweist.
Das Verfahren gemäß Anspruch 10, wobei das dritte Software-Programm durch den zweiten Bootlader ausgeführt wird, wenn ein erstes Zugriffssteuergerät, das mit einem die zweite CPU und die dritte CPU verbindenden Bus-Verbinder verbunden ist, es der zweiten CPU gestattet, auf die dritte CPU zuzugreifen.
Das Verfahren gemäß Anspruch 10, wobei das vierte Software-Programm durch den dritten Bootlader ausgeführt wird, wenn ein zweites Zugriffssteuergerät, das mit einem die zweite CPU und die vierte CPU verbindenden Bus-Verbinder verbunden ist, es der zweiten CPU gestattet, auf die vierte CPU zuzugreifen.