एंक्लस्ट्रा के मार्स जेडएक्स 3 मॉड्यूल पर आधारित एक गलती-सहिष्णु एंबेडेड लिनक्स सिस्टम का निर्माण

विशेषज्ञों के कार्यभार के कारण, कई साल पहले हमें समकक्षों को एक विकास देने के लिए मजबूर किया गया था। विकास एन्क्लेस्ट्रा मार्स ज़ेडएक्स 3 मॉड्यूल पर किया गया था, जो एसओसी एआरएम + एफपीजीए ज़िनक -7020 का उपयोग करता है। लिनक्स का निर्माण करने के लिए, हमने एनक्लस्ट्रा (bsp-xilinx) से Bcl का उपयोग किया, जिसे थोड़ा संशोधित किया गया था।

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

मार्स जेडएक्स 3 मॉड्यूल में क्यूएसपीआई फ्लैश और नंद फ्लैश चिप्स हैं। हमारे मामले में, मॉड्यूल क्यूएसपीआई फ्लैश से भरा हुआ है, जिसमें यू-बूट लिखा गया था। चूंकि दोनों चिप्स एक ही Zynq-7020 पिन का उपयोग करते हैं, यू-बूट लोड करने के बाद पिन को NAND फ़्लैश पर स्विच करता है, जिस पर बूट अनुभाग, डिवाइस ट्री, लिनक्स कर्नेल, ubifs फ़ाइल सिस्टम, और पर्यावरण चर अलग-अलग वर्गों में लिखे जाते हैं। इसके अलावा, पर्यावरण चर के साथ अनुभाग को छोड़कर सभी खंड, आरक्षित थे (अर्थात, ऐसे दो खंड थे)। निम्नलिखित डिवाइस ट्री फ़ाइल का एक टुकड़ा है, जो दिखाता है कि ठेकेदारों द्वारा हमारे लिए प्रेषित संस्करण में नंद फ्लैश कैसे टूट गया था:

partition@nand-linux { label = "nand-linux"; reg = <0x0 0x500000>; }; partition@nand-device-tree { label = "nand-device-tree"; reg = <0x500000 0x100000>; }; partition@nand-bootscript { label = "nand-bootscript"; reg = <0x600000 0x100000>; }; partition@nand-linux-second { label = "nand-linux-second"; reg = <0x700000 0x500000>; }; partition@nand-device-tree-second { label = "nand-device-tree"; reg = <0xC00000 0x100000>; }; partition@nand-bootscript-second { label = "nand-bootscript"; reg = <0xD00000 0x100000>; }; partition@nand-rootfs { label = "nand-rootfs"; reg = <0xE00000 0xF500000>; }; partition@nand-rootfs-second { label = "nand-rootfs"; reg = <0x10300000 0xF500000>; }; partition@boot-env { label = "nand-env"; reg = <0x1F800000 0x100000>; }; 

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

कॉन्फ़िगरेशन डेटा बैकअप के लिए दो फ़ोल्डरों में दर्ज किया गया था, लेकिन इससे स्थिति नहीं बची। यह माना जाता है कि कॉन्फ़िगरेशन फ़ाइलों की अनुपस्थिति में, वे डिफ़ॉल्ट सेटिंग्स के साथ स्वचालित रूप से फिर से बनाए जाते हैं।

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

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

परिणामस्वरूप, निम्न NAND फ़्लैश विभाजन किया गया:

  partition@nand-linux { label = "nand-linux"; reg = <0x0 0x500000>; }; partition@nand-device-tree { label = "nand-device-tree"; reg = <0x500000 0x100000>; }; partition@nand-bootscript { label = "nand-bootscript"; reg = <0x600000 0x100000>; }; partition@nand-linux-second { label = "nand-linux-second"; reg = <0x700000 0x500000>; }; partition@nand-device-tree-second { label = "nand-device-tree"; reg = <0xC00000 0x100000>; }; partition@nand-bootscript-second { label = "nand-bootscript"; reg = <0xD00000 0x100000>; }; partition@nand-rootfs { label = "nand-rootfs"; reg = <0xE00000 0x9600000>; }; partition@nand-rootfs-second { label = "nand-rootfs"; reg = <0xA400000 0x9600000>; }; partition@nand-data { label = "nand-data"; reg = <0x13A00000 0x5F00000>; }; partition@nand-data-backup { label = "nand-data-backup"; reg = <0x19900000 0x5F00000>; }; partition@boot-env { label = "nand-env"; reg = <0x1F800000 0x100000>; }; 

जब U- बूट कमांड का उपयोग करते हुए NAND फ्लैश चमकता है, तो हम नंद-डेटा और नंद-डाटा-बैकअप अनुभाग मिटाते हैं:

 u-boot>nand erase.part nand-data u-boot>nand erase.part nand-data-backup 

लिनक्स बूट स्क्रिप्ट में, हमने रूट फाइल सिस्टम को रीड-ओनली के रूप में लागू किया, लाइन को लिनक्स असेंबली में / etc / inittab फाइल में बदल दिया:

 ::sysinit:/bin/mount -o remount,rw / 

पर

 ::sysinit:/bin/mount -o remount,ro / 

हमने /etc/init.d/ फ़ोल्डर में एक बूट स्क्रिप्ट जोड़ी, जो पढ़ने और लिखने के लिए नंद-डेटा और नंद-डेटा-बैकअप अनुभागों को मापता है। एक बढ़ते त्रुटि (पहली बूट के दौरान या यदि फ़ाइल सिस्टम क्षतिग्रस्त है) के मामले में, ये विभाजन स्वरूपित और फिर से घुड़सवार हैं। फ़ोल्डर / mnt / डेटा / और / mnt / बैकअप / पहले रूट फ़ाइल सिस्टम में बनाया जाना चाहिए।

 #!/bin/sh # # datafs Mount datafs. # umask 077 start() { printf "Starting mount datafs..." /usr/sbin/ubiattach /dev/ubi_ctrl -m 8 /usr/sbin/ubiattach /dev/ubi_ctrl -m 9 mount_datafs_err=0; mount_datafs_backup_err=0; /bin/mount -t ubifs ubi1:datafs /mnt/data mount_datafs_err=$? if [ $mount_datafs_err -ne 0 ]; then /usr/sbin/ubidetach -p /dev/mtd8 /usr/sbin/ubiformat /dev/mtd8 -y /usr/sbin/ubiattach /dev/ubi_ctrl -m 8 /usr/sbin/ubimkvol /dev/ubi1 -N datafs -s 81MiB /bin/mount -t ubifs ubi1:datafs /mnt/data mount_datafs_err=$? fi /bin/mount -t ubifs ubi2:datafs /mnt/backup mount_datafs_backup_err=$? if [ $mount_datafs_backup_err -ne 0 ]; then /usr/sbin/ubidetach -p /dev/mtd9 /usr/sbin/ubiformat /dev/mtd9 -y /usr/sbin/ubiattach /dev/ubi_ctrl -m 9 /usr/sbin/ubimkvol /dev/ubi2 -N datafs -s 81MiB /bin/mount -t ubifs ubi2:datafs /mnt/backup mount_datafs_backup_err=$? fi printf "Mount datafs: " if [ $mount_datafs_err -ne 0 ]; then echo "Error" else echo "OK" fi printf "Mount backup datafs: " if [ $mount_datafs_backup_err -ne 0 ]; then echo "Error" else echo "OK" fi touch /var/lock/datafs } stop() { /bin/umount /mnt/data /bin/umount /mnt/backup rm -f /var/lock/datafs } restart() { stop sleep 1 start } case "$1" in start) start ;; stop) stop ;; restart|reload) restart ;; *) echo "Usage: $0 {start|stop|restart|reload}" exit 1 esac exit 0 

डाउनलोड करते समय, यदि / mnt / डेटा / फ़ोल्डर में कॉन्फ़िगरेशन फ़ाइलें गायब हैं, तो उन्हें / mnt / backup / फ़ोल्डर से डाउनलोड किया जाता है। यदि / mnt / backup / में कोई कॉन्फ़िगरेशन फ़ाइल नहीं हैं, तो वे डिफ़ॉल्ट पैरामीटर वाले सॉफ़्टवेयर से स्वचालित रूप से बनाए जाते हैं। यदि फाइलें / mnt / डेटा में मौजूद हैं, लेकिन / mnt / backup / में नहीं हैं , तो उन्हें / mnt / data / से / mnt / backup / से कॉपी किया जाता है। ये सभी ऑपरेशन यूजर सॉफ्टवेयर द्वारा किए जाते हैं।

अगले चरण में, विश्वसनीयता बढ़ाने के लिए, हमने प्रत्येक कमांड के लिए कॉन्फ़िगरेशन को फ़ाइल में लिखने से इनकार कर दिया। संपूर्ण कॉन्फ़िगरेशन अब रैम में संग्रहीत किया जाता है और यदि आवश्यक हो, तो अलग-अलग कमांड द्वारा / mnt / डेटा / और / mnt / बैकअप / फ़ोल्डर में फ़ाइलों में सहेजा जा सकता है।

यदि काम के दौरान आपको डिवाइस को रीफ़्लैग किए बिना रूट फाइल सिस्टम में बदलाव करने की आवश्यकता है, तो आप कमांड के साथ पढ़ने और लिखने के लिए सिस्टम को कंसोल से हटा सकते हैं

 mount -o remount,rw / 

बदलाव करें और फिर पढ़ें केवल

 mount -o remount,ro /