 My name is Peter. I'm going to talk about Buildroot and a little bit about what it is and what is new in there. Maybe first of all, who has ever used Buildroot? Just about everyone, okay. That means the first few slides will probably be a little bit boring, but here goes anyway. Well, Buildroot is, as you apparently almost all know, an embedded Linux system. So something that builds your cross-tool chain, your bootloader, your Linux kernel, and a root file system. No special thing there. And we, of course, not the only build system like we also heard this morning. There's all these other things. Yocto, OpenBricks, OpenWRT, Gen2, BaseRock, T2, and so on and so on and so on. But there might be a reason to use Buildroot instead of some of these other ones. One of the reasons is simply that it's one of the older system, if not the older system, which means it's quite mature and I think our documentation is fairly, fairly okay. Another nice thing about it is that it's fairly simple. Kevin Hellman recently said this quote here that I think is nice because it's the kind of thing that I hear sometimes that certain other systems are fairly complicated to get started with and that's a focus of Buildroot to make things quite easy to use. And nice thing about Buildroot compared to at least some other system is also that we do very regular time-based releases. We do releases every three months and then Bobfix releases if needed. That means that you'll get regular updates and you know when to expect a new version to come out. It's also a real community project. This I mean that it's, there's no single company deciding what should this thing be and what should it move in towards. It's just a bunch of people that use Buildroot that move it in the direction that they now want to move it in and the community is quite active and friendly to get started with. If I may say so myself at least. Now if you do embed the build systems then there's a lot of trade-offs involved. There's all kind of features you can think of that you might want to add. Unfortunately features tend to add complexity to the system and in general Buildroot is on the trying to stay on the side of being simple to use, simple to understand but maybe doesn't have all features. We also try to look at whenever a person comes with a certain use case that they don't see exactly how to do certain things in Buildroot. We try to take a step back and see if maybe that special use case and that special use case is actually, you can actually solve them in general if you do something more generic. I think that's important to do because otherwise after a few years you have a system with all these special features and yeah if I want to use it like this it works like that and at the end you cannot understand how it's supposed to work anymore. Because of these choices about simplicity it means that in Buildroot we generate one root file system. We don't generate binary packages that you can install afterwards so whenever you say I want to make a system with Buildroot you really have to say it's for this kind of process it's these kind of packages I want and this is exactly what my system should be and if you want to have something else you start a new build and you configure it differently. Some might say this is an advantage, some might say it's a disadvantage it depends on what you want to do. But having runtime packages do add quite some complexity in making sure that things still work together and that everything is up to date. So we don't support that. Okay well how does Buildroot work? There's basically two steps to it. We have a configuration step where you go and say okay I have this kind of system, I want these kind of packages, I want these kind of file systems generated and for that we use kconfig that you all know from the Linux kernel. In there you have a tree-based structure, you can go and say okay I want to look at my target packages and I might want to go down to libraries and maybe graphics libraries and okay I want LIP PNG enabled or whatever you want to do. You also have on options you have dependencies so maybe in order to have some graphical program you might need to pull in Qt or the ggk or whatever that might be. You can also have conflicts. Certain things are not available if you do something else so you need to make sure you have a toolchain with C++ support before you can use a program written in C++ those kind of things. And finally the options have help text so you can go and say oh I don't really know what this thing is and if I do help I'll get some more information about it. But finally once you control all of these things and you said this is what my system has to be you save it and it writes out that .config exactly like the Linux kernel that's just a text file saying option one is on, option two is on and so on and so on and then you need to build it and building it is just brand make. Exactly like all kinds of other systems and that's all this to building a system you build it. The nice thing about these things is that both of those technologies are technologies that you'll encounter anyway when you do embedded Linux systems. So it's hard to get around not ever configuring a Linux kernel so menu config is something you need to figure out to use anyway and building any software without using make is also pretty difficult and of course none of these technologies are specific to build routes so you had them already. Good. Build route is very much structured around packages. What is a package? It's a piece of your system and each packages has a number of steps that you need to do in order to have them built in part of your root file system. This means that as a download step that's a step to extract what you have downloaded that's a step to maybe add some patches. You need to configure it, you need to build it and you need to install it. That's what a package is. And then the builds, so build route configuration is simply handling all these steps for all the packages that are enabled in the correct order of course. If you have a program that needs a certain library you need to do the library before you do the program but it makes sense. So you can see build route as kind of a meta-build system something that will go and download the source code and the build systems of each of these individual packages and direct the build systems of these individual packages in order to make sure they get built and installed. From high above this is what build route is about. If we go down and look at what is a package, a package is two parts. It's a kconfig file called config.in where you have options, at least one option for a package do you want a package or not but you could also imagine some kind of package with sub-options do you want that feature enabled or do you want that thing enabled? These look something like this. This is a real package in build route for gzip. Everyone uses gzip often. So what does it contain? Well, it contains a line saying kconfig with some symbol, in this case gzip. All these packages have a prefix called b2package. That's mainly historical. Then you have a line saying what should be shown in your menu config, in this case gzip. Finally, you can have some dependencies. In this case, you can only build gzip if your tool chain has white character support. So you need that and if you don't have it, then a comment will be displayed and you need white character support in your tool chain. And in the middle, there are some help texts with a link to the home page of that project. So you can always go there and hopefully learn some more about what the thing does. That's part one. You also need part two, which is a make file snippet called name of package, so in this case gzip.mk. And in there, you need to list these build steps and you also need to list information about what version is it of the package and where do you find the source code. Now, if the package that you add is using its completely custom build system, then you need to explicitly say what does it mean to configure for this kind of package? What does it mean to build? What does it mean to install it? But if you're in the happy case of having a package that uses something a bit more standard, like auto tools or CMake, then we already have some classes or some support for these packages because you always configure and build and install the same way for auto tools packages. So if you have that, then you can just say this one uses auto tools and the defaults will be correct for you. You need to say, ah, I need to add a specific configure option or whatever needs to be in there, but in general, the defaults will do the right thing. Now, gzip uses auto tools, so it's very easy. You just have to say, I want to use gzip version 1.6. The tab all is called gzip 1.6.tab.exe and you find it in the local GNU mirror in the gzip sub directory. That's very easy and because it's auto tools, you have to say it's an auto tools package. It could also be a generic package, then you have to say all these build steps, but it could be a CMake package. Very simple, very small. So that's for your package. You also need to integrate it into builddude, so builddude can find it. You need to say where should it be in the menu, is it a library, is it a utility or something related to network or what is it. So that's the next part. The packages are all on the package and there's a kconfig file that says everything on the package is in here. So you need to open that one up, find where you want to put it, and add to your include. In this case it's on the compressors and decompressors. Kind of makes sense for gzip. It doesn't include the line saying include the config in file from gzip. Very simple. If you then run menu config, go under the packages, go under the compressors and decompressors. You see something like this gzip. You can enable it if you want to and if you then run make, you will build gzip. Very easy to use. Good. That's using builddude, but as most of you had your hands up before, you all know this thing. Good. What you may or may not know is the way you handle the source code. First of all, we use git and we use it in the same way as the linux kernel is maintained. With that I mean there's only one person having commit access, that person being me. And the way development happens is patches get posted to our mailing list. It gets reviewed and finally I commit it. Exactly the same as getting a change into the linux kernel. We have something like two, 300 patches that gets added to the tree per month. We use patchwork. Again, very similar to a lot of this subsystem in the linux kernel. Patchwork is a web-based tool and Wolfgang Zang already talked about it yesterday, but for the ones that didn't saw his presentation, it's something that is subscribed to the mailing list, keeps track on everything on the mailing list that looks like a patch and it adds it in this overview. What it also does is whenever people comment on a patch, it gets added on that page and whenever you add these tags that you also have in the linux kernel about this is act by a certain person, these things get all added. And I can then, when I want to then apply a patch, this is my to-do list basically of patches I need to look at. I can take it in. I can put it from there. Basically, all the people that agreed on this patch and I can add it to the git repository. That's basically the workflow that we use for that. All of it happens on the mailing list. This mailing list is pretty active and the activity has been growing over the years. So we have something like 1000 people, more or less subscribe to the mailing list and we have something like 2000 males, something like that. When I started using buildroot which was around here, 2006 it was more like a few emails a day, 2-3 emails a day, something like that. So things are changing. Also the number of contributors so the people that contribute patches these months have been growing quite a bit and now we are up to something like 30-40 changes a bit from month to month but in that order of scale of people submitting patches. Next to the discussion on the mailing list, we also have an ISC channel but we do meet up two times a year. Normally these things are aligned with the process because people are together anyway. So we have one in February and we have one around ELC next weekend. When we meet up face to face we normally, well the group let's say core developers somewhere between 5 and 10 people and we discuss various things that are sometimes difficult to discuss on emails. If you are a user of build route and you are interested in participating in the development of this, you are also welcome to join these kind of developer days. Luckily we have companies that sponsor these events because there are typically some kind of expenses involved with finding a place to have these meetings and setting things up for that and I would like to take the opportunity to thank these companies that have been sponsoring us so far. Yeah, we have free electrons, imagination technologies, Google, Synopsys, Flensu Callao systems have sponsored. That's very nice. If you look at what companies are using build route it's of course a bit difficult because in general people don't tell us about these things. There's presumably a lot of companies that are not on this list but a few companies I can mention is Baku where I'm working, we're using it in the projects that I'm working on. Not a very well known company is Google that is using it for their fiber boxes in America. Rock and Collins have recently started submitting patches for us so they are also using it and various SOC vendors are using it in in the software delivery to their customers. Admiral is one. Imagination technologies, Synopsys and so on and so on. Good. That's a bit of what built with this. If we now look at what is new one of the new things that have been added within the last year, year and a half is the number of new architectures. The 64-bit version of ARM and these, let's say a bit more special architectures like Synopsys ARC, Blackfin, MicroBlaze, Nios2 Extensa. The nice thing or the interesting thing is the work on adding Blackfin and ARC and Extensa was actually done by the companies making these cheap architectures. That's nice. And we have also improved the variant support. That's a particularly mean to support on ARM for a number of years basically what we supported was software floating point on ARM. ARM has a lot of variations of the hardware floating point support if it has neon support or not and by now you can choose between software floating point, you can choose between the hardware floating point but passing it in integer registers or the hardfp support. So that's nice to make advances of these features if your processors have them. We also have improved the no MMU support for instance in relation to Blackfin for instance. What we have done is that we have annotated a bunch of packages because not all packages works when you don't have an MMU you cannot do the normal fork so these packages just like for the tool chain options about this package you need C++ support in your tool chain it will say that this package is not available and it's not present in menu config. The same about the file format that you generate for these no MMU systems. That's architecture tool chains that thing should add them regularly. For a number of years buildroot only did uselipc and the reason for that was mainly that originally it was created to test and demo uselipc and that's not the case anymore. We can build tool chains with eglipc and glipc as well as uselipc and you also have the options of not always building your own tool chain you can also use an external tool chain already from your SoC vendor or you can maybe use some of these popular ones like the codebends ones the linear tool chains you can provide a complete you can say I use a complete custom one and you have to say where to find it but we also have pre-configured the popular linear tool chains and the codebends ones so you can just go and select them. It's very easy very easily we have been adding support for the Muscle C Library as well as an alternative to uselipc we have also added a lot of new packages lately I started being maintainer in 2009 and honestly buildroot at that time had been without maintainer for a number of years so we did spend quite a lot of time on cleaning up stuff that took a while but let's say the last two years or something like that around here we really started adding a lot of new packages so within the last 12 months we have added something like 30% more and now we add 1100 packages something like that so that's nice what kind of packages have we been adding lately well a bunch of multimedia stuff mainly G streamer 1.2 Wayland EFL Qt5 Pools Audio, Opus LinFone TV Headend and so on and so on we also have Python 3 by now Node.js we have flash burns we have systemd we also added quite some development tools that are sometimes quite interesting like Perf, LCT, NG Trace Command ISIAC that are sometimes indeed stuff that you that can be interesting to have on your target some of this stuff the multimedia stuff was done in context of Google Summer of Code where we this year had a student, Spencer with Thomas as mentor and Spencer was working on adding support for all these complicated packages for SOC specific hardware acceleration so for GPUs and for the video acceleration and he added support for the GPU drivers on the TI components the Mali on Alwinner GPU on the IMX series IMX6 in this case and Raspberry Pi support and similar for the video acceleration it was also Alwinner the IMX and the Raspberry Pi this means if you if you're using any of these SOCs the hardware acceleration support looks a lot nicer than it used to be and the way these things have been added means that it's quite easy to add new variants now because there's a concept of multiple drivers that can provide for instance OpenGLES support and the rest of the packages that have OpenGLES support knows how to work with these different packages good the way we do quality insurance is well basically when you have an embedded build system or a build system of any of these kind of configurations if you have a thousand packages with a number of sub-options number of architectures with all kinds of sub-options as well the question comes how do you actually how do you do any QA on this how do you test these things if you just look at the number of combinations you cannot really do this in any structured way so the way we do it is to do random configurations just again and again that kind of architecture that kind of sub-options with these kind of packages with option A on, option B off and so on and we build all the time and with that you catch a lot of corner cases about on this particular tool chain this particular option if that is enabled then this thing doesn't work we do that on a number of servers there's a website you can go to that provides a new view of all the build results so the green things is good the red things are not too good and we also generate a daily report and we have a look at this package that were upgraded yesterday tends to fail now on let's say PowerPC let's have a look at what that is so that's really something we use a lot when we do the development to make sure that all kinds of combinations that you will end up using will actually work because that could otherwise very well be a problem the developers use this kind of system and it all seems to work and you go and download a new release and you have something a bit different and it blows up in your head and it doesn't even build next to that we also have split up the development cycle so the three months we really have two months where we do development then I put out release candidate one and then there's only bug fixes until the final release gets released at the end of the month and of course if then a problem happens then we do a bug fix release like what we've done this time so the latest release is 2013 08.1 because we do last minute issues that were found what we don't do here at least is any kind of runtime tests of course here you just check that things are building but you don't really know if it works it's quite tricky to do for all these kind of combinations typically need all kinds of different hardware so that we don't do the hope is these release candidates and notice things I use build with myself at work so I tend to test it as it gets released but other than that there's no real structured way that we do runtime tests okay well it's better than nothing still next thing that comes up with these kind of things is license compliance build with itself is GPL2 and a lot of the packages that you tend to use in the system are also GPL if nothing else then the Linux kernel and probably busybox maybe U-boot and these kind of license have certain things you need to do and in general build system makes it easier for you to do all the build steps and it would be nice if it would also make it easy for you to do this license compliance the way we are doing it is that we have annotated our packages with the license they are so in this case Gzip is GPL3 or any later version and the license file is called copying like from most other packages as well and what we can do is that we have a make tag called legalinfo that can generate a manifest of saying this configuration contains of these and these and these packages these packages are on the license this and this and this the license files are here with sometimes more information or more details not all packages are as simple as this sometimes you have this part is under that license that part is under that sometimes it can get messy do you have a copy of the license file with these packages? of course that's in the case of GPL also a requirement and you have to build with configuration now you have to understand this is support for doing your license compliance cannot solve all your problems but at least you have all the data that you need in a condensed form but you still need to look at it and see if you don't have any kind of conflicts or any kind of proprietary applications that links to GPL license libraries or maybe even license conflicts in the sense of BSD with an advertising clause and a GPL thing like you have it open as a cell those kind of things we don't try to see if there's some kind of combination that is not allowed in that sense it will become very very difficult to do with this information and you can review it or your legal department whoever does these kind of things can do it for you so that's also a relatively new feature we have in build route we also have an eclipse plugin for doing development package development using your cross compiler so it's something that makes it easy to find the cross tool chains that you built with build route and set it up correctly so that you built with that one it finds the right pkt config files and so on and so on well say personally I don't use eclipse sorry don't know a lot about it but it's there we have also added a number of configuration files for popular boards to make it easier to get started on these kind of boards we have the beagle bone we have gubi board we have nitrogen 6x which is an imx6 board the aspen pi the van board which is nice if you have that kind of hardware but if you don't the qmo variants are also quite nice because you can easily build something you can run inside the qmo virtual machine I use this as well for testing quite often on my pc so I can easily build a kernel that matches a certain qmo configuration and a root file system that can be fairly handy to get running in a fast way historically everything in build route was running as root we only had some pre-determined system users and it's not really flexible if you have a specific package that would like to run as a non-root user because you could come up with your own root file system skeleton and you wouldn't have these things in there so we added some infrastructure that the package can say I need to have a specific user and it has to be called this and this and this and then the init script will start up that daemon that's that user so you define something like this this is from a package called tvheadend that we would like a user to be added called tvheadend we don't really care about what user ID or what group ID it is but okay, users should be tvheadend groups should be tvheadend the home directory should be that and it should be in the video group and then build route automatically add that to the ETC password and ETC group files when you build can sometimes be handy good that's all kind of features now, if you want to use build route to build a final system which is presumably why you're using it in first place you typically want to do some kind of customization can be small things, it can be big things and we have added a number of features to make it easier to do these kind of things there's some very simple customizations that everyone wants to do and for those we added options in menu config for for instance, you want to set the host name or the login banner or you want to change the route password or you want to choose on what serial port should the login program run on those things almost always need to be changed so we simply add menu config options for these it's very easy to go and change sometimes that's not really enough, you might want to do other things so we have a concept of overlays of extra files you want into your file system one or more of these directories and whatever is in there you can just add it on top of the default file system so if you have some data files or images for your website or something like that you can add them in there that goes good if you just want to add stuff but sometimes you want to remove stuff or you want to change stuff or you want to do something strange and instead of adding options for all these special things we simply said okay you can run one or more scripts at a step where we have put everything into the file system but before we created our file system images and that's the post-built script so you have added all your files in there and you say okay I'll run a shell script in here and you can say oh that file I really don't want so I'll go and delete that or maybe certain things should be changed so if you just write a simple shell script that does this you can plug it in at the right spot just before you create file system images the other thing that people sometimes want to do is okay they use build root they create a bunch of things kernel image bootloader root file system but actually in order to put them on the target they need to put it together in some special way or maybe they need to create partition table to make an SD card image or something like that and in concept you can do all of these things outside build root because build root just generates these things and you can do whatever you want to do with it afterwards but if you want to put it under configuration and you want to make sure that it always gets done in the same way you can add it in a post-image script so that's just at the very end when build-root is done with it stuff you can go and say I want to put them together to one kind of upgrade image so whatever you want to do with it yes so that's true this is when all the stuff has been added to the root file system but before you create the images so you can remove stuff or change stuff and then once the images has been created when you have everything there basically when make would stop otherwise you can run one more script that's called the post-image script and of course you can always add custom packages you can always add your own stuff like that that's the options we have for customization there's a number of things in progress one of them is if you now do these custom packages then at least some like to be able to keep them separate from build-root and make it easy to upgrade to a new version of build-root and not have any kind of merge conflicts so we're looking at some kind of package overlay support for that we also had some support for SE Linux submitted recently that we're working on getting integrated the systemd version and udev version we have fairly old but we're working on getting that updated and of course anything else that gets submitted by people interested in working on it good any questions? yeah no so what I'm if I can go back one too many what I'm saying is that this is just to support your options we're not going to start saying if you have enabled a certain I don't know if you said I don't want gpl stuff you cannot have a dino's kernel anymore no we're not going to do that because very fast it becomes complicated what license is this exactly on and it depends on how do you use it and how are these things so we have added this just to help because every user through all of these things I'm using that package what license is it under what do I need to do on the top level they still have to see is this even legal to put together like this but ok that's difficult for us to do but we can at least do the groundwork collect all the information in a nice overview so that you can easily assess what you need to assess yes make random package config it's a make target yes if you go back to that the website itself ok I got too far the website itself that collects the information is something that we run and we prefer to have a bit of control over the auto builders because imagine something doesn't work on this one machine and it works on all auto machines and we cannot figure it out then it's nice to understand what is special on or try it again on the machine yourself and look at it but in concept there's nothing secret about it and even the source code of that web application is also available so there's nothing special as such I would say if you are a user of buildroot and you really care about specific configurations you probably don't want to do it like this because you have a specific configuration this is the configuration I care about yes yes certainly certainly where I work we have a number of configurations that we care about and I build those configurations to make sure that they work but for buildroods also projects what are the configurations that are interesting we have these dev configs for a few boards but they are very minimal just saying I need this kernel in order to run on a beagle bone or whatever so they don't really test a lot of things okay caching is a new mechanism or is it just built from scratch if you do an image well you have ccache but other than that there's no caching on it the downloads will get cached but not the build results are not cached so you build them from scratch to make sure that everything is well there's no thing leaking possible to from little p1 package and then this package remover from the final image when it's already yielded no can you add the from a slackware that takes track of what file is installed and the source is possible to revert what is installed in the target directory because slackware has nice things that takes target data install it and it can go back to the installation so this is nice because a lot of times they happen to me that I build for example some package and then I say no I need to remove it and it's not nice and it's very nice to have a target in the main file some things that are very useful for the world that the force they remove of the pre-config so dot build they build that or remove some file that is configured or patched so it's easy to rebuild just one package without going to the directory and remove manually some files there yeah that's possible but to be able to remove a package once you build it and have that robust that very easily becomes quite complicated imagine you have selected open SSL and you have a bunch of packages that you built that have optional optional open SSL support and you go and remove open SSL then you need to see all the reverse dependencies and you need to rebuild all of these things so we don't do it because if you do something then you need to take track of what package you need to remove so it's not the only package so indeed if you know what you're doing and for certain subsets of packages you can do that I do it myself okay I remove that package and I build it again but we don't support it because we cannot support it in all the situations and we prefer to not offer something that sometimes work but it don't always work well right now build route that the top level build route doesn't support parallel builds but each step imagine GC but whatever can build in parallel there's some work being done now on getting top level getting some more parallelism in there but right now there isn't any support it would be nice to have if you need to download big things and it takes a while and those kind of things but we don't have it okay any other questions yes you well it's something that comes up sometimes you have two different pieces of hardware but actually it's the same kind of software you support or you have one piece of hardware and you have two different configurations right now we don't really support it in concepts you can do it because the .config files they're just text files you can just concatenate and I say I have a base config with just the hardware specifics and I have one with a set of packages so you can just put them with cats after each other and it works but there's no we don't have a nice way of saying if you go and then run menu config to split it up again and what belongs in one or the other how to really solve this it's not that we don't care but the question is how do you define what belongs to what it can be what is your definition of the base system it can be just really hardware specific I always have these kind of libraries available they also need to be in there it becomes quite tricky to be able to define this in any way with our minimal configuration files that only have the non default option values so instead of being like several thousand lines there are usually like tens to tens of lines so you can manually edit them and you can put a fragment where you define which tool chain, which hardware and another fragment where you define the base software stack and another fragment with the high level software stack and then you can combine them and it is being cast the first fragment, the second fragment and the third fragment it will direct that in that complete start with your build well it's in and then at the end once you are ready if you want to further refine it then you can really make and you can really work with your interests you have just to correct it yes, yes usually it's I mean, whenever you have a package play equal Y in a file which isn't that difficult the option the older denominator then you generate the definite you realize ok, the change that I need is expressed by changing just this option this way and this other option this way then I'm going to take this change and then put it in the base fragments that I use in all the builds the problem is that as Peter said there is a good way of splitting that thing for some people it's a hardware as we talk to our stack split from some other people it's a tool chain versus hardware plus software stack or some other people it's hardware on the west side the base of the stack and the high level software stack so there's no way we could organize that kind of thing to manage it I think the way we if we want to solve that problem I think the way we do a little tricking it's common that you want to do something special but it's always different what you want to do so maybe we could come up with some kind of a hook before menu config make menu config and a hook afterwards and you could say I'm going to write a script that says ok I'm going to split it up I'm going to take these three files put them together first and another script that splits them out and it would be then structured yes but if you put it in the script ok you have to stop if you put it in the script at least it would be you would make sure you always do it in the same way that's basically the same about these hooks the reason why you want to have them in build route is just to make sure that you can always build the same thing it's always reproducible ok we out of time