 Good morning everyone, well I'm actually quite surprised that I've got so many people here when I'm competing with a number of other talks and it's nine o'clock in the morning, I suppose it's early enough in the conference that people are getting up. Thank you very much for coming, my name is Grant Likley, I am an engineer at ARM working, I've been involved with the Linux community for many years and I am here to talk about something that I'm hoping is really boring because it's about standards, it's about making things just work, rather than exciting new features or things like this. So I've got a short talk here on a project that I and a number of others in the Linux community have been working on recently to make, when we're doing embedded systems, to make it a whole lot easier to get past that stage of being able to boot, being able to manage, being able to update the system. And the project is called EBBR. EBBR stands for Embedded Base Boot Requirements. So before I get into that, I want to talk a little bit about the history that we have with firmware in the computer industry. So I mean, for a lot of you this will be, this is not new information but I want to kind of take it from a particular stance. With the, in the desktop PC server market, we've had for a long time, right from very early on, there's been a very strong push towards being able to, the hardware vendors produce their hardware and then we've got a number of OS vendors that want to run on it. After very early days, it became very, very obvious that the software vendors, the OS vendors, could not support all the hardware that was out there. There was just too much. And that drove a whole bunch of, there was the exhortation that end users would be installing their operating systems. It drove a lot of horizontal integration. So the PC vendors, they cared about their hardware. They didn't want to have to deal with the software. And so you've got that tiering that goes on, which requires, which creates just a combinational explosion of the number of situations that you can get in of the different pieces of hardware. This required standardization. This was actually an economic incentive that the companies that were involved, sometimes happily, sometimes kicking and screaming, they got involved with standards and they had to make their products conform to standards to allow for them to play within that market. Those of us who build embedded systems know that that market, that doesn't work the same way. For most of our embedded systems, we have one company that generally makes the hardware. Usually the same company has direct control over the OS or at least the one company has control over that final product of the board, the SOC, the software operating system and the applications that run on that. It's all bound together and it's managed by a single place. That vertical integration is great because you can go whatever you need to do. You can go in, you can change it, you can make it work the way that you need to. And some have said within the embedded community, it's like we don't care about standards, which I don't think is entirely true. We do care about standards, but often the moment the standard isn't actually helping us, we go off and redo something else. We do what we need to because of our tight time frames, because we've got to get products out of the door. We just want to, we do what we need to to get done. But when things do work, when the standards do work, it helps us long because that's one less thing that we need to be dealing with. So the economic incentive just happens to be not there and without that economic incentive to make sure that we've got standards in place to boot, it just doesn't happen. And so, and not from malice just because we've got other things, we've got better things to do with our time. Things are getting more complicated. We're getting more capable on what kinds of hardware we're able to produce. We've got a lot of SBCs now. 15 years ago, it was only engineers with large budgets were able to get access to a lot of the development boards. There wasn't a whole lot of hacker boards that were really available and there was a limit to the amount that you could actually do. Things have changed quite a bit now. I mean, we've got just an explosion of kind of single board computers that are available to hobbyists, to companies that are wanting to start prototyping, get a product out there for a very low cost. And the software stacks getting a whole lot more complicated. Where a lot of applications a number of years ago, we're probably, you know, we could probably do it with the Linux kernel busy box and then a little bit of custom code on top as we're getting into IoT devices, the capability, the amount of software that we need to be running on these devices is starting to get larger. We're expecting more of the devices, we're expecting to have network stacks, we're expecting to have security, a secure updates, we're expecting to have the ability to keep track of many different visions of the hardware. Because it's easier to kind of get these, this equipment, some companies have multiple pieces of hardware and they need to support it all. But with, you know, how do you make sure that those things all behave the same way? And this becomes, it's becoming more and more desirable to be able to actually use pre-canned distros, even on embedded platforms. So for a long time we were comfortable, we are comfortable with using like Yachto or Buildroot to get an image put together. But now there's also the, well, do I really need to maintain all of that software? Do I need to be the one who's responsible for the kernel and all of user space when the product I'm working on, I'm mostly interested in my application? In fact, if I can offload a lot of that maintenance of most of the software stack to a distribution partner, whether it's a traditional distro or an embedded distro, there's lots of options out there. That means that there's less engineering work that I need to be spending my time on. So there's an economic, there's starting to be an economic incentive to make sure that these embedded, these traditionally embedded platforms can be supported and run with existing distributions. So for example, the Debian's, the Suze's, the Red Hat's, Ubuntu's of the world, should it be possible, you know, should we be able to put together and boot an embedded system and all of these SBCs that are easily available with these standard platforms? I think we should be able to. The distros certainly think we should be able to, but it's really, really hard. Every single SBC that's out there has a different, you know, we put Ubuntu on the board and quite often the install, the way that Ubuntu is configured behaves slightly differently. There's slightly different boot scripts. It needs a slightly different setup for the way the device tree is passed through, and it's impossible for the Linux distros, or even any other operating system, to support this beyond just a couple of boards, because every single new board is new engineering effort required. It's also not supportable because the number of board-specific images that we end up needing to have. We've got, not only is it a problem of the boot flow of how do you get from firmware on a board into an operating system, but how do you tell that operating system about what's on that board? Many of you are familiar with, of course, with Device Tree, and you can blame me for some of the pain and warts on Device Tree, but with Device Tree, one of the major things that did, that gave us that separation of board description and the firmware that actually, or the operating system that runs on the board. The next step is to take that machine description and actually make that part of the platform. Once you take those machine descriptions and make a part of the platform, now we're in a situation, if we've got a standard boot flow, and the machine is able to describe itself to the operating system, we're now in a situation where the standard distros can actually support it in their released images without having to go in and hack things around or get a custom kernel to get the board up and running. And then that opens up. Once you've got that ability, that opens up the distros being able to actually perform the work that they do with doing kernel updates, keeping up on security updates, and being able to install and update all parts of the operating system in a standard way. Some of the other problems I've just got on this slide so I don't forget, there's a couple of other use cases in the embedded space that ends up being painful. One is that with embedded firmware, we haven't really had a standard pre-boot environment. So there have been a number of embedded platforms that I've worked on where they've wanted to, they've needed to do some custom stuff at boot time. Well, okay, well, they'll use, say, the Uboot API and go and write a little bit of code. It's not necessarily portable to another platform. So the ABI that has been there has been insufficient to this point. And the world isn't all Linux. We pretend it is. We keep all our device tree files in the Linux kernel source tree. But FreeBSD is interested in supporting these platforms, too. Microsoft is interested in supporting these platforms. The other operating systems that are there, some of those crazy experimental stuff. I love the people who do crazy stuff who do things that don't seem to make any sense because they're the ones who are coming up with the ideas that are interesting for future products. All this comes down to is when it comes to the feature list that I want to see on my firmware, exciting is not one of them. When I bring up a board, what I want is I want it to work. I want to be able to, whether I'm using an existing distro and put an image on it that it will just boot, or even if I'm building an image from scratch, I don't want to have to do custom board-specific stuff just to get my operating system up and running. These are solvable problems. There's no technical barriers to the kind of standardization that's required here. We've got all the technology that we need to do it. We've got, as I was just saying with Yachto, this isn't just about supporting distros on embedded platforms. This is even about supporting custom vertically integrated stacks on SBCs because once you've got those standards in place and they work, it means you don't have to go filling with that. You can spend your engineering time on other things. Also, platform-specific features aren't actually impeded. One of the arguments against standardization is, well, I need to do my custom thing. That's no problem. Doing your custom thing is there. What the standard does is it gives you a framework so that you've got a place to go and do your custom thing without breaking the existing flow. We're just doing a whole lot of duplicating of the same work. It really isn't a need to do that. The whole point, this EBBR project, I'm here at a software conference talking about a project about a document. EBBR is a document. That's all it is. It's a document that covers some of the things that have already been going on within the embedded community. It actually pulls them together as this is what needs to be there, to be a standard. I'm going to talk a little bit about that now. Just on the topic of the, even on embedded platforms, I need to have a case study. This is a platform that I had been looking at. Say you've got a cable set top box. These things tend to have, when they're provided by the cable provider, they tend to have very fixed or very defined stacks, and they're controlled, they're managed remotely from the cable provider. Minimal local storage, it's every time it boots up, it looks for updates off the network, needs a pre-boot agent, and they were doing a whole bunch of custom work on every single platform to be able to go and see, do I need to do some configuration or updates to this platform before I boot the OS. Multiple hardware variants that they had to support, but they were really hitting the pain of not having a single OS image. One of the things that the standardization was giving them is all those funky, silly, embedded things that they needed to do, they didn't have a framework for being able to do that. Having a common API at firmware allowed them to go do what they needed to do, while still having a Linux kernel that was built from the mainline source, be able to get information about the platform and boot on into the system. I think I've established standards are good. They don't appear. If we're trying to standardize the boot interface, what do we actually work on? There are an awful lot of projects that we've got in the, I've just got a small survey of them here. Uboot, of course, is what most embedded platforms work on. Little kernel or possibly Tiano Core is used on a lot of Android devices. There's Coreboot, which Chrome OS has been using. There's, well, I mentioned Tiano Core. There's Linux Boot that has been gaining a lot of traction in the server space. There's a lot of these projects that are out there, and it's not just about the bootloader firmware, because there's another set of projects that are involved here as well. So Trusted Firmware is a project that runs at the higher privilege level from where your operating system would run. This stuff needs to be there. Whether we do a Trusted Firmware or a vendor specific thing, there's also Trusted Execution Environments. There's a lot of moving pieces here. If we're going to try to push towards standards on embedded, we need to choose a few things that we're going to start working on. So what do we start? Well, especially when your project is just a document, you need to have some things that are actually, where we're actually making some progress. So the intent of this process with EBBR was to start with things that we already have working in upstream. Well before, EBBR was conceived of about a year and a bit ago, took a little bit of time to get up and running, but there was already work going on within Uboot to standardize what the boot flow would be. That gave us a base fund for what we would be working on, and most of what was needed was right there, and what was missing was some discussion over how that actually should be implemented, what the guidance is for putting that onto a platform. We want stuff that was implemented in upstream projects, and we want to start with achievable goals. It makes no sense to me to go off and do a specification project in this day and age when there's no software backing it. So all of the stuff that's going into EBBR is stuff that's already being already implemented or being implemented in open source projects. So that's why we started with Uboot and Trusted Firmware A. All of the stuff that I'm talking about here today is equally applicable to the other firmware projects, and one of the questions I've gotten is, why don't you do it with this firmware instead of Uboot? It's simply pragmatism. We needed a place to start, and that makes sense. Besides, for most of the platforms that we care about, Uboot is already on there, so that's the same place to start. Right, so what is EBBR? EBBR is a platform requirements document. It is, if you're familiar with the Windows ecosystem, it's similar to the document that Microsoft publishes that says, if we are to support Windows on this platform, then your platform needs to conform to the requirements in this spec. It's not a technical spec that says how you implement all the features or what features, but it's a document that refers to the other specs and then fills in the gaps where things are ambiguous or missing. It's intended to be usable by Linux distributions in particular for them to say, this is the base standard. If you want your board, your SBC or embedded product to be bootable with a standard operating system, then you should conform to what this document says. Then the other thing that this says is it's a completely open process. I work for ARM, and ARM, we produce a lot of IP and we produce a lot of specification documents. A lot of the time, we do things in a very proprietary manner. We go off, we ask our partners, what do you want? We go off, we write it, we come back and say, is this it? Then we either give it to them or we license it or whatever. This is actually a very new process for us. We realize that, while those who are involved, ARM is hosting this, but for this to be useful, especially for this community, for the embedded community, it's of no value if we go off and do something in private and then say, here you go. Actually, in fact, we tried that. The first version of EBBR, we asked everyone what they wanted, we went away, we wrote it, we came back and said, is this what you want, and we heard nothing, because no one was interested. We took a reset, we went back, and this completely changed the process. So now, instead of being proprietary, we're using Creative Commons license by SA, so anybody is welcome to contribute. We're drafting and hosting the project on GitHub. All of our conversations on mailing list, it looks like a regular open source project. Anyone can participate. There's no contributor agreement. We're using a DCO developer certificate of origin, same as the Linux kernel process. And the document is written in restructured text, so for us kernel hackers, we can actually go and just write a patch if we don't like what the spec says. And then finally, it's architecture independent. So while this is hosted by ARM and our primary, the primary driver right now is supporting ARM platforms, it's open to any architectures. We've had RISC 5 be interested and have been in some of the conversations, and there's been questions from other architectures. So anybody who wants to submit, contribute support for another architecture to the document and be able to have architecture specific requirements in there, more than welcome to join this project. It's also implementation independent. I went on a long time about we did this with Uboot, but nothing in the document actually says Uboot. The spec has been written with Uboot in mind, right? So it's the we know we've got all these platforms, we've know we've got all these platforms with Uboot, we know we've got an upstream Uboot project with the features that we need. This document says if you're doing Uboot, everything that's in this document, you can do. It's already there. In fact, it's not a hard lift as long as you can get up to mainline or close to mainline, you've got just about everything that you need. So it's possible to implement this with Uboot and also with TianoCore, which is UEFI, the UEFI spec's reference implementation. It's also UEFI, and this is where I get a lot of questions of, wait, you're doing UEFI? That's that big bloated PC stuff, right? No, I need to be very clear on this one. UEFI is a specification for firmware interface, and it provides, it's a big spec. There's a lot of stuff in there. There's a lot of hardware specific things in there, but it's just a specification, and it defines an ABI for how applications can be running at boot time, how to hand off to an operating system, and how to provide some very minimal services while the operating system is running. This is easily implementable in, well, I say easily. I can say easily because I didn't write the code. Ask Alex Graff over here how easy the process has been. So it implements the, where we're choosing the UEFI ABI because it's a standard, because it's what's already used in the PC space, it isn't costly, it's not expensive, it doesn't add a whole lot of blow to your firmware, and it means that you now have an interface that the distros can actually use. It also defines behavior, which means when you have an image, rather than each board saying, well, I like my image on this partition of my SD card or my EMMC, it defines a predictable process for how you actually boot, how you actually go from an image on an SD card or a USB or off the network to something that can be executed without that application having to know ahead of time what you're booting on. The document also contains a bunch of additional architecture guidance, such as on ARX64, for example, we specify PSCI. And what PSCI is, it's just another interface to, instead of having to do board-specific or SOC-specific features to power control your CPUs, PSCI defines that interface. And we will add, so EBBR will add more specs as they become relevant to the platform. The idea with EBBR is that the first release of it is going to be kind of a baseline of how you would boot, and then as we go forward, it will evolve and bring in more standards, as those standards and the implementations evolve. And finally, it accounts for the constraints that we can admit in systems. PCs have a very specific view of the world. They assume that you have firmware, and you have your operating system. Firmware lives on the baseboard. Your operating system lives on your M.2 or on your hard disk or on your USB stick. We don't have that. I mean, quite often we've got an EMMC device, and everything's on that same device. Or we have an NAND flash, and we have to deal with firmware and the operating system resident on the same device. This causes problems. In the PC world, it assumes that the firmware can actually provide runtime services, can provide the ability to update variables, because that's on a different device. Firmware can just go talk to that device. Well, if your storage device is EMMC, your firmware, if you call into a runtime service with firmware, firmware can't go touch your EMMC, because the EMMC is, Linux is using it. It's got its file system on there, so if you start creating transactions there, you're going to have corruption. You're going to have problems. We need to account for that in embedded, and there's guidance that's going into EBBR on how you do that. Or in this case, we have a spec change on UEFI that's pending that allows us to, most of those runtime services, just return not implemented. And then we've got, there's another mechanism that's being talked about on how you do variable updates, which is actually the most important part of runtime services, if you're doing an operating system and you need to change the boot flow, the way you do that is variables. If you can't do that with runtime services, we need another mechanism, and EBBR has talks about that. And then it also talks about just the mechanics of sharing firmware between, firmware and the operating system between the same device, so that the operating system doesn't come along and just go erase all of your firmware, and then suddenly you're not booting anymore. How am I doing on time? I'm not too bad. So the projects hosted on GitHub, there's a regular main list hosted by Lonaro. We have a weekly conference call. It's, as I already talked about it, being an open source project. Current release is, we've got .7 pre-release, which is available if you, in fact, just go to GitHub, ARM software, EBBR, into the releases page, and you'll find the PDF. Go read it, provide comments to the, to the mailing list. Or, you know, come find one of us who's worked on it. So some of the folks who have worked on it, we've got Alex Graff over here, Daniel. Sorry, Daniel. Thompson. Two in the room has worked on EBBR, because I just can't see everyone. We've just got Alex and Daniel at the moment, but there's a committee. We've got Silicon vendors in the room. We've got the distro vendors. So, Sousa and Red Hat have been involved. We've got Rob, or sorry, Tom Rini, the UU maintainer has been involved. So any of those folks, you can see the, who's been involved, and go and ask them questions. We want to release a 1.0 as a baseline in December. And by that time, we expect everything that's in EBBR is also implemented in UBoot. And so if you're up to date, you should be able to bring a platform up. Oh, and FreeBSD boots on it. That was a nice surprise when FreeBSD suddenly showed up at Lunaro Connect a few weeks ago, and it booted. It worked on some of our initial platforms. In the version 1.0, it's going to include ARX32 and ARX64, unless someone comes along with another architecture we can put in there. We'll have the basic UEFI ABI. We'll have the hardware description platform required to be provided by the platform. Either device tree or ACPI. This is a bit controversial, but the intent here is EBBR includes everything on the server platforms, right? Linux supports both ACPI and device tree. As long as you supply one of them, and the mainline kernel can boot, you're good. Our shared storage guidance, there's PSCI, runtime services, and some exceptions to the UEFI spec. We have Peter Jones from Red Hat has been involved as well, and he's been talking to the UEFI spec, so we don't want a lot of exceptions, but we can put them in if we need them. And then after 1.0, we're going to start looking at the more complicated issues. We're going to talk about secure boot. We're going to talk about capsule updates, other embedded use cases such as ABI updates, the better UEFI compliance. And that is EBBR. Thank you. Questions? There's microphones on either side of the stage if you have a question. I have a specifically used case that for a project, we have a requirement of fast booting, where in a hybrid multiprocessor we had Cortex ARM, Cortex something, and DSP in the same SOC. So for the fast booting, we use the DSP offload to the DSP, the root file system loading. Is there something that you are thinking in having in this standard as well? It's for fast booting, I mean, it depends on whether or not U-boot as it is, is fast enough for you. If you are able to turn off most of your drivers in U-boot and get to loading the OS, then it helps you there because the UEFI API doesn't really add any significant time. So you'd still be able to do the fast boot. If you needed to do something custom, you could do an application that uses the UEFI API, which gives you, I mean, a standard API, but it also gives you access to networking and block storage, USB, any of the driver stacks that are within U-boot. So you'd be able to use that. You'd still need to do platform-specific stuff. You can always do for your platform to say, the fast path is, I'm going to just go and I'm going to go and boot straight through to this one that I know is there. But if I had an exception, then I'll take the slow path and I'll go through an update and I'll look for boot sources that are in another direction. So the standard gives you a common behavior, but you're always able to do, for my case, I will go and do a custom behavior for this platform and then fall back to the common behavior. Other questions? So we're working in the automotive embedded space, and most of the requirements that we get through from our customers at the moment are focused very heavily on security, for example, the FETA security things. Now I see you've got that as your first point on your next steps. Is it something you haven't looked at yet, or is it something you in the back of your mind just haven't addressed properly yet? We've talked about it a little bit. We haven't put any significant effort into it because we need to get the baseline out. It's none of the features that we are, I don't think any of the features for UEFI secure boot are implemented in U-boot yet. Alex can talk more intelligently on that. So the main reason we don't have secure boot in 1.0 is simply, as Grant said, we don't want to run before we walk. We want to boot first and have something that has a baseline and then work on secure things on top because that is it another completely different field to standardize on. We want to ideally follow the UEFI way of secure boot as much as we can just to be compatible. If that doesn't fit requirements, like if you see that the UEFI secure boot way is insufficient for the automotive use case, we would love to just get that feedback. We are a community driven spec. As far as implementation goes, there actually is a company right now implementing secure boot using UEFI. The whole UEFI secure boot flow in U-boot and that's going to come in the next couple of months, I think. So it's work in progress. It just isn't there yet. It's also one of the reasons why we've been, what we want to have in EBBR because we want to use, there's already processes for doing security that we want to be able to use the same things that are working on the PC secure boot as on the embedded platforms. Go on. So I've just been reading through the PDF and well written and clear, but for lazy people, is there a platform you can point to that say is implementing or just say use the get U-boot master, use the common distro infrastructure and enable UEFI and you're done? Raspberry Pi works quite well. We'll have a bunch of demos at the tech showcase later, which hopefully they'll work. So Raspberry Pi works well. Ultra96 works well. The Machiato bin, I'm just thinking of ones off the top of my eyes. There are a number of platforms that work reasonably well. We're hitting, in fact, one of the things that I've wanted to bring up or do is try to do some kind of plug-fest and start actually testing these things because the functionality is there, but we need to do a bunch of testing. Raspberry Pi is a good place to start. There's also going to be a QMU model, basically a canned, Daniel Stone has been pulling that together or organizing that so that you'll just be able to bring it up in QMU and see the flow and how that all works. I hope to have that by the time we've got a 1.0 release as well. People working on the AM Logic U-boot port mainlining said they want to support EVBR and they think they turned on all the right options, but they were still a bit unsure how to test actual compliance. Yeah, we don't have compliance tests yet. That is the missing piece. There's a bunch of work going on right now that Suze is doing on SCT, which is the UEFI self-certification test. U-boot is currently able to run the SCT and tell you a whole bunch of failures, but that's better than not running the SCT at all. Once we've got some useful results out of SCT, that's probably going to be our compliance platform. To answer the question really quickly, if you are U-boot based, your mainline, your device tree in U-boot, the one that U-boot consumes is compatible with mainline Linux and actually contains all the same nodes so you don't rip out things. You enable Distroboot and you enable the Distroboot command and you don't explicitly disable anything, like you disable the EFI, then you're obviously not compliant anymore. But if you don't explicitly disable anything, automatically everything will just happen to be EBBR compliant. So if you don't do anything weird, you basically are compliant with the U-boot platform today. So I guess the reality for us is we tend to go whatever bootloader our SOC provider is shipping as part of their SDK. So I'm just wondering how long you think it be before Broadcom say, no, we don't want you using Bolt anymore, EBBR is what we're going to be supporting in the future? That's a hard question simply because that depends on vendors SDK release cycles. Any board that's currently supported in U-boot mainline, of course you're you can immediately go and say, I'll just use that. I can't say what the timeline is going to be on the vendors, but I think that the distros are going to start saying, look, you got to do this, or we're not going to support you. So if a vendor wants to be supported by Debian, Red Hat, Suze, Ubuntu, FreeBSD, I think that's going to start becoming a requirement probably in the next year. Ish, Ish, depending on the distros? Yeah, so you're definitely talking to the distros. Are you talking to the SOC vendors as well? Do you have a conversation with Broadcom? ST is involved. Who else do we have involved? Xilinx is involved, yes. So NXP, any vendors who aren't involved are welcome to come and join and help out. Okay, thank you. Great. Any other questions? I think I've got time for a couple more. Hello. So one of the major requirements in my business regarding booting is implement a recovery safe boot, particularly if you think on land devices, does the document contain somehow patterns for that, or does even the you put implement already such things if it implements your document? The document doesn't contain anything about reliable fallback or that's the kind of situation you'll be able to do reliable updates and fallbacks. That's one of the things that we're planning to tackle after 1.0. I don't know if that will be something that goes in the spec proper or in guidance documentation, because there's some interpretation document that goes along with that as well of how you should do things. Everything that's needed to do reliable boot or most of the stuff that's needed is there. Right, so if you do AB boot, you would probably have two different variables to say this is my primary, this is my secondary, and then you need to fallback mechanism to detect when you're not, when the previous one didn't boot and then switch. So while that's there, we don't have guidance on that yet, and we will need to do that. Any other questions? So I want to build an operative system, that's the point I'm looking at it. And I have really bad experiences with secure boot from what I've done. So if I, also I use x86. Yes. Well, I was looking at the standards, and I wonder if I don't use secure boot, and I use x86, if I try to follow the standards to get into a more general solution to my system, will it boot? Will it work? Because I just wonder. So on x86, well, first of all, for x86, if, how should I answer this one? With secure boots, the whether or not secure boot is turned on is going to be dependent on the platform. And so it would be the option of the board, like the board vendor on whether or not they turned on secure boot and whether or not it was allowed to be turned off. I think for most, for all of the development platforms, for all the SBCs, I want to see secure boot enabled, available, available to be turned off and in setup mode, so that the end user, those of us who are developing things, can actually make use of it. Most people don't know what it is. Yes. So it's not that useful for the user to know, oh, do you want secure boot? Because most people don't know what it is. Right. One of the advantages is if it's turned on right away, then the distros can say, we've got a secure image. It'll boot securely. You'll know what you're in, but you can turn it off for when doing the custom stuff. Thank you. All right. Ivan told my time is up, so thank you very much.