WEBVTT 00:00.000 --> 00:14.840 So, hi everyone, I'm Francesco, and I work on the Unure project. 00:14.840 --> 00:19.200 So we often hear about breaking the mobile do-opily. 00:19.200 --> 00:24.400 So today I want to talk about our initiative and how we are bringing a mobile OS that 00:24.400 --> 00:30.400 is designed for one specific regional ecosystem and how we bring it to the global open source 00:30.400 --> 00:36.720 community and how we make it run on sound up phones. 00:36.720 --> 00:42.320 So what is Unure and how does it relate to Open Harmony? 00:42.320 --> 00:49.480 Open Harmony is a project that was launched in 2020 as a code donation from Huawei to the open 00:49.480 --> 00:51.680 source community. 00:51.680 --> 00:58.840 And it's a massive project, it's mature and it powers Harmony OS that runs on Huawei commercial 00:58.840 --> 01:00.720 devices. 01:00.720 --> 01:06.240 So Open Harmony was primarily incubated in the Chinese ecosystem and so that's the role 01:06.240 --> 01:12.560 of Unure is to build a bridge and to bring this project globally. 01:12.560 --> 01:17.240 So it's an Eclipse Foundation project and it's based in Europe and we take the Open Harmony 01:17.240 --> 01:24.120 code base and we wrap it in the European governance. 01:24.120 --> 01:26.120 So why do we need a bridge? 01:26.120 --> 01:30.960 So if you're a developer outside of China and you want to work with Open Harmony, you 01:30.960 --> 01:33.160 might hit some friction. 01:33.160 --> 01:42.200 For example, Open Harmony code is hosted on Chinese GitHub from or the documentation 01:42.200 --> 01:50.040 is often in Chinese and the hardware used by the community is often not available in Europe. 01:50.040 --> 01:55.560 So Unure tries to strips that friction away and we maintain GitHub mirrors, we maintain 01:55.560 --> 02:02.200 English first documentation and we focus on hardware enablement for devices that people 02:02.200 --> 02:09.600 actually have, maybe already in your jar or you can actually buy and we also provide tooling 02:09.600 --> 02:14.760 that are developer friendly. 02:14.760 --> 02:20.560 So let's dive into the architecture, Open Harmony is not just a phone OS, it's one OS 02:20.560 --> 02:27.240 any device and it can scale from the mini system running on MCU with kilobytes of RAM all 02:27.240 --> 02:31.200 the way to the standard system that runs on phones and tablets. 02:31.200 --> 02:37.040 So for this talk in the possible mobile context we're focusing on the standard system that 02:37.040 --> 02:45.920 has the full stack, it has 3D GPU support and a complete application ecosystem. 02:45.920 --> 02:51.600 So one question that I often hear is, is Open Harmony or Unure based on Android? 02:51.600 --> 02:57.480 So the question is the answer is no and it's a completely new software stack and it's 02:57.480 --> 03:06.320 designed from the ground up to enable seamless collaboration between wide range of smart devices. 03:06.320 --> 03:15.120 So here's a high view level of the kernel and so the kernel at the kernel level we support 03:15.120 --> 03:21.960 multiple kernels, we have light OS for the mini system and Linux for the standard system 03:21.960 --> 03:27.040 and above that we have an hardware structure layer called hgf and a graphical layer called 03:27.040 --> 03:29.640 the rows and so I'll explain this in a moment. 03:29.640 --> 03:34.880 But the things get innovative with distributed capabilities, we have the distributed framework 03:34.880 --> 03:40.160 that allows devices to collaborate with each other, discover each other and virtualized 03:40.160 --> 03:41.160 hardware. 03:41.160 --> 03:47.200 So think about the phones camera that can be mounted on two tablets over Wi-Fi as if they were 03:47.200 --> 03:50.360 a single super device. 03:50.360 --> 03:56.480 But for us, porters, the challenge starts at the kernel layer. 03:56.480 --> 04:04.040 Open Harmony uses Linux 5.10 or 6.6 so you cannot use vanilla mainline and you need some 04:04.040 --> 04:07.640 specific configuration enabled. 04:07.640 --> 04:17.320 So we need binder IPC like in Android and Ashmem, anonymous shared memory, similarly to Android 04:17.320 --> 04:24.840 until Android 12 recently Android migrated to MemFty but Open Harmony still relies on Ashmem 04:24.840 --> 04:29.840 so you need to patch the kernel if you're tracking mainline and you need also some other 04:29.840 --> 04:35.640 open Harmony specific extension like for hdf and for access token ID for the security 04:35.640 --> 04:37.240 subsystem. 04:37.240 --> 04:42.160 So these parties are required for our porting. 04:42.160 --> 04:48.520 The part that usually confuses people coming from ASP or from Linux is the use of hdf, 04:48.520 --> 04:52.240 the hardware driver from foundation. 04:52.240 --> 04:58.840 So it might look like that we are reinventing the wheel but hdf is actually a middleware. 04:58.840 --> 05:02.080 It's not a replacement for a kernel. 05:02.080 --> 05:10.400 The Linux kernel remains there, we still use the device 3 and the user space rather than 05:10.400 --> 05:18.000 talking directly to the kernel drivers it talks to the hdf which abstracts the service publishing. 05:18.000 --> 05:25.760 So this allows us to write one driver interface once and you can run all on both the Linux 05:25.760 --> 05:35.000 kernel and both on the light OS so it decouples the driver logic from the underlying kernel. 05:35.000 --> 05:41.680 Moving to the graphics, the graphical stack is called Rosen, application don't draw the buffers, 05:41.680 --> 05:47.760 they build a local scene graph and they batch this command via IPC to the render service 05:47.760 --> 05:55.640 which reconstructs the scene and execute the GPU draw commands and how does it talk to 05:55.640 --> 06:00.040 the hardware rely on the standard Linux graphical stack. 06:00.040 --> 06:07.040 There's the display hardware device interface that wraps around the standard DRM and 06:07.040 --> 06:10.280 KMS for mode setting and B-sync. 06:10.280 --> 06:16.840 There's a memory hdf that wraps around the Ragnol, Ralloc or GPM and it uses direct memory 06:16.840 --> 06:20.880 access buffers for zero copy buffer sharing. 06:20.880 --> 06:26.400 So if you're porting a device that already has a good mainline support for DRM, you already 06:26.400 --> 06:30.160 have with there for the display stack. 06:30.160 --> 06:36.200 But here's the catch, the GPU driver problem, to get hardware acceleration you need drivers 06:36.200 --> 06:42.680 and in the mobile world, the vendors often provide blocks that are linked against bionic 06:42.680 --> 06:49.560 eclipsy for Android and on OpenHarmony, we use Mazol eclipsy that is more lightweight 06:49.560 --> 06:52.600 but it's not binary compatible with bionic. 06:52.600 --> 06:58.280 So either you have a very good friend at the chipset manufacturer that can build a Mazol-based 06:58.280 --> 07:05.760 driver for you or you use open source Mazol drivers but many mobile SOC lock support for 07:05.760 --> 07:08.040 Mazol. 07:08.040 --> 07:14.200 So how do we support the already existing thousands of Android devices, we integrate the 07:14.200 --> 07:17.360 libraries to access a translation layer. 07:17.360 --> 07:23.520 So it sits in between the Mazol-based user space and the bionic-based vendor blocks 07:23.520 --> 07:28.080 and it overrides the symbols and dynamically links the libraries. 07:28.080 --> 07:33.120 So this allows you to run on existing hardware using the proprietary GPU drivers. 07:33.520 --> 07:40.600 It's a workaround, it's not ideal but it can lock support for existing hardware. 07:40.600 --> 07:44.080 So OpenHarmony is already ported by the community on many devices. 07:44.080 --> 07:50.480 For example, we can demonstrate a OnePlus 60 which is the pure path, it has a good 07:50.480 --> 07:58.760 mainline support and so we use pre-dreeno for the Mazol drivers so it's the fully open stack. 07:58.760 --> 08:04.800 For the second example we have is we're porting to the Voila devices, here the mainline support 08:04.800 --> 08:12.400 is thinner so we're implementing the hybrid approach and we got the system booting the 08:12.400 --> 08:15.600 RAM display output and patch input. 08:15.600 --> 08:23.280 So this proof that we can both tackle the open path and the proprietary paths. 08:23.280 --> 08:30.240 Beyond physical devices we also developed a QMO-based emulator for development using 08:30.240 --> 08:33.120 a Mazol-Grivers for software rendering. 08:33.120 --> 08:38.600 It's using X86 architecture for a hyperparzac acceleration. 08:38.600 --> 08:44.400 So you can use this rather than having to ship a development board from China. 08:44.400 --> 08:49.160 Moving to the application layer, OpenHarmony uses RTS for development which is an extended 08:49.160 --> 08:56.560 TypeScript language for design for this platform but you can also use other cross platform 08:56.560 --> 09:00.400 frameworks so we are bringing React Native and other others. 09:00.400 --> 09:06.280 So developers can bring their existing application without too much effort. 09:06.280 --> 09:10.240 And we're also trying to improve the developer experience. 09:10.240 --> 09:17.400 We are providing a only RID extension for VS code which can handle SDK building application 09:17.400 --> 09:20.680 and deploy them on any device and its sports Linux. 09:20.680 --> 09:24.800 So this can lower the entry barrier for. 09:24.800 --> 09:32.520 So unfortunately I don't have much time so we're bringing mobile OS that is owned by any 09:32.520 --> 09:37.840 single corporation so I invite you to join the community and let's code local while 09:37.840 --> 09:39.480 thinking go boom thank you.