Genode meets the Pinephone
Feske, Norman
Driven by the vision of a truly trustworthy smartphone, I dedicated the past year to bringing the component-based Genode OS to the Pinephone. The talk presents my experience story, touching on the hardware, booting, the porting of the kernel, component-architecture concerns, and device drivers. Smartphones have become a commodity almost everyone relies on. With the convenience, however, comes complexity that is impossible to comprehend and constantly changing. The opaqueness of hardware and software puts the user in a subordinate position, making their devices - and by extension many aspects of their life - dependent on the decisions of a few dominant corporations. Our personal devices are constantly changing under our fingertips. Steady updates are presumably needed to stay secure, similar to how medicine is needed to stay healthy. But are the incentives of the platform providers aligned with my interests? I want my digital life healthy without a constant supply of medicine! To reinforce trust, both hardware and software must become transparent, traceable, and tractable. The Pinephone satisfies the urge for transparency of the hardware, thanks to publicly available schematics and documentation. However, the predominant software stacks - even though based on the open-source Linux kernel - are practically inscrutable because of their immense complexity. Genode's rigid component architecture promises to bring order and clarity - and thereby trustworthiness - to the software. Over the course of the past year, I pursued the combination of Genode with the Pinephone, diving deep into the Pinephone schematics, the SoC, booting, Genode's kernel, and device drivers. In my talk, I present the experiences made, touch on the use of Linux drivers directly on Genode, and draft a plan forward. The talk will be garnished by a demonstration.
 Welcome to my contribution to this year's Michael Kuhnel Dev Vela Per Room at FOSSTEM. Thanks a lot to Martin Decchi and Sebastian Zumpf for organizing this year's Dev Per Room. So, it's a pleasure to be here. So, my name is Norman Feske. I'm from the company GenoDepps, the developer behind the GenoOS framework. And this talk will be about the last year's journey to bring together the GenoOS framework and the Pinephone. The talk will be structured in three major sections. The first section will be about the underlying motivation of this work. So, why have we even started doing this? The second part will be a bit like a picture story of what happened in the last year. So, I can't go into too many technical details, but I will give you some insights into the whole development experience. And finally, I will give you a brief demonstration of how GenoOS on the Pinephone looks right now. And finally, I will close the talk with an outlook of what to expect in 2022. So, when speaking about the motivation of this work, I have to really go back a bit to a kind of root concern of mine, which is basically a struggle that is getting ever stronger, I think, between really powerful, dominating corporations and the civil society. And the smartphones and the smartphone industry is, I think, one of the most impressive expressions of this power struggle. So let's take a closer look. So what are the motives behind corporations in general? So don't get me wrong, I'm an anti-corporate. I can understand what is how this works, but there is still some kind of problem arising from this. It's natural that companies seek profits, so I'm also running a company, so I know what this is about. So you want to be profitable, and there's also a desire for growth. It's natural for companies. The growth aspect is actually much filled by investors, for the most part, who demand growing revenue to have their assets increase their values. So what to do about it, of course, one way is to increase the customer base and the other way is you also have to keep the existing customers paying. It's clear. And whenever possible, raise the margins. That's basically a cradle. And what to do to keep the existing customers paying? It's called customer retention. So one way to do this is to leverage platform effects. So let's say if everyone is on eBay, then all sellers and buyers are going to eBay. So that's basically one thing that big platform companies strive for. Another one is to create artificial dependencies, so that customers have a really hard time leading the platform, and another strategy is to increase or introduce new complexity and then offer the aid to make the suffering of the customers less. So the basic, it comes down to making your customers addicted to you, to your products, because addicts are the best customers. And to make this even more efficient, it's always good to have as much information as possible about the customers, the market, the competitors, and so on. So there's a corporate motive to seek holistic knowledge without any bounds. And when it comes to smartphones, it's really easy to see that people are really some kind of addicted to smartphones. Actually smartphones play an ever more important part of our lives. But smartphones are a need of constant attention by the platform companies, or I would call it medication, because there's the sole story about the security. You have to keep your device updated. You have to keep it healthy. So you have to subscribe to some kind of service from a platform vendor to get new system updates. You have to use the platform provider's competence to save you from bad behaving applications. So there's this whole curation of apps. And you also expect the platform provider to entertain you a bit like following the latest fashion. So there's a constant stream of new supplies of kind of medication. And today's situation to corporations really dominate this whole business. So what about me as a member of the society? For a long time I have really not used a smartphone, and I'm still not a smartphone user, but this is not a long term sustainable strategy. So I want to participate in digital society, of course. So for example, I want to use a smartphone to look for the timetables for trains, or I want to use a COVID tracking application or things like that. So I'm not opposed to any kind of convenience that a smartphone provides. So I want to actually enjoy this utility value. But at the same time, I value my digital autonomy a lot. So I don't want to subordinate myself to corporate interests. What this breaks down into is that I don't want to have any changes on my devices without my consent. So I don't want to have questions like, do you want to install the update today or tomorrow? That's not a question I want to answer. I want to be in control of the device. I also want to be treated like a human being. So I don't want to be exploited. Like my attention should be mine. I should not be forced to look at advertisements. I don't want to be tracked. I don't want to data mind or anything like that. Finally, I want to keep my communications private by default, unless I decide otherwise. And I want to keep my personal data for me. And another aspect is that I'm always looking for sustainable paths in my way in my life. So in one way, that's the environmental footprint I leave. And the other way is that I want to keep learned skills usable. So if I learn how to operate a device, I don't want to learn it again in the next years. So there's of course a lot of conflicts of interests between those two goals. So first, I think that this whole trend towards subscription-based business models, be it cloud services or this whole security update story, is really a taxation of digital life. And people are slowly getting used to it, and they just transfer money over to corporations in a periodic way. At the same time, data gets more and more centralized into kind of the silos controlled by big companies. And those are the same companies who basically look through this data and make out the patterns, analyze this data, or even give this data to third parties without the consent of the end user. So the corporations have been extremely dominant and powerful in these areas. So and as another kind of aspect to it, because of the whole consumer cycle, that the pressure to always release new electronic products and to have customers buy new versions of the devices, a lot of electronic ways is generated. So these are all political problems. And ultimately, the micro-cronodevroom is not the right place to solve them. That's clear. But on the other hand, we as technologists, we can at least give politicians some kind of arguments that there may be alternatives pass forward. And this is the whole story about where my motivation comes from. It's not a kind of spleen that I only have for myself. There are a few others who share similar sentiments. So one prominent example is the precursor project by Bunny. It's kind of extreme approach to a mobile phone that takes open hardware and open software to an extreme. So the hardware is based on a custom SoC built in an FPGA and the software is completely developed from scratch. The device is deliberately a deviation from smartphones. It's more comparable to a feature phone, which kind of has a deliberate decisions of these developers. But what about smartphones? When looking at smartphones, one company really comes to their attention, which is the Pine 64 company that produces the Pine phone. And this Pine phone is marketed as an open source friendly phone, catering to the open source developer community, especially the Linux community. So the device supports the mainline kernel. There are diverse distributions. The SoC is a bit old, but it's well understood and it's quite well documented actually. And the nicest thing is that it's readily available and quite affordable. So it's a good device for tinkering basically. So that's really attractive. But open source is not enough. So even if we say, ah, we use a Linux operating system on top of this phone, isn't this all good? No, it's not because the complexity of this whole software and hardware combination defeats autonomy. So still when using a Linux system on such a phone, you make yourself dependent on this distribution and you have to be faithful in this software stack that is just incomprehensible complex. So we notice on Linux, for example, I'm using Linux for decades now. And whenever I update my Linux distribution, I think of, ah, hopefully nothing changes too much. And so there is a lot of phase involved and that's something we cannot overcome really with such complex software stacks. And finally, there is also no queue inside for this whole security update. Sorry. So this is something we have just have to accept. So of course, when looking at a G node, this is something that we at least promise to change. So when structuring the system around the idea of the principle of least privilege and sandboxing all tiny operating system and application functionality into small sandboxes, then this whole situation becomes much easier. There is no need to create applications or there's also much less need to keep the system medicated all the time. So it's more comparable to kind of cure than the relieving of symptoms. So that I think can be a huge contribution when combined with smartphones. And so I made it my mission to combine G node with the pine phone in the last year. So my aspiration is really to have a replacement for a feature phone, but also so basically featuring telephony messaging, but also doing being capable of using a web browser and encrypt doing encrypted communication and crypto storage. And also what's important to me is a half a decent battery life. So currently I'm using a Nokia phone, an old Nokia phone, which has a kind of weak of battery life, which is really nice. And I want to have this also in the future. I don't want to address any kind of entertainment or comfort functions that's currently out of scope. So how was this whole process about? So how did I start it and what looked at it at the different times? So when starting such an ambition, we first have to look into the kind of the way of how the operating system boots on a platform. So when the system is powered up, the bootloader takes over control, which is U-boot in our case or in the case of the pine phone, it's a default bootloader. And then this bootloader boots the first F image, which is basically a program that runs in physical memory. It's really called Bootstrap. And then from there on, this bootstrap program bootstrap to kernel and virtual memory and so on and so on. So the first thing is really jumping from U-boot into custom piece of program that gives us any kind of life sign. And so this is basically the first small challenge to come up with a small program that can be started directly from U-boot and gives us some characters on the zero line. So this is how it looks like. There are a few lines of C code, very simple, directly poking memory map dredges. Here for outputting some characters and then a small kind of bunch of instructions to compile the code into an object file loaded that can be loaded directly into the device memory. And you see then the results and this can make one really happy when this happens, because now we have passed the control to our own code. So the next thing that we aspire to do is to port the kernel, the microkernel. And here the all-winner SOC of the pine phone is really nice to us because it consists of components that are readily supported by the existing base HW kernel of the Geno2S framework. So it's a pretty aged by now 64-bit ARM SOC. It uses the standard ARM GIG version 2 interrupt controller, generic timer infrastructure, very simple UART interface and of course a custom memory layout that needs to be configured. But all in all it comes down to basically mirroring the platform support for an existing SOC, so for example the IMX8 and adjusting the files for the pine phone, like picking the right interrupt controller and setting up the physical memory layout. But this basically takes I would say a week or so, this is not a big challenge. But the biggest challenges come ahead of us, so the next small exercise to get the test met with the hardware is to access some kind of device hardware. So the first tempting thing to do is to run some kind of GPIO controls on the chip, so to toggle some pin state or to sense some pin state. And so for this small test program can be written that uses genotes, basic services like IQ and MMIO to access memory map registers and receive interrupts. And this is really fun because this draws the connection between the physical world like we have here, a pin that goes into the SOC, a physical thing that is basically a wire and it goes into the SOC, then it goes through a bunch of logic and then there is some device inside the SOC that maps this to a bus that's on the system bus, which then can be accessed by the software here. And the same thing for the interrupts, so this is interesting how this physical pin is basically wired up to the interrupt controller and then ending up in the micro chronos IRQ handler to the user application. So the nice thing about this step is that it really lets you see the physical effects of some piece of software, which is quite nice. So now the next thing when having this basic test running was to bring a bit order in this whole situation. So instead of allowing this program to access all the hardware, we introduced a platform driver that basically assigns a certain specific memory map IO ranges and interrupt numbers to this specific program. So there is a kind of access control enforced by the platform driver. And as another step, we go further, we put this or change this program into a proper driver with a driver interface that allows other programs to control individual pins. So here what we see is the strength of a microkernel based system. We have a cascade of authorities that can limit the reach of the programs. So here at the bottom, we have the kernel and the core component of GNOT with ultimate authority over the whole platform. Then in the next step, we have the platform driver which has handed over all the memory map IO resources and interrupts. So it has authority over all devices. But then it gives only a part of this authority over to this GPIO driver over here. And this again can assign a part of its own authority to a simple program. And so the actual program like this LED Pulse program here can access only a one specific pin in a specific mode, which really comes down to the principle of least privilege. The experimentation setup looks like this. So you can have some wires here, some resistors and an LED and can play with it. And this is all a lot of fun. And by the way, this board what you see here is this Pine A64 LTS board, which is mirror basically the Pine phone hardware and is also available at the Pine 64 store. So the next step up is the problem of dealing with real devices, not just filling with some GPIO pins, but some real drivers. So when looking at real hardware, real drivers, you see that on ARM as a C's, the situation is much more chaotic and less regular than on PC hardware, which basically is organized around the PCI bus. On ARM as a C's, it's more chaotic and you have to, you are faced with a lot of complex interplays between device details like the power regulators, clocks, reset lines, a variety of buses and many, many quirky details. And added to that, there are certain pin functions that can be selected for the SSE, which are at another level of obscurity, I would say, but it's of course, it's a nice feature of these chips, but it doesn't make the situation any easier. And on top of that, the documentation is often not available or quite sparse. So the only reliable reference to working systems is really the Linux kernel, because the SSE vendors are usually the ones who write drivers directly for the Linux kernel. And so we are now faced with the situation where we can look at the device trees that are shipped with the Linux kernels as some kind of hardware documentation. And the cool thing about this is that this documentation is really the ground truth, because it's actually kind of executed. So if there was a mistake in the device tree, then this Linux kernel would not work on this hardware, so that's quite nice. It gives us a lot of information about the hardware. We also found that because of this whole interplay between the different devices and the clocks and resets and so on, that the porting of the drivers is much more feasible than the developing of the drivers from scratch. So we concentrated completely on this idea of porting complex device drivers from Linux to genote. So when starting this kind of idea, it's useful to start with reasonably small example, like an Ethernet driver, and we will come to bigger or more complex devices later. So when looking at Ethernet and looking at the device tree for the Pine AS64 board, yeah, it looks a bit like this. This is a graph visualization of the device tree. It's basically incomprehensible. So to make some sense out of this, we came up with some custom tooling that processes this device tree files, and where we can say we are interested in a specific part of the hardware, in this case the Ethernet controller, and want to only retain things that are related to this part of the hardware. And here the tool spits out this smaller device tree which is in itself consistent, but consists only of the parts that are relevant for networking. And this becomes suddenly much more clear and can guide our way for porting code from Linux. Speaking about porting code from Linux, one intermediate step I always did is basically first trying to build a custom Linux kernel that is as bare bones as possible and only drives the hardware that I am after. So in the current case, a Linux kernel that drives the network but doesn't know a thing else really. The usual process is to start with a tiny config of Linux kernel, which is basically a Linux kernel that doesn't work really. So it compiles but it doesn't run, and then try to find the configuration values for the Linux kernel that produce a kernel that performs a bit of network functionality, like issuing a DHCP request. And to aid this process, we can look into the device tree, find information there about certain compilation units. From this compilation units, we can learn config options that are conditions for this compilation unit, so we can add these configuration options. We can also let our intuition guide us. So for example, it is logical that the internet controller also needs a food driver, so things like that. And also of course some kind of rational thinking. But in the end, there is a gap here in the middle where we can't really guess what kernel configurations options are needed. And for this, I came up with some kind of sledgehammer approach, basically bisecting the configurations of Linux to try out the minimal set of configurations. So each of these config options you see here require several kernel compiles and boots of the kernel on the platform. But it took maybe a day or maybe even two days to find out these options. It's quite a boring task, but it's terminating the process. It's terminating. And it leads us to these kind of minimalism, which is really nice. Because in the end, when we have this kind of small set of kernel options, we have a really tight Linux kernel that we can work with. And then it's time to transplant code from Linux to the G-node system, put it into a component. And here, we came up with a new version of Linux device driver environment, which allows us to use unmodified Linux kernel code here and combine this with a small kind of emulation environment of certain Linux kernel mechanisms like memory subsystem and in-it call handling and things like that. Then a small API layer for certain G-node interfaces that map the C++ interface of G-node to C interfaces. And then finally, we have the G-node API. On top, we can use the services then of the driver. And on the bottom, we can access the device. And so this is a very rigid scheme. So for example, we keep really C++ and C galvanically separated. So next thing is, so basically to wrap this up, once I got the network driver working, I switched my attention to the PinePhone as a development platform because that's my actual goal. And so I looked about the process, how can I work with the PinePhone? The cool thing is, it can boot directly from the SD card, so you cannot really break anything or break anything. You can always swap out an SD card and start from new, which is really nice. It's also cool that you can basically repurpose the audio jack to become a zero line, try just flipping as far as small switch, and there is an accessible reset button, which is really cool. For the workflow, some things should be considered. So for example, SD card juggling is not really convenient. And you look at these kind of Linux bisecting experiments, you need to boot the system like hundreds of times, and juggling an SD card each time is not viable. So other strategies are needed, and we can of course also not use Ethernet, so TFTP is out of question. So I looked at UBoat's fast boot support, also with the help of an old friend, Ivan Loskutov, who give me some really, really valuable hints. And so I could automate much of the workflow and also combine this with some custom automation tools in Genotes Toolchain. And as a small detail, there are these tiny things. So for example, you have this reset button in the back of the phone here, this is a small hole. So you are supposed to fiddle with a small toothpick or so in this hole to reset the phone. But when developing, for example, a touchscreen driver, you have to split to flip the phone for each test, which is really not convenient. So I came up with this small life hack here. So I had a small screw laying around, and by putting the screw inside the hole and flipping off the phone, the whole phone becomes a big reset button, which is really nice and extremely satisfying. So these are the small things that make life so much better. Yeah, now looking at the display driver, you see again this kind of part of the device tree that is concerned with the display. You see that it is a lot more complicated than the Ethernet part. So there are lots of questions to answer. So the process of cutting down Linux is more or less a mechanical work. It came really down to this small set of configuration options here. So this is actually enough to bring up this crippled version of the Linux kernel, which basically just presents us hooks and then to crashes, maybe. But it doesn't matter because it has successfully initialized the frame buffer, and that's what we wanted. So that's really nice. And so we can go on and select the driver sources that we find in the object files and look at them, consider them to include into our component, then compile and link the result. And if you see any unresolved symbols, we can generate dummy functions for these symbols automatically using custom tools that we developed over the last year. And yeah, and when such a function is called, we look closely to the called function supplement custom emulation code and try it again. And this is basically an iterative process that basically eventually leads us to this result. So a working graphics driver, which is extremely satisfying. So don't get me wrong, it's not all roses. It basically takes sometimes really long time to come up with this, but there is a very structured way of doing this. So now we have this frame buffer driver running on the platform. And when we can really see all the kind of devices that are accessed by this monolithic frame buffer driver, and this is really staggering. It also expresses how big intertwined all the different driver parts of this arm SOCs are. So the problem arises that when we try to add another driver, so for example, besides the frame buffer driver, we want to also have a touchscreen driver. So until suddenly we see a big conflicts, so that the same drivers want to access the same hardware resources. And this is of course not possible or not getting any useful results. So now we have to start the process of basically cutting those dependencies here and basically either adding emulation code in here and the drivers or putting in intermediate components that basically reconciled the access of those devices. So this is how it looks like in the end. So basically everything that's related to clocks, power and reset is basically put into a different driver component and both drivers access this higher level driver component and all things that are related to general purpose IO pins are basically going through this component over here. And now we have nicely reconciled those both drivers on the platform. So this is really the whole micro-colonial idea here. We now know exactly which parts of the SOCs are accessed by which driver and so we can also assess the reach of the driver on the system, that's really intuitive now. So now that I have covered these kind of small story about how the process went, let me give you a short demonstration. So as you may have guessed, I'm actually using genotes right now. So this is basically a scope-based system here. So this is my site program here and here I have a normal Linux, an Xubuntu Linux running inside a virtual box and the whole system runs on top of the Nova hypervisor. And in this terminal up here, I have connected this to the ZLine of the pine phone and over here I have a build directory for genotor for ARM V8. And now to give you the look on the pine phone, I will basically start a component to look at our webcam. So I will just deploy a small program here that basically captures the picture from the webcam and displays this in a window. And you can see here that this window appears here. So we can see the phone. So yes, some dust. Okay. So now I can issue the command to... So the phone is actually already switched on. So you see the red cable here. So the phone is powered. It's currently stuck in the U-Boot loader and it's waiting for a fast boot command. So here I can give it the command to basically run this Sculpt test run script. That's basically part of the genot tooling, targeting the base HW kernel, the board pine phone and also direct the log output to the core component of genot. So let's give it a try. So now there's not much to build. So we just integrate the image. And in this case, the image contains also some kind of pre-loaded software. So it's a bit larger than normal. So this takes a few seconds until the image is generated, but not too long after. You should see here that the system is booting up. And on the webcam, you will briefly see... Here it is. You can see that the user interface has been started. So you see now the same Sculpt OS that I'm running on this machine. So basically when I go back here, you see this same kind of system that I'm having on my machine here. The same system basically runs now on the pine phone, except for some details like no persistence storage. But for example, I can basically click on this or touch on these different user interface elements and user interface response to this. Also for example, when I touch the settings bar, you see you can basically change also some user interface settings. And one specific interesting thing is that I can deploy some scenario from memory. So I can use the RAMFS. So sorry, you cannot really see it. But I can tell you that now the system is deploying a genotes subsystem as a deployment. And here you see that some components have been loaded. I can switch to this kind of desktop by pressing it to the side here. And you see here there is a small keyboard here and a terminal over here. So I can basically... And there's actually a window manager running. So this is of course still inherited from the desktop version of Sculpt. And I can even drag these windows around and use this small keyboard. It's hard to see in the webcam. But I can basically type in a small command. For example, I can type in something like LS and return. And you see that this Linux... Not Linux, but it's a native genote-based UNIX environment. It's basically presenting some results. And I even can, in principle, also use things like Vim to edit all kinds of files on the system. And so, for example, also access the configuration file system of the Sculpt OS. So basically this gives me complete control over the device. Let me see. Q. Q. Okay. There's also a smaller demo I can show you. That's basically just rotating... Oh, maybe I haven't... Yeah, I failed to reach it here. I still have to train my fingers to type on the touch screen. So here a small program is coming up that basically... You may recognize this from previous talks. That's basically a small software rendering demo running now directly also on the Sculpt OS. And the nice thing here is that all the underlying infrastructure, like the package management concept, the deployment concept, the configuration concept, etc. It's all the same things, the same components as we use on the normal system on PCs. Okay. So that's basically what I can show you right now. So now to close the talk, let's give some ideas what's next. So the vision for this year is to have a video chat scenario running on the pine phone. So I want to chat with my family, for example, using this device, using G-Node on Sculpt. And there are of course a lot of challenges in the way. So these are just an animation of things we have to work on, which is at the same time exciting, but also a bit frightening, of course. But we are really driven towards this goal. If you want to follow the progress of this ambition, you are invited to visit the G-Node website, which is basically a kind of blog for various genome developers. And I am publishing an article series called Pine Phone, where I report on the progress that I make. And in the end, this article series will be integrated into a large document that's called the G-Node porting guide or G-Node platforms document, which will give a kind of guidance to future developers who want to bring G-Node to other SOCs. So for example, if any one of you is interested in the new Pine Phone Pro that is based on the Rockchip SOC, then this documentation is probably the best pathway to develop this kind of support. So that's already the first version of this document online, but it will be updated in May with the new findings. Okay, thank you very much for your attention. And that is the end of my talk. Thank you. So let's start with some questions. There are some questions in the chat. You or the others have partially answered them, but maybe we can just repeat them for the stream. So there was one question about the base HW. So could you just tell us what that actually is? Yeah, sure. So yeah, first thank you for organizing the deaf room together with Sebastian this year. So yeah, yeah, about the strange name of this kernel. So it's really the result of this naming scheme of G-Node. So G-Node, the G-Node OS framework supports quite a few different kernels. So you can use the G-Node OS framework on top of traditional four micro kernels or also on the Nova kernel or the SEL4 kernel or the Fiasco OC kernel and also on the Linux kernel. And at one time, like seven years ago, we had the idea to come up with a custom micro kernel that is actually much simpler than compared with the traditional kernels. So it has a kind of different software architecture that is glued more closely to G-Node. And by doing this, we expected to reduce the complexity of the base system even further. So we already had a pretty good or a pretty tight base system with the existing kernels, but we saw the potential that we could reduce it further. And so we came up with the base HW kernel. And the notion is that now G-Node runs on the real hardware, not with the kernel underneath, but the G-Node's low-level system is touching the CPU hardware directly. And so it's called base minus Linux or base minus Nova, but base minus HW, which means it accesses the hardware directly. But it's still a micro kernel. And in practical terms, it's your native micro kernel. Yes. It really fits your architecture perfectly. Exactly. Yes. Okay. So it's a small question, maybe just a clarification. So the demo you have shown, that was really running just on the phone. There was nothing running on the desktop machine. Yeah. So maybe it is the demo where I executed first G-Node on the machine, on the laptop, and then on the phone. Well, it's a bit misguiding, but yeah, the phone has a complete separate system running. And it's loaded as a single image through the fast boot channel to the phone and then executed standalone. So it's running autonomously on the phone. Yes. Wonderful. Another quick question. Do you plan to support the PinePhone Pro as well in the future? So not immediately. So the idea, so I have to come back a bit. One idea behind this work is that we will go, or the idea was to go through the process of plotting all these difficult technical challenges, but not only doing this, but also implementing all these steps in very much detail. So the idea was to, at the end of the whole process, there should be something like a book, I would say it will be like 300 pages or so, that explains in detail how this kind of process works. And so I hope, that's at least in my hope, that others will find this kind of idea inspiring that now someone else can also take this book and take a new hardware and apply the steps of this book to get G-Node running on this new hardware. So that's my goal to cultivate some kind of community around this idea. And so I put a lot of work into this documentation. So I would say more work was spent on the writing the documentation than on the actual technical work. And so I think that it would excite us very much if someone else would step up and take over this idea to bring G-Node on the Rockchip, for example, which is the chip used in the Pinephone Pro, and we would give assistance, of course, but the ownership of this project would be somewhere else. But anyway, if there's some commercial interest in that and someone would approach us, then of course we would be up to it to do this. Another point is, I think that the Pinephone is appealing because it's a limited platform. It's universally known to be not really strong, it's a bit dated. And if you look at the Linux systems on top of this platform, they do not perform really so well. So it's usable, don't get me wrong. I admire what's happening in this community, but it's not comparable to the user experience that we see on commercial phones or on consumer devices. And I think if we managed to really rock the phone with G-Node to bring a really nice user experience to the phone, it also would nicely allow people to compare the beauty of microkernel-based systems and the performance of our system to Linux to basically despell the myths that microkernel systems are slow. So if it performs better on the phone than Linux, then I think that would be quite exciting. But I cannot promise this, but that's my goal. Yes, it definitely sounds very intriguing, I should say. And going back to the UI, there was a question in the chat as well in that direction. So clearly the desktop UI is really not a good fit for this touch screen, small touch screen. So do you have any ideas or plans towards having really a smartphone native, you know, touch screen native UI? Yeah, so there are several ideas. I think it will be two-staged. So there is a one-stage where we have some basic interaction that gives the user control over the phone, but not much convenience. So that's basically what this user interface that you see right now presents. It's very small in terms of bytes. So the image is very tight and very small. It puts up quite quickly. And then there will be a second layer on top of that where everything is basically up to the different use cases. And for example, I think that it would be really nice to bring QT-based applications to this phone on top of G-Node. So for example, there is the SailFush OS that uses QT for applications. And so the applications on this phone on this OS are really native applications using QML and all the kind of beauty of this, what you expect. And there's nothing that's good to speak against leveraging these kind of frameworks like QT-QML on top of G-Node. And that's what you would then present to the end user, of course. But in the intermediate step, of course, we need to have some nice ways to interact with the phone as a developer. And so here are our kind of intermediate component like this touch screen keyboard comes to play. I think nobody really will enjoy it this, but it will have its purpose for our development and for hacking with the device, playing with the power management with the modem and all these kind of things. OK. There are several more questions, but sadly, the time is running out. So to prevent your answer being cut off, I would like to thank you again for this amazing talk. We are definitely looking forward to further development in this area and in G-Node in general. I encourage our attendees to ask you more questions in the chat. And thanks once again. See you. Bye-bye. Thank you.
 Welcome to my contribution to this year's Michael Kuhnel Dev Vela Per Room at FOSSTEM.  Thanks a lot to Martin Decchi and Sebastian Zumpf for organizing this year's Dev Per  Room.  So, it's a pleasure to be here.  So, my name is Norman Feske.  I'm from the company GenoDepps, the developer behind the GenoOS framework.  And this talk will be about the last year's journey to bring together the GenoOS framework  and the Pinephone.  The talk will be structured in three major sections.  The first section will be about the underlying motivation of this work.  So, why have we even started doing this?  The second part will be a bit like a picture story of what happened in the last year.  So, I can't go into too many technical details, but I will give you some insights into the  whole development experience.  And finally, I will give you a brief demonstration of how GenoOS on the Pinephone looks right  now.  And finally, I will close the talk with an outlook of what to expect in 2022.  So, when speaking about the motivation of this work, I have to really go back a bit  to a kind of root concern of mine, which is basically a struggle that is getting ever  stronger, I think, between really powerful, dominating corporations and the civil society.  And the smartphones and the smartphone industry is, I think, one of the most impressive expressions  of this power struggle.  So let's take a closer look.  So what are the motives behind corporations in general?  So don't get me wrong, I'm an anti-corporate.  I can understand what is how this works, but there is still some kind of problem arising  from this.  It's natural that companies seek profits, so I'm also running a company, so I know  what this is about.  So you want to be profitable, and there's also a desire for growth.  It's natural for companies.  The growth aspect is actually much filled by investors, for the most part, who demand  growing revenue to have their assets increase their values.  So what to do about it, of course, one way is to increase the customer base and the other  way is you also have to keep the existing customers paying.  It's clear.  And whenever possible, raise the margins.  That's basically a cradle.  And what to do to keep the existing customers paying?  It's called customer retention.  So one way to do this is to leverage platform effects.  So let's say if everyone is on eBay, then all sellers and buyers are going to eBay.  So that's basically one thing that big platform companies strive for.  Another one is to create artificial dependencies, so that customers have a really hard time  leading the platform, and another strategy is to increase or introduce new complexity  and then offer the aid to make the suffering of the customers less.  So the basic, it comes down to making your customers addicted to you, to your products,  because addicts are the best customers.  And to make this even more efficient, it's always good to have as much information as  possible about the customers, the market, the competitors, and so on.  So there's a corporate motive to seek holistic knowledge without any bounds.  And when it comes to smartphones, it's really easy to see that people are really some kind  of addicted to smartphones.  Actually smartphones play an ever more important part of our lives.  But smartphones are a need of constant attention by the platform companies, or I would call  it medication, because there's the sole story about the security.  You have to keep your device updated.  You have to keep it healthy.  So you have to subscribe to some kind of service from a platform vendor to get new system updates.  You have to use the platform provider's competence to save you from bad behaving applications.  So there's this whole curation of apps.  And you also expect the platform provider to entertain you a bit like following the latest  fashion.  So there's a constant stream of new supplies of kind of medication.  And today's situation to corporations really dominate this whole business.  So what about me as a member of the society?  For a long time I have really not used a smartphone, and I'm still not a smartphone user, but this  is not a long term sustainable strategy.  So I want to participate in digital society, of course.  So for example, I want to use a smartphone to look for the timetables for trains, or  I want to use a COVID tracking application or things like that.  So I'm not opposed to any kind of convenience that a smartphone provides.  So I want to actually enjoy this utility value.  But at the same time, I value my digital autonomy a lot.  So I don't want to subordinate myself to corporate interests.  What this breaks down into is that I don't want to have any changes on my devices without  my consent.  So I don't want to have questions like, do you want to install the update today or tomorrow?  That's not a question I want to answer.  I want to be in control of the device.  I also want to be treated like a human being.  So I don't want to be exploited.  Like my attention should be mine.  I should not be forced to look at advertisements.  I don't want to be tracked.  I don't want to data mind or anything like that.  Finally, I want to keep my communications private by default, unless I decide otherwise.  And I want to keep my personal data for me.  And another aspect is that I'm always looking for sustainable paths in my way in my life.  So in one way, that's the environmental footprint I leave.  And the other way is that I want to keep learned skills usable.  So if I learn how to operate a device, I don't want to learn it again in the next years.  So there's of course a lot of conflicts of interests between those two goals.  So first, I think that this whole trend towards subscription-based business models, be it  cloud services or this whole security update story, is really a taxation of digital life.  And people are slowly getting used to it, and they just transfer money over to corporations  in a periodic way.  At the same time, data gets more and more centralized into kind of the silos controlled  by big companies.  And those are the same companies who basically look through this data and make out the patterns,  analyze this data, or even give this data to third parties without the consent of the  end user.  So the corporations have been extremely dominant and powerful in these areas.  So and as another kind of aspect to it, because of the whole consumer cycle, that the pressure  to always release new electronic products and to have customers buy new versions of  the devices, a lot of electronic ways is generated.  So these are all political problems.  And ultimately, the micro-cronodevroom is not the right place to solve them.  That's clear.  But on the other hand, we as technologists, we can at least give politicians some kind  of arguments that there may be alternatives pass forward.  And this is the whole story about where my motivation comes from.  It's not a kind of spleen that I only have for myself.  There are a few others who share similar sentiments.  So one prominent example is the precursor project by Bunny.  It's kind of extreme approach to a mobile phone that takes open hardware and open software  to an extreme.  So the hardware is based on a custom SoC built in an FPGA and the software is completely  developed from scratch.  The device is deliberately a deviation from smartphones.  It's more comparable to a feature phone, which kind of has a deliberate decisions of these  developers.  But what about smartphones?  When looking at smartphones, one company really comes to their attention, which is the Pine  64 company that produces the Pine phone.  And this Pine phone is marketed as an open source friendly phone, catering to the open  source developer community, especially the Linux community.  So the device supports the mainline kernel.  There are diverse distributions.  The SoC is a bit old, but it's well understood and it's quite well documented actually.  And the nicest thing is that it's readily available and quite affordable.  So it's a good device for tinkering basically.  So that's really attractive.  But open source is not enough.  So even if we say, ah, we use a Linux operating system on top of this phone, isn't this all  good?  No, it's not because the complexity of this whole software and hardware combination defeats  autonomy.  So still when using a Linux system on such a phone, you make yourself dependent on this  distribution and you have to be faithful in this software stack that is just incomprehensible  complex.  So we notice on Linux, for example, I'm using Linux for decades now.  And whenever I update my Linux distribution, I think of, ah, hopefully nothing changes  too much.  And so there is a lot of phase involved and that's something we cannot overcome really  with such complex software stacks.  And finally, there is also no queue inside for this whole security update.  Sorry.  So this is something we have just have to accept.  So of course, when looking at a G node, this is something that we at least promise to change.  So when structuring the system around the idea of the principle of least privilege and  sandboxing all tiny operating system and application functionality into small sandboxes, then this  whole situation becomes much easier.  There is no need to create applications or there's also much less need to keep the system  medicated all the time.  So it's more comparable to kind of cure than the relieving of symptoms.  So that I think can be a huge contribution when combined with smartphones.  And so I made it my mission to combine G node with the pine phone in the last year.  So my aspiration is really to have a replacement for a feature phone, but also so basically  featuring telephony messaging, but also doing being capable of using a web browser and encrypt  doing encrypted communication and crypto storage.  And also what's important to me is a half a decent battery life.  So currently I'm using a Nokia phone, an old Nokia phone, which has a kind of weak of battery  life, which is really nice.  And I want to have this also in the future.  I don't want to address any kind of entertainment or comfort functions that's currently out  of scope.  So how was this whole process about?  So how did I start it and what looked at it at the different times?  So when starting such an ambition, we first have to look into the kind of the way of how  the operating system boots on a platform.  So when the system is powered up, the bootloader takes over control, which is U-boot in our  case or in the case of the pine phone, it's a default bootloader.  And then this bootloader boots the first F image, which is basically a program that  runs in physical memory.  It's really called Bootstrap.  And then from there on, this bootstrap program bootstrap to kernel and virtual memory and  so on and so on.  So the first thing is really jumping from U-boot into custom piece of program that gives us  any kind of life sign.  And so this is basically the first small challenge to come up with a small program that can be  started directly from U-boot and gives us some characters on the zero line.  So this is how it looks like.  There are a few lines of C code, very simple, directly poking memory map dredges.  Here for outputting some characters and then a small kind of bunch of instructions to compile  the code into an object file loaded that can be loaded directly into the device memory.  And you see then the results and this can make one really happy when this happens, because  now we have passed the control to our own code.  So the next thing that we aspire to do is to port the kernel, the microkernel.  And here the all-winner SOC of the pine phone is really nice to us because it consists of  components that are readily supported by the existing base HW kernel of the Geno2S framework.  So it's a pretty aged by now 64-bit ARM SOC.  It uses the standard ARM GIG version 2 interrupt controller, generic timer infrastructure, very  simple UART interface and of course a custom memory layout that needs to be configured.  But all in all it comes down to basically mirroring the platform support for an existing  SOC, so for example the IMX8 and adjusting the files for the pine phone, like picking  the right interrupt controller and setting up the physical memory layout.  But this basically takes I would say a week or so, this is not a big challenge.  But the biggest challenges come ahead of us, so the next small exercise to get the test  met with the hardware is to access some kind of device hardware.  So the first tempting thing to do is to run some kind of GPIO controls on the chip, so  to toggle some pin state or to sense some pin state.  And so for this small test program can be written that uses genotes, basic services  like IQ and MMIO to access memory map registers and receive interrupts.  And this is really fun because this draws the connection between the physical world  like we have here, a pin that goes into the SOC, a physical thing that is basically a  wire and it goes into the SOC, then it goes through a bunch of logic and then there is  some device inside the SOC that maps this to a bus that's on the system bus, which then  can be accessed by the software here.  And the same thing for the interrupts, so this is interesting how this physical pin  is basically wired up to the interrupt controller and then ending up in the micro chronos IRQ  handler to the user application.  So the nice thing about this step is that it really lets you see the physical effects  of some piece of software, which is quite nice.  So now the next thing when having this basic test running was to bring a bit order in this  whole situation.  So instead of allowing this program to access all the hardware, we introduced a platform  driver that basically assigns a certain specific memory map IO ranges and interrupt numbers  to this specific program.  So there is a kind of access control enforced by the platform driver.  And as another step, we go further, we put this or change this program into a proper  driver with a driver interface that allows other programs to control individual pins.  So here what we see is the strength of a microkernel based system.  We have a cascade of authorities that can limit the reach of the programs.  So here at the bottom, we have the kernel and the core component of GNOT with ultimate  authority over the whole platform.  Then in the next step, we have the platform driver which has handed over all the memory  map IO resources and interrupts.  So it has authority over all devices.  But then it gives only a part of this authority over to this GPIO driver over here.  And this again can assign a part of its own authority to a simple program.  And so the actual program like this LED Pulse program here can access only a one specific  pin in a specific mode, which really comes down to the principle of least privilege.  The experimentation setup looks like this.  So you can have some wires here, some resistors and an LED and can play with it.  And this is all a lot of fun.  And by the way, this board what you see here is this Pine A64 LTS board, which is mirror  basically the Pine phone hardware and is also available at the Pine 64 store.  So the next step up is the problem of dealing with real devices, not just filling with some  GPIO pins, but some real drivers.  So when looking at real hardware, real drivers, you see that on ARM as a C's, the situation  is much more chaotic and less regular than on PC hardware, which basically is organized  around the PCI bus.  On ARM as a C's, it's more chaotic and you have to, you are faced with a lot of complex  interplays between device details like the power regulators, clocks, reset lines, a variety  of buses and many, many quirky details.  And added to that, there are certain pin functions that can be selected for the SSE, which are  at another level of obscurity, I would say, but it's of course, it's a nice feature of  these chips, but it doesn't make the situation any easier.  And on top of that, the documentation is often not available or quite sparse.  So the only reliable reference to working systems is really the Linux kernel, because  the SSE vendors are usually the ones who write drivers directly for the Linux kernel.  And so we are now faced with the situation where we can look at the device trees that  are shipped with the Linux kernels as some kind of hardware documentation.  And the cool thing about this is that this documentation is really the ground truth,  because it's actually kind of executed.  So if there was a mistake in the device tree, then this Linux kernel would not work on this  hardware, so that's quite nice.  It gives us a lot of information about the hardware.  We also found that because of this whole interplay between the different devices and the clocks  and resets and so on, that the porting of the drivers is much more feasible than the  developing of the drivers from scratch.  So we concentrated completely on this idea of porting complex device drivers from Linux  to genote.  So when starting this kind of idea, it's useful to start with reasonably small example, like  an Ethernet driver, and we will come to bigger or more complex devices later.  So when looking at Ethernet and looking at the device tree for the Pine AS64 board, yeah,  it looks a bit like this.  This is a graph visualization of the device tree.  It's basically incomprehensible.  So to make some sense out of this, we came up with some custom tooling that processes  this device tree files, and where we can say we are interested in a specific part of the  hardware, in this case the Ethernet controller, and want to only retain things that are related  to this part of the hardware.  And here the tool spits out this smaller device tree which is in itself consistent, but consists  only of the parts that are relevant for networking.  And this becomes suddenly much more clear and can guide our way for porting code from  Linux.  Speaking about porting code from Linux, one intermediate step I always did is basically  first trying to build a custom Linux kernel that is as bare bones as possible and only  drives the hardware that I am after.  So in the current case, a Linux kernel that drives the network but doesn't know a thing  else really.  The usual process is to start with a tiny config of Linux kernel, which is basically  a Linux kernel that doesn't work really.  So it compiles but it doesn't run, and then try to find the configuration values for the  Linux kernel that produce a kernel that performs a bit of network functionality, like issuing  a DHCP request.  And to aid this process, we can look into the device tree, find information there about  certain compilation units.  From this compilation units, we can learn config options that are conditions for this  compilation unit, so we can add these configuration options.  We can also let our intuition guide us.  So for example, it is logical that the internet controller also needs a food driver, so things  like that.  And also of course some kind of rational thinking.  But in the end, there is a gap here in the middle where we can't really guess what kernel  configurations options are needed.  And for this, I came up with some kind of sledgehammer approach, basically bisecting  the configurations of Linux to try out the minimal set of configurations.  So each of these config options you see here require several kernel compiles and boots  of the kernel on the platform.  But it took maybe a day or maybe even two days to find out these options.  It's quite a boring task, but it's terminating the process.  It's terminating.  And it leads us to these kind of minimalism, which is really nice.  Because in the end, when we have this kind of small set of kernel options, we have a  really tight Linux kernel that we can work with.  And then it's time to transplant code from Linux to the G-node system, put it into a  component.  And here, we came up with a new version of Linux device driver environment, which allows  us to use unmodified Linux kernel code here and combine this with a small kind of emulation  environment of certain Linux kernel mechanisms like memory subsystem and in-it call handling  and things like that.  Then a small API layer for certain G-node interfaces that map the C++ interface of G-node  to C interfaces.  And then finally, we have the G-node API.  On top, we can use the services then of the driver.  And on the bottom, we can access the device.  And so this is a very rigid scheme.  So for example, we keep really C++ and C galvanically separated.  So next thing is, so basically to wrap this up, once I got the network driver working,  I switched my attention to the PinePhone as a development platform because that's my  actual goal.  And so I looked about the process, how can I work with the PinePhone?  The cool thing is, it can boot directly from the SD card, so you cannot really break anything  or break anything.  You can always swap out an SD card and start from new, which is really nice.  It's also cool that you can basically repurpose the audio jack to become a zero line, try  just flipping as far as small switch, and there is an accessible reset button, which  is really cool.  For the workflow, some things should be considered.  So for example, SD card juggling is not really convenient.  And you look at these kind of Linux bisecting experiments, you need to boot the system like  hundreds of times, and juggling an SD card each time is not viable.  So other strategies are needed, and we can of course also not use Ethernet, so TFTP is  out of question.  So I looked at UBoat's fast boot support, also with the help of an old friend, Ivan  Loskutov, who give me some really, really valuable hints.  And so I could automate much of the workflow and also combine this with some custom automation  tools in Genotes Toolchain.  And as a small detail, there are these tiny things.  So for example, you have this reset button in the back of the phone here, this is a small  hole.  So you are supposed to fiddle with a small toothpick or so in this hole to reset the  phone.  But when developing, for example, a touchscreen driver, you have to split to flip the phone  for each test, which is really not convenient.  So I came up with this small life hack here.  So I had a small screw laying around, and by putting the screw inside the hole and flipping  off the phone, the whole phone becomes a big reset button, which is really nice and extremely  satisfying.  So these are the small things that make life so much better.  Yeah, now looking at the display driver, you see again this kind of part of the device  tree that is concerned with the display.  You see that it is a lot more complicated than the Ethernet part.  So there are lots of questions to answer.  So the process of cutting down Linux is more or less a mechanical work.  It came really down to this small set of configuration options here.  So this is actually enough to bring up this crippled version of the Linux kernel, which  basically just presents us hooks and then to crashes, maybe.  But it doesn't matter because it has successfully initialized the frame buffer, and that's what  we wanted.  So that's really nice.  And so we can go on and select the driver sources that we find in the object files and  look at them, consider them to include into our component, then compile and link the result.  And if you see any unresolved symbols, we can generate dummy functions for these symbols  automatically using custom tools that we developed over the last year.  And yeah, and when such a function is called, we look closely to the called function supplement  custom emulation code and try it again.  And this is basically an iterative process that basically eventually leads us to this  result.  So a working graphics driver, which is extremely satisfying.  So don't get me wrong, it's not all roses.  It basically takes sometimes really long time to come up with this, but there is a very  structured way of doing this.  So now we have this frame buffer driver running on the platform.  And when we can really see all the kind of devices that are accessed by this monolithic  frame buffer driver, and this is really staggering.  It also expresses how big intertwined all the different driver parts of this arm SOCs  are.  So the problem arises that when we try to add another driver, so for example, besides  the frame buffer driver, we want to also have a touchscreen driver.  So until suddenly we see a big conflicts, so that the same drivers want to access the  same hardware resources.  And this is of course not possible or not getting any useful results.  So now we have to start the process of basically cutting those dependencies here and basically  either adding emulation code in here and the drivers or putting in intermediate components  that basically reconciled the access of those devices.  So this is how it looks like in the end.  So basically everything that's related to clocks, power and reset is basically put into  a different driver component and both drivers access this higher level driver component  and all things that are related to general purpose IO pins are basically going through  this component over here.  And now we have nicely reconciled those both drivers on the platform.  So this is really the whole micro-colonial idea here.  We now know exactly which parts of the SOCs are accessed by which driver and so we can  also assess the reach of the driver on the system, that's really intuitive now.  So now that I have covered these kind of small story about how the process went, let me give  you a short demonstration.  So as you may have guessed, I'm actually using genotes right now.  So this is basically a scope-based system here.  So this is my site program here and here I have a normal Linux, an Xubuntu Linux running  inside a virtual box and the whole system runs on top of the Nova hypervisor.  And in this terminal up here, I have connected this to the ZLine of the pine phone and over  here I have a build directory for genotor for ARM V8.  And now to give you the look on the pine phone, I will basically start a component to look  at our webcam.  So I will just deploy a small program here that basically captures the picture from the  webcam and displays this in a window.  And you can see here that this window appears here.  So we can see the phone.  So yes, some dust.  Okay.  So now I can issue the command to...  So the phone is actually already switched on.  So you see the red cable here.  So the phone is powered.  It's currently stuck in the U-Boot loader and it's waiting for a fast boot command.  So here I can give it the command to basically run this Sculpt test run script.  That's basically part of the genot tooling, targeting the base HW kernel, the board pine  phone and also direct the log output to the core component of genot.  So let's give it a try.  So now there's not much to build.  So we just integrate the image.  And in this case, the image contains also some kind of pre-loaded software.  So it's a bit larger than normal.  So this takes a few seconds until the image is generated, but not too long after.  You should see here that the system is booting up.  And on the webcam, you will briefly see...  Here it is.  You can see that the user interface has been started.  So you see now the same Sculpt OS that I'm running on this machine.  So basically when I go back here, you see this same kind of system that I'm having on  my machine here.  The same system basically runs now on the pine phone, except for some details like no  persistence storage.  But for example, I can basically click on this or touch on these different user interface  elements and user interface response to this.  Also for example, when I touch the settings bar, you see you can basically change also  some user interface settings.  And one specific interesting thing is that I can deploy some scenario from memory.  So I can use the RAMFS.  So sorry, you cannot really see it.  But I can tell you that now the system is deploying a genotes subsystem as a deployment.  And here you see that some components have been loaded.  I can switch to this kind of desktop by pressing it to the side here.  And you see here there is a small keyboard here and a terminal over here.  So I can basically...  And there's actually a window manager running.  So this is of course still inherited from the desktop version of Sculpt.  And I can even drag these windows around and use this small keyboard.  It's hard to see in the webcam.  But I can basically type in a small command.  For example, I can type in something like LS and return.  And you see that this Linux...  Not Linux, but it's a native genote-based UNIX environment.  It's basically presenting some results.  And I even can, in principle, also use things like Vim to edit all kinds of files on the  system.  And so, for example, also access the configuration file system of the Sculpt OS.  So basically this gives me complete control over the device.  Let me see.  Q.  Q.  Okay.  There's also a smaller demo I can show you.  That's basically just rotating...  Oh, maybe I haven't...  Yeah, I failed to reach it here.  I still have to train my fingers to type on the touch screen.  So here a small program is coming up that basically...  You may recognize this from previous talks.  That's basically a small software rendering demo running now directly also on the Sculpt  OS.  And the nice thing here is that all the underlying infrastructure, like the package management  concept, the deployment concept, the configuration concept, etc.  It's all the same things, the same components as we use on the normal system on PCs.  Okay.  So that's basically what I can show you right now.  So now to close the talk, let's give some ideas what's next.  So the vision for this year is to have a video chat scenario running on the pine phone.  So I want to chat with my family, for example, using this device, using G-Node on Sculpt.  And there are of course a lot of challenges in the way.  So these are just an animation of things we have to work on, which is at the same time  exciting, but also a bit frightening, of course.  But we are really driven towards this goal.  If you want to follow the progress of this ambition, you are invited to visit the G-Node  website, which is basically a kind of blog for various genome developers.  And I am publishing an article series called Pine Phone, where I report on the progress  that I make.  And in the end, this article series will be integrated into a large document that's called  the G-Node porting guide or G-Node platforms document, which will give a kind of guidance  to future developers who want to bring G-Node to other SOCs.  So for example, if any one of you is interested in the new Pine Phone Pro that is based on  the Rockchip SOC, then this documentation is probably the best pathway to develop this  kind of support.  So that's already the first version of this document online, but it will be updated in  May with the new findings.  Okay, thank you very much for your attention.  And that is the end of my talk.  Thank you.  So let's start with some questions.  There are some questions in the chat.  You or the others have partially answered them, but maybe we can just repeat them for  the stream.  So there was one question about the base HW.  So could you just tell us what that actually is?  Yeah, sure.  So yeah, first thank you for organizing the deaf room together with Sebastian this year.  So yeah, yeah, about the strange name of this kernel.  So it's really the result of this naming scheme of G-Node.  So G-Node, the G-Node OS framework supports quite a few different kernels.  So you can use the G-Node OS framework on top of traditional four micro kernels or also  on the Nova kernel or the SEL4 kernel or the Fiasco OC kernel and also on the Linux kernel.  And at one time, like seven years ago, we had the idea to come up with a custom micro  kernel that is actually much simpler than compared with the traditional kernels.  So it has a kind of different software architecture that is glued more closely to G-Node.  And by doing this, we expected to reduce the complexity of the base system even further.  So we already had a pretty good or a pretty tight base system with the existing kernels,  but we saw the potential that we could reduce it further.  And so we came up with the base HW kernel.  And the notion is that now G-Node runs on the real hardware, not with the kernel underneath,  but the G-Node's low-level system is touching the CPU hardware directly.  And so it's called base minus Linux or base minus Nova, but base minus HW, which means  it accesses the hardware directly.  But it's still a micro kernel.  And in practical terms, it's your native micro kernel.  Yes.  It really fits your architecture perfectly.  Exactly.  Yes.  Okay.  So it's a small question, maybe just a clarification.  So the demo you have shown, that was really running just on the phone.  There was nothing running on the desktop machine.  Yeah.  So maybe it is the demo where I executed first G-Node on the machine, on the laptop, and  then on the phone.  Well, it's a bit misguiding, but yeah, the phone has a complete separate system running.  And it's loaded as a single image through the fast boot channel to the phone and then  executed standalone.  So it's running autonomously on the phone.  Yes.  Wonderful.  Another quick question.  Do you plan to support the PinePhone Pro as well in the future?  So not immediately.  So the idea, so I have to come back a bit.  One idea behind this work is that we will go, or the idea was to go through the process  of plotting all these difficult technical challenges, but not only doing this, but also  implementing all these steps in very much detail.  So the idea was to, at the end of the whole process, there should be something like a  book, I would say it will be like 300 pages or so, that explains in detail how this kind  of process works.  And so I hope, that's at least in my hope, that others will find this kind of idea inspiring  that now someone else can also take this book and take a new hardware and apply the steps  of this book to get G-Node running on this new hardware.  So that's my goal to cultivate some kind of community around this idea.  And so I put a lot of work into this documentation.  So I would say more work was spent on the writing the documentation than on the actual  technical work.  And so I think that it would excite us very much if someone else would step up and take  over this idea to bring G-Node on the Rockchip, for example, which is the chip used in the  Pinephone Pro, and we would give assistance, of course, but the ownership of this project  would be somewhere else.  But anyway, if there's some commercial interest in that and someone would approach us, then  of course we would be up to it to do this.  Another point is, I think that the Pinephone is appealing because it's a limited platform.  It's universally known to be not really strong, it's a bit dated.  And if you look at the Linux systems on top of this platform, they do not perform really  so well.  So it's usable, don't get me wrong.  I admire what's happening in this community, but it's not comparable to the user experience  that we see on commercial phones or on consumer devices.  And I think if we managed to really rock the phone with G-Node to bring a really nice user  experience to the phone, it also would nicely allow people to compare the beauty of microkernel-based  systems and the performance of our system to Linux to basically despell the myths that  microkernel systems are slow.  So if it performs better on the phone than Linux, then I think that would be quite exciting.  But I cannot promise this, but that's my goal.  Yes, it definitely sounds very intriguing, I should say.  And going back to the UI, there was a question in the chat as well in that direction.  So clearly the desktop UI is really not a good fit for this touch screen, small touch  screen.  So do you have any ideas or plans towards having really a smartphone native, you know,  touch screen native UI?  Yeah, so there are several ideas.  I think it will be two-staged.  So there is a one-stage where we have some basic interaction that gives the user control  over the phone, but not much convenience.  So that's basically what this user interface that you see right now presents.  It's very small in terms of bytes.  So the image is very tight and very small.  It puts up quite quickly.  And then there will be a second layer on top of that where everything is basically up to  the different use cases.  And for example, I think that it would be really nice to bring QT-based applications  to this phone on top of G-Node.  So for example, there is the SailFush OS that uses QT for applications.  And so the applications on this phone on this OS are really native applications using QML  and all the kind of beauty of this, what you expect.  And there's nothing that's good to speak against leveraging these kind of frameworks like QT-QML  on top of G-Node.  And that's what you would then present to the end user, of course.  But in the intermediate step, of course, we need to have some nice ways to interact with  the phone as a developer.  And so here are our kind of intermediate component like this touch screen keyboard comes to play.  I think nobody really will enjoy it this, but it will have its purpose for our development  and for hacking with the device, playing with the power management with the modem and all  these kind of things.  OK.  There are several more questions, but sadly, the time is running out.  So to prevent your answer being cut off, I would like to thank you again for this amazing  talk.  We are definitely looking forward to further development in this area and in G-Node in  general.  I encourage our attendees to ask you more questions in the chat.  And thanks once again.  See you.  Bye-bye.  Thank you.
nfeske_0_143.png nfeske_144_263.png nfeske_264_1067.png nfeske_1068_2327.png nfeske_2328_2603.png nfeske_2604_2951.png nfeske_2952_6287.png nfeske_6288_8039.png nfeske_8040_11003.png nfeske_11004_14015.png nfeske_14016_19043.png nfeske_19044_21863.png nfeske_21864_22691.png nfeske_22692_25367.png nfeske_25368_29027.png nfeske_29028_33455.png nfeske_33456_34667.png nfeske_34668_34847.png nfeske_34848_39911.png nfeske_39912_42659.png nfeske_42660_44063.png nfeske_44064_45383.png nfeske_45384_46619.png nfeske_46620_47495.png nfeske_47496_49007.png nfeske_49008_52607.png nfeske_52608_54371.png nfeske_54372_57587.png nfeske_57588_58655.png nfeske_58656_59171.png nfeske_59172_60263.png nfeske_60264_60971.png nfeske_60972_61271.png nfeske_61272_61367.png nfeske_61368_62651.png nfeske_62652_63227.png nfeske_63228_63371.png nfeske_63372_63707.png nfeske_63708_63887.png nfeske_63888_64163.png nfeske_64164_64811.png nfeske_64812_64991.png nfeske_64992_67247.png nfeske_67248_68699.png nfeske_68700_68903.png nfeske_68904_69011.png nfeske_69012_69347.png nfeske_69348_69479.png nfeske_69480_71243.png nfeske_71244_71495.png nfeske_71496_71627.png nfeske_71628_72275.png nfeske_72276_72335.png nfeske_72336_72457.png
Welcome to my contribution to this year's Michael Kuhnel Dev Vela Per Room at FOSSTEM. Thanks a lot to Martin Decchi and Sebastian Zumpf for organizing this year's Dev Per Room. So, it's a pleasure to be here. So, my name is Norman Feske. I'm from the company GenoDepps, the developer behind the GenoOS framework. And this talk will be about the last year's journey to bring together the GenoOS framework and the Pinephone. The talk will be structured in three major sections. The first section will be about the underlying motivation of this work. So, why have we even started doing this? The second part will be a bit like a picture story of what happened in the last year. So, I can't go into too many technical details, but I will give you some insights into the whole development experience. And finally, I will give you a brief demonstration of how GenoOS on the Pinephone looks right now. And finally, I will close the talk with an outlook of what to expect in 2022. So, when speaking about the motivation of this work, I have to really go back a bit to a kind of root concern of mine, which is basically a struggle that is getting ever stronger, I think, between really powerful, dominating corporations and the civil society. And the smartphones and the smartphone industry is, I think, one of the most impressive expressions of this power struggle. So let's take a closer look. So what are the motives behind corporations in general? So don't get me wrong, I'm an anti-corporate. I can understand what is how this works, but there is still some kind of problem arising from this. It's natural that companies seek profits, so I'm also running a company, so I know what this is about. So you want to be profitable, and there's also a desire for growth. It's natural for companies. The growth aspect is actually much filled by investors, for the most part, who demand growing revenue to have their assets increase their values. So what to do about it, of course, one way is to increase the customer base and the other way is you also have to keep the existing customers paying. It's clear. And whenever possible, raise the margins. That's basically a cradle. And what to do to keep the existing customers paying? It's called customer retention. So one way to do this is to leverage platform effects. So let's say if everyone is on eBay, then all sellers and buyers are going to eBay. So that's basically one thing that big platform companies strive for. Another one is to create artificial dependencies, so that customers have a really hard time leading the platform, and another strategy is to increase or introduce new complexity and then offer the aid to make the suffering of the customers less. So the basic, it comes down to making your customers addicted to you, to your products, because addicts are the best customers. And to make this even more efficient, it's always good to have as much information as possible about the customers, the market, the competitors, and so on. So there's a corporate motive to seek holistic knowledge without any bounds. And when it comes to smartphones, it's really easy to see that people are really some kind of addicted to smartphones. Actually smartphones play an ever more important part of our lives. But smartphones are a need of constant attention by the platform companies, or I would call it medication, because there's the sole story about the security. You have to keep your device updated. You have to keep it healthy. So you have to subscribe to some kind of service from a platform vendor to get new system updates. You have to use the platform provider's competence to save you from bad behaving applications. So there's this whole curation of apps. And you also expect the platform provider to entertain you a bit like following the latest fashion. So there's a constant stream of new supplies of kind of medication. And today's situation to corporations really dominate this whole business. So what about me as a member of the society? For a long time I have really not used a smartphone, and I'm still not a smartphone user, but this is not a long term sustainable strategy. So I want to participate in digital society, of course. So for example, I want to use a smartphone to look for the timetables for trains, or I want to use a COVID tracking application or things like that. So I'm not opposed to any kind of convenience that a smartphone provides. So I want to actually enjoy this utility value. But at the same time, I value my digital autonomy a lot. So I don't want to subordinate myself to corporate interests. What this breaks down into is that I don't want to have any changes on my devices without my consent. So I don't want to have questions like, do you want to install the update today or tomorrow? That's not a question I want to answer. I want to be in control of the device. I also want to be treated like a human being. So I don't want to be exploited. Like my attention should be mine. I should not be forced to look at advertisements. I don't want to be tracked. I don't want to data mind or anything like that. Finally, I want to keep my communications private by default, unless I decide otherwise. And I want to keep my personal data for me. And another aspect is that I'm always looking for sustainable paths in my way in my life. So in one way, that's the environmental footprint I leave. And the other way is that I want to keep learned skills usable. So if I learn how to operate a device, I don't want to learn it again in the next years. So there's of course a lot of conflicts of interests between those two goals. So first, I think that this whole trend towards subscription-based business models, be it cloud services or this whole security update story, is really a taxation of digital life. And people are slowly getting used to it, and they just transfer money over to corporations in a periodic way. At the same time, data gets more and more centralized into kind of the silos controlled by big companies. And those are the same companies who basically look through this data and make out the patterns, analyze this data, or even give this data to third parties without the consent of the end user. So the corporations have been extremely dominant and powerful in these areas. So and as another kind of aspect to it, because of the whole consumer cycle, that the pressure to always release new electronic products and to have customers buy new versions of the devices, a lot of electronic ways is generated. So these are all political problems. And ultimately, the micro-cronodevroom is not the right place to solve them. That's clear. But on the other hand, we as technologists, we can at least give politicians some kind of arguments that there may be alternatives pass forward. And this is the whole story about where my motivation comes from. It's not a kind of spleen that I only have for myself. There are a few others who share similar sentiments. So one prominent example is the precursor project by Bunny. It's kind of extreme approach to a mobile phone that takes open hardware and open software to an extreme. So the hardware is based on a custom SoC built in an FPGA and the software is completely developed from scratch. The device is deliberately a deviation from smartphones. It's more comparable to a feature phone, which kind of has a deliberate decisions of these developers. But what about smartphones? When looking at smartphones, one company really comes to their attention, which is the Pine 64 company that produces the Pine phone. And this Pine phone is marketed as an open source friendly phone, catering to the open source developer community, especially the Linux community. So the device supports the mainline kernel. There are diverse distributions. The SoC is a bit old, but it's well understood and it's quite well documented actually. And the nicest thing is that it's readily available and quite affordable. So it's a good device for tinkering basically. So that's really attractive. But open source is not enough. So even if we say, ah, we use a Linux operating system on top of this phone, isn't this all good? No, it's not because the complexity of this whole software and hardware combination defeats autonomy. So still when using a Linux system on such a phone, you make yourself dependent on this distribution and you have to be faithful in this software stack that is just incomprehensible complex. So we notice on Linux, for example, I'm using Linux for decades now. And whenever I update my Linux distribution, I think of, ah, hopefully nothing changes too much. And so there is a lot of phase involved and that's something we cannot overcome really with such complex software stacks. And finally, there is also no queue inside for this whole security update. Sorry. So this is something we have just have to accept. So of course, when looking at a G node, this is something that we at least promise to change. So when structuring the system around the idea of the principle of least privilege and sandboxing all tiny operating system and application functionality into small sandboxes, then this whole situation becomes much easier. There is no need to create applications or there's also much less need to keep the system medicated all the time. So it's more comparable to kind of cure than the relieving of symptoms. So that I think can be a huge contribution when combined with smartphones. And so I made it my mission to combine G node with the pine phone in the last year. So my aspiration is really to have a replacement for a feature phone, but also so basically featuring telephony messaging, but also doing being capable of using a web browser and encrypt doing encrypted communication and crypto storage. And also what's important to me is a half a decent battery life. So currently I'm using a Nokia phone, an old Nokia phone, which has a kind of weak of battery life, which is really nice. And I want to have this also in the future. I don't want to address any kind of entertainment or comfort functions that's currently out of scope. So how was this whole process about? So how did I start it and what looked at it at the different times? So when starting such an ambition, we first have to look into the kind of the way of how the operating system boots on a platform. So when the system is powered up, the bootloader takes over control, which is U-boot in our case or in the case of the pine phone, it's a default bootloader. And then this bootloader boots the first F image, which is basically a program that runs in physical memory. It's really called Bootstrap. And then from there on, this bootstrap program bootstrap to kernel and virtual memory and so on and so on. So the first thing is really jumping from U-boot into custom piece of program that gives us any kind of life sign. And so this is basically the first small challenge to come up with a small program that can be started directly from U-boot and gives us some characters on the zero line. So this is how it looks like. There are a few lines of C code, very simple, directly poking memory map dredges. Here for outputting some characters and then a small kind of bunch of instructions to compile the code into an object file loaded that can be loaded directly into the device memory. And you see then the results and this can make one really happy when this happens, because now we have passed the control to our own code. So the next thing that we aspire to do is to port the kernel, the microkernel. And here the all-winner SOC of the pine phone is really nice to us because it consists of components that are readily supported by the existing base HW kernel of the Geno2S framework. So it's a pretty aged by now 64-bit ARM SOC. It uses the standard ARM GIG version 2 interrupt controller, generic timer infrastructure, very simple UART interface and of course a custom memory layout that needs to be configured. But all in all it comes down to basically mirroring the platform support for an existing SOC, so for example the IMX8 and adjusting the files for the pine phone, like picking the right interrupt controller and setting up the physical memory layout. But this basically takes I would say a week or so, this is not a big challenge. But the biggest challenges come ahead of us, so the next small exercise to get the test met with the hardware is to access some kind of device hardware. So the first tempting thing to do is to run some kind of GPIO controls on the chip, so to toggle some pin state or to sense some pin state. And so for this small test program can be written that uses genotes, basic services like IQ and MMIO to access memory map registers and receive interrupts. And this is really fun because this draws the connection between the physical world like we have here, a pin that goes into the SOC, a physical thing that is basically a wire and it goes into the SOC, then it goes through a bunch of logic and then there is some device inside the SOC that maps this to a bus that's on the system bus, which then can be accessed by the software here. And the same thing for the interrupts, so this is interesting how this physical pin is basically wired up to the interrupt controller and then ending up in the micro chronos IRQ handler to the user application. So the nice thing about this step is that it really lets you see the physical effects of some piece of software, which is quite nice. So now the next thing when having this basic test running was to bring a bit order in this whole situation. So instead of allowing this program to access all the hardware, we introduced a platform driver that basically assigns a certain specific memory map IO ranges and interrupt numbers to this specific program. So there is a kind of access control enforced by the platform driver. And as another step, we go further, we put this or change this program into a proper driver with a driver interface that allows other programs to control individual pins. So here what we see is the strength of a microkernel based system. We have a cascade of authorities that can limit the reach of the programs. So here at the bottom, we have the kernel and the core component of GNOT with ultimate authority over the whole platform. Then in the next step, we have the platform driver which has handed over all the memory map IO resources and interrupts. So it has authority over all devices. But then it gives only a part of this authority over to this GPIO driver over here. And this again can assign a part of its own authority to a simple program. And so the actual program like this LED Pulse program here can access only a one specific pin in a specific mode, which really comes down to the principle of least privilege. The experimentation setup looks like this. So you can have some wires here, some resistors and an LED and can play with it. And this is all a lot of fun. And by the way, this board what you see here is this Pine A64 LTS board, which is mirror basically the Pine phone hardware and is also available at the Pine 64 store. So the next step up is the problem of dealing with real devices, not just filling with some GPIO pins, but some real drivers. So when looking at real hardware, real drivers, you see that on ARM as a C's, the situation is much more chaotic and less regular than on PC hardware, which basically is organized around the PCI bus. On ARM as a C's, it's more chaotic and you have to, you are faced with a lot of complex interplays between device details like the power regulators, clocks, reset lines, a variety of buses and many, many quirky details. And added to that, there are certain pin functions that can be selected for the SSE, which are at another level of obscurity, I would say, but it's of course, it's a nice feature of these chips, but it doesn't make the situation any easier. And on top of that, the documentation is often not available or quite sparse. So the only reliable reference to working systems is really the Linux kernel, because the SSE vendors are usually the ones who write drivers directly for the Linux kernel. And so we are now faced with the situation where we can look at the device trees that are shipped with the Linux kernels as some kind of hardware documentation. And the cool thing about this is that this documentation is really the ground truth, because it's actually kind of executed. So if there was a mistake in the device tree, then this Linux kernel would not work on this hardware, so that's quite nice. It gives us a lot of information about the hardware. We also found that because of this whole interplay between the different devices and the clocks and resets and so on, that the porting of the drivers is much more feasible than the developing of the drivers from scratch. So we concentrated completely on this idea of porting complex device drivers from Linux to genote. So when starting this kind of idea, it's useful to start with reasonably small example, like an Ethernet driver, and we will come to bigger or more complex devices later. So when looking at Ethernet and looking at the device tree for the Pine AS64 board, yeah, it looks a bit like this. This is a graph visualization of the device tree. It's basically incomprehensible. So to make some sense out of this, we came up with some custom tooling that processes this device tree files, and where we can say we are interested in a specific part of the hardware, in this case the Ethernet controller, and want to only retain things that are related to this part of the hardware. And here the tool spits out this smaller device tree which is in itself consistent, but consists only of the parts that are relevant for networking. And this becomes suddenly much more clear and can guide our way for porting code from Linux. Speaking about porting code from Linux, one intermediate step I always did is basically first trying to build a custom Linux kernel that is as bare bones as possible and only drives the hardware that I am after. So in the current case, a Linux kernel that drives the network but doesn't know a thing else really. The usual process is to start with a tiny config of Linux kernel, which is basically a Linux kernel that doesn't work really. So it compiles but it doesn't run, and then try to find the configuration values for the Linux kernel that produce a kernel that performs a bit of network functionality, like issuing a DHCP request. And to aid this process, we can look into the device tree, find information there about certain compilation units. From this compilation units, we can learn config options that are conditions for this compilation unit, so we can add these configuration options. We can also let our intuition guide us. So for example, it is logical that the internet controller also needs a food driver, so things like that. And also of course some kind of rational thinking. But in the end, there is a gap here in the middle where we can't really guess what kernel configurations options are needed. And for this, I came up with some kind of sledgehammer approach, basically bisecting the configurations of Linux to try out the minimal set of configurations. So each of these config options you see here require several kernel compiles and boots of the kernel on the platform. But it took maybe a day or maybe even two days to find out these options. It's quite a boring task, but it's terminating the process. It's terminating. And it leads us to these kind of minimalism, which is really nice. Because in the end, when we have this kind of small set of kernel options, we have a really tight Linux kernel that we can work with. And then it's time to transplant code from Linux to the G-node system, put it into a component. And here, we came up with a new version of Linux device driver environment, which allows us to use unmodified Linux kernel code here and combine this with a small kind of emulation environment of certain Linux kernel mechanisms like memory subsystem and in-it call handling and things like that. Then a small API layer for certain G-node interfaces that map the C++ interface of G-node to C interfaces. And then finally, we have the G-node API. On top, we can use the services then of the driver. And on the bottom, we can access the device. And so this is a very rigid scheme. So for example, we keep really C++ and C galvanically separated. So next thing is, so basically to wrap this up, once I got the network driver working, I switched my attention to the PinePhone as a development platform because that's my actual goal. And so I looked about the process, how can I work with the PinePhone? The cool thing is, it can boot directly from the SD card, so you cannot really break anything or break anything. You can always swap out an SD card and start from new, which is really nice. It's also cool that you can basically repurpose the audio jack to become a zero line, try just flipping as far as small switch, and there is an accessible reset button, which is really cool. For the workflow, some things should be considered. So for example, SD card juggling is not really convenient. And you look at these kind of Linux bisecting experiments, you need to boot the system like hundreds of times, and juggling an SD card each time is not viable. So other strategies are needed, and we can of course also not use Ethernet, so TFTP is out of question. So I looked at UBoat's fast boot support, also with the help of an old friend, Ivan Loskutov, who give me some really, really valuable hints. And so I could automate much of the workflow and also combine this with some custom automation tools in Genotes Toolchain. And as a small detail, there are these tiny things. So for example, you have this reset button in the back of the phone here, this is a small hole. So you are supposed to fiddle with a small toothpick or so in this hole to reset the phone. But when developing, for example, a touchscreen driver, you have to split to flip the phone for each test, which is really not convenient. So I came up with this small life hack here. So I had a small screw laying around, and by putting the screw inside the hole and flipping off the phone, the whole phone becomes a big reset button, which is really nice and extremely satisfying. So these are the small things that make life so much better. Yeah, now looking at the display driver, you see again this kind of part of the device tree that is concerned with the display. You see that it is a lot more complicated than the Ethernet part. So there are lots of questions to answer. So the process of cutting down Linux is more or less a mechanical work. It came really down to this small set of configuration options here. So this is actually enough to bring up this crippled version of the Linux kernel, which basically just presents us hooks and then to crashes, maybe. But it doesn't matter because it has successfully initialized the frame buffer, and that's what we wanted. So that's really nice. And so we can go on and select the driver sources that we find in the object files and look at them, consider them to include into our component, then compile and link the result. And if you see any unresolved symbols, we can generate dummy functions for these symbols automatically using custom tools that we developed over the last year. And yeah, and when such a function is called, we look closely to the called function supplement custom emulation code and try it again. And this is basically an iterative process that basically eventually leads us to this result. So a working graphics driver, which is extremely satisfying. So don't get me wrong, it's not all roses. It basically takes sometimes really long time to come up with this, but there is a very structured way of doing this. So now we have this frame buffer driver running on the platform. And when we can really see all the kind of devices that are accessed by this monolithic frame buffer driver, and this is really staggering. It also expresses how big intertwined all the different driver parts of this arm SOCs are. So the problem arises that when we try to add another driver, so for example, besides the frame buffer driver, we want to also have a touchscreen driver. So until suddenly we see a big conflicts, so that the same drivers want to access the same hardware resources. And this is of course not possible or not getting any useful results. So now we have to start the process of basically cutting those dependencies here and basically either adding emulation code in here and the drivers or putting in intermediate components that basically reconciled the access of those devices. So this is how it looks like in the end. So basically everything that's related to clocks, power and reset is basically put into a different driver component and both drivers access this higher level driver component and all things that are related to general purpose IO pins are basically going through this component over here. And now we have nicely reconciled those both drivers on the platform. So this is really the whole micro-colonial idea here. We now know exactly which parts of the SOCs are accessed by which driver and so we can also assess the reach of the driver on the system, that's really intuitive now. So now that I have covered these kind of small story about how the process went, let me give you a short demonstration. So as you may have guessed, I'm actually using genotes right now. So this is basically a scope-based system here. So this is my site program here and here I have a normal Linux, an Xubuntu Linux running inside a virtual box and the whole system runs on top of the Nova hypervisor. And in this terminal up here, I have connected this to the ZLine of the pine phone and over here I have a build directory for genotor for ARM V8. And now to give you the look on the pine phone, I will basically start a component to look at our webcam. So I will just deploy a small program here that basically captures the picture from the webcam and displays this in a window. And you can see here that this window appears here. So we can see the phone. So yes, some dust. Okay. So now I can issue the command to... So the phone is actually already switched on. So you see the red cable here. So the phone is powered. It's currently stuck in the U-Boot loader and it's waiting for a fast boot command. So here I can give it the command to basically run this Sculpt test run script. That's basically part of the genot tooling, targeting the base HW kernel, the board pine phone and also direct the log output to the core component of genot. So let's give it a try. So now there's not much to build. So we just integrate the image. And in this case, the image contains also some kind of pre-loaded software. So it's a bit larger than normal. So this takes a few seconds until the image is generated, but not too long after. You should see here that the system is booting up. And on the webcam, you will briefly see... Here it is. You can see that the user interface has been started. So you see now the same Sculpt OS that I'm running on this machine. So basically when I go back here, you see this same kind of system that I'm having on my machine here. The same system basically runs now on the pine phone, except for some details like no persistence storage. But for example, I can basically click on this or touch on these different user interface elements and user interface response to this. Also for example, when I touch the settings bar, you see you can basically change also some user interface settings. And one specific interesting thing is that I can deploy some scenario from memory. So I can use the RAMFS. So sorry, you cannot really see it. But I can tell you that now the system is deploying a genotes subsystem as a deployment. And here you see that some components have been loaded. I can switch to this kind of desktop by pressing it to the side here. And you see here there is a small keyboard here and a terminal over here. So I can basically... And there's actually a window manager running. So this is of course still inherited from the desktop version of Sculpt. And I can even drag these windows around and use this small keyboard. It's hard to see in the webcam. But I can basically type in a small command. For example, I can type in something like LS and return. And you see that this Linux... Not Linux, but it's a native genote-based UNIX environment. It's basically presenting some results. And I even can, in principle, also use things like Vim to edit all kinds of files on the system. And so, for example, also access the configuration file system of the Sculpt OS. So basically this gives me complete control over the device. Let me see. Q. Q. Okay. There's also a smaller demo I can show you. That's basically just rotating... Oh, maybe I haven't... Yeah, I failed to reach it here. I still have to train my fingers to type on the touch screen. So here a small program is coming up that basically... You may recognize this from previous talks. That's basically a small software rendering demo running now directly also on the Sculpt OS. And the nice thing here is that all the underlying infrastructure, like the package management concept, the deployment concept, the configuration concept, etc. It's all the same things, the same components as we use on the normal system on PCs. Okay. So that's basically what I can show you right now. So now to close the talk, let's give some ideas what's next. So the vision for this year is to have a video chat scenario running on the pine phone. So I want to chat with my family, for example, using this device, using G-Node on Sculpt. And there are of course a lot of challenges in the way. So these are just an animation of things we have to work on, which is at the same time exciting, but also a bit frightening, of course. But we are really driven towards this goal. If you want to follow the progress of this ambition, you are invited to visit the G-Node website, which is basically a kind of blog for various genome developers. And I am publishing an article series called Pine Phone, where I report on the progress that I make. And in the end, this article series will be integrated into a large document that's called the G-Node porting guide or G-Node platforms document, which will give a kind of guidance to future developers who want to bring G-Node to other SOCs. So for example, if any one of you is interested in the new Pine Phone Pro that is based on the Rockchip SOC, then this documentation is probably the best pathway to develop this kind of support. So that's already the first version of this document online, but it will be updated in May with the new findings. Okay, thank you very much for your attention. And that is the end of my talk. Thank you. So let's start with some questions. There are some questions in the chat. You or the others have partially answered them, but maybe we can just repeat them for the stream. So there was one question about the base HW. So could you just tell us what that actually is? Yeah, sure. So yeah, first thank you for organizing the deaf room together with Sebastian this year. So yeah, yeah, about the strange name of this kernel. So it's really the result of this naming scheme of G-Node. So G-Node, the G-Node OS framework supports quite a few different kernels. So you can use the G-Node OS framework on top of traditional four micro kernels or also on the Nova kernel or the SEL4 kernel or the Fiasco OC kernel and also on the Linux kernel. And at one time, like seven years ago, we had the idea to come up with a custom micro kernel that is actually much simpler than compared with the traditional kernels. So it has a kind of different software architecture that is glued more closely to G-Node. And by doing this, we expected to reduce the complexity of the base system even further. So we already had a pretty good or a pretty tight base system with the existing kernels, but we saw the potential that we could reduce it further. And so we came up with the base HW kernel. And the notion is that now G-Node runs on the real hardware, not with the kernel underneath, but the G-Node's low-level system is touching the CPU hardware directly. And so it's called base minus Linux or base minus Nova, but base minus HW, which means it accesses the hardware directly. But it's still a micro kernel. And in practical terms, it's your native micro kernel. Yes. It really fits your architecture perfectly. Exactly. Yes. Okay. So it's a small question, maybe just a clarification. So the demo you have shown, that was really running just on the phone. There was nothing running on the desktop machine. Yeah. So maybe it is the demo where I executed first G-Node on the machine, on the laptop, and then on the phone. Well, it's a bit misguiding, but yeah, the phone has a complete separate system running. And it's loaded as a single image through the fast boot channel to the phone and then executed standalone. So it's running autonomously on the phone. Yes. Wonderful. Another quick question. Do you plan to support the PinePhone Pro as well in the future? So not immediately. So the idea, so I have to come back a bit. One idea behind this work is that we will go, or the idea was to go through the process of plotting all these difficult technical challenges, but not only doing this, but also implementing all these steps in very much detail. So the idea was to, at the end of the whole process, there should be something like a book, I would say it will be like 300 pages or so, that explains in detail how this kind of process works. And so I hope, that's at least in my hope, that others will find this kind of idea inspiring that now someone else can also take this book and take a new hardware and apply the steps of this book to get G-Node running on this new hardware. So that's my goal to cultivate some kind of community around this idea. And so I put a lot of work into this documentation. So I would say more work was spent on the writing the documentation than on the actual technical work. And so I think that it would excite us very much if someone else would step up and take over this idea to bring G-Node on the Rockchip, for example, which is the chip used in the Pinephone Pro, and we would give assistance, of course, but the ownership of this project would be somewhere else. But anyway, if there's some commercial interest in that and someone would approach us, then of course we would be up to it to do this. Another point is, I think that the Pinephone is appealing because it's a limited platform. It's universally known to be not really strong, it's a bit dated. And if you look at the Linux systems on top of this platform, they do not perform really so well. So it's usable, don't get me wrong. I admire what's happening in this community, but it's not comparable to the user experience that we see on commercial phones or on consumer devices. And I think if we managed to really rock the phone with G-Node to bring a really nice user experience to the phone, it also would nicely allow people to compare the beauty of microkernel-based systems and the performance of our system to Linux to basically despell the myths that microkernel systems are slow. So if it performs better on the phone than Linux, then I think that would be quite exciting. But I cannot promise this, but that's my goal. Yes, it definitely sounds very intriguing, I should say. And going back to the UI, there was a question in the chat as well in that direction. So clearly the desktop UI is really not a good fit for this touch screen, small touch screen. So do you have any ideas or plans towards having really a smartphone native, you know, touch screen native UI? Yeah, so there are several ideas. I think it will be two-staged. So there is a one-stage where we have some basic interaction that gives the user control over the phone, but not much convenience. So that's basically what this user interface that you see right now presents. It's very small in terms of bytes. So the image is very tight and very small. It puts up quite quickly. And then there will be a second layer on top of that where everything is basically up to the different use cases. And for example, I think that it would be really nice to bring QT-based applications to this phone on top of G-Node. So for example, there is the SailFush OS that uses QT for applications. And so the applications on this phone on this OS are really native applications using QML and all the kind of beauty of this, what you expect. And there's nothing that's good to speak against leveraging these kind of frameworks like QT-QML on top of G-Node. And that's what you would then present to the end user, of course. But in the intermediate step, of course, we need to have some nice ways to interact with the phone as a developer. And so here are our kind of intermediate component like this touch screen keyboard comes to play. I think nobody really will enjoy it this, but it will have its purpose for our development and for hacking with the device, playing with the power management with the modem and all these kind of things. OK. There are several more questions, but sadly, the time is running out. So to prevent your answer being cut off, I would like to thank you again for this amazing talk. We are definitely looking forward to further development in this area and in G-Node in general. I encourage our attendees to ask you more questions in the chat. And thanks once again. See you. Bye-bye. Thank you.
The talk will be structured in three major demonstration of how GenoOS on the Pinephone are the motives behind corporations in general? constant attention by the platform companies, or You have to use the platform provider's a smartphone to look for the timetables for opposed to any kind of convenience that a subordinate myself to corporate interests. What have any changes on my devices without my I want to be in control of the device. I also really a taxation of digital life. And people are be alternatives pass forward. And this is the myself. There are a few others who share similar hardware is based on a custom SoC built in an deliberate decisions of these developers. But smartphones, one company really comes to their No, it's not because the complexity of this whole software and hardware combination defeats such a phone, you make yourself dependent on this software stacks. And finally, there is also no can be loaded directly into the device memory. get the test met with the hardware is to access basic test running was to bring a bit order in kernel and the core component of GNOT with of that, the documentation is often not available write drivers directly for the Linux kernel. And so on, that the porting of the drivers is much strategies are needed, and we can of course also component and both drivers access this higher system is booting up. And on the webcam, you will can basically click on this or touch on these see in the webcam. But I can basically type in a the vision for this year is to have a video chat different software architecture that is glued system is touching the CPU hardware directly. And comparable to the user experience that we see on and the performance of our system to Linux to applications on this phone on this OS are really