Ceux qui suivent notre projet ont peut-être remarqué qu'un dossier e2k est apparu dans le répertoire avec les architectures, qui contient le support des processeurs domestiques avec l'
architecture Elbrus .
Une série d' articles sur le portage d'
Embox sur des plateformes nationales ne serait pas complète sans une histoire sur cette architecture.
Je ferai quelques commentaires sur le contenu de l'article. Premièrement, le processus de maîtrise de cette architecture par nos soins est au stade initial, nous avons réussi à lancer Embox sur cette plateforme, mais nous n'avons pas encore implémenté bon nombre des parties nécessaires, qui seront discutées dans de futures publications. Deuxièmement, cette architecture est complexe et
une description détaillée nécessite beaucoup plus de texte que le format ne le permet
un article. Par conséquent, nous vous suggérons de prendre cet article en introduction,
contenant un minimum d'informations techniques sur l'architecture elle-même.
Commençons.
Objet de recherche - Disposition du système embarqué sur Elbrus
Puisque nous sommes engagés dans Embox (et si quelqu'un ne le sait pas, il se concentre sur les systèmes embarqués), nous étions principalement intéressés par l'option que le MTsST lui-même soit positionné, y compris pour les systèmes embarqués. Passant à l'ICST, nous avons découvert que la société souhaitait utiliser ses processeurs pour les systèmes embarqués. L'une des dernières solutions pour ce segment est
la carte E4C-COM . Dans le processus de communication avec le MCST, il est devenu clair que pour le portage et la maîtrise de l'architecture, vous pouvez utiliser n'importe laquelle des machines disponibles, et on nous a donné un ordinateur appelé
Tempérament pour une utilisation temporaire. En général, un monocube n'est pas tout à fait ce à quoi nous sommes habitués dans les systèmes embarqués. En règle générale, les systèmes embarqués utilisent des ordinateurs à carte unique, une puce - un système sur une puce ou même un microcontrôleur, mais le monocube est un ordinateur à part entière, mais puisqu'il a été testé en «climat et mécanique», il peut toujours être considéré comme un système embarqué.
Compilateur, construire, remplir l'image
Après avoir reçu l'unité centrale, la question s'est naturellement posée - comment remplir l'image. Le MCST utilise son propre BIOS (chargeur de démarrage système de premier niveau). Par défaut, le système d'exploitation Elbrus est installé (c'est-à-dire Debian avec modifications). Nous souhaitons lancer notre propre image. Heureusement, le chargeur MTST peut exécuter des images sur le réseau. Pour ce faire, utilisez le
protocole ATA sur Ethernet .
Après avoir été aidé à monter un stand et à lancer une image externe sur le réseau, nous avons commencé à développer notre propre image. Pour ce faire, nous avions besoin d'un compilateur. Nous n'avons pas trouvé le compilateur dans le domaine public, mais depuis que nous avons signé le NDA, nous avons reçu des binaires pour Linux. Le compilateur s’est avéré être tout à fait compatible avec gcc, et nous n’avons pas eu à changer quoi que ce soit, à l’exception des drapeaux de compilation, que nous avons mis dans un fichier de configuration séparé. Ce qui est très prévisible, car Linux, bien qu'avec des modifications, est assemblé par ce compilateur.
Quelques questions techniques
Les personnes impliquées dans des activités spécifiques telles que le portage du système d'exploitation sur une plate-forme savent que la première chose à faire est de placer correctement le code du programme en mémoire. Autrement dit, écrivez un script de l'éditeur de liens (lds) et implémentez le code de démarrage. Nous avons rapidement compris le script de l'éditeur de liens, mais lors de l'implémentation du code de démarrage, nous sommes tombés sur la première magie, que nous ne comprenions pas complètement. Le fait est qu'Elbrus a un mode de compatibilité x86 et à 0x00FF0000 il y a un code auquel je donnerai simplement un
lien , puisque nous l'avons emprunté à l'exemple MCST. Le script de l'éditeur de liens contient
.bootinfo : { _bootinfo_start = .; *(.x86_boot) . = _bootinfo_start + 0x10000; _bootinfo_end = .; } SECTION_REGION(bootinfo) .text : { _start = .; *(.e2k_entry);
Le code de démarrage lui-même n'est même pas écrit en assembleur, mais simplement en
C. Il est placé dans la section située à 0x01000000, ce qui, soit dit en passant, correspond à l'adresse de départ des machines x86 normales - c'est là que l'en-tête
multiboot ou un autre en-tête se trouve à cette adresse.
Afin de vous assurer que le code de démarrage et les adresses sont corrects, vous devez obtenir une sortie. Si vous pouvez imprimer n'importe quel caractère, il n'y aura probablement aucun problème avec la sortie des chaînes. En utilisant cette sortie, il sera déjà possible d'utiliser le printf () familier pour le débogage. De plus, la plupart des plates-formes offrent la possibilité de sortir des caractères en faisant une simple entrée dans un registre spécifique (car le chargeur de démarrage a probablement configuré UART selon les besoins).
Notre ordinateur utilise le contrôleur de port série am85c30 (alias
z85c30, nous avons assez rapidement trouvé comment imprimer un caractère, et cela suffit pour que notre printf fonctionne. Nous avons immédiatement fait face à un problème étrange - certains des caractères imprimés par printf semblaient être dupliqués, mais parfois mélangé. Par exemple, lorsque j'ai essayé de produire Hello, world! Il s'est avéré quelque chose comme Hhelellloo, woworrlldd. Maintenant, il semble évident que la question est multicœur, mais au début, nous avons fouillé dans le pilote lui-même. Dans notre monocub il y a un Elbrus-2C bicœur + (1891VM7YA) ( quatre cœurs DSP ne comptent pas) et le chargeur de démarrage active tous les cœurs de processeur. Par conséquent, afin de ne pas jouer avec le multicœur (SMP), tous les cœurs, à l'exception du premier, sont envoyés dans une boucle infinie. Pour ce faire, nous avons introduit une variable pour le numéro de processeur et l'incrémentons à l'aide de l'ajout atomique Zero core continue de fonctionner, tandis que d'autres noyaux bouclent.
cpuid = __e2k_atomic32_add(1, &last_cpuid); if (cpuid > 1) { while(1); } memcpy((void*)0, &_t_entry, 0x1800); kernel_start();
L'appel kernel_start () est déjà un transfert de contrôle vers notre code.
Nous avons également emprunté l'addition atomique, pour nous cela ressemble à de la magie. Mais, comme vous le savez, cela fonctionne - ne touchez pas!
#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; \ })
Une autre magie que j'ai dû emprunter est un code, qui est requis pour tous les cœurs. À savoir
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"); }
Par conséquent, après avoir écrit le code de démarrage, nous avons non seulement affiché des messages à l'aide de printk, mais également commencé à charger des modules, ce qui n'est généralement pas très trivial pour les compilateurs pas tout à fait standard. Donc, encore une fois, je note que cette fois-ci, la compatibilité avec gcc était très heureuse.
L'étape suivante consiste généralement à démarrer le contrôleur d'interruption et le minuteur, mais pensant que nous devrons implémenter non seulement la prise en charge de ces périphériques, mais également le code architectural des gestionnaires d'interruption, nous avons décidé que nous pouvons commencer à partir de la périphérie. Le monocub a un bus PCIe, pour les programmeurs il ressemble à un PCI ordinaire. Nous étions principalement intéressés par deux appareils: un contrôleur d'affichage et un contrôleur de réseau.
Le monocube utilise un contrôleur graphique de la série
sm750 . Ceci est un contrôleur graphique pour les applications intégrées, a un support intégré pour les graphiques 2D. La puce est soudée directement sur la carte mère, si je comprends bien. Les sources du pilote pour Linux peuvent être trouvées
ici .
Une fois le pilote trouvé, il semblait que nos problèmes étaient terminés, il ne restait plus qu'à implémenter le contrôleur pour PCI. plus précisément, les opérations de lecture / écriture de l'espace de configuration PCI pour connaître les paramètres. La mise en œuvre de ces fonctions a dû être empruntée à nouveau. En conséquence, la lecture des enregistrements se résumait à des macros comme
#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"); \ })
Il y a une certaine compréhension de ce qui se passe. Elbrus possède plusieurs espaces d'adressage alternatifs, comme, par exemple, dans l'
architecture SPARC . L'identification se fait à l'aide de l'identifiant de l'espace d'adressage. C'est-à-dire que la même commande ld arrive à différentes adresses internes, elle génère également des opérations de lecture de différentes longueurs (8, 16, 32, 64 bits). Si dans SPARC, il s'agit d'une commande lda / sta distincte, alors dans Elbrus en raison des paramètres, il s'agit de la commande ld. Les
fenêtres de registre ont été empruntées à l'architecture SPARC. Je vais reporter une histoire plus détaillée pour les articles suivants.
En conséquence, tout s'est avéré avec PCI. Nous avons pu obtenir toutes les données nécessaires, nous avons transféré le pilote graphique, mais nous avons ensuite rencontré le problème suivant. Pour dessiner une image dans la mémoire vidéo, vous avez dû écrire deux fois. Tout indiquait le cache. Pour résoudre ce problème, il était nécessaire de traiter avec MMU, et cela, comme on dit, ne peut pas être résolu avec la condachka, comme, en principe, de nombreux autres problèmes que nous avons rencontrés et rencontrerons plus d'une fois au cours du développement de cette architecture.
Nous avons progressé dans d'autres directions: les interruptions et les appels système, mais nous en parlerons également dans les prochains articles de cette sous-série. À la fin de cet article, je vais simplement apporter la sortie à la console (via le port série).
Conclusions
Comme je l'ai dit dans l'introduction, je veux me concentrer principalement non pas sur les détails techniques, mais sur les sentiments généraux. Ainsi, les sentiments sont contradictoires, bien que certainement plus positifs. D'une part, le processeur existe et est très intéressant en termes de caractéristiques architecturales. Sur la base de ce processeur, des systèmes informatiques sont produits, il existe des logiciels de qualité assez élevée. Comme je l'ai dit, il n'y a pas eu de plaintes concernant le compilateur (jusqu'à un certain point, que je décrirai un peu plus tard), il existe un Linux à part entière (OS «Elbrus»). J'ai personnellement vu comment dans l'ICST lui-même, le développeur a créé directement sur le bureau avec l'architecture Elbrus.
Mais d'un autre côté, je ne comprends pas pourquoi avec une telle persévérance ils essaient de faire un remplacement banal d'Intel x86 à partir de ce processeur. En effet, nulle part dans le monde n'utilisent des processeurs basés sur l'architecture
VLIW comme ordinateurs personnels universels. VLIW, en raison de ses caractéristiques architecturales, est un "broyeur de nombres" sympa, ils font du DSP dessus, ils ont fait des serveurs itanium, ils ont fait des cartes graphiques. Non, avec une pelle, bien sûr, vous pouvez creuser un trou pour planter un arbre, mais ça vaut le coup.
Le principal problème qui entrave le développement de l'architecture, à mon avis, est la nature fermée de tout l'écosystème. Oui, pour obtenir une description du système de commande, il vous suffit de signer le NDA, mais cela ne suffit pas. L'architecture est peu familière et très complexe. Oui, j'ai toujours pensé que certains logiciels de base devraient être développés directement par le fabricant du processeur, ou en étroite collaboration avec lui. Selon ce principe, un PC sur Elbrus dispose d'un progiciel avec
le système d'exploitation Elbrus . Mais il est encore trop naïf de croire qu'une entreprise, même grande, peut fournir un support de qualité à tous les composants: un processeur, un compilateur, des outils de développement et de débogage, des logiciels système (différents OS), des logiciels d'application, ... même Intel ne peut pas faire ça. Le monde s'oriente depuis longtemps vers ce que l'on appelle la collaboration ou le développement conjoint.
Permettez-moi de vous donner un exemple d'un problème de compilation sur lequel nous sommes tombés. À un moment donné, le pilote du port série a cessé d'afficher des caractères et, à première vue, rien n'a changé. Il s'est avéré que nous avons supprimé la fonction de débogage inutilisée, que nous avons insérée afin de comprendre à travers le désassembleur comment passer des arguments à la fonction dans l'assembleur. Autrement dit, si la fonction est présente, tout va bien, sinon, la sortie disparaît. Au début, ils ont péché pour l'alignement, mais il s'est avéré que la fonction peut être transférée à la fin de C-Schnick, donc tous les caractères du pilote étaient aux mêmes endroits qu'auparavant, mais le problème a été reproduit. Bien que ce problème n'ait pas été résolu, nous continuons d'enquêter pour montrer aux développeurs du compilateur du MCST ou pour comprendre où nous avons fait une erreur.
À mon avis, le problème ci-dessus aurait pu être évité s'il y avait plus d'utilisateurs tiers. Au minimum, le problème serait apparu plus tôt, ou, on pourrait simplement google ce que nous avons fait de mal.
L'ICST est également conscient du problème de la fermeture, car le processus de découverte de choses non classifiées a néanmoins commencé. Par exemple, j'ai vu Alt-Linux travailler sur plusieurs PC Elbrus lors de plusieurs conférences. Voici des photos de l'affichage d'une des conférences de cette année (désolé de voir mal, il faisait noir). Nous nous sommes également liés au développement. Nous espérons que nous serons utiles à l'ICST, car, en fait, certains des points forts de l'architecture Elbrus ne peuvent pas être pris en charge sous Linux (ou les coûts sont très élevés), par exemple, la mémoire balisée.
Un autre point important lorsque nous avons discuté du problème de la fermeture avec les développeurs du MCST, ils ont objecté que, par exemple, les sources du noyau Linux étaient ouvertes depuis longtemps, mais seuls nous et les développeurs Dolomant avons posé des questions et les avons utilisés d'une manière ou d'une autre.
De plus, selon mes informations, le MCST va organiser un stand
accessible à distance. Sur lequel il sera possible d'assembler et d'exécuter des logiciels sur un PC avec l'architecture Elbrus. S'il y a un intérêt similaire et que vous souhaitez utiliser le stand, vous devez contacter, par exemple, moi: décrire comment il est prévu de l'utiliser, combien de temps cela prend, etc., car pour partager avec changer le logiciel, vous devez organiser un calendrier. Je transférerai les données à l'ICST ou je relierai ceux qui le souhaitent aux organisateurs.
Liens utiles:
L'adresse postale des utilisateurs est user [at] mcst.ru
Une brève description de l'architecture d'ElbrusSources d'emboxPS Nous montrerons à tous ceux qui veulent ce que nous avons obtenu au festival
TechTrain IT
les 1er et 2 septembre.