 Welcome to this very last slot here today. My name is Sascha Hauer. I work for Pangotronics which is a small company in Germany as a kernel developer and Well, yes as a bootloader developer For today Mostly have a simple mission mission and it's only one. I Want to tell you about bootloader specification, which I think we need And Because that's probably not enough for this slot. I'll tell you a bit about barebox infrastructure and device trees Multi-image support and some additional goodies so Why do we need bootloader specification right now? We have the situation on at least on arm that Kernel and the root file system were quite good together, but there's a disconnect between the kernel and the bootloader because Usually with U-boot and barebox is it's the same. We usually do scripting as Scripting to find our kernel and With this it's really difficult to Get a consistent setup between different boards Basically the scripts are there. They do something. They usually find a kernel and start it But this looks completely different across different boards so Let me let us have a look at the different distributions Right now here for example Ubuntu. It doesn't really support arm It supports the I mix 53 quick start board. It's supports It says omap 4 but if you look have a closer look it says omap folk panda board omap 3 No, it's only the Beagle board and a touchy by AC hundred the this list isn't complete there are other boards Which are supported and Sometimes only a single version is supported and the next Ubuntu version Supports another set of boards similar with Davion they support some Selected socks like the Marvel Kirkwood as a very popular one Fedora it has a different set of boards. Hey, it supports the Beagle board and the panda board but It all is the same. There is no General on board support, I mean it's always possible to to somehow install Your distribution on the board Basically, you can get a root file system and You're on your own. It's always possible to start it somehow and if you look around the internet it there are How-to's for most Distribution board combinations you will always find a how-to, but I said there's no general support Instead only support for certain arm-based boards For it. This is not only the fault of the boot loader. There are some other things missing but For sure the boot loader plays and plays a good role. So That's the situation we currently have and yeah, looks like this old Microsoft commercial For those not native German speakers an open operating system doesn't only have advantages, so I Think we have to sort that out So let's create a way to independently Install a kernel on a board There's another problem Generally with your boot or barebox. You can only have a single corner installed and As usual there are ways to get around this but they are not board agnostic Images yeah, you can create images but they usually for a single board and All this Makes kernel updates risky because the Distributions normally Make certain assumptions on the board and which boot loader is on the board and where the boot loader searches for its kernel so yeah, you have to know which board and You have and yes, this all is a risky process when you Be there without a corner So instead of having this which requires an Arrow between each combination of distribution and Board let's do something like that where We simply put a well-defined way how to start our kernel between the boards and the distributions and That's what the boot loader spec says about this it's created by Kai sievers and Harald Hoya Leonard potmuring was also involved. It's on free desktop org the specification And it says currently there's little cooperation between multiple distributions in dual boat or triple Multi-boot setups and we'd like to improve this situation by getting everybody to commit to a single boot configuration Format that is based on drop-in files. That's robust simple works without rewriting configuration files And is free of namespace clashes note. This is for x86 but Why shouldn't we use it for arm as well and That was what I implemented for Bear books and It's really simple like that the specification only specifies a way to Find the boot partition on a certain device and so each boot partition each device each SD card or use B stick or whatever you have Has a single boot partition this is shared across different distributions which are installed on this device and In this boot partition, there is a directory named loader entries and it contains a single text file per entry And in this boot partition, there is a Sub-directory with a machine ID. It contains the kernel the init ID Device tree files or whatever else is needed to start and Next we have a single There was another slide Here's how to find this boot partition on the device on devices with Mbr with a dust partition table. It's simple. It's simply the a petition with a type Zero X ER EA Once you find that, you know, it should be used as boot partition The boot flag is ignored No, it's just like 0x80 is I think EXT2 and C is VFET for Windows On GPT disks, it's simply the petition with this GUID here, which I'm not going to read On UEFI systems Alternatively the ESP partition can be used And this partition is shared across all installations on the device What I have next is a Single entry which describes a one kernel to boot and It looks as simple as that We have a Single config file, which has a title. This is shown to the user. So He knows what to select, what he will booting. We have a version field Basically It could be used to always start the newest entry or something like that. Right now. It's only informational Each board has a machine ID. It's basically the same as Find under The options field is simply passed to the kernel It's better here in this case. It's it only specifies where to find the root file system But you could also specify Yeah, the user the usual stuff where which console to use and The next entry simply specify where you find the kernel the init ID Or and in this case Device tree the important thing about this is These paths are in the very same petition as the entry. So there's no No way it's not in the specification to to find some other petition or even some other device so this Bootloader specification is simply about the single single device a single SD card or a single USB stick and Basically this is about it Yeah, right good question the question was whether it's fat formatted it's Recommended To format to use fat file system. You could also use ext2 or 3 or 4 This is also mentioned in the specification, but yeah in theory you could use whatever you want Whatever your bootloader and the kernel can read Yeah, so you you have to really choose something your bootloader can read and it has certain advantages to use something Your bootloader can even write Because then it could manipulate the petition the entries Pardon, could you speak up? Yeah, he asked whether this is like rap and Indeed there are certain parallels because the grub has a manual list and It specifies the same things but the Main difference is that grub specifies a single file for all and If you have multiple distributions on the same device, it's not clear which distribution should write this single entry Where as this one is the bootloader spec is based on multiple entries So and this is said to be shared between distributions So each distribution just creates a single entry and it won't conflict with the other entries That's a big advantage of this behavior Yeah 6 a 9 8 is just a machine ID. It's a placeholder. It's just a Hash which is used which should be unique for each distribution. It's normally randomly generated during installation of a distribution and The question is It tells him which the the 6 a 9 8 tells which machine it is it's It can be used to identify it but It a set it's randomly generated during installation of the machine. So if you The bootloader simply reads the bootloader entries directory and parses all config files and The 6 a 9 8 is only a way to to come up with a unique directory where the files for the certain Distribution can be installed. You see Down there the linux the init ID and device tree files are also installed in this directory and So each distribution can have Its own directory where things are installed without conflicting with others Yeah, that that's right once you install Yeah, yeah, if you No, no, no Alright But you're right if you install Fedora on the same machine twice you get Different machine IDs each time Yeah, it's I haven't thought it out this name. It's basically Fedora and PTX just based and I think other distributions do it as well have this file named ETC machine ID and Yeah, the semantics is Like like I described There was another question the question was if Machine if a kernel can boot on multiple machines How does this does this match with the single device tree that is here specified because different machines require different device trees and with The entry here will boot on a single machine only that's right A gen if you have a generic Image that shall boot on multiple machines would just skip this device tree entry and Rely on the device tree firmware would provide you once again, please Where does the device tree come from either you with barebox you can Nowadays at least on IMX Tegra It probes itself from the device tree it has a device tree compiled in which it which barebox uses to probe itself and It just you it's used to to pass this to the kernel or you can store Another device tree in the environment could we Do this later because I have some slides in this which also Mention this topic. All right We have a copy of the device tree source files In the barebox source code these are compiled into barebox during compilation That's one possibility These device trees are used to probe barebox itself and the very same device tree is then passed to the kernel That's one possibility the other possibility is that Barebox itself might not use the device tree Because the architecture doesn't support device tree yet In this case you would store and a Device tree in the environment wherever this may come from you have to supply it by you can download it by Networking or Whatever you have to supply it manually Or Different Solution you could download a generic SD card image for your distribution which Maybe Has this An entry like this without a device tree and you manipulate the entry to actually supply it Device tree the device through you want to have for your board But then of course you won't have a generic image anymore There can be multiple of these entries You can Specify different device trees with each entry. All right The bootloader does not know which one to pick. Yeah, let me just continue the Because this is covered later Yeah along Along with this Here's a screenshot from my Africa and make smart smart book Along with this bootloader spec. There's this kernel install script And it can be used to to manipulate entries. It can be used to create entries or To make entries the default So what is here is kernel install minus a for add an entry and we have kernel version 3.12 Rc6 and specify a way to pass to the kernel image to install and this is enough to actually install a new kernel entry and There are similar commands to to remove entries and Or to change entries This tool here is Running on the system on the distribution that should It's in running a native mode But you could also run the same tool on a host for example, so you could So maybe you have messed up your system or Want to create a new system you messed it up you Pull the SD card put it in your laptop or wherever and can use the very same Kernel install script to to fix it again So this is a similar kernel install script is part of system D already and That's the next thing Bootloader spec is already implemented By Gummi boot, which is a UEFI shim boot manager implemented by Kai Severs and Herald Hoya they Actually had the problem that even the UEFI boot mechanisms were not enough for them and that was that was Their motivation to to write the gummy boot and this whole bootloader spec if you Like grub more then there's Already a patch for this So grub can with a patch read this bootloader specification as well and that's about it Yeah, you should implement it for your bootloader because It makes SD cards and stuff like that introspectable and even if your favorite bootloader is not barebox You could use it and then we could Exchange images between different boards Already set most of these And this answers your question a bit What's missing right now in the bootloader spec? There's no way To specify Which entry should be the default? It's not part of the specification So right now it only gives you a way to Give the bootloader the information Which entries are existing? but you would have to implement a bootloader specific way to To actually choose one of them that In barebox you have the possibility to either it reads a default entry. There's the file named default So it picks this entry and Just starts it There's another Entry it's named once and If it finds a file named once it This file should contain a config file or a path to a config file and the bootloader would Erase that file and start that one so that then this once entry is Executed actually only once and then next time the old entry is executed again So it's basically a way to specify To test a new entry What is also missing is There's no Nor on end device support yet because the Specification is coming from the x86 area and they simply don't have these devices. They're not interested in it so maybe We should at some point at this but SSD cards and emmc cards getting more and more and No, no, no, no nant devices are becoming much more seldom This is Not on the top of the priority list. Yeah, Paul so Yeah, so Pavel asks What's the difference? The difference is On non-nant devices you can do UBFS Which most people do or jffs to or whatever you like and Put the same Specification on it. That's no problem. You can do that The problem is only that With SD cards and emmc cards you have the partition table on the device itself and Can look what you have and look for the slash boot partition with UBI FS or MTD in general the Partition information is outside of the device and has to prove be provided from somewhere else So as long as you skip that step and say, yeah, I'm using this petition as my boot device The same will work with UBF UBI FS as well But I'm I currently hesitate to say we do it like that Because I'm really happy to actually implement a specification that is that someone else is written So we don't do our own stuff, but Yeah, there are at least two of us Who do the same stuff? Which is actually good Is there more for bootloader specification mark Mark asks whether I know the fit image which is used in UBOOT and how does it compare on the I know fit image. I haven't tried it, but I know it. It's Correct me if I'm wrong. I think it's basically a device tree snippet which contains Several informational stuff Yeah Of course it does because Yeah, the fit image Provides a way to start a kernel, but how do you find this image? It's not specified No, this is exactly what the bootloader spec describes. It describes a way to introspect an SD card It exactly describes where on an SD card I find a kernel But On with fit image, there's a way to find a fit Once I found the fit image I Know what to do, but it's not specified how to find this image in the first place Yeah So the question is basically well, why don't we reuse the grub configuration that's already there And I think I answered that already the grub specification has One big blob file Which must be managed by a single Distribution So once it's the same on your PC once you have Fedora and Zuse installed on the same machine You still can only have one grub installed and either you use Fedora to to install the grub or you use The the other distribution to install grub because there can be only So you're saying that it's possible to use to boot up Fedora and How's it called on grub? I think it's grub install. Is it that? I only know that for example on Debian I do up get install new kernel and this kernel will be installed and it usually assumes that The the grub configuration is controlled completely by the system. I'm currently running It won't find any other Entries that are there You start by doing nothing They say you need to install Fedora You can just divide it by five countries and put the machine in the Fedora the front Yeah, I'm specified by grub Now you have the specification how to do this. That's the good enough to explain. That's all about it. It's a bit Simplified from the grub copy Because you don't need all those things that are possible in grub like finding other devices because we're defining we have a single boot rotation and yeah, it just simplifies things a bit and makes it more robust And what I can say is the patch for grub 2. It's a hundred lines or something like that so it's not really invasive and And If you only take the things that are actually Needed then what's different? I mean If you strip away all the rest I don't think the configuration we have now The And then compile one Or it won't touch it other possibility And basically we're mostly talking about embedded devices or Devices that are not so embedded anymore because they're arm laptops now and we don't have grub there so Maybe that would be different if grub would exist on arm as well. All right Don't have that much time left so I tell you something about Bearbox infrastructure It's not much and we're more in the commercial corner now As mentioned before We Support device tree on certain different levels on device and bearbox the IMX Devices can basically be completely probed from the device tree. So it's very simple nowadays to make a new board pod just write a device tree and If you're lucky, of course, you're not always lucky but if you're lucky your board already comes up with a new device tree and You can use this very same device tree and pass it to the kernel and this will start as well. I Often I already made the experience sometimes that Once I've done my bearbox port and that's written a device tree the corner already comes up and That's quite amazing and the same works with the taegra To a certain extent because taegra is not so good Supported in bearbox and with the sock FPGA stuff, of course If you use the same device tree for the kernel for the bootloader, then you use for the kernel it this requires some stability and We've discussed very much about this this week some people say the device tree should be Just unstable just change every kernel version and I was really quite against it and Because I as a bootloader Montana want to use the device tree for the kernel and for the bootloader So hopefully we came up with it not with a solution But we agreed on that we do not needlessly Change the device tree bindings Because it causes causes pain But Nevertheless, they will change He that would be one possibility to flesh a new bootloader with a new device tree, but Yeah, nowadays deep-breaking devices is Possible you don't have to have a JTEC to rebrick unbreak devices, but There's another way you can Simply update the device tree This would be Yeah, this is currently something that Also lacks an API between the bootloader and the kernel because normally you want to start a kernel and you have Want to have a unified way to Update your device tree, but this doesn't exist yet. Nevertheless, you can use bootloader spec to update To add this device tree thingy and Add a new device tree. So I basically think that it should be possible to To Let the device tree be so stable that it it's at least enough to bring up a kernel Which is then able to install a newer device tree which enables all features of your hardware Another thing that we gained recently is the multi-image support Which is very handy because you can use the same configuration to build from multiple boards it basically means that we have less variance to compile and I can just compile and Pick up the one of the images below there and Yeah Just choose the image that matches my board. I Have on the desk It's really handy because we have Also have better compile coverage With less effort Currently this is limited to a few architectures, but hopefully They will become more over time What we also gained is a detect mechanism. We used to have different USB Detect mechanisms, so you would have to type USB to detect all USB devices or with MMC. It was a different command and now we can simply call detect unified for all devices and It would also be possible to do a detect minus a which would simply detect all devices So it's really handy to do this and to see how my system is made up similar we have Mount minus a which would detect all devices and then mount all partitions that we find This is again on my if you can make smart book and to see in the last lines Oh, it found the MMC card and then found the fat file system on this card And it would just mount it to a known path It's really nice Yeah so on the miscellan on the misc side we have generally postic style programming API and So you would have to call open close read write just just the regular stuff. Most people know from user space already Okay config is used for easy configuration. So you can just enable disable features and Of course, we have the regular file commands. You already know from the shell Magic where Va is a nice stuff because we sometimes have the need for variables with a special meaning and It's not nice to Use this variable and just hope that This variable is interpreted in this special version of the bootloader So we have the command magic while that's which is only a informational command Which shows you which magic variables are available along with a description of this Variable Yeah, you have mount points devices probably know that by now get opt is Nice stuff to to make positional arguments unnecessary So you there's an easy way to extend commands, but with new options and probably lots of more stuff as well and Yeah, that was it from my side Are there any questions? No question Actually Actually I was asked Who who who was this guy who wrote Linux device drivers Know the the Italian guy Rubini he asked me whether he could ask one of his students to students to make barebox a real operating system so far he hasn't started but Maybe next year, I don't know yeah, that's Yeah, this often comes the comparison to an operating system and It's yeah, why not it it must I mean all this must be small enough to to Fit into the device, but as of now, I don't think it's even bigger than you would is from binary size The question the question is whether I can boot the same image on different boards and Basically the with a multi image support. There's a one image embedded which Could be started on all of these boards, but you have to to pick one of them Which has a single device tree to actually make that bootable so if you in theory if you have a Way to detect on which board you're on There's nothing preventing you to to start on multiple boards. Oh I don't think there's infrastructure missing To do this although it's not explicitly there there. I don't think there's anything missing There's nothing that prevents you from doing so it wouldn't be much code actually And then choose the correct Yeah So I think we're out of time now so Not much much left to say except thank you very much for listening