 Welcome everybody thank you for coming Our talk is UEFI boot from your mortals So I appreciate you all to coming out at noon for a talk on UEFI that shows a lot of Stanley I know lunch is right around the corner, so I'll try and keep this mostly brief First off a little bit about us. My name is Stefano I work for Intel and I'm currently the Tiano core community manager And I'm also an open-source firmware and hardware advocate Alexander will be up next He is the KVM and QEMU developer for SUSE and he's one of the founding members of the SUSE arm team So let me start off with a quick demographic check How many of you like me six months ago? Think of UEFI and you think of a blob five to ten megabytes that lives in some flash round part somewhere That's really complicated Good, I'm in the right room perfect. Okay So let's start with UEFI then It turns out UEFI is actually just a PDF So that's what I want you to think the next time you think of UEFI UEFI is a series of PDFs and If you are looking for a sleep aid, I would highly recommend reading the entire thing But really you can use it as a reference for how the specification of UEFI is laid out The definition is actually in several parts. So Platform initialization is one of the things that's defined in its own specification Boo and runtime interfaces are defined ACPI which is its own talk and which I am not qualified to give is its own Specification and UEFI shell is another specification. So when you think of these things don't think about implementations think about specifications that define an interface a way to standardize calls into hardware and That gets me to what the point of UEFI is which is really standardization And it's the standardization of the transition from hardware Into some payload and that payload could be Grub it could be Linux it could be lots of things but the transition from hardware in it into that payload is what UEFI is all about So let's talk a little bit about How that process works? How many people here? understand what a Reset vector is Okay, good number. Excellent. Well for those of you who don't know Once the magical world of hardware has done the thing it needs to do It's going to pull the reset line low and that's its way of saying hey all that stuff I'm not going to tell you about is done now and there's a pointer to Some well, there's a place in memory where you can go and it promises it'll start executing instructions Assuming it did its job, right? So UEFI is concerned with what happens when you get to that place. What do we do next? It's concerned with the most basic Fundamentals of hardware initialization like DDR memory initialization. So getting the timing right making sure that you can write something to memory Understanding where the media is that you're going to boot from and initializing some silicon specific stuff like you like PCI or USB or even simple stuff like you arts So that's everything from the hardware end and you can sort of think about that in terms of the initialization of the hardware Then from the payload end There needs to be a way to look back into that firmware sort of a thin interface to look into the hardware and make calls And that's where UEFI comes in it creates these standard definitions of how do we do things? How do we call back into that firmware? So sign capsule update is one of my favorite examples because I think it's one of the less known features that UEFI enables So the LVFS Which I've written down look Linux vendor firmware service is a really exciting thing that you should go look up because it again is its own talk on its own and Mike Kinney from Intel did a great talk recently on that Lenaro connect HTTPS boot if only people here know what pixie boot is Excellent, I really am in the right room We would really like for that to go away and for those of you who raise your hand You should know why we really want that to go away and HTTPS boot is a great way to make that go away Graphics output protocol is just another good example of how we standardize something like how you interact with a frame buffer But these are all ways that that payload that I talked about can then look back into the hardware and make calls and in some Standard way so that you don't have to roll everything from scratch You can know this implements the UEFI spec I can know what to expect and it's important to remember too that it doesn't the UEFI spec isn't an implementation It has no interface. It tells you how to write an interface and that's an important point So I don't want to spend this entire talk talking about UEFI because there are other really important boot loaders out there Corbett and Slim boot loader are things that again could be their own talks But things that you should go out there and look at and There are corporate people here in the room so please throw something at me if I say anything bad but The idea that I have in my head when I think about things like core boot and some boot loader is if you want to get to Your payload as quickly as possible the minimal amount of hardware in it that you really need to do to get the memory Initialized and to get yourself into some payload. That's where core boot really shines So if you're looking for a quick handoff to some OS who knows maybe Linux Or some boot loader who knows maybe grub That's the thing you should be looking at The idea is that you're booting the OS you want as quickly and efficiently as possible UEFI really thinks more along the lines of what if you wanted to boot a whole bunch of operating systems? How do we make that efficient? So this is the slide I bring two things up on the screen Which many of you probably aren't used to seeing which is UEFI and Uboot And this is why I have an expert over here with me because I can't talk to that very well But I can't talk to Tiano core Indeed and we have a slide on that so Hardware initialization done in such a way that it isn't minimalistic that you really do want to have something more robust where you could have Networking and you could have USB capabilities Providing boot time services and allowing firmware to be updated and as I look at this slide I realize easy may want to be in quotes These are things that are all that we attempt to address and one of the things that we really want to do with this talk is Show the ways in which both of these pieces of firmware are really great choices for different things So don't think of them as competing software. They really are trying to accomplish the same goals just in different environments So for one example Uboot has been open source since day one Tiano core was open source in 2004 for those of you who have ever tried to open source closed source software You will know that it is a tad complicated and so when you look at the code as Frank Sinatra said please be kind it's There's gonna be things there that you're going to have some issues with but realize that it is the effort to drag that Into the open-source world that is our goal so from the Tiano core side you've got both Platform initialization so we do the hardware part and we do that to the UEFI spec and then we also do I'd said a word I say Thank you to the PI spec. I'm clearly jet lag too many acronyms. So we do that to the PI Twice they'll hit three times before I'm done. I promise You go on the other hand does implement the parts of UEFI that are necessary But just enough so that when you look back into that firmware you see the things you need to such that the payload will know I'm in a UEFI compliant environment There are numerous platforms available for Tiano core and we'll get to that in a different slide But as most of you will know there are an amazing amount of platforms that run Uboot So there is a huge field to play in there UEFI shell is implemented in both and that's a slide that I'll get to later on too so EDK 2 Coming to the part that I think is also somewhat misunderstood EDK 2 is a number of things. It is a build environment. It's a place where you can build a reference implementation of UEFI firmware It is not the actual firmware that you're putting on the board though. It does contain it So there is open source firmware code inside the EDK 2 repository But like with many complicated projects like this It's hard to put a pin on what all of these words mean because you have things like UEFI and EDK 2 and Tiano core and you just want to know what to call the thing you just built But the thing you just built is custom firmware So the fact that the open source firmware is in the repo makes it a little more complicated but the thing that I think is really great about the But this repo is that it has a number of different large corporations Contributing to it and as you all know large corporations are really good at working together So clearly it happens seamlessly and there's never any arguments or problems and all the care gets merged flawlessly To combat that ever we have the open source community that I am working to build and we'll talk about that in the next slide One of the things to know is that EDK 2 has a fully validated UDK releases but you can also work from the master branch obviously and then also several stable branches that we release we release the stable tags on three month cadence The part that I actually like to talk about because I feel like a little bit of an expert Is the Tiano core community because that's the thing that I'm trying to push I've set up monthly community meetings so that people who are engaged in working on the software We're just interested in learning more can come and ask questions. We usually have some of the Experts in the world of EDK 2 and UEFI present So they could answer questions or we talk about topics like how do we improve our mailing lists? How do we communicate better as a community? I'm going to be setting up when I get back from this event Bug triages so that we can go through bugzilla in the public sphere and say here are some of the things we found Here are some feature requests here are some bugs that we're trying to fix and that gives the community opportunity to pitch in with Project that is often looked at as really just stuck in the domain of corporations And we're also working to build a continuous environment a continuous integration environment And we're trying to do that in a community-oriented way so I'm working with people from core boot and Linux boot and with people From you boot to try and make this something that is a community effort to do CI rather than just going off in the corner and doing it ourselves. I Want to talk briefly about EDK 2 platforms So I mentioned that there are some platforms that Tiano core can natively support and EDK 2 platforms is our way of trying to pull some of that code out into its own repository So specific hardware like the Beagle bone is available there will be available there shortly The stable branches there track the UDK releases So those completely validated releases get tracked in stable branches And then we currently have development branches, which I will admit need a lot of cleanup But if you're trying to get that hardware booted just so that you can play around with it that develop the development branches are perfect Just for that purpose They need a lot of work that so some of the boards that we're looking to To get going obviously the Beagle bone black as I mentioned is something that we're going to be working on And up squared board which I'll talk about briefly is something that I'm personally excited about And more about Machado bin, and I'm sure some of you have heard of the miniboard project Which is a continuing project and that we hope to continue to support So I'll talk briefly about to the and up squared board So the up squared board is really interesting It's got a whole lot of really fun. I know and it actually has a max 10 FPGA on it So there's a lot of possibility in this board, and we currently got it booting Tiano core as of version 2 7 oh Okay, yeah, so it's been up there for a little while so this is one of the things that we're trying to further We realize that we have open-source tooling we have an open-source code base But we need some the form of Hardware that everyone can afford that is readily available that we can give people to test on so and up squared board is one of our first Efforts in this area, but we are going to continue and try to push other boards as well The idea being that we know you need something relatively cheap to put on your desk so that you can play around with this stuff So this is one of the boards that I'm really excited about there a couple other that I'm looking into that I won't talk about here, but check out with me afterwards, and I'm happy to chat about them so But that I've talked a lot about you if I and about edk2. I'd like to have Alex come up and chat with you about Yep, thanks So I'm the the upstream you if I you boot maintain out which means that I take care of the You if I Implementation parts inside of you boots, so who of you knows what you boot is very nice Who of you understands what the bullet points me? I? Think you go through them so so important what one important piece that's intrinsic in you boot is it's it's a Very open saucy project. It's it's all GPL code. It chairs code with Linux even in a couple of cases You can really think of it more as a as a long stretch boot face Arm of Linux almost right. It's it's a very open-saucey intrinsically open saucy community-based product product project The idea of you boot has always been to be as small as you can and as fast as you can So you want to be out of the boot face as soon as possible Which means you want to be really really quick and small one of you with amazing features is as Falcon boot Where you basically do pretty much nothing until you you're up in in linux land, which is a similar goal to what core boot is trying to do Which basically goes hand-in-hand with where it's targeted, so I You boot is really really big whenever you get to embedded appliances where you have vertical integration of the whole stack you want to just You you want to control what your boot environment does because you don't want to have that Throw anything in your face while you're running which usually happens on normal actually six big service because vendors happen to add Amazing new features into the SMM mode which happens to run while you happen to run your operating system And suddenly you're losing real-time abilities You boot is is trying to avoid any of that you're basically trying to get out of the business as fast as you can which means It's ideal for an embedded appliance you you can if there's about you can fix it because it's all open source and you can You do control what happens Which means if you if you find any latencies or issues you can you can actually resolve them It Because of its heritage in the Linux community and and people around there the whole coding style Looks like Linux, so if you are a Linux developer contributing to you Buddhist trivial, right? It looks the exact same basically it's you you will know how the code works within minutes and Traditionally you would has implemented it very direct boot mechanisms like For example the direct Linux boot where you just implement the Linux boot protocol So you can hand off really quickly to linux because that's what the bootloader's job is supposed to be right and out really quickly To the operating system It has its own new boot API, which some people use so example some BSTs use the U boot API to implement Whatever their file system is called and ZFS drivers and whatever additional drivers To to that they cannot port into a GPL compliant code base in in a payload Or they didn't want to have a tainted by GPL so Tiano core on the other hand is basically The way I usually put it. It's it's built to fork. All right you You it's it's it's the whole purpose of Tiano core is that it's a base For people to take and build their own thing with and then ideally never contribute back We try to I mean people are trying to change that, right? It's but but but if you if you an HP you you don't really want to push your HP Nailman back into some open source project because what what's your value at what's your what's your revenue stream for getting open source Filmware in there right is there's there's very little incentive for them to do so. There's a lot of incentive in enabling communities with Those with by having upstream enabled support Which is what we're seeing in tian in the tiano core community now But in I would say in 99% of tiano core based systems out there film We're out there is eventually in a closed source environment It is much bigger than a typical uboot load is because it supports way more interfaces. It actually has amazing features in there, right? Stefan I was talking about HTTPS boot. We don't even have TCP support in uboot not even speaking of HTTP or HTTPS, right? This is a full blown operating system tiano core and EDK to the EDK to The words are terrible the the tiano core community has support in its EDK to projects for a Lot of amazing features Because of that heritage where it allows you to really do Close source firmware. This is the big market. It's in right if you if you get if you're getting a random server today It's probably going to run some code from this code base Maybe not everything of it, but a lot of code from the EDK to code base Coding style wise if you are used to politically correctly saying camel case Code You will feel very natural in in that uef. I Like environment in the in the in the tiano core environment Whereas if you from a linux heritage I cannot read that code to be honest You Yeah, Leif isn't either so It implements a lot less Interfaces because really at the end of the day what you need to implement is this is wrong. This should be PI it implements the the front-end interface to have bootloaders and anything above running interfacing to to your to your uef I standard firmware and Implement drivers, that's basically it only lives in a uef. I only world where's you boot lives in in this Weird state in between at this point So what's the whole point of adding you if I support to you boot then right? Why do we want to? Blow it up with more code to actually give us something that we already have a nice invitation for you Why do something more? Well turns out abstraction interfaces are a good thing Because using this Small uef I'm patient. It's not feature completed doesn't implement everything everything from the spec But it implements enough to boot into linux to boot into BSD to boot into grab it Most things you want to run except for windows work just fine Because both implementations implement the uef I spec to that point you can then have the exact same boot flow Regardless of which environment you live in if you have a you would based environment You can just run the exact same binaries as you can on on a uef I on an EDK to base system and see even I get the words wrong So this is all possible because we basically have this abstraction interface and this abstraction interface is what the uef I spec is all about And what you see down here looks artificial But really what it enables you is it enables you to boot any standard distro That you want and I just happen to care about the open-tooth one what most Any standard distro you want Regardless of what is there on the upper layer it really just is an abstraction interface, right? It's imagine it like the JavaScript engine for for for firmware So what this leads to is The really nice benefit of it is The number of the the overlap of machines that each firmware runs on that there's very little overlap between the two right So the typical system that's that you have an EDK to base system on it's not the typical system You have a you would base system on so by enabling the exact same interface. You're suddenly broadening you reach by Many folk right you you can run on pretty much any system these days that is either x86 or arm based Without even thinking about all of this booting stuff because people really don't want to be in that business It just happens to be a difficult, but we don't want to make this difficult only because easy as possible So with that you're more than happy to contribute to either one of the two or even both or just I mean jump between worlds It's always always a great thing. You can reach Stefano here with those credentials the mailing list up there Patches are always welcome to everything if you want to implement some cool new feature Make windows boot on you It's it's a great thing to have and now we have about four minutes left for questions Because I'm sure you will have some yes How's progress for the UEFA one-time service going on you boot it depends on you consider progress so the We have had if you if I want time services from day one So that's always been one-time service because without one-time services linux will just call into null pointers You have to have something there Admittedly most of these one-time services implement error return in minus error and not implemented and that's it There there are two things that we're doing one is as part of the ebbr initiative the embedded based boot requirements farm We added an easy R to the UEFI spec Which allows you to not implement one-time services, so it's you would finally becomes that compliant by not implementing them So you if you can't change I mean if you if you don't want to you know I do if you was what's the the mountain and the profit thing in that English, you know, you know what I'm getting to so so that one's the ones there and the other one is We have a lot of infrastructure to implement one-time services, but it's not as pretty as it should be In in you would right now, and it's intrinsically bound to the way your one-time services are done. It's just There are some suggestions on many is today even just just from this week on how to clean all that up that maybe we should build Another tiny version of you boots inside the build process that only comes with a small device model and only the devices You need for one-time services and then you embed that into your bigger you boot and you make that your one-time service While you're running We'll have to see how we how we get there, right? I think eventually we will want to leverage some of that infrastructure. We have a new boot for one-time service today We don't it's just function overloads and in couple sections that you put stuff into but you can do one-time services if you want to Yes Which architecture do we support in Tiano core or in you? So sorry for people don't know art is one of the main contributors to the edk2 code base So he will you will know all these pieces in you boot currently we support Actually six 32 bit 64 bit arm 32 bit arm 64 bit with 5 32 bit with 5 64 bit Yes, I don't think anybody rented to MIPS yet. I we do have people want to send a power PC. So let's see Yeah Can you want you would from Tiano core of course you can you can you can run either from either just whatever this Yeah, anything anything goes You can you can have you would be a an actual payload on an EFI payload You can have you would be an EFI operating system Which kicks away edk2 and takes over the machine at which point you can then run EFI applications from you would get The whole world is open to you Yeah What's the difference between China quantity to that was what Stefan there was explaining It's very easy Tiano Tiano core is the is the umbrella project All right, that's that's that's basically the name for the overall arching project edk2 is the tool kit itself That allows you to build firmware and the firmware that falls out of it doesn't have a name In a nutshell Yeah Yeah, any other things we have one more minute one more question, I guess Yeah If I like what is what is light? What is the the UEFI spec is It's not quite 10,000 line the 10,000 pages here, but it's getting close. It's it's big, right? So light basically implements everything you need It does not It implements enough to make real life use cases from today work So that the approach is different the edk2 approach is let's give you a reference of notation that implements everything that there is in this Back whereas the you would Approach is let's look at what people actually do use today and what they do need what what do we need to make Linux work? What do we need to do to need to make rub work? What do we need to make? To make to make BSD's work and turns out all of these have almost the exact same requirements There's there's very little you don't you don't need additional protocols You don't you don't need the human interface interface or whatever. It's the HII databases and such to just make Grub work you do need it for the UEFI show So we have it now and you could because you can now on the UEFI show but There's a lot of these really really arbitrary weird protocols that nobody usually runs Except for very specific targeted Workloads that I haven't seen yet. Also, you are missing out on any or on most parts that make up the whole driver environment We do support some of that so you can Henry for example at an amazing code You can in you boot you can run I pixie as an if I payload which provides a UEFI block device which gets merged back into a you would block device Inside the you boot layers you have a combat layer so you can use you boots partitioning code and you would file system code Which exposes a you an UEFI file system protocol again to so that you can use that to load driver to to load binaries throughout all those layers So we have we have some Driver parts or we don't have a PCI abstraction layer for example that the whole stuff just doesn't exist That's what light means light doesn't mean it doesn't boot you it might just means Things you really don't care about