WEBVTT 00:00.000 --> 00:18.640 Okay. Thank you. Can you all clean me? Yeah, it's a little bit loud sometimes. So, thank 00:18.640 --> 00:26.000 you all for coming. I'm going to present today a journey on how to add a risk 00:26.000 --> 00:35.040 five support to my favorite operating system. So, a little bit about myself, my name is Adrián 00:35.040 --> 00:41.120 Vladó, I work for a small company in Romania, cloud-based solutions. And for the past 15 years, 00:41.120 --> 00:48.240 I've been doing quite a lot of software work in the cloud world. I don't know if anyone 00:48.240 --> 00:55.680 here, it's familiar with OpenStack. Anyone? OpenStack, guys. Then of course, OpenStack 00:55.680 --> 01:04.400 could change to Kubernetes on OpenStack containers and here we are. I have also a few 01:05.680 --> 01:15.680 years of experience in making short Linux actually works on hardware or software virtualization 01:15.680 --> 01:24.880 like Hyper-V, also did a quite a lot of work on R. So, that's my background. I'm a flat-carbon 01:24.880 --> 01:30.240 container, flat-up container Linux maintainer, maintainer. So, this is the favorite operating 01:30.240 --> 01:36.480 system that I'm really going to present about. You can find me on GitHub and you can shoot me 01:36.480 --> 01:47.760 any mail if you want. So, let's establish some outlines. Why it is five? Why flat-carbon 01:47.760 --> 01:56.000 container Linux? And also the bulk of the presentation will be about how I managed to add 01:56.960 --> 02:04.960 another architecture support to flat-carbon. And if the networking works, hopefully I will present 02:04.960 --> 02:13.520 you a demo with flat-carbon running Kubernetes on it on R.5. Hopefully that works. So, a little bit 02:13.520 --> 02:21.120 of history actually found out about R.5 two years ago here at Fosden and decided, oh nice, let's 02:21.120 --> 02:30.720 let's see how it works. And then last year it was a big year in R.5 because a lot of chip hardware 02:30.720 --> 02:37.440 appeared on the market. And I thought, okay, maybe it's time to buy one, get one and see how it goes. 02:39.040 --> 02:47.920 I decided to get one of those boards. And of course, as a normal thinker would do, I actually 02:47.920 --> 02:57.280 end up buying three boards, not one of those. My background about R.64. So, I've been doing this 02:57.280 --> 03:03.520 inkling with Raspberry Pi from the Raspberry Pi version one, two, three, four. I have a lot of 03:03.520 --> 03:08.720 Raspberry Pi's at home and a lot of other boards. So, I thought, okay, it might not be so difficult, 03:08.720 --> 03:18.960 after all, to also work with these five. So, first board I got, it was in February last year. 03:18.960 --> 03:26.720 And the best board that you can buy from the market was the L.C. Pi 4A. Anyone here has such a 03:26.720 --> 03:39.360 board. So, this was the entry point for me as a thinker because it had quad core, had an availability 03:39.360 --> 03:49.520 of 16GB of RAM. Unfortunately, it had only as the cards in EMMC. So, the NVMe part was lacking. 03:50.480 --> 03:57.600 So, what did I do? Well, I bought one with NVMe support right. This one is the high-five unmatched. 03:59.200 --> 04:07.920 It's a precious board. It's an amazing board. Although, I found out after I bought it that the NVMe 04:09.760 --> 04:16.240 microcontroller was not that fast, but still, I could use it with an NVMe. And then I found out 04:16.240 --> 04:27.360 more about the how old let's say environment works. That canonical supported this board for like 04:27.360 --> 04:34.240 three years already, which was amazing. And I could basically run a bunto on it without an issue. 04:35.440 --> 04:41.600 Then I found out that the bunto image came with a downclock of the CPU. 04:41.920 --> 04:50.080 Very interesting. Then I learned how to overclock it, of course. And it's working very well. 04:51.280 --> 04:59.120 Then in October, 2024, came the banana pie of three, the new CPU, the spadesmith, 04:59.760 --> 05:05.920 spadesmith X60 with the M1 or K1 variant. This one had the K1 variant. And this board 05:06.000 --> 05:12.720 did all the boxes, had NVMe, had enough from to play with, had vector extensions, 05:12.720 --> 05:17.200 almost all of the boxes, because it doesn't have a H extension, the virtualization extension. 05:18.800 --> 05:25.280 So, I was ready. I had the boards. Okay, let's see how I can go further. 05:27.520 --> 05:30.880 It's being said that, and I strongly believe that the Linux, 05:31.840 --> 05:40.080 the Linux equivalent of the CPU in structured set of textures. And I really like that. 05:41.920 --> 05:50.000 The recent availability of hardware was the tipping point for me to actually involve time 05:50.000 --> 05:59.600 into this file. So, because you have to test on something. And the only way to test it is with 05:59.600 --> 06:06.960 KEM formulation. And I will show a little bit later on the demo how slow it is. You can not 06:06.960 --> 06:12.720 use the most of the time on waiting, which is wasted time here. 06:14.720 --> 06:22.160 You can get it for a personal ownership. And there's also a provider that 06:22.160 --> 06:29.120 scale weight that started offering from last year away to cloud. 06:35.680 --> 06:42.320 Can I maybe I should remove my microphone or to the point of the device to be called it? 06:42.320 --> 06:50.320 Okay, thank you. So, scale weight offers this, basically to paper per the time used of that 06:50.320 --> 07:05.040 bar metal, which is amazing. I could remove it because I could remove it, because I could remove it. 07:20.480 --> 07:34.480 Maybe this way? Yeah. Okay, perfect. Then I decided, okay, and also for this five, 07:34.480 --> 07:39.920 two, because it's fun. I like tinkering with stuff. And I see a quite a bright future ahead. 07:40.640 --> 07:48.160 I'm not going to enter into a geopolitical things, but things are looking great from 07:48.320 --> 07:57.120 a number of perspectives for this five. Okay, why a flat car container links? I'm a flat 07:57.120 --> 08:05.520 car container links maintainer. And I thought that, okay, we sport and this 64, 164, why not try to 08:05.520 --> 08:12.080 at support for this five? Flat car container links is an image-based operating system. It's a very 08:12.240 --> 08:20.640 minimal operating system. It's secure and reliable by design in the sense that it's very 08:21.280 --> 08:29.600 compact and it's also immutable. So, and the only purpose for flat car is to run containers. 08:30.240 --> 08:36.800 Basically to run Kubernetes in today's world, in the cloud native world. Of course, you can 08:37.120 --> 08:46.000 run also virtual environment, of course with Kubernetes, but that's the main idea for flat 08:46.000 --> 08:54.080 car container links. Okay, so starting for this five support. I had to look first at the flat 08:54.080 --> 09:01.040 car ancestry. Flat car was a drop in replacement for Coroés. Anyone here remembers Coroés? 09:01.600 --> 09:12.880 Still use Coroés? Fedora Coroés? Okay, flat car. Perfect. So, it's a drop in replacement for Coroés. 09:12.880 --> 09:20.480 It's a direct fork and it had evolved over the last four or five years into a, let's say, 09:22.480 --> 09:29.280 to follow the legacy of Coroés. Important note that flat car via Coroés is the downstream 09:29.360 --> 09:37.040 fork of Gen 2. Gen 2 is the basically where flat car draws its packaging system. 09:39.040 --> 09:46.560 And it's good to note here that it draws the way to build the packages. It doesn't draw the 09:46.560 --> 09:54.880 packages itself. So, it's a source based operator system in the same sense as Gen 2. Gen 2 is just the 09:54.960 --> 09:59.200 way of building those packages or provides the way of building those packages. 10:01.840 --> 10:07.360 About this tomorrow there will be a presentation about how flat car communities and Gen 2 communities 10:07.360 --> 10:12.160 work together and how they help each other, you know, going back and forth with the packages, 10:12.160 --> 10:20.720 and the things. If you'd like to then my colleague James will be presenting that tomorrow at 10:21.040 --> 10:28.160 90th. Important part too is also about the necessity of the ability. So, being immutable, 10:29.200 --> 10:35.520 there is no way other than using containers. Because if you cannot change the OS, 10:36.320 --> 10:43.040 there's just the container way. There's no other way. Upgrades are also done 10:44.000 --> 10:49.920 so being immutable, upgrades have to be done via the AB partition in scale. Like Stimois 10:49.920 --> 10:55.600 another operating system. Because if you cannot change it, you have to have another partition. 10:55.600 --> 11:02.160 And then at the reboot time the B partition becomes the A partition, the active partition. 11:02.160 --> 11:08.480 So, this is how upgrades work. This is all important for the risk support. 11:08.800 --> 11:17.040 So, Gen 2 has already support for this five. It's currently in the unstable architecture, 11:17.040 --> 11:25.360 but most of it is already working. Last year after the first day, I got my leechy pie for A. 11:26.000 --> 11:33.200 I went to Gen 2 and okay, let's see how far I can go. So, I could actually go really far 11:33.200 --> 11:38.240 the root file system from Gen 2 was perfect. It was working on this five. The only problem 11:38.240 --> 11:48.720 is with all the boards for this five. He's that they always, at this moment, require a very, 11:48.720 --> 11:54.160 let's say, different kernel so-street. They're own so-street. There's no way to use the vanilla kernel. 11:56.000 --> 12:02.480 Also, the way of doing the DTPs and the other stuff, the firmware, it's again. 12:02.480 --> 12:10.240 So, what I ended up, I actually took from, took the kernel and in it are the, from the 12:11.600 --> 12:18.160 already working operating system. The one that came with leechy pie for A, put the root file system 12:18.160 --> 12:24.400 of Gen 2 and it put it magically, everything worked. I was lucky in this because the, 12:26.000 --> 12:32.080 there was the same kernel major version. Otherwise, it wouldn't have been possible, but it worked. 12:32.480 --> 12:41.440 It was a miracle. Okay, I booted it. Then I tried to, okay, do I have Docker? Yes, I have Docker, 12:41.440 --> 12:48.480 if I build Docker, right? And after one day, I could finish building Docker because Docker is not 12:48.480 --> 12:57.360 Docker. It has continuity, it has tons of packages. So, on the leechy pie, it took me around 12, 14, 12:57.440 --> 13:03.200 20 hours to actually build Docker. So, that doesn't work. That's no way working. 13:04.000 --> 13:11.280 So, flatcard is solving this already because flatcard comes as a, as an image, as an image of 13:11.280 --> 13:17.200 based operating system. And afterwards, you have Docker and then there's a lot of great support 13:17.200 --> 13:23.600 from the alpine community. Anyone here using the alpine list five Docker images? 13:24.160 --> 13:31.200 There, I mean, they have support for anything and everything. You can, you just get a GCC 13:32.160 --> 13:38.160 and all the building libraries and you just build stuff on top of using the alpine. You don't need anything, 13:38.160 --> 13:43.600 any compiler on flatcard, for example, to do your work afterwards. So, it's, it's quite amazing. 13:43.600 --> 13:48.640 Does it mean that everybody who inherits alpine image also supports this file? 13:48.640 --> 14:01.280 Sorry. Can you, does it, does it mean if anybody use alpine image to build a Docker image? 14:01.280 --> 14:03.920 Will it also support this file? 14:03.920 --> 14:10.000 No, so, so how it works? The flatcard operating system already has to have a kernel for this 14:10.000 --> 14:19.200 file. So, you can actually use with some shenanigans, we clear KEMO on other architectures. 14:19.200 --> 14:26.640 But by default, you should have a flatcard running risk-5 and then using the Docker image for risk-5. 14:27.200 --> 14:34.320 The Docker images are separate 100% separate for each architecture. So, it's not just one Docker 14:34.400 --> 14:41.040 image for alpine latest, for example, there are three or, well, how many for how many architectures? 14:41.600 --> 14:47.920 So, yeah, it won't work directly unless you use KEM and you will end up in the same problems 14:48.480 --> 14:52.720 of a slow environment. So, yeah. 14:53.600 --> 15:07.280 I have a question. Yes. Have it tried, I have a question. Have it tried using DCC and cross compilers? 15:07.280 --> 15:12.640 Do you leverage something like, I'll be, I'll be going exactly to that topic. 15:13.200 --> 15:18.400 So, we have a bit of materials for the flatcard to build flatcard. What does it mean to build the flatcard? 15:18.720 --> 15:26.240 Flatcard heavily relies on an SDK. That SDK is a Docker image, it's a very big Docker image 15:26.240 --> 15:34.880 amounting to something like 10GB. Which, and there are all the libraries necessarily, all the 15:34.880 --> 15:43.440 cross libraries to build flatcard. There's also the flatcard packages which you put into the flatcard 15:44.400 --> 15:51.440 OS. So, we have to disobey here that in order to build flatcard, you need to have more packages than the 15:51.440 --> 15:57.840 packages that make flatcard up. So, that's why, how wide the Docker image you exist for the SDK. 16:00.080 --> 16:07.680 Of course, in the middle of materials, flatcard heavily relies on two things, system D and ignition. 16:08.240 --> 16:17.840 Anyone here used the system DCC6? Do know how, what they are. So, system D C6 16:20.240 --> 16:28.000 being a new table comes with a problem. You cannot augment the immutable file system. 16:28.000 --> 16:35.200 But, what if you have an overlay which is immutable and then you have system D C6, put it on top 16:35.200 --> 16:42.240 of the already unignutable stuff. Practically, it becomes mutable, but it's not mutable. 16:42.240 --> 16:48.160 It still is immutable, but it's composable. So, this is how we solve the problem of 16:48.160 --> 16:56.320 composability for an unignutable operating system. There are more steps, but it works. 16:57.920 --> 17:03.280 And then you have the root file system, you have the C6, you have the flatcard packages, 17:03.280 --> 17:08.400 then you need to put that root file system to have a put loader and you need RD 17:09.360 --> 17:15.840 to work with the utilization and also to work with the DM variety. It's a security feature for flatcard. 17:19.840 --> 17:24.960 So, the first, the flatcard is the K Docker image based on the Gen2 bootstrap workflow. 17:25.920 --> 17:31.600 Currently, supports NM D64 and NM 64. And everything is cross-compiled. 17:31.600 --> 17:38.080 The RM 64 is cross-compiled on NM 64 machines. So, the Docker image for flatcard is the K, 17:38.080 --> 17:43.440 it's only NM 64. Everything, including NM 64, is using the cross-compiled 17:43.440 --> 17:51.520 for NM 64, but everything is done in the cross-compiling way of thinking. 17:52.480 --> 18:00.560 Okay, let's use the same workflow for RIS5. So, important, I had to create a new profile. 18:00.560 --> 18:13.760 This is Gen2 Quartz based on the system DLP 64D, which is the implementation for floats in the CPU. 18:14.480 --> 18:20.720 And a few flags. And now, nowadays, to build even, to build Linux kernel, 18:20.720 --> 18:26.160 you need more than GCC, you need also REST. So, again, REST comes with its own 18:27.600 --> 18:37.440 cross-compiling stuff. So, add that more to the Docker image. And then, always, in order to cross-compile, 18:37.440 --> 18:43.360 you will find some packages that, in their Mac files, they do cross-compile stuff, 18:43.360 --> 18:47.600 you know, you have a binary. And then, SNAP, I want to run that binary. 18:47.600 --> 18:57.440 To create config files, to create something. And that is solvable via the QM static process, 18:57.440 --> 19:03.840 or binaries. So, if you install QM, you will have always the QM static, REST before. Sorry, 19:03.920 --> 19:15.040 it is QV 64, or REST 64. And with bin and bin format, it is a small service that when you are 19:15.040 --> 19:21.680 trying to run binary for another architecture, it basically hooks up into the QM static. 19:21.680 --> 19:26.320 And it works. Magicly works afterwards. Slow, but it works. Perfect. 19:26.960 --> 19:38.800 Okay. So, I have the SDK boilerplate definition, but some of the packages need some tricks. 19:38.800 --> 19:49.200 Let's see. Here, Flatkar has two sources of packages, or two package categories. 19:49.200 --> 19:54.240 Once they are, when inherited from CoreOS, and were special to CoreOS, 19:55.760 --> 20:04.080 some that are only flatcard packages in the sense of, they work for some cloud providers, 20:05.040 --> 20:10.960 some virtualization platforms, and so on. And those are updated manually, most of the time, 20:10.960 --> 20:18.000 and infrequently. Here, it is also the package to be a Linux kernel system, because we have a lot of 20:18.000 --> 20:24.640 packages, grub, and then more. Basically, the most important packages are not only the source 20:24.640 --> 20:32.960 thing and a part of how Gen2 does it are coming to Fatkar, but they are very specific. 20:33.680 --> 20:41.280 And the most part, the biggest part of the packages are, they are just mirrored once a week 20:41.360 --> 20:50.560 of Gen2 tested and made sure everything worked. And those ones, were already had the risk five 20:50.560 --> 20:58.800 support, so there was no problem. The most part was spent on adding those CoreOS, the legacy 20:58.800 --> 21:04.160 once to make them work with Tories Tv. Basically, to add a risk of the keyword, and then just 21:04.240 --> 21:12.640 pray that they build on risk five. There are some Gen2 packages that need some fixes, 21:12.640 --> 21:22.480 and some of the work also got upstreamed already to Gen2, basically, because of Fatkar, sometimes 21:22.480 --> 21:31.840 uses very niche packages, very niche packages, and Gen2 is a very big ecosystem. So there's no 21:32.480 --> 21:41.600 possibility for any package to support any architecture. Okay, so boilerplate to work done, 21:42.160 --> 21:49.440 do we have a Flatkar is the K, not really? So there are a lot of packages that are not really 21:49.440 --> 21:55.440 supported by risk five, because they're not supported by Linux in itself. For example, the K exact Tools. 21:56.080 --> 22:03.360 I think they work only for AMD 64. Some cloud provider packages, like Azure VM, Amazon agents, 22:04.480 --> 22:12.320 secure boot packages, like Shim and ShimSign, they had to be confined only to basically remove 22:12.320 --> 22:19.360 from the risk five profiles. And then Flatkar also supports from a security perspective, 22:19.360 --> 22:29.360 supports via SystemD, locks to, with stores like TPM, and that had to be fixed, also, 22:29.360 --> 22:35.040 Sim that the Gen2 is not actually supporting it for a risk five. And of course, 22:36.720 --> 22:42.640 everything is five, like with ARM 64, it's an FE implementation. So everything 22:42.640 --> 22:49.280 FE related had to work. There are some issues with LibFFI, the foreign function interface, 22:50.240 --> 22:57.040 that's a pain at any time, from the Python perspective. And some goline, let's 22:57.040 --> 23:02.400 ask the architecture or close compile flags that have to be taken care of. 23:04.480 --> 23:11.120 So we are getting here, getting very close. What did next on the menu? Linux kernel. 23:11.840 --> 23:19.680 So I had to remove the same hypervith support from the risk five config, because it's not supported 23:19.680 --> 23:28.240 or well supported on on on on this five, um, important part. Initially, I wanted to test Flatkar 23:28.880 --> 23:35.440 with the hardware devices, the the actual hardware boards, but then realized that's going to take 23:35.520 --> 23:43.280 quite a while, and I have to use a very specific kernel for each. So I just took a step back 23:43.280 --> 23:48.960 and decided to test on the KEM simulation first, because that's easier. Well, it's easier, 23:48.960 --> 23:54.800 but it required extra work because the emulation, the KEM emulation, relies on some 23:54.800 --> 24:03.840 paravitualized drivers that I had to implement, it's called the HCI platform. And in order to have a 24:04.640 --> 24:16.800 KEM VNC console working, I also had to enable some PCI whole generic and a lot of DRM framework 24:16.800 --> 24:25.280 buffer stuff. Important, those two kernel parameters, FED bug and the early cone SBI, 24:26.000 --> 24:34.720 risk, you know, KEM emulation for this five heavily depends on the OpenSBI project, 24:34.720 --> 24:40.720 which is very close to the risk five. It's actually made by the risk five community. 24:41.440 --> 24:51.840 And as Flatkar supported or had kernel Linux 6.6, I had to support for KEM firmware configuration module, 24:52.800 --> 25:01.040 which was basically, I need to patch it. So after all, and after I think one week of work, 25:02.080 --> 25:06.880 I'm building the kernel and just trying again and again, takes some time. After one week of work, 25:06.880 --> 25:19.120 it finally got built. For Docker, I had it complained a lot about the linkers, so this was a 25:19.120 --> 25:26.400 gentle issue. I have to upstream it, but also Docker work. Docker container D Kubernetes, 25:26.400 --> 25:33.200 which were all transformed into system D66. We will see soon how that looks like. 25:35.840 --> 25:43.360 So we have the root file system, everything is working, success? No. So we go here to the, to the 25:43.360 --> 25:50.480 hard part, bootloader. Flatkar relies on the red, red hat packages for grub 2. 25:51.920 --> 25:58.160 Yeah, there's a lot going on there. The packages are thousands of lines of code. It's really, 25:58.160 --> 26:04.560 really hard, but it works from this five, because also Fedora supports this five, so everything 26:04.560 --> 26:17.680 worked there, but Flatkar from the Coroest legacy inherited a lot of grub 2 special workflows 26:17.680 --> 26:27.040 and functions in order for the AD partitioning tool work. In the sense that the grub had to know 26:27.040 --> 26:33.680 about which partition is active in order to set the Linux kernel command line parameters 26:33.760 --> 26:43.760 for the root. And that's fully a Flatkar grub package, so that's, that those had to be patched and 26:43.760 --> 26:51.360 made sure that everything worked. And also I had to find an interesting thing. For DM variety, 26:51.360 --> 26:57.920 there is a hash somewhere, and we have to store it somewhere, and we store it in the Flatkar workflow, 26:58.000 --> 27:04.880 we store it in the inner defile, but I had to find an offset where to put that hash, 27:04.880 --> 27:11.920 which should be free. Still working progress to know if anyone from the Linux community is here 27:11.920 --> 27:20.800 to tell me if I did a good job finding the offset, please let me know. Okay, then I tried visualization 27:20.880 --> 27:29.520 to on my litchie Pi4A and my banana Pi3 it didn't work. It seems that you only 27:30.880 --> 27:36.480 currently available board that somehow supports virtualization extension is the 27:37.440 --> 27:55.600 high-five premier Pi515. Okay, so next, demo time. Let's see how this works. 27:59.040 --> 28:06.160 Can you see the screen? Yeah, that's going to be a tough challenge. 28:06.480 --> 28:17.360 Let me see. Okay, a little bit better. Okay, so here I have the Flatkar operating system. 28:17.360 --> 28:26.720 And as you can see here, it's running or is 564. This is the Linux kernel 6.6. And if I do 28:27.600 --> 28:37.600 see all this release, you'll see here the Flatkar container Linux version 4187. So, I have it running. 28:37.600 --> 28:47.040 But what I like to show, okay, the important part is for Flatkar to be able to run containers. 28:47.120 --> 28:56.400 So that, okay, can we check if containers work? If Docker works? Oh, perfect. We have 28:57.120 --> 29:07.680 some yellow worlds running which run at some moment. Let's run it again. And now you can see 29:07.760 --> 29:19.280 the range of virtualization. To run a yellow world, it takes quite a while. So, this is why I'm 29:19.280 --> 29:28.560 actually waiting patiently for the H extension harder to actually be able to test stuff. 29:28.560 --> 29:35.600 But you see everything worked from the yellow world. Let me show you the system, the 29:36.480 --> 29:43.760 C6. So, what do we have here? So, we have the overlays which are themselves in 29:43.760 --> 29:49.440 usable applied on the big file system, which is imutable. So, we have a container deflatkar, 29:49.440 --> 29:58.160 a Docker flatcar, an OMQM, and a K3S. Why K3S? Because I wanted to run Kubernetes. Okay, 29:58.160 --> 30:13.440 do we have Kubernetes in the house? I think we should. It's working. It's working. Yeah. And I also 30:13.440 --> 30:22.560 when it was verified heavily with deployments, everything works, networking works, it's amazing. 30:22.560 --> 30:31.600 So, we have three, I call it a freelancer and we can also hit it. Right. And if anything, 30:31.600 --> 30:37.360 we just run, if we don't want Kubernetes, we just do Docker run, help find stuff and do APK installs 30:37.360 --> 30:43.520 or APK ads. And we have at our disposal everything from risk-life community there. 30:44.480 --> 30:52.160 Which is amazing. Okay. Let's, I wanted to actually show you something. 30:59.840 --> 31:02.880 Can you see my screen? A little bit bigger. 31:05.920 --> 31:12.240 Okay. So, this is the console log of the, so this is the console log, the SSH1, 31:12.560 --> 31:20.320 and what you see here is the VNC. I actually work quite hard to make VNC work with KM emulation. 31:20.320 --> 31:29.440 You will have here really good explanation on how it works, what needed to be done, 31:29.440 --> 31:39.360 what were the boot loaders used, because I have tried first with, so I have tried first KM emulation 31:39.360 --> 31:45.360 with EDK2, and then also with OpenSBI, both work, which is actually amazing. And you, 31:46.160 --> 31:54.320 at this link here, you will have download files for flatcard to test, and also the OpenSBI 31:54.320 --> 32:01.360 firmware binaries, and also the EDK2 firmware binaries in order to test. So, actually you can use 32:01.360 --> 32:07.360 any operating system with those binaries. Interesting enough, EDK2, it's actually based also 32:08.320 --> 32:14.400 on OpenSBI, so basically it adds OpenSBI. So, what I wanted to show you, 32:15.360 --> 32:19.040 is do a Sudori boot. Let's see what happens here. 32:22.640 --> 32:29.920 Okay, my, you see, my cry containers are going, okay, let me show, okay, 32:31.600 --> 32:35.760 just making sure that I'm in the home. So, we should see now flatcard booting, 32:35.840 --> 32:41.600 and I would like to show you something very interesting, how the, how all works from the boot loader 32:41.600 --> 32:47.920 perspective, what I use, okay. Hopefully, we have some time. 32:48.880 --> 32:56.960 Oh, five minutes? Yeah, so you can see, you can see right now the risk 5 EDK2 firmware. 33:06.880 --> 33:14.080 And flatcard booting. Flatcard heavily relies on the in-it-arty workflow. 33:15.040 --> 33:21.040 It uses something very similar to Cloud init is called Ignition, but most of the work that Ignition 33:21.040 --> 33:29.440 has to bootstrap the machine, the flatcard machine is done in the in-it-arty not after. Cloud init 33:29.440 --> 33:41.440 mostly has the user data and everything running in the normal after the in-it-arty pivot pivoting. 33:41.600 --> 33:49.840 So, flatcard is very special in this sense because you can control the behavior before, not after, 33:50.880 --> 34:01.120 or well, after it doesn't make sense, right? Yeah, now I have to fix this part, 34:01.120 --> 34:08.000 it will take a while, display output is not active to enable the frame buffers, so it will take a while 34:08.000 --> 34:18.080 until it boot. So, yeah, this I will, these are the slides if nothing worked in the demo. 34:18.080 --> 34:25.440 So, take away great, it looks great on risk 5. Most of the issues that I had to solve were 34:27.200 --> 34:36.480 cross-compiler issues, different things with packaging. Most of the work with the kernel, 34:36.480 --> 34:43.840 the bootloader and the DMVRity. And the biggest takeaway is that you can actually 34:43.840 --> 34:50.720 right now run Kubernetes, which is amazing because it opens up a door of possibilities. 34:52.240 --> 35:02.960 Testing is low, can wait for the new new board versions. And it would be glad to get some feedback 35:02.960 --> 35:09.920 if people want flatcard to have a visual support for this 5. We'll have to do a little bit more 35:09.920 --> 35:17.200 polishing and see where that goes. Of course, there's a backlog of patches that we have to 35:17.200 --> 35:27.040 backport to Gen2 to make sure that we pay our debt. And yeah, so here are the links. 35:28.000 --> 35:34.320 You can try it right now. Also, it's very useful if you want to try out the opening systems, 35:34.320 --> 35:41.280 as I said with the EDK to firmware and so on. Questions? 35:42.480 --> 35:48.800 We have one minute. I will take question of questions afterwards. We have very active in the 35:48.800 --> 35:56.080 flatcard community just, yeah. We can do one. 36:02.080 --> 36:08.320 This is extra for you. Oh, you can ask me afterwards.