Device Tree: hardware description for everybody !

hello and welcome to my talk about the device tree the other description for everybody my name is thomas petazzoni and i have been working at bootlen for over 12 years as the cto and one of the embedded linux engineers we are a consulting company providing embedded linux expertise such as development consulting and training to our customers in fields like bootloader development linux known development yoktop project and build root we do complete linux bsp developments hardware support and bootloader and linux and we have a strong open source focus with a lot of upstreaming work and contributions and our training materials are all freely available i am also one of the commanders of beardroot and i live in toulouse in the south of france so this talk is an update from a talk i did many years ago called device tree for dummies back in 2013 2014 and in this talk we are going to discuss what is the device tree why we have the device tree what is the basic syntax of the device tree the principle of inheritance that exists in the device tree what are the specification and the notion of device stream binding how do we build and validate device trees and most importantly what are the common properties and a number of examples about device trees so this is a slide showing an example embedded platform which contains a system on chip in the middle in the grey box this system on chip includes a number of cpu cores in blue and around it a number of peripherals such as gpios ethernet mac pcie controller gpu ddr controllers and many others this system on chip is then included into a board on which you have additional components such as a spy flash a touchscreen controller a ddr memory a camera sensor a display panel an auto codec and more and this typical embedded platform is important to keep in mind as the reason for the device tree is to describe the hardware that we have used in such platforms in such platforms we have some hardware that is discoverable and some hardware that is not so we have hardware buses that provide discoverability mechanisms for example on pcie or usb buses you don't need to know ahead of time what devices are connected on those buses the devices can indeed be enumerated and identified at runtime using mechanisms that are part of the the definition of those buses you have the concept of vendor id product id device class in pci and usb which allows to uniquely identify the device and therefore the corresponding driver that is needed in the operating system but there are many more other hardware buses that do not provide any discoverability mechanism for example i score c spi one wire or memory map devices are typically not dynamically discoverable one needs to know what is connected on those buses how they are connected to the rest of the system and embedded systems typically make a lot of use of such buses indeed ice core cspi memory map devices are very very common in most embedded systems so the android description is necessary for this non-discover hardware the operating system needs to somehow get the details uh for things like the system on chip as two cortex a9 cpu core two ui controller of this specific variant which is registered at that address and the rq line that one and the other ui controller with these other address for the registers and this other interrupt line that's the same system on chip as maybe three iscsi controller of that other variant with register there and the entrop line here and the input clock there all those details the operating system simply cannot guess this also applies to what what is available at the board level for example let's say you have a serious logic 4234 codec how can the operating system guess that it is connected on the icecrow c 0 at slave address 45 connected to the i square s interface 2 of the system on ship with the codex providing the clocks and that this codec has a reset signal connected to some gpio of the system on chip again all those details cannot be guessed by the operating system or the bootloader they have somehow and need to be described either in code or some other data structure so we have different possibilities to do that to provide this description it can be done directly in the operating system or bootloader code using compiled data structures typically in c and this is how it was done on most embedded platforms in linux and new boot but it was at some point consider not maintainable sustainable mainly on arm 32 which motivated for this specific architecture the move to another solution another solution that is exist on some platforms is acpi tables this is the widely used solution on x86 systems but it is also now available on a few arm 64 platforms in this case the acpi tables are provided by the firmware so on x86 systems it would be your bios that provides those tables to the bootloader and to the operating system and these tables describe the non-discoverable aspects of the hardware another solution which is the main topic of the talk today is the device tree it is used on most embedded cpu architectures that run linux for example arc arm 64 risc-5 arm 32 poor pc extensor mips and a bunch of others it originates from the power pc well and is not a linux specific solution but it is now used in linux in your boot in barebox in the arm trusted firmware or tfa in freebsd and perhaps in other projects as well writing and or tweaking a device tree is not always necessary when you want to part linux to a new board or support new hardware on one of those cpu architectures so the principle of the device tree is that you write as a developer a tree data structure that describes the hardware in a format called device resource typically stored in a with a dot dts extension this file that describes the hardware gets compiled to a more efficient representation called device 3 blob or dtb so the extension is dtb and this transformation from source to blob is done by the device tree compiler or dtc the resulting dtb accurately describes the hardware platform in an os agnostic way and it can for example be linked directly inside a bootloader binary this is what you boot or bearbox would do or it can be passed by the firmware or bootloader to the operating system and this is what would happen with linux so for example nowadays when you boot linux on an arm 32-bit platform from a the u-boot bootloader you use the bootset command which takes the canal address where the kernel image has been loaded into ram and the device triplob address so the operating system really needs to have access to the device tree to be able to recognize what hardware is available and how it is organized here is a first look at the base syntax of the device stream so on the right hand side of that slide you can see an example of device tree with a number of comments so it is really a tree of nodes that are separated by curly braces a little bit like data structures in c there is a root node that is labeled with slash and a number of sub nodes for example node at 0 is a node node at 1 is another node at the same level at as node 0 and child node at 0 is a sub node of node at 0. each node has a name in this case node is a node name child node is a node name node is another node name and then each of those nodes have properties and they are each of a name and a value the property values can be strings can be integers can be arrays of integers can be booleans so there are different types of properties and pretty much in the usage of that device 3 syntax for representing hardware we will have one node representing a device or an ip block in a system-on-chip while the properties will be there to describe the characteristics of a certain device it should be kept in mind that the device 3 compiler dtc only does syntax checking no and but no semantic validation so dtc allows you to write completely arbitrary properties to with completely arbitrary values it only matters that the the device tree is syntactically correct so let's have a look at the simplified example of a device tree on the right hand side we have a very very simple embedded system and that has a system on ship with two cortex a9 cores it has a ddr controller a nice corset controller a geek interrupt controller and a usb controller from the chip id vendor and on the left side we see the device tree which has been simplified a little bit with with some nodes folded and we will unfold them in the next slides so we have a top level uh node which really and globates all the other definitions and it has a number of top level properties address cells and size cells which we will be discussing later it has a compatible property which identifies the platform as a whole and we will again talk about the compatible property later and then it has a number of sub nodes some of those nodes are mandatory in the device tree specification and some are really specific to each platform the cpus sub node is specified by the device respect and it will contain description of the cpus memory will describe the memory chosen will describe firmware related information and soc in this case will describe the devices inside the system on chip so let's have a look at the sub-nodes and starting with the cpu sub-node so we have two cpu cores so we have two sub nodes cpu at zero and cpu at one each of those nodes also has a label that you can see before the colon cpu zero cpu one these labels can later be used to refer to such nodes in other parts of the device a little bit like you would have pointers in c the device tree has a concept of p handle which allows one property to point to another node using this concept of label so here we have two cpus that contain in your our system the next node is the one describing the memory so the run that is attached to our system it's a very simple node which contains just a device type property saying this device is a memory and a rank properties that gives the base address of the memory physical base address and its size the other sub-node that we have expanded here is chosen which is a mechanism that allows the firmware or bootloader to pass extra information to the operating system which is not exactly hardware description for example the boot args property will be used by the bootloader to pass the canal command line to linux std i would pass is another variable that can specify what should be the default output for the known messages and then we have the soc sub node which is actually the most important one and where the biggest part of the device three will be this node whose name can be different from one platform to the other again this one is not specified by the device tree specification we'll be there to encapsulate all the devices that we have in our system on chip and the devices that are connected to them so for example here we have the description of an interrupt controller which is our geek interrupt controller so it has a number of properties that describe this interrupt controller and we will discuss those properties later on it describes a nice quasi controller and this ice crease controller is interesting because not only the ice question controller itself is described but we have an uh knee prong attached to this ice quesadilla controller at slave address 52 and this eeprom which is a nice corset device is described as a sub-node of the iscosic controller so the device tree is a tree representation of the hardware that mimics the topology of the hardware the eeprom is connected to that ice quesadilla controller so we represent the eeprom as a sub-node of that accuracy controller so if to this um very i squashed controller there was another ice core c device such as an audio codec for example it would be also represented as a sub node of that exquisite controller just side by side with the eeprom moving on we have yet another device in our system on ship which is a usb controller and it is again described by a number of properties that we'll discuss later on but here you can see that no usb device is described as a sub node indeed usb is one of those buses that provide dynamic enumeration so in the vast majority of the cases there are no need to describe usb devices in the device tree the usb controller will be able to enumerate them and discover them at runtime so where do you find these device resources even though they are completely or at least supposedly operating system agnostic there is currently no central and operating system mutual place to host device resources and share them between projects indeed as we've seen they're already used by linux by ubud by their box by tfa by freebsd and perhaps other projects as well but there there's no like neutral place to store them so in practice the linux scanner source code can more or less be considered as the canonical location for device resource files so in arch arm or arch arm 64 boot dts this is where you would find for each cpu architecture the device 3 files there are approximately 4 700 device 3 files as of linux 5.10 and this is obviously growing and growing as we add support for more system on chip and more platforms those device 3 files for linux are sometimes duplicated or synced in on various other projects and this is what ubroot and bearbox are doing for example these device 3 files are not monolithic instead of writing everything in one single dts to describe your complete platform we will typically split that into multiple files that can be reused between platforms so we have the concept of dtsi files which are device three source include files which can then be included into dts files only dts files are accepted as an input to the device free compiler so only dts files can really be compiled but they can include any number of other dtsi files so a very typical use case of this inheritance inclusion mechanism is that dtsi files will typically contain the definition of what is inside the system on chip and then this dtsi describing the system on ship devices will be included in all the dts files describing boards that use that system-on-chip for example for the ti am 335x system-on-chip which is quite popular as being used for the bigger bone platform there is one dtsi file describing the system on chip and all boards that use the am335x system chip will include the same gtsi and specify in addition to what is described in that dtsi the devices that are on their specific board and this inclusion works by overlaying the tree of the dts over the tree of the dtsi and of course this can go on on with multiple levels this inclusion is done with is the c preprocessor directive sharp include because all the ts files in linux are passed through the cpr processor before they are fed into the device 3 compiler dtc this most notably us to use sharp defined definitions and provide like human readable constants instead of hard-coded values so here is an example using the am335x soc as an example so on the top left you have the am33 xx dtsi of course just a very short portion of it which describe one ui controller so it describes the ui controller with a compatible property a reg property an interrupt property and a status property you can see here that the status is disabled which means that the device is not really used and then on the top right we have a dts file which describe a particular board that uses that soc it starts by including the dtsi as i mentioned and then this dts is going to override or add additional properties to this senior port controller description as you can see the status is changed to be okay to indicate on this specific board the uart controller is actually used so the device should be enabled by the operating system and two additional properties pin control names and pin control 0 are also added at the bottom of the slide you have what looks like the final dtb of course in practice the dtp is binary format so it doesn't look like text file but this is what you would get if you would decompile the dtb back into a source file so what you see is really the combination of the dtsi plus the dts where the values specified in dts win over the ones defined in the dtsi when you do such inheritance you have two ways to override values specified by a dtsi you can either do like the example shown replicate the hierarchy of nodes and at the same location define a property with the same name so for example in the case specify here at the left bottom you would get the status be okay in the final dtb but another way of doing that is to use the label and on this example the serial node has a label called uart zero so you can replace this solution by the one on the right side where in the dts instead of having to replicate the hierarchy all the way down to the specific node you're interested in you can use this ampersand url notation and just override that status property this solution is actually now the preferred solution in at least in the linux kernel for overriding properties from another dtsi you are including how do you build divine street files you typically don't build them manually on arm and arm 64 there are make files in the channel that indicate which device trees should be built depending on the platforms that are enabled in your kindle configuration so for example arch arm 64 boot dts marvel make file is enabling several device 3 and this is just a small part of that that file which says that if config arc mvebu is enabled in your kernel configuration this is one of the options for marvel platforms then the two device trees described there will be combined so you will get as the result of the device the canon build two dtbs corresponding to those 200 platforms so if you run make to build your kindle you would get those dtbs but there is also an explicit make dtbs target that is available if you want to build just the dtbs and during the canon build you will get messages like dtc and the name of the gtb just like you can see the kingdom buildings c files and sometimes assembly files as well um there is no some work that has been done to validate device three files and as i mentioned dtc is only doing syntax validation but we now have some yaml written specification of device 3 and this is a topic we're going to discuss later in this talk that allows to do semantic validation and the linux scanner has two new or relatively new targets in the in its build system to help with that validation process make dt bindings check you can verify that the yaml bindings are valid that the ml files can be parsed properly while make dtbs check we really check the dts files that are in the channel against all or one of the ml binding that you can specify as an argument and this is a very useful tool because the fact that dtc has only been doing syntax validation has caused many people to to lose hours and hours looking for issues in their device trees and ended up finding that it was just a small typo in a property name or just a mix-up in in the values of the properties and having validation at the semantic level allows to detect such silly mistakes and hopefully fix them earlier when you have booted a system or linux scanner with the device tree you can also explore at run time the device tree on the target simply to verify if you're running with the right device tree if it has the the latest changes you have made so if you go in the csfs file system in slash c vmware slash device 3 you can explore the device tree where each node of the device tree is a directory and each property is a file so you can cut all the properties you can cd into the nodes and really check what your device three contains very useful debugging tool um it is also possible to modify the device tree at runtime normally the device tree is just loaded by the bootloader and passed as is to the kennel but in practice a few changes can be done or potentially more changes can be done you boot automatically patches the device tree block that is passed to linux first to set the run base address and signs if you remember this memory top level node that we have in the device tree you might have a default value in the dts file you've write but in fact you boot is going to override that with the exact ram ramp-based address and size it has detected your boot can also pass the canal command line to linux using the slash chosen slash bootrx property that we have also discussed earlier but it can also do other things like set the mac address for mac for network interfaces for example there are additional um device three blob patching features that you can do in ubud there is a set of fdt commons and fdt stands for flattened device tree this is basically the compiled device three format which you boot came and can modify with commands like set fdtmk node fdtrm and there's a whole bunch of other fdt commands as well another concept is the one of device three overlays on which i'm gonna spend a little bit more time and the device three overlays is there are there to solve a specific use case of platforms that have some flexibility aspects that are difficult to describe in a static device tree um typically a use case are baseboards that um can to which can be connected an arbitrary number of expansion boards um for example in the bigger board world there are capes you can connect expansion bars to your beaglebone raspberry pi hats also of the same concept but another use case are fpgas that contain arbitrary ip blocks that can be synthesized and so this gives some flexibility into the hardware which has to be reflected in the description of that hardware in the device tree and to support that instead of writing another and another device tree for each of these combinations that exist between a baseboard and any number of expansion board that you connect to it the concept of device tree overlay allows to describe what is in your fpga or what is in one of those expansion boards and have this device three overlay be applied to a base device stream at boot time a little bit like a patch to the device stream and so for example such an overlay can describe a display panel that is on your expansion board or a bunch of relays that are on your expansion board or any other device that your expansion board contains and this the description of that device or devices will be added to the base device tree you boot as support for applying device 3 overlays so it can be done in your boot before ending over the device tree to the kano there is however no support in linux for applying device 3 overlays at runtime if you want to see some examples of device 3 overlays you can look at the linux kindle tree for the raspberry pi project and this is where they store their overlays so how does one know how to write the correct nodes and properties to describe a given hardware platform indeed we have seen the overall syntax then we've seen how the device gets compiled that pass to the operating system but really if you need to write your own device tree for your own platform how do you do that how do you know what to write there's really two layers of documentation that are available the first base layer is the device tree specification which is available on pbs3.org and it provides the base device 3 syntax definition and specifies the number of channel properties for example the cpus node the memory node the chosen node and a few other aspects are described in that specification but it is far from sufficient to describe the wide variety of hardware devices we have today so in addition to that we have the concept of device tree bindings which are documents that each describe how a particular piece of hardware should be described in the device stream they are currently located a little bit like the device we find themselves in the linux keynote sources in documentation slash device 3 bindings in theory they are operating system agnostics so they really have no place in the linux kindle source code but this is where they belong today these bindings which are documents they are reviewed by the dt binding maintainer team of the linux scanner which ensure that bindings across different types of devices are reasonably consistent and that people don't come up with creative ideas on how to solve the same problems there are two ways of writing such device three binding documents the legacy way which are simple human readable text documents but the new norm is to write them in yaml so that they can be used for device tree validation as we have mentioned earlier so here is an example of a legacy old style device rebinding document which is there to describe the isc controller used in atmel no microchip platforms and it says that if you want to describe in a device tree a nice crc controller for those platforms you need to create a node which has a number of required properties compatible reg interrupts address cells size cells and clocks and then in addition you can have optional properties they can be there or they can they may not be there such as clock frequency dmas dma names scl gpios sdn gpios and there are actually a number of others that they have cut just to make things fit on the slide and then under on the right column um such device stream bindings typically come with an example showing how it can be used and you can see them in use so we again see this principle where we have one node describing the iscsi controller and then as sub-nodes we have the description of the devices connected to that i square c bus of course the device tree binding for those devices is another device tree binding document because those are other devices the new format in yaml is somewhat a little bit less readable as a human but the benefit is that it is more easily machine possible for validation and this document specifies how to write a device tree to describe the ice crease controller of am logic socs so it contains pretty much the same information such as which properties are expected which one are required so we can see the required field says that compatible rag interrupts and clocks are mandatory and we can see that compatible can be one of those two values that there must be one entry in the rank property there must be one entry in the intro property there must be at least one entry in clocks and then there is an example again that shows how it should be used there are some principles in designing in the design of those bindings the bindings should describe the hardware like how the hardware factually is but not the configuration of the hardware like not how you personally choose to use the hardware that is quite a bit of a distinction and that's the end force when designing the device three bindings also the bindings should be operating system agnostic which means that for a given piece of hardware the device tree should ideally be the same for ubud for freebsd for linux so we really need to describe the hardware but and not how it is used by a particular operating system and also there should be no need to change the device tree when updating the operating system there is a backward compatibility requirement that they try to enforce in practice it is quite difficult to to always enforce but they try to enforce it and so that when there are changes that are needed in device tree bindings they should be backward compatible also the device stream should describe the integration of the hardware components but not the internals of hardware component details so for example the details of how a specific device or ip block is working internally does not belong to the device tree what belongs to the device tree is the description of i have an ip block there which is a nice question controller and then how it is integrated with the rest of the system around it it is integrated with the rest of the system as being located at that address for its i o registers it is connected to this um line of the interrupt controller it is connected to this line of the dma controller and so on and same for devices outside of the system on chip if you have an audio codec you are not going to describe the internals of the audio connect but just like the external signals that's um connected to the rest of the system its data interface for audio its control interface to the processor maybe its reset signal and other signals that it may it might have of course like all beautiful design principles the principles that i have just described are sometimes violated um just because it is difficult to get them applied in all situations or also because the the device 3 has a history and in the initial steps of device 3 usage on arm some mistakes were made which are somewhat still present in parts of the knot so let's have a look at a number of the properties in the device tree and the most important property by far to explain is the compatible property the compatible property is a list of strings from the most specific to the less specific and this compatible property describes the specific binding to which the node complies so this is the property that is going to say this node is describing this particular device using that specific device tree binding and it uniquely identifies the programming model of the device and this term programming model comes from the device tree specification so essentially it means that if there is a given ip block such as a nice question controller which is reused between system on chips we would typically have the same driver in the keynote for it because it's pro in the same device strip representation because it's programming model which means it lists off registers and the meaning of the bits in those registers is the same it's the same ip block so we can reuse the same driver but also we use the same device representation for it so practically speaking this compatible string not only just says which debunk street binding is used to represent that device but it is also used by the operating system to find the appropriate driver for that device so there it is kind of a free form string which for real hardware matches vendor comma model as you can see in the examples below such as arm coma arm va timer or actions comma s 900 dash uart for yard controller would be um compatible values for real hardware the last two are for um linux scanner drivers for regulators fixed regulators and for keys over gpios which are not like like real hardware is more like what you do based on a given piece of hardware there is also a special value that can be used for some compatible string called simple bus this is the value that is used for a node in the device screen which represents a bus where all sub-nodes are devices that are memory mapped so it is very common that's one of the top-level nodes describing the all the devices in your system on chip will use that compatible value in terms of association with the linux keynote drivers and this is how it gets done for example for memory map devices and linux memory map devices are managed by what we call platform drivers and each of those platform drivers registers in the linux channel a struct platform driver that you can see here at the bottom of the slide it this structure contains a number of function pointers such as probe and remove but one of the thing that matters to our discussion is the id table field it points here to a structure called imx uart dt ids which contains the list of compatible strings that this driver is capable of supporting and as you can see in this driver each compatible string is associated to a data field that i had to cut off for size reason for space reasons but that is different for each compatible string indeed this very driver which is a driver for the imx uart controllers is supporting four different types of uart controllers all coming from from freescale but they have some small variations they are not sufficient to warrant making different drivers for each but still the driver needs to know um whether it is a niamic 6q type of uart an imx 53 type of yard and i mix one type of uart or an imix 21 type of uart and the compatible string will indicate that associated to a different data value that the rest of the driver can use to act slightly differently depending on the type of the uart besides this compatible property that mainly identifies the driver we have a number of other important properties that are commonly used the right property has different meanings depending on the device that uses it if it is used to describe a memory mapped device the reg property provides the base address and the size of the i o registers to communicate with that device over the memory mapped bus there can also be several entries if the device has multiple areas of registers for rx corset devices the reg property will contain the address of the device on the ice core c bus for spy devices it contains the chip select number and every bus can give a slightly different meaning to the rank property then we have properties to describe interrupts interrupts will give the interrupt number and sometimes a bunch of flags related to it inter parent will point to the interrupt controller that is used for all the sub nodes um in device stream when interrupts extended can provide bus at the same time so it's a single property that allows you to give a pointer to the interrupt controller and the number of the interrupt that you want to use from that interrupt controller as well as a number of flags clocks is also widely used it indicates um which clock or clocks are used by your the device that you are currently describing and from which clock controller dmas in a similar way will describe which dma controller your device is attached to and which channel of this dma controller it is using status that we have already mentioned before indicates whether the device should really be enabled or not by the system so a status of ok means that the device is present and should be enabled by the operating system any other value would leave the device unused almost as if it was not even described in the device tree there are also pin control properties that describe the pin mixing requested by that device in the device tree there is a concept of cell to encode integral values so all integer values are encoded in 32-bit values which are called cells so the example here of the property foo is a property that has a value of just one cell if you want to encode 64-bit values you need the two cells of 32-bit so in the uk in the new example foo has a is a property with two cells of each 32-bit forming a 64-bit value and then we have properties such as sharp address cells and sharp size cells that indicate how many cells are used in the sub nodes to encode the address and size in the rank property so first of all let me make it clear they start with sharp they are not comments even my syntax highlighting gets it's a bit wrong they are in green because they are considered as comments but they are not comments they are really just properties whose names start with a sharp sign so if we look at this soc node it says compatible equal simple bus which again says every sub node describes a memory mapped device one of the memory map device that we have is a nice question controller but this soc node also provides two properties for the number of address cells one and the number of size cells one that are used by the rank properties of the child nodes so the rank property of our ice question controller has one cell for the address which is f100 one zero zero zero and one cell for the size which is one thousand so this is the base address of the memory map register for the ice creaser controller and the size of the register area but then this accuracy controller node itself overrides those values and says for the sub nodes of me the android the number of cells to encode the address will be 1 and the number of cells to encode the size will be zero and indeed in the child node which is a nice course eprom we have a reg property which contains just 52 just one cell which encodes the address and indeed for ice corset devices we don't they are not memory mapped we don't have a notion of address and size we have just an address which is the slave address on the icroc bus so we need just one address sales and zero size cell this concept of cells applies to other things as well for example sharp interrupt cells is a property that is defined by a node in a device tree describing an interpret controller so in the example here the first node in c describes an interrupt controller in your system on chip and it says sharp intro cells equal to which means that any device such as the ice crease controller described below which says my interrupt controller is in c and here we see an example of using a label to point to another node in the device tree this pointer and person in c is called a p handle and this is very common in the device tree syntax and then the interrupts property must have two cells here just arbitrary example 1224 because the target of the um of the the pn which is our interrupt controller as specified i need two cells in my interrupt specifiers and this is because the interrupt controller driver will parse these two values 12 24 to find which interrupt is actually used by our ice crescent controller and this goes on and on for sharp clock cells sharp gpio cell sharp 5 cell pwm cells sharp dma cells and so on and so forth so here is an example again with our iscsi controller which has a clock's property pointing with a piano to a clock controller and identified by the clkc label and this clock controller as sharp clock cells three which means that it needs three additional cells to describe which clock is actually going to be used and perhaps with some flags here we have just put some added drive value for the example and the values are 12 24 32 which are those three cells are used to identify which clock from that controller we need to use for this ice crc controller another very common pattern in the device stream is the usage of dash names properties for example here you can see an interrupt property and associated to it an interrupt names property and the interrupts property has two entries the first one is zero fifty nine zero and the second one is zero seventy zero and the interrupt names property also has two entries mac rq and mac pmt and those names can then be used by drivers to more easily identify which interrupt is what in the list of interrupt specifiers so for example the driver could do something like platform get rq by name and ask what is the rq called mac rq and the device tree logic in in the kano would automatically find it is 0 59 0. there is another example with clocks which follows exactly the same rule and this is again something we can find for many other properties reg reg names gpio gpio names and so on and so on so this kind of concludes our visit of the device tree as a way of representing non-discoverable hardware it is as we've seen a tree of nodes with nodes having properties there is a standardization of how to describe a specific piece of hardware based on the device tree bindings the device tree is a new description language which has lots of properties and sometimes the bindings are complex but it is no use for numerous cpu architectures widely used in linux and outside of linux as well and it has definitely become a must know for all embedded linux developers i hope this talk will have helped you understand device 3 and if that's not sufficient do not hesitate to contact me thank you you

Channel: Bootlin

Views: 15,313

Keywords:

Id: Nz6aBffv-Ek

Length: 43min 17sec (2597 seconds)

Published: Thu Dec 03 2020