Autor: Frank Storm, Avnet Silica<\/p>\n
Viele und unterschiedliche Prozessor-Cores sind in heutigen SoCs Standard. Wie man diese asynchron, also mit unterschiedlichen Betriebssystemen, betreibt und sie dann auch miteinander kommunizieren l\u00e4sst, leider nicht. Dies f\u00fchrt dazu, dass viele Anwender eigene L\u00f6sungen implementieren, die zeit- und wartungsintensiv sind. Dieser Artikel beschreibt OpenAMP, einen offenen Standard, der es sich zur Aufgabe gesetzt hat, dieses Problem zu l\u00f6sen.<\/strong><\/p>\n Fast alle gro\u00dfen SoCs kommen heute mit mehr als einem Prozessor daher. Im oberen Segment sind Arm-Prozessoren als Quad-Core inzwischen Standard, ob als A53, A57 oder als big.LITTLE Kombination aus A15 und A7 (i.MX8 [1], Marvell Armada [2], Xilinx Zynq UltraScale+ [3]). Im mittleren Segment hat man dann eher Dual-Core Systeme (i.MX8, Xilinx Zynq 7000 [4]). Da die typischen Applikationsprozessoren (Arm A) nicht f\u00fcr alle Applikationen ideal sind, stellen die Hersteller den Applikationsprozessoren auch noch andere Cores zur Seite. Das sind dann entweder spezielle Real-Time Prozessoren, wie der Cortex-R5 beim Zynq UltraScale+, oder typische Mikrocontroller-Cores, wie der Cortex-M4 beim i.MX8. Sogar im unteren Segment wird einem Cortex-M4 noch ein Cortex-M0+ zur Seite gestellt, wie in der NXP Controllerfamilie LPC54000 [5].<\/p>\n Bereits in der Vergangenheit hat es diese Kombination aus Universalprozessor und Spezialprozessor gegeben, wie die im Mobilfunkbereich lange Zeit verbreitete OMAP-Familie. Der Spezialprozessor war in diesem Fall ein DSP, der f\u00fcr die Abarbeitung des GSM Stacks zust\u00e4ndig war. Schaut man sich die Verwendung der Zusatzprozessoren an, so werden diese sehr oft gezielt f\u00fcr Echtzeitaufgaben eingesetzt, sei es zur Abarbeitung eines Funkprotokoll-Stacks oder zur Antriebsregelung im Industriebereich. Dem Applikationsprozessor fallen dann die Aufgaben zu, sich um die Schnittstellen nach au\u00dfen zu k\u00fcmmern, das Human Machine Interface (Display oder Web-Server) zu realisieren und nebenbei noch „House-Keeping“ zu betreiben.<\/p>\n Wir haben in vielen Kundenanwendungen gesehen, dass diese Aufteilung auch bei Systemen mit zwei Applikationsprozessoren gemacht wird, wie dem Zynq-7000, der \u00fcber zwei Cortex-A9 Cores verf\u00fcgt. Hier ist es nahezu Standard, auf dem ersten Core ein Linux laufen zu lassen, das sich um Schnittstellen wie Ethernet und USB k\u00fcmmert und eine komfortable Umgebung f\u00fcr ausgewachsene Web-Server bietet. Auf dem zweiten Core l\u00e4uft dann ein schlankes Echtzeit-Betriebssystem, wie z.B. FreeRTOS oder \u00b5C-OS, oder eben auch gar kein Betriebssystem (Bare Metal).<\/p>\n In der Praxis bringen diese heterogenen Systeme eine Reihe von Herausforderungen mit sich. Dabei kann es auch eher hinderlich sein, wenn die Prozessoren zu eng miteinander verzahnt sind. Typische Problemstellungen sind die Aufteilung des Speichers, das Festlegen eines Shared-Memory, das von beiden Cores zum Austausch von Daten genutzt wird, das Verteilen der System-Ressourcen (wer darf sich z.B. um den CAN-Bus k\u00fcmmern?) und auch die Frage nach der Interrupt-Verteilung (wer unterbricht wen, l\u00e4uft dies \u00fcber einen gemeinsamen Interrupt-Controller oder vielleicht \u00fcber eine spezielle Mailbox-Hardware?). Da wird auch die Frage wichtig, wie MMU oder MPU konfiguriert werden m\u00fcssen oder welche Bereiche nicht gecacht werden d\u00fcrfen. Je mehr Flexibilit\u00e4t der SoC-Hersteller in den Chip gelegt hat, umso mehr muss der Anwender bei der Umsetzung beachten.<\/p>\n Die Erfahrung hat gezeigt, dass Applikation-Notes zum AMP-Betrieb der Cores [6] dankend angenommen werden, meistens aber nur der erste Schritt sind. Je komplexer ein Betriebssystem ist, desto schwieriger wird es auch, z.B. in das Speicher und Cache-Management einzugreifen. Bei einem Bare Metal Programm stellt man noch mal eben ein, welche Speicherbereiche nicht gecacht werden sollen. Bei einem Linux m\u00f6chte man sich damit gar nicht erst besch\u00e4ftigen m\u00fcssen. Leider hat auch hier die Erfahrung gezeigt, dass man sich sp\u00e4testens dann damit besch\u00e4ftigen muss, wenn Interrupts verschluckt werden und die Performance unter bestimmten Bedingungen pl\u00f6tzlich nicht mehr ausreicht.<\/p>\n Auch die Fragen nach dem sogenannten Lifecycle-Management, also dem Laden und Starten von Programmen, sowie dem gezielten Schlafenlegen, Herunterfahren und Neuladen sind nicht unbedingt trivial.<\/p>\n Der Wunsch kommt also ganz schnell auf, hier auf etwas Existierendem, Stabilem und Standardisiertem aufsetzen zu k\u00f6nnen. Weil das auch Hersteller von SoCs, Betriebssystemen und Tools erkannt haben, haben sich etliche Firmen zur Multicore Association (MCA) zusammengeschlossen [7]. Die Multicore Association erarbeitet in Arbeitsgruppen Standards und Implementierungen, die das Zusammenspiel von Multi-Core-Systemen regeln und vereinfachen sollen.<\/p>\n Einer dieser Standards ist OpenAMP – das Open Assymetric Multiprocessing Framework [8]. OpenAMP stellt dabei ein Open-Source-Framework zur Verf\u00fcgung, was die standardisierte Kommunikation einer Vielzahl von heterogenen Systemen miteinander erm\u00f6glicht. Die entsprechende Arbeitsgruppe bei der MCA k\u00fcmmert sich dabei um die Standardisierung der Schnittstellen.<\/p>\n Man hat dabei einen pragmatischen Ansatz gew\u00e4hlt. Anstatt einen allgemeinen Ansatz zu w\u00e4hlen, der alle m\u00f6glichen Szenarien abdecken soll, hat man sich auf die in der Praxis typischen F\u00e4lle konzentriert und auf bestehende Software Schnittstellen aufgesetzt.<\/p>\n Konkret bedeutet das Folgendes: OpenAMP unterscheidet zwischen einem Master- oder Host-Prozessor, dem die komplette Kontrolle unterliegt, und einem Remote-Prozessor. Auf dem Master-Prozessor l\u00e4uft typischerweise ein Linux, auf dem Remote-Prozessor ein RTOS oder ein Bare-Metal Programm. Als Interface-Komponente f\u00fcr das Lifecycle Management (LCM) wird\u00a0remoteproc<\/em>\u00a0[9] verwendet, f\u00fcr die Interprozessor-Kommunikation (IPC) findet\u00a0RPMsg<\/em>\u00a0[10] Verwendung. Beide Komponenten sind Bestandteil des Linux-Kernels ab Version 3.4. remoteproc und RPMsg setzen beide auf\u00a0virtIO<\/em>\u00a0auf, ein Layer, der virtuellen Device-Treibern die direkte Kommunikation mit dem Host-OS oder einem Hypervisor erlaubt.<\/p>\n Das gilt zwar f\u00fcr Linux auf der Host-Seite, aber nicht f\u00fcr ein auf Remote-Prozessor-Seite verwendetes RTOS. Deswegen ist es Aufgabe von OpenAMP, hier eine Implementierung zur Verf\u00fcgung zu stellen, die sich in ein RTOS einbinden l\u00e4sst.<\/p>\n Zus\u00e4tzlich zu LCM und IPC kommt bei OpenAMP noch eine dritte Komponente hinzu. Ein auf dem Remote-Prozessor laufendes Programm soll schlie\u00dflich auch Ausgaben machen k\u00f6nnen, die man gerne zusammen mit den Ausgaben des Host-Prozessors in einem Terminal-Fenster sehen m\u00f6chte. Au\u00dferdem w\u00e4re es vorteilhaft, wenn der Remote-Prozessor (kontrollierten) Zugang zum File-System des Hosts h\u00e4tte, sei es, um Konfigurationsdateien zu lesen oder autonom auf Daten zugreifen zu k\u00f6nnen. Hierf\u00fcr gibt es eine Proxy-Infrastruktur, die I\/O- und File-Zugriffe des Remote-Prozessors \u00fcber den Host abwickelt.<\/p>\n OpenAMP \u00fcbernimmt zwar einiges an Arbeit, ohne ein paar Vorarbeiten bei der Installation des Linux-Kernels kommt man aber nicht aus. Gl\u00fccklicherweise beschr\u00e4nken sich diese haupts\u00e4chlich auf das Hinzukonfigurieren von remoteproc und RPMsg (falls diese nicht sowieso schon aktiv sind) und das Hinzuf\u00fcgen von ein paar Eintr\u00e4gen im Device-Tree, die gemeinsam genutzte Speicherbereiche und Interrupts definieren und die Verbindung zu remoteproc herstellen.<\/p>\n Anhand eines kleinen Beispiels soll gezeigt werden, wie sich OpenAMP aus Sicht des Anwenders darstellt. Das Beispiel ist ein Programm, das auf dem Remote-Prozessor eine FFT berechnet und dann die berechneten Daten zur\u00fcckschickt.<\/p>\n \u00dcber die Datei\u00a0firmware<\/em>\u00a0im Sysfs-Filesystem wird das Programm auf den Remoteprozessor geladen:<\/p>\n # echo fft_server > Gestartet wird es dann auf \u00e4hnliche Weise durch Schreiben des Wertes „start“ auf die Sysfs-Datei\u00a0state<\/em>:<\/p>\n # echo start > \/sys\/class\/remoteproc\/remoteproc0\/state<\/p>\n Im User-Programm gestaltet sich die Kommunikation dann recht einfach. Das entsprechende RPMsg-Device wird ge\u00f6ffnet, und die FFT-Eingangsdaten werden hineingeschrieben. Anschlie\u00dfend werden die berechneten Ausgangsdaten ausgelesen.<\/p>\n int fd;<\/p>\n int input_data[512];<\/p>\n int output_data[512];<\/p>\n fd = open(„\/dev\/rpmsg0“, O_RDWR); \u2026<\/p>\n read(fd, output_data, sizeof(output_data));<\/p>\n Das Programm auf dem Remote-Prozessor gestaltet sich etwas aufw\u00e4ndiger.<\/p>\n int output_data[512];<\/p>\n void rpmsg_read_cb(<\/p>\n \u00a0\u00a0\u00a0 struct rpmsg_channel *rp_chnl,<\/p>\n \u00a0\u00a0\u00a0 void *data, int len, \u00a0 calculate_fft(data, output_data); } struct hil_proc *hproc; \u2026<\/p>\n hproc = platform_create_proc(proc_id);<\/p>\n rsc_info.rsc_tab = get_resource_table((int)rsc_id,<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 &rsc_info.size)<\/p>\n remoteproc_resource_init(&rsc_info, hproc, \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 rpmsg_read_cb, &proc, 0);<\/p>\n \u00dcber\u00a0remote_proc_resource_init<\/em>\u00a0wird die Callback-Funktion\u00a0rpmsg_read_cb<\/em>\u00a0registriert, die beim Empfang von Daten angesprungen wird und dann den eigentlichen Service (hier Berechnung der FFT) \u00fcbernimmt.<\/p>\n Abh\u00e4ngig von der Funktion, die das Programm auf dem Remote-Prozessor zu erf\u00fcllen hat, ist nat\u00fcrlich noch etwas mehr zu tun. Im User-Programm kann es auch empfehlenswert sein, das Abschicken der Eingangsdaten und das Empfangen der berechneten Daten durch Threads zu entkoppeln.<\/p>\n Die Sourcen f\u00fcr OpenAMP und Beispielprogramme werden \u00fcber GitHub zur Verf\u00fcgung gestellt [11]. Von Xilinx gibt es inzwischen eine Application-Note, die den Umgang mit OpenAMP beschreibt [12]. Au\u00dferdem stellt Xilinx in seinem Software Development Kit bereits Templates f\u00fcr OpenAMP Projekte zur Verf\u00fcgung. Von NXP gibt es eine ressourcensparende RPMsg-Implementierung (RPMsg-Lite), die ebenfalls \u00fcber GitHub zur Verf\u00fcgung gestellt wird [13]. Von Mentor Graphics gibt es inzwischen mit dem\u00a0Mentor Embedded Multicore Framework<\/em>\u00a0die erste kommerzielle Implementation des OpenAMP-Standards [14].<\/p>\n Wo man mit richtig vielen Cores (> 1000) zu tun hat, also im Bereich der GPUs, existieren bereits Frameworks zur Verwaltung von Multicore-Architekturen. Diese sind entweder propriet\u00e4r (wie CUDA von NVIDIA) oder offen wie OpenCL der Khronos Group [15]. Man kann sich jetzt nat\u00fcrlich die Frage stellen, ob sich ein Framework wie OpenCL nicht auch f\u00fcr die oben beschriebenen AMP-Szenarien verwenden lie\u00dfe und warum man mit OpenAMP ein neues Framework geschaffen hat.<\/p>\n OpenCL ist daf\u00fcr konzipiert worden, mit einer generischen Anzahl von Cores umgehen zu k\u00f6nnen. Mit OpenCL entwickelte Programme sollen auf unterschiedlichen Systemen laufen k\u00f6nnen, die unterschiedlich viele Prozessoren zur Verf\u00fcgung stellen. Abzufragen, wie viele Prozessoren das System hat, um daraufhin einen Algorithmus generisch zu verteilen, ist eine der ersten Aufgaben einer OpenCL-Initialisierung. Das f\u00fchrt zu einem m\u00e4chtigen, aber auch komplexen API. OpenAMP adressiert hingegen Systeme, die typischerweise einen oder vielleicht zwei Remote-Prozessoren zur Verf\u00fcgung stellen. Hier ist die Aufgabe des Remote-Prozessors klar umrissen und das Hardware-Setup von vornherein bekannt. Dadurch kann aber auch der Overhead wesentlich geringer ausfallen als in einer Umgebung, bei der beliebig viele Cores verwaltet werden m\u00fcssen. OpenAMP agiert dadurch wesentlich schlanker, was nicht zuletzt auch den Lernaufwand gegen\u00fcber OpenCL drastisch reduziert.<\/p>\n Momentan h\u00e4lt OpenAMP bei den ersten Entwicklern Einzug. Die ersten Fragen nach Erweiterungen kommen auch bereits („Wir h\u00e4tten gerne noch einen C++ Layer“). Manch einer, der bereits eine L\u00f6sung hat, wird sich auch mit der Adaption Zeit lassen. Mit OpenAMP steht jetzt aber erstmals ein Standard zur Verf\u00fcgung, auf dem man bei der Implementierung von AMP-Systemen aufsetzen kann, ohne selber wieder das Rad neu erfinden zu m\u00fcssen.<\/p>\n [1]\u00a0https:\/\/www.nxp.com\/products\/microcontrollers-and-processors\/arm-based-processors-and-mcus\/i.mx-applications-processors\/i.mx-8-processors:IMX8-SERIES<\/a><\/p>\n [2]\u00a0https:\/\/www.marvell.com\/embedded-processors\/<\/a><\/p>\n [3]\u00a0https:\/\/www.xilinx.com\/products\/silicon-devices\/soc\/zynq-ultrascale-mpsoc.html<\/a><\/p>\n [4]\u00a0https:\/\/www.xilinx.com\/products\/silicon-devices\/soc\/zynq-7000.html<\/a><\/p>\n [5]\u00a0https:\/\/www.nxp.com\/docs\/en\/fact-sheet\/LPC541XXFAMFS.pdf<\/a><\/p>\n [6]\u00a0https:\/\/www.xilinx.com\/support\/documentation\/application_notes\/xapp1078-amp-linux-bare-metal.pdf<\/a><\/p>\n [7]\u00a0https:\/\/www.multicore-association.org\/<\/a><\/p>\n [8]\u00a0https:\/\/www.multicore-association.org\/workgroup\/oamp.php<\/a><\/p>\n [9]\u00a0https:\/\/www.kernel.org\/doc\/Documentation\/remoteproc.txt<\/a><\/p>\n [10]\u00a0https:\/\/www.kernel.org\/doc\/Documentation\/rpmsg.txt<\/a><\/p>\n [11]\u00a0https:\/\/github.com\/OpenAMP<\/a><\/p>\n [12]\u00a0https:\/\/www.xilinx.com\/support\/documentation\/sw_manuals\/xilinx2017_2\/ug1186-zynq-openamp-gsg.pdf<\/a><\/p>\n [13]\u00a0https:\/\/github.com\/NXPmicro\/rpmsg-lite<\/a><\/p>\n [14]\u00a0https:\/\/www.mentor.com\/embedded-software\/multicore<\/a><\/p>\n [15]\u00a0https:\/\/www.khronos.org\/opencl\/<\/a><\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Multicore \/Mikrocontroller.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Multicore \/Mikrocontroller steht\u00a0hier\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nEin Beispiel<\/h2>\n
\n\/sys\/class\/remoteproc\/remoteproc0\/firmware<\/p>\n
\nwrite(fd, input_data, sizeof(input_data));<\/p>\n
\nvoid *priv, unsigned long src)
\n{<\/p>\n
\nrpmsg_send(rp_chnl, output_data, sizeof(output_data));<\/p>\n
\n\u2026<\/p>\n
\nstruct rsc_table_info rsc_info;<\/p>\n
\nrpmsg_channel_created,
\nrpmsg_channel_deleted,<\/p>\nWas bekommt man nun als Anwender?<\/h2>\n
Warum nicht OpenCL?<\/h2>\n
Wie geht es weiter?<\/h2>\n
Quellenverzeichnis<\/h2>\n
\nMulticore – unsere Trainings & Coachings<\/h2>\n
\nMulticore – Fachwissen<\/h2>\n