 So here we're checking the embedded-based boot requirements, EBBR right here. Who are you? I'm Daniel Thompson. I work at Leonardo in the support and solutions team and I'm one of the EBBR committee members. So EBBR is a big deal that's very important and that's happening right now? Yes I think so. So the key thing is we've had fragmentation in the embedded boot space for a long time and there have been some significant changes that allow us to look at addressing that and the most significant is the U-Boot which is one of the most popular embedded bootloaders has been modified by Alexander Graf to become a EFI implementation which means most of the embedded community based on U-Boot on Tiana Cork can then unify around the same boot architecture. And right here you're showing some stuff plugged in around here. What is that? We've got a bunch of boards and we've got three embedded, four embedded boards and a big board. So we've started with this is the developed box. This is here to point out that SBBR... This is your main desktop? It is yeah you've got to spy the bug. So the reason this is here is that it's a server based system and EBBR is compatible with SBBR so any SBBR system is automatically EBBR compliant so we're trying not to fragment the space we're staying as aligned as we can to server systems and then we have four small Singapore computers all running U-Boot. So in particular on two at the front the Raspberry Pi and the Dragonboard 410C are running mainstream mainline unmodified bootloaders that we compiled on Wednesday from the U-Boot sources. What is this one? That's a pine 64. Pine 64 right here. And that one again that's connected to this serial console up here and if I reboot it this one is particularly interesting because this is running Linux. This one currently has a stick implementing 3BSD on it. So we're currently in the bootloader. What's happening? It's about to fetch the EFI payload from the USB disk. In fact the USB has me to take from the Dragon. It's about to detect the USB stick and fetch the EFI payload from the USB stick. So that's going to come through now. It's not from the storage device again but we've tried different slots. So this version of U-Boot only sports the bottom slot I remember. Yeah because I just got you to reconnect everything Yeah yeah so I did move things a bit. There we go that's when it's found the storage device. So the storage device has been found it was in the right slot this time around. That's going to then load an equivalent of perhaps this is a 3BSD bootloader an EFI payload that's coming up and then in about 10 seconds time when that finishes it will be booting the operating system the kernel from 3BSD. So like I said huge credit to the 3BSD guys for all their work making this work on the board. We've simply standardised the boot process just ahead of it to make their life easier. So you standardise the boot process ahead of it? So all these sticks are the unmodified ice images from the distributions. We've got Debian, OpenSuser, Fedora and 3BSD and they're unmodified. So we've now provided the means for these embedded boards to load the payload on those USB sticks. After that all credit goes to the distros for their hard work and for the kernel developers to be upstreaming and everything else. So even guys simply the matter of getting that first bootloader off the media and into memory. So why wasn't this existing before? It's fragmentation so all we're really doing is trying to reduce fragmentation. So it's not all these boards used to boot an operating system. They all used to boot Linux. Very few of them used to boot 3BSD but they all used to boot an operating system and it all used to work but they all used to do it a different way and that meant that you couldn't take standard things like the Debian installer and have it work. And that's what EBBL is all about. Why didn't you just agree to have a standard from the beginning? I can say, I mean it's just the way life pens out when you're working in ecosystems where there's not an economic incentive ultimately. We believe that even when you're not doing distro boot that you can still save money by having this in your infrastructure. Because they will standardise upgrade flows. So now we believe the economic stars are aligned that this would now be good economics to implement and I think previously it wasn't. Good economics and now everybody's agreeing this is a great standard? The committee certainly believe it is a great standard. I mean for other people to use the standards you have to us then we're here to socialise it and to get interest in the specification. Ultimately it's a tiny, tiny extension to EFI. So we are relying on EFI as the base standard. We're simply almost like a profile, a specific way that you might choose to implement it to get some useful, useful effects. And what's your role in that? What do you do? I'm a committee member and I also have a few commandment and secretarial roles helping the project, looking after the GitHub repositories, things like that. So Dong and Grant kind of run the show. They own the spec. It's a completely open process. You can join the meetings which are every Thursday. Anybody who wants to come and join joins those meetings and comes to talk to us a bit about how exciting producing is.