Diejenigen, die unser Projekt verfolgen, haben möglicherweise bemerkt, dass im Verzeichnis mit Architekturen ein e2k-Ordner angezeigt wurde, der Unterstützung für inländische Prozessoren mit
Elbrus-Architektur enthält .
Eine Reihe von Artikeln zur Portierung von
Embox auf inländische Plattformen wäre ohne eine Geschichte über diese Architektur nicht vollständig.
Ich werde einige Kommentare zum Inhalt des Artikels abgeben. Erstens befindet sich der Prozess der Beherrschung dieser Architektur durch uns in der Anfangsphase. Wir haben es geschafft, Embox auf dieser Plattform zu starten, aber wir haben noch nicht viele der erforderlichen Teile implementiert, die in zukünftigen Veröffentlichungen erörtert werden. Zweitens ist diese Architektur komplex und
Eine detaillierte Beschreibung erfordert viel mehr Text als das Format zulässt
ein Artikel. Daher empfehlen wir, diesen Artikel als Einführung zu nehmen.
mit einem Minimum an technischen Informationen über die Architektur selbst.
Fangen wir an.
Forschungsobjekt - Eingebettetes Systemlayout auf Elbrus
Da wir uns mit Embox beschäftigen (und wenn jemand nicht weiß, dass es sich um eingebettete Systeme handelt), waren wir hauptsächlich an der Option interessiert, dass das MTsST selbst positioniert ist, auch für eingebettete Systeme. Beim MCST haben wir festgestellt, dass das Unternehmen daran interessiert ist, seine Prozessoren für eingebettete Systeme einzusetzen. Eine der neuesten Lösungen für dieses Segment ist
die E4C-COM-Karte . Während der Kommunikation mit dem MCST wurde klar, dass Sie zum Portieren und Beherrschen der Architektur alle verfügbaren Maschinen verwenden können, und wir erhielten einen Computer namens
Temperament zur vorübergehenden Verwendung. Im Allgemeinen ist ein Monocube nicht ganz das, was wir in eingebetteten Systemen gewohnt sind. In der Regel verwenden eingebettete Systeme Einplatinencomputer, einen Chip - ein System auf einem Chip oder sogar einen Mikrocontroller. Der Monocube ist jedoch ein vollwertiger Computer. Da er jedoch in „Klima und Mechanik“ getestet wurde, kann er dennoch als eingebettetes System betrachtet werden.
Compiler, Build, Füllbild
Nach Erhalt der Systemeinheit stellte sich natürlich die Frage, wie das Bild ausgefüllt werden soll. Das MCST verwendet ein eigenes BIOS (First Level System Boot Loader). Standardmäßig ist das Elbrus-Betriebssystem installiert (d. H. Debian mit Änderungen). Wir sind daran interessiert, unser eigenes Image zu starten. Glücklicherweise kann der MTST-Loader Bilder über das Netzwerk ausführen. Verwenden Sie dazu das
ATA over Ethernet-Protokoll .
Nachdem uns geholfen wurde, einen Stand einzurichten und ein externes Image über das Netzwerk zu starten, begannen wir mit der Entwicklung unseres eigenen Images. Dazu brauchten wir einen Compiler. Wir haben den Compiler nicht öffentlich gefunden, aber seit wir die NDA unterzeichnet haben, haben wir Binärdateien für Linux erhalten. Der Compiler erwies sich als ziemlich gcc-kompatibel, und wir mussten natürlich nichts ändern, mit Ausnahme der Kompilierungsflags, die wir in einer separaten Konfigurationsdatei veröffentlicht haben. Das ist sehr vorhersehbar, da Linux, wenn auch mit Modifikationen, von diesem Compiler zusammengestellt wird.
Ein paar technische Fragen
Diejenigen, die an bestimmten Aktivitäten wie dem Portieren des Betriebssystems auf eine Plattform beteiligt sind, wissen, dass das erste, was zu tun ist, darin besteht, den Programmcode korrekt im Speicher abzulegen. Schreiben Sie also ein Linker-Skript (lds) und implementieren Sie den Startcode. Wir haben das Linker-Skript schnell herausgefunden, aber als wir den Startcode implementiert haben, waren wir mit der ersten Magie konfrontiert, die wir nicht vollständig verstanden haben. Tatsache ist, dass Elbrus einen x86-Kompatibilitätsmodus hat und bei 0x00FF0000 gibt es einen Code, zu dem ich einfach einen
Link geben werde , da wir ihn aus dem MCST-Beispiel ausgeliehen haben. Linker-Skript enthält
.bootinfo : { _bootinfo_start = .; *(.x86_boot) . = _bootinfo_start + 0x10000; _bootinfo_end = .; } SECTION_REGION(bootinfo) .text : { _start = .; *(.e2k_entry);
Der Startercode selbst ist nicht einmal in Assembler geschrieben, sondern einfach in
C. Es befindet sich in dem Abschnitt 0x01000000, der übrigens der Startadresse regulärer x86-Maschinen entspricht - dort liegt der
Multiboot- Header oder ein anderer Header an dieser Adresse.
Um sicherzustellen, dass der Startcode und die Adressen korrekt sind, müssen Sie eine Ausgabe erhalten. Wenn Sie ein Zeichen drucken können, gibt es höchstwahrscheinlich keine Probleme mit der Ausgabe von Zeichenfolgen. Mit dieser Ausgabe ist es bereits möglich, das bekannte printf () zum Debuggen zu verwenden. Darüber hinaus bieten die meisten Plattformen die Möglichkeit, Zeichen auszugeben, indem sie einen einfachen Eintrag in ein bestimmtes Register vornehmen (da der Bootloader höchstwahrscheinlich UART nach Bedarf konfiguriert hat).
Unser Computer verwendet den seriellen Port-Controller
am85c30 (auch bekannt als
z85c30). Wir haben schnell genug herausgefunden, wie ein Zeichen gedruckt werden kann, und dies reicht aus, damit unser printf funktioniert. Wir hatten sofort ein seltsames Problem - einige der von printf gedruckten Zeichen schienen doppelt vorhanden zu sein, aber Manchmal verwechselt. Zum Beispiel, als ich versuchte, Hello, world! + (1891VM7YA) ( vier DSP-Kerne zählen nicht) und der Bootloader aktiviert alle Prozessorkerne. Um nicht mit Multicore (SMP) in Konflikt zu geraten, werden alle Kerne mit Ausnahme des ersten an eine Endlosschleife gesendet. Dazu haben wir eine Variable für die Prozessornummer eingeführt und diese mithilfe der atomaren Addition erhöht Der Zero Core funktioniert weiterhin, während andere Kernel eine Schleife ausführen.
cpuid = __e2k_atomic32_add(1, &last_cpuid); if (cpuid > 1) { while(1); } memcpy((void*)0, &_t_entry, 0x1800); kernel_start();
Der Aufruf von kernel_start () ist bereits eine Übertragung der Kontrolle auf unseren Code.
Wir haben uns auch Atomzusätze geliehen, für uns sieht es nach Magie aus. Aber wie Sie wissen, funktioniert es - nicht anfassen!
#define WMB_AFTER_ATOMIC ".word 0x00008001\n" \ ".word 0x30000084\n" #define __e2k_atomic32_add(__val, __addr) \ ({ \ int __rval; \ asm volatile ("\n1:" \ "\n\tldw,0 %[addr], %[rval], mas=0x7" \ "\n\tadds %[rval], %[val], %[rval]" \ "\n\t{"\ "\n\tstw,2 %[addr], %[rval], mas=0x2" \ "\n\tibranch 1b ? %%MLOCK" \ "\n\t}" \ WMB_AFTER_ATOMIC \ : [rval] "=&r" (__rval), [addr] "+m" (*(__addr)) \ : [val] "ir" (__val) \ : "memory"); \ __rval; \ })
Eine andere Magie, die ich ausleihen musste, ist ein Code, der für alle Kerne benötigt wird. Nämlich
static inline void e2k_wait_all(void) { _Pragma ("no_asm_inline") asm volatile ("wait \ttrap = %0, ma_c = %1, fl_c = %2, ld_c = %3, " "st_c = %4, all_e = %5, all_c = %6" : : "i" (0), "i" (1), "i" (1), "i" (0), "i" (0), "i" (1), "i" (1) : "memory"); }
Infolgedessen wurden nach dem Schreiben des Startcodes nicht nur Nachrichten mit printk angezeigt, sondern auch Module geladen, was für nicht ganz Standard-Compiler im Allgemeinen nicht sehr trivial ist. Ich stelle also noch einmal fest, dass diesmal die Kompatibilität mit gcc sehr zufrieden war.
Der nächste Schritt besteht normalerweise darin, den Interrupt-Controller und den Timer zu starten. Da wir jedoch nicht nur die Unterstützung für diese Geräte, sondern auch den Architekturcode für die Interrupt-Handler implementieren müssen, haben wir beschlossen, von der Peripherie aus zu starten. Der Monocub verfügt über einen PCIe-Bus, für Programmierer sieht er aus wie eine normale PCI. Wir waren hauptsächlich an zwei Geräten interessiert: einem Display-Controller und einem Netzwerk-Controller.
Der Monocube verwendet einen Grafikcontroller aus der
sm750- Serie. Dies ist ein Grafikcontroller für eingebettete Anwendungen, der integrierte Unterstützung für 2D-Grafiken bietet. Der Chip ist, wie ich es verstehe, direkt auf das Motherboard gelötet. Quellen für den Treiber für Linux finden Sie
hier .
Nachdem der Treiber gefunden wurde, schien es, dass unsere Probleme vorbei waren, es blieb nur die Implementierung des Controllers für PCI. Genauer gesagt, Lese- / Schreibvorgänge des PCI-Konfigurationsraums, um die Parameter herauszufinden. Die Implementierung dieser Funktionen musste erneut ausgeliehen werden. Infolgedessen kam das Lesen von Datensätzen auf Makros wie
#define _E2K_READ_MAS(addr, mas, type, size_letter, chan_letter) \ ({ \ register type res; \ asm volatile ("ld" #size_letter "," #chan_letter " \t0x0, [%1] %2, %0" \ : "=r" (res) \ : "r" ((__e2k_ptr_t) (addr)), \ "i" (mas)); \ res; \ }) #define _E2K_WRITE_MAS(addr, val, mas, type, size_letter, chan_letter) \ ({ \ asm volatile ("st" #size_letter "," #chan_letter " \t0x0, [%0] %2, %1" \ : \ : "r" ((__e2k_ptr_t) (addr)), \ "r" ((type) (val)), \ "i" (mas) \ : "memory"); \ })
Es gibt ein gewisses Verständnis dafür, was passiert. Elbrus verfügt über mehrere alternative Adressräume, beispielsweise in der
SPARC-Architektur . Die Identifizierung erfolgt anhand der Adressraumkennung. Das heißt, der gleiche ld-Befehl gelangt zu verschiedenen internen Adressen und generiert auch Leseoperationen unterschiedlicher Länge (8, 16, 32, 64 Bit). Wenn dies in SPARC ein separater lda / sta-Befehl ist, ist dies in Elbrus aufgrund der Parameter der ld-Befehl. Die
Registerfenster wurden aus der SPARC-Architektur entlehnt. Ich werde eine detailliertere Geschichte für nachfolgende Artikel verschieben.
Infolgedessen stellte sich mit PCI alles heraus. Wir konnten alle erforderlichen Daten abrufen, den Grafiktreiber an uns selbst übertragen, stießen dann aber auf das folgende Problem. Um ein Bild im Videospeicher zu zeichnen, musste man zweimal schreiben. Alles zeigte auf Cache. Um dieses Problem zu lösen, war es notwendig, sich mit MMU zu befassen, und dies kann, wie sie sagen, nicht mit der Condachka gelöst werden, wie im Prinzip viele andere Probleme, auf die wir bei der Entwicklung dieser Architektur mehr als einmal gestoßen sind und stoßen werden.
Wir sind in andere Richtungen vorangekommen: Unterbrechungen und Systemaufrufe, aber darüber werden wir auch in den nächsten Artikeln dieser Unterreihe sprechen. Am Ende dieses Artikels werde ich einfach die Ausgabe auf die Konsole bringen (über die serielle Schnittstelle).
Schlussfolgerungen
Wie ich in der Einleitung sagte, möchte ich mich in erster Linie nicht auf technische Details konzentrieren, sondern auf allgemeine Gefühle. Die Gefühle sind also widersprüchlich, wenn auch sicherlich positiver. Einerseits existiert der Prozessor und ist hinsichtlich der architektonischen Merkmale sehr interessant. Basierend auf diesem Prozessor werden Computersysteme hergestellt, es gibt Software von ziemlich hoher Qualität. Wie gesagt, es gab keine Beschwerden über den Compiler (bis zu einem bestimmten Punkt, den ich etwas später beschreiben werde), gibt es ein vollwertiges Linux (OS "Elbrus"). Ich persönlich habe gesehen, wie der Entwickler im ICST selbst direkt auf dem Desktop mit Elbrus-Architektur erstellt hat.
Andererseits verstehe ich nicht, warum sie mit solcher Beharrlichkeit versuchen, Intel x86 von diesem Prozessor banal zu ersetzen. Nirgendwo auf der Welt verwenden sie Prozessoren, die auf der
VLIW- Architektur basieren, als universelle PCs. VLIW ist aufgrund seiner architektonischen Merkmale ein cooler „Zahlenbrecher“, sie machen DSP darauf, sie haben itanium Server gemacht, sie haben Grafikkarten gemacht. Nein, mit einem Bagger können Sie natürlich ein Loch graben, um einen Baum zu pflanzen, aber es lohnt sich.
Das Hauptproblem, das meiner Meinung nach die Entwicklung der Architektur behindert, ist die geschlossene Natur des gesamten Ökosystems. Ja, um eine Beschreibung des Befehlssystems zu erhalten, müssen Sie nur die NDA unterschreiben, dies reicht jedoch nicht aus. Die Architektur ist ungewohnt und sehr komplex. Ja, ich habe immer gedacht, dass einige grundlegende Software direkt vom Prozessorhersteller oder in enger Zusammenarbeit mit ihm entwickelt werden sollte. Nach diesem Prinzip verfügt ein PC auf Elbrus über ein Softwarepaket mit
dem Betriebssystem Elbrus . Dennoch ist es zu naiv zu glauben, dass ein Unternehmen, auch ein großes, allen Komponenten Qualitätsunterstützung bieten kann: einem Prozessor, einem Compiler, Entwicklungs- und Debugging-Tools, Systemsoftware (verschiedene Betriebssysteme), Anwendungssoftware, ... Selbst Intel kann das nicht. Die Welt bewegt sich seit langem in Richtung der sogenannten Zusammenarbeit oder gemeinsamen Entwicklung.
Lassen Sie mich ein Beispiel für ein Compiler-Problem geben, auf das wir gestoßen sind. Der Treiber für die serielle Schnittstelle zeigte irgendwann keine Zeichen mehr an, und auf den ersten Blick hat sich nichts geändert. Es stellte sich heraus, dass wir die nicht verwendete Debugging-Funktion entfernt haben, die wir eingefügt haben, um durch den Disassembler zu verstehen, wie Argumente an die Funktion in Assembler übergeben werden. Das heißt, wenn die Funktion vorhanden ist, ist alles in Ordnung, wenn nicht, verschwindet die Ausgabe. Zuerst sündigten sie für die Ausrichtung, aber es stellte sich heraus, dass die Funktion auf das Ende von C-Schnick übertragen werden kann, sodass sich alle Zeichen des Fahrers an denselben Stellen wie zuvor befanden, aber das Problem wurde reproduziert. Obwohl dieses Problem nicht gelöst wurde, untersuchen wir weiterhin, um den Entwicklern des Compilers aus dem MCST zu zeigen oder um zu verstehen, wo wir einen Fehler gemacht haben.
Das obige Problem hätte meiner Meinung nach vermieden werden können, wenn es mehr Drittanbieter gegeben hätte. Zumindest wäre das Problem früher ans Licht gekommen, oder man könnte einfach googeln, was wir falsch gemacht haben.
Das ICST ist sich auch des Problems der Schließung bewusst, da der Prozess der Entdeckung nicht klassifizierter Dinge dennoch begonnen hat. Zum Beispiel habe ich gesehen, wie Alt-Linux auf mehreren Konferenzen auf mehreren Elbrus-PCs funktioniert. Hier sind Bilder des Displays von einer der Konferenzen in diesem Jahr (leider schlecht zu sehen, es war dunkel). Wir haben uns auch mit der Entwicklung verbunden. Wir hoffen, dass wir für das ICST nützlich sein werden, da, wie sich herausstellt, einige der Highlights der Elbrus-Architektur unter Linux nicht unterstützt werden können (oder die Kosten sehr hoch sind), z. B. mit Tags versehener Speicher.
Ein weiterer wichtiger Punkt, als wir das Problem der Schließung mit den Entwicklern des MCST diskutierten, war, dass beispielsweise die Linux-Kernelquellen lange offen waren, aber nur wir und die Dolomant-Entwickler Fragen stellten und sie irgendwie verwendeten.
Außerdem wird das MCST nach meinen Informationen einen Stand organisieren
Fernzugriff. Auf dem es möglich sein wird, Software auf einem PC mit Elbrus-Architektur zusammenzustellen und auszuführen. Wenn es ein ähnliches Interesse gibt und Sie den Stand nutzen möchten, sollten Sie sich zum Beispiel an mich wenden: Beschreiben Sie, wie die Nutzung geplant ist, wie lange es dauert und so weiter, da Sie zum Teilen mit dem Ändern der Software einen Zeitplan organisieren müssen. Ich werde die Daten an das ICST übertragen oder diejenigen, die dies wünschen, mit den Organisatoren verbinden.
Nützliche Links:
Die Postanschrift für Benutzer lautet user [at] mcst.ru.
Eine kurze Beschreibung der Architektur von ElbrusEmbox-QuellenPS Wir werden allen zeigen, die wollen, was wir beim
TechTrain IT Festival
am 1. und
2. September bekommen haben.