उदाहरण के रूप में लिंक्स कंट्रोलर के GPIO का उपयोग करके _HID ACPI विधि द्वारा ड्राइवर और डिवाइस के बीच संचार

समस्या का बयान

लिनक्स में GPIO के साथ sysfs के माध्यम से काम करने के लिए एक मानक इंटरफ़ेस है। इसके लिए प्रलेखन यहां पाया जा सकता है ।

संक्षेप में, "/ sys / class / gpio" फ़ोल्डर में "निर्यात" और "अनएक्सपोर्ट" फाइलें हैं। निर्यात फ़ाइल में संख्या X लिखकर, आप GPIOX को नियंत्रित करने के लिए उपयोगकर्ता स्थान में इंटरफ़ेस खोल सकते हैं

#    user space   GPIO12 $ echo 12 > /sys/class/gpio/export 

इंटरफ़ेस खोलने के बाद, फ़ोल्डर / sys / class / gpio / gpioX / दिखाई देगा जिसमें "मान" या "दिशा" के रूप में ऐसी फाइलें होंगी, और "दिशा" फ़ाइल में "इन" या "आउट" लिखकर और फ़ाइल में 1 या 0 लिखेंगे। "मान" कमांड लाइन से सीधे GPIO आउटपुट को नियंत्रित कर सकता है।

 #  GPIO   $ echo "out" > /sys/class/gpio/gpio12/direction #  1   GPIO $ echo 1 > /sys/class/gpio/gpio12/value 

"GpioX" फ़ोल्डर बनाने के लिए "इको X> / sys / क्लास / gpio / एक्सपोर्ट" कमांड के लिए, GPIO कंट्रोलर ड्राइवर को कर्नेल में पंजीकृत होना चाहिए, जो इंटरफ़ेस को GPIO लाइनों में खोलता है।

ऐसा हुआ कि मैं इंटेल हसवेल i7 प्रोसेसर पर आधारित एक कस्टम बोर्ड के लिए कोरबूट को पोर्ट करने पर काम कर रहा हूं [जो लोग नहीं जानते हैं, उनके लिए कोरबूट एक ओपन सोर्स BIOS प्रोजेक्ट ओपन सोर्स ( https://www.coreboot.org/ ) है। ]। LynxpointLP दक्षिण पुल जिसमें 94 GPIO लाइनें हैं, मेरे प्रोसेसर में बनाया गया है। और मैं उन्हें sysfs में खोलना चाहता था ...

समस्या को हल करना (लिनक्स में ड्राइवर और डिवाइस संचार)

कर्नेल कोड पर एक छोटी खोज के बाद, मैंने पाया कि यह ड्राइवर पहले ही लिखा जा चुका है, "ड्राइवर \ gpio \ gpio-lynxpoint.c" फ़ाइल में स्थित है और Kconfig का उपयोग करने में सक्षम है

 config GPIO_LYNXPOINT tristate "Intel Lynxpoint GPIO support" depends on ACPI && X86 select GPIOLIB_IRQCHIP help driver for GPIO functionality on Intel Lynxpoint PCH chipset Requires ACPI device enumeration code to set up a platform device. 

GPIO_LYNXPOINT विकल्प उस कर्नेल में सक्षम किया गया था जिसके साथ मैं काम कर रहा था, हालाँकि, GPIO नियंत्रक के लिए "/ sys / class / gpio /" फ़ोल्डर (जो होना चाहिए) में एक भी "gpiochipN" फ़ोल्डर नहीं था, और इस तरह की स्क्रिप्ट से भी किसी के निर्यात का नेतृत्व नहीं हुआ। लाइन।

 $ for i in {0..255}; do echo $i > /sys/class/gpio/export; done 

कोरबूट कोड को देखते हुए या इस दक्षिण पुल के लिए दस्तावेज़ीकरण को देखते हुए, आप देख सकते हैं कि GPIO नियंत्रक एक अलग PCI डिवाइस नहीं है। यह एक अन्य PCI डिवाइस का हिस्सा है: LPC इंटरफ़ेस ब्रिज। इस डिवाइस के PCI कॉन्फ़िगरेशन स्पेस रजिस्टर का उपयोग करते हुए, आपको GPIO कंट्रोलर को सक्षम करना होगा और I / O स्पेस में BASE_ADDRESS को असाइन करना होगा। यह 1KV I / O स्पेस में एक विंडो खोलेगा। इस विंडो में बाइट्स लिखने / पढ़ने से आप GPIO लाइनों को नियंत्रित कर सकते हैं।

हम कोरबोट कोड में क्या देख सकते हैं:

Southbridge \ Intel \ lynxpoint \ pch.h:

 #define DEFAULT_GPIOBASE 0x1400 #define DEFAULT_GPIOSIZE 0x400 ... #define GPIO_BASE 0x48 /* LPC GPIO Base Address Register */ #define GPIO_CNTL 0x4C /* LPC GPIO Control Register */ ... /* PCI Configuration Space (D31:F0): LPC */ #define PCH_LPC_DEV PCI_DEV(0, 0x1f, 0) 

Southbridge \ Intel \ lynxpoint \ initial_pch.c:

 /* Setup GPIO Base Address */ pci_write_config32(PCH_LPC_DEV, GPIO_BASE, DEFAULT_GPIOBASE|1); /* Enable GPIO functionality. */ pci_write_config8(PCH_LPC_DEV, GPIO_CNTL, 0x10); 

यदि हम "lspci -xxx" के माध्यम से लिनक्स में LPC डिवाइस रजिस्टरों को देखते हैं, तो हम देखेंगे कि हमारे द्वारा रिकॉर्ड किया गया डेटा इन रजिस्टरों में है। तो ऐसा लगता है कि सब कुछ कॉन्फ़िगर होना चाहिए।

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

ड्राइवर \ gpio \ gpio-lynxpoint.c:

 static const struct acpi_device_id lynxpoint_gpio_acpi_match[] = { { "INT33C7", 0 }, { "INT3437", 0 }, { } }; MODULE_DEVICE_TABLE(acpi, lynxpoint_gpio_acpi_match); static struct platform_driver lp_gpio_driver = { .probe = lp_gpio_probe, .remove = lp_gpio_remove, .driver = { .name = "lp_gpio", .pm = &lp_gpio_pm_ops, .acpi_match_table = ACPI_PTR(lynxpoint_gpio_acpi_match), }, }; 

यह इस तरह से काम करता है: यदि कर्नेल, एसीपीआई तालिका को पार्स करते समय, इसमें _HID पहचानकर्ता "INT33C7" के साथ एक डिवाइस देखता है, तो यह संरचना के क्षेत्रों में मिलान पहचानकर्ताओं के साथ इसके लिए मंच चालक को खोजने का प्रयास करेगा "। Driver-> acpi_match_table"।

जब एक मैच पाया जाता है, तो लिनक्स .probe ड्राइवर फ़ंक्शन को निष्पादित करेगा।

जैसा कि यह निकला, इस डिवाइस के लिए ACPI कोड को कोरबूट में प्रस्तुत किया गया था, मैंने अभी इसकी टिप्पणी की थी। इस तथ्य के कारण टिप्पणी की गई कि इस डिवाइस के लिए विंडोज ड्राइवर को नहीं ढूंढ सका और डिवाइस मैनेजर में "अज्ञात डिवाइस" प्रदर्शित किया। इस पर अधिक नीचे।

तो हम फ़ाइल से जानकारी में रुचि रखते हैं
src \ Southbridge \ Intel \ lynxpoint \ acpi \ serialio.asl (कोड थोड़ा सरल है):

 /*     * src\southbridge\intel\lynxpoint\pch.h * #define DEFAULT_GPIOBASE 0x1400 * #define DEFAULT_GPIOSIZE 0x400 */ Scope (\_SB) { Device (PCI0) { ... Device (GPIO) { // GPIO Controller Name (_HID, "INT33C7") Name (_CID, "INT33C7") Name (_UID, 1) Name (RBUF, ResourceTemplate() { DWordIo (ResourceProducer, MinFixed, // IsMinFixed MaxFixed, // IsMaxFixed PosDecode, // Decode EntireRange, // ISARanges 0x00000000, // AddressGranularity 0x00000000, // AddressMinimum 0x00000000, // AddressMaximum 0x00000000, // AddressTranslation 0x00000001, // RangeLength , // ResourceSourceIndex , // ResourceSource BAR0) Interrupt (ResourceConsumer, Level, ActiveHigh, Shared, , , ) {14} }) Method (_CRS, 0, NotSerialized) { CreateDwordField (^RBUF, ^BAR0._MIN, BMIN) CreateDwordField (^RBUF, ^BAR0._MAX, BMAX) CreateDwordField (^RBUF, ^BAR0._LEN, BLEN) Store (DEFAULT_GPIOSIZE, BLEN) Store (DEFAULT_GPIOBASE, BMIN) Store (Subtract (Add (DEFAULT_GPIOBASE, DEFAULT_GPIOSIZE), 1), BMAX) Return (RBUF) } Method (_STA, 0, NotSerialized) { Return (0xF) } } ... } } 

इस कोड को विस्तार से समझने के लिए, आपको एसीपी विनिर्देश में एएसएल सिंटैक्स के साथ खुद को परिचित करना चाहिए।

लेकिन संक्षेप में, यह कोड पहचानकर्ता "INT33C7" के साथ एक उपकरण बनाता है जिसमें 2 संसाधन हैं:

 I/O memory: 1400-17ff; IRQ: 14; 

इसके .probe लिनक्स फ़ंक्शन के अंदर, ड्राइवर को उपरोक्त डिवाइस संसाधन प्राप्त होते हैं:

 io_rc = platform_get_resource(pdev, IORESOURCE_IO, 0); irq_rc = platform_get_resource(pdev, IORESOURCE_IRQ, 0); 

इस डेटा के आधार पर, ड्राइवर कोड gpio_chip संरचना में भर जाएगा और सिस्टम में gpio नियंत्रक को पंजीकृत करेगा, जो इसे sysfs इंटरफ़ेस के माध्यम से सुलभ बना देगा।

डिवाइस के ASL कोड को वापस करने और BIOS छवि को फिर से जोड़ने के बाद, सिस्टम sysfs के माध्यम से GPIO तक पहुंचने में कामयाब रहा।

शुरू करने के लिए, फ़ोल्डर "gpiochip162" / sys / class / gpio में दिखाई दिया। इस फ़ोल्डर में फ़ाइल "आधार" और "एनजीपीओ" शामिल है। आधार फ़ाइल इस नियंत्रक के पहले GPIO की संख्या, उनकी संख्या के लिए ngpio के लिए जिम्मेदार है।

 $ cat /sys/class/gpio/gpiochip162/base 162 $ cat /sys/class/gpio/gpiochip162/ngpio 94 

इस प्रकार, सब कुछ निर्यात किया गया था जैसा कि यह होना चाहिए। हम स्क्रिप्ट निष्पादित करते हैं:

 $ for i in {162..255}; do echo $i > /sys/class/gpio/export; done 

उसके बाद, gpioN सबफ़ोल्डर / sys / class / gpio / फ़ोल्डर में दिखाई देंगे, जिसके अंदर लाइन की स्थिति को नियंत्रित करने के लिए फाइलें होंगी।

टिप्पणियों की एक जोड़ी:

• GPIO0 के प्रबंधन के लिए / sys / वर्ग / gpio162 / फ़ोल्डर जिम्मेदार है, GPIO1 के लिए / sys / वर्ग / gpio163 / फ़ोल्डर जिम्मेदार है यह बदलाव इस तथ्य के कारण हुआ है कि नियंत्रण संरचना "संरचनात्मक gpio_chip" के आरंभीकरण के दौरान ड्राइवर को "gc-> आधार = -1" सौंपा गया है। यही है, मैंने खुद नंबर चुनने के लिए कर्नेल को छोड़ दिया। यह आमतौर पर महत्वपूर्ण नहीं है, लेकिन इसके बारे में याद रखने योग्य है।
• एक्सेस केवल GPIO लाइनों को दिया जाता है जिन्हें GPIO के रूप में कॉन्फ़िगर किया जाता है, और किसी भी मूल साउथब्रिज सुविधाओं के रूप में नहीं। ऐसी पंक्तियों के लिए, चालक dmesg में जानकारी प्रदर्शित करता है: "gpio% d ACPI के लिए आरक्षित है"। कोरबूट के मामले में, GPIO को मदरबोर्ड के साथ फ़ोल्डर में "gpio.h" फ़ाइल में कॉन्फ़िगर किया गया है।
• डिवाइस और ड्राइवर को _CID (कम्पेटिबल आईडी) विधि का उपयोग करके मैप किया जा सकता है, और कर्नेल में हमारे विषय के लिए दस्तावेज़ "ACPI आधारित डिवाइस एन्यूमरेशन" दस्तावेज़ में प्रस्तुत किया गया है।

यह ध्यान देने योग्य है कि INT33C7 डिवाइस में ACPI टेबल (IBASE और DFI से) में एक ही चिपसेट पर 2 मालिकाना मदरबोर्ड नहीं हैं। सच है, वहाँ सबसे अधिक संभावना है कि GPIO लाइनें आउटपुट नहीं हैं (मैंने उस पल में प्रलेखन को विस्तार से नहीं देखा)।

पहचानकर्ता "INT33C7"

Sysfs कार्यक्षमता बढ़ाने के बाद, मेरा एक सवाल था, "INT33C7" पहचान संख्या कहां से आई?

_HID पद्धति के लिए दस्तावेज़ देखने के बाद, यह स्पष्ट हो गया कि यह http://www.uefi.org/PNP_ACPI_Registry देखने लायक है


इस लिंक पर 3 बिंदु हैं:

• सभी प्रकार के 3 अक्षर पहचानकर्ता (पीएनपी आईडी) यहां इंगित किए गए हैं
• Microsoft द्वारा आरक्षित "PNP" के साथ शुरू होने वाले PNP आईडी यहां इंगित किए गए हैं।
  
• सभी प्रकार के 4 अक्षर पहचानकर्ता (ACPI ID) यहां दिए गए हैं

यह बहुत स्पष्ट क्यों नहीं है, लेकिन पीएनपी आईडी सूची से आप पा सकते हैं कि "INT" पहचानकर्ता इंटरप्रेन्योर कॉर्पोरेशन पर आरक्षित हैं:

 INTERPHASE CORPORATION INT 11/29/1996 

जाहिर है, संपूर्ण उपकरण पहचानकर्ताओं (पत्र भाग + डिजिटल) की एक भी सूची प्रकाशित नहीं की गई है। लेकिन Google की मदद से यहाँ या यहाँ उदाहरण के लिए उपकरणों की सूची और उनके _HID को खोजना संभव था।

वे संकेत देते हैं:

 INT33C7=Intel Serial I/O GPIO Host Controller 

और इस सूची की शेष पंक्तियों को देखते हुए, सभी INTxxxx डिवाइस इंटेल डिवाइस हैं (अब यह बहुत स्पष्ट लग रहा है, लेकिन INTERPHASE CORPORATION के साथ संबंध अभी भी स्पष्ट नहीं है; यह भी बहुत स्पष्ट नहीं है कि इतनी संख्याओं के साथ नंबरिंग क्यों शुरू होती है, लेकिन यह दृश्यमान है) इंटेल विवेक)।

विंडोज में संचार चालक और डिवाइस

अपनी जिज्ञासा को संतुष्ट करते हुए, मैंने अपने बोर्ड पर विंडोज डाउनलोड करने का फैसला किया। जैसा कि अपेक्षित था, सिस्टम को डिवाइस के लिए ड्राइवर नहीं मिला। IBASE और DFI बोर्डों के लिए ड्राइवरों की कोई मदद नहीं की गई, जो समझ में आता है, क्योंकि इन बोर्डों के BIOS में इस डिवाइस को इंगित नहीं किया गया है।

मैं Microsoft वेबसाइट पर ड्राइवर खोजने में कामयाब रहा

हालाँकि, यह ड्राइवर केवल विंडोज 8.1 और उच्चतर के लिए प्रस्तुत किया गया है। मैं अभी भी विंडोज 7 के साथ काम कर रहा हूं।

फिर भी, मैंने अपने अज्ञात डिवाइस के लिए ड्राइवर की खोज करते समय ड्राइवरों में से एक को डाउनलोड करने और उसका फ़ोल्डर निर्दिष्ट करने का प्रयास किया।

हालाँकि, डिस्पैचर ड्राइवर को डिवाइस पर मैप नहीं कर सकता था। हालाँकि inf फ़ाइल में INT33C7 डिवाइस के बारे में स्पष्ट रूप से जानकारी थी।

 [Manufacturer] %INTEL%=Intel,NTamd64.6.3 [Intel.NTamd64.6.3] %iaLPSS_GPIO.DeviceDesc_LPT%=iaLPSS_GPIO_Device, ACPI\INT33C7 %iaLPSS_GPIO.DeviceDesc_WPT%=iaLPSS_GPIO_Device, ACPI\INT3437 

INF फ़ाइल को पार्स करने की प्रक्रिया में, यह निकला कि [निर्माता] अनुभाग ने स्पष्ट रूप से संकेत दिया कि यह मेरे सिस्टम के लिए अभिप्रेत नहीं था:

क्या Intel.NTamd64.6.3 का मतलब विवरण से समझा जा सकता है:

 nt[Architecture][.[OSMajorVersion][.[OSMinorVersion] OSMajorVersion=6 => Windows 7/Windows 8.1/Windows Server 2012 R2/... OSMinorVersion=3 => Windows 8.1/Windows Server 2012 R2 

Windows 7 ड्राइवर को Intel.NTamd64.6.3 के साथ Intel.NTamd64.6.1 के स्थान पर पुश करने की कोशिश कर रहा है, इसे हल्के ढंग से विफल करने के लिए, क्योंकि इसने मुझे मौत की नीली स्क्रीन और एक असभ्य ओएस दिया, और इसलिए मुझे एक रिकवरी करनी थी।

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

उनकी शक्तिहीनता का एहसास करते हुए, मैंने विंडोज 10 पर कार्यक्षमता का परीक्षण करने का फैसला किया। एक सुखद आश्चर्य था। Intel चिपसेट डिवाइस सॉफ़्टवेयर (INF अद्यतन उपयोगिता) ने बिना किसी समस्या के मेरे नियंत्रक के लिए ड्राइवर स्थापित किया।



जैसा कि आप देख सकते हैं, इस उपकरण में हमारे द्वारा इंगित किए गए संसाधन हैं।



सिद्धांत रूप में, GPIO नियंत्रक के साथ ड्राइवर को स्थापित करने के बाद, IOCTL फ़ंक्शन ( जैसे इस दस्तावेज़ में) के माध्यम से काम करना सबसे अधिक संभव होगा।

हालाँकि, विंडोज से कोई GPIO प्रोग्रामिंग कार्य नहीं था, इसलिए मेरे चिपसेट के लिए एक समान दस्तावेज़ की खोज स्थगित कर दी गई थी।

---

निष्कर्ष:

इस लेख ने ड्राइवर और डिवाइस के बीच _HID ACPI पद्धति का उपयोग करके कनेक्शन की जांच की। इस तरह के संचार को उन उपकरणों के लिए एक x86 सिस्टम की आवश्यकता हो सकती है जिन्हें गणना नहीं की जा सकती है।

• लिनक्स के मामले में, ड्राइवर के साथ संचार .acpi_match_table के माध्यम से होता है
• विंडोज के मामले में, ड्राइवर के साथ संचार एक INF फ़ाइल के माध्यम से होता है