भाग 6: पोर्टिंग मेमटेस्टी + से आरआईएससी-वी

शायद कुछ आईटी लोगों को यह समझाने की जरूरत है कि मेमेस्टोरी + क्या है - शायद यह पहले से ही पीसी पर रैम की जांच करने के लिए कम या ज्यादा मानक बन गया है। जब पिछले हिस्सों में से एक में मैं एक टूटी हुई मेमोरी बार में आया था जो बोर्ड के साथ बंडल में आया था, तो यह (एक डीडीआर 2-सक्षम नेटबुक के साथ) एक स्पष्ट समाधान लग रहा था। एक और सवाल यह है कि वहाँ, सिद्धांत रूप में, सिस्टम का अस्थिर संचालन नग्न आंखों को दिखाई दे रहा था। अधिक पेचीदा मामलों में, मैंने सुना है कि इन्फिनिटी के लिए मेमोरी कोशिकाओं के केलेल "टैपिंग" के अलावा, यह उपकरण कुछ विशेष डेटा पैटर्न का उपयोग करता है, जिस पर डीडीआर ऑपरेशन में त्रुटियों का पता लगाने की अधिक संभावना है। सामान्य तौर पर, एक अद्भुत बात, यह एक दया है कि यहां तक ​​कि नाम में यह भी कहा गया है: 86 - "केवल x86- संगत प्रणालियों के लिए।" या नहीं?

कट के तहत आप RISC-V और उप-योग मेमेस्टोरी + v5.1 को पोर्ट करने के मेरे प्रयासों को देखेंगे। Spoiler: यह चलता है!

अस्वीकरण: परिणामी परियोजना को विशेष रूप से एक विशिष्ट बोर्ड पर एक विशिष्ट रॉकेट विधानसभा पर मेरे द्वारा विशेष रूप से परीक्षण किया गया था। सटीकता और सुरक्षा (विशेषकर अन्य प्रणालियों पर) की गारंटी नहीं है। अपने जोखिम पर उपयोग करें। विशेष रूप से, वर्तमान में आरक्षित मेमोरी क्षेत्रों को किसी भी तरह से संसाधित नहीं किया जाता है यदि वे रैम रेंज में आते हैं।

जैसा कि मैंने पहले ही कहा, बहुत पहले नहीं मैंने अलीएक्सप्रेस पर साइक्लोन IV के साथ एक मदरबोर्ड खरीदा था, लेकिन इसमें मेमोरी छोटी थी। सौभाग्य से, इस बोर्ड की महत्वपूर्ण विशेषताओं में से एक पारंपरिक DDR2 SO-DIMM मॉड्यूल का उपयोग था - मेरी पुरानी नेटबुक की तरह। फिर भी, यह दिलचस्प होगा, इसलिए बोलने के लिए, मेमोरी मॉड्यूल के परीक्षण के लिए एक स्व-होस्टेड समाधान (और, वास्तव में, नियंत्रक भी)। बुरी यादों की परिस्थितियों में मेरी गलतियों को डिबेट करने की संभावना किसी भी तरह से प्रसन्न नहीं थी। विशेष रूप से एक त्वरित समाधान की उम्मीद नहीं है और मानसिक रूप से अनिश्चित काल के लिए एक अन्य कोडांतरक में पूर्ण पुनर्लेखन को स्थगित करने की तैयारी कर रहा है, मैंने मेमटेस्टी + पर एक विकिपीडिया लेख खोला और अचानक कार्ड में "लिखित: सी और विधानसभा" लिखा। हम्म, वह है, हालांकि, वह "... 86" है, लेकिन पूरी तरह से कोडांतरक में नहीं लिखा है? यह उत्साहजनक है। यह केवल रिश्ते को समझने के लिए बनी हुई है।

तो, memtest.org पर जाएं और GPL2 के तहत संस्करण 5.01 डाउनलोड करें। विकास में आसानी के लिए, मैंने इसे GitHub पर पुनः लोड किया। सौभाग्य से, स्रोत संग्रह में ही सही, हमें README.background फ़ाइल द्वारा बधाई दी जाती है, हकदार

मेम्नेस्टोरी-एसएमपी के एनाटॉमी और फिजियोलॉजी

यह कुछ विस्तार से बताता है (और एएससीआईआई-कला के रूप में चित्रों के साथ) कोड के उच्च-स्तरीय संचालन। दस्तावेज़ की शुरुआत में, हमें एक बाइनरी लेआउट दिखाई देता है , जिसमें setup.o , head.o , head.o और कुछ memtest_shared । यह देखना आसान है कि इन तीन ऑब्जेक्ट फ़ाइलों को संबंधित कोडांतरक स्रोतों से प्राप्त किया जाता है। पहली नज़र में, बाकी सब सी में लिखा है! बुरा नहीं, बुरा नहीं ...

नतीजतन, मैंने Makefile को Makefile.arch कॉपी किया और सब कुछ फिर से लिखना शुरू कर दिया, और जो कुछ भी अनुरूप नहीं है उसे बाहर फेंकने की कोशिश की। सबसे पहले, निश्चित रूप से, मुझे RISC-V के लिए एक टूलकिन की आवश्यकता थी, जो कि सौभाग्य से, पिछले प्रयोगों के बाद भी मेरे साथ है। पहले तो मैंने 32-बिट आर्किटेक्चर के लिए एक पोर्ट बनाने के बारे में सोचा, लेकिन फिर मुझे याद आया कि एक 64-बिट प्रोसेसर को बोर्ड पर अपलोड किया गया था, और मेरे पास riscv64- उपसर्ग के साथ riscv64- ।

गीतात्मक विषयांतर: बेशक, 32- और 64-बिट कोड की संगतता के मुद्दे का अध्ययन करने के लिए पहली बात थी। परिणामस्वरूप, 1.3 RISC-V ISA Overview स्टेटमेंट के पैरा 1.3 RISC-V ISA Overview में ISA (इंस्ट्रक्शन सेट आर्किटेक्चर) के अनपेक्षित भाग के लिए विनिर्देशन:

आधार आईएसए को स्पष्ट रूप से अलग करने का मुख्य लाभ यह है कि प्रत्येक आधार आईएसए को अन्य आधार आईएसए के लिए आवश्यक सभी कार्यों का समर्थन करने की आवश्यकता के बिना अपनी आवश्यकताओं के लिए अनुकूलित किया जा सकता है। उदाहरण के लिए, RV64I निर्देश और CSR को छोड़ सकते हैं जो केवल RV32I में संकरे रजिस्टरों से निपटने के लिए आवश्यक हैं। RV32I विकल्प एन्कोडिंग स्थान का उपयोग कर सकते हैं अन्यथा केवल व्यापक पते-स्थान वेरिएंट द्वारा आवश्यक निर्देशों के लिए आरक्षित हैं।

मैं यह भी नोट करना चाहता हूं कि riscv64- उपसर्ग के साथ riscv64- 32-बिट कोड को आसानी से इकट्ठा करने की संभावना है अगर लक्ष्य वास्तुकला सही ढंग से चुना गया है - बाद में उस पर और अधिक।

पोर्ट करते समय, इन दस्तावेजों को काम में रखने के लिए यह समझ में आता है:

• RISC-V इंस्ट्रक्शन सेट मैनुअल वॉल्यूम I: अनप्रीविलाइज्ड ISA
• RISC-V इंस्ट्रक्शन सेट मैनुअल वॉल्यूम II: प्रिविलेज्ड आर्किटेक्चर
• इसके अलावा, कुछ SiFive FU540-C000 मैनुअल - चिप के लिए एक मैनुअल, सॉफ्ट प्रोसेसर के समान व्यवहार, जो कि FPGAs में डीबगिंग के लिए उपयोग किया जाता है, जगह से बाहर नहीं होगा

सेटअप बनाएँ

आइए सहमत होकर शुरू करें: मैं x86 और RISC-V के अलावा अन्य आर्किटेक्चर के लिए आगे के पोर्ट के लिए उपयुक्त पोर्ट प्राप्त करना चाहता हूं। मैं बूट फ़्लॉपीज़ और अन्य x86 बारीकियों को क्रॉस-प्लेटफॉर्म बिल्ड से बाहर फेंकने का प्रस्ताव करता हूं।

हमारे पास आखिरकार क्या है: तीन setup.S फाइलें हैं: setup.S , setup.S और head.S पहले दो की आवश्यकता केवल स्टार्टअप पर होती है, और तीसरे की आवश्यकता तब होती है जब किसी अन्य मेमोरी क्षेत्र में स्थानांतरित किया जाता है। तथ्य यह है कि मेमोरी को "स्वयं के नीचे" का परीक्षण करने के लिए, परीक्षण कोड को पहले एक नए स्थान पर ले जाना चाहिए। ELF में Sich फाइलों को एकत्र किया जाता है, जहां से कोड, डेटा आदि को फिर से लिया जाता है। इसके अलावा, इसे PIC (स्थिति स्वतंत्र कोड) के रूप में एकत्र किया गया है - पहले तो मुझे और भी आश्चर्य हुआ: हालाँकि यह कोड फ्रीस्टैंडिंग है (जो कि कर्नेल, libc इत्यादि के बिना), यह ऐसी उन्नत सुविधाओं का उपयोग करता है।

इसके अलावा, पैरामीटर जो समय-समय पर वास्तुकला को परिभाषित करते हैं, -m32 में आते हैं: -march=i486 , -m32 और इसी तरह। मुझे ऐसा कुछ लिखने की ज़रूरत है, और फिर एक चूसने वाले की तरह । RISC-V आर्किटेक्चर के साथ स्थिति कुछ इस तरह है: rv32 और rv64 (जैसे, अभी भी सबसे ट्रंकेटेड एम्बेडेड और rv128 भविष्य के लिए आरक्षित हैं, लेकिन हम उनमें बहुत रुचि नहीं रखते हैं), और इस उपसर्ग को अक्षर असाइन करके ISA नाम बनता है एक्सटेंशन: i - निर्देशों का मूल पूर्णांक सेट, m - पूर्णांक गुणन और विभाजन, ... बेशक, मैं rv64i करना rv64i , लेकिन Memtest86 शायद ही आसानी से गुणन के बिना वास्तुकला में rv64i जाएगा। सच है, ऐसा लगता है कि कंपाइलर "समस्याग्रस्त" निर्देशों के बजाय फ़ंक्शन कॉल उत्पन्न करेगा, लेकिन बहुत कम प्रदर्शन के साथ शेष रहने का जोखिम है (यह उल्लेख नहीं करने के लिए कि इन कार्यों को लिखने या कहीं ले जाने की आवश्यकता होगी)।

आपको लाइन एबीआई की भी आवश्यकता होगी। सिद्धांत रूप में, कॉलिंग कन्वेंशन की मूल बातें पहले से निर्दिष्ट Volume I में "RISC-V असेंबली प्रोग्रामर की हैंडबुक" में वर्णित हैं, इसलिए मैं ऐसा कुछ करूंगा

 $ riscv64-linux-gnu-gcc-9 -mabi=help riscv64-linux-gnu-gcc-9: error: unrecognized argument in option '-mabi=help' riscv64-linux-gnu-gcc-9: note: valid arguments to '-mabi=' are: ilp32 ilp32d ilp32e ilp32f lp64 lp64d lp64f riscv64-linux-gnu-gcc-9: fatal error: no input files compilation terminated. 

और lp64 सोचने के बिना, मैं lp64 । आगे देखते हुए, मैं कहूंगा कि इस ABI के साथ, मानक पुस्तकालय से हेडर फाइलें काम नहीं करती lp64f , इसलिए मैंने lp64f और ARCH को "अपग्रेड" किया। घबराहट के बिना, मैं वास्तव में अपने पोर्ट में फ्लोटिंग पॉइंट का उपयोग करने की योजना नहीं बनाता हूं।

चूँकि मैं किसी तरह से क्रॉस-प्लेटफ़ॉर्म लिंकर स्क्रिप्ट लिखने में गहराई से नहीं जाना चाहता - और इसलिए मुझे तुरंत ld की चाबी नहीं मिल रही थी , मैंने कोडांतरक head.S साथ प्राप्त करने का निर्णय लिया। फ़ाइल, memtest_shared.arch.lds का उपयोग करके memtest_shared.arch.lds फ़ंक्शन से memtest_shared.arch.lds । मैंने इससे आउटपुट प्रारूप और वास्तुकला का एक संकेत बाहर फेंक दिया (आखिरकार, इसे DISCARD में एक चर से बदलना आसान है), और अंत में DISCARD की अस्थायी रूप से टिप्पणी भी की, मुझे डीबगिंग जानकारी के विशिष्ट खंडों का पता लगाने में सक्षम नहीं होना चाहिए। (आगे देखते हुए: ठीक डिबगिंग जानकारी, लेकिन .rela को .rela पड़ा) आम तौर पर बोलते हुए, x86 संस्करण ने 64k में फिट होने की आवश्यकता पर जोर दिया - मुझे आशा है कि यह किसी भी तरह वास्तविक मोड की विशेषताओं से संबंधित है और RISC-V से हमें चिंतित नहीं करता है। । परिणामस्वरूप, PIC के साथ साझा की गई वस्तु को एकत्र किया जाएगा, जैसा कि मूल में है, कोड और डेटा जिसे मेमोरी में लोड किया जाएगा उसे काट दिया जाएगा।

हम एकत्र करते हैं ... और संकलन पहली reloc.c फ़ाइल पर आता है - यह, जाहिरा तौर पर, कुछ ld-linux.so से लिया गया है और ग्लोबल ऑफ़सेट टेबल आदि का समर्थन करने के लिए जिम्मेदार है। x86 के लिए कॉलिंग सम्मेलनों के अनुसार। यह पता चला है कि यह कोडांतरक आवेषण का उपयोग कर रजिस्टरों के साथ सीधे काम करने की आवश्यकता है। लेकिन हम RISC-V पर हैं - यह मूल रूप से PIC का समर्थन करने के लिए बनाया गया था, इसलिए reloc.c को फेंकने के लिए स्वतंत्र महसूस करें। इसके अलावा, अभी भी आवेषण थे, कभी-कभी काफी लंबे। सौभाग्य से, वे या तो परीक्षण कोड में सी कोड के तुरंत बाद थे, जिसे वे ऑप्टिमाइज़ करते हैं (उनसे मैंने फिर से प्रीप्रोसेसर निर्देश द्वारा स्विच किए गए कोड के पूर्ण टुकड़े किए) या कुछ प्लेटफ़ॉर्म-निर्भर, जिसके बिना, चरम मामलों में, मैं (शायद) कर सकता हूं करना (जैसे कैश को चालू / बंद करना, सीपीयूआईडी को घटाना, आदि)। अंत में, rdtsc कॉल जैसी कुछ चीजें थीं, जिन्हें मैंने rdtsc , बिना किसी बड़ी समस्या के एक प्लेटफ़ॉर्म-निर्भर हेडर में डाल दिया और इसे RISC-V पर प्रलेखन के अनुसार लागू किया।

नतीजतन, हमें arch/i386 निर्देशिका मिली, जहां पीसीआई समर्थन कोड की एक बड़ी मात्रा चली गई, चिपसेट से जानकारी, मेमोरी-मैप किए गए पते की प्लेटफ़ॉर्म-विशिष्ट परिभाषाएं, आदि पढ़ें। इसके अलावा, test_start फ़ंक्शन की शुरुआत test_start , जो setup.S से C कोड में प्रवेश बिंदु है। कितनी लंबी, छोटी, लेकिन हर उस चीज़ पर टिप्पणी करना जो संभव है और उस चीज़ को साकार करना जो RISC-V (जैसे setup.S और कोड के साथ काम करने के लिए कोड के तहत टिप्पणी नहीं की जा सकती। SiFive कार्यान्वयन में सीरियल पोर्ट), मुझे arch/riscv , जिसके साथ सब कुछ कम या ज्यादा संकलित था।

यहां मुझे यह स्पष्ट करने के लिए मजबूर किया जाता है कि लेख के लेखन से पहले प्रयोग खुद आंशिक रूप से किए गए थे, इसलिए क्रियाओं के एक विशिष्ट अनुक्रम में "कलात्मक कथा" की एक निश्चित मात्रा हो सकती है। हालांकि, मैं कम से कम प्रस्तुति को इस तरह से संचालित करने की कोशिश करता हूं कि किसी भी स्थिति में यह संभावित रास्तों में से एक का प्रतिनिधित्व करता है (मैं एक प्रोग्रामर हूं, मुझे वह याद है) । तो आइए देखते हैं कि यह सब कैसे शुरू किया जाए।

लोहे पर चल रहा है

पिछले प्रयोगों के बाद से, मेरे पास अभी भी रास्पबेरी पाई से धूल भरा "स्टैंड" है, जिसे डिबग बोर्ड पर रखा गया है। तारों UART, JTAG और एक एसडी कार्ड के साथ एक एडाप्टर प्रदान करते हैं। DDR2 नियंत्रक के साथ एक निश्चित RV64 प्रोसेसर को कॉन्फ़िगरेशन मेमोरी में सीवन किया जाता है। जैसा कि पिछले समय में, मैं "रास्पबेरी" चालू करता हूं, इसके पहले दो एसएसएच सत्र खोलें, जिनमें से एक को ओपनओसीडी में जीडीबी को जोड़ने के लिए 3333 टीसीपी पोर्ट के आगे। एक सत्र में, मैं UART के लिए देखने के लिए मिनिकॉम शुरू करता हूं, दूसरे में - JTAG के माध्यम से मेजबान से डिबग करने के लिए ओपनकाड। मैं बोर्ड की शक्ति को चालू करता हूं - और कंसोल में संदेश देता हूं कि यह एसडी से डेटा कैसे लोड करता है।

अब आप कमांड चला सकते हैं:

 riscv64-unknown-elf-gdb \ -ex 'target remote 127.0.0.1:3333' \ -ex 'restore /path/to/memtest_shared.bin binary 0x80010000' \ -ex 'add-symbol-file /path/to/memtest_shared 0x80010000' -ex 'set $pc=0x80010000' 

-ex विकल्प gdb को यह ढोंग करने का -ex कि उपयोगकर्ता ने कंसोल से इन कमांडों में प्रवेश किया है:

• पहले OpenOCD के साथ संबंध स्थापित करता है
• दूसरी निर्दिष्ट होस्ट फ़ाइल की सामग्री को निर्दिष्ट पते पर कॉपी करता है
• तीसरे ने gdb को समझाया कि स्रोत कोड के बारे में जानकारी इस फ़ाइल से ली जानी चाहिए, इस तथ्य को ध्यान में रखते हुए कि इसे इस पते पर डाउनलोड किया गया था (और इसमें जो संकेत दिया गया है वही नहीं)
  
  • नोट: हम ELF फ़ाइल से वर्ण लेते हैं, और "कच्चे" बाइनरी लोड करते हैं
• अंत में, चौथा वर्तमान कमांड पॉइंटर को हमारे कोड में जबरन ट्रांसलेट करता है

दुर्भाग्य से, सब कुछ पूरी तरह से सुचारू रूप से नहीं चलता है, और यद्यपि डिबगर में कोड की रेखाएं सही ढंग से प्रदर्शित होती हैं, लेकिन सभी वैश्विक चर - शून्य में। वास्तव में, यदि हम gdb में फॉर्म p &global_var कमांड को निष्पादित करते हैं, तो, हम, प्रारंभिक डाउनलोड पते (मेरे पास 0x0 ) के अनुसार पता देखते हैं, जो add-symbol-file का उपयोग करके निर्दिष्ट नहीं है। एक बैसाखी के रूप में, लेकिन एक बहुत ही सरल समाधान, मैंने बस 0x80010000 को निर्दिष्ट पते पर मैन्युअल रूप से जोड़ा और मेमोरी की सामग्री को x/x 0xADDR माध्यम से x/x 0xADDR । वास्तव में, लिंकर स्क्रिप्ट में सही शुरुआती पते को अस्थायी रूप से इंगित करना संभव होगा, जो इस परीक्षण कॉन्फ़िगरेशन में डाउनलोड पते के साथ मेल खाएगा ।

आधुनिक वास्तुकला पर पुनर्वास की विशेषताएं

खैर, कोड को किसी तरह डाउनलोड करने के लिए हमने इसे कैसे निकाला - हम इसे शुरू करते हैं। काम नहीं करता है। चरण-दर-चरण डिबगिंग से पता चलता है कि हम switch_to_main_stack फ़ंक्शन के संचालन के दौरान आते हैं - ऐसा लगता है कि यह अभी भी कार्य स्टैक के अनुरूप प्रतीक के पते के असंबंधित मूल्य का उपयोग करने की कोशिश कर रहा है।

सभी समान, प्रलेखन की पहली मात्रा हमें अलग-अलग छद्म निर्देशों और पीआईसी के साथ उनके काम के बारे में बताती है:

जैसा कि आप देख सकते हैं, सामान्य सिद्धांत यह है कि स्मृति में पते वर्तमान निर्देश से गिने जाते हैं, पहले ऑफसेट के शीर्ष को जोड़ते हैं, और अगला add कम-ऑर्डर बिट्स को पॉलिश करते हैं। यह शायद ही किसी वैश्विक वैरिएबल को घोषित करने में मदद करता है

 struct vars * const v = &variables; 

इसलिए, हम RISC-V ELF psABI प्रलेखन को रिलोकेशन के प्रकारों के विवरण के साथ लेते हैं और reloc.c लिए प्लेटफ़ॉर्म-विशिष्ट भाग reloc.c । यहां यह ध्यान दिया जाना चाहिए कि मूल फ़ाइल, जाहिरा तौर पर, क्रॉस-प्लेटफ़ॉर्म कोड से ली गई थी। वहां भी, एक विशिष्ट बिट गहराई को निर्दिष्ट करने के बजाय, ElfW(Addr) मैक्रोज़ का ElfW(Addr) , जो Elf32_Addr या Elf64_Addr में Elf32_Addr Elf64_Addr । हर जगह नहीं, हालांकि, इसलिए हम उन्हें जोड़ते हैं जहां वे सामान्य कोड में नहीं होते हैं (साथ ही साथ arch/riscv/reloc.inc.c - आखिरकार, RISC-V के लिए एक विशिष्ट बिट गहराई से बंधा होने के लिए कोई विशेष अर्थ नहीं है, जहां यह नहीं है आवश्यक)।

नतीजतन, switch_to_main_stack (निश्चित रूप से प्लेटफ़ॉर्म-निर्भर switch_to_main_stack निर्देशों के बिना नहीं) पास करना शुरू कर दिया। डिबगर अभी भी कुटिल रूप से वैश्विक चर दिखाता है। ठीक है, ठीक है :(

हार्डवेयर परिभाषा

बेशक, परीक्षणों के लिए, फेंके गए उपकरण परिभाषा कोड के बजाय हार्ड-कोडेड स्थिरांक का उपयोग करना संभव होगा, लेकिन प्रत्येक विशिष्ट प्रोसेसर असेंबली के लिए, मेरे आवेदन के मानकों के अनुसार मेमस्टेस्ट का पुनर्निर्माण भी महंगा है। इसलिए, हम "गंभीर वयस्कों के रूप में" कार्य करेंगे। सौभाग्य से, RISC-V (और शायद अधिकांश आधुनिक आर्किटेक्चर पर), यह बूटलोडर के लिए डिवाइस ट्री ब्लॉब पर एक कोड पारित करने के लिए प्रथागत है, जो इस तरह डीटीएस विवरण का संकलित संस्करण है:

 /dts-v1/; / { #address-cells = ^_^lt gt^_^; #size-cells = ^_^lt gt^_^; compatible = "freechips,rocketchip-unknown-dev"; model = "freechips,rocketchip-unknown"; chosen { bootargs = "console=ttySIF0,125200 debug loglevel=7"; }; firmware { sifive,uboot = "YYYY-MM-DD"; }; L16: aliases { serial0 = &L8; }; L15: cpus { #address-cells = ^_^lt gt^_^; #size-cells = ^_^lt&#0;gt^_^; timebase-frequency = ^_^lt󴉀gt^_^; L5: cpu@0 { device_type = "cpu"; clock-frequency = ^_^lt&#0;gt^_^; compatible = "sifive,rocket0", "riscv"; d-cache-block-size = ^_^lt gt^_^; d-cache-sets = ^_^lt@gt^_^; d-cache-size = ^_^ltကgt^_^; d-tlb-sets = ^_^lt gt^_^; d-tlb-size = ^_^lt gt^_^; i-cache-block-size = ^_^lt gt^_^; i-cache-sets = ^_^lt@gt^_^; i-cache-size = ^_^ltကgt^_^; i-tlb-sets = ^_^lt gt^_^; i-tlb-size = ^_^lt gt^_^; mmu-type = "riscv,sv39"; next-level-cache = <&L10>; reg = <0x0>; riscv,isa = "rv64imafdc"; status = "okay"; timebase-frequency = ^_^lt󴉀gt^_^; tlb-split; L3: interrupt-controller { #interrupt-cells = ^_^lt gt^_^; compatible = "riscv,cpu-intc"; interrupt-controller; }; }; }; L10: ram@80000000 { device_type = "memory"; reg = <0x0 0x80000000 0x0 0x40000000>; reg-names = "mem"; }; L14: soc { #address-cells = ^_^lt gt^_^; #size-cells = ^_^lt gt^_^; compatible = "freechips,rocketchip-unknown-soc", "simple-bus"; ranges; L1: clint@2000000 { compatible = "riscv,clint0"; interrupts-extended = <&L3 3 &L3 7>; reg = <0x2000000 0x10000>; reg-names = "control"; }; L2: debug-controller@0 { compatible = "sifive,debug-013", "riscv,debug-013"; interrupts-extended = <&L3 65535>; reg = <0x0 0x1000>; reg-names = "control"; }; L9: gpio@64002000 { #gpio-cells = ^_^lt gt^_^; #interrupt-cells = ^_^lt gt^_^; compatible = "sifive,gpio0"; gpio-controller; interrupt-controller; interrupt-parent = <&L0>; interrupts = <3 4 5 6 7 8>; reg = <0x64002000 0x1000>; reg-names = "control"; }; L0: interrupt-controller@c000000 { #interrupt-cells = ^_^lt gt^_^; compatible = "riscv,plic0"; interrupt-controller; interrupts-extended = <&L3 11 &L3 9>; reg = <0xc000000 0x4000000>; reg-names = "control"; riscv,max-priority = ^_^lt gt^_^; riscv,ndev = ^_^lt gt^_^; }; L6: rom@10000 { compatible = "sifive,maskrom0"; reg = <0x10000 0x2000>; reg-names = "mem"; }; L8: serial@64000000 { compatible = "sifive,uart0"; interrupt-parent = <&L0>; clocks = <&tlclk>; interrupts = ^_^lt gt^_^; reg = <0x64000000 0x1000>; reg-names = "control"; }; L7: spi@64001000 { #address-cells = ^_^lt gt^_^; #size-cells = ^_^lt&#0;gt^_^; compatible = "sifive,spi0"; interrupt-parent = <&L0>; interrupts = ^_^lt gt^_^; reg = <0x64001000 0x1000>; clocks = <&tlclk>; reg-names = "control"; L12: mmc@0 { compatible = "mmc-spi-slot"; disable-wp; reg = <0x0>; spi-max-frequency = ^_^lt gt^_^; voltage-ranges = <3300 3300>; }; }; tlclk: tlclk { #clock-cells = ^_^lt&#0;gt^_^; clock-frequency = ^_^lt gt^_^; clock-output-names = "tlclk"; compatible = "fixed-clock"; }; }; }; 

मैं ईएलएफ फ़ाइलों को पार्स करता था, लेकिन अब मैं फिर से एफडीटी (फ्लैट डिवाइस ट्री) के साथ आश्वस्त हूं: इन प्रकार के विनिर्देशों को अच्छी देखभाल करने वाले लोग लिखते हैं (फिर भी, वे खुद तो इसे पार्स करते हैं!) और ऐसी फ़ाइलों को पार्स करना (कम से कम जब तक आपको अविश्वासित इनपुट को संसाधित करने की आवश्यकता नहीं है) कोई विशेष समस्या नहीं है। तो यहाँ: फ़ाइल की शुरुआत में एक साधारण हेडर संरचना होती है जिसमें मैजिक नंबर 0xd00dfeed और कुछ और फ़ील्ड होते हैं। हम "फ्लैट ट्री" off_dt_struct और पंक्ति तालिका off_dt_strings की ऑफ़सेट में रुचि रखते हैं। दरअसल, आपको off_mem_rsvmap को प्रोसेस करने की भी आवश्यकता off_mem_rsvmap , जो कि स्मृति से बचने वाले क्षेत्रों की गणना करता है। मैं अभी भी उन्हें अनदेखा करता हूं (वे मेरे बोर्ड पर नहीं हैं), लेकिन घर पर इसे दोहराएं नहीं ।

सिद्धांत रूप में, प्रसंस्करण विशेष रूप से मुश्किल नहीं है: आपको बस टोकन के अनुसार एक सपाट पेड़ पर चलने की आवश्यकता है। तीन प्रमुख टोकन हैं:

• FDT_BEGIN_NODE - इसके तुरंत बाद के अतिरिक्त डेटा में, शून्य-समाप्त स्ट्रिंग के रूप में सबट्री तत्व का नाम आता है। बस स्टैक में नाम जोड़ें
• FDT_END_NODE - सबट्री खत्म हो गई है, स्टैक से तत्व को हटा दें
• FDT_PROP - यहाँ थोड़ा पेचीदा मामला है: यह एक संरचना द्वारा पीछा किया जाता है, इसके बाद अतिरिक्त डेटा के लेन बाइट्स होते हैं। "वैरिएबल" का नाम स्ट्रिंग टेबल में ऑफसेट nameoff है
  

   struct { uint32_t len; uint32_t nameoff; } 

ठीक है, सामान्य तौर पर, यह सब: हम इस अनुभाग से गुजरते हैं, 4 बाइट्स द्वारा संरेखण का निरीक्षण करना नहीं भूलते हैं। अरे हां, मरहम में एक मक्खी: एफडीटी में संख्याएं बड़े एंडियन प्रारूप में हैं, इसलिए हम एक सरल कार्य करते हैं

 static inline uint32_t be32(uint32_t x) { return (x << 24) | (x >> 24) | ((x & 0xff0000) >> 8) | ((x & 0xff00) << 8); } 

परिणामस्वरूप, riscv_entry पहली बात FDT को पार्स करना है, और head.S का हिस्सा है। जो नियंत्रण को riscv_entry स्थानांतरित करने के लिए जिम्मेदार है, riscv_entry कुछ इस तरह दिखता है

  .globl startup_32 #  --    ... startup_32: lla sp, boot_stack_top mv s0, a0 # s0, s1 -- callee-saved mv s1, a1 # ...  .bss #   jal _dl_start #      mv a0, s0 mv a1, s1 j riscv_entry 

रजिस्टर a0 hart id हमें दी गई है (hart RISC-V शब्दावली में एक हार्डवेयर स्ट्रीम की तरह है) - मैं अभी तक इसका उपयोग नहीं करता, मुझे इसे एकल-थ्रेडेड मामले में समझाना होगा। a1 बूटलोडर FDT के लिए एक पॉइंटर रखता है। हम इसे फंक्शन void riscv_entry(ulong hartid, uint8_t *fdt_address) ।

अब, मेरे कोड में FDT पार्सिल्का के आगमन के साथ, बोर्ड का लोडिंग क्रम इस प्रकार हो गया:

• सत्ता चालू करो
• U- बूट कंसोल के लिए प्रतीक्षा करें
• सही FDT तैयार करने के लिए इसमें कमांड दर्ज करें। विशेष रूप से, /chosen/bootargs कमांड /chosen/bootargs कर्नेल कमांड लाइन को संग्रहीत करता है। बाकी सब कुछ जो मैं एफडीटी से लेता हूं - रैम रेंज, यूएआरटी पता, ... - के रूप में छोड़ा जा सकता है और होना चाहिए
  

   run fdtsetup fdt set /chosen bootargs "console=ttyS0 btrace" 

• fdt addr कमांड का उपयोग करते हुए, यदि आपने नहीं देखा है, तो FDT डाउनलोड पता प्राप्त करें

और gdb की तरफ से कमांड को जोड़ा जाता है

• -ex 'set $a1=0xfdtaddr'

स्क्रीन पर सूचना उत्पादन

जैसा कि यह निकला, कोडांतरक आवेषण के अलावा, स्मृति पते भी हैं। उदाहरण के लिए SCREEN_ADR (ठीक उसी तरह, जैसे कि एक D साथ), जो स्क्रीन पर प्रदर्शित होने के अनुरूप क्षेत्र को इंगित करता है। जब मैं इस पार आया, तो मैंने बस एक विस्तृत इशारे के साथ सब कुछ रखा जो इसे #if HAS_SCREEN तहत संदर्भित करता है, और फिर लंबे समय तक #if HAS_SCREEN डिबग किया गया। मैंने सोचा कि कुछ समय में एक बार मैन्युअल रूप से यह सब सांत्वना के लिए डंप कर दिया जाए, लेकिन फिर मैंने देखा कि एक ही कोड दर्दनाक रूप से सीरियल पोर्ट के लिए कई एस्केप सीक्वेंस आउटपुट देता है। यह पता चला है कि सब कुछ हमारे सामने पहले ही लिखा जा चुका था, आपको बस परिभाषित को अधिक सटीक रूप से रखने की आवश्यकता है - और यहां यह है, मिनीकैम विंडो में परिचित इंटरफ़ेस (काले और सफेद)! (फिलहाल, HAS_SCREEN का उपयोग बिल्कुल नहीं किया जाता है - मैंने मूल कोड को न्यूनतम पर बदलने के लिए dummy_con सरणी शुरू की है।)

QEMU पर डिबगिंग

इसलिए मैंने एक असली बोर्ड पर सब कुछ डिबेट किया, और कुछ समय के लिए - आँख बंद करके भी नहीं। लेकिन JTAG पर सब कुछ धीमा हो गया - आतंक! खैर, अंत में, सब कुछ वास्तविक हार्डवेयर पर काम करना चाहिए, लेकिन QEMU पर डिबग करना अच्छा होगा। प्रयोगों की एक निश्चित संख्या के बाद, कुछ एक बैसाखी निकला, लेकिन बोर्ड के साथ काम करने के समान:

 $ qemu-system-riscv64 -M help Supported machines are: none empty machine sifive_e RISC-V Board compatible with SiFive E SDK sifive_u RISC-V Board compatible with SiFive U SDK spike_v1.10 RISC-V Spike Board (Privileged ISA v1.10) (default) spike_v1.9.1 RISC-V Spike Board (Privileged ISA v1.9.1) virt RISC-V VirtIO Board (Privileged ISA v1.10) 

हम देखते हैं कि कौन से बोर्ड QEMU का अनुकरण करने के लिए तैयार हैं। मुझे sifive_u संगत हार्डवेयर में दिलचस्पी है।

 $ qemu-system-riscv64 -M sifive_u,dumpdtb -m 1g # - QEMU      on --  strace   $ ls -l on -rw-rw-r-- 1 trosinenko trosinenko 1923  19 20:14 on $ dtc -I dtb < on > on.dts #   $ vim on.dts #  bootargs $ dtc < on.dts > on.dtb <stdout>: Warning (clocks_property): /soc/ethernet@100900fc:clocks: cell 0 is not a phandle reference <stdout>: Warning (clocks_property): /soc/ethernet@100900fc:clocks: cell 1 is not a phandle reference <stdout>: Warning (clocks_property): /soc/ethernet@100900fc:clocks: cell 2 is not a phandle reference <stdout>: Warning (interrupts_extended_property): /soc/interrupt-controller@c000000:interrupts-extended: cell 0 is not a phandle reference <stdout>: Warning (interrupts_extended_property): /soc/interrupt-controller@c000000:interrupts-extended: cell 2 is not a phandle reference <stdout>: Warning (interrupts_extended_property): /soc/clint@2000000:interrupts-extended: cell 0 is not a phandle reference <stdout>: Warning (interrupts_extended_property): /soc/clint@2000000:interrupts-extended: cell 2 is not a phandle reference 

अब हमारे पास एक "फिक्स्ड" डिवाइस ट्री ब्लॉब है। VM (बैसाखी!) के कॉन्फ़िगरेशन को बदले बिना , चलाएं:

 qemu-system-riscv64 \ -M sifive_u -m 1g \ -serial stdio \ -s -S 

-serial stdio सीरियल पोर्ट को कंसोल पर पुनर्निर्देशित करता है, क्योंकि एस्केप अनुक्रम सक्रिय रूप से उपयोग किए जाएंगे। -s -S विकल्प क्रमशः gdbserver बढ़ाते हैं और एक VM को विराम देते हैं। आप loader का उपयोग करके कोड डाउनलोड कर सकते हैं, लेकिन फिर आपको हर बार QEMU को पुनरारंभ करना होगा।

आप का उपयोग कर कनेक्ट कर सकते हैं

 riscv64-unknown-elf-gdb \ -ex 'target remote 127.0.0.1:1234' \ -ex 'restore /path/to/on.dtb binary 0x80100000' \ -ex 'restore /path/to/memtest_shared.bin binary 0x80020000' \ -ex 'add-symbol-file memtest_shared 0x80100000' \ -ex 'set $a1=0x80020000' \ -ex 'set $pc=0x80100000' 

नतीजतन, सब कुछ चालाकी से अधिक काम करता है!

काम का सामान्य सिद्धांत

, , , Memtest86+ btrace , , ( , QEMU):

, , memtest . , (, trap): , , QEMU - ! «» Illegal instruction , . mcause (?), — mepc (?), — mtval ( ?), .

, :

head.S:

 #       #   = 0 ---   ,   #  ,    ,     ... lla t1, _trap_entry csrw mtvec, t1 # ... _trap_entry: csrr a0, mcause csrr a1, mepc csrr a2, mtval jal riscv_trap_entry 

, calling convention, . memtest, HiFive_U-Boot, Volume II :

arch.c:

 static const char *errors[] = { "Instruction address misaligned", "Instruction access fault", "Illegal instruction", "Breakpoint", "Load address misaligned", "Load access fault", "Store/AMO address misaligned", "Store/AMO access fault", ^_^quot quot^_^, ^_^quot quot^_^, ^_^quot quot^_^, ^_^quot quot^_^, "Instruction page fault", "Load page fault", ^_^quot quot^_^, "Store/AMO page fault", }; void riscv_trap_entry(ulong cause, ulong epc, ulong tval) { char buf[32]; cprint(12, 0, "EXCP: "); if (cause < sizeof(errors) / sizeof(errors[0])) { cprint(12, 8, errors[cause]); } else { itoa(buf, cause); cprint(12, 8, buf); } cprint(13, 0, "PC: "); hprint3(13, 8, epc, 8); cprint(14, 0, "Addr: "); hprint3(14, 8, tval, 8); HALT(); } 

— « » . , «» , , , .

: . , memtest : : « , , . ». : do_test main.c 2, ( ), — «» , memtest. , run_at , memtest _start _end ( «» ), - spinlock' goto *addr; . , , «» , «».

, bss — _dl_start , riscv_entry , trap entry. , : L1I-, . , fence.i .

, Memtest86+ — , barrier_s . , . , , .

, : . : . : , - (Own Address, ) . , , . . - . , x86 , , uint64_t 0x80000002 . , : , load/store x86 , — . , QEMU , « , ».

, , — unaligned access ..

, , RocketChip, — QEMU, , , RocketChip — unaligned access trap, QEMU « ».
«misaligned» ,

Changed description of misaligned load and store behavior. The specification now allows visible misaligned address traps in execution environment interfaces, rather than just mandating invisible handling of misaligned loads and stores in user mode. Also, now allows access exceptions to be reported for misaligned accesses (including atomics) that should not be emulated.

, , — , user-mode code , . . , , . , — - machine mode . , rdtsc (x86) rdtime (rv64), trap, . , , memory-mapped .

: , low_test_addr ( ), , fdt . , , low_test_addr , , 2 high_test_adr … , — : head.S initial_load_addr , riscv_entry move_to_correct_addr :

 static void move_to_correct_addr(void) { uintptr_t cur_start = (uintptr_t)&_start; uintptr_t cur_end = (uintptr_t)&_end; if (cur_start == low_test_addr || cur_start == high_test_adr) { //  ,     return; } if (cur_start == initial_load_addr && (cur_start - low_test_addr) < (cur_end - cur_start) ) { //   " ":   , //           //     ,    ,   //     ... serial_echo_print("FIRST STARTUP RELOCATION...\n"); void *temp_addr = (((uintptr_t)&_end >> 12) + 1) << 12; run_at(temp_addr, 0); } else { // ,    --- ,  . serial_echo_print("FINAL STARTUP RELOCATION...\n"); run_at(low_test_addr, 0); } } 

, — , memtest , RAM - . RISC-V , v->plim_lower .

, «» , -, — test.c ulong ( unsigneg long ), 32- x86 uint32_t , « 64 » uint64_t . «!!! Good: ffffffff Real: ffffffff Bad bits: 00000000». ? - -1, 32 1. , , 0… , : , ulong ( uint32_t ), ( uintptr_t ). , . , uint64_t 4. RISC-V , C, , — UB. memtest UBSan. , , UBSan trap-on-error JTAG.

, memtest - , , U-Boot.

: mkimage U-Boot Linux :

 mkimage -A riscv -O linux -T kernel -C none \ -a 0x80000000 -e 0x80000000 \ -n memtest -d memtest.bin memtest.uboot 

SD-

 run mmcsetup; run fdtsetup; fdt set /chosen bootargs "console=ttyS0"; fatload mmc 0:1 82000000 memtest.uboot; bootm fdt; bootm 82000000 - ${fdtaddr} 

( , run — ).

: FDT: 0xbffb7c80 . , : ffffffff , . , ( ), : HiFive_U-Boot :

  theKernel(machid, (unsigned long)images->ft_addr); 

,

  void (*theKernel)(int arch, uint params); 

, , , , 32 , head.S :

  li t0, 0xffffffffL and a1, a1, t0 

, , - , , , :

• x86. — review
• SMP RISC-V
• arch/ -
• test.c RISC-V ( -O0 !)