All right.
Next up we have G-Note on the platform on the track to real-world usability.
Have a big round of applause for Norman.
Thank you very much for the chance to be the second time at this developer room.
I was here one year ago introducing G-Note based phone,
and now I will give you an update what happened in the meanwhile.
So I had very little preparation here,
but I wanted to show some demo source.
If something breaks, please feel with me.
I hope it will run smoothly.
So first, to give you some background.
Microphone is a bit.
I will try.
So the background of what we are doing to just recap.
Like in 2003, my best friend Christian and me,
we had a dream about a truly trustworthy operating system.
We are somehow new from academia,
certain puzzle pieces that should lead us there,
but those puzzle pieces,
each of those seem to belong to a different puzzle each.
So that was quite difficult to align them.
Can you hear me still?
Okay. So it took us a few years to bring them into
alignment to build the first prototype back then.
Once we saw how all this could work,
we were quite motivated to bring it to the real world and
bootstrapped a company in Dresden by ourselves doing contract work.
And with the idea to do our licenses technology.
Fast forward ten years, we kept on working on this.
And during this time, we had grown a small team of ten people.
And at this time, we were able to move our work towards our genoed on our laptops.
This was a bit milestone.
And now a few years later,
we did the first baby steps to also bring it on a mobile phone.
So on the PC, it looks like this.
So this is this good OS.
That's an operating system built on top of the genoed system.
And this is actually also running on this machine right now here.
So that's basically used day to day on our developed machines.
On the phone, what I presented one year ago,
is this system running on the pine phone.
The basic idea is that there is a part of the phone that has
kind of fixed functionality like a feature phone you can think,
or like a boot loader, something that is really fixed.
And then there is a user defined part of the phone
where the user can install software into and switch it in and out.
And I will just give you a quick tour through the user interface.
Let me just log into ARM.
This type into my Linux VM over here.
And let's see if you can get some kind of video running.
Yeah, this one.
So basically, here you see the phone UI.
And the basic UI divides the phone into five categories over here.
Is it doing something or why?
Yeah.
And the device category basically gives you control over physical things,
physical aspects like the brightness or volume,
or control over the microphone like a kill switch for the microphone,
or some power settings like how you want to operate the phone.
And you can see here when I modify the brightness, it has immediate effect.
Then there is a second section that is all related to telephony.
And you see here also the user has complete control over even lower level
aspects like the powering of the phone.
So here the power lines to this phone is really controlled by the user.
So now, for example, when you switch it on, the modem is booted.
And now we interact with the SIM card and the user can type in some PIN to get
access to the network.
And now we can receive calls or initiate calls.
And we can also initiate a mobile data connection,
which I'm going to do now.
So basically, switching on the option to use your mobile data.
So you can see that's also the option to use Wi-Fi.
And now you see the three dots over here.
They are basically telling that there is a currently setting up the connection.
And once this is done, we see an IP address appearing here.
And this means we have a data connectivity.
And with this data connectivity, we can actually now do interesting things like
install photo software.
And the image when you just install it comes with a few example systems,
I would say.
So these are basically systems for the other side of the device.
You can switch these two sides using this gesture here on the left side.
And this is, for example, a very minimalistic example of an interactive
application as a subsystem running on this user defined side of the device.
And there are a few other examples, like, for example,
this small oscilloscope that just shows microphone data.
And you can see, basically, when switching to the other side,
nothing is really visible there.
That's because the microphone is still not enabled.
So the user must enable the microphone first.
And then you can see that the application, the user defined side,
can observe the audio data from the mic.
There are a bunch of other examples.
I think the most interesting one is a web browser that we ported to the system.
So this is based on the Chromium Engine and the Morph browser specifically.
So in order to bring this to our OS, we also had to port, for example,
the Uwuntu Touch UI toolkit, or nowadays called Lumiri UI toolkit,
also enable the GPU and things like that.
And you see here that the browser is running.
It's not super smooth, but you have to keep in mind,
it's a time phone that we are running on.
But it's actually usable, and you can browse those websites and
use these kind of modern JavaScript-based sites also.
I think visiting GitHub also is possible.
Yeah, this was basically what I could show you last year.
So just to get to the set of
this point, and now, okay, you see here,
the number of controls that you may know from the Uwuntu Touch UI project.
Okay, so what do I want to cover this time?
So shortly after my talk here at FOSSTEM,
we published a first image for the community to try out and to get user feedback.
And then once you get user feedback,
of course the problem you have to incorporate a somehow,
you have to do something with this.
And then you want to give the user some new version, the user needs to install it.
And so how can this interplay work to be enjoyable for both sides?
Then I want to also talk a bit about our first wishes by the users,
and then going forward to speak about how to bring software on the device.
So first when speaking about user feedback,
you have this loop where the developer installs it.
The system originally on the SD card following the instructions from the website
gives feedback to the developer, improves the image, publishes it,
and then the user installs into a new version and gives feedback.
And you have this loop.
And now the question is how fast can this loop happen and how frictionless can this be?
Friction comes in at these two places.
So for example, when the user wants to install a new version,
the question is can the user trust the new version?
It downloading something from the internet.
How much work is it to install a new version?
So if this is like a real big operating system that you have to upgrade,
it's really a lot of effort and also a risk.
What happens when you have a regression and you want to roll back to the previous version, for example?
And on the developer side, it comes down to basically labor.
So the developer has to put thoughts and work into improving the images
and then also building it, publishing it, hosting the images for the users.
So these are the costs at the developer side.
That's just how it disturbs you somehow.
This kind of rigging is okay.
So we tried to look at this cycle in a kind of holistic way.
So you see here that the developer cycle can come down to about five to 20 seconds.
So for the image that I will show you in a minute,
the cycle for iterating over this UI to things was about five seconds to 20 seconds,
depending on whether I could start this whole thing on my Linux system or on the Python via fastboot.
And then the publishing of the new version takes about three minutes or
I do a full release, 30 minutes.
So this is all done from my laptop, so I don't need any special hardware for that.
Out of this complete process comes a really small image on that source, about 16 megabytes.
And the user can basically install this.
It's signed by the developers, so there is some kind of integrity protection there.
And the nicest thing is that the installation is very simple and very transparent.
It's basically replacing just one file in the boot directory.
And the user can instantly roll back to another version if some regression occurs.
So let's now try to give this as a demo.
So to do that, I first have to, let me see.
I first have to start a USB webcam over here.
Let me see if this works.
Okay.
Okay, here's the webcam.
Okay, can you see this?
Okay, okay.
So I will switch down.
So now there are a few risks involved because the update will run over the air.
So I hope that I get some kind of connectivity over here.
So now you have seen the boot of the image from SD card.
So it's quite quick to come up, but it's also a small image.
So let's try to connect to the Wi-Fi.
Okay, I think I tested this first and do a stack.
Let me see if I get an IP address.
Ah, I got an IP.
Okay.
So now you can basically go to the software dialogue over here.
There's this tab over there, update.
And one concept is that we can basically select different software sources,
which are basically URLs.
So this is, for example, the software source of my company, JunoLabs.
But I can also select other sources like my colleagues or this guy here,
and Feske, that's me.
And I can basically check what Nfeske has to offer.
So now there are some metadata is downloaded.
And I see, okay, there are different images offered by Nfeske myself.
And I can basically get some information about these different images.
This was the last real release, and there's a new image that's the FOSTA edition.
So let's try to download this one.
And, yeah, I have luck that the wireless connection works well.
So you can see now the progress of downloading.
I can actually see it.
And you can see with these buttons, you can also download the other versions.
So you can have any number of versions downloaded and also from different software sources
and keep them on your system as well.
So we are almost there.
Okay, so now the integrity is checked using openPGB signatures.
So everything went smooth.
And now I can install this image to my system, which is basically copying one file to the boot directory.
And it says, okay, reboot to activate.
So let's do this.
So I go to the device section and I say, okay, reboot.
And I have to confirm it.
And now I'm doing a hardware reset and pressing fingers, crossing fingers.
Sometimes the boot load, ah, now it's actually working.
And now for anyone of you who also grew up in the 80s using Atari 800 computers,
you may recognize the fonts and the color scheme.
So these are inspired by my childhood.
But what you see here is really a custom image.
So I hacked this together in the last week.
We had a lot of fun with these kind of graphics.
It's basically the same functionality as the regular script image.
But you can now see that the appearance has changed completely.
So it's a completely different image.
And using the update feature, I could now also go to another place
and switch, for example, install another version and switch back to the earlier version.
Okay.
Let's continue.
Okay.
So the first response we got from the community of users was a question about the power.
So the pine phone is quite well known for not being very long lasting when it comes to the battery.
So people found it quite unacceptable that we left the screen on all the time.
So they asked, how about implementing some kind of a screen saver to save the energy.
So that was the first thing that we considered.
And I will just give you a brief tour of how this normally works.
So when you speak about power management on the pine phone,
you have on the bottom of this this power management chip,
which is in control over the actually voltages, power ramps, battery, the power button is attached there.
So these are the lowest level kind of electric concerns.
And once the pine phone switches, it's switched on,
and the communication processor starts up together with a kind of companionship,
which is the system control processor.
And these are completely separate.
So this is an ARM processor.
This is a small microcontroller.
It's based on RISC 1000 CPU core over here.
And the first thing that happens at boot is that the ARM trusted firmware is started,
and this loads the firmware into the system control processor.
So this is also an open source of the nowadays, which is pretty cool.
And this firmware is basically meant to interact with this power management chip over here.
And this can also run when the application processor gets switched off if you want to save power.
And then the Linux kernel is started, and you have these bunch of drivers.
One driver talks over these kind of devices, mailbox device and chat memory through the device to the firmware.
You can give commands, for example, for suspend or resume.
And then you have drivers for the display, for the touch input and so on, all as kernel drivers.
And then on top of that, you have the user space that uses these kernel services,
like the input driver services, like kernel mode settings, things like that.
And on top of that, you have the applications.
That's the traditional architecture that you may know.
And with G-Node, we can do a bit more flexible, so the picture looks like this.
What's the same is that we have the startup, we have this ARM trusted firmware,
but this time it loads a custom firmware, which is basically a small force interpreter.
You have to know that the execution environment over here is just about 16K, so it's really small.
So we put a small force interpreter here, but left it basically like a hull.
It has no predefined functionality, it's just an open-ended force interpreter.
And then the system be woods a small microkernel, and on top of that, now things get upside down.
Because here we have the GUI server directly running on top of the microkernel with no dependencies underneath.
So it can run without any driver running.
And the drivers, they come in later, they connect to the GUI server as a client.
So now we have put this upside down.
And so you have the applications that talk to the GUI server using the SCUI interface over here.
You have a display server that talks to the CAPTCHA service, which is the same service as you would use for screen shots and things like that.
And the input driver, the touch screen driver, talks to the event service for injecting input events.
Then there is this platform driver over here, and this guy has the job to arbitrate the access to the physical device resources,
like interrupts, memory mapped I.O. and things like that.
And so then, for example, this display driver comes up to the platform driver, asking for a platform session.
The platform driver turns on the right power, watches and the right clocks, and the driver can do its work.
And then you have this power driver here.
This uses this interface over here and can send force commands to the force interpreter and can basically extend from there at runtime, which is quite flexible.
So when we started this system, initially it grew about two and a half watts, which is quite a lot.
And now, when it's going to sleep, five minutes, oh, okay, I have to hurry up.
This is basically different.
You see this difference?
We just removed two components and that's it.
And the power draw goes up down to just one watt, thereby also tweaking some voltages.
Okay, live sleeping demo.
I don't know if this I should really show because of the time constraints, but let's do this one quickly.
So now it's sleeping, you see.
So I will also have to connect the console here, the Pico.com.
Oh, no.
Okay, I will skip this small demo.
I wanted to show you how the drivers come up, but it's probably, even time constraints, I will just skip this.
It's a bit sad, but yeah.
Okay, here we were.
Okay, the last point I wanted to talk about is the question of extending the system.
So we identified this whole bunch of work items that the developer typically has in front of him.
And we also touched this at some parts of the previous talks, like the flat out talk was quite interesting in this respect.
You have a bunch of different toolings and different build systems and so on to consider and all these different steps.
And this is quite complicated.
So and when targeting a system, the developer is confronted with all of this.
And so we came up with a tool that's called Goa.
It's called Goa because it's gold, but reached a little bit sooner.
To basically assist the developer with these steps.
And I will just show you an example how this Goa tool can be used.
Using my Linux VM over here, I go to my Goa playground directory where I'm just playing around.
And so I wanted to, for example, port the Atari 800 emulator to this phone.
So I can do a Goa run and this basically runs this emulator here now on Linux.
And I can basically see when I do a PS that these genot components that you see in the background with this Atari basic running here.
They are actually Linux processes over here.
So this is basically the Linux version of genot running on inside the VM here.
And there is a nice demo I wanted to show you for the Atari 8 bit.
So I can basically make a modification here in this runtime file.
So I will, for example, at this argument here to the emulator, do a Goa run again.
And you see here that this is now running a small graphics demo here for that's quite famous on the Atari 8 bit.
And you see now the cycle is really fast.
Okay, correct.
Then when I want to try out this on a real machine, I can say I want to target this script system over here.
So my host system, I start the test environment over here.
And I can say I want to target script and I want to give the information where this script server, where this should be run.
Okay, thank you.
Still not going.
Time's up.
Time's up. Okay, so I will stop over here and invite you to catch up with my colleague Johannes who will give a talk at the microcunnel death room later at 6.30.
And I will be there as well.
So if you want to get in touch and see where we should go.
Thank you.