फर्मवेयर के रहस्यों के माध्यम से एक यात्रा: BIOS/UEFI से OS तक

क्या आपने कभी सोचा है कि जब आप अपने कंप्यूटर पर पावर बटन दबाते हैं तो क्या होता है? उस संक्षिप्त विराम के पीछे, आपकी स्क्रीन के जलने से पहले, प्रक्रियाओं की एक जटिल श्रृंखला चल रही होती है। यह लेख फर्मवेयर की आकर्षक दुनिया में गोता लगाएगा, यह पता लगाएगा कि बूट प्रक्रिया के दौरान विभिन्न घटक कैसे परस्पर क्रिया करते हैं ।

इन कनेक्शनों को समझने से, आपको उन मूलभूत तत्वों की स्पष्ट तस्वीर मिलेगी जो आपके सिस्टम को जीवंत बनाते हैं। हमारा प्राथमिक ध्यान इंटेल x86 आर्किटेक्चर पर होगा, लेकिन कई सिद्धांत अन्य आर्किटेक्चर पर भी लागू होते हैं।

अगर आपने हमारी सीरीज़ का पहला भाग नहीं देखा है, तो इसे पढ़ने के लिए यहाँ क्लिक करें । अब, आइए फ़र्मवेयर के पीछे के रहस्यों को उजागर करें।

विषयसूची:

• परिभाषाएं
• समग्र फर्मवेयर वास्तुकला
• प्रथम-चरण बूट लोडर (FSBL)
  • BIOS (पोस्ट चरण)
  • UEFI प्लेटफ़ॉर्म आरंभीकरण (PI)
  • कोरबूट
  • अन्य समाधान
• द्वितीय-चरण बूट लोडर (SSBL)
  • बायोस
  • यूईएफआई
• ओएस बूट लोडर

परिभाषाएं

• फर्मवेयर (Farmware ): हार्डवेयर में सन्निहित एक विशेष प्रकार का सॉफ्टवेयर, जो निम्न-स्तरीय नियंत्रण प्रदान करता है तथा हार्डवेयर को सही ढंग से कार्य करने तथा अन्य सिस्टम घटकों के साथ अंतःक्रिया करने में सक्षम बनाता है।

• बेसिक इनपुट/आउटपुट सिस्टम (BIOS) : एक लीगेसी फ़र्मवेयर (मूल रूप से IBM PC के लिए बनाया गया) जो प्लेटफ़ॉर्म पावर-ऑन के बाद हार्डवेयर इनिशियलाइज़ेशन के लिए ज़िम्मेदार है। आजकल, इसे अक्सर फ़र्मवेयर के पूरे सेट के रूप में संदर्भित किया जाता है।

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

• पेलोड : बूटलोडर के बाहर निकलने पर निष्पादित होने वाला सॉफ़्टवेयर। यह दूसरे चरण का बूटलोडर, ऑपरेटिंग सिस्टम, BIOS/UEFI एप्लीकेशन आदि हो सकता है। यह आमतौर पर फर्मवेयर डिज़ाइन के अनुसार बूटस्ट्रैपिंग प्रवाह का ध्यान रखता है।

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

• EFI बनाम UEFI : एक्सटेंसिबल फ़र्मवेयर इंटरफ़ेस (EFI) इंटेल द्वारा विकसित मूल विनिर्देश था । यूनिफाइड एक्सटेंसिबल फ़र्मवेयर इंटरफ़ेस (UEFI) EFI का उत्तराधिकारी है, जिसे UEFI फ़ोरम द्वारा मूल विनिर्देश को मानकीकृत और विस्तारित करने के लिए बनाया गया था। ज़्यादातर मामलों में, EFI और UEFI का परस्पर उपयोग किया जाता है।

समग्र फर्मवेयर वास्तुकला

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

फर्मवेयर या BIOS को आम तौर पर दो मुख्य भागों में विभाजित किया जा सकता है, जिनके बीच आमतौर पर न्यूनतम इंटरफ़ेस होता है:

1. हार्डवेयर आरंभीकरण : सिस्टम के हार्डवेयर घटकों को आरंभ करने के लिए जिम्मेदार।
2. ओएस और उपयोगकर्ता के लिए इंटरफ़ेस : ऑपरेटिंग सिस्टम और उपयोगकर्ता के लिए आवश्यक इंटरफेस प्रदान करता है।

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

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

अगर ये आरेख अब जटिल लग रहे हैं, तो चिंता न करें। इस लेख को पढ़ने के बाद इन्हें फिर से देखें, और वे स्पष्ट हो जाएँगे।

प्रथम-चरण बूट लोडर (FSBL)

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

एफएसबीएल की प्रमुख जिम्मेदारियां :

1. सीपीयू : 16-बिट रियल मोड से 32-बिट प्रोटेक्टेड मोड में स्विच करना ( नोट : या BIOS के मामले में वर्चुअल 8086 मोड में)।
2. कैश उपयोगिता : C वातावरण के लिए कैश-ऐज़-रैम को कॉन्फ़िगर करने के लिए FSP-T को कॉल करना।
3. डीबग पोर्ट : बोर्ड-विशिष्ट आरंभीकरण विधियों को कॉल करके कॉन्फ़िगर किए गए डीबग पोर्ट को आरंभ करना।
4. मेमोरी आरंभीकरण : सिस्टम की मुख्य मेमोरी को आरंभीकृत करने और महत्वपूर्ण सिस्टम मेमोरी जानकारी को सहेजने के लिए FSP-M को आमंत्रित करना।
5. GPIO : बाह्य उपकरणों के साथ इंटरफेस करने के लिए सामान्य-उद्देश्य इनपुट/आउटपुट (GPIO) पिन को कॉन्फ़िगर करना।
6. सिलिकॉन : प्रारंभिक प्लेटफ़ॉर्म आरंभीकरण करना और चिपसेट, सीपीयू, और आईओ नियंत्रक आरंभीकरण को पूरा करने के लिए FSP-S का उपयोग करना।
7. पीसीआई गणना : पीसीआई उपकरणों की गणना करना और मेमोरी एड्रेस और आईआरक्यू जैसे संसाधनों का आवंटन करना।
8. पेलोड तैयारी : पेलोड को पास करने के लिए आवश्यक तैयारी जानकारी (कोरबूट टेबल, एचओबी) सहित एसएमबीआईओएस और एसीपीआई टेबल की स्थापना।
9. लोडिंग और हैंडऑफ : लोडिंग और पेलोड पर नियंत्रण स्थानांतरित करना।

BIOS (पोस्ट चरण)

कंप्यूटिंग के शुरुआती दिनों में, ओपन-सोर्स सॉफ़्टवेयर व्यापक रूप से लोकप्रिय नहीं था, और अधिकांश BIOS कार्यान्वयन मालिकाना थे। BIOS POST स्रोत कोड प्रदान करने वाले केवल कुछ ही उपलब्ध ओपन समाधान हैं, जैसे सुपर पीसी/टर्बो XT BIOS और GLaBIOS । इन परियोजनाओं को IBM 5150/5155/5160 सिस्टम और अधिकांश XT क्लोन पर काम करने के लिए डिज़ाइन किया गया था।

हालाँकि, OpenBIOS और SeaBIOS जैसे अधिक प्रसिद्ध ओपन-सोर्स BIOS कार्यान्वयन हार्डवेयर आरंभीकरण नहीं करते हैं क्योंकि वे नंगे हार्डवेयर पर चलने के लिए अभिप्रेत नहीं हैं। लेकिन उन्हें व्यापक रूप से सेकंड-स्टेज बूटलोडर के रूप में उपयोग किया जाता है और वे QEMU और Bochs जैसे वर्चुअल वातावरण में मूल रूप से चलते हैं।

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

जहां तक वर्तमान विकास प्रवृत्तियों का प्रश्न है, ऐसा प्रतीत होता है कि स्वामित्व वाले BIOS समाधानों का कोई विकास नहीं हो रहा है, तथा आधुनिक विकल्पों के सामने ऐसी परियोजनाएं अप्रचलित हो गई हैं।

UEFI प्लेटफ़ॉर्म आरंभीकरण (PI)

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

• सुरक्षा (SEC) : रीसेट वेक्टर के बाद पहला चरण, इसका प्राथमिक कार्य अस्थायी RAM (सीपीयू कैश-ऐज़-रैम या SRAM) स्थापित करना है।
• प्री-ईएफआई इनिशियलाइज़ेशन (पीईआई) : यह चरण विशेष ड्राइवर भेजता है जिन्हें प्री-ईएफआई इनिशियलाइज़ेशन मॉड्यूल (पीईआईएम) कहा जाता है। ये मॉड्यूल आवश्यक हार्डवेयर इनिशियलाइज़ेशन को संभालते हैं, जैसे कि सीपीयू और चिपसेट को कॉन्फ़िगर करना और मुख्य मेमोरी (डीआरएएम) सेट करना।
• ड्राइवर निष्पादन वातावरण (DXE) : इस चरण में, सिस्टम आरंभीकरण का शेष कार्य किया जाता है। DXE चरण UEFI सेवाएँ प्रदान करता है और सिस्टम के संचालन के लिए आवश्यक विभिन्न प्रोटोकॉल और ड्राइवरों का समर्थन करता है।
• बूट डिवाइस चयन (बीडीएस) : यह चरण प्लेटफ़ॉर्म बूट नीति को कार्यान्वित करता है, बूट अनुक्रम निर्धारित करता है और उपयुक्त बूट डिवाइस/लोडर का चयन करता है।
• क्षणिक सिस्टम लोड (TSL) : इस चरण के दौरान, सिस्टम OS तैयार करने के लिए UEFI सेवाओं का उपयोग करके एप्लिकेशन चलाता है। इसमें UEFI वातावरण से ऑपरेटिंग सिस्टम में संक्रमण शामिल है, जो ExitBootServices() कॉल के साथ समाप्त होता है।
• रन टाइम (RT) : इस चरण में, ऑपरेटिंग सिस्टम पूरी तरह से क्रियाशील होता है, तथा अपने नियंत्रण में सिस्टम का प्रबंधन करता है।
• आफ्टर लाइफ (AL) : यह चरण उन परिदृश्यों से निपटता है जहां हार्डवेयर या OS क्रैश/शट डाउन/रीबूट होता है। फ़र्मवेयर पुनर्प्राप्ति क्रियाओं का प्रयास कर सकता है, हालाँकि, UEFI PI विनिर्देश इस चरण के लिए विशिष्ट आवश्यकताओं या व्यवहारों को परिभाषित नहीं करता है।

यह प्रक्रिया और इसके निष्पादन चरण UEFI प्लेटफ़ॉर्म इनिशियलाइज़ेशन (PI) विनिर्देश द्वारा कवर किए गए हैं। हालाँकि, UEFI इंटरफ़ेस (चित्र में बोल्ड ब्लू लाइन द्वारा दर्शाया गया) भी है, जो पिछले दस्तावेज़ का हिस्सा नहीं है और UEFI विनिर्देश में वर्णित है। हालाँकि UEFI के नाम और लगातार उपयोग भ्रामक हो सकते हैं, इन दोनों दस्तावेज़ों के अलग-अलग फ़ोकस हैं:

• UEFI PI स्पेक : निम्न-स्तरीय फर्मवेयर घटकों के बीच इंटरफेस पर ध्यान केंद्रित करता है और विस्तार से बताता है कि ये मॉड्यूल प्लेटफॉर्म को आरंभ करने के लिए कैसे इंटरैक्ट करते हैं।

• UEFI विनिर्देश : ऑपरेटिंग सिस्टम (OS) और फ़र्मवेयर के बीच बातचीत के लिए इंटरफ़ेस को परिभाषित करता है। इस पर आगे सेकंड-स्टेज बूटलोडर के संदर्भ में चर्चा की जाएगी। ध्यान दें कि UEFI विनिर्देश PI विनिर्देश पर निर्भर करता है।

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

UEFI PI को शुरू में एकीकृत फ़र्मवेयर समाधान के रूप में डिज़ाइन किया गया था, जिसमें पहले चरण और दूसरे चरण के बूटलोडर के बीच अंतर पर विचार नहीं किया गया था। हालाँकि, जब हम UEFI को पहले चरण के बूटलोडर के रूप में संदर्भित करते हैं, तो इसमें SEC , PEI और शुरुआती DXE चरण शामिल होते हैं। हम DXE को शुरुआती और बाद के चरणों में विभाजित करते हैं, इसका कारण आरंभीकरण प्रक्रिया में उनकी अलग-अलग भूमिकाएँ हैं।

प्रारंभिक DXE चरण में, ड्राइवर आम तौर पर आवश्यक CPU/PCH/बोर्ड आरंभीकरण करते हैं और DXE आर्किटेक्चरल प्रोटोकॉल (APs) भी बनाते हैं, जो DXE चरण को प्लेटफ़ॉर्म-विशिष्ट हार्डवेयर से अलग करने में मदद करते हैं। APs प्लेटफ़ॉर्म के लिए विशिष्ट विवरणों को समाहित करते हैं, जिससे बाद के DXE चरण को हार्डवेयर विशिष्टताओं से स्वतंत्र रूप से संचालित करने की अनुमति मिलती है।

कोरबूट

कोरबूट कैसे काम करता है, इस पर विस्तृत लेख जल्द ही आने वाले हैं। मेरे सोशल मीडिया को फॉलो करें - वे बहुत जल्द प्रकाशित होंगे!

अन्य समाधान

• इंटेल स्लिम बूटलोडर (SBL) : शुद्ध प्रथम-चरण बूटलोडर जो केवल कोर हार्डवेयर घटकों को आरंभीकृत करता है, उसके बाद पेलोड लोड करता है। हालाँकि, यह केवल इंटेल x86 प्लेटफ़ॉर्म पर काम करता है और AMD x86 या अन्य आर्किटेक्चर का समर्थन नहीं करता है।
• दास यू-बूट : प्रथम-चरण और द्वितीय-चरण बूटलोडर दोनों। हालाँकि, प्लेटफ़ॉर्म के x86 रीसेट वेक्टर (जिसे बेयर मोड के रूप में जाना जाता है) से सीधे बूट करने के लिए समर्थन अन्य फ़र्मवेयर की तुलना में सीमित है। यह एम्बेडेड सिस्टम और ARM-आधारित डिवाइस पर अधिक लोकप्रिय है। दूसरे चरण के बूटलोडर के रूप में, यू-बूट UEFI के एक उपसमूह को लागू करता है लेकिन एम्बेडेड सिस्टम पर ध्यान केंद्रित करता है।

द्वितीय-चरण बूट लोडर (SSBL)

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

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

एसएसबीएल की प्रमुख जिम्मेदारियां :

1. प्लेटफ़ॉर्म सूचना पुनर्प्राप्ति : प्रथम-चरण बूटलोडर से प्लेटफ़ॉर्म-विशिष्ट जानकारी प्राप्त करता है, जिसमें मेमोरी मैपिंग, SMBIOS, ACPI तालिकाएँ, SPI फ़्लैश आदि शामिल हैं।

   
   

2. प्लेटफ़ॉर्म स्वतंत्र ड्राइवर चलाएं : इसमें SMM, SPI, PCI, SCSI/ATA/IDE/DISK, USB, ACPI, नेटवर्क इंटरफेस आदि के लिए ड्राइवर शामिल हैं।

   
   

3. सेवा कार्यान्वयन (जिसे इंटरफ़ेस भी कहा जाता है) : सेवाओं का एक सेट प्रदान करता है जो ऑपरेटिंग सिस्टम और हार्डवेयर घटकों के बीच संचार को सुविधाजनक बनाता है।

   
   

4. सेटअप मेनू : सिस्टम कॉन्फ़िगरेशन के लिए एक सेटअप मेनू प्रदान करता है, जिससे उपयोगकर्ता बूट ऑर्डर, हार्डवेयर प्राथमिकताएं और अन्य सिस्टम मापदंडों से संबंधित सेटिंग्स समायोजित कर सकते हैं।

   
   

5. बूट लॉजिक : उपलब्ध बूट मीडिया से पेलोड (संभवतः ऑपरेटिंग सिस्टम) का पता लगाने और लोड करने की प्रणाली।

बायोस

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

16-बिट रियल मोड में, उन्हें INT x86 असेंबली भाषा निर्देश के माध्यम से सॉफ़्टवेयर इंटरप्ट को लागू करके आसानी से एक्सेस किया जा सकता है। 32-बिट प्रोटेक्टेड मोड में, सेगमेंट मानों को संभालने के अलग-अलग तरीके के कारण लगभग सभी BIOS सेवाएँ अनुपलब्ध हैं।

आइए उदाहरण के लिए डिस्क सर्विसेज ( INT 13h ) लें, जो सिलेंडर-हेड-सेक्टर (CHS) एड्रेसिंग का उपयोग करके सेक्टर-आधारित हार्ड डिस्क और फ्लॉपी डिस्क रीड और राइट सेवाएं प्रदान करता है, इस इंटरफ़ेस का उपयोग कैसे किया जा सकता है, इसका एक उदाहरण है। मान लें कि हम 2 सेक्टर (1024 बाइट्स) पढ़ना चाहते हैं और उन्हें मेमोरी एड्रेस 0x9020 पर लोड करना चाहते हैं, तो निम्न कोड निष्पादित किया जा सकता है:

 mov $0x02, %ah # Set BIOS read sector routine mov $0x00, %ch # Select cylinder 0 mov $0x00, %dh # Select head 0 [has a base of 0] mov $0x02, %cl # Select sector 2 (next after the # boot sector) [has a base of 1] mov $0x02, %al # Read 2 sectors mov $0x00, %bx # Set BX general register to 0 mov %bx, %es # Set ES segment register to 0 mov $0x9020, %bx # Load sectors to ES:BX (0:0x9020) int $0x13 # Start reading from drive jmp $0x9020 # Jump to loaded code

यदि आप इस बात में रुचि रखते हैं कि यह सेवा SeaBios में कैसे लिखी गई है, तो src/disk.c पर एक नज़र डालें।

बूट चरण

• डिवाइस से प्रथम 512-बाइट सेक्टर (सेक्टर शून्य) को पढ़कर बूट करने योग्य डिवाइस (यह हार्ड ड्राइव, सीडी-रोम, फ्लॉपी डिस्क आदि हो सकता है) की खोज प्रारंभ करता है।

  
  

• BIOS में बूटस्ट्रैप अनुक्रम, कंप्यूटर की भौतिक मेमोरी में भौतिक पते 0x7C00 पर पाए जाने वाले पहले वैध मास्टर बूट रिकॉर्ड (MBR) को लोड करता है (संकेत: 0x0000:0x7c00 और 0x7c0:0x0000 एक ही भौतिक पते को संदर्भित करते हैं)।

  
  

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

यह ध्यान देने योग्य है कि शुरुआती दिनों में BIOS विनिर्देश मौजूद नहीं थे। BIOS एक वास्तविक मानक है - यह उसी तरह काम करता है जैसे 1980 के दशक में वास्तविक IBM PC पर काम करता था। बाकी निर्माताओं ने बस रिवर्स-इंजीनियरिंग की और IBM-संगत BIOS बनाए। नतीजतन, BIOS निर्माताओं को नए BIOS फ़ंक्शन का आविष्कार करने या ओवरलैपिंग कार्यक्षमता रखने से रोकने के लिए कोई विनियमन नहीं था।

एकीकृत एक्सटेंसिबल फ़र्मवेयर इंटरफ़ेस (UEFI)

जैसा कि पहले बताया गया है, UEFI अपने आप में सिर्फ़ एक विनिर्देश है और इसके कई कार्यान्वयन हैं। सबसे ज़्यादा इस्तेमाल किया जाने वाला TianoCore EDK II है, जो UEFI और PI विनिर्देशों का एक ओपन-सोर्स संदर्भ कार्यान्वयन है । हालाँकि EDKII अकेले पूरी तरह से कार्यात्मक बूट फ़र्मवेयर बनाने के लिए पर्याप्त नहीं है, लेकिन यह अधिकांश व्यावसायिक समाधानों के लिए एक ठोस आधार प्रदान करता है।

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

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

यूईएफआई पेलोड के प्रकार :

1. लीगेसी UEFI पेलोड : आवश्यक कार्यान्वयन-विशिष्ट प्लेटफ़ॉर्म जानकारी निकालने के लिए पार्स लाइब्रेरी की आवश्यकता होती है। यदि बूटलोडर अपने API को अपडेट करता है, तो पेलोड को भी अपडेट किया जाना चाहिए।

   
   

   

   
   

2. यूनिवर्सल UEFI पेलोड : यूनिवर्सल स्केलेबल फ़र्मवेयर (USF) स्पेसिफिकेशन का पालन करता है, एक सामान्य इमेज फ़ॉर्मेट के रूप में एक्ज़ीक्यूटेबल और लिंकेबल फ़ॉर्मेट (ELF) या फ़्लैट इमेज ट्री (FIT) का उपयोग करता है। उन्हें खुद पार्स करने के बजाय, यह पेलोड एंट्री पर हैंड ऑफ़ ब्लॉक (HOB) प्राप्त करने की अपेक्षा करता है।

जबकि लीगेसी UEFI पेलोड ठीक काम करता है, EDK2 समुदाय उद्योग को यूनिवर्सल UEFI पेलोड की ओर स्थानांतरित करने की कोशिश कर रहा है। पेलोड के बीच का चुनाव आपके फर्मवेयर घटकों पर निर्भर करता है। उदाहरण के लिए, मेरे पैच के बिना स्लिम बूटलोडर पर SMM समर्थन के साथ लीगेसी पेलोड को चलाना संभव नहीं है। दूसरी ओर, कोरबूट के साथ यूनिवर्सल पेलोड का उपयोग करने के लिए कोरबूट तालिकाओं को HOBs में अनुवाद करने के लिए एक शिम परत की आवश्यकता होती है, एक सुविधा जो केवल StarLabs EDK2 फोर्क में उपलब्ध है।

इंटरफ़ेस

प्रत्येक UEFI-अनुरूप सिस्टम एक सिस्टम टेबल प्रदान करता है जिसे UEFI वातावरण (ड्राइवर, एप्लिकेशन, OS लोडर) में चलने वाले प्रत्येक कोड को पास किया जाता है। यह डेटा संरचना UEFI निष्पादन योग्य को ACPI , SMBIOS और UEFI सेवाओं के संग्रह जैसे सिस्टम कॉन्फ़िगरेशन टेबल तक पहुँचने की अनुमति देती है।

तालिका संरचना MdePkg/Include/Uefi/UefiSpec.h में वर्णित है:

 typedef struct { EFI_TABLE_HEADER Hdr; CHAR16 *FirmwareVendor; UINT32 FirmwareRevision; EFI_HANDLE ConsoleInHandle; EFI_SIMPLE_TEXT_INPUT_PROTOCOL *ConIn; EFI_HANDLE ConsoleOutHandle; EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL *ConOut; EFI_HANDLE StandardErrorHandle; EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL *StdErr; // // A pointer to the EFI Runtime Services Table. // EFI_RUNTIME_SERVICES *RuntimeServices; // // A pointer to the EFI Boot Services Table. // EFI_BOOT_SERVICES *BootServices; UINTN NumberOfTableEntries; EFI_CONFIGURATION_TABLE *ConfigurationTable; } EFI_SYSTEM_TABLE;

सेवाओं में निम्नलिखित प्रकार शामिल हैं: बूट सेवाएँ , रनटाइम सेवाएँ और प्रोटोकॉल द्वारा प्रदान की गई सेवाएँ ।

UEFI , UEFI प्रोटोकॉल सेट करके डिवाइस तक पहुँच को सारगर्भित करता है। ये प्रोटोकॉल डेटा संरचनाएँ हैं जिनमें फ़ंक्शन पॉइंटर्स होते हैं और इन्हें ग्लोबली यूनिक आइडेंटिफ़ायर (GUID) द्वारा पहचाना जाता है जो अन्य मॉड्यूल को उन्हें ढूँढ़ने और उपयोग करने की अनुमति देता है। उन्हें बूट सेवाओं के माध्यम से खोजा जा सकता है।

UEFI ड्राइवर इन प्रोटोकॉल का निर्माण करता है, और वास्तविक फ़ंक्शन (पॉइंटर्स नहीं!) ड्राइवर के भीतर ही समाहित होते हैं। यह तंत्र UEFI वातावरण के भीतर विभिन्न घटकों को एक दूसरे के साथ संवाद करने की अनुमति देता है और यह सुनिश्चित करता है कि OS अपने स्वयं के ड्राइवर लोड करने से पहले डिवाइस के साथ बातचीत कर सके।

जबकि कुछ प्रोटोकॉल UEFI विनिर्देश में पूर्वनिर्धारित और वर्णित होते हैं, फर्मवेयर विक्रेता किसी प्लेटफॉर्म की कार्यक्षमता का विस्तार करने के लिए अपने स्वयं के कस्टम प्रोटोकॉल भी बना सकते हैं।

बूट सेवाएँ

ऐसे फ़ंक्शन प्रदान करें जिनका उपयोग केवल बूट समय के दौरान किया जा सकता है। ये सेवाएँ तब तक उपलब्ध रहती हैं जब तक EFI_BOOT_SERVICES.ExitBootServices() फ़ंक्शन को कॉल नहीं किया जाता ( MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c )।

सभी बूट सेवाओं के संकेत बूट सेवा तालिका ( MdePkg/Include/Uefi/UefiSpec.h ) में संग्रहीत हैं:

 typedef struct { EFI_TABLE_HEADER Hdr; ... EFI_GET_MEMORY_MAP GetMemoryMap; EFI_ALLOCATE_POOL AllocatePool; EFI_FREE_POOL FreePool; ... EFI_HANDLE_PROTOCOL HandleProtocol; ... EFI_EXIT_BOOT_SERVICES ExitBootServices; ... } EFI_BOOT_SERVICES;

रनटाइम सेवाएँ

ऑपरेटिंग सिस्टम के चलने के दौरान सेवाओं का एक न्यूनतम सेट अभी भी सुलभ है। बूट सेवाओं के विपरीत, ये सेवाएँ तब भी मान्य होती हैं जब कोई पेलोड (उदाहरण के लिए, OS बूटलोडर) EFI_BOOT_SERVICES.ExitBootServices() को कॉल करके प्लेटफ़ॉर्म पर नियंत्रण कर लेता है।

सभी रनटाइम सेवाओं के पॉइंटर्स रनटाइम सेवा तालिका ( MdePkg/Include/Uefi/UefiSpec.h ) में संग्रहीत किए जाते हैं:

 typedef struct { EFI_TABLE_HEADER Hdr; ... EFI_GET_TIME GetTime; EFI_SET_TIME SetTime; ... EFI_GET_VARIABLE GetVariable; EFI_GET_NEXT_VARIABLE_NAME GetNextVariableName; EFI_SET_VARIABLE SetVariable; ... EFI_GET_NEXT_HIGH_MONO_COUNT GetNextHighMonotonicCount; EFI_RESET_SYSTEM ResetSystem; ... } EFI_RUNTIME_SERVICES;

नीचे दिया गया चित्र बूट और रनटाइम सेवाओं के लिए समयरेखा दिखाता है, ताकि आप देख सकें कि प्रत्येक कब सक्रिय है।

बूट डिवाइस चयन (BDS) चरण

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

• Boot#### ( #### एक अद्वितीय हेक्स मान द्वारा प्रतिस्थापित किया जाता है) - एक बूट/लोड विकल्प।
• BootCurrent — वर्तमान में चल रहे सिस्टम को शुरू करने के लिए प्रयुक्त बूट विकल्प।
• BootNext — सिर्फ़ अगले बूट के लिए बूट विकल्प। यह सिर्फ़ एक बूट के लिए BootOrder प्रतिस्थापित करता है और पहले इस्तेमाल के बाद बूट मैनेजर द्वारा हटा दिया जाता है। यह आपको BootOrder बदले बिना अगले बूट व्यवहार को बदलने की अनुमति देता है।
• BootOrder — ऑर्डर की गई बूट विकल्प लोड सूची। बूट प्रबंधक इस सूची में पहले सक्रिय विकल्प को बूट करने का प्रयास करता है। असफल होने पर, यह अगला विकल्प आज़माता है, और इसी तरह आगे भी।
• BootOptionSupport — बूट प्रबंधक द्वारा समर्थित बूट विकल्पों के प्रकार।
• Timeout - फर्मवेयर का बूट मैनेजर, BootNext या BootOrder से स्टार्टअप मान को स्वचालित रूप से चुनने से पहले, सेकंड में टाइमआउट कर देता है।

इन चरों को efibootmgr(8) का उपयोग करके लिनक्स से आसानी से प्राप्त किया जा सकता है:

 [root@localhost ~]# efibootmgr BootCurrent: 0000 Timeout: 5 seconds BootOrder: 0000,0001,2001,2002,2003 Boot0000* ARCHLINUX HD(5,GPT,d03ca3cf-1511-d94e-8400-c7a125866442,0x40164000,0x100000)/File(\EFI\ARCHLINUX\grubx64.efi) Boot0001* Windows Boot Manager HD(1,GPT,6f185443-09fc-4f15-afdf-01c523565e52,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)57a94e544f5753000100000088900100780000004200430044039f0a42004a004500430054003d007b00390064006500610038003600320063002d1139006300640064002d0034006500370030102d0061006300630031002d006600330032006200330034003400640034003700390035007d00000033000300000710000000040000007fff0400 Boot0002* ARCHLINUX HD(5,GPT,d03ca3cf-1511-d94e-8400-c7a125866442,0x40164000,0x100000) Boot2001* EFI USB Device RC Boot2002* EFI DVD/CDROM RC Boot2003* EFI Network RC

आइए ऊपर दिए गए कोड स्निपेट पर भरोसा करके बूटिंग पर एक नज़र डालें। UEFI BootOrder सूची को दोहराना शुरू कर देगा। सूची में प्रत्येक प्रविष्टि के लिए, यह एक संगत Boot#### चर की तलाश करता है - 0000 के लिए Boot0000 , 2003 के लिए Boot2003 2003, और इसी तरह। यदि चर मौजूद नहीं है, तो यह अगली प्रविष्टि पर जारी रहता है। यदि चर मौजूद है, तो यह चर की सामग्री को पढ़ता है। प्रत्येक बूट विकल्प चर में एक EFI_LOAD_OPTION वर्णनकर्ता होता है जो चर लंबाई वाले फ़ील्ड का बाइट-पैक बफर होता है (यह केवल डेटा संरचना है)।

डेटा संरचना का वर्णन [MdePkg/Include/Uefi/UefiSpec.h][ https://github.com/tianocore/edk2/blob/edk2-stable202405/MdePkg/Include/Uefi/UefiSpec.h#L2122 ) में किया गया है

 typedef struct _EFI_LOAD_OPTION { /// The attributes for this load option entry. UINT32 Attributes; /// Length in bytes of the FilePathList. UINT16 FilePathListLength; /// The user readable description for the load option. /// Example: 'ARCHLINUX' / 'Windows Boot Manager' / `EFI USB Device` // CHAR16 Description[]; /// A packed array of UEFI device paths. /// Example: 'HD(5,GPT,d03ca3cf-1511-d94e-8400-c7a125866442,0x40164000,0x100000)/File(\EFI\ARCHLINUX\grubx64.efi)' // EFI_DEVICE_PATH_PROTOCOL FilePathList[]; /// The remaining bytes in the load option descriptor are a binary data buffer that is passed to the loaded image. /// Example: '57a9...0400' in Boot0001 variable // UINT8 OptionalData[]; } EFI_LOAD_OPTION;

इस बिंदु पर, फर्मवेयर डिवाइस पथ ( EFI_DEVICE_PATH_PROTOCOL ) की जांच करेगा। ज़्यादातर मामलों में, हमारा कंप्यूटर स्टोरेज डिवाइस (हार्ड ड्राइव/SSD/NVMe/आदि) से बूट होता है। इसलिए, डिवाइस पथ में HD(Partition Number, Type, Signature, Start sector, Size in sectors) नोड शामिल होगा।

• प्रकार - कीवर्ड MBR (1) या GPT (2) के साथ विभाजन योजना के लिए उपयोग किए जाने वाले प्रारूप को इंगित करता है।
• हस्ताक्षर - यदि प्रकार MBR है तो 4-बाइट MBR हस्ताक्षर, या यदि प्रकार GPT है तो 16-बाइट UUID हस्ताक्षर।

नोट : यदि आप अन्य पथों का अनुवाद करने में रुचि रखते हैं, तो UEFI विनिर्देश v2.10, 10.6.1.6 टेक्स्ट डिवाइस नोड संदर्भ पढ़ें।

UEFI डिस्क को देखेगा और देखेगा कि क्या इसमें नोड से मेल खाने वाला कोई विभाजन है। यदि यह मौजूद है, तो इसे एक विशिष्ट ग्लोबली यूनिक आइडेंटिफायर (GUID) के साथ लेबल किया जाना चाहिए जो इसे EFI सिस्टम पार्टिशन (ESP) के रूप में चिह्नित करता है। यह एक फ़ाइल सिस्टम के साथ स्वरूपित है जिसका विनिर्देश FAT फ़ाइल सिस्टम के विशिष्ट संस्करण पर आधारित है और इसका नाम EFI फ़ाइल सिस्टम है; वास्तव में, यह एक नियमित FAT12/16/32 है।

• नेटिव बूट : यदि डिवाइस पथ में File(\Path\To\The\File.efi) के लिए एक स्पष्ट पथ है, तो UEFI उस विशिष्ट फ़ाइल की तलाश करेगा। उदाहरण के लिए, Boot0000 विकल्प में File(\EFI\ARCHLINUX\grubx64.efi) शामिल है।
• फ़ॉलबैक बूट : यदि डिवाइस पथ केवल डिस्क की ओर इंगित करता है, तो ऐसी स्थितियों में, फ़र्मवेयर फ़ॉलबैक बूट पथ का उपयोग करेगा जो आर्किटेक्चर पर आधारित है - \EFI\BOOT\BOOT{arch}.EFI ( amd64 के लिए BOOTx64.EFI या i386 / IA32 के लिए BOOTia32.EFI )। यह तंत्र बूट करने योग्य हटाने योग्य मीडिया (उदाहरण के लिए, एक यूएसबी ड्राइव) को UEFI में काम करने की अनुमति देता है; वे बस फ़ॉलबैक बूट पथ का उपयोग करते हैं। उदाहरण के लिए, Boot0002 विकल्प इस तंत्र का उपयोग करेगा।

नोट: ऊपर उल्लिखित सभी Boot#### विकल्प efibootmgr के उदाहरण आउटपुट में प्रदर्शित बूट विकल्पों को संदर्भित करते हैं।

दोनों मामलों में, UEFI बूट मैनेजर UEFI एप्लीकेशन (यह OS बूटलोडर , UEFI शेल, यूटिलिटी सॉफ्टवेयर, सिस्टम सेटअप और जो भी हो सकता है) को मेमोरी में लोड करेगा। इस समय, नियंत्रण UEFI एप्लीकेशन के एंट्री पॉइंट पर स्थानांतरित हो जाता है। BIOS के विपरीत, UEFI एप्लीकेशन फर्मवेयर को नियंत्रण वापस कर सकता है (स्थिति के अलावा, जब एप्लीकेशन सिस्टम का नियंत्रण अपने हाथ में ले लेता है)। यदि ऐसा होता है या कुछ भी गलत होता है, तो बूट मैनेजर अगली Boot#### प्रविष्टि पर चला जाता है, और बिल्कुल उसी प्रक्रिया का पालन करता है।

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

उपरोक्त पाठ UEFI बूटिंग का वर्णन करता है। इसके अलावा, UEFI फर्मवेयर संगतता समर्थन मॉड्यूल (CSM) मोड में चल सकता है जो BIOS का अनुकरण करता है।

ओएस बूट लोडर

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

• विभिन्न फ़ाइल सिस्टम (HFS+, ext4, XFS, आदि) से पढ़ना
• नेटवर्क पर इंटरैक्ट करना (जैसे, TFTP, HTTP)
• मल्टीबूट -संगत कर्नेल बूट करना
• चेनलोडिंग
• प्रारंभिक रैमडिस्क लोड हो रहा है ( initrd )
• और अधिक!

इन प्रोग्रामों के सामान्य डिज़ाइन इस लेख के दायरे से बाहर हैं। लोकप्रिय OS बूटलोडर्स की विस्तृत तुलना के लिए, आप ArchLinux wiki और Wikipedia लेख देख सकते हैं।

विंडोज सिस्टम अपने स्वामित्व वाले ओएस बूटलोडर का उपयोग करता है जिसे विंडोज बूट मैनेजर (BOOTMGR) के रूप में जाना जाता है।

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

समग्र वास्तुकला को समझना आपके दिमाग में इन घटकों को व्यवस्थित करने में मदद करता है। मौजूदा फर्मवेयर के डिजाइन की जांच करके, आप उस आकर्षक प्रक्रिया के बारे में जानकारी प्राप्त करते हैं जो हर बार कंप्यूटर चालू होने पर सामने आती है। यह ऊपर से नीचे का दृष्टिकोण न केवल प्रत्येक भाग की भूमिका को स्पष्ट करता है बल्कि आधुनिक फर्मवेयर सिस्टम की परिष्कृत और विकसित प्रकृति को भी उजागर करता है।

संसाधन

• UEFI विनिर्देशन संस्करण 2.10
• UEFI प्लेटफ़ॉर्म आरंभीकरण विनिर्देशन संस्करण 1.8 (त्रुटि A)
• EDK II दस्तावेज़ीकरण
• स्लिम बूटलोडर परियोजना दस्तावेज़ीकरण
• UEFI बूट: तो फिर यह वास्तव में कैसे काम करता है?
• आधुनिक UEFI-आधारित प्लेटफ़ॉर्म बूट को समझना
• इंटेल गैलीलियो पर UEFI बूट अनुक्रम की संरचना
• कुछ सामान्य आर्किटेक्चर में डिस्क डिवाइस "पथ" पर बहुत सरल नोट।
• कंप्यूटर कैसे बूट होता है?