 Good morning. This is the embedded essentials track and we've had a couple of top talks already yesterday Today we have a few more talks to do. Hopefully you can you can stay with us for this after these talks as well this morning we have a talk with by scourpaton on device tree and then we were all also gonna have a talk later on on I squared C and SPI finishing up with some Belunking through hardware schematics and reference manuals, which should be a lot of fun at the end of the day But today we're gonna start with a device tree it's a fundamental part of embedded Linux and Something that every embedded engineer certainly needs to know a little bit about in order to configure a board or write a driver For the Linux kernel and on that note. I'll pass it over to scholar Thank you, John Thank you for attending our talk today I'm gonna be talking about as behind mentioned the device tree and some things that I've learned over the last Six seven eight years, maybe of supporting a device tree So let's go into the next slide here and Here's our agenda. We're gonna we're gonna talk about I'm gonna start off with talking about who I am and what I do and Then we're gonna talk about Linux bring up some suggested practices for on a derivative base board and We're gonna kind of do a quick refresher on boot flow and see how the device tree is used during that flow And then we're going to go into discussing what kind of some major components from a high-level view of looking Now with the device tree files put together and then there's part of a board bring up I want to introduce or if It's already been a topic that's been brought up before but kind of like a hello world concept We always had that that first line of code we wrote and see was hello world Well, I want to kind of and it was you know very elementary So the the DTS file we're talking about is gonna be very elementary We just want to make the board basically boot and so we can prove that the board at least boots Linux and then I'm gonna go through the steps that I've used to create a This so hello world DTS file and then I want to talk about something important why the hello world's important why the hello world important is with the life cycle of the LTS kernel and some of the things I've seen over the last few years of as people are making products for boards and As new kernels come out new features and they want to to upgrade to that kernel and why this this hello world might actually help with that process So let's move on to the so whom I so I've been working with embedded software ti for for 20 plus years Currently a member of the sitara processors Linux applications team And I've been there since the the product line was just created back at about 11 years ago I support Linux general Linux But I can also do a lot of networking support and and is what the topic of this presentation is about board porting On on ti so C's the things I'm talking about today are not going to be specific to ti This is this hello world concept could be used for any Board that's using a DTS far derivative board that's using a DTS file. All right, that doesn't work so the target audience for this presentation is people that are kind of getting introduced to the Linux and also as I mentioned a Embedded system and how the embedded systems are using DTS files with the kernel to kind of define the non-discoverable components that are on the board Anybody who's always been maybe a higher level application was always kind of interested in to know how all these devices become available on the board How an SOC is actually what they call bound to the board? This is again. These are the people. I'm hoping we'll get the most out of this presentation This to kind of kind of give you some guidelines on how this presentation was put together This is about a method that I've kind of been using for the last couple years We're kind of helping other people bring up the kernel on their boards and this is stuff that I've come up with I'm sure there may be a ton of other ways to do it The key thing I always want to talk about is it with this concept of talking about the whole world later We just need the kernel to boot initially. This is getting to that initial prompt So you have some basic control over the board. This is not a Like a whole complete turnkey type type Discussion because that's that in my mind. That's a little too complex And so I'm trying to simplify the problem because a lot of times when you're bringing up a board for the first time there's all kinds of Issues that can come up that they kind of get you in this debate. Is it my DTS file or is it the Is it the Is it my board? Sometimes it's both Now also where I'm an application engineer I've done a little bit for my option quite familiar with the kernel, but I'm not doing this from a From a kernel developers point of view and that's kind of again the target audience is that this is your application person But the stuff I'm talking about will also be kind of critical for anybody who's also going to be you know Eventually has plans to ride device drivers And so when I was putting this presentation together I there's some things I didn't get a chance to go to actually get going into nodes being very specific So again, this is kind of a macro level presentation and kind of showing you how the device trees put together and how You can from a macro level kind of make sure that certain components are in place Again, I've made an assumption that everybody's least heard of what a DTS file is I'm not I will I will go over some of the syntax and kind of point out There's a couple things about appending nodes. That's very important for a person who's bringing up a board But one recommendation is that the that the free electrons group or company has put together a great tutorial presentation That's what I first started looking at and I still go back to it every once in a while but It's a great presentation. I highly encourage you if you haven't seen it to go look at it and now the next topic is a Making a key point here. So this talk is going to be about bringing up a board that's based on another board So and the reason why I'm making that distinction Is that most of the SSE vendors are going to at least put out some kind of evaluation module? And so through that process, they will have they will have done all that hard lifting And we'll explain what some of that hard lifting is of getting a lot of the all that Linux support into place to So that your job is trying to bring up this derivative board shouldn't be as complex as what they had to do to bring up that full full evaluation module that they did and so I said is a derivative board that you're as you're Basing your your your derivative board that you're basing on is going to be from an existing existing board and there's three possible I call it kind of categories that these these boards come from there's the Linux community boards that are Also based on an SSE vendor board But the the first one is the most important is the SSE vendor evaluation module has to be taken It has to be put into place and the reason is that there's a There's a processor include file and we'll get to what that is in a second that defines everything on that part So anything after that evaluation module for that original SSE vendor is going to be a derivative board and Another classification. I've seen over the years is existing Companies that have got several boards that they've designed and as they're basing new designs off their original design And that is usually a life cycle a kernel lifecycle Thing we'll talk about later, but not to keep you in suspense is it usually like parts go out of go out of date And so therefore they have to re-spin the board and when they re-spin the board sometimes they want to say okay there's maybe it's time to upgrade the kernel and You know talk about some more of that later the block diagram on the left is is a big old bone black and and and what I'm trying to represent here is that if you look at the The the processor here in the center You have all these old blocks around the ground each side of the processor and this is basically all the peripherals that you're attaching to the processor And so there's gonna be as I move along. I'll make the distinction between what is the SOC? And then what are the peripherals that you're putting on that board and how the DTS helps you define what you've put on the board and Kind of carry this thought for so if you start off with the big old bone black or any any processor and you want to Change that you decided that for example that okay That's a great design but from what I'm trying to do is I want to add a couple of interfaces and Also, maybe perhaps take away a couple of interfaces because I don't really need them for what I'm trying to do and so in this slide here I'm showing you that okay in this particular example say we want to add another ethernet port or an RJ45 we're gonna be adding a five to go with that and Then a couple of you arts and then then we're gonna take away the HDMI So you've already changed since you've changed Assuming we were doing this design you've changed it to the point where you can't just drop in the previous DTS file so you have to so you probably could and it might work but I've found that sometimes when you just do these minor changes is anything can go wrong And also then the board itself could also have some issues So as we go along we'll talk about how we're gonna come back to this hello world Which is I'm gonna start with a minimal thing and then I'll add in everything else So when you're Looking for an existing design you're gonna make a derivative is that you'll go into the this particular directory here If you can see it's the arch arm boot DTS directory This is where all the 32-bit arm DTS files are down at the bottom I'll show you where the arm where the 64-bit versions are but in that directory in this particular directory here There's like over 2,000 DTS files, and I've only kind of snapshotted the ones that I'm gonna Just a small briefs subset here, and I've kind of mostly based it on the 335x which is coming from the From like this where the beagle bone black is and so you can see that there's There's quite a few quite a few boards here and none of these are not all TI boards. Some of these are community boards and then there's other Like it's people who have based their their design on 335x that put their boards in also So the only way you get access to this is the people who have made this decision when they ported their their board have actually decided to actually mainstream it or mainline it and And since TI's main lines it's it's boards This is why you see the 335x supported, but you see a lot of other people decide that too. That doesn't mean every Any SOC is always gonna find it in there pride the file would get I mean the directory probably get really huge but but these are the board you have to choose from when you're making your derivative design and so that's one of the reasons why you know when the SOC is there you always have that ability to you want to leverage a known working design and So like so there's several board vendors here and this is just a sample of the boards like said in the directory and You always want to start with the DTS file of the reference board that you want to look at and And By starting with a known good and especially boss you don't want to emphasize this also You really need that that platform that you're starting with to kind of help you with your your next design But this is where all the files are stored that you can start with And you can see I actually kind of snapshot a directory that actually has both the The DTS files and actually the compiled versions, which are the DTB file. All right So if you're going to start with your to make your new DTS board How do you start and like I was mentioning if you copy the board exactly then there's probably no reason to To do that, but you know for argument's sake you could just drop that that reference DTS file into your new design You want to completely start over No, you don't because you always want to leverage what's there and Say you're gonna start with a DTS version of the reference board that you're driving from and This is the so this is a this is a just a snapshot of it And this is a very simple. This is not a full DTS file But what I want to highlight here is this processor dot DTS file So this usually this is the file that leads off a DTS file You can actually also say that you can actually reference a DTS file here That would eventually come back and still reference a processor DTS I file in this processor DTS I file Which I'll go into a little more details is basically defining everything that's inside the SoC and why that and why that's critical Or not so much critical, but it's done for you as a derivative developer So what are the reasons for developing a hello world DTS versus a full board DTS? As I got to mention it's a mention before you can get to this when you're developing you're debugging a board when you're bringing it up you can get into this is it the board or is it my DTS file and The reason why I say that is it sometimes a simple Semantic error inside your DTS file will actually cause the board the kernel of crash as it boots because the kernel won't be able to parse the The DTS file correctly So therefore by that you want to make sure you to reduce the challenge You want to get to a small minimal set that just boots the board You're not trying to bring everything up in my opinion at this point You just want you really just need a console or root file system then the memory and the kernel to actually be loaded in the memory By going with the minimal interface set if you can get to that Once you can get to a prompt then there's all the utilities within Linux that allows you to kind of kind of debug interface so for example say you're having Like blackberry say you're having ethernet trouble If you can get to a prompt in you've got the ethernet node in the DTS file You could you know start using some of the if config you know each tool Utilities to try and help you kind of find things also that what's going wrong You can also use like five tool to maybe talk to the five to see for example What's going on with the five and that's usually when you're at that level That's when you're trying to debug something on the board So by getting to that again to getting that base prompt you can you can use leverage all those utilities To be able to find out that you can really run something kind of diagnostic on the board at the Linux level That might help you with trying to understand what's going on with some other part that's getting some kind of hardware conflict or issue Debugging a DTS is that is not mentally correct is a pain and There may be some other techniques, but usually that's is why again I might have talked about the lower level point out why is it again if you just miss you know if you You miss the hierarchy just a little bit and It could cause all kinds of problems So if you start with a really small DTS file around the full-blown reference one You you I think will alleviate a lot of pain as you bring up a board And then the other reason is um, you know again, I'll highlight this several times is that upgrading kernels will be easier with a minimal base DTS and The reason isn't I'll point out later is this processor DTS I file that I mentioned is the most likely file that's going to be changing the most and It could just be one release two releases but a lot of times say for example people are maybe in two years they decided they want to upgrade the kernel and That DTS file will no longer even compile under that new new kernel version probably or if it does compile it could be you know That could be some kind of hidden Semantic error that I've seen Before that things didn't line up correctly anymore inside the inside the DTS file So as I was mentioning it, what is initial success? So When I've been bringing up boards or with working with people bringing up their boards We want to get to that prompt because once we get to that prompt means we have a working kernel We have access to the to the file system. We have access to all the perhaps all the other utilities We can use to kind of help us and also it's it's always good to be able to get to a baseline So once you get to that prompt you've got a baseline saying hey I've got I can actually use the kernel to help with additional debug features and to get to that prompt you're going to need a kernel and the the new custom DTB for your your derived board and a root file system and in obviously a UR console and So not all the peripherals have to be enabled. So if you're you've got like six URs You really only need that one for that console and you can bring them in individually or say you're having trouble with an I squared C device You don't have to bring in all the I squared C at once is it that you can kind of add all these things iterably and that's again, I want to Highlight is during a board bring up typically it's I always think it's a good idea to kind of do these things in an iterative fashion And that way you're just working on one interface rather than this whole, you know, you know huge one complete All entitled full entitlement type DTS you will I think you'll be able to be a lot more efficient by doing it One piece at a time it might seem a little bit slow, but this is something I've found has been Very helpful So a quick review of bootings that we need to talk about how the kernel of DTP get together Is as part of this talk I think I mentioned again probably as it we're expecting a bootloader of some kind So typically you boots used and so this is kind of a this is a very generic boot flow diagram So you have a you when the part comes up the SOC the ROM is going to run And then sometimes there's going to be there's going to be a secondary program loader that gets loaded Which is and then then you boot and use those two images both come out of the you boot source tree And then finally you boot loads the kernel and it's also going to load a DTS file and And to kind of kind of highlight again the the elements we need to for the board to boot is We have a well the processor and so see and we've got all these peripherals that we want to have on our new drive board And for that we're going to have to have a working bootloader and that working bootloader is already taking care of setting up Some basic system functionality such as we're expecting the DDR to already be set up and And basically some clocks and maybe a little bit of power So that the processor boots a particular performance point that I guess allows it to boot quickly But again, those things are those are the responsibilities of view boot Then we need a Linux kernel One thing here is like a lot of I might say you have you can build the kernel But a lot of maybe it perhaps SDKs that come with these evaluation boards. They provide a kernel I would just recommend using that base kernel that comes with the SDK that you get with the board there So see that you're working with and then also just use a root file system. Hopefully it's not too big Or they've got varying sizes And then back to what I'm talking about the board DTB, this is your custom board DTB that you've done So with these with these elements is what we're trying to do a minimal boot on the board so the So what's the the board state? Okay, so once the boot loader sits I guess I'm gonna get a little more details about the boot state or What the boot loader has left the processor and is Linux is gonna come up and boot and Works actually we're expecting a boot loader The UBoot has been ported to the board and run and set up a minimal configuration and as I was mentioning before the DDR is being configured and in a performance point and So the boot loader then loads the kernel image and board DTB to the DDR In typically, I mean well, I shouldn't say typically this the kernel can come from whatever persistent storage you're doing A lot of the like the Beagle bones probably use they all use You have in a micro SD card that you can use or you can use the onboard MMC or well again, I'm sorry. That's the board itself your new design. Maybe something else but as a I would add It'd be nice if you had a at least an SD card For your some of your initial work because that might help with some initial bring up Because if you're doing like network boot right off the bat I found that that can be kind of challenging because one of the biggest issues when you're putting a network boot in Is making sure you get that five to Mac? Relationship working and When you get to the higher speed fives this usually becomes sometimes problematic because layout comes into play Strapping of the five comes into play and those Those have usually we've had some headaches with that So that's why I recommend maybe an SDK excuse me an SD card or maybe some kind of persistent storage I haven't really tried USB that way, but that's why I tend to I think most designs tend to use SD card Further initial bring up and so when you're So is what what you do does it's going to put the the kernel in the memory along with the new custom DTB file for your new drive board and There's a kernel boot. It's going to consume that DTB file So it gets it'll override it, but it'll have pulled it into the kernel into this tree that you can then look through the proc You can look through using cat proc. You can look at the device tree to make sure you're certain elements ended up in the right place So for an official definition In this case, we'll use the DTS binds Linux to the board and this is the definition here comes from From from Wikipedia and The big highlight is that sometimes there's been some confusion that people think that that the DTB code itself Which is the compile version DTS Is actually executed. It's not it's just it's just a big block of metadata that describes components on the board and the processor The whole system itself. It is not executable At least my knowledge is not It's just again metadata and what that device tree is doing just to kind of I guess belabor the point a little bit Is it's going around and looking like all the blocks here for like the USB host the emmc the micro SD card Not the J tag, but there's going to be in this particular instance There's going to be a processor DTS I file and then there's going to be in a specific node in the DTS file saying okay I'm actually going to use This ethernet interface or I'm actually going to use this HD or this HDMI port where I'm going to use this micro SD so that Inside the DTS file and you know how it is it's defining all the nodes But not all of them are enabled So the DTS file's job is to enable each of these interfaces and we'll highlight that again here in just a bit So sure to drive a new board Based on the existing board is that again, we're going to start off and And this is for this example here. I'm kind of showing How a reference board looks as you'll see this processor DTS file Which again defines the processor and all the peripherals are inside the processor need to be bound to the peripherals on the board And you'll see sometimes a lot of times when people are making common designs they'll start adding these additional DTS file DTS I files or include files that Allow them to kind of make their design more efficient in using TI's cases that we had Even the beable black but also a different processor the 57 class there would be varying levels of these include files to kind of consolidate How to make the development work that much easier for the I guess the vendor but maybe a little more complicated for you as the developer and I'll point it out is that this is again when you see this This is typically the SoC vendor trying to make their process a little bit more efficient But you as a developer sometimes this becomes a little bit more complicated because your design may not follow the design that you're referencing on the SoC platform so be aware that you may be consolidating yourself and again That's why I'm also coming back to I'm gonna keep harping about the hello world design. I'm gonna talk about is it With you with your specific derived board is that you don't probably need these these different include files Is it be that's way best to start with a minimal one and then add in the peripherals as you see as you for your board But anyway, so this is the the DTS file DTS file and there's a Couple things to point out so that you be it could be several these include files We're including all these different dot DTS files or even other DTS files by the way And then you'll have to start off with a root node and this is with the root symbol here And you'll start for the model and this is where you put in your new name saying board-based design We'll just call it X1 and then there'll be some more Root level nodes that you might have in and then we'll talk a little bit more about some of the Those beyond that that's kind of a real basic structure that I'm trying to highlight here Is that there's going to be a processor DTS file? That's the most important when you need to include and then you'll be having to To rearrange these ones to to maybe make yours a little bit more simpler. All right So to highlight again not to go more specifically how the processor DTS I file that typically works And again, I'll state this and I'll state it several times This is a file that you as a developer or board developer should not not be touching This is the this is the people the maintainers of the SoC. This is their main Vehicle for describing the processor Anything you need to do to modify the data that's in that include file you can do inside the DTS file and I'll point that out reason why I say that is that I've seen a lot of users make modifications here because it was just simpler but Then as their project took, you know, maybe two years to come them to be to completion And they needed to pick up different kernels that this file usually If you've modified this file you're having to deal with the changes got modified But actually taking your changes back out and trying to merge them. So it becomes kind of an upgrade nightmare So again, don't touch this file. You can always change anything in a file. There's nothing you can't change outside the file And and they kind of highlight what the processor DTSI file is is it it's gone through there's a node or an entry in this file That describes everything that you see in a block diagram for the SoC So all these different peripherals are going to have equivalent Equivalent representation in that DTS file or nodes as they like to call it So any any proof you won't think of it. So it's going to be defined there and when you Typically you will get they call full processor entitlement when all these nodes are defined within this DTSI file I can't speak for other vendors, but for example T. I list we We try to we do get everything defined in there and then that way it becomes Once you have this kind of like the definition of the processor So now you have the definition of processor you can actually decide which peripherals you're going to actually enable on your particular board and so So now I want to talk about some of the how the DTSI file is represented in the file because this is kind of important because what I'm trying to to get across here is that Is it a lot of times when people are starting out with Trying to do a board port with DTS file. They're thinking where do I need to how much work do I need to do and So you're thinking okay, I'm leveraging a lot of the board I mean is there anything additional and they do and and so what I'm going to try to explain is how the File is kind of put together and how use this board developer would need it with which where you need to pay attention So the first thing within the the DTSI file is going to be definition of the processor that's being used in the SOC and Then the next one is that so let me let me go back one second here So this again this most vendors writer or licensing this this this arm core or whatever processor core they're using So this is something they're going to be getting from they're typically licensing And then here the SOC vendor. This is where they're adding in their differentiation They're adding in all these different modules of the type of SSC. They're trying to put together and so As I was mentioning before so each of these modules will then have a representation in that DTSI file and these ones will be specific to the To the processor and also to be things like for example the interconnects and the clocking all it all the information that interrupts and These are all things that you can abstract out as a board As a board developer this these things are all going to be taken care of for you these The only thing you're going to be having to do is when you get to the next stage is this one here of Saying okay, I want to have a ethernet So you're basically say I'm gonna I'm gonna add in the last little couple of steps or things I needed to find that binds that processor to the board and And And so for each of it like as you can see there's several peripherals within this block diagram We're not this particular board design isn't going to use all of them So we're not going to be using completely mean while the processor DTSI defines everything There's only these peripherals that we're trying to use that need to be defined in the DTS file And we'll we'll go into a little more how that works But I want to highlight again here that there's there's three things here that there's the processor architecture There's the SoC portion and Then the board binding this is the part here that Use the board developer will be need to be concentrating on there's not going to be I mean Again, you're just doing this last little step So this is where I was this benching before is that you're not doing a complete board design Everything's derivative here and the derivative bit that you're doing is going to be just that last bit of saying okay I'm using this particular interface and I just need to enable it and like this you are and I'm using Which you aren't you're using maybe say there's say there's six of them. You're only going to use one There's multiple I squared C. You're only going to use one of the buses and and so you're use the board developer only having to turn on these particular interfaces in the DTS file So to kind of highlight that process is we're as you the board developer has to be you know have to be concerned is That just taking any IP for example, there's going to be internal things that are necessary like where am I getting my clocks There's a bunch of other interrupts that we need to set up and and so there's going to be a lot of stuff They're very specific to the processor. This is what's going on This red box here is being kind of represented by what the processor DTS I file is It's only when you're having to actually put it on a board this blue blocks is representing the bit of information that you as the board developer have to provide and But to take into a call count when it comes time to execute this on a board These both have to be the fine. You have to have both both of these Every single has to be accounted for it's going to make that particular interface work that in this particular mode that you want and And as you as a board board developer or a board developer Do you have to identify all these settings? No, not that's kind of what my point here Is that a lot of the stuff is already taken care of for you a lot of Basic overhead is done inside the DTS I file Sometimes like you know point out I know I've mentioned that you'll have you can always rewrite stuff that's in the DTS I file but first There's going to be certain things that you'll see as you're defined the board There's only those couple of things that you need to worry about and kind of to come back to that That approach I'm talking about so in terms of the components of a DTS file You've got is you as you're defining your derivative DTS file You're going to have that processor DTS I file, which is this one here is a m3 3xx in this particular case You'll whatever derivative board you'll you'll find is that I wish I had a Better way of telling you other than the fact of just looking inside it the DTS I file that and you had to look through several of them Sometimes depending upon the SSC vendor You'll see a thing when they start to find the processor and basic thing like that's going to be the processor DTS I and a lot of the different nodes But I want to highlight again. This is the from a DTS perspective There's going to be arch specific things with there's nothing really here It's mostly contained here in the SSC side of the Thing so again, there's the SSC component, which is what the SSC vendor provides So this is inside the DTS I file in this case There's several other include files, but these are things you don't again typically have to worry about you're mostly worried about What do I have to do to enable it with my DTS file in this particular example? There's actually a third one now. That's down here, but But as you write your DTS file, then there's I was mentioning sometimes there's an include file That's used to kind of consolidate designs. The reason why that's here is that there's a couple different beagle bones There's a big a bone white and a big a bone Black, but there's also those two are kind of related in design. I know there's several of different colors like green and blue but they're based on Just the using this as their processor DTS I found they may use I've got through all of them They might use some of the things from this phone common DTS I file But in the end when you when you have a complete DTS file You've got your arch Architecture SSC and your board to find and every signal counted for that you need on each on each interface Alright, so let's talk about the hello world DTS file So I think I already I think I already kind of this slide looks like it's Looks like maybe kind of redundant Get a board DTS file is going to be as I'm mentioning it's going to have you're going to find the nodes that you need for the SSC application that you're trying to do Against just the data structure as you put together DTS file so This is the hello world concept that I've been talking about so like I mentioned For is that we have the main we all recognize this from from it for see see program Is you have your hello world and you simply do a print up say hello world? So it's that really simple simple approach a lot of times when a lot of people are doing a lot of simple embedded stuff They if the sooner you can blink an LED sometimes that really you know says volumes I know it's very simple, but people really like that first stage Okay, can I get it to work? Can I get it to do something and it can I get it to boot? And that's what the hello world is trying to do here So in this particular case for the For our hello world, we only need memory A micro SD card and a header for the you are I put power in there in case I needed it in this particular case. I didn't I didn't need it but with these three things I can boot the kernel to a point where I can actually start adding more components or more peripherals to it and And so the basic structures I want to take the The processor DTSI file and then I'll just and I'm gonna make I'm gonna call it my hello world This is my model that goes into the device tree I'm gonna call it my hello world model and then I'll add the nodes in again. This is this is extremely simplistic I'm just trying to show you there's just a few components that we're using here to get a kind of get to that prompt that we really want that basic starting point and And so as you would once you got to this point, then you would just keep adding these nodes like okay If you want a second MMC or a second you are or ethernet you'd add an emack These are you would just keep adding these these nodes to kind of iteratively bring up your board But this is where we're just trying to we're just trying to get to that in this particular example Just trying to get to that prompt and so we're going back to the block diagram here What so I'm only gonna be binding three peripherals to the board or you are An SD card and the DDR and the DDR we already expect because you've already programmed it but we are passing some parameters about the memory in the DTS file and So How we got this is now I want to talk about how you construct this DTS file So I'm going to take this existing reference design and I've kind of again kind of genericized it so I've got a Processor DTS I file again. That's a key processor definition Then there may be in the reference design. I've got as you have several include files that They don't really match this new design that I'm going to be working on but to kind of so I have to Go through some of these and figure out which ones I need but again, I'm just trying to get to a minimum once the most of this stuff will be about cutting these out and then I Should have left this as original processor design, but you'll see like there's a lot of these nodes that are defined so we're going to take this Existing reference the board DTS and we're going to cut it down to a to a simpler hello world DTS and And and so we're just going to be in this particular example we're just going to have just two peripherals enabled the you are and the MMC and and And we're so we're going to leverage the DTS file to get there so we're not writing the DTS from scratch I guess you could if you wanted to but it's a lot easier just to kind of reduce what's there So before we start modifying experiment experimenting with the The the existing reference design I want to kind of cover real quick I'm how you build the DTV file so in this Typically, I mean When you have the the kernel make system, it's going to have that make target for DTVs and So this particular case I've already added and I'll show you how I added this But we want to build the DTVs and it's going to and we've added our DTV file in this case We call the hello world and you'll see some maybe some other call of Compiler tool calls is just building the DTC file or the DTV file and So that's how you build it and this is a really important debug tip Is how do you uncompile or disassemble a DTS file? And we want to highlight this is that talk with some fellow developers and they they kind of agree This is that sometimes when you're adding stuff into these Really complex DTS files where I was telling what I mean by complex there's like several these include files that They overlap and sometimes it's kind of hard to keep track Of where certain nodes got appended and so Why I'm bringing this up here is if you ever get stuck. It's always this is how you would disassemble you would call it the DTC compiler from the From the current in the directory that you run in the kernel And then this dash I was saying I want to output the DTS and then your little dash little though is being saying This is the name of my DTS file and it will take this DTV file and it will disassemble it And so why why that's helpful is that you can then see Again, it'll be a very long file But you can then go through and you can account for all your nodes And if you have any kind of a nesting issue sometimes or you overwrote something And to kind of give a real simple example what I mean by overwrite Is that um Say you set the status to okay, but then you decided you Didn't want to that's made that a good example Maybe another one of these you you set like a file address wrong And you and you enter the node again and it get set the file address again now It's incorrect or you set it correctly and then you then you then you set it incorrectly So what happens is is when the DTC compiler is going through or Compiling your DTS It's going to take the last thing it finds and that's what's going to end up in the In your DTV file. So what that means if you've done multiple Like definitions and I'll show you what I mean by that in here so we talk about no dependent no depending You'll see that sometimes you know you could you could do several And it's going to take the last one And that that's where usually you can run into problems So when you're adding your file to your Your you can so you can you can build it with that DTBS command on the kernel When you're making use the kernel toolchain Is that you would go into the make file And when I highlight where the make file is it's in the arch arm boot DTS directory And you would add your file down here. I just put it at the end You could put it in here anywhere you wanted But the key thing is you if it's going to be If you don't you when you're when you're building you're building for a particular processor, right? So in this case, we're building AM 3 3 XX so whatever process you're building your DTB has to be in that same Config area where all the other DTBS are for that particular SOC and So all right, so if you are building your board and you don't push it mainline This is a change you'll have to do every time there's a kernel upgrade. So Just be aware of that but I think a lot of people are just I'm sure there's way more boards in what's on mainline but But that's where that's where you put it So where's the DTB file stored? So in this particular example, I was telling you This is where we're using an SD card for the root file system. So uboot will read It will load the kernel with the DTB file So in this particular case, you see this is the this is a this is we're looking at the boot directory on the SD card that I was using and the You'll see that there's several DTB files And and the reason there's several DTB files for one reason is that on boards that are using TI processors And this is I think true for some other vendors There's a there's an e-prom that goes on the board That allows you to have a single kernel binary and then you can you can select based on a value That's in the e-prom the DTB file that goes with that board and So that's that's where you would put your DTB file in your boot load again This is going to be an exercise of the boot loader The boot loader is the one that has to read both the kernel and the DTB file and put it in memory and then pass that to the kernel as it boots But in this particular example, I was just going to show you a little trick that I was doing because I was being I didn't want to have to go change my uboot settings I knew that I was doing a lot of this development for this presentation on the beagle bone black So I want to highlight what I did was is I have I copied in my I think you can see it because I can't highlight there's a hello world Here down towards the bottom. You can see that's the file. That's 30 31k roughly and then you can look up higher in the list And you can see the the actual beagle bone black DTB file and it's got the same date So what I was doing here was is I was trying to give myself the option of being Being a little bit lazy so I can I can leverage The uboot without having to make any changes while I'm testing my DTB file So this is how you might want to do this with your if you're doing this on And you have a similar setup Whether you be a problem or not. This is how I develop I would recommend developing your whole world is on your existing reference design You can you can cut your file down to this this base minimum Using that board and and using the uboot that goes with it Okay, so now we're going to talk some of the techniques I use to kind of kind of consolidate into a single hello world file So going into this is the this is the top level DTS file thing for for beagle bone black and there's two Two to include files and this is where this says there's a bone black common. There's a bone common and a lot of this information there since I'm only wanting to bring up those the I only want to bring up the root file system Which on an sd card and all I want to have a console with you aren't so a lot of these things are in here Are are going to be redundant. I mean, well not redundant. They're not there's a purple list. I don't need them right now So I could But I don't know if there's some other information in there So when I'm going to show you this is it sometimes there might be some other information in there That's kind of critical to the boot That you don't know about so you have to kind of go through these because you don't really know I mean you could go through the code, but to me it was just faster to kind of go through the code and start commenting out Certain certain areas and seeing how that would if it wouldn't boot after that So like in this particular example here So I would I've already started in the dts file. I said, I didn't think I wanted anything to do with the opp table Because that's kind of a higher level once I'm into the kernel Again, this is a little bit experience of my part. I admit But you can pick any node and just put this if zero around it or do the regular c comments and just Comment out that node and see if it even compiles And then we'll after compiles and you want to see if it runs And so I would iteratively do this for all the elements that were in these two these two include files And so for me again, I'm kind of familiar with it. It took maybe a little bit less than about 40 I didn't take that long it took 30 to 40 minutes and I'm being I'm being a little bit generous on the time because probably doesn't mean I take that long Just depends on how fast you want to comment out things and then rebuild it and get it loaded And this is more examples of kind of showing elements that I don't really care about at the moment So I would just comment them out And then and then see if it would boot this one though was kind of critical since this was the mmc and I need to define power for my mmc card And so the one question you might have right now I kind of answer is how do you know you need mmc? So we'll talk about device tree binding files. There's going to be required elements and So there's two ways you can read through every binding document and see what's required or you can just kind of You know experiment with uh with a dts file and just start cutting things out until it's quit working That's kind of what I did here. I've heard of people talking about that just just kind of I'll tell you anyway So if you keep going here is it uh, you see this next note down here I didn't I didn't highlight but there's an f-serial so like this mmc2 Which is i'm not even going to use that note. So I just commented it out So I just needed one mmc interface for my root file system And uh, and I need to make sure that power to it Again, I want to highlight the process as an iterative There'll be a few times that when you when you cut something else like say for example If you were to cut out this mmc interface you would find that okay It would hang when it was trying to mount the root file system That would be the x that's the that's what would happen here if you didn't have been this uh this um This power supply definition So how does that um kind of look when I when I got done? So as you can see here now, I've only got the include, you know, I'm going to go into this a little more detail So I don't think you have to I'm going to go through each step, but I'm going to kind of step through the Highlights here is it so now you saw we had like three include files before now We're just down to the one which is the process processor include file And then we're just defining the memory we have on the board This chosen is an important thing for um, this is the you have to tell the kernel Which one's going to be your standard out and we're going to say you are at zero with that And then we have the voltage regulator that was mentioning before this is critical. So otherwise you can't mount the uh the sd card They won't actually won't enable so you couldn't so you couldn't mount it and then there's um Some vendors have requirements to guys one about you having pinbox So we have variable pinbox that allow you to Select based on how you want to lay out your board perhaps It gives you advantage of being able to select different pins for different different peripherals And so on this particular part we have to make sure that we've got the pinbox lined up Otherwise the ip won't be connected to the pin And then continue on this is the additional more pinbox for the um for the mc For the mmc interface, which is sd card and then this is the The the uart nodes. This is where we're just we're going to turn on uart zero and mmc one now want to highlight Back in that diagram where I had the blue and the red boxes Is that there's a whole lot more signals that are required while signals are definitions that are required for your uart to work But you as a board developer only have to do these two or three signal three lines here And so what we're telling it is that we have to tell which uh Pin control we're using and which set of pins we're using and then finally the status. Okay. This is the main thing for any dts, right? until You set the device to our status to okay that that peripheral is not going to work So in the dtsi file that's defined for the processor every node every excuse me every peripheral node Is always going to be set to disabled And as you're bringing your board up this you just need to turn on the ones you're using And then down here for the mmc is that This is all you need even though there's several more required Fields that need to be filled out for the node. These are the only ones you need to do to bind it to the board So you're just looking for a status and this in this particular case since we're using a micro card. We're using four Four pins and i'm kind of getting going a little bit more detail here in a second I think because I think it broke this down by interface so Kind of again step through this in an order of how you can look at the file So first thing in your file. This is true for every dts file as you're saying which version of dts you're using And then This is the key part want to make sure you have your arch s of c abstraction file this is where your processor include file goes and And without this right you don't have a board And then this is when we're breaking down so now we're defying the root node And as i've mentioned before we have we've defined our model on They are our hello world board and then the compatible field These are really important Especially we'll talk more down here at the uh in the in the device nodes here Um, and then how much member using again that you are so let's talk about Some of the fields here. So like the compatible field here is really critical And that uh, whatever node you're putting in here, or this is also true for load nodes, but this in this particular case We're saying this is a regulator fixed Um, again, i'm leveraging the existing board design here. I didn't have to figure this out um since there is a You know a lot of times you can do that, but here say when we're talking about power for example You have to be you know leverage what's there, but also be aware of what you're doing Um, so in this particular case we're saying that the card only is going to have 3.3 volts for a for a min and a max If you had different cards with different speeds these things would probably change But again, you can leverage A lot of existing designs Um, like so c vendors again when you're looking at how they define the nodes again, you want to leverage that It's good to be looking at the device tree bindings file, which we'll get to in a second But again leverage I would just want to highlight leverage what's there and that's all I did in this particular case And I just took this definition that was already there for the big of bone black Because my new design are my new this new board i'm trying to do would be exactly like that for the most part And um, so let me talk a little more about pinmux so you can appreciate what i'm going to show you next in the Why why the pins are defined that way? Um, so as mentioned earlier a lot of socs have um You have have Some of them have the ability to you know route different signals to the pins based on how they want to lay out things on the board Um in this particular example, this is coming out of the data sheet Is it I know i'm saying i'm trying to set up a can bus and this particular pin is j I think it was j18 I want to make sure that it's lined in With my uh with my decan ip that's inside the soc And so with these different modes um mode one Is what turns on the uh can bus to this pin if I made a mistake And say I left it is zero then i'd be talking to my um I guess an mi port would be uh tx 30 line three would be coming out to this pin Which is not going to be a can bus So when you're bringing up a board and you have to worry about pinmux make sure this is a this is also a big um Big problem because this is where a lot of derivative designs would be changing Is that you might be using the peripherals just a little bit different So you want to make sure you're just not cutting pasting directly from that dts derivative file Reference file into your new file if you've made any kind of changes like this. So be aware of Be aware of pinmux okay um So going into this this bit here again kind of talking about more about more pinmux so that so coming from This particular image now we have to enter this into a dts file um A lot of I guess I don't know about other vendors, but there is a there is a tool that you can use to kind of help with this Is that you would enter the The pins that you're trying to use for a particular interface would be a pinmux tool Uh, I think I think it's something called systems config tool now But hopefully there's a tool like that So you as a developer are not having to go through and figure out all these lines because these are This can be if you if you get a direction wrong or a mux mode wrong Like I was telling you or a pull up a pull down wrong that can impact your your Your setup So hopefully if there's a tool there make sure you leverage the tool To kind of output this information that you can include as either include file for your new board Or that you can just cut and paste directly and drop into your dts file but um So devices that have pinmux requirements be be aware of that and hopefully rely on whatever tools they provide for you um So moving on to the nodes themselves I want to highlight is that um, like I was saying before is that there's just a there's just a few lines You need to do to add the board and make it active and This ampersand here at the beginning It's critical to making sure you're this is what you call you're appending to a node so We'll go a little bit more detail about the ur but ur at zero There's already one defined in the dtsi file So you want to say okay? I just want to tell I want to actually turn it on But I need to also tell it which pins it's going to be using for its interface And so you're passing these things and uh, so that when the driver's coming up it will then reference this particular Entry in the node so When we get to the uh, and I get to the full blown disassembled version, I'll show you just how the the nodes kind of processed Um But as we're saying we're sort of showing the ur at zero and mc1 Again, these are specific names that we're trying to bring up. So as you saw kind of going through this We're again turning on the interface with the status. Okay We're saying we're going to use a four bit Bus with here and then we're saying which pins I want you to use for this interface And then when there's a car detect pin we need to add in and the direction or the active this if it's low or high And then I also have to give This uh, basically the power supply is going to be used for the m of c interface Again highlighting it's like for example, if you uh Just to kind of give an example if you if you don't this is a required property If you don't know get on explain what required properties aren't second. If that's not there Then you'll see it's like the board. I mean the board will hang as it tries to mount its root file system But you'd see a whole bunch of other things Because you are it's working. So that's kind of a Well, it's nice things about it sometimes with again with this minimal whole world you can debug it And it is Well, that's for just a uart And I want to highlight again that Do not make these changes in the processor DTSI file you could but don't because of for up gay reasons and At least at least that's my personal opinion. I think I think people you know you want to do it That's probably fine. But if you want to upgrade later, you'll you're gonna be it's gonna be a little bit of a headache um So what um, okay, it looks like This slide got repeated Oh, okay, this is I'm sorry All right, so the uh, this is again, this is the bit that we put in our whole world file here This uart zero. This is all we needed to do to turn on the device but When it gets compiled and gets processed and read by the serial driver If this is what the serial driver is going to see it's going to see this data structure with all this This information in it They use the board board developer only necessary to fill out this bit The rest of this information came from the DTSI file and um So we'll step through a couple of nodes so as the driver is coming up It's going to look at this compatible field to make sure that the driver is aligned with this particular node Uh, and some of this stuff is going to be very specific to the driver as you as a board board developer Don't really need to know about Because this is like internal driver information like this ti hardware mods this clock frequency There's a couple of registers. This is the register start The interrupts that we're using for in terms like you don't have to know which interrupt you have to worry about for the for the for the uart you can if you want to but This is just to help you try to come up to speed quickly on your design As As you as your drive as you mature working on more and more dts file some of this information may become more important to you The dma channels that are going to be used the dma names and then finally this is the pin control name So we look at just kind of highlight the stuff that you as a board developer had to define These are the only two things that are showing up in that particular Um, for this particular node now, let me point out something else here So if you were to look through the dts file, I didn't point out something here As we're doing this slide is that see how this is uart zero and then you'll see this is serial at this particular base address um While i'm highlighting this is this is an alias And in the dtsi file. It's ali. It's aliasing uart zero to this interface So just so you're aware of how that works So this is the uart binding doc. So this is the This is in the one highlight where it's at. So i'll just go to the next slide It's in the kernel directory And in the documentation directory by street binding serial omap and it's omap underscore serial dot text and um Um And you'll see like we saw before we saw that compatible fields And if you looked at we let's go back. I guess two slides kind of highlight here See this compatible am three three five two uart and ti and there's one called omap three dash uart and that is Well, it's kind of like we're showing here, but uh, that's where the omap three uart So this compatible fields really is important. But again, these are These are things that are taken care of inside the dtsi file You don't have to worry about this But if you're trying to understand when you look at a bindings document It's you need to look at that unassembled node That was just showing you because all this information needs to be there And then what I was also mentioning before like there's what they call required properties And then there's optional properties and um You can see that some of the nodes that we're using are optional Or excuse me field field names are optional And then there's additional optional ones you can use and these are like for example if you're implementing particular like like rs45 or Or additional type how you're implementing the rs45 But this is an important document and this is and this is not just for the obviously for the uarts This is for all the peripherals that are defined in the soc And you can always Kind of by looking in your reference board you can kind of look at the compatible field here If you want to if you're not if you're not finding this particular Text file, I always recommend taking the compatible field here and then doing a grep on this directory Oh, hold on just a second apologies for that All right next so how do we know our hello world file work? so here's a copy of the outs of the console output and And I want to highlight first is let's see if I did this no I didn't highlight it Okay, all right. I guess I did so this is the start of our our Our kernel output so the first thing you want to look at or obviously this is your the kernel that you've got built And but you're looking for is that your your hello world machine model name worked So What I mean by that that's our new dts file So you want to make sure that you're actually using your dts file that you created so look at the model name there And that that gives you a good indication. Okay. I'm using the dtb file or dts file that I created for my board And then I want to see if the information I've got for the For the mc's working correctly And so i'm copying out you'll see certain information like like for example got the cd GPIO which is coming out of our field here So these are you can look through the dts file and make sure you can kind of see some of these clues The biggest one is is that when you say the status. Okay, then you should start seeing this interface come up like the the mmc interface And then obviously it finds the card and then it it's going to mount the card Okay, uh, and then finally it got to our our all important prompt. This is what we want to see this is So we just did those three. Uh, those three interfaces getting the Getting the memory in there and getting the the ur and the mmc in there And the pinbox for it and we now have a working processor And this is this is our success point of snowing. Okay, we actually got our hello world file to work And now we can start adding in the rest of our nose to continue our board bring up But this is I would say this is the this is a celebration point here Is that when you get to this it means you've uh, you've gotten past any potential issues like Maybe some power issues or maybe some board issues I'm not saying you won't find them after you bring up other interfaces But this is this is a really huge step And uh, and it gives you a again a baseline that you can start working with continuing to bring the rest of the board up all right, so let me uh talk about um The sd uh, I'll call the sdk lifecycle, but it's actually the the kernel lifecycle And this is something I've picked up over a few years And what we've seen with people who are working on boards is that um, they'll start a process start a board design And they'll be real energetic But then something will come up and they'll that design will get pushed off to the side for up to a couple years maybe And um in that time right the kernel is always marching on new features New new new driver fixes and just all this just continued advancement of the kernel And so with each lts release it's kind of like you know your Your original design you're starting to get further and further behind and um So what people find is that um, especially with dts files is the dts and the processor dts i files are always changing um, but what i'm highlighting this is that um Is that some customers? I shouldn't take out users They will they'll come back and they'll say wow look at these new features I want to take advantage of or there's a couple of kernel really key kernel bug fixes I really need to pick up And just dropping that new kernel in probably isn't going to well kernel is there but the The dts file no longer works with that kernel and then they're back into that same Uh process of having to do almost a complete port And uh, sometimes it's not too bad. It depends upon the interfaces that they're using But i've seen a lot of people can you know get frustrated With having to notice they might have to take a couple of weeks to to redo the the upgrade so my suggestion is with the um Uh, well kind of highlight again the you're always going to have this upgrade port versus backport Typically the the backport I don't think is a good idea because that just seems like that's a whole lot more work than trying to upgrade your dts file No matter how bad the dts file is um But the the upgrade port is it for some reason that seems to be um Uh, a big decision for depending on how complicated it is, but I always recommend Um, I think it's always the always keep moving and keep up with the kernel. I know that sounds Some people they've got it sounds like work. They don't want to have to do but I think it's it's an effort that's really really valuable So let's go to the next kind of slide is to kind of highlight How things can change in so this is looking at um, I kind of snapshot of the dts file for the 335x and um And just the processor include file there was uh, there was just a ton of changes and um, I thought I'd put it down here There was like significant changes like a couple hundred lines were the changes And so this is where I'm saying if you've modified this with your um, with your when you did your derivative board Uh, then you're gonna have to do two things. You're gonna have to you're gonna have to modify your dts file But you're also gonna have to modify you're gonna have to find out everything you did to the dts I file that you were trying to do for your board and either pull in your dts or put it back in the dts I I would again always recommend putting it into the dts file and uh, then moving on would be the next issue is that um, this is where when uh, basically uh, uh users who've got like a large existing design inventory They may have four or five maybe six designs And um, they're trying to okay, they're gonna add a the next design x and they're saying well, maybe it's this time We need to maybe think about upgrading the kernel Because sometimes they'll for for years They'll have multiple designs and one kernel that kernel may be getting to like four or five years old And now there's new features and bug fixes they're trying to pick up And now they're having to do this to all their board in their inventory So this can be kind of a big headache for them for users so um And also there's always the design refresh when certain parts become obsolete or certain parts new parts come online That they may want to take advantage of there may be consolidate designs But if you um, if you've had this if you had your hello world for this design you could um It would allow you to uh, to you know, maybe just At least test the new kernel see if it's going to work in a very basic matter on your board And then you could always again, um, if you want to leverage and upgrade later, you can always do that same iterative approach again And okay, wait, I want to come back and highlight one more thing about this design design inventory here is that as you Oh gosh, the thought escaped me. Okay, maybe I'll come back to it. Maybe during q&a Um, all right. So the q&a I guess session could start now I have one more thing real quick and maybe I'll just do this real, uh, but Um, looks like we have just a little bit of time here I want to get to this point because this is something that has to do with hello world But I want to talk about adding in your root file system into your kernel And this is another tip that we've used quite a bit to help us with board bring up Yeah, if you can't get your root file system or your sd card to work or something like that We may have network you're working or something like that if you can build your root file system in to the kernel That would actually save you another entry in your in your hello world But it actually gives you that key point I was mentioning earlier about getting to a point where you can actually add in The support you need for getting the uh, like particularly helping you debug interfaces so In this particular case to kind of step through it is that uh Yeah, um step through it is that you can just go into the kernel config And you're going to add in you're going to go into general setup and And you're going to go from there, but I want to highlight you you're going to have to have a root file system Some people I guess you could maybe use busybox here That's I've only used that we have a ti as a file system We have what we call a minimal file system that allows us to do that But if you can find access to a file system for the particular sdc that you're working on You want to make sure that the utilities you need are in that in that file system And then you would add it into this line here, which looks a little small And uh, and then you just rebuild the kernel and then once that's done you would have um And this is just an example me putting in a root file system here So the big thing to point out is that your kernel will probably go from more four megabytes to about 20 megabytes And uh, and that will greatly increase the uh amount of um I guess time it takes to download so if you're expecting like maybe a couple seconds This might turn into a 30 second download Uh, or or more depends on the interface that you're using to read the kernel in so um with that, uh, I guess Open up the q&a section I guess the Uh, I guess I got a lot of questions here about asking about whether or not, uh I guess I didn't see these just going along. Um, so I guess going through these Uh, I assume these uh slides would be shared Um, I don't know behind do you do you know? They will be shared Yes, so they will be shared. Uh, in fact, um, uh, they'll be on sketch. They'll also be on the um, On our embedded essentials website and uh, actually also in the elinix wiki In fact, I was gonna grab a copy of them from you at the end if you haven't already uploaded them to uh to uh sketch Okay, having uploaded to them, but I can I can do that where I can I'll get they will be they will be indeed I'll I'll put a link in the um In the questions here, uh as to where they will be Okay, um, so that's that's quite a few questions Uh, in terms of I guess the similar presentations available for download that would be uh um That's gonna be a real common thing Yep. Uh, what was the reference generally is previous? Uh for uh, petazzoni I there's a link in the presentation to the one I was talking about that talks about the free electrons device tree uh tutorial or background or um I forget what the exact name of they call it, but it's a Again, it's a great presentation. They kind of go through lots of different architectures And showing how the device tree goes together for several of these All right, so one question was why is it hard for peripherals to be discoverable like pcie devices in x86? um the uh So again, I'm not a pcie expert. I believe those are discoverable, but things like uh The i-squared c devices they're not discoverable because um, I guess there's not really a protocol for it Uh, you typically that's why you have to know in advance these devices are there same thing with like the st cards Now st cards is kind of interesting in that you have to tell the kernel that the st card is there But then the st Excuse me, then the kernel and the driver will go out and determine. What's the best mode? So once it knows it's there, there's quite a bit of negotiation that happens uh with the st card It's just there's I guess to answer the question in general like A lot it's not so it's I guess that's just the way things were I guess written is that you have to know that you're using an ethernet interface to know that uh and what's out there in terms of like where the fi is and and um And then once it once the kernel knows where the fi is again, there's negotiation with the fi and the driver for the fi driver that kind of um Kind of let you know exactly you know what the modes the fi supports and what they set up the the interface at speeds for I hope that answers that question if they're not, please post again. I can Go into it So the one question is the processor dot dts file is just in this example, right? Sometimes the content will be inside the main dts file. Uh, it could be um the That I'll answer the question from the perspective is that when the ssc vendors are creating their processor dtsi file they Some of they do they're just making abstraction. There's nothing saying that you have to do that I think that's just been a convention that's been established for um Just having abstraction defining everything that's in the the processor and to be able to include it And ideal making the dts file itself a little bit more simpler But there's yeah, there's content could be however you want to put it. Hopefully that answers the question Why satara packages is great for app development I'm not quite sure how to answer that when I was just using that as an example For today's today's talk. I'm sure if you look at the other ssc vendors. They have They have their I mean how they package their Their stk or kernel or how they want they relate I haven't really looked at that To be honest, I was just something saying is I'm assuming I guess I should have said that when you're you're doing an ssc derivative board I'm assuming that you have access to To a kernel tree and it may depend on how the kernels packaged up ti packages as sdk But there's nothing I mean You could just all you really need is a I guess you could go with a mainline kernel and a toolchain and be able to build for the board also, so It's just I was just kind of referencing what ti has done But there's nothing When you're following mainline, which is what I guess in the ti process or a lot of all these ssc vendors are doing There's nothing you could always clone the mainline tree and build everything there Okay, that's the last question. I see is there are any more questions Kind of a little red arrow, but it goes uh, there's there's five pages of questions Oh, oh, okay Yeah, I had the same problem in my talk. Okay. Thank you uh Okay, so don't you think it's easier to get the latest kernel to boot then take similar bards old kernel Usually major release and then upgrade um, let me think about that for a second I'm not sure if I'm following. Um Yes, the latest getting the latest kernel to boot is Is always I would always agree with that Taking the similar bards old kernels and using um Yeah, I Okay I actually okay. I think what you see. I think I understand what you're asking. Um, so this is how you want to upgrade um, sure, I guess it's um the thing I was talking about what I've I've usually done but um You could I don't see why you couldn't do that What is the full form of rbl? Uh, if I have rom boot loader is what I think you're asking It's just uh I'm using that term because I've seen it used a few times. I'm not sure if I may maybe there's a different term to use But that's basically the code that's inside the rom that's figuring out the next stage of boot So if you're once the when the boot rom comes up, it's going to determine Where am I going next it's just going to go to a peripheral to read in an image So if it's going to like a a nand or um, or st card or even like network It's um, basically saying, okay, I'm going to run this particular code inside the rom And that's why I was referring to it as a rom boot loader Uh, that question. Are these going to slide? Yes. They'll be available for download Okay, good question here is uh, yeah I was trying to be generic. Um, is processor dtsi actually named processor dot dtsi Or is it a stand-in for the actual processor example given? aam3c5x.dtsi I can can we grab for processor dtsi and when looking at dts file? No, I was using that as a generic term Whenever you're basing your design on the river board, you'll have to look at existing designs uh, it was existing dts files and be able to extract out the The the processor dtsi file and again, that's assuming that they followed the um This I'll call it for lack of better term and abstraction for defining a processor um I think that's becoming pretty common because of how At least our files seem to be changing So yes, it was it was definitely a just I was using as a stand-in. So it'd be generic And will these slides be available? Yes Uh, what is simple bus? And what is Gosh, I don't know I don't know if I said that or not. Uh, I don't know how to answer that one What is the syntax dts8? Okay, it stands for dts version one And it's basically that's the uh, I guess it's telling the the device tree compiler which uh version of dts that you're using What is the prcm and lcd controller example? That is the power reset controller module um And I was always just trying to highlight that there are uh interconnects with inside the SFC for example, that might be controlling a power and reset for a particular module And that's what prcm is in this particular with the the lcd controller example Hi, is there a complete example of the dts source file? um, I guess what I could do if I could ask bahan is I can I can upload the one that I did in this presentation that you could compile directly Is that possible bahan? Absolutely. Yeah, I know it absolutely is and just you know I'm starting at the end of your list and just because we're going to run out of time I'm trying to answer the questions from behind you'll notice that I've marked a bunch as ignore where there's repeats So if it's grayed out, you can just skip it. Okay Okay, I looked at the github link could not locate. Um, I think that's something that we'll have to All right, let me go to the next page Okay, do you know what's allowed to be put under a root node versus some other node? Uh, that is a great question Um, this is where I'll have to tell you you need to rely on what you find on your base derivative board It's very important that you get the nesting correct inside the root node. Um That's a really good question. Um if uh I would love to say that for a topic of some other time because that has caused me a lot of grief if you don't get the um Uh, the nesting right inside the root node things just don't just don't work They end up in the other parts of the tree and the driver can't find them. So I guess that is really critical Okay, so how do you come up with the pin control single pins? Those are things are defined by the people who defined uh, with I guess the main terms you define the pin control structure for the dts files Um, I don't think that's I think that's anybody who's using pinmux will have to be follow that one That should be excuse me. That should be in the um dts um Bindings document you should be able to find more of the definition on that Okay, does status equals okay being first or last matter? Uh, I'm not sure but I know I think what I know what you're saying is that as soon as you define status equals. Okay that means that device is active And um, it doesn't oh, I so it's structured. No because this is just something that's uh, so long as that flag gets set There's not really a dependency It's my knowledge inside of any dts node They just that information just has to be there because the driver will parse it based on looking particular fields So it does not be first or last. It just has to be set to okay Yes, they can be replaced. Oh, actually, I'm sorry. I'm kind of jumping ahead here So the uh, yeah, I call the dependent they can be replaced. It's basically you're saying you're going to update the ur definition That's probably I probably didn't use that term correctly. So yeah, I agree with that Is it uh, you can be replaced and also not only that you can remove things From that there's actually a removed flag that you can use inside of a when you're using that ampersand symbol Uh, somebody else is talking about for dtb reverse compiling is offering another tool dtx difference Uh, I vaguely heard of that one. Um I'd like to look into that more myself. That's a good question Okay, thank you for the comment great presentation. Are you aware of uh That I'm not sure about I would that was one of the things I was hoping it to kind of maybe kind of spark is that uh About life cycling operations because I think this is a a big Issue for people when they they don't update their their car or their dts files for a couple of years And uh, it would be really great because I've had numerous complaints about it really just really impacts their development process They use something they didn't have they didn't anticipate they would have to do It's typically where that comes into play Or where they try to tell me Oh, I'm not okay. That's what they're saying is I'm I guess I missed that I should look at this thing. I'll look at this uh collaborate. I wasn't aware that about this with lanaro But thanks for that tip. Uh, am I working on? example tutorial page link not at this time, but uh, it probably will because this is a A lot of questions you see a lot of this is experience-based information And it'd be kind of good to kind of help people not have to Uh Tell people with uh, they'll be with her up with their upgrades Do you ever use device tree overlays with the customers you support? Uh, no ti does not But if you look at the community boards, that's a big part of the community boards I I don't really we don't support the community boards too much but um We don't use that's one of the great things about the I'll admit the device tree overlays are actually a pretty important thing Are there differences between what u-boot and lance kernel need in the dts? Uh, that that's a good question Um, these days since the u-boot has moved into the uh driver model a lot of times the dts files are very similar Uh, but there's no guarantee that they are um That one I'd have to reflect on a little bit more. I'm not sure if I can answer that one Is other than the fact that they both use dts files now And uh, they try to make the functionality is the same. I believe Uh, would I suggest any tutorials for new beginners? Um, well, I was hoping that this one would be a good tutorial, but may uh, but I could um, again The thing I would point out is that the free electrons is a good one, but um The I'm trying to think of just remember a lot of the things in the a lot of times you'll see I can see the reason for the question is a lot of stuff You find a device tree is written at the device driver rider level and not really the uh board developer level I wish I mean, I don't have an answer for that one, but I think that's a great I if I can think of someone I'll try and I'll work with behind maybe to kind of post it Uh, could you please talk about the alias a little bit more? Sure. Um the um inside the uh, the um Inside the dts i file is usually a large list They used to be sometimes in the dts to alias. So if like we're seeing like mmc one That's a whole lot easier to to look at in a dts file rather than saying, okay It's serial at this particular address. So they're trying to make the um The whole purpose of the alias is trying to make the dts file a little more readable And not having to know that serial is this particular address is like And the reason why is like for example, you saw that serial is like a hex address You don't know what the order is in terms of I guess you could look at the If you could look at all of them together Okay, all right. It'll be kind of quick here. I've got to get through the messages here But aliases are just a sign to make the dts file a little bit more readable Outside of debugging our use case for ram s is desired. Um, I think that's a system design decision I like the uh, the root file system built in the kernel just kind of is nice, but um But I've seen I've seen use cases where people wanted to use that just got to remember you can't really store it off Uh Does dts going to be updated on the fly? Uh, not to my knowledge. It's a boot. It's a one-time boot as a process as the kernel reads in the dtb That's it. It doesn't get uh, it can't you can't be updated uh, you could probably Edit the the entries in the field But I think you have to be careful about if you're loading drivers. Again, that's a good question It might be I don't want to tell you no I just know when the dtb is read in it then it goes into the dt file So I guess excuse me the kernel device tree you probably could But I don't I haven't really done that um How to proceed when we are designing dts from scratch removal of unwanted part of it already Uh, well the the I well I guess they answer the question about uh, designing from scratch is that this this was about Leveraging if you're doing a unless you're doing an s o c bring up then that then you're doing it from scratch I would say you're always doing a derivative work based on any Um s o c that already exists if you're bringing up a new s o c then yes You're gonna have to develop from scratch And uh, that's the only time I would see it wouldn't work Uh, what probing hardware do you recommend? That's a really involved question. Um I typically I said once I get the uh, it just depends on the order you need things in I would guess I would say once you get to that base profit with a console then you can start you can pick whatever devices or you want to bring up next Uh I don't know about the videos available for the after the event Uh, what's the approach to monitor ssd u art read write speed? Um I that I don't know Uh, okay, is there any impact with harborside of the wrong configuration on the dts? Uh, yes, it is possible to blow up things um He uh, I would say is that you have to be very careful like with example sd cards that you don't uh That you get the voltage right That one you can cause a lot of damage the same thing with uh, I would say sd cards is the biggest one I can think of off the top of my head. There's maybe something with pcie too, but uh Uh, if the linux kernel willing mainline to accept proprietary board dti I think it's really more of a question if you want. Um, again, I I haven't ever submitted a dts to mainline Uh, but you're gonna have to have a maintainer and it's gonna have to it's gonna have to go through review Um, there's not any reason to uh, I think unless you're trying to have people leverage your design Uh, I think there's a lot of proprietary boards that have not made it to mainline Uh, it's what I was saying is that's why the existing board design discussion I was talking about you have to be careful with that Um, okay. Thank you for the nice word there and uh, what is the purpose of hardware mod? Um That one That's going away. I'll just put it that way It's uh with the latest kernel that are coming out This is something the purpose of hardware might always be able to help with the basically the power clocks management of the processor during bring up Uh Okay, somebody says came back with simple bus means a simple memory map bus with no specific handling of the driver Okay. I'm again, I I don't have a answer for that one Uh Okay, Drew mentioned. I see it in device tree files frame three three five eight um I'll have to I guess you must be talking about overlays. Um I have to go back and look uh Do you have a vision on using usb on board standard bring up version sd card? uh, um No, I don't have a uh a version yet. I guess that means version. Um But um, I would like I said, I usually it was just cut and pasting in uh nodes from an existing dts file I hope that answered that question When using dts create a dts from the dtv have you ever found a tool that can create a dts and add reference to the source of each device tree entry uh No, I'm not that I'm aware of If I understand the question question correctly, can you find out? Which include file it came from? I don't think you to my knowledge I don't think you can because it's just basically disassembling a big data a big blob And once it's uh into that blob you can't tell how it just got into the blob our dts file is covered under Oh, that's a I that's a gpl v2 Our dts file is covered under the gpl v2 license sort of can they remain proprietary? um I I guess that that one I have to you'd have to I have to defer to getting legal advice on I don't I mean No, I don't know. I can't I don't know that that's that one uh Okay, so somebody's asking can you divide modify dt a dt or device tree on the fly The person saying yes, you can do it by blobbing you can do it in the memory. So yes, you can I just person saying that they've done it before uh another Okay, there's oh somebody's telling me that you can find a source file by using dtx diff annotated against the dts file. Okay Okay, I haven't really tried dtx diff before I think I should probably look into that All right, it looks like I've made it through the questions Thank you very much. This has been great And just to add just really fast the the last comment there from frank rowan. Uh, he's the device tree maintainer. So His his answer there is Is the definitive one so you can in fact figure out where things come from using his his his pearl script there Anyway, thank you very much. Skyler's been really great. Uh, it's been a wonderful introduction to uh to device tree and uh Indeed indeed. I'm sure we will refer to it as we have with the other You know talks from from people like thomas pesoni and such but yeah that the slides will be uploaded after the talk and Indeed as I understand that the the videos will be available afterwards I would suggest checking back with the q&a You'll find that people add more questions. Uh, even after the talk. I've actually just been adding some to mine Uh during your talk as well. So anyway, thank you very very much everybody The next talk will be an i-squared c and spi this afternoon with michael welling And map porter will be giving a talk on uh spelunking through reference manuals and schematics Uh at the at the end of the day, which will finish off our essential embedded track. So thank you very much everybody for attending