uEFI grub2 on Raspberry Pi
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 63 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/54554 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
openSUSE Conference 201661 / 63
1
5
8
13
14
19
20
24
25
31
32
33
34
35
37
38
40
43
44
45
46
47
49
50
51
52
53
54
58
59
61
63
00:00
Musical ensembleJames Waddell Alexander IISoftware developerEmulationArmPower (physics)Server (computing)Support vector machineBootingBootingTable (information)Physical systemVideo game consoleService (economics)Communications protocolMiniDiscStorage area networkProcess capability indexSicRead-only memoryRun-time systemMedical imagingStructural loadScripting languagePartition (number theory)Real numberRootSheaf (mathematics)Uniform resource locatorFile formatWeb pageFunctional (mathematics)Binary codeKernel (computing)Network topologyPointer (computer programming)PlastikkarteCore dumpGraphics tabletComputer fileDefault (computer science)1 (number)InformationPoint (geometry)Data structureMultiplication signOrder (biology)CASE <Informatik>WhiteboardAlgorithmSpecial unitary groupBootingFile systemTouchscreenBootingComputer hardwareOpen setArmNormal (geometry)WordData storage deviceRight angleDistribution (mathematics)Cartesian coordinate systemCodeResource allocationPower (physics)Physical systemSoftware developerGraph (mathematics)PasswordObject (grammar)Process capability indexDevice driverElectronic mailing listSemiconductor memoryService (economics)Address spaceSpacetimeDifferent (Kate Ryan album)Table (information)Social classIntrusion detection systemMiniDiscGame controllerArithmetic meanHydraulic jumpVirtual memorySerial portSoftwareOperator (mathematics)FirmwareCommunications protocolSystem callVideo game consoleFerry CorstenSet (mathematics)FrequencyConfiguration spaceMemory managementMilitary baseOperating systemBlock (periodic table)Computer animation
09:20
BootingTable (information)Physical systemVideo game consoleService (economics)Bridging (networking)Wrapper (data mining)Execution unitObject (grammar)Computer networkVideoconferencingMiniDiscLie groupArmDefault (computer science)Demo (music)BootingGastropod shellBinary codeDemo (music)Default (computer science)Kernel (computing)System callStructural loadNetwork topologyGraph (mathematics)Point (geometry)Multiplication signVariable (mathematics)CollisionPhysical systemDifferent (Kate Ryan album)CodeRight angleDirected graphMiniDiscService (economics)Escape characterLine (geometry)Functional (mathematics)BootingSpacetimeVideo game consoleOperator (mathematics)Execution unitWhiteboardWrapper (data mining)Data managementBefehlsprozessorRun time (program lifecycle phase)Semantics (computer science)Term (mathematics)Integrated development environmentPointer (computer programming)SoftwareVirtual machineContext awarenessPower (physics)Interface (computing)RandomizationMetropolitan area networkStack (abstract data type)Object (grammar)Table (information)Semiconductor memoryIntrusion detection systemStandard deviationPatch (Unix)Computer architectureElectronic mailing listWaveSheaf (mathematics)Medical imagingNP-hardConfiguration spaceWindowUniform resource locatorMereologyAdditionEmailFunction (mathematics)Scripting languageCuboidKey (cryptography)Logic gateMemory managementSource codeDistanceReal-time operating systemTemplate (C++)Set (mathematics)TupleConnected spaceImplementationGoodness of fitWritingWeb 2.0Einbettung <Mathematik>Computer hardwareVideoconferencingAddress spaceBlock (periodic table)Resource allocationBridging (networking)
18:32
Power (physics)Connected spaceBootingComputer animationLecture/Conference
18:54
Distribution (mathematics)BootingSlide ruleBootingKeyboard shortcutComputer animation
19:58
BootingCuboidLatent heatKernel (computing)Rollback (data management)Flash memoryBootingShift operatorEqualiser (mathematics)Selectivity (electronic)FirmwareMereologyPhysical systemDefault (computer science)Normal (geometry)Point (geometry)Link (knot theory)2 (number)PlastikkarteDisk read-and-write headPiDifferent (Kate Ryan album)Virtual machineGoogolReliefCore dumpSoftwareInterface (computing)CASE <Informatik>Lecture/Conference
24:06
Line (geometry)Computer animation
Transcript: English(auto-generated)
00:08
Hello, and welcome to my amazing talk about running every buzzword you could possibly hear in a single device. EFI, grub2, raspberry all at once. I'm Alexander Graf, this time
00:24
for real. David was just faking to be me. I'm usually a KVM developer. You might have seen me from things like running KVM in KVM, I was doing KVM on power. Things that people usually seem to take as granted these days. But this time around, I'm going
00:43
to talk to you as a member of the OpenSUSE arm team. So, you saw on the headline the Raspberry Pi. That's what it looks like. Most of you guys have seen one. I just took this image from our web page. It also has a logo on it, which is cool. Why would
01:03
you possibly want to buy a Raspberry Pi? That's very, very simple reasons. It's grab it and it's arm based. What more could you possibly ask for? But most of you guys probably want to run software on such a device, right? So, you want to boot, which means
01:23
you want to get into a system. So, how does booting on the Raspberry Pi work? Well, it's really, really simple. You take this board and then you take your SD card and then you plug your SD card in and then you take your power cable and you plug your power cable in down there and then it just boots. Unless you're the one creating
01:44
the image that is supposed to make this thing boot, which is what we're here for, right? In the distribution. So, let's take a look at the SD card. What does this thing actually look like? What do we have in there? You have the usual. We do have our root file system. We do have a swap partition. The usual stuff you would expect on a main
02:04
device that you run your operating system from. But the Raspberry is special in one regard in that it also has a FET partition. And that one is very, very mandatory on those devices because the FET partition actually contains a few files that are incredibly necessary to boot such a device. The really, really most important
02:22
one is boot code bin. That just lies around on that FET partition. It just hangs there. And it's so important because that's what is the initial boot code. That comes from the Raspberry Pi foundation. It's actually GPU code. So, the whole thing doesn't boot from the ARM systems. It boots from the GPU. This is GPU code that then goes in and reads the config text file, which is
02:42
also on there, to figure out what it should do, how it should look like, whether it should enable serial ports, what frequencies it should use, what monitor depth it should use. That's all written in config text with defaults, obviously. And we usually, if you have, say, a Raspian distribution, you also
03:02
get a kernel on that FET partition that you boot. Which ever from the very first time we enabled the Raspberry Pi in OpenSUSE, we figured it was a really bad idea. So, instead, we are using U-Boot at that point. And U-Boot then goes in
03:20
and can actually break out of that FET partition and go into your real root partition and read a script called boot script from there and load the kernel in a device tree from your root partition, which means you can actually update files with normal RPMs. How is that different from how your PC
03:42
boots? Very simple. Your PC boots first off by being a PC and not a Raspberry Pi. And then you have something some storage where you put your firmware in. On the Raspberry Pi, everything is on the SD card. On a real PC, you have something sold on to your board where your EFI firmware
04:01
usually lies. And that EFI firmware goes around and just looks at your hard disk, at your storage device or whatever they are, even a network, and just searches for something it should boot based on different algorithms. It finds something that it can execute and should execute in boot orders, which usually in our case OpenSUSE is GRUB 2, which
04:24
then uses callbacks into EFI to proceed, load a kernel, run that kernel, and you're good. So, you can see it's actually pretty similar to how the Raspberry Pi boots, just that you have a firmware piece of hardware rather than your SD card and you're not running off a GPU.
04:43
But other than that, pretty similar. So, what is this EFI thing, really? The whole talk is about running EFI, right? So, what is EFI and why are people so scared of it? I honestly don't know. Well, why they're scared, but I can tell you what it is. The really, really most important crucial core piece of EFI is something called
05:00
the system table, which is just a pointer to a struct that has pointers to structs that have pointers to structs that have either information or function callbacks. The most important one of them are the boot time services. That's basically a collection of around 50 function callbacks that you can call into to do
05:25
different things during boot time. GRUB 2, for example, uses those. I just took a few most important ones out here. Obviously, you want to load images, right? So, the load image callback, you just, if you have an image, a memory, and you actually want
05:41
to have it loaded into the system, you call the load image function with a binary that's EFI compatible. Anybody recognize what this might look like? You've seen that thing down there before? Yeah. It's a PE executable. So, basically, the same thing
06:01
that Windows uses. It's the same format. It's a pretty simple format, to be honest. A lot simpler than ELF. So, loading that into memory is not too hard. It's really just sections that you take and then put into RAM at different locations. And then you've got an entry point, jump into it, and that's all you need to do for loading. So, loading an image is easy.
06:24
The other really core piece of EFI is that it has a notion of objects. It doesn't call them objects and it doesn't call classes classes, but it is basically the same idea. So, you have protocols which are classes and handles which are your objects. And imagine you have a disk device, right? You've got
06:44
a set of disks, your first set of disks in your system, and that one set of disks can implement a class called a block operation class. You never give names to anything in EFI. They're all based on IDs. You have really long, 128-bit
07:00
long GU IDs. But this is basically just a class that says I can do block operations. And that consists of just a few function callbacks again. So, all of these are structs, right? So, this is a struct that basically tells you it's a struct. It's a struct inside a struct. And then in there, you have function callbacks that you can call to read or write to such a device. It's very, very simple. And it can
07:23
also have a second or third or fourth or how many ever you want different classes implemented by the same object. In the example of a set of disks, for example, you usually have a thing called a device path. Where you can find out where in
07:42
your device tree this thing is. So, this is like my disk is attached to a set of controller which is attached to a PCI device. And then you can just walk through this path. So, it's really just a simple means of providing access to objects. And objects can be, I would tell you, enhanced
08:01
too. So, you can load another driver that then adds objects to your object list and exposes different devices basically with this. And the next really cool thing that EFI does, which is important for filmware, is it manages memory. You always want to know which memory in your memory space
08:20
is already occupied and which isn't. So, EFI maintains a memory map that you can always ask for. Where it just says, all right, so at this address, I have some space available. At that address, everything is already occupied. At this address, there's nothing there at all. At that address, we got one time services. I'll get to this later. And say down here is a lot of memory available again.
08:43
If you allocate memory, what happens is that EFI basically just goes and says, oh, you want one megabyte allocation? All right, I'll swing down an existing available size and add one more blob for your one megabyte allocation. We turn this thing to you and that's it. It doesn't do anything beyond this. So, if you don't
09:01
free this, it will still be allocated by the time you exit your application. Which, by the way, GRUB2 does. So, memory allocation is really simple too. You can always ask for your memory map. You can receive it whenever you like. It's always up to date. So, you always know how much memory you still have available for allocations. Console is obvious. It's just pointers
09:23
to the console objects for standard in, standard out. And additional tables contain fancy things like your device tree or your ACPI tables, your DMI tables. Everything that's just arbitrary data that you want to have somewhere in memory and know where it is, it's just put as with IDs into those arbitrary tables. So, it's just
09:41
tuples of ID and pointer. Runtime services are a really, really cool thing in EFI. Imagine you boot your PC, right? You boot it up and you have a lot of RAM. And initially when you boot, of course, EFI is running there. And EFI owns some of that RAM. Now, EFI goes and loads GRUB. GRUB goes and
10:02
extends itself, allocates a lot more memory, loads Linux into that space. Linux gets loaded into real memory and then what? Well, then at this point, Linux actually is also an EFI binary that executes and talks to EFI and tells EFI, you know what? EFI go away. I don't need you anymore. I'm done with booting. I don't need booting
10:23
anymore. Please give me the machine. I want to have access to all of that memory without asking you for it. So, it does that. But one thing that you can do with EFI is you can still preserve some of EFI in your memory space by having that block be self relocatable and
10:43
Linux calls you with your new relocation addresses on it. So, this block is still available while Linux is running. So, Linux can call into functions inside of that small space and then those EFI runtime services can still do operations on behalf of Linux. So, this is code that
11:02
actually is filmware code that you just call into. And the most obvious examples for runtime services are get time. So, you can ask EFI what time it is just to access the real time clock. You can ask EFI to give you a variable or set a variable. You have some variable
11:20
space in EFI and you can ask it to reset your system, for example. Please reboot now and you don't need to care about 50 different power management units or whatever you have out there. It just reboots the system. So, it's a really convenient hardware section layer for you. So, how do we bridge U-Boot and EFI?
11:45
How do these interfaces even match? I mean, U-Boot is a completely different world, isn't it? It's done for embedded. It doesn't have anything to do with a real cool service that do have EFI. Well, if we take a really deep look, memory management, yes, sure. We need to write new code to support
12:03
all the memory management that EFI exposes in U-Boot. Because U-Boot doesn't have a notion or has a notion of memory allocations but it's different from what EFI thinks it should be. But anything else, if you look at the network stack, well, there's a network stack in U-Boot. So, if we just write small web code,
12:23
we can as well just access the U-Boot network code from a random boot time service callback. The same goes for console, for disk, all the devices actually look almost the same on their interfaces if you really compare EFI interfaces and U-Boot internal interfaces.
12:41
So, all we need to do to support calling into U-Boot code from a boot time service function callback is to write a small wrapper that just converts function semantics for us. For runtime services, that's slightly more complicated because U-Boot doesn't have any notion at all of runtime services. It only knows how to run
13:02
at boot time and then tries to just completely disappear. However, it's not really hard to do either. We need to basically teach a function like the reset CPU function to be runtime service aware. That's a patch of about three to four lines at this point per function that we want to call.
13:22
And at that point, we can just call a wrapper, run the CPU reset function and you get fully working runtime services in U-Boot. So, I have enabled this for Raspberry Pi 3, or Raspberry Pi in general actually, and the layer scape trendy 85 systems.
13:42
But adding new support is really a matter of a couple lines of code, so it's trivial. Get time, we don't implement at all. Reason is most boards that you have out there don't have a time to, don't have a clock to ask. If you don't have a clock, you can't really return a working time.
14:01
And same for variables, if you want to support variables, we would need to support storing variables somewhere and reading variables from somewhere that doesn't collide with what Linux actually uses at the point in time when Linux calls our runtime service code. We don't have those separate devices on most devices that we want to support with this.
14:21
And for additional tables, very simple, we just put our device tree in there. We have a device tree, we can load the device tree, we put it in there, done deal. And at that point, we actually have everything we need to execute an EFI binary, right? So if we take a look, this is just a boot log from a zinc MP system. It just boots up into U-boot and then gets you to a shell.
14:41
All right, so what we need to do to boot an EFI binary on these with current U-boot, so if you just take U-boot 20, 16, or five, for example, it's all implemented. All you need to do is load your grub binary, load your device tree, and call boot EFI, done.
15:01
Gotta grub. It's as simple as that. So if you take a current U-boot, you can always just manually load an EFI binary, which could be grub, which could be, the Linux kernel itself, it's also EFI binary, can be anything that you like. It could be the OpenBSD bootloader,
15:20
whatever you prefer. But if we go back, actually, and take a look at this excerpt, one thing you might have realized while reading through all of these lines here is there's something on down there that's called Auto-boot. So what is Auto-boot? Auto-boot just means that U-boot goes in and executes a boot script
15:41
that's predefined in the configuration. And on most systems these days, that's a distro script. It's just a set of templates that go through a list of different devices and searches for known good sources of booting from them. So really, the distro script just goes in, searches your disk, and looks if it finds an EFI binary
16:02
at the spec-defined removable location path for EFI binaries. That's just part of the EFI spec. And searches if it can find a device tree. If it doesn't, it just doesn't load it. And then usually, of course, your EFI binary is grub2.
16:21
So you don't press any key at all, and it just automatically finds everything, and you get grub. Which is pretty much how you want to boot these days. You don't want to mess with boot scripts. You don't want to mess with anything at all. You really just want to have things work out of the box. So where are we standing? Pretty good. As you can see, everything's implemented.
16:43
So we have EFI objects. We have console support. We have disk support. We can even do pixie boot support. I see pixie boot by now. Video support works. You can see graphical output. We can run grub2. We can run Linux. I have not tried to boot Windows yet. There were patches on the mailing list to enable x86-64
17:04
about two days after I posted my first patch set. So it really is not hard to enable a new architecture. But they haven't actually progressed since because the guy was doing something different since then. And I don't know. I don't really care too much about booting Windows right now.
17:20
If you compare code sizes between enabling EFI support and not enabling EFI support, you can see that the difference is negligible. You increase your code size by somewhere between 10 and 20k, which, if your code is already 500 kilobytes big, 10 or 20k doesn't really account for anything at all.
17:41
It's completely negligible, which means that upstream, we're now enabled by default. So if you just take U-Boot and you do a dev config for a board, you get EFI support on today's U-Boot. You don't have to mess with anything at all anymore. You don't have to mess with U-images, with Z-images,
18:02
with anything. You just run the grub and it works. Since I'm telling you that everything works, I should probably also show you that it works, which is more fun. So for the demo, I'm going to plug this Raspberry Pi 3
18:25
I got in here into the HDMI connector and connect power.
18:50
I hope this one works. All right, there you go. So this is U-Boot. This is GOP 2 booting up with graphics and everything, all the bells and whistles you would usually know.
19:00
If you have a USB keyboard attached, you can even use the USB keyboard to edit a command line, do whatever you like. It boots into Linux and there you go. You get a fully working distribution with just the way you would usually expect it to work, with all the YAS bootloader things working, with all the Perl bootloader updates working. Everything just works the way you would imagine it to have
19:20
worked from the very first day. I'll just leave it at that one. So the next slide is really just a thank you and go out and try it for yourself.
19:41
And do you have any questions? Seifer, please get a mic there right next to you. Yes. What's the idea behind slowing down the Raspberry Pi boot even more, with more complicated stuff? I mean, the one thing, if this doesn't work,
20:00
people will go Googling and ask why it doesn't work. Everybody will tell them to go away. Just boot the Raspberry Pi like it's supposed to boot. It depends on what your goal is. Is your goal to support the Raspberry Pi? Boot the way the Raspberry Pi does it. If you want to really actually do it the Raspberry Pi way,
20:21
use the downstream kernel, use whatever method you like. I don't care. If you want to boot the Raspberry Pi, like you boot any random normal system, if you want to actually go towards a maintainable future, you want to have that path. But then it needs to speed up a lot more,
20:41
because I mean, it's a hell of a lot slower than booting a normal boot with. There was a 10-second timeout. Yes, it does boot slower, but that's all things that are going to go away.
21:01
The big advantage of this UUMI enablement, in particular for the Raspberry Pi, is here that you now have a boot menu to select different kernels, because the way it worked before is that when we updated a kernel, and the new kernel for some reason didn't work, like some kernel had, and then you were kind of stuck,
21:20
and you now had to take the SD card and put it into a different machine, tweak some links and so on, and now with this couple seconds more in the boot process, you can just select a different kernel if the default selection doesn't work and you still have a working system. You can also add a command lines on the fly from the bootloader.
21:41
It just basically moves your Raspberry Pi from a device that you target to a device that you work on. That's basically the shift. It goes from this is something like an embedded device, like a mobile phone, that I just want to cross-compile things on my PC on and then push them onto the device over towards this is the device I'm actually working with and working on.
22:01
You would never imagine to directly flash your kernel into your flash chip on your PC, would you? Well, maybe you would, but nobody else who is sane would. So, would this also mean that if you have butter FS and the snapshots that it's all just working?
22:21
Yep, all just working. Butter FS, snapshots, snapshot rollback booting, all of that just works out of the box. The other question I have is around pixie boot. So, pixie boot is not implemented by the firmware in that case, so it's really done on the UFI side or? Okay, it's probably just a naming problem.
22:42
EFI is the specification that tells you how to implement these interfaces. U-Boot implements that specification and TianoCore implements that specification. You can use both to boot your system and at that point because you're booting your system from those pieces of software, they become your firmware.
23:03
So, on the Raspberry Pi, U-Boot is my firmware. On your PC, a TianoCore based fork from your vendor is your firmware. It's just a naming thing. And that firmware implements EFI. Or actually it implements UEFI because it's 2.0.
23:23
But it did work, that's the important part. Say again? Pixie boot will just work, that's the important part. The point about this is it won't be any different from a PC at that point. As soon as you have your U-Boot on there, it will behave as a PC does or like the overdrives that we saw earlier do.
23:40
Just at a much lower price point. More questions? Size of relief? All right, great. Well, thanks a lot.