OS को Aarch64 में पोर्ट करना

एआरएम 64 एआरएम (जिसे कभी-कभी आर्म 64 कहा जाता है) से 64-बिट आर्किटेक्चर है। इस लेख में मैं आपको बताऊंगा कि यह "नियमित" (32-बिट) एआरएम से कैसे भिन्न होता है और आपके सिस्टम को इसे पोर्ट करना कितना मुश्किल है।

यह आलेख एक विस्तृत मार्गदर्शिका नहीं है, बल्कि उन सिस्टम मॉड्यूल का अवलोकन है, जिन्हें फिर से बनाना होगा, और एक पूरे 32-बिट एआरएम से भिन्न रूप में वास्तुकला कितना होगा; यह सब मेरे व्यक्तिगत अनुभव से Embox को इस वास्तुकला में चित्रित करता है। एक विशिष्ट प्रणाली के प्रत्यक्ष पोर्टिंग के लिए, एक तरह से या किसी अन्य को आपको प्रलेखन से निपटना होगा, लेख के अंत में मैंने कुछ दस्तावेजों के लिंक छोड़ दिए जो उपयोगी हो सकते हैं।

वास्तव में, समानताओं की तुलना में अधिक अंतर हैं, और Aarch64 परिचित एआरएम के 64-बिट विस्तार की तुलना में एक नई वास्तुकला का अधिक है। Aarch64 का पूर्ववर्ती काफी हद तक Aarch32 है (यह सामान्य 32-बिट ARM का एक विस्तार है), लेकिन चूंकि मुझे इसके साथ अनुभव नहीं था, इसलिए मैं इसके बारे में नहीं लिखूंगा :)

लेख में आगे, अगर मैं "पुराने" या "पुराने" एआरएम के बारे में लिखता हूं, मेरा मतलब 32-बिट एआरएम (एआरएम के एक सेट के साथ) है।

मैं संक्षेप में 32-बिट एआरएम की तुलना में परिवर्तनों की सूची से गुजरूंगा, और फिर मैं उन्हें और अधिक विस्तार से विश्लेषण करूंगा।

• सामान्य-उद्देश्य रजिस्टर 2 गुना व्यापक हो गए हैं (अब वे प्रत्येक में 64 बिट्स हैं), और उनकी संख्या दोगुनी हो गई है (यानी अब 16 नहीं, बल्कि 32 हैं)।
• msr vbar_el1, x0 रजिस्टरों की अवधारणा से इनकार करते हुए, अब उन्हें केवल नाम से एक्सेस किया जा सकता है, उदाहरण के लिए msr vbar_el1, x0 (पिछले mcr p15, 0, %0, c1, c1, 2 खिलाफ mcr p15, 0, %0, c1, c1, 2 )
• नया MMU मॉडल (यह किसी भी तरह से पुराने के साथ जुड़ा नहीं है, आपको फिर से लिखना होगा)।
• पहले, दो विशेषाधिकार स्तर थे: उपयोगकर्ता (यूएसआर प्रोसेसर मोड के अनुसार) और सिस्टम (एसवाईएस, आईआरक्यू, एफआईक्यू, एबीटी ...) के अनुरूप, अब सब कुछ एक ही समय में आसान और अधिक जटिल है - अब 4 मोड हैं।
• AdvSIMD ने NEON को प्रतिस्थापित किया, फ्लोटिंग-पॉइंट ऑपरेशन इसके माध्यम से किए गए।

अब अंक पर अधिक।

रजिस्टर और निर्देश सेट

सामान्य-उद्देश्य रजिस्टर r0-r30 हैं, जबकि आप उन्हें 64-बिट (x0-x30) या 32-बिट (w0-w30, निचले 32 बिट तक पहुंच) के रूप में एक्सेस कर सकते हैं।

Aarch64 के लिए निर्धारित निर्देश A64 कहलाता है। निर्देशों का विवरण यहां पढ़ें। असेंबली भाषा में मूल अंकगणित और कुछ अन्य आदेश समान रहे:

  mov w0, w1 /*    w1  w0 */ add x0, x1, 13 /*   x0  x1   13 */ b label /* ""   "label" bl label /* ""   "label",     x30 */ ldr x3, [x1, 0] /*   x3 ,    x1 */ str x3, [x0, 0] /*   x3  ,    x0 */ 

अब मतभेदों के बारे में थोड़ा:

• एक विशेष "शून्य" rzr/xzr/wzr , जो पढ़ते समय शून्य है (आप रजिस्टर में लिखने का उपयोग कर सकते हैं, लेकिन गणना परिणाम कहीं भी नहीं लिखा जाएगा)।

 subs xzr, x1, x2 /*  x1  x2    NZCV,       */ 

• आप एक ही बार में कई रजिस्टर ( stmfd sp!, {r0-r3} ) को ढेर में नहीं रख सकते, आपको जोड़े में यह करना होगा:

  stp x0, x1, [sp, 16]! stp x2, x3, [sp, 16]! 

• पीसी रजिस्टर (प्रोग्राम काउंटर, वर्तमान निष्पादन अनुदेश के लिए एक संकेतक) अब एक सामान्य रजिस्टर नहीं है (यह R15 हुआ करता था), इसलिए, इसे सामान्य कमांड ( mov , ldr ) के साथ एक्सेस नहीं किया जा सकता है, केवल ret , bl और इतने पर के माध्यम से।

  
  

• कार्यक्रम की स्थिति अब सीपीएसआर नहीं दिखाती है (यह रजिस्टर बस मौजूद नहीं है), लेकिन डीएआईएफ रजिस्टर (आईआरक्यू, एफआईक्यू मास्क, आदि, एआईएफ - समान बिट्स ए, आई, एफ सीपीएसआर से), एनजेडसीवी (बिट्स नकारात्मक, शून्य, कैरी) , OVerflow - अचानक, CPSR से एक ही NZCV) और सिस्टम कंट्रोल रजिस्टर (SCTLR, कैशिंग, MMU, एंडियननेस और इतने पर सक्षम करने के लिए)।

  
  

ऐसा लगता है कि ये कमांड एक साधारण बूटलोडर लिखने के लिए पर्याप्त हैं जो प्लेटफ़ॉर्म-स्वतंत्र कोड पर नियंत्रण स्थानांतरित कर सकते हैं :)

प्रदर्शन मोड और उनके बीच स्विच करना

प्रदर्शन मोड अच्छी तरह से ARMv8-A के मूल सिद्धांतों में लिखे गए हैं, मैं यहां संक्षेप में इस दस्तावेज़ का सार बताऊंगा।

Aarch64 में 4 विशेषाधिकार स्तर हैं (निष्पादन स्तर, इसके बाद संक्षिप्त रूप से EL)।

• EL3 - सिक्योर मॉनिटर (यह माना जाता है कि फर्मवेयर इस स्तर पर चल रहा है)
• EL2 - हाइपरवाइजर
• ईएल 1 - ओएस
• EL0 - अनुप्रयोग

64-बिट OS पर, आप 32-बिट और 64-बिट दोनों अनुप्रयोगों को चला सकते हैं; 32-बिट OS पर, केवल 32-बिट एप्लिकेशन चलाए जा सकते हैं।

ईएल के बीच परिवर्तन अपवादों (सिस्टम कॉल, इंटरप्ट, मेमोरी एक्सेस एरर) के माध्यम से किए जाते हैं, या अपवाद ( eret ) eret से रिटर्न का उपयोग करके किया जाता है।

प्रत्येक EL का अपना रजिस्टर SPSR, ELR, SP होता है (अर्थात यह "बैंक रजिस्टर्ड" है)।

कई सिस्टम रजिस्टरों को भी ईएल द्वारा विभाजित किया जाता है - उदाहरण के लिए, एमएमयू संदर्भ रजिस्टर ttbr0 - ttbr0_el2 , ttbr0_el1 , और आपको संबंधित ईएल पर अपने रजिस्टर तक पहुंचने की आवश्यकता है। वही कार्यक्रम की स्थिति रजिस्टर पर लागू होता है - DAIF, NZCV, SCTLR, SPSR, ELR ...

MMU

Armv8-A MMU ARMv8.2 LPA का समर्थन करता है, इसके बारे में अधिक जानकारी ARMv8, Armv8-A के लिए ARM आर्किटेक्चर रेफरेंस मैनुअल के D5 चैप्टर में मिल सकती है।

संक्षेप में, यह MMU 4KiB पृष्ठों (वर्चुअल मेमोरी टेबल के 4 स्तरों), 16KiB (4 स्तरों) और 64KiB (3 स्तरों) का समर्थन करता है। किसी भी मध्यवर्ती स्तर पर, आप एक मेमोरी ब्लॉक निर्दिष्ट कर सकते हैं, इस प्रकार तालिका के अगले स्तर का संकेत नहीं देते हैं, लेकिन आकार की स्मृति का एक पूरा टुकड़ा जिसे अगले स्तर की तालिका को "कवर" करना चाहिए। मेरे पास वर्चुअल मेमोरी के बारे में एक लंबा-चौड़ा लेख है , जहां आप टेबल, अनुवाद के स्तर और उस सब के बारे में पढ़ सकते हैं।

छोटे परिवर्तनों में से, उन्होंने डोमेन से इनकार कर दिया, लेकिन गंदे बिट जैसे झंडे जोड़े।

सामान्य तौर पर, मध्यवर्ती अनुवाद तालिकाओं के बजाय "ब्लॉक" को छोड़कर, कोई विशेष वैचारिक परिवर्तन नहीं देखा गया, MMU MMU के रूप में।

उन्नत सिमड

फ़्लोटिंग पॉइंट और वेक्टर ऑपरेशन (SIMD) के साथ काम करते समय पुराने NEON में महत्वपूर्ण AdvSIMD अंतर हैं। उदाहरण के लिए, यदि पहले D0 में S0 और S1 शामिल थे, और Q0 - D0 और D1 के थे, तो अब ऐसा नहीं है: Q0 D0 और S0 से मेल खाता है, Q1 - D1 और S0 के लिए, और इसी तरह। उसी समय, VFP / SIMD के लिए समर्थन अनिवार्य है, समझौते को कॉल करके अब कोई प्रोग्रामेटिक पैरामीटर ट्रांसफर नहीं होता है (जिसे "सॉफ्ट फ्लोट एबीआई" कहा जाता था, जीसीसी में - फ्लैग -mfloat-abi=softfp ), इसलिए आपको फ़्लोटिंग पॉइंट के लिए हार्डवेयर समर्थन को लागू करना होगा ।

128 बिट्स के 16 रजिस्टर थे:

128 बिट्स के 32 रजिस्टर हैं:

आप इस लेख में NEON के बारे में अधिक पढ़ सकते हैं; Aarch64 के लिए उपलब्ध आदेशों की एक सूची यहां पाई जा सकती है ।

फ़्लोटिंग पॉइंट रजिस्टरों के साथ मूल संचालन:

  fadd s0, s1, s2 /* s0 = s1 + s2 */ fmul d0, d1, d2 /* d0 = d1 * d2 */ 

मूल SIMD संचालन:

  /*  , : NEON,    */ /* q0 = q1 + q2,   --   4     */ vadd.s32 q0, q1, q2 /* : AdvSIMD,    */ /* v0 = v1 + v2,   --   4     */ add v0.4s, v1.4s, v2.4s /*   v1 (  2 64- )    d1 */ addv d1, v1.ds /*     4   0 */ movi v1.4s, 0x0 

मंच

QEMU

AEM64 के लिए QEMU का समर्थन है। प्लेटफार्मों में से एक virt , ताकि यह 64-बिट मोड में शुरू हो, आपको अतिरिक्त रूप से -cpu cortex-a53 पास करने की आवश्यकता है, कुछ इस तरह से:

 qemu-system-aarch64 -M virt -cpu cortex-a53 -kernel ./embox -m 1024 -nographic # ./embox -- ELF-  

क्या अच्छा है, इस मंच के लिए बहुत सारे बाह्य उपकरणों का उपयोग किया जाता है, जिसके लिए ड्राइवर पहले से ही Embox में थे - उदाहरण के लिए, कंसोल के लिए PL011, ARM Generic Interrupt Controller, आदि। बेशक, इन उपकरणों में अलग-अलग आधार रजिस्टर पते और अन्य रुकावट संख्याएं हैं, लेकिन मुख्य बात यह है कि ड्राइवर कोड नई वास्तुकला पर अपरिवर्तित काम करता है। जब सिस्टम शुरू होता है, तो नियंत्रण EL1 में होता है।

i.MX8

लोहे के इस टुकड़े के कारण, Aarch64 - i.MX8MQ Nitrogen8M को पोर्ट करना शुरू किया गया था।

QEMU के विपरीत, यू-बूट ट्रांसफर ईएल 2 में छवि को नियंत्रित करता है, और, इसके अलावा, किसी कारण से इसमें एमएमयू (सभी मेमोरी 1 से 1 मैप की जाती है) शामिल हैं, जो आरंभीकरण के दौरान कुछ अतिरिक्त समस्याएं पैदा करता है।

Embox पहले से ही i.MX6 को सपोर्ट करता है, और, i.MX8 में, परिधि का हिस्सा समान है - उदाहरण के लिए, UART और ईथरनेट, जो भी काम करता है (मुझे कुछ स्थानों को ठीक करना था जहां 32-बिट पतों के लिए एक तंग बंधन था)। दूसरी ओर, बाधा नियंत्रक वहां अलग है - एआरएम जीआईसी 3, जो पहले संस्करण से काफी अलग है।

निष्कर्ष

फिलहाल, Embox में Aarch64 के लिए समर्थन पूर्ण नहीं है, लेकिन पहले से ही न्यूनतम कार्यक्षमता है - इंटरप्ट, MMU, UART के माध्यम से इनपुट-आउटपुट। बहुत कुछ अंतिम रूप दिया जाना है, लेकिन पहला कदम आसान बनाने की तुलना में यह शुरुआत से ही लग रहा था। एआरएम की तुलना में बहुत कम प्रलेखन और लेख हैं, लेकिन हर चीज से निपटने के लिए पर्याप्त जानकारी से अधिक है।

सामान्य तौर पर, यदि आपके पास एआरएम के साथ अनुभव है, तो Aarch64 को पोर्ट करना एक संभव कार्य है। हालांकि, हमेशा की तरह, आप कुछ छोटी चीजों पर ठोकर खा सकते हैं :)

आप हमारी रिपॉजिटरी से QEMU में इसे प्रोक करने के लिए प्रोजेक्ट डाउनलोड कर सकते हैं, यदि आपके कोई प्रश्न हैं - टिप्पणियों में, या न्यूज़लेटर में , या टेलीग्राम में चैट में (एक चैनल भी है)।

उपयोगी लिंक

• A64 निर्देश
• ARMv8-A की बुनियादी बातों
• एआरएम आर्किटेक्चर रेफरेंस मैनुअल फॉर आर्म्व 8, आरएमवी 8-ए
• Aarch64 ABI (सम्मेलन बुलाना)
• एआरएम से एआरएम 64 में माइग्रेटिंग कोड - पोर्टेबल कोड लिखने के लिए सिफारिशों के साथ एक छोटी प्रस्तुति

पुनश्च

24-25 अगस्त, हम TechTrain पर बोल रहे हैं, दो या तीन बार के बारे में हमारे प्रदर्शन को सुनेंगे , स्टैंड पर आएंगे - हम आपके सवालों का जवाब देंगे :)