Gadgets and Trinkets, The Upstream Linux Way - Geert Uytterhoeven, Glider bv
Goedemorgen, iedereen. Mijn naam is Geert Uitruven. Welkom bij mijn presentatie, Ketchets en Trinkets The Upstream Linux Way. Ik begin met een kort introductie over mezelf en het topic. Dan ga ik continu met devicedrivers in Linux, hardwaredescriptions en eindelijk er zal er wat tijd voor live vragen zijn. Ik heb met Linux een lange tijd geleden in 1994 als een hobbyist geïnteresseerd. Met de help van de porties van Linux naar de Amiga platform. Later werd ik op verschillende andere platformen en architecturen. PowerPC, MIPS, PlayStation 3, met de celbrotemant-engin. En ik ben ook een maintenance van de Linux-chamber van een device-subsystem. Ik ben nu een maintenance van de M68K-architectuur, maar ik ben nog steeds een hobbyist. Maar een paar jaar geleden ben ik een freelancer en ik heb met Linux een kernal hacker geïnteresseerd. En in dat context heb ik meestal contractwerk gedaan voor Renesas te helpen in opstreaming en support voor hun arm-SLC's. En voor dat ben ik de maintenance van de Renesas clock en ping-controle drivers en voor de arm-SLC-platformen. In deze presentatie zal ik jullie begrijpen hoe te connecteren met simpele devices naar een Linux-system. En gebruiken ze natuurlijk van Linux. Simpele devices zijn sensors, motors, switches, LEDs, actuators, displays, solenoids. En dit is belangrijk niet alleen voor makers. We willen bijvoorbeeld een maker-robot of een 3D-printer, maar ook voor industriele automatie waarom je wilt controleren en monitoren grote machines. Misschien heb je een van deze kinderen gezien. Die containeren veel sensors waar je je Arduino of Raspberry Pi mee kan connecteren. Maar deze kan ook een grote machine extenden, zoals bijvoorbeeld deze excavator, die echt een Linux-board en Olimax Olinuxini hebben ontdekken om de operation van het systeem te monitoren. Deze dagen zijn veel mensen met elektronische ongeving op een Arduino. Het is een erg simpele platform waar je een microcontroller kan connecteren. Dat is een grote economie met veel libraries die het meest populaire device ondersteunen. Je bent niet limiteerd op één particular hardware-platform. Je hebt ook ESP32 en TNC, die de Arduino-environnement kunnen gebruiken. Deze avonturen van een Arduino zijn dat er een limitere procespouwer kan zijn op het verhaal van de microcontroller. En er is ook geen hardware-description, die betekent dat je applicatie moet hardkouden op alle devices die er in software zijn.  De meeste boards hebben LED-connected op pin 13, maar dat is de enige ding die je kunt gelijven op. De rest heb je in je applicatie te zorgen. De Arduino provide several APIs to talk to devices. Sommige van die hebben ik gebruikt om pin te handelen. Je kunt een pin configureren, die is eigenlijk een GPIO voor input of output. Je kunt het op een digitale pin rekenen of analoge values rekenen. Als het een pin is dat connecteert met een ADC of een Pulse Width Modulation Output. Er is ook ondersteunen door libraries voor I2C devices, serial peripheral interface, serial port, Uarts en ook voor de Onewire. Om te praten met je devices op de bus, er zijn verschillende libraries. Bijvoorbeeld de Dallas Temperature Library, waar je de temperatuur van de temperatuur van de sensor connecteert met de Onewire. Aan de andere kant hebben we Linux. Voor veel mensen is Arduino te beperkt, en ze willen een hoge performanceplatform te switchen, zoals Linux. Linux hier is een platform voor devices die een reale operatie systeem met multitasking hebben, en een method dat ook een TCP-IP-connectiviteit provides voor internet of wireless. Dat is een heel groot ecosysteem om Linux te ondersteunen. En er zijn, zoals voor Arduino, veel drijfers die meer populair devices ondersteunen. Het procesen van de Power on the Linux systeem kan van een single-core systeem met alleen een aantal megabytes van RAM tot supercomputers met honderds processors en terabytes van RAM. Zoals Arduino, Linux usually provides a hardware description. Voor sommige devices is het niet echt nodig omdat er autodiscoverables zijn, zoals PCI-devices. Andere devices can be described by a firmware ACPI on PCs of a real open firmware on some of the older sun and powerPC boxes. Maar voor embedded devices is this mostly done handle through the flattened device trees. Which is a hierarchical method to describe the devices on your system. Embedded devices traditionally also used board files which were just C files containing structure definitions describing the hardware, but this is being replaced by a flattened device tree. Unlike Arduino, there's a real operating system running when you have a Linux system and with a strict separation between kernel and user space. Most of the drivers are living in kernel space en the application is living in user space.  You can have user space drivers and of course if you have a really embedded system you could have your application in kernel space but it's better to maintain the separation between kernel and user space because this will make your system much safer. And to communicate between these two layers there are standardised APIs. Due to these APIs it means that you can replace both platform and peripherals without changing the application. So for example based on availability, price, performance, features like industrial temperature ranges you may want to decide to change your computer a single board computer like Bigelbomb Black and replace it by Raspberry Pi or OluNyxinio and because of these APIs all of that is possible. It's also possible to change sensors because you have a temperature sensor but it turns out that your device needs to be used in an environment where it can be cold or hotter than supported by the sensor. You can just replace the sensor by another one that suits your requirements and due to the standardised APIs it means that you don't really have to change your application. Let's now show a smart example. Suppose you have an LED on your Arduino connected to pin 13 which is LED built in and you want to blink it. On Arduino you first have to configure the pin as an output in the setup function and then you can have a loop that enables the LED wait a bit, disables the LED wait a bit and so on forever. Very simple, probably the first program everybody writes on the Arduino. Now of course the question is if we move to Linux, can we do the same on Linux and can we do that from user space? Let's give it a try. The first example I'm showing you is using the Linux CISFS GPIO. First you have to tell Linux that you want to use the GPIO from user space so you export GPIO number 953 for example then you have to configure the direction you want to use the output pin because it has to drive LED and then you can control the LED by writing 1 or 0 to a special value file in CISFS. There are also short hands to configure direction and value directory for the glitches. No, that sounds simple.  Of course where does this magic number 953 come from? And is it always the same number? These are good questions. Disadvantage of the CISFS GPIO is that these numbers are difficult to obtain. So you have they are based on which GPIO controller it is and which GPIO on which GPIO controller and worse they depend on probe order of drivers if you add devices to the system so that the numbers can change in de tabel. Er are other issues with this API and that's why CISFS GPIO has been is being replaced by something better. I'd like to point out that there are also Arduino-like libraries for various programming languages on top of this interface so you could still use a program that looked very similar like the one I showed for the Arduino. Is there a better way to talk to the LED? Yes. The CISFS GPIO API has been deprecated but the replacement has been written which is the correct device for GPIO. There's also a user space library for that LibGPIOD to make it easier to to use this card device GPIO API. Together with LibGPIOD some tools are bundled so you can easily use it from the shell for example as well. So let's run for example a few of those commands. I run GPIO detect. It shows me that on my system there are several GPIO controllers called GPIO ships. Each of them has multiple GPIO lines. So the names you see in between in brackets they indicate bus addresses and types. So for example the top one is 605 that's a GPIO controller on the SOC. The GPIO ship 8 that's a device on an I2C bus on I2C bus 4 the device with address 20 in hex and the last one is a GPIO controller connected to a PIMIC. So as you can see it's much easier to find out which GPIO you want to talk to. There's also a GPIO info command which shows you even more information about it also shows you what the GPIOs are actually used for in the system which can help finding which you can use from user space because of course you cannot use a GPIO from user space if it's already in use from a device driver in kernel space.  So how do I now control my LED suppose my LED is connected to GPIO 19 of GPIO ship 2 then I can use GPIO set to disable the LED or to enable it. The GPIO set to enable it you have to be very careful with that because when you close the character device it restores the state to the original state of the GPIO which means that if you just run GPIO set 19 equals 1 it will enable the LED and then when GPIO set quits it will restore to the old state which means that it will blink only very briefly. If you want to let it stay enabled for example 500 milliseconds then you can use the minus M time option en if you can also keep the GPIO asserted until you quit the application by pressing a key or using the minus M weight option. In the last example you also see that you can control multiple GPIO lines from one command which means that if they are on the same GPIO ship this can be done in one atomic operation changing all 3 GPIOs at once which is something that was not possible with the old CISFS API so can we do better? Yes we can because if Linux would know that there is an LED connected to it then we can use the CISFS LED interface no we can just change the brightness by writing a 001 to a special file in CISFS. There are other things we can do because there are triggers let LED triggers with our small kernel drivers on top of the LED subsystem which can control the LED for you without you having to do anything during user space for example if you write activity to the trigger file it means that LED will now die de lage state van het systeem ontwerp. Er zijn ook triggeringen voor andere dingen, voor deze activiteiten, netwerkactiviteiten, de populaire een is ook de hartbeet, die de stumpstumpe laat zien op je LED. Een ander interessant is de pattern driver, die betekent dat je een pattern kan programmen en de kerneldrijver zult de pattern verhalen. Dus je gebruikspaces moet niet dat doen.  In het eerste exemplen ontwikkelde ik een pattern van 500 milliseconden hoog, 500 milliseconden hoog, die is zoekbaar voor post-width modulatie LED's, omdat eigenlijk de pattern implementeert niet de discrete change status. Met het exemplen dat ik daar geef, zal het 0 tot 255 tijdens de tijdperiode 500 milliseconden en dan zal het van 255 tot 500 milliseconden gaan. Als je een binary LED hebt, die kan gewoon op of weg zijn, zoveel als het verhaal wordt 1. Het zal erop turneren, dus je moet een verschillende pattern gebruiken, zoals de onderste. Ik zal het gebruiken om 0 te gaan van 0 tot 0 tijdens de tijd van 500 milliseconden. Dat betekent dat het echt af zal zijn tijdens die tijd. En dan zal ik het automatisch van 0 tot 255 die is geënabeld. En dan zal ik het van 255 tot 255 tijdens de tijd van 500 milliseconden. Dus het zal altijd geënabeld en dan hetzelfde voor de verhaal. Dus dit is een klein exemplen dat je ziet dat kerneldrijvers kan helpen, ook omdat je niet moet controleren. Je LED's van gebruikerspaces, als je een kerneldrijver hebt voor dat. Natuurlijk, het betekent dat je moet vertellen dat er eigenlijk een LED connecteert met de GPIO, dat is iets we zullen praten later. Nu, als je een Linux systeem hebt, er zijn twee manieren die je kan proberen. Een van de manieren is uit drie Linux, dat is een Linux versie waar je kunt doen wat je wilt. Je kunt met whatever custom en hacky solutionen wat je dat je kunt imaginen. Maar het betekent dat er zal worden geënabeld. Een betere manier is met upstream Linux en probeer je te werken met de upstream community en doe het in de upstream manier en dan kan je je iets integreren met de upstream kernel dat geeft je te hebben meer te shares en het makkelijker opnemen als je opgericht naar later kernels. Dus het is belangrijk dat je een langere term is. Natuurlijk, dit betekent dat voordat je je werk van de upstream kan worden geënabeld. Je moet de opnemen van de upstream Linux kernel. We zijn op de tweede sectie die is met Linux device drivers. Dus eerst start ik over user space drivers. Dus op de onderde level in je systeem heb je de hardware.  Op de top van dat zal er een Linux kernel opnemen met low level drivers die typisch bus drivers zijn voor I2C, GPIO, SPI, UART. Op de top van dat zal er meer generische drivers zijn die het interface op de user space om de devices te praten. De examples van die is I2C Dev, die een file in een speciaal device file op de slashdev en dat file geeft je om de devices op de I2C bus te controleren. Het is belangrijk hier. Dit is een device die verantwoordt op de bus. Dus gebruik dat device kun je op alle devices die op de I2C bus zijn. Er is ook een generische driver voor de GPIO ship, die we al opdraagt met de GARDEV GPIO driver. Dus dit geeft een slashdev GPIO ship device die op de I2C bus een GPIO controller wil. Voor de SPI, de serial peripheral interface is het verschillend. Er kan een dev-SPI-dev device zijn, maar dat op de I2C bus op een particular device. En je kunt het alleen op de I2C bus en niet alle obtainers aan het SPI-device, wanneer ze hun SPI-device hebben. Deze device is niet altijd available en dat betekent dat je Linox wilt gebruiken om SPI-device te laten zien. Voor serial ports is een heel klassische device de DevTTYS-device te spoken met UART. En voor pulsepeel modulatie is er ook een interface onder de CCCS file. Nu gaan we eens kijken naar de kernelspacescreen. In deze keuze zijn de hoge levenlevenlevenleven die specifiek zijn om te praten van devices die op de lage levenbus zijn, verbindigd. Op deze slide laat ik ze zien niet straks op de lage levenlevenlevenlevenleven, want typisch een device zoals de Block B mogen op een device dat connecteert met i-square C-buses en er kan ook controleren van de GPIO's. Deze hoogtelevers geven APIs om speciale files te ontdekken of CFSFL, maar deze zijn niet generisch, niet zo generisch als de vorige, maar ze dependen op de device en op het subsystem. Dus laten we gebruikspaces en kernels proberen. Veel mensen komen uit Arduino en willen gebruikspaces proberen, omdat het werkvloor heel simpel is met wat ze vroeger gebruikten. Het kan ook simpel zijn om iets te werken. Er zijn misschien andere redenen waarom mensen willen gebruikspaces proberen.  Bijvoorbeeld als de device een proprietary device met een publiek documentatie, een licentie van de device driver kunnen komen in de plek. De device zou bijvoorbeeld een custom microcontroller zijn dat connecteert met i-square C of SPI bus. Dat is een custom protocool met de microcontroller. Dus in dat geval zou het betekenen om in gebruikspaces te implementeren en te gebruiken, bijvoorbeeld als SPI def. Het advies van een gebruikspacesproberen is dat het meer moeilijk is om aan te reuzen en de drijvers te shareen. Als de device gebruikt in interrupts, kan het een verkeerder zijn om nog een UIO te gebruiken om in interrupts van gebruikspaces te gebruiken. Maar ik weet niet of het te veel gebruikt is. Een gebruikspacesproberen kan ook meer overheden hebben, zeker als je een Bitbank GPIO of iets zoals dat wilt. En dan de kernelsproberen kan het nog steeds meer verkeerder zijn. Kernelsproberen zijn usually meer efficiënt als ze in de opstrijdkernel zijn om te reuzen. Als kernelsproberen een specifieke API gebruiken in het Linux, is het makkelijk om de hardware te abstracten, dat betekent dat je de hardware kan verkeerden later om de interface te houden en je applicatie niet te veranderen. Kernelsproberen zijn ook geïntegratie met andere subsystemen. Dat is bijvoorbeeld als je een serial flash connectt met een I2C bus. Als je dat gaat van gebruikspaces, dan dat is alles dat je hebt. Als je het van de kernels gebruikt, dan betekent dat je een blocklayer subsystemen kan hebben op de top van dat en dingen zoals dat. Voor media advies, als het een camera is of iets zoals dat, wil je het connecten met de media pipelines in de andere parts van de kernels. Voor kernelsproberen is het makkelijk om interrupten te gebruiken. Maar deze avontjes zijn dat kernelsproberen duidelijk meer complex dan gebruikspacesproberen zijn. En als je ze wilt opstreamen, dan is er een opstreaming auffort. Als je niet bekend is met dat, kan het soms een beetje een beetje moeilijk om je verandering uit te veranderen. Persoonlijk, ik denk, er zijn te veel gebruikspacesproberen deze dagen voor de verschillende voordelcomputers zoals de Raspberry Pi en 96 ports. Je kunt alle gebruikspacesproberen voor die drijvende devices wanneer in veel cases een kernelsproberen is. Het maakt het veel makkelijker en simpeler en makkelijker voor mensen om het te gebruiken.  Een voorbeeld hier is de populaire Hitachi HD 44780 karakter LCD. Misschien heb je het eerder gezien, omdat het gebruikt in printer, scopier, faxmachine, veel machine en veel devices. Het is een karakter LCD driver met een parallel bus waarvan er 4 of 8 bit kan zijn en een aantal controlesignal. De meeste devices hebben een achterlijn die LED maakt dat deze plek makkelijk te readen. Maar zelfs in de 4-bit mode heb je al veel pins om het te drijven. Hoeveel van deze LCD is er een serialisator blok in het voortje die tussen de serial protocool en de parallel protocool dat de display nodig is. Dus als je een gebruikingsspel driver voor alle deze variënten van de LCD dan kun je met 5 of meer verschillende driveren een voor de basic GPIO parallel versie voor bit en 8 bit dan een versie dat ondersteunt de LCD waar je een A2C GPIO expander in de voortje een andere driver als je SPIO expander een ander voor de 1 wire en dan misschien je hebt veel devices waar ze een custom microcontroller in de voortje en dat ook verandert de protocool slecht dus je moet veel drivers voor dat.  Nu als je het van kernelspaces dus Linux gebruikt te hebben een driver voor deze character LCD's voor ongeveer 20 jaar of iets zoals dat en dat was een variënt dat was connecte tot de de parallel port dus een tijdje ik konverde dat driver om te gebruiken de GPIO's wat betekent dat je kan connecten tot je GPIO en gebruiken en omdat Linux alweerde onderzoek voor verschillende expanderen zoals je kan vertellen dat je LCD controle is connecten tot een van deze GPIO expanderen het zal gebruiken dat existische driver en het zal uit de boven natuurlijk als je serialiser blok in vond de LCD een custom microcontroller je nog nodig een custom frontend voor de kernelspaces en de voor een van deze maar je kan al zien dat de lees werk ingeweld in het van kernelspaces van gebruik spaces nu wat soort drijvers does Linux al hebben voor simpel devices en er zoveel input drijvers is zoals GPIO keys dus als je switch switches connecten tot je GPIO voor input voor metricks keypads waar je je je multiple switches connecten in een metricks ja compare dat te wat ik op de internet waar iemand doet dat van gebruik spaces dus is is polling multiple GPIO's van gebruik spaces tot het wanne je een een knie dus ook voor rotary encoders touchscreens en al dat is handeld van gebruik spacespaces tot tot input event device vijl dus ook voor simpel output devices zoals LED's eh binary LED's LED's met pulse width modulation veel displays kunnen supporten tot DRM system als zelfs support voor BitBank bus implementations voor i square c spi en 1 wire dus zelfs als je niet heb een hardware controler voor een van deze bus dan je kan gebruiken een ander een groot deel van drijfers voor eh sensors eh LEDC's eh analoge digitale comfort digitale analoge comfort is aan de industriele IO sub system in Linux meestal deze zijn devices dat de connecten tot i square c o spi bus en de controle tot cfs dus gebruik spacel library liep iio tot het makkelijker om te praten deze devices eh ik een voor een per de devices op de bord dus liep iio heeft onderzoek voor verschillende achterkant het kan praten tot lokale devices maar het kan ook praten tot devices connecten tot USB of connecten tot een ander bord over internet voor een voor een bijvoorbeeld dus op deze voor een voor een ander bord de rena zes salvatore XS bord en iio informatie kan me informatie over alle de devices het vindt de list is te lang de slide dus ik ik gewoon te een bord van het als je in liep iio ik suggestie dat je de presentatie dat zal worden gegeven tomorrow een ander voor de dat is de de voor de modulatie dus de middel is een systeem waar je een een square waaf met een verkeerd en een variant de de cycle dat speciaal gebruikt voor voor controleren motor en de ld's in kern de driver pwm ledes die verkeer verkeer ledes en de meeste in kern is limit te deze de verkeer maar verkeer de beginnen punt wont het trape in verwist dat al zoals een is al in dialet die is af k reprobr neemWhoa de de een pwm signaal, die nu niet mogelijk is met een current sysapi. Nu hadden we pwm, we hebben een andere hot-topiek gekregen, het is de RGB LED's. Het is een beetje complex. Een tijd geleden heb ik op Linuxweekly.net dat er een patch-series-poster voor multicolore LED's, het was al op versie 30, de goede nieuw is dat versie 31 het in de Linux versie 59RC1 maakte. Dit is niet een pure RGB LED controler framework, het is een framework dat je kunt controleren de globale en lokale bruinheid van een string van LED's. Het betekent dat je kunt configureren voor een bruinheid voor iedere individuele LED's en dan kun je veranderen de globale bruinheid van de hele string later, de intensiteit van de hele string. Dus als de individuele LED's in de strings zijn, zijn de individuele RGB componenten van LED's, dan betekent dat het er wat RGB support heeft. Door dat kun je controleren, de lokale bruinheid zal dan zijn de color controleren en de globale bruinheid van de hele RGB LED's, laten we de LED's verbinden. Maar ja, het is hetzelfde dat de RGB LED's nodig meer lucht in de kernel. Vooral als we de NeoPixels en DotStars, die de kleine RGB LED's zijn, kunnen je de serial bus controleren. Vooral voor NeoPixels is het een beetje complicateerd, want ze moeten exacte timings nodig. Op microcontrollers gebruiken mensen de SPI controleren, of ze willen te controleren over lange strings van NeoPixels of ze gebruiken speciale DMA controleren. Zodra er geen upstream support is daar, dan zou ik leuk zijn om dat te zien, natuurlijk. Nog een gapara, motor en activatoren. Er zijn nu geen GBO motors, relays of activatoren, zoals de GPO LED's. Ik denk dat de meeste reden voor dat is dat er geen motor en sub-system is in de NeoPixels kernel, waarom er een LED sub-system is. Dus wat mensen typisch doen, als ze gewoon willen controleren, is om het als LED te controleren. En dan gebruik ik de GBO LED's, dus hoe zou je een motor controleren? Typisch is dat door de luchtbrug gestaan, met wat op de lucht van mijn slide. Dus het is het luchtbrug, omdat het luchtbrug lijkt zoals de letter H. Het invoort vier switchen, A, B, C, D. En op welke switchen zijn geënabeld, zal de motor spinnen of in één richting spinnen, in de andere richting stoppen.  Bijvoorbeeld als je een aantal switchen, A en D, de motor gaat in één richting en als je een aantal switchen bent, zie je dat het in de andere richting gaat. Mere drijfers, ik zie ze om de luchtbrug te implementeren. Ze proberen ook een nabelsignal dat kan worden beeld met controle. En ik denk dat Linux met een generale hbrug drijfers zou kunnen doen die de schrijvingdivijs aanbieden zouden zijn, en controleren ze van gebruikerspaces met een simpele interface in CISFS om de motor in één richting te turneren, in de andere richting te stoppen, brengen, controleren op snelheid, als het een PWM-nabelsignal is. Maar dat is iets dat er definitief nodig is om te worden beeld. Eindelijk, een andere drijfers zou willen praten over deze GPIO aggregator, die ik ontstaan, en die was accepteerd in versie 5.8. Dus, zoals ik het vertelde, voordat een GPIO kan controleren met de character-devijs interface om die GPIO-nabelsignal te ontstaan. Nu, deze device-nabelsignal vraagt jullie om alle GPIOs op de GPIO-controller te controleren, die een probleem kan zijn, zoals het is niet aankomend voor een bord, dat het een GPIO-controller is waar een GPIO is gebruikt voor een heel kritische systemoperatie en de andere is gebruikt voor andere externale devices. Dus als je de permissies op die GPIO-nabelsignal veranderen, dat een gebruiker die de device wil controleren kan controleren, dan heeft hij ook de permissie om de kritische GPIOs te controleren, die is een beetje ongeveer. Dus ik kwam op de solution om een nieuwe virtual GPIO-nabelsignal te creëren, de GPIO aggregator, die geeft je te aggregeren met verschillende GPIO's en te verbinden met een nieuwe GPIO-chip. Die nieuwe GPIO-chip heeft het eigen deft-GPIO-chip file en dan kan je de permissies op dat veranderen. En dan kan de gebruiker die de permissie om de accesses te ontstaan, alleen de GPIO's die de GPIO aggregator door de GPIO aggregator kan gebruiken, en niet alle andere GPIO's op de parent-GPIO-chip. Een voorbeeld dat ik hier geef, dat geeft je hoe te verbinden met een GPIO-nabelsignal van 1 GPIO-chip, en de GPIO was 2020 en 2021 in een nieuwe GPIO-chip. Om een speciale file te schrijven in CZepast, de nieuwe device file, en dat geeft je, dan kan de GPIO info laten zien, de nieuwe GPIO, en je kunt de permissies van het file veranderen om iemand te geven accesses.  Dit begint als een manier om GPIO's te ontstaan voor een virtuele machine, maar het is nu een gebruikelijke feature voor andere gebruikers ook. De GPIO aggregator kan ook gebruiken als een generische GPIO driver, zoals I2C-dev en SPI-dev voor autobusers. Ik zal het later over praten in de volgende seizoen. We hebben een hardwaydescription gekregen. Dus wat is een hardwaydescription? Het is eigenlijk om te vertellen wat devices op het systeem zijn. Omdat, als leuksen niet weten wat devices zijn, dan kan GPIO's niet accessen. En dan kan het apparaat niet accessen. Dus voor verschillende typen van bussen is er autoproop. Bijvoorbeeld een PCI of een wire. Als een device erop is, dan wordt het automatisch detecteerd. I2C-dev's zijn typisch beschermd, maar het is de manier om te vertellen dat er een device erop is, om een nieuwe device te schrijven in het systeem. Zoals ik je showed voor de GPIO aggregator. Zoals ik je showed, is het een PCF8574, die een GPIO expander is. Het is present op address X24. De speciaal device files dev I2C en dev D2S, zijn altijd available. Zoals Liam Snow said, is de device daar. Typisch deze dagen zijn de devices in de device-tree gestrijven, die is een hierarchische systeem waarin je verschillende noten, en iedere note beschrijven de device. De type van de device is ontdekend door een kompatiete waarde, en een paar andere property's die registreren, interrupten, en misschien device-specific property's, en dan meer complicate dingen, zoals subnoten, links naar andere devices, naar p-handels. Een voorbeeld hier is een SPI-controller met een SPI-device. Aan de top zie je iets in de beschrijving van een SPI-controller op Renissa's platform. Typisch deze is de deel die in de DTSI file correspondt naar de SOC. En de onderdeel shows je hoe om een externe device naar deze SPI-controller. Dit is in dit geval een klein Ebron Flash ship. Dit is typisch behoorlijk in de Borg-DDS file. Een van de meest gewone vragen over SPI-device is dat mensen zeggen ik wil SPI-device in DT, omdat ik mijn device van userspace wil gebruiken met SPI-device, en dan posten ze de patch. Maar dat is niet accepteerd, omdat de eerste deel van de device 3 is dat het hardware, niet een software politie beschrijft. Er is geen SPI-device. Je moet beschrijven wat eigenlijk connectt met de SPI-device, niet hoe je het wilt praten.  Dus de solution om dat te doen is een proper kompatieke waarde. En als je een proper kompatieke waarde hebt, kan je het gewoon aan de SPI-device-driver, die een array van devices kan praten. Als je niet wilt aan het draaien, kan je het ook op het manier opbinden. Er is een probleem dat je het device systeem aan de CIS-FS kan vertellen wat het driver moet opbinden. Dus in dit geval, het vertelt dat je de SPI-device op bus 1, device 0, op de SPI-device-driver gebruikt de commands die je erin geeft. En na die SPI-device speciaal opbinden. Hoe komt je met de kompatieke waarde? Door alle cases waar je je device in DT hebt, moet je device 3 bindingen voor je device hebben. Als je een device hebt met de kompatieke waarde, dan moet mijn vender, mijn device, en het is van twee parts. Dus mijn vender is de vender-prefix. Als het nog niet is in het vender-prefix.yaml file, dan moet je het opbinden. Als er nog geen bindingen voor de device zijn, dan moet je mijn vender, mijn device, de YAML file, die bindingen voor de device beschrijven. Als dit een heel simpel drijvende device is, die is de keuze voor CIS-FS, zoals een echte tijdklok of iets zoals dat, we schrijven gewoon naar de CIS-FS en voor te doen, dan zou het in het drijvende device een file zijn. Als je bindingen hebt, moet je make sure dat je een drijver dat veel is. Dan moet je de device nu aan de boord DTS. En het belangrijkste is nu dat we de device 3 bindingen in deze YAML syntax hebben, dat je een validatiekommand kan doen om te bekijken of je bindingen en je DTB op de schemaal zijn. Let's give an example. Ik heb een GPIO operator door. Het gebruikt twee GPIOs, een om de door te openen, een om de door te lopen. Ik heb hier een sample device 3 bindingsfile voor dat. De belangrijkste deel is de exemplen die op het onderkant zijn, maar ze hebben het op de slide gegeven, dus ik heb het op de rechter gegeven en het werd een beetje groter, omdat het de interessante deel is. Het bevindt je dat je een doordevijsnode moet hebben, dat is compatible met mijn vendor, mijn door, dat indikt dat er wel een soort device is.  Er zijn twee GPIOs, een om de door te openen en een om de door te lopen. Ja, deze exemplen voel ik te valideren, want het heeft de GPIO-lijnen, maar er zijn nogal twee linken nodig dat je een GPIO-controller hebt, ook voor dat. Maar laten we dat weten voor nu. Dus je hebt gecreëerd bindings zo, voor je door. De volgende stap is een driver voor dat. Dus je moet dus een nieuw driver of een existente driver nodig en als het een existente driver is, moet je de compatible waarde aan de driver toevoegen, of moet je het meteen binden. In dit geval is het een erg simpel GPIO-controller, dus je kunt de GPIO-aggregator gebruiken voor dat. Dus als je, dan kan je Cizavas gebruiken om de driver, de device systeem te informeren dat je de driver voor de doorgeving voor de doorgeving wilt overigen, met de GPIO-aggregator en dan kan je het binden. En naast dat heb je een nieuw GPIO-chip met twee GPIO's. Dit is ook een voorbeeld, het zult ook laten zien dat door de GPIO-lijnen in de DTS dit ook in de GPIO-info en dan kan je ook de GPIO gebruiken om de GPIO te vinden en dat maakt het easier voor gebruikers om te veel lijnen op de speciaal lijnen. Hoe schrijf ik mijn device in mijn DT? Dus één solution is om het door de doorgeving in de DTS te maken. Mijn mensen denken dat het een beetje inflexibel is op het gebruikgeving. Oudere opties zijn om de device te creëren wat meer flexibel is. Als je dat doet, dan zijn er drie opties. Eerst loopt je de overleiding aan het rondzijden. Dit is iets dat niet ondersteund is op het web. En ik zal het later opdraaien. Oudere opties zijn om de uboodlood te overleiden voordat het begin in de kernel is. Of er ook een tool is om een base device, een file en een of meer overlijs in een nieuw DTS file. Dat kan heel makkelijk zijn. Een overleiding van een sample is hier gezegd. Als je dit comparet met de vorige example waarin ik het EEPROM gevoel had. Je ziet dat het heel simpel is de belangrijk verschillende is dat er een plug-in lijn is op de top. Nu een beetje dynamisch overlijs. Dat kan ondersteund worden. 