System-on-Chip-Desgin

Systempartitionierung für sichere und nicht sichere Anwendungen

Seite: 2/2

Firmen zum Thema

Die beiden Prozessor-Cores kommunizieren über einen gemeinsamen physikalischen Speicherkanal nach dem OpenMCAPI-Standard (Bild 3). Das HPS-System wurde statisch partitioniert und jedes Betriebssystem auf seine zugewiesenen Ressourcen portiert. Die Memory Map wurde entsprechend in Regionen unterteilt, die entweder µC/OS-II oder Linux zugeordnet sind sowie Regionen, die sich beide Betriebssysteme teilen. Ebenso wurde die Peripherie zwischen µC/OS-II und Linux aufgeteilt – dabei gibt es keine Peripherie, die gemeinsam benutzt wird.

Im System gibt es eine Master-Konfigurationstabelle, die die alle HPS AXI-Master sowie deren TrustZone-Sicherheitsstatus auflistet. Dieser Sicherheitsstatus lässt sich statisch einstellen, sodass ein Master stets nur sichere oder stets nur nicht sichere Zugriffe ausführt. Es gibt aber auch die Möglichkeit die Einstellung so vorzunehmen, dass per Transaktion entschieden wird, ob es sich gerade um einen sicheren oder nicht sicheren Zugriff handeln soll.

Bildergalerie

Jeder Interrupt wird zu einem bestimmten Core geleitet

Jeder Cortex-A9-Prozessor verfügt über seinen eigenen unabhängigen L1-Cache für Befehls- und Datenzugriffe sowie über ein unabhängiges Timer/Watchdog-Modul. Die Prozessoren teilen sich den L2-Cache, General Interrupt Controller (GIC) und die Snoop Control Unit (SCU). Der GIC verwaltet die Priorisierung und das Routing von Interrupts zum MPCore-Prozessor. Er lässt sich so konfigurieren, dass jeder Interrupt an einen bestimmten Core geleitet wird. Jedem Interrupt kann auch ein TrustZone-Status zugewiesen werden.

Der L2-Cache kann in vielfältiger Weise konfiguriert werden. In unserem Beispiel werden die L2-Konfigurationsregister so eingestellt, dass sie nur von einem sicheren Master beschreibbar sind. Damit kann Linux die L2-Cache-Konfiguration nicht verändern, außer wenn der entsprechende Zugriff über einen sogenannten Secure State Monitor erfolgt. Der L2-Cache ist mehrwege-assoziativ und kann aufgeteilt werden.

In unserem Beispiel werden zwei Wege für µC/OS-II und sechs Wege für den Linux-Core vergeben. Der µC/OS-II Core erhält 1 MByte DDR SDRAM, UART1 und sämtliche Peripherie innerhalb des FPGAs. Alle anderen Ressourcen werden dem Linux-Kernel zugewiesen.

Bootvorgang des SoC erfolgt über drei Stufen

Während der Linux-Kernel die MMU (Memory Management Unit) des ARM-Prozessors selbst verwaltet, ist dies bei µC/OS-II nicht der Fall. Das µC/OS-II BSP wurde daher so angepasst, dass während des Startup eine statische Page-Tabelle erstellt wird. Die dem µC/OS-II zugewiesenen Ressourcen werden dann in der Page-Tabelle platziert, und das µC/OS-II wird so konfiguriert, dass es nur diese Memory Map benutzt. Für Linux enthält der Device Tree, der das System beschreibt und beim Startup an den Kernel weitergereicht wird, keine Referenz zum Speicher oder zur Peripherie, die dem µC/OS-II zugewiesen ist.

Das Booten des SoC ist ein 3-stufiger Vorgang. Die erste Stufe umfasst ein On-Chip Boot-ROM, das eine minimale Konfiguration von Core 0 durchführt und einen externen nicht-flüchtigen Speicher aktiviert. In diesem Speicher wird ein „Preloader“ Software-Image lokalisiert, überprüft und in ein integriertes RAM geladen. Dieses Preloader Image wird zunächst verwendet, um die Konfiguration des SDRAM und der Peripherie-I/Os des SoC vorzunehmen. Nachdem diese Initialisierung abgeschlossen ist, übernimmt der Preloader das Laden und die Ausführung des eigentlichen Boot-Loaders (z.B. U-Boot). Dieser Boot-Loader ist dann für das Laden und Ausführen des letztendlichen Betriebssystems zuständig.

Für unser AMP-System gibt es weitere Anforderungen: z.B. das Laden der zwei getrennten Betriebssysteme in den Speicher und die Konfiguration der TrustZone-Sicherheitsoptionen innerhalb des SoC. Die lokale Timer/Watchdog-Peripherie in Core 1, UART1, Watchdog Timer 1 und die vom µC/OS-II verwendeten Interrupts werden als sicher konfiguriert. Der Zugriff darauf kann daher nur durch das µC/OS-II erfolgen. Alle anderen Peripherieeinheiten und Interrupts werden als nicht sicherheitsrelevant konfiguriert. Danach wird µC/OS-II auf Core 1 und anschließend Linux auf Core 0 gestartet.

Mit diesem Ansatz können Entwickler die Vorteile der Baustein-Konsolidierung mithilfe eines Altera SoCs nutzen und somit gleichzeitig eine strikte, durch TrustZone/Hardware-erzwungene Softwaretrennung für sicherheitskritische Anwendungen gewährleisten.

* * Stefano Zammattio ist Product Manager und Clive Davies ist Manager Automotive System Solutions Engineering bei Altera.

(ID:40109720)