 For those of you who don't know me, I'm Frank Rowand. I'm one of the two device tree maintainers. And it wasn't on purpose that I became a device tree maintainer, I just kind of fell into it as I was submitting things and giving talks. And all of a sudden, it seemed to be the thing to do. Knowledge is failing me today. Okay, I'm tied to the laptop. Okay, I have a history of having about 200 slides for an hour presentation. I've cut back for today, and my goal is to actually not show all the slides that I do have. So here's the agenda. I'll talk a little bit about what's been going on in the last year, what we see coming up in the next year, event-wise, what's been new with device tree itself in the last year. Tools are near and dear to my heart, so I'll talk about tools a little bit. Thank you. Yeah, that could be why my pointer was in advancing things. Uh-huh, thank you, Bill. That feels so much better, except now I can't see the slides. I'm always gonna be looking sideways. I hate looking sideways at the screen, sorry. What I really wanna spend time on is what you guys are interested in. So that's the next bullet point on the slide. I really would like to spend most of my time there. So I'll try and rush a little bit through the introductory stuff before that point. And if you guys run out of questions and comments, I've got more slides, and I can continue talking. And feel free, as I'm going through the early slides, ask questions, interrupt. I'd like to know what's on your minds. Okay, the first event that happened last year was really easy to describe, because it didn't happen. If plumbers, there wasn't enough interest, there weren't enough people who were planning to show up. So we did not even submit a request for that conference. I heard, in retrospect, that there were people who were upset that there was no device tree session. Didn't have a person who, so did you actually complain or just were upset? I was missing it. Oh, you were missing it. I don't know who you're up to. Yeah, I'm sorry. So, and I'm just gonna give up on this technology. We did have a large workshop. Grant likely put one together in association with ELC Europe and the Open Source Summit that was in Prague last year. And it was a sizable group. You can see just from the picture how full it was. It started out as being a small room and they were turning people away, so they actually gave us a much bigger room. And I was really, the thing I was really happy about in this get-together was the breadth of participation we had. So we had people like the ARM subsystem maintainers. We had the tool chain, DTC tool chain people. We had people from the Linux kernel. And just seeing that breadth of knowledge and the synergy we could get out of that was really, really nice. So I'm hoping that we can get some of that this coming year in plumbers. But going back to that, that conference, there is a URL there which points to the slides that were presented. And also notes taken. There was a whiteboard set of notes and an individual also took notes. Grant also has an audio recording. Last I checked, he had not posted it because it was so large. But if you want it, he'll be glad to share it with you. So I highly recommend you go to that URL. I'm not gonna try and describe what really happened. It was a day-long event. And so that'd just take a whole lot of time. But major categories, one of the things that was really driving the desire to have that workshop was the validation and verification stuff that has been going off and on for the last three years or so. And then there were a bunch of other stuff that got added in as there was room. And here is the full schedule. So you can see there are a lot of topics covered. But again, just look at my slides or go to that webpage to see more details. Plumbers 2018, November of Vancouver, British Columbia in association with the Linux Kernel Summit. And we really like to have sessions in association with the Kernel Summit because we do get a lot of the cross subsystem people visiting and participating. In this room, who is likely to go to plumbers this year? One, two, three, pardon? If we have a track, okay. So four, okay, that's a start. Put my hand up, I'll go. I'll see what we can do here. I'll put in a proposal and see if we can start getting people. I already know one key person who's not gonna make it because he has too much international trouble already. Little twist arms. And you guys twist arms to get the right people there. So now we're on to what's been going on. The device tree specification was released a little over a year ago at version 0.1, version 0.2 followed quickly. And the significance of this slide is that we no longer use the ePAPR as our specification that says what device tree is supposed to be. This is essentially a cut and paste of ePAPR with some cleanups and it's going to be evolving. And the specification group meets regularly. There's a URL to go get more information on it. It's actually maintained in a repository. So you can see how it's being edited and changing. And you can actually participate in that process. You can submit changes on the mail list. Tools, stuff I like. This is really old and it's in kernel. It's there. It works 80%, I would say. The reason I bring it up is it seems that people don't know about it. When you have a device tree and you want to have a kernel that actually works with that device tree, which drivers you can figure in, it's not an easy process. And this is one tool to help you figure out which config options you might want to use. It's not always obvious. For a single compatible string there might be several drivers that are willing to deal with that hardware. So you need to pick. But this will at least let you know what those drivers are and it will check what your config options are if they're set properly for those drivers. Next tool. This is a really old tool. And I gave a talk on this many, many years ago. 2015 was the last time I was writing on the mail and it's about it. And it just, it was just sitting. Out of time I wasn't paying any attention to it. And as part of that whole workshop in Prague, there was an email conversation and Julia Lowell picked up on the fact that this tool was out there in a prototype form and not really advancing and volunteered to look into it. And she has been working and submitting new patches, fixing everything up. And she's up to version four, I believe, on the mail list. Yeah, version four. And it seems to be in the proper state to get in. No one's making any more comments. David Gibson says he's happy with it. He likes that it's being there. And so we expect to get that into the compiler pretty soon. So what are annotations? Kind of put the horse before the horse. This is an old example. This is not the current format. But the idea is with the structure of device tree source files, you tend to have one starting file, which includes another file. And you start, you end up with this include nest. And one of the strange features about device tree is you can define the same thing multiple times. And each time it's redefined, the old definition just disappears. So if you've defined a property in three different places, it can be difficult to know what actually got up, got into that end product when you compiled it all together. And this will show you exactly which source file a property or a node came from. So it's really convenient when you're trying to understand how to fix your end result device tree, where to go to change something. Yeah. This is an option on DTC. It'll be dash, dash, annotate. And I believe it's dash, dash, annotate, dash, full. So it's either a shortened path or a full path. It's the specific line number column or it's a range of line numbers and columns because an object can encompass a very long distance. So you'd like to have your opening parenthesis or your opening mark and your closing mark for a node, for instance. So your node definition actually spans a lot of different lines. Next tool, not quite as old. The issue I was trying to deal with with this tool was you have a device tree which has a bunch of stuff in it. You have a driver which is accessing that data. And are they consistent with each other? Are they in sync? So is the driver trying to access properties that don't exist? Does the device tree define properties that the driver is not trying to access? Is there synchronicity here or is there a disconnect? And this was one way to get a good sense of what was going on there. And in the end what it looks like is just a diff which is really simple to deal with conceptually. The diff is what is in the device tree file. The other half of the diff is what properties were actually accessed on the system. And it's just a simple print case. So we look at the d-message and see what properties were accessed on the system. So the diff here is showing the minus side, the d-message, what happened on the system, what properties were accessed. On the plus side was what was in the device tree source file. So you can see that there are a lot of properties that were in the source file. They have the plus, but they weren't accessed on the system. One side effect of the tools is we don't see the values of the properties. So one thing that the tool points out is a node disabled or not. And that's why all the properties or most of the properties were not accessed on the system. Turns out that the status was not enabled. So of course the driver is not going to read all those properties. So that's just a little shortcut to save you. It's wasting a lot of cycles trying to figure out why the heck aren't these properties being accessed. Again, this is a tool that's waiting for me to get back to it. Anybody who wants to jump in and take it over feel free. It's on elinux.org. Another tool. A lot of the problems with device tree, especially for a new system, is getting the boot to work. And there are a lot of things that have to work in the boot. You have to have the node defined in the device tree. You have to have a device that gets created in the system. You have to have the device and the driver hooked together. Figures which driver goes to which device. And this tool was a way to give you a quick look at where are you in that process? Which of the things happened right? Which of the things happened right? So here's just a quick example from a talk I gave on it. And the things on the top are things that went well. The things on the bottom are things that didn't go well. I'm looking at a coin cell device and driver. And there are no devices. There is a node in the device tree. The node doesn't have a driver. The node doesn't have a device. So we've got problems here. We don't have a device. We don't have a driver. Sorry, we don't have a device. We don't have the node connected to the driver. We don't have the node connected to the device. And then kind of the opposite mirror image of what went wrong is the same thing. Node that doesn't have a driver. Node that doesn't have a device. And in the talk that the slides came from, I went through well. Here's problem A and we fixed that. And then we find the next problem. And here's problem B, we fixed that. And after a while, we get to this next date. Honest, we got to our next date. Okay, we got to our next date. And things were better. More things in the top half were in place. And there were fewer things in the bottom half. So in this point, there was a device created for the node. The node and the device were hooked together. But we still didn't have a driver bound to it. And that's going to show up again in the bottom. No, not bound to a driver. So this is yet another tool that's waiting for help. If anyone wants to go in and fix it up and get it ready for submission, you're welcome to do so. Moving on to the compiler. There's been a lot of work going on there in the last year. One thing that Rob has been working on is making the compiler more knowledgeable about what a device resource should look like. And specifically tying in knowledge of what a Linux binding should look like. So he's adding lots of checks in, in warning checks. And if you've been following, he'll submit a few warnings. We'll pull that new compiler version in. And he'll disable those warnings in the kernel build initially. Because we don't want a ton of warnings appearing all of a sudden. But now the warnings are available. Developers can turn on the warnings. That's what this slide is. Just on your W equals 1 flag. And see what errors you're getting for your device trees. And then we'll get a bunch of patches and clean those device trees up. And then we'll enable the warnings once we've done a lot of cleanup. And then a new set of checks come in. And Rob is, this is a list of all the commits. And the compiler get repo for the last year, roughly. So you can see how many checks Rob has added. So if you're out of tree with your device resource, I highly recommend you start building with warnings enabled and cleaning up your device trees. The warnings tend to be real things. They're not just cosmetic. They really are catching real problems. Overlays. How many people are interested in overlays? Yeah. That's generally why most people show up I think. If we got rid of overlays, no one would come. There has been progress in overlays in a few areas. One of them is the device tree compiler is more aware of overlays at the source level. It's now easier to encode an overlay. There's much less of the structure exposed that you have to hand code. There's still more work left to be done in the compiler. But the current version in the kernel tree as of 4.15 does have much better support for overlays. A second issue related to overlays is, but we'll start with. So I said you don't need to code fragments, overlays, fix-ups, local fix-ups, and symbols anymore. The compiler can do that for you. Fragments and overlays are really the overlays. The others are metadata. They're information about the overlay or that the overlay application code needs. And you really shouldn't have to deal with that. That should all be behind the scenes for you. And it's somewhat problematic in the format. It was put in place in an attempt to not... Well, to be compatible with the existing ecosystem. So it just dropped in. Bootloaders wouldn't have to be aware of any changes. It would just work. But it's made for a solution that's not optimal. And so I put a proposal out on the mail list recently saying, I'd like to actually put this metadata into the format of the flatten device tree, the binary format, and explicitly code that, not to make it compatible, which is the unfortunate side of it, but to make it much more efficient in the end. I really encourage people who care to go to this thread and look at it. It's kind of stalled out just because there's so many things going on, and there's so many parallel discussions. We'll get back to this one and start driving it. I started with my proposal. David Gibson came back with a different approach, which was very interesting. And they each have their advantages and disadvantages, and maybe someone else will come up with a third approach, or maybe we'll just somehow decide between those two. But please get involved if you care, especially bootloader people, especially people with other operating systems. It turns out VSD likes to use device tree, Zephyr uses device tree, NutX is considering device tree, and we're trying to be compatible and considerate of all these groups. So this is what drove me to make that change. It had been kind of a thorn in the side, and if you're going to apply an overlay, the overlay is going to be pointing back to symbols in your base device tree, the device for your system booted with. And that symbolic information is that underscore symbol, underscore node currently. And it turns out that takes a lot of space. And there were some people saying, well, why don't you just turn on symbols for all the device trees? This is part of the kernel build, and this was the answer, why not? I went and built all the device trees in ARM and measured how large they were. And that's the second column. This is kind of a percentile chart. So the 99th largest was 90,000 bytes without any symbols. The 83th percentile was 43,000 bytes. So just trying to slice, you're trying to get a sense from largest to smallest how large are these device trees. And when you turn symbols on, which is the next column, how much larger does your device tree get? And that binary device tree, in the worst case, was about 40,000 bytes larger. That's pretty significant, especially if you have a boot image that carries a couple of device trees in it, which some people like to do. So my first prototype, the format is proposing instead has a much smaller overhead, and the final column is how many fewer bytes it requires than the current format. So that's a significant size savings. We do like Linux, right? This is the year of the laptop. Okay. So going back to a saying, you don't need to hand code a lot of this overlay stuff anymore. This is what the old format looked like. You're used to hand coding for each overlay a fragment. So the fragment node contains an overlay. It contains some information about where the overlay is going to get loaded into or applied, which is the target of target path. And then you actually have the overlay that you want to inject into the device tree. What it will look like if you use the new DTC is instead of having the fragment and the overlay nodes, you just specify a label of where you want it to be applied. So it's a lot simpler. DTC figures everything out. And just to diff the two formats, you can see everything else is the same. The only thing that changed is you no longer say fragment, you no longer say overlay, you no longer say target. You simply say, where is the label I want this applied to? So it's a very simple transformation. But much cleaner. There are some issues with this. And we're working on fixing the issues. One is that target where you're going to apply the overlay has to have a label on it in the base device tree. You can't hard code a path. We'll need to fix that. The other is you cannot put a label on the root node of the device tree. The compiler just chokes on that. So we're working on that. I'm not sure how that'll get resolved. Yeah. I'm sorry. Say that again. Right, right. So the question is, where you specify target path? Can you just say... All right. Can you just say slash there? And the answer is ultimately yes. So... Okay, let's... So here what you would say, this is really interesting syntax. You would say, you're saying ampersand fpga region. If you wanted the root, you'd say ampersand open brace slash close brace. And that syntax lets you use a full path instead of a symbol name in this context. The problem is that DTC right now doesn't create the target path property. It doesn't know how to do that, but that's going to get fixed. That's on David's radar. That was one of the things I was saying that needs to get fixed so we can use any arbitrary path instead of a label. Okay, I had much more I could say about the nice features of having this new syntax of how you can use essentially the same code as the same source as either an include file to another device resource file or as an overlay. But I wanted to let you guys have a chance to talk, so I deferred those slides and we can come back to them later if you want to come back to them later. But now it's you guys. Hopefully you've been thinking about what you want to know, what you want to say, what you love, what you hate about device tree. What would make your life better with device tree? Which overlay to apply in which situation? You know, so in Uboot we have fit so that's one solution. I know Android's putting all the device tree information into a specific partition with a not invented here format. But, you know, so not everybody wants to use fit, right? I mean, I personally think it's kind of a pain in the butt to put your kernel and your init ramfs into this, you know, into this image. But so, you know, I think, we need to think about what does it look to consume this stuff on devices in boot loaders. Right, so basically it comes down to how do you specify the device tree to use on a given boot and potentially which overlays to apply to that device tree on a given boot. That's definitely a topic for somewhere like plumbers where we need the boot litter guys to get involved. It's not purely a kernel thing. It's a community bigger question. Well, it's not just overlays. It's also, if you have multiple device trees, which one do you use? So it's a big configuration question. How would you like to run a session at plumbers on the topic? If we have a track. Yeah, okay. I won't hold you to it, but there's kind of another thing related to overlays that maybe I should point out is that it's really easy to take flattened device trees, combine them together to create a new device tree and feed that to the kernel and boot the kernel. Or you can feed a flattened device tree in an overlay to the kernel. It's very easy for the kernel to combine them before starting the boot. The ugliness with overlays is when you boot from a base device tree and once the system is live, once all the subsystems think they know everything about the fabric of the system, now you inject new data and now drivers and subsystems have to figure out well, how do I react to all this change? And it's much, much worse than that. So that conceptually is easy to understand at a theoretical level. At the practical level, the device tree implementation in Linux was not designed with the idea that overlays would come along at runtime. So the foundation's not there for it to work. We don't have locking that works. We don't have memory management of our data structures that works. We have a lot of things that we really need to clean up before overlays are practical at runtime in the kernel. But we are open to the idea of being able to pass overlays to the kernel that get applied pre-boot. And I think we can get that in mainline much quicker than doing live systems already booted overlay application. So if anyone's interested in that concept, we should start discussing that. And then we're going to have the same issue. How do you feed the information of which overlays you want to apply to the kernel? So it's the same thing as how do you tell the bootloader? So we need to come up with a way to communicate that information from the bootloader to the kernel if we actually implement that. So again, the bootloader people are real important to that conversation. Next. Let me see when we got that one. Well, the risk of exposing how lazy I truly am. The new compiler, what will it do in the presence of an existing fragment and overlay syntax? In other words, do I have to go and edit all my old files? It will continue to work. My personal desire is that the compiler start to refuse nodes that start with underscore underscore because those are illegal node names. My pragmatic position is that the compiler should continue to support those some way, whether we have to pass a command line argument to say, yeah, let me do this thing which is otherwise illegal, or it might be the opposite. Maybe we have to pass a command line argument which says don't allow the old hand coded. But either way, I believe the old method should continue to be supported for a very, very long time because there's so many people using it out in the wild. The other thing, I want to change that internal metadata format. As soon as that metadata format has changed, you will not be able to hand code local fix ups and symbols, but you shouldn't be doing that anyway even a year ago when you're hand coding. A year ago, you should only have been hand coding the fragments and the underscore overlay nodes. You should have been letting DTC already do all that other stuff, all that metadata stuff. That shouldn't be an issue, hopefully for most people. I know some people like to do hand code symbols and stuff, but yeah. Yeah, Merrick, can we get the mic over? When are we going to get the DTO config of us loaded into mainline Linux? Not for a long time. There's a gating factor, and we've been very clear about this from the very beginning. I mentioned before that we have foundational issues in that we were not built in our core infrastructure to handle overlays. As long as these issues haven't been fixed, we're not going to accept the overlay loader. We need to work through these, and we're slowly working through them. We have some fixed already. We have some more queued up for 4.16, and we'll continue to work on them. It is no longer a security issue, but it's an issue with the DT infrastructure. Is that right? There is a security issue. The security issue is really, really easy to fix. It's flipping a bit, saying we're not going to allow overlays to be applied, and that's an administrator tool to flip that bit. That was accepted by the security people two years ago, conceptually. I'm not aware of any other security issues. Are you? I think this is what it was about. Yeah, so that one, it'll be easy to take a patch to actually implement that. That one's not going to be a big deal. The other stuff is a lot more work. Thanks. Back to Bill. I think there's someone else in the middle also. Just to carry on that, I thought the connector format, where you could extend, and not just a binary yes-no overlays, but you can put an overlay here. This is where I was saying, we decided a long, long time ago, and we've been staying up front. Until we get that base stuff fixed up, the loader's not going in, and it's been out on the mail list. Here's the list of things that we've been actually accomplishing and things that we need to do. This is not a complete list. These slides are on the conference website. If you want to download them. It's not my self-made thought there. Sorry. There's some things we've accomplished. There are more things we need to fix, and there are yet more things we need to fix that are not listed here, just because they are not as critical as these things. These are just major, major issues. They're going to take time to resolve. The first thing on the list was refactoring some of the code in the kernel, just so that when a patch came in, I could understand what the heck was going on. To me, it was just very hard to understand, so that's been accomplished. Those are all in. The hand-coded overlays and device trees were talked about already. The compiler's updated, except for the few corner cases which we're working on, so that's resolved, and that's in the compiler that's in the kernel source tree. The next big issue was... This is really sad, but the whole API of how a driver gets information from the device tree, we return pointers to the driver. The driver's saying how pointers into our internal data structures, which means we cannot free our internal data structures. If I apply an overlay, a driver accesses some of that data, has pointers, and if I apply the overlay, I still cannot free that overlay data. It's got to live on forever and ever until the system reboots. The responsibility used to be out in the people who applied the overlay to free the data. There are some changes that are queued for port dot 16. That responsibility of freeing the device tree overlay has moved into the infrastructure, into the core device tree. The overlay applyer no longer needs to worry about that, but the base problem still exists. We still have no way to make sure that there are no pointers into our internal structures. We're going to have to come up with a whole new API for drivers to access device tree data, which does not give them pointers. That's going to take a long time. That's going to have to filter out to all the drivers on a system that's applying overlays, that you can take. You can say, okay, as policy, only the drivers that are actually going to access the overlay have to be updated. It's kind of a slippery slope. The question of how quickly to enforce all drivers get changed or just a subset of drivers and start allowing overlays in a limited fashion, given that you follow the rules. You hold your hand up, you say, I promise I followed the rules and didn't follow the rules. It's my problem. I'm not going to make you fix it for me. Oh, so there's more... Sorry. Changing the format of the flatten device tree, the compiled device tree. When we remove an overlay, unapply it, we need to make sure that nobody's using that overlay. No drivers are still using it. No devices. Those checks aren't there. You can see the stuff just snowballs. They're all in place. And we're working through them at a time. Yeah, there's a question from... Magnus? Or you're just wondering back there with the mic. Yes. I don't remember what I was supposed to ask, but... When can we see this upstream? Which part of it? Everything. Oh, my goodness. I'm going to make you bet. Five years? And the reason for that long time frame is that's the full... All of the drivers in the kernel have changed over to this new API. And so now we can be fully unrestrained. We don't have to have the people running around overlays saying, I promise all my drivers are correct, and therefore I accept all consequences of drivers that aren't. So I think we can have partial overlay support actually working in the kernel sooner. And I can't really give a good estimate whether it's a year or two years. FPGAs are probably going to be the first users who are going to be able to say, I promise I'm using them the right way, and in a very constrained environment. But for this generic case, I think it will be a phase in as we allow more and more use in more unrestricted ways. Makes sense. I'm not sure if the... So I'm not sure if the FPGAs should be the first citizen there. Yes, so America is saying that FPGAs can do anything, but anything in there. So maybe that's not a good starting point. The cool thing about FPGAs says that connectors are fine with them. They're willing to live within the constraints of the connector architecture. So if we can get the connector architecture in place, they'll be in good shape because they'll be living within that. The problem they're going to have is that in some cases they want to be able to apply an overlay, unapply it, reconfigure their FPGA, apply a new one, at a very high frequency, very frequently. So those people will not be supported because they're going to have a memory leak every time they unapply an overlay. So that's going to be... Even FPGAs, even if they're following connectors, if we have connectors in place that are following those rules, they'll be allowed to apply in a very limited sense, unapply as long as they realize they're getting a memory leak and they have to constrain themselves to not run out of system memory. Which will eventually be fixed, right? Eventually will be fixed. Yeah. So I have another question. What about the YAML DT? Can you comment on that? Ah, okay. There's something I forgot to mention. So I said that the driving impetus between the Prague Summit was validation verification. Grant likely is giving a presentation at Lanara Connect in Hong Kong next week. I think Monday. I think they livestream that stuff. So if you want, you can see it or maybe just audio conference. Slides are normally out there. So you can see what's going on. He's going to be updating what's going on with that validation and verification stuff. And he's going to be making available repository, making public the code that he's been working on so people can see what's going on and participate. I mean, it's never been closed. It's always been anyone who wants to work on it they've just been doing it on the mail list. But now he's exposing what he's been doing in a repository. So that's what the YAML DT question. Well, there are two YAML things. So the way that they're going to verify the code their thinking is they'll take the device tree and somehow they'll transform it into a YAML language format to describe directly one for one what the device tree is. And then the validation tools can easily consume a YAML representation into the validation. There's someone else who wanted to be able to describe device tree source as YAML and that's a whole different question. So I didn't I hope you weren't asking about that. Don't. Yeah, okay. Just wanted the YAML stuff mentioned. Yeah. So that's ongoing and definitely take a look at what's going on and Elinor connect next week if you're interested in that stuff. So there was the idea of writing your device tree in YAML versus DTS. Yeah, let's not go there. That's what I was saying. Yeah. That's not my favorite topic. The question was was the session in Prague recorded. It was audio recorded. So if you want the audio you have to go to grant. It was such a huge file he didn't actually download it to Elinix. But the Elinix page which the URL is in the earlier slides does have the notes from two different sources and all the slides that were presented. Question in the back. So it was a random question but when submitting a device tree how closely do you have to follow the 80 character rule for the device tree files? Not really source. Does anybody here know of a device tree source file that's not greater than 80 lines? 80 characters in a line? You don't know of some unwritten rule but your device tree source file has got to be really long lines. And we ignore any check patch warnings about that. They might, check patch might even be smart enough to exclude DTS I'm not sure. So yeah, check patch doesn't exclude it but we kind of ignore it so I just wonder if there's some kind of unwritten rule. You should submit a patch to check patch to tell it to ignore line length and DTS files. That would be a good improvement. I might do that. Check patch, patch. Question up front. There's a whole other group of maintainers that deals with device tree source files. That was part of my ideal. I was just going to deal with device tree core as a maintainer. And I try and stay out of device tree source although I do get sucked over there sometimes. So, new topic. I asked this last night at the Tiny Linux forum but kind of rephrasing it and rethinking in my head. You know, suppose I have a single function device. I don't really need 14 different device trees to ship with it. I don't need overlays. What is currently the best way, most optimal way to package the one device tree with the kernel? And what would be a better way going further? So are you saying that you have a very capable device with a very large device tree that describes all the hardware on the device? But you don't care about the scuzzy interface and the ethernet interface. All you care about is that one serial port. Yeah, or all I care about is this one device. We were talking about bootloaders earlier needing to carry three or four different device trees. I just want to append the device tree to my kernel. Have the one binary blob. I want to append it to make it as small as possible. Okay, do you want the normal device tree that describes the whole hardware that you're booting? No. You actually want to customize it. Trim it down to a subset. Even that I'm going to trim down. Okay. So what's the best way now? There are about two or three different concepts and issues related to this. So let me get to make sure I cover enough of the issues here. These are not new issues. One is the size of the device tree when you really don't need the whole thing. And Nicholas, Nicholas's last name doing system size reduction, Michael, or Peter. He's been looking at that and working with Rob and some of his prototyping work, they're looking at, well, what devices are we not using? Can we exclude those from the device tree? And there's been some prototyping and dealing with that. One way to approach that would be if the device tree compiler, if you passed it a flag that said if this node is not enabled, then don't even put it into the compiled device tree. Just leave it out. So for today, I could address that by going in and hand editing the device tree. I'm looking for what can I do today versus where can I go? Yeah, hold that question. I'll give a few, don't lose it though. Another way of dealing with it is go ahead and create that large device tree like we do now. So now you still have a big thing at boot time for the boot loader and then have the kernel say nodes that are not in use just don't create those in the live device tree. So we save memory in the kernel. We don't save size in the actual binary file and at the boot loader level. So we have these different places where we can save resources, whether it's memory, whether it's file space, so kernel, boot loader. So saving space is one issue. Another issue is essentially how do you configure a system? So device tree is supposed to be a hardware description. The device tree is supposed to say this is what your whole system looks like. You're not supposed to use device tree to configure your system to say I only want this little piece. But we don't have a good solution for that. We don't have a way to configure systems. You don't want to... You have the kernel configuration system Kconfig. You can say what drivers do I want to include my kernel image or not. But that's answering the kernel half of the equation. It's not answering the device tree half of the question. So I think this is an open issue and I'd love for someone to come up with a really good solution for it. And nobody really has proposed one that I'm aware of. But I'd like to get people brainstorming on that one because that's something I've considered as an issue. Don't forget what you're going to say. The other issue that often comes up in this configurability is if you have a system where your build materials might be changing frequently and the manufacturing people might be changing things out from underneath you, how do you maintain all those descriptions and pick the right one at boot time? You can see there are a lot of different related problems to be solved. And it'd be nice if we could keep those all in mind and have as few solutions as possible to address as many needs as possible. So is this on the same topic I assume? Yeah, okay. Then we'll come back to you. Yeah. Plus it's adding into the device 3 stuff which shouldn't be there. Yeah. So we're officially at lunchtime. I'll stay here and continue talking, but if you want to go eat lunch, you won't hurt my feelings walking out. So Merrick was saying that you boot, they can trim out nodes that you don't want or don't need. Especially in the SPL which is like the preloader which has to be as small as possible. If you boot the system in that basic mode, and then suppose later you want to add an overlay that's going to need some of those things you trimmed out, can you add those back in somehow? So you can start multiplying these interactions and you start getting really complex and how you're trying to solve the problem. Of course it's a slide substance issue, but if you boot isn't your bootloader. Yeah. You were talking about trimming the tree in U-Boot, but that's only useful if you're using U-Boot as your bootloader. Trim out the dead ones or make the kernel just not load the dead ones. What do you think? I think that both can go in easily. I don't see major problems with either of them other than opinions of maintainers. Whether they're willing to go along with it or not. But in terms of technology I think both of them. One's a tool thing and one's a run time thing. I just didn't know this would never get... From my point of view I'd rather have the compiler pull it out because I'm trying to squeeze every bit possible. You're trying to shrink your boot image as well. Yeah. Yeah. So you reduce your flash and you... So Frank, can I ask you is there any tool, sort of like patch or diffutils where you can do filter diff and diff start and stuff like that but on DT files? Is there any tool available that you can do things like filter diff and diff start and stuff like that like you do on patch files but you do it on DT files because if that would exist then you can kind of filter out stuff. Right. I started thinking about that in terms of symbols. Which... So some people want to have that base device tree include all the symbols that nobody might need. So just build it that way always. And that's what a distro would ship. But I was thinking why not just strip that stuff out if you don't want it. You could have a strip tool. So something along those lines conceptually I think that's a possible good approach because that way the person who wants to have a generic distro that has something that works for everyone. They can create the big ugly object. People want to shrink it down. There's a nice supported way to easily shrink things down. Yeah, that would be nice. You have a static tree that has everything under the sun and you did it one time. We don't care about space. We got plenty of space because we're a PC or we're on the embedded side of things and we care about every single thing and how do we do that efficiently? Yeah, unfortunately the reality on an SoC isn't that straight forward because the hardware that you have exposed and available on a single board single specific board based on a specific SoC can change based on what your pinmuxing is. So how? And then you get into reconfigurable hardware with FPGA and things and now it's a whole other... Yeah, we actually had a session that I did in Plummer's two years at Santa Fe where it was hardware description configuration policy because we actually have all three of those in device tree even though we claim we're just hardware description and it's not always clear when you crossed a line from one to another and it was really interesting with all the different experts in the room coming up with examples saying well here's an example, what is it? Hardware description is a policy is it policy, let's say configuration or policy and just seeing the opinions and the rationalizations people were using to drive it into one category or another was very interesting. Quick question, I'm a student right now for computer engineering and I've used Linux for a long time in the general sense of the driver development stuff like that for it but I was wondering in particular to say FPGAs where you can just program it to whatever you want it to do could that be that issue where you're having issues with overlays be where maybe the firmware creators for those devices or when you're making an FPGA and you're rewriting it to do what you want it tells the operating system what it's supposed to be doing or what options it has so that it knows what pins you're doing this here's all the different pins of what I'm doing here's how you connect and do it to me so it doesn't have to require the operating system to like poke and prod it but it's the device telling the operating system this is what I do, I do magic here this is how you connect to me is there something you can look at from that kind of way in the kernel development? Well that's essentially what the overlay is doing it's the FPGA system's way of saying here operating system here's what the hardware now looks like it's going to work to make it work for me does that make sense? Yeah, I was just thinking like the way you were saying how you're having the memory leak and what's causing the memory leak in particular with that The problem with the memory leak is when we tell a driver here's the device, please initialize your advice, it's yours the driver needs to get the description of the hardware the way it gets it is it looks like and unfortunately we return pointers to data in our internal data structures instead of just returning the values back or a copy of the data we're returning pointers into our internal structures So as soon as that driver has a pointer we can't free that memory There was a session yesterday on i3c having two different drivers for the same peripheral that you need to select between them based on what else is on the bus Oh interesting I meant to go to that session Well it introduces a new problem of one device needing to know what else is on the bus to pick the right device driver, of course if there isn't conflicting drivers you'd want to use it in a high performance mode but fall back if it has a conflict if it was as simple as that it would be great to introduce hot plug support so it's this notion of needing to reconfigure if there is a slow device being plugged into the network This seems like a candidate for overlays to change the configuration but I feel like that's coming up from that perspective as well and that's analogous to the FPGA reconfiguring themselves this is a bus that needs to reconfigure itself and all the devices that are off of it and PCI is the same sort of thing anything that's hot plug there's a lot of overlap between the hot plug world and overlays conceptually in a lot of the same problem areas that hot plug has been dealing with for 20 years and then one more question the Prague one we had a discussion afterwards on if an overlay is removed what state does it go back into is that dictated by the underlying device tree or the overlay that is being removed there's no definition at all of that to my mind the basic default should be that we do not remove an overlay until the driver connected any node is removed and the device that is connected to any node is removed and the nodes are in the overlay we don't even have those checks right now but you're making a more nuanced suggestion where you could choose to configure what the behavior is for a given overlay whether you'd have to follow those base rules or whether you would allow the device to continue functioning and the drivers remain connected after that I guess one way of looking at it is if you have a scenario okay let's say like this is analogous but a boot condition where you boot up you load an FPGA and then for whatever reason you need to reboot the system that's kind of the classic example I think FPGA might already stay configured your configuration is different to a different state and the boot configuration which is expecting one state is now entering a different state it's a conditional rate so in that case you would still want to have the driver if I remember the conversation you didn't even want to acquiesce the device you wanted the device to still be able to function the driver itself is going to go away so the FPGA can no longer be communicating with the kernel but the FPGA could still be having active state it could still be running it could still be communicating with the outside world doing stuff even though that driver has been severed from it and so your issue is that you want to reboot you want to retrain persistence persistence for that hardware description so when the kernel reboots it says oh this is what the hardware already looks like and not load a new FPGA image but now reload a driver and reconnect that yeah I mean it's a real it's a real use case and it's something that nobody has moved forward on it doesn't have to be an FPGA too it could just be a microcontroller it could be any hardware FPGA is just a real good example yeah and remote kind of assumes that the remote processors aren't going to do anything until they start up right but there's a use case where the bootloader has to start it early and get it going and then or Linux started it doing a keeping the heart pumping kind of thing and it wants to do a reboot for security update or something and that's got to remain active and so the kernel has to re-sync with that so it's something that we talk about in the remote proc RP message context as well you might also need to keep certain clocks in a certain state what's that? you might need to keep certain clocks in a certain state so there are a lot of subsystems potentially involved you need to make sure that they don't reset so you're definitely facing a big issue that crosses the kernel subsystems but yeah if you want to tackle it this is almost hot plug in reverse where instead of the device being hot plugged it's the operating system and the computer being hot plugged there is some sort of boot constraints patch set which allows you to pre-configure the clock boot time maybe this is somehow related to this stuff but it might not even be a static thing it might be dynamic but it's based on what the system previously was doing well I'm not sure if it makes sense to use it because you're basically reinventing board files yeah yeah yeah yeah yeah yeah yeah right so when you're saying deferred bind if your driver is willing to make that decision itself you want somebody else to make that decision but you have like max cpu's for cpu hot plug right you can say you have max cpu's for cpu hot plug for instance you say like you have like this one cpu so you just put with a single one and you use hot plug to insert it later that's sort of like they're not bound but it's not for drivers it's more it's for cpu's instead right but it's a similar yeah but later on I was going to take one but I can't do both so in a multi-processor system we also have a similar problem with that in that you know it's a node and it's disabled oh well I can shut off the clocks and I can shut off the power we need a different state to say this device is used by somebody else keep your hands off so we were kind of debating what's disabled mean and should there be another state you know can I just bring up the use case of actualization too that it would be neat to be able to take the device tree and pass it on to like a guest or something pass it on to what yeah so you sort of want to make sure that this device is in the host not used but then somehow managed by the guest instead so yeah and then maybe the guest survives or not survives I'm surprised that hasn't come up yet it's a proposal it seems to me that gets back to the question of policy versus configuration you know versus whatever the third one was I'm blanking on because now does this belong in the format in the device tree or is it belong in what's using the device tree or what there's no clear answer we need some other data structure to deal with things like policy and configuration we keep circling that it seems conceptually clean to me to do something like that add an additional structure that handles those things or two structures yeah we could have a node that's called policy or a sub tree it's called policy or configuration that might be the most palatable easy to throw out the idea it's easy to throw out the idea this is where we finish with patches I've actually considered that idea I don't know how it will go over I I don't know how well it would work one thing I've learned with the device tree is I start with an idea and it seems like a great idea and I just code it up but no problem I'll just work and then I go to implement it and it's like all these complications and side issues and entanglements actually exist so conceptually to me it sounds like a nice clean way to do it but when you actually go to do it I'm not sure what we'll find if we try that so it's the sort of thing I think it's worth prototyping and see does it seem to be working or not one of the things that's sort of springboarding off of that that's interesting to me is reconfigurable hardware user control so now it's not just boot sequence it's the user can literally go in and say I want you to do this or I want you to do that yeah it's a button press or reconfigurable hardware let's just go back to the days of back says in 360s who needs all this complexity of SOCs alright I think we're done thank you