समर्थन के साथ एकल-बोर्ड अपडेट के लिए लिनक्स असेम्बली बनाने का अनुभव करें

परिचय

फिलहाल, बाजार हर कीमत पर हर कीमत पर एक ही भुगतान करने वालों की एक विस्तृत श्रृंखला पेश करता है।

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

इंटरनेट पर, इस बारे में लगभग कोई जानकारी नहीं है कि रिलीज़ असेंबली क्या होनी चाहिए और इसके अपडेट को कैसे लागू किया जाए, इसलिए डेवलपर को "साइकिल" के साथ आने या अपने स्वयं के विकास का उपयोग करने के लिए मजबूर किया जाता है, जो हमेशा 100% परीक्षण नहीं होते हैं।

चूंकि मैं विभिन्न लिनक्स उपकरणों के लिए सॉफ्टवेयर के विकास में भाग लेता हूं (मेरा पोर्टफोलियो शब्द develinux द्वारा Google हो सकता है) और मैं 11-भागों की परियोजना का लेखक भी हूं, मुझे नियमित रूप से न केवल भवन विधानसभाओं के साथ सौदा करना है, बल्कि वेब या यूएसबी फ्लैश के माध्यम से विकासशील तंत्र के साथ भी है।

इस लेख में मैं प्रासंगिक क्षेत्रों में अपने अनुभव और ज्ञान को साझा करना चाहता हूं।

विधानसभा आवश्यकताओं

विभिन्न उपकरणों के लिए असेंबली और अपडेट विकसित करने की प्रक्रिया में, मैंने अपने लिए कई आवश्यकताओं की पहचान की:

• जब बिजली अचानक बंद हो जाए तो विधानसभा को नुकसान नहीं होना चाहिए;
• विधानसभा को जल्दी से लोड करना चाहिए;
• बूटलोडर को निर्दोष रूप से काम करना चाहिए;
• विधानसभा को अपडेट का समर्थन करना चाहिए।

मैं नीचे और अधिक विस्तार से इन आवश्यकताओं की व्याख्या करने की कोशिश करूंगा, और उसके बाद मैं छवियों के विभाजन में 3 दृष्टिकोणों को अनुभागों और उनके अपडेट में वर्णित करूंगा।

जब बिजली अचानक बंद हो जाए तो विधानसभा को नुकसान नहीं होना चाहिए।

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

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

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

लेकिन कॉन्फ़िगरेशन को बचाने, फ़ाइलों को डाउनलोड करने आदि के बारे में क्या। तुम पूछते हो
लेकिन इसके लिए आपको अलग RW विभाजन बनाने की आवश्यकता है। यदि आप नंद में लिखने की योजना बनाते हैं, तो मैं एक सिद्ध विकल्प की सिफारिश करता हूं - यूबीआईएफएस। यदि NOR में है, तो jffs2 यदि मैं किसी अन्य ड्राइव पर लिखता हूं, तो मैं ext4, btrfs, ReiserFS की सलाह देता हूं, क्योंकि मैं उनके लिए सबसे अच्छा FS इंगित नहीं कर सकता, क्योंकि सभी के साथ विभिन्न समस्याएं थीं।

इस मामले में, हमेशा आरडब्ल्यू विभाजन को बढ़ाने से पहले, fsck जैसी उपयोगिताओं की त्रुटियों के लिए विभाजन की जांच करना सुनिश्चित करें।

विधानसभा को जल्दी से लोड करना चाहिए

डिवाइस डाउनलोड की गति समग्र प्रयोज्य को प्रभावित करती है। कुछ कार्यों में, लोडिंग समय 30 सेकंड से अधिक नहीं है, कुछ में, 5 मिनट की अनुमति है। खुद के लिए, मैंने 1 मिनट तक का समय दिया, जितना कम बेहतर होगा। डाउनलोड के लिए एक मिनट से अधिक समय तक प्रतीक्षा करें, ऐसा लग सकता है कि डिवाइस लटका हुआ है, इसलिए यदि आप समय कम कर सकते हैं, तो इसका उपयोग करना बेहतर है।

बूटलोडर को सुचारू रूप से चलना चाहिए

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

बूटलोडर को एक सुरक्षित जगह पर, एक विश्वसनीय ड्राइव पर संग्रहीत किया जाना चाहिए, उदाहरण के लिए, एक अलग NOR या EEPROM चिप में। नीचे बूटलोडर को स्टोर करने के लिए SPI NOR के साथ, imx6ull चिप पर आधारित एक मॉड्यूल का एक उदाहरण है।

बिल्ड अपग्रेड का समर्थन करना चाहिए

एक अद्यतन के बिना, कहीं नहीं ... मैंने कई परियोजनाओं में भाग लिया और काम की डिलीवरी के लिए कभी भी सही सॉफ्टवेयर नहीं मिला। एक त्रुटि हमेशा पाई जाती है या एक कार्यात्मक सुधार की आवश्यकता होती है। आपको यह समझने की आवश्यकता है कि जब लोग सॉफ़्टवेयर लिखते हैं, तो वे गलतियाँ करेंगे, जबकि लोग डिवाइस का उपयोग करते हैं, वे थोड़ा और चाहते हैं। 90% मामलों में, एक सुविचारित अपडेट सिस्टम की कमी निर्माता के लिए सिरदर्द और पूरे प्रोजेक्ट के पतन का कारण बन सकती है। उदाहरण के लिए, परिवहन के लिए एक वीडियो निगरानी प्रणाली विकसित की गई है, सिस्टम पूरे रूस में स्थापित किया गया है, और यह पता चला है कि विपणक ने बाजार को कम करके आंका और स्ट्रीमिंग के लिए प्रदान नहीं किया, और इसके अलावा, फर्मवेयर में कई त्रुटियां पाई गईं, साथ ही उपभोक्ता प्रतियोगियों की दिशा में नज़र रखना शुरू कर देता है, क्योंकि उनके पास है बस कुछ ऐसा है जो खरीदे गए उपकरण में नहीं है ... हाँ, हाँ, एक अजीब बगीचे में स्ट्रॉबेरी स्वादिष्ट हैं और मौसम बेहतर है (मनोविज्ञान)।
ऐसी स्थिति में क्या करें? यदि अपडेट का समर्थन किया जाता है, तो बहुत सारे समाधान हैं, त्रुटियों को ठीक किया जा सकता है, स्ट्रीम प्रसारण में सुधार किया जा सकता है, और उपभोक्ता के लिए कार्यक्षमता को अनुकूलित किया जा सकता है, उपभोक्ता को निर्देशों के साथ फर्मवेयर दें और वह सब। लेकिन अगर यह समर्थित नहीं है, तो निर्माता के पास उपकरणों को बदलने के लिए सेवा इंजीनियरों की व्यावसायिक यात्राओं के साथ बड़ा रोमांच होगा।

डिवाइस में अपडेट सिस्टम को सबसे छोटा विवरण माना जाना चाहिए और 100% परीक्षण किया जाना चाहिए। इस हिस्से में एक गलती लोहे को ईंट में बदल देगी, इसलिए इसमें कोई सहिष्णुता और अपवाद नहीं होना चाहिए।

अद्यतन प्रक्रिया को बिजली बंद करने के लिए प्रतिरोधी होना चाहिए, और किसी भी परिस्थिति में यह डिवाइस को खराब नहीं करना चाहिए।

भविष्य के अपडेट के लिए विभाजन के दृष्टिकोण का अवलोकन

कई दृष्टिकोणों में से मैं 3 प्रकार की सिफारिश कर सकता हूं जिन्हें मैंने व्यक्तिगत रूप से लागू किया है। ये सभी दृष्टिकोण नहीं हैं, उनका दायरा इस लेख के दायरे से परे है। सभी 3 प्रकारों में दोष हैं और आदर्श से बहुत दूर हैं, लेकिन, जैसा कि मुझे लगता है, सामान्य ज्ञान के सुनहरे मतलब के करीब हैं।

दृष्टिकोण संख्या १

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

दृष्टिकोण संख्या २

सबसे विश्वसनीय और संरक्षित विधि माना जाता है, लेकिन सबसे कठिन। मैं इस विधि का उपयोग विशेष रूप से जिम्मेदार घटनाक्रम में, के रूप में करने की सलाह देता हूं यह टूटी हुई छवियों और शारीरिक क्षति से मुख्य ड्राइव दोनों को बचाता है, क्योंकि सर्किट एक अतिरिक्त का उपयोग करता है।

दृष्टिकोण न्यूनतम निर्माण (8-16MB का रैमडिस्क आकार) और मुख्य एक का उपयोग करता है। रामडिस्क एक संपीड़ित संग्रह है, इसलिए एक 16 एमबी का निर्माण शारीरिक रूप से कई गुना छोटा होगा।
न्यूनतम विधानसभा का लक्ष्य मुख्य विधानसभा का मूल्यांकन करना और उसे लोड करना है।
रामडिस्क को एफआईटी इमेज में कर्नेल और यू-बूट स्क्रिप्ट के साथ होस्ट किया गया है।

एफआईटी छवि क्यों और यह क्या देता है? एफआईटी छवि एक प्रारूप है जो यू-बूट द्वारा समर्थित है। यह सभी घटकों (कर्नेल, डीटीएस, रैमडिस्क, स्क्रिप्ट) की अखंडता सुनिश्चित करता है। FIT छवि को अनपैक करना u-boot में किया जाता है, और यदि चेकसम अभिसरण नहीं करता है, तो u-boot इसे लोड करने से मना कर देगा। यह सुविधाजनक है, अर्थात् अपने आप से अखंडता नियंत्रण की देखभाल करने की आवश्यकता नहीं है, अलग से कई फाइलें लिखने या अपनी खुद की छवियों का आविष्कार करने की आवश्यकता नहीं है, सब कुछ एफआईटी छवि द्वारा किया जाता है। आमतौर पर एक एफआईटी छवि 7-20 एमबी तक ले जाती है, इसे एक अलग उच्च विश्वसनीय ड्राइव पर लिखा जाना चाहिए, उदाहरण के लिए, क्यूपीआई में या फ्लैश नहीं। मुख्य असेंबली को सस्ती और अविश्वसनीय मेमोरी में संग्रहीत किया जा सकता है, उदाहरण के लिए, नंद फ्लैश। चूंकि मुख्य काम मुख्य विधानसभा में होगा, इसलिए यह ठीक है कि पहले क्षतिग्रस्त हो जाएगा। इस मामले में, न्यूनतम रूटफुट के साथ एक अलग ड्राइव बचाव में आएगा।

बूट प्रक्रिया।

यू-बूट एक स्क्रिप्ट डाउनलोड करता है जो एफआईटी अपडेट (एफआईटी 2) और फिर एफआईटी फैक्ट्री फर्मवेयर (एफआईटी 1) का उपयोग करने की कोशिश करता है।

यदि FIT2 मौजूद नहीं है या इसकी अखंडता का उल्लंघन किया जाता है, तो फिट परीक्षण विफल हो जाएगा और यू-बूट पहले FIT (FIT1) को लोड करेगा। यदि एफआईटी अपडेट (एफआईटी 2) हैं, और यह टूटा नहीं है, तो इसकी रैमडिस्क लोड की जाती है जो रूटफुट अपडेट (रूटफ 2) की जांच करती है।

यदि Rootfs2 टूट गया है, तो स्क्रिप्ट FIT अपडेट (FIT2) को हटा देगा, फिर रिबूट के बाद FIT (FIT1) और Rootfs1 से युक्त कारखाने की छवि डाउनलोड हो जाएगी।

अद्यतन प्रक्रिया।

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

चरणों में प्रगति का अद्यतन करें:

• हार्डवेयर और सॉफ्टवेयर के साथ संगतता के लिए छवि की जाँच करना,
• अद्यतन फ़ाइल में छवि की अखंडता की जाँच,
• अद्यतन फ़ाइल से रूटफ़्स 2 की प्रतिलिपि पहले से तैयार अनुभाग में,
• अनुभाग में प्रतिलिपि की गई छवि की अखंडता की जाँच करना,
• FIT2 को उपयुक्त अनुभाग में कॉपी करें,
• रीबूट।

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

अपडेट के बाद, नई असेंबली को FIT2 और Rootfs2 के रूप में मुख्य ड्राइव पर रखा जाएगा।

यह विधि ड्राइव और एफएस त्रुटियों के लिए यांत्रिक क्षति के लिए प्रतिरोधी है।

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

मैंने वसूली का सिर्फ एक उदाहरण दिया, कई विकल्प हैं। इस दृष्टिकोण में, पुनर्प्राप्ति प्रक्रिया पूर्ण-लिनक्स द्वारा संचालित होती है, जो सब कुछ कर सकती है ... और पहले संस्करण के रूप में बूटलोडर नहीं।

दृष्टिकोण संख्या ३

इस प्रकार के अद्यतन का उपयोग लगभग सभी 11-भागों की परियोजनाओं में किया जाता है, क्योंकि इसने बहुत अच्छा काम किया है।

अपडेट किसी भी प्रकार के ड्राइव के लिए, किसी भी असेंबली आकार के लिए उपयुक्त है। पिछले प्रकार के विपरीत, यहां SPI NOR का उपयोग केवल u-boot के लिए किया जाता है, इसलिए इसका आकार छोटा और कम होता है, 1 MB पर्याप्त होता है।

इस प्रकार के अद्यतन के लिए रैमडिस्क के अलग से निर्माण की आवश्यकता नहीं होती है, जिसका अर्थ है कि प्रोग्रामिंग समय को भविष्य में इसके विकास और समर्थन के लिए सहेजा जाता है।

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

डाउनलोड करने और अपडेट करने का तर्क पिछले दृष्टिकोण के समान है।

लोडिंग के मामले में, यू-बूट पहले FIT अपडेट (FIT2) डाउनलोड करता है, अगर यह नहीं होता है या अखंडता का उल्लंघन होता है, तो U-बूट पहले FIT (FIT1) को लोड करता है, कारखाने में सिले हुए विधानसभा शुरू होता है, और इसी तरह जब तक सिस्टम अपडेट नहीं होता है। जब सिस्टम अपडेट किया जाता है, तो FIT2 और Rootfs2 दिखाई देंगे। इस स्थिति में, जब डिवाइस बूट होता है, तो FIT अपडेट (FIT2) पहले शुरू होता है। यू-बूट स्क्रिप्ट में प्रत्येक एफआईटी में संग्रहीत किया जाता है, यह लिखा जाना चाहिए कि कौन से रूट को माउंट करना है।

साझा विभाजन RW

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

संक्षेप में देना

लेख में अपडेट के लिए समर्थन के साथ तीन प्रकार की असेंबली की चर्चा है, सभी मेरे द्वारा व्यक्तिगत रूप से जाँच की गई हैं, आप सुरक्षित रूप से परियोजनाओं में उनका उपयोग कर सकते हैं।

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

• RS485 पुनरावर्तक 4G / WiFi / LAN के माध्यम से,
• 4K वी-बाय-वन इंडस्ट्रियल डिस्प्ले कंट्रोलर कंट्रोल बोर्ड,
• एकीकृत हैंगर जलवायु नियंत्रण प्रणाली,
• 2DisplayPort-LVDS औद्योगिक प्रदर्शन वीडियो नियंत्रक,
• लाइन नियंत्रण प्रणाली
• वीपीएन गेटवे।

यदि मेरा लेख उपयोगी और दिलचस्प है, तो मैं इस साइट पर एम्बेडेड लिनक्स के क्षेत्र में अपने अनुभव और सिद्ध तकनीकी समाधानों को आगे साझा करने के लिए तैयार हूं।

आप सभी का धन्यवाद।
गोरचकोव इल्या
टेलीग्राम: डेवेलिनक्स