 Hi, and welcome to this session about Automotive Grade Linux on Raspberry Pi. My name is Leonor Novi and I'm Senior Software Engineer at Consul Goodwill. It is a pleasure to be presenting here at Embedded Linux Conference. Before we start, a huge thanks to the whole team at Linux Foundation for switching to a virtual event on such a short notice. Fingers crossed that the future ahead of us is better and soon we'll be able to get together on physical events. Consul Goodwill, the company that I work for, is a service company specialized in Embedded Linux and open-source software. My colleagues and I have experienced in hardware and software build, design, development and training services. We have upstream contributions to various popular open-source projects among which are the Yocto project, Open Embedded, the Linux kernel itself, Uboot and, of course, Automotive Grade Linux. The company is based in California. However, we have engineering presence worldwide and I am living in Povelliburg area in Europe. The agenda for the talk today includes a brief introduction to Automotive Grade Linux followed by a few words about Raspberry Pi and the history how AGL was ported to AGL, a process that I was involved from day one. In this talk you'll learn how to build an AGL image for Raspberry Pi, how to boot it on Raspberry Pi 3 or 4. You'll understand how it works. And finally, we'll do some conclusions and there will be time for Q&A session. So Automotive Grade Linux is a project of the Linux Foundation. It is an open-source, new Linux Automotive distribution with in-vehicle infotainment. It's very important to note that Automotive Grade Linux is based on another project of the Linux Foundation, the Yocto project and the Open Embedded build framework. Automotive Grade Linux was founded several years ago and the first code delivery was in 2014. I personally started contributing to this project back in 2015 which makes five years for me. I'll be celebrating five years of contributions to AGL this year. AGL has a lot of members. These are companies from the Automotive industry, well-known names in the industry. More and more companies are joining AGL over the time. And by the way, AGL is already available on Vihos on the road, for example, Toyota Camry is powered by AGL. This is a high-level picture of the core components of AGL. So in general, AGL as a Linux distribution is not so different from the Linux distributions that we are running on our personal computers as desktops. However, there are certain components that are very specific for the automotive industry and that makes AGL special. So let's have a look at these core components. Of course, this is a very small portion of the older components that the Linux distribution has. However, I think these are some of the most important parts. So AGL works on various different hardware platforms. In the next slides, I'll show you the list of boards on which you can run AGL. So for each board, there is a specific boards for package which includes a Linux kernel version if the board does not support running mainline Linux kernel. And the boot loader, eventually some binary blocks for running the graphical user stack. AGL is powered with SystemD. There is this new audio framework, PipeWire. AGL started with ASS and PUSA audio. After that, there was another audio framework called 4AAudio. And for the past about a year, a bit more than a year, AGL is using PipeWire. This is a really exciting project covering some very specific audio use cases, especially for the automotive industry with Bluetooth connected devices. There are software over the air updates and other components which is specific for embedded devices, and especially for the automotive industry. AGL relies on OS tree, also known in modern days as Lib OS tree and actualizer to perform Git-like software updates over the air. This means that you are downloading only the binary delta, which is smaller compared to doing AB updates. And this is convenient because the vehicle might be in a region with not so good internet connectivity and it might be hard to download a huge image if you're doing AB updates. In this particular case, OS tree and actualizer are providing a better solution. Another specific thing about AGL is the graphical user stack, which is based on Wayland with Western as a compositor. And something new that is going on right now. AGL is switching from the IVI shell for Western to AGL shell desktop. This is something that is in development. I'm really excited about it. You can check some of the newer images of AGL and see how this is going on. On the top of AGL, you find human-to-machine interface applications. The default applications are written in Qt and QML. These are just demo applications. Of course, companies manufacturing vehicles for the market are replacing these applications with specific application branded for their vehicle. Alternatively, you can also use HTML5 or integrate a completely different platform for development of graphical user interfaces. Also, we have a number of supported technologies, such as GIST trimmer or video streaming. Before we move on, just to mention that another very specific thing about automotive grade Linux is the security model. SMAC has to be enabled in the Linux kernel, and AGL uses the so-called application framework. Although the name may sound as something else, the application framework is actually part of the security mechanism with Synagora, it provides permissions how different parts of the system can be accessed by applications and software components. As I said, automotive grade Linux is based on the Yocto project and open embedded. Therefore, you can see a lot of layers in AGL. AGL is based on Pocky. Pocky is the reference distribution provided by the Yocto project. There are a number of AGL-specific layers. You see that they're starting with Prefix Meta AGL. Also, there are a lot of board support package layers. Most importantly for this talk, which is focused on Raspberry Pi, is Meta Raspberry Pi. This is the layer that provides support for all Raspberry Pi models and versions. However, in the latest AGL releases, we support only Raspberry Pi 3 and 4. Other layers that worth mentioning, of course, are Meta Open Embedded, which provides a number of sub-layers, such as Meta, OE, MetaPython, and so on. If you are building a distribution, another distribution with the Yocto project and Open Embedded, most probably you end up using Meta Open Embedded too. It's probably the most popular collection of recipes in the Yocto and Open Embedded world. Meta Data, something that I've mentioned before, is required for the software over the air updates with Libo, Stree, and Actualizer. And MetaQt 5 is required for compiling and running the default demo graphical user interface. Let's have a look at the releases of AGL. AGL releases twice per year. Every six months there is a new stable release of AGL. AGL releases are named on Fishes. The latest stable release as of today is Ichi Icefish. However, just in a few days, another release candidate and a stable release hopefully after that will be released. This is going to be Jumping Jellyfish. It's part of the development process right now. Here you can see a screenshot which is taken from the AGL Wiki with the AGL schedule for this year. And so far the project is going on schedule. So in July we can expect the next release candidate. AGL runs on several hardware devices. The entire one device is the device that has best support for AGL. Our Renaissance Air Car Starter Kit generation tree boards. Most of Intel's 64-bit hardware platforms including Minuboard, Max and Turbo. These are open source hardware development boards with Intel CPU. You can also run AGL in emulator. There are two options for this. It's up to you to decide. Raspberry Pi is part of the community supported boards. Both Raspberry Pi 3 and 4 are supported by the latest versions of AGL. There are a bunch of other devices that are supported by AGL including an older version of Raspberry Pi. Raspberry Pi 2 was supported by the first Raspberry Pi model supported by AGL. However due to the limited hardware capabilities of it in the later AGL releases we stopped supporting Raspberry Pi 2. Visit this link in the Wiki to learn more about the supported devices and the particular releases in AGL in which they are supported. A few words about Raspberry Pi. I'm personally attached to Raspberry Pi. I like this platform a lot. Raspberry Pi are a series of small single board computers with the size of a credit card or even smaller, considering Raspberry Pi 0, which is out of the scope of this talk. AGL doesn't run Raspberry Pi 0. However, Raspberry Pi is a single board computer developed by the Raspberry Pi Foundation, which is based in Cambridge in the United Kingdom. All models of Raspberry Pi feature a Broadcom system on a chip and an ARM CPU. Raspberry Pi has been designed primarily to promote teaching of basic computer science. However over the time it became extremely popular platform in the maker community for hobby projects and a lot of demonstrations. And actually in AGL Raspberry Pi is commonly used for demonstrations. Raspberry Pi nowadays is a commodity. It's easy to buy. It's all around the world. Pretty much everyone has a Raspberry Pi so it's easy to just grab it, build an image, flash it in a microSD card and build it on Raspberry Pi. And by the way, the Raspberry Pi Foundation is providing a desktop distribution, which I'm sure everyone here knows, Raspbian. However, it's a very different distribution compared to AGL. And in the next slides you see the major differences. A few milestones about Raspberry Pi, important dates. The Raspberry Pi Foundation was established more than a decade ago. The first Raspberry Pi was released in 2012. Raspberry Pi then transformed with a lot of hardware differences in 2014. They extended the header from 26 pins to 40 pins and introduced the new form factor, which they keep for several versions now. The first board with this form factor was Raspberry Pi B+. After that Raspberry Pi 2, 3 and 4, all they have the same form factor. Important dates from these milestones related to AGL is the release of Raspberry Pi 3 and 4 because as of the moment the master branch of AGL supports these two hardware versions of Raspberry Pi. So in terms of AGL, the important dates start actually in 2015, when Mara Chenna, who at that time was working for Samsung open source group, ported Tizen based on Yocto and OpenBetter to Raspberry Pi 2. The difficult part there was to get Wayland and Weston properly working on a Raspberry Pi with ARM devices getting Wayland and Weston properly working. It's always one of the huge challenges even today, five years later. As I mentioned, the first code release of AGL from 2014 was based on Tizen, the IBI profile of Tizen. So there are some similarities between Tizen and AGL. Of course over the time the two projects are moving on in different directions, so nowadays there are quite a lot of differences as well. But in 2015 what Mara did was very useful because after that his work was adopted first by the Geneva Development Platform and shortly after that I was the one who used the knowledge from Geneva Development Platform and Tizen, which are both open source projects and ported AGL to Raspberry Pi 2. Over the time we also support Raspberry Pi 3, which the support in AGL was added in 2016 with pretty much the same time with the release of the new Raspberry Pi version. And last year we added support for Raspberry Pi 4, which was a quite exciting process. There were some challenges over it, which we will mention at the end of this presentation, but today we have both Raspberry Pi 3 and 4 working in the master of AGL as well as in the latest stable release. However keep in mind that Raspberry Pi 3 is with less RAM and that's kind of a problem for AGL. So I expect that in the near future the support for Raspberry Pi 3 will be dropped and AGL will focus on supporting Raspberry Pi 4 and eventually new Raspberry Pi versions of the Raspberry Foundation hopefully will release on the market. Let's have a look at how to build an image for Raspberry Pi from scratch. And before we go into details, which you already seen in this slide, I would like to highlight that it is also possible to directly download a pre-built AGL image for Raspberry Pi 3 on 4 and to save all these steps for building an image from scratch. However, the point of this presentation is that this presentation is for beginners, people that are interested in developing for AGL using AGL for prototyping and in this case you should be able to customize AGL, which means that you need to build it, to modify the source code, to build it again, to deploy it on the board and so on. So AGL is using the Google Repo 2 to simplify the process for downloading all the metadata for building an image. So first of all you need to prepare the Repo 2. This is a one-time operation. After that you need to make an appropriate directory and to initialize a repo in it. As you can see here, I'm directly initializing a repo for the master branch of AGL. This is the latest and greatest. However, this means that this is not the stable version. This is the version that is being in development. If you want to use something that's stable and properly tested, I highly recommend you, instead of using the master branch, to use the appropriate stable version as of the time when you're doing it. Repo sync command actually downloads the source code based on the repo that we had initialized on the previous command. Once we have downloaded the metadata, then there is this AGL script which initializes the build environment. So in this AGL setup script, it's a bar script. We need to set a machine. In our case, we want to build it for Raspberry Pi 4 and a list of AGL features. This is going to be a very basic image with not too many features. I'm just setting up a build environment with AGL demo and AGL application framework smart features. However, depending on the use case that you're going to use your Raspberry Pi and AGL, you should decide whether you need to enable more features. And then you need to execute BitBake. BitBake is coming from the AGL project in open and better. People will experience with the AGL project already familiar with BitBake. So the name of the most common touchative image in the AGL world is AGL demo platform. So the build from scratch takes a significant amount of time because AGL has a lot of components. The time depends on your internet connection speed because in the previous step we just downloaded the source code of the metadata which BitBake uses to start building each package, each recipe. Now we are going through the download task for each of these recipes. And this will, again, take some time to download depending on your internet connection speed. And after that it also depends on the hardware capabilities of your build machine. Something super important to note, the whole procedure that you see here the idea is that you should execute this on a machine with x8664 CPU from Intel or IMD with a Linux distribution that is compatible to the GunFeld release of AGL. For example, I'm an Ubuntu user. I'm running Ubuntu both on my laptop and my build machines. So I have built this image on Ubuntu 18.4. It's also possible to build it on other new Linux distributions. Have a look at the appropriate Yocto Mega Manual for release GunFeld as of the moment or from your releases if you are watching this presentation later on. To figure out which are the supported distributions if the distribution that you are running on your build machine is different please consider building it in a container. So the supported Raspberry Pi models which you can set in the AGL script that initializes the build environment at Raspberry Pi 3 and 4 this is a short list of some of the AGL features that you may consider. For example, the AGL netboot for boot over the network or AGL soda which enables the software over-the-air upgrades. Run source meta-aGL slash script slash aGL setup.nch help to show the list of all features supported. Once the image is ready it will end up in the temporary deploy directory for the image that you've selected. For Raspberry Pi 4 we are building a 64-bit image of AGL. The output file is weak and you need to extract it and flush it on the microSD card. The easiest way to do it is using DD. However, just be careful to find the appropriate SD card device otherwise you risk to wipe out your drive. For beginners it's also possible instead of using a DD to use software with graphical user interface such as Balana Etcher or the recently released Raspberry Pi foundation, Raspberry Pi Etcher. Once you're ready with the flushing procedure, flip the microSD card in the Raspberry Pi and turn it on to turn on the Raspberry Pi. All you need is to plug an appropriate USB cable for Raspberry Pi 4. This has to be a USB-C cable. The first boot of AGL takes a little bit more time because it's doing some one-off preparations. Each next boot is significantly faster. These are the common AGL images. We build AGL demo platform, but there are also other images such as AGL image IVI, which is a very base image for IVI targets, or AGL image minimal, which is a minimal file system with APIs without graphical interface. There's also an AGL image that just includes Wayland and Weston. Explore these images if you need to customize them. However, the most common target, especially if you are a beginner, is AGL demo platform. This is an output from the serial console. So basically you can connect your computer to the Raspberry Pi using the UR pins on the 40 pin header of the Raspberry Pi and using USB to UR cable, you can monitor the serial output as the Raspberry Pi boots. This is an ad-copied sample of how our mode of grade Linux has been booted on my Raspberry Pi 4. The default login is through, and this is the Linux kernel version that I printed it out. The serial boot rate, if you're doing something like this, is 115-200. A few screenshots of Raspberry Pi on AGL Raspberry Pi 4. These are three screenshots. The first screenshot is the home screen with all the installed applications. As I told you, the first boot takes a little bit more time because all these applications are automatically installed in the first boot. This boot is significantly faster. These are, of course, just demo applications just to prove that the platform works and to allow you to make more complex demonstrations. The second screenshot is from the HVAC application, and the third one is from the settings and more specifically from the about section of the settings. Here is system D lock of Western. As I told you, this is something very specific for AGL. AGL relies instead of X11 on Wayland, and Western is a reference compositor for Wayland. Wayland has actually, over the time, been adopted not only by the automotive industry, but also you can find it in modern smart TVs manufactured by LG and Samsung, respectively with WebOS and Tizen. As well as even in smart watches with Tizen. Supported Raspberry Pi peripherals in AGL, these are peripherals that we try to test. HDMI monitors. Of course, this is the most common setup to plug an HDMI cable in your Raspberry Pi. For Raspberry Pi 4, it's going to be the first AGL by connector. Of course, the Raspberry Pi official 7-inch touchscreen display, which has a separate connector on the Raspberry Pi board, is also supported. Starting with Raspberry Pi 3, the platform has a built-in Wi-Fi and Bluetooth capabilities. They are supported and they work. However, they are not super reliable. In AGL JIRA, you can see some people complaining about the real abilities of the Wi-Fi. So if you are experiencing something like this with the Wi-Fi and it's highly recommended to use USB dongle as an external hardware and plug it into a Raspberry Pi for more stable Wi-Fi connection. Also, you can attach various third-party add-on boards and hats. Hats is a hardware standard introduced by the Raspberry Pi Foundation. It means hardware attached on top. The device is that you plug on the 40 pin header of the Raspberry Pi and it has an EEPROM with device tree binary overly connected to pins 27 and 28 of the Raspberry Pi header. Where is the secondary I2C? Okay, so we've built an image. The image boots. We've seen all this, but how does this really work? So first of all, the core component of building AGL is the Yoctop project. The Yoctop project is an open source collaborative project of the Linux Foundation for creating custom Linux-based systems for embedded devices using the open embedded build system. Open embedded build system provides BitBay which you have already seen in the previous slides how to use to kick off a build of an image and open embedded core. Pocky is the name of the reference distribution provided by the Yoctop project. It is used by automotive-grade Linux. In one of the previous slides, you saw it among the list of Yoctop open embedded layers. So Pocky provides, it's provided as metadata. There are no binary files there. They use to bootstrap your own distribution for embedded devices and to save you some time because Pocky is on its own. It's a very minimal Linux distribution that you can boot. The Yoctop project has the annual release cycle twice per year. There is a new release of the Yoctop project. This happens in the spring and in the autumn. So here is the current releases of the Yoctop project. As of the moment, since April, the stable release of the Yoctop project is called Dunfile. This is version 3.1. This is a long-term stable. The names of the previous releases were Zeros, Warrior, Tud, Sumo, Rocco, and so on. The next release is hopefully scheduled for October this year. AGM Master, as of the moment, is based on Dunfile. Here is ColdSniper taken from the default XML. This is the repo manifest that we are actually using for the build that we did on the previous steps because when we did this repo init command, what it actually did was to download this default XML manifest and using it to do the repo sync. So here you see the exact tree visions from the build that we did, or at least I did at the time when I did it, and the upstream is referencing to the latest stable release of the Yoctop project called Dunfile. AGL also provides other releases, so if you want to use a stable release for AGL instead of Master, you can explore the AGL slash AGL repo and figure out the exact release that you need for the build that you are touching. It's very specific depending on the project you are working on. If you don't know how to start, what I would recommend to you is the latest stable release. A few words about Meta Raspberry Pi we've already mentioned on a couple of occasions. This is a general Yocto Open Embedded board support package layer for all models and versions of Raspberry Pi. It depends on layers from Meta Open Embedded. These are Meta OE, Meta Multimedia, Meta Networking, Meta Python. It provides specific variables as knobs to enable-disable hardware-specific features. In AGL we have the UART-enabled as well as UBOOT. Another very important thing is the variable that sets the type of KMS that should be used in AGL to support Wayland and Weston and the demo applications that you've seen on screenshots. We've got the HDMI monitor and the official Raspberry Pi 7-inch touchscreen display. Last autumn in October and November we had some difficulties to figure out why the official Raspberry Pi 7-inch touchscreen display isn't properly working in AGL on certain Raspberry Pi models and it appears that at that time we were using KMS instead of firmware KMS. So the solution was to switch this variable to the value that you see here which basically means using the firmware KMS. If you find a bug and want to report it, if you want to fix it or add a new feature to Meta Raspberry Pi, do it as a GitHub pull request. This is the link in GitHub where you can find it. The maintainer of Meta Raspberry Pi is Andre Gersen. There are more than 90 contributors, a very active community. Raspberry Pi, after all, is super popular so there are a lot of people interested in looking after this support package and I have to say that Andre is doing a great job and this is one of... Actually, this is my favorite more support package layer for Yocto Project and Open Embedded. There is also a great documentation. It's available at the link here at Read the Docs. Meta Raspberry Pi in AGL is done in the following way. So when you run the AGL setup script for Raspberry Pi, if you specify Raspberry Pi 3 or 4 as a targeted machine, it initializes the built environment by automatically populating comf slash local dot com and comf slash bblers dot com. So Meta Raspberry Pi will go into the bblers dot com file in order to take advantage of all the things that it brings for supporting AGL. So furthermore, there is one sub-layer of Meta AGL called Meta AGL BSP which contains hardware-specific configurations so AGL setup will take care of automatically loading it also in the bblers. In local dot com file, if you have a look at it, for example, if you open it with Vim or none or whatever is your favorite text editor, you'll notice that it will include AGL underscore Raspberry Pi 3 or 4 depending on the machine that you've selected. So these are again hardware-specific configurations for running AGL on Raspberry Pi. So what are these hardware-specific configurations? Well, AGL on Raspberry Pi uses Uboot as a bootloader, not the default bootloader provided by the Raspberry Pi Foundation. We are using Uboot. We're setting up the GPU memory. We're enabling QR which provides us the opportunity to monitor the serial output while the board boots. Also, various kernel modules as well as Wi-Fi and Bluetooth firmware are included in the AGL demo platform image that we've learned how to build in one of the previous slides. A few words about the AGL software over-the-air updates. In order to enable them, you have to explicitly type in the AGL sort of feature when you're running the AGL setup script. It will include a couple of Yocto and Open Embedded Layers. They're called MetaUpdater and MetaUpdater Raspberry Pi. As the name suggests, the second layer, MetaUpdater Raspberry Pi, contains some specific BBA plan files to run Oystree and Actualizer and properly make the partitions and everything for booting on a Raspberry Pi. LibOstree is a great project that I really admire because it provides a Git-like model for committing and downloading updates. Initially, it was a technology that was developed for desktop distribution. Actually, DOM continues using it for code assurance. And several years ago, maybe four or five years, it was supported to embedded devices. I was happy to be part of this process. There is a tool called Actualizer which was developed by the German company Advanced Dynamics Systems, which was acquired by here, and here is now developing it, which is an overall open source tool for automatic provisioning of bootable file system trees to a fleet of vehicles. This is something specific for the automotive industry. You can use LibOstree and Actualizer either in AGL using the AGL sort of feature, or if you prefer, you can even integrate them in a separate, your own Yocto and open and embedded distribution, even if it's not AGL. More details about how to use it are available both in the Wiki of AGL as well as the documentation, the official documentation of Actualizer provided by here. Both links are available in the slides. Let's have a look what development tools are used in AGL so that you can join the project and use them. Actually, all those tools are quite popular in the industry and most probably you are already familiar with them, so it's going to be great. As you have seen, the source code in AGL is stored in various Git repositories and the Google Repo tool is used to easily, with just a few commands, check out these repositories together and build an image. For code reviews, AGL is relying on Garret. Also, there are Git Hub repositories but only for the documentation. Here you can see both links to Garret and Git Hub. If you find the bug and want to report it, go to Jira. This is the bug tracking system that AGL uses. There is also great Wiki, so if you find something specific or if you are searching for some specific information, have a look at the Wiki first. And for the general documentation, the official documentation of Automotive Great Linux is available at docs.automotivelinux.org. AGL relies on Jenkins for continuous integrations, Lava and Fuego for running tests. A few words about AGL. Garret, this is a free and open source web-based team called Collaboration Tool for code reviewers. It is specifically useful when you have large projects and, definitely, AGL is a large project with people working and reviewing code that are distributed around the world working in different time zones. AGL simplifies the code review process and it's a great tool for this job. You can use AGL. Garret, all you need to do is to create a free account at identitylinux.foundation.org to be able to log in to garret.automotivelinux.org. The workflow for contributing to AGL is basically that you report an issue or a new feature in Jira. After that, you modify the source code and you include a reference to the Jira issues in the commit message that provides the bug fix or the new feature and you have to contribute it to the AGL. Garret workflow which is pretty standard for using Garret. Basically, the idea is that you are cloning locally the git repository you are modifying it after that you are pushing changes which are pending under review and a reviewer must vote and if the change is approved by the community if it has enough plus votes the maintainer will submit it to the AGL repository. Here is an example this is a screenshot taken from one commit that I did a few months ago and it has been merged in AGL Garret I have mentioned that back in the days last autumn we had a lot of problems supporting both the AGI monitors and the 7 inch official Raspberry Pi touchscreen display so the solution was to switch to firmware KMS so here if you notice there is a bug AGL tag and it contains a link to the GERA issue this is spec 2465 so this is very convenient because if you are reading the log several months later as we do here today you can just click on this link and you see the whole history with more details what has been done and why it has been done I encourage you to join the AGL communication channels AGL has some mailing lists there is a weekly developer call each Tuesday where all developers get to discuss the progress of the project this developer call takes about an hour or even less and if you have a quick question you can always join the automotive channel on free note so a few conclusions at the end of this presentation as you have seen Automotive Great Linux is a collaborative open source project that is bringing together automotive makers suppliers and technology components as well as individuals the idea is to accelerate the development and adoption of fully open source software stack based on Linux this is really important for the Connective Car AGL is a Linux foundation project Raspberry Pi is just one of the supported platforms by AGL of course AGL is in general targeting to run Automotive Great hardware Raspberry Pi is not made for cars however it is a very convenient platform for getting started for doing proof of concept demonstrations because Raspberry Pi is cheap and it is easy to get most probably there is a distributor near you so you can easily buy a Raspberry Pi and get started I hope this talk will encourage you to join the Automotive Great Linux community start contributing to the development to the testing by reporting bugs on JIRA or to the documentation AGL is participating in the Google Summer of Code programs as well as Summer of Documentation the community managers of AGL can share more details about it they are part of the embedded Linux conference have a look for Walt or Jan Simon to chat about the project if you are interested and want to learn more details how to join our community thank you very much here are a few useful links and I will be happy to hear your questions thank you very much for your attention again hi thank you very much for joining this session there are a lot of useful commands and questions so I will start answering them Randy from the Linux Foundation who is looking after the infrastructure of AGL has a very important command he wrote that soon there will be GitHub Repositories not only for the documentation but also for the source code so thank you very much for this command another question does this work for Raspberry Pi Zero sorry Valentin no AGL doesn't run on Raspberry Pi Zero W because Raspberry Pi Zero and Raspberry Pi Zero as well as the very first version of Raspberry Pi Zero have a very constrained hardware this was the same reason why we stopped supporting AGL on Raspberry Pi 2 AGL requires quite a lot of resources and as a conclusion of this talk I would highly recommend you using AGL on Raspberry Pi 4 with 4 or 8GB of RAM because of the UI another question Orlin is asking Qt and QML has been very common in the automotive industry is HTML5 getting popular as well do you know any car companies that run HTML5 for UI I'm not familiar with products integrated in cars on the road the idea in AGL is to provide a platform on top of which manufacturers can change the UI and shift it to the market however you can see some demonstrations by Igalia running HTML5 applications on embedded Linux devices and on AGL sorry that I cannot provide any details about products available on the market it's just something that I really don't know another question does AGL support any can shoots for Raspberry Pi yes, Marcello can shoots are supported however I don't remember on top of my hat the exact model for Raspberry Pi had with Kanda was supported is supported by AGL however this year during the demonstrations at CES and FOSDM AGL had a demo with Raspberry Pi I had exactly through this please let's continue this conversation in Slack and I'll try to find pointers and providing more details about it I believe Jan Simon from Linux Foundation can also provide details on this thank you very much for your comments here's another question that's important to answer how can open source beginners start contributing to AGL you can follow the instructions and the links shared in my slides and my slides are already available at chat after the conference I'm going to share them also in slide share and linked in so the easiest way is first to join our community the mailing list the weekly developer calls on Tuesday the IRC channel to have a look at the documentation and the wiki to get started and hopefully this presentation will catch you and more people to join our community and get started AGL is a great product open source product for beginners to get started with open source and something that's made for embedded devices and especially the vehicles all right Kurt is asking apart from infotainment telematics what other anticipated application domains yeah that's a good question there are many demonstrations done with AGL especially in the past years as you have seen in this presentation there are a lot of changes going on there was even a demonstration with Alexa integrated in AGL so again I would recommend you to have a look at the CES demonstrations with AGL there are details about them in the AGL wiki there is a big question here I know it's a big question but what are the usual challenges with porting AirPyBSP from Western and perspective yeah that's a huge challenge it was a huge challenge nowadays it's not such a challenge because of the excellent shape in Meta Raspberry Pi unfortunately I don't have enough time to answer in details however if you are basing an embedded distribution built with the Yachter project and open embedded on the Meta Raspberry Pi BSP layer nowadays porting to Wayland is way easier than it used to be thank you very much for joining this presentation it's great to see so many commands and questions we're running out of time so please let's continue the discussion in Slack you can find me there in the embedded track as well as in the Yachter project track and the video software track so it's going to be great to continue the discussion over there thank you very much for your attention and huge thanks to the holding of Linux Foundation for organizing this virtual event I hope you've enjoyed see you