 So we're here at the NPR Connect and who are you? Hi Charbox. I'm Grant Likley. I am Senior Director at ARM and I have been involved with the Linux community for many years. So what's the latest that's happening? What are you working on? So I've been working on a project that's called EBBR or Embedded Base Boot Requirements. And this is a project, it's the stuff that most people won't see, but it's with regard to how firmware is set up. And when you take a look at PCs or servers or laptops, they all have a standard boot interface. So the Linux distributions like Suze and Debian and Red Hat and Fedora are able to rely on that firmware to boot. You put a USB key in and it boots the system no problem. With the embedded system, especially like 96 boards or all of the Raspberry Pi, similar boards like that, none of them have any firmware interface, firmware standards, they're all different. And that makes it really hard for distributions to support. So the distributions, they've been struggling with this problem. They want to support these boards, they're interesting. But they need, they can't do a separate image for every single board. So EBBR is a set of requirements that takes the software ecosystem and the software that's already running for firmware on these platforms. Most of them are running UBoot. And it adds some standards to that. So it adds, for example, the UEFI API. And so UEFI is another specification, it's a standard that's implemented on PCs. And so UBoot has gained the ability to do, to provide the UEFI API, which means that the standard OS install tools, like if you take a USB stick with a regular Linux distro, a device that's EBBR compliant will be able to boot it. And that's a big change from the way that most of the embedded platforms are where you have to go and get a special image and do some manipulation or some change in some files on the SD card before you can get it to actually boot. So is it a requirement kind of guidelines that everybody has to follow? It's, for those who want to follow it, and I think the distributions are going to require it for support. But yes, it's a set of requirements that they have to meet. So they have to be EBBR compliant, they have to provide the UEFI API at boot time. They have to provide PSCI for doing CPU control. And they have to provide a device description, so either a device tree or a ACPI description. And the way that we've designed EBBR is we've got another specification in ARM called server-based boot requirements. And these are parallel specifications. So the server-based boot requirements are very strict. You will use UEFI, you will use ACPI, and it restricts the hardware that's allowed to be used. EBBR opens it up to all the embedded development works. So that allows us to support those by relaxing some of those requirements. But it's still usable by the distros. And then the other thing that EBBR does is it gives guidance on what to do with embedded hardware. So on a PC, you will have a separate flash device for storing the firmware, and then you'll install the operating system on an EMMC or a disk or something like that. With an embedded platform, a lot of the time there's only one flash device, there's only one storage. So if you're storing your firmware and your operating system on the same device, then there needs to be some standards on how that device gets used to make sure that one doesn't overwrite the other. Because if you overwrite the firmware when you update your OS, you don't boot your OS anymore. So it's part of the distribution of the image. It's not on the chip or anything. An EBBR compliant platform, it could be on the chip. That is an option. EBBR doesn't say anything about that. EBBR has preference for firmware being installed directly on the board so that then you can boot off of USB and then install to an onboard device. You can also prepare an EBBR compliant platform. Like if you've got a Raspberry Pi that boots off of SD, you can put EBBR compliant firmware on the SD that boots the platform and then it will go and load an OS from the same SD and that's fine. But that's still an advantage because, for example, for Debian, when it updates its kernel, it can do kernel updates exactly the same way that it does kernel updates on a PC. It takes the kernel image, it puts it onto the file system and then it updates the grub configuration file for the new kernel. Well, with an EBBR platform, that all works in exactly the same way. And so the distribution doesn't need to go and manipulate firmware settings to do the normal operations that it would do for upgrading the OS. So is this something that's been in the idea's drawer or what's it called for a while? Or is it very new? It is. We've been working on EBBR for about two years now. So it came up at Lunaro Connects seriously. Let me see if I can remember. A year and a half ago, actually, I think it was that it first really came up seriously as we need a specification here. We drafted a specification internal to ARM. It's called an EBBR. Did not get a whole lot of feedback or a whole lot of engagement with it. About this time last year, we decided that this wasn't working very well and so we changed it. So now, EBBR, I mean, it is a specification. It's just a document. But we're doing two things. One, we're developing the document in conjunction with Uboot. So anything that's in the document is already implemented in Uboot. It's not something that... There's already all the code that you need to be EBBR compliant is in that stream project. The other thing that we did is we turned the EBBR document itself into an open source project. So if you go to GitHub, ARM Software, EBBR, you will find the source files for the next draft of the specification. And we accept contributions under Creative Commons by SA license and using a developer certificate of origin or TCO process. So it's completely open. Anyone is able to be involved with the specification and develop it so that it's useful for the embedded market. And this is not existing earlier. Is it one of the things that kept ARM a little bit back in terms of there was too much fragmentation? Yeah, it's part of dealing with the fragmentation. And I think you and I have talked previously about the work that I've done on DeviceTree. This is more of the same. Where DeviceTree has provided a mechanism for doing all the embedded boards and described the boards to the kernel, EBBR now says DeviceTree needs to be provided by firmware so that the operating system doesn't need to know any platform, doesn't need to have pre-knowledge of the platform. So the work you did on DeviceTree is everywhere, is all over the place? Everybody's using this. Yes. And why is it so great? I mean, what's so special about DeviceTree? Because it changes from a mindset of you build the kernel for each and every platform to being data-driven. And it's just, it's valuable to be able to discover what's running on your hardware. And when you're, there's an awful lot of platform hardware that you just can't detect. It's not discoverable. So, DeviceTree has been significant because it's a language for things that aren't discoverable. And it's a common language, which means every single platform can go and implement, can go write a description of their hardware. As long as the kernel has device drivers for the hardware, it's able to discover it through DeviceTree and use it. And you're the maintainer of that? I'm not the maintainer anymore. Rob Herring has taken over maintainership with DeviceTree. I still own the DeviceTree specification, which is another document that is on GitHub and we're using an open process for the development of the specification. But I don't do any of the engineering work anymore. So, you like doing engineering kind of like the stuff that goes everywhere? I really did not expect. I did not intend for it to be as important as it was. I was surprised. I'm still surprised with how many different areas or how many different things people are doing with DeviceTree. And it is a privilege to be able to be involved with defining a platform and that having impact on a lot of different areas of industry and also not just the industry, but also hobbyist or prototype projects that, I like the people who are doing crazy things. I like the people who are doing things that no one else has thought of. And the way that I view standards like EBBR and DeviceTree is it lays groundwork. It says, here's some ways to do this so that you don't have to worry about the boring stuff. You can then go off and do the interesting things that you care about. But when you create standards kind of like basic kind of let's say most important standards, it has to be so like clean and perfect and stuff, right? I think that's... Is it like a lot of design thought that goes into that? So yes, there's a desire for standards to be really specific. But that can also be a trap because if too much emphasis is put on getting the standard absolutely perfect and covering every single one of the areas, you'll never release anything. So the view that I've taken on that is the standards are... I'm interested in releasing standard when it's useful. If it's a useful document, then it makes sense to release it. And if that document isn't perfect, that's fine. Because that document can always be iterated. It can always be resolved. There is a little bit of engineering on how to choose, how to make good decisions that aren't going to cause problems in the future. But a standard doesn't have to be perfect to be useful. And then if this works out, that means enable a lot of cool things. Yes. That will make ARM much stronger? It will. It will. It'll make it easier to use ARM platforms in all the places that ARM is being used. So is it ready? There are EBBR... Well, okay. So EBBR, I've got released a 0.6 pre-release. There's going to be another release in a couple of weeks that has some updates to it. Aiming for a final release beginning of December this year. But there's already all the code. So in Uboot, support for EBBR or what we're doing with EBBR is already there. In fact, a lot of this work to get UEFI into Uboot has already been in progress. A bunch of it's already been done. And this is making sure there's a specification that lines up with that so that there's guidance on how to use that functionality, how to turn it on and be able to have that booted interface. Does that mean we're going to see, thanks to this, it might be part of helping us get more on laptops, desktops and all these kinds of things? Unlikely on the laptops and desktops. It might. And if it does, I mean that's I have no problem. I might be thrilled. I think for the laptops, for the form factors that are out there right now, at least the ARM laptops that are running Windows, they're all ACPI based. So they're going to be SPSA compliant already. They're already going to have a lot of the things that are talking to it here. But who am I to say? I don't know. If there's platforms that choose to implement device tree, device description and they choose to use Uboot as the firmware, they would be supportable by all the major Linux distros. All right. So it's exciting times and some very busy and archmage for you, right? Very busy and archmage. I always go home tired.